PhanTom
11.01.2006, 20:01
Может у кого есть предположение почему так?
Проблема в следующем, в прикрепленном файле пример:1 выдаваемой строки CDR, а пример:2 так как она должна выглядеть в соответствии с описанным в доке форматом. Почему добавляются дополнительные пробелы "h00"не понимаю? Станция М1 Opt.11 Rls S4.0

neoplan
11.01.2006, 20:22
А какое описание Вы смотрите?
У меня на 11С R25.40 указанный вариант 2, в то же время на 61С S3.0 указанный вариант 1.

Имхо не стоит заморачиваться с поиском ответа на вопрос, главное чтобы тарификатор правильно отрабатывал.

pvalera
12.01.2006, 20:15
Я тоже на нескольких Меридианах встречал такую разновидность формата, где рут от транка был отделен символом h00. Предположительный диагноз - версия софта.

Хотя не исключено что это неверный диагноз...

Согласен с neoplan. Заморачиваться не стоит - не та проблема. Прийми как должное и всё...

vv11
13.01.2006, 07:52
Предположение такое, символы 00h разделяют рут от транка всегда. По крайней мере с релиза 15 до 25 это точно.
Почему он может быть виден не всегда? Скорее дело в терминалке, дело в том, что символ 00h должен терминалкой либо вырезаться, либо заменяться на символ например 20h (пробел), который вы потом видите в терминалке как пробел.
Обрабатываться он должен обязательно, так как иначе в любой строковой переменной он будет являться символом окончания строки со всеми вытекающими отсюда последствиями.:(

PhanTom
13.01.2006, 12:16
Описание которым руководствовался:553-3001-350. Дело в том что этот управляющий символ "00h" встречается не только в разделении номера рута и транка, между секундами и долями секунд, но и и в других позициях. Судя по всему это BUG. По большому счёту Вы правы, особой проблемы нет. Но если это возможно исправить, то хотелось бы знать как?

pvalera
13.01.2006, 15:20
vv11 пишет
Предположение такое, символы 00h разделяют рут от транка всегда. По крайней мере с релиза 15 до 25 это точно.

Это предположение ошибочно.
Я использую _только_ свой модуль регистрации соединений. А он не может в одних случаях регистрировать h00, а в других нет.
Уж его логику работы я знаю абсолютно точно :p

Больше я склонен согласиться с PhanTom пишет
Судя по всему это BUG

pvalera
13.01.2006, 15:27
Кстати, если это баг, то причина его появления может быть связана именно с тем, на что указывал vv11. Строка о коннекте собирается меридианом из кусков (рут, транк, дата и т.д), но некоторые куски этой строки ошибочно копируются на 1 символ длиннее чем нужно, т.е. с завершающим h00 поэтому он и появляется в CDR ...

Gluker
13.01.2006, 16:05
Если бага наблюдается более 10 лет, то это уже фича.:)

RXL
13.01.2006, 20:39
Не надо забывать, что это терминальный порт, а не файл на винте - тут каждый байт имеет смысл (0 = NUL = нефига).
Если удалить все нулевые байты из строк, то записи полностью соответствует спецификации.

pvalera
15.01.2006, 04:22
Gluker пишет
Если бага наблюдается более 10 лет, то это уже фича.:)
Абсолютно не согласен! Просто категорически!
Бага становится фичей не по истечении времени, а по мере отражения в документации :p

Если отразили - значит фича. Но я что-то пока нигде не видел отражения этого факта вендором в документации.

Учитывая вышеизложенное, сей феномен, скорее баг, чем фича. :D Хотя я не читал последних релизов доки, может быть все - таки уже фича, а не бага :D

RXL пишет
Не надо забывать, что это терминальный порт, а не файл на винте - тут каждый байт имеет смысл
Кхм! Воистину, век живи - век учись - дураком помрешь. Вот кто бы мог подумать, что в файле на винте не каждый байт имеет смысл! :D Может опубликуете список байтов, которые в файле на винте не имеют смысла? А то "мужики то и не знают". :p

vv11
16.01.2006, 08:20
Ув. pvalera я так понимаю от "скромности" вы точно "не помрете" и поэтому еще раз предлагаю вам такой способ решения проблемы: в процедуре которая в вашей программе получает байты нужно либо "вырезать" байты 00h, либо заменять их на другие, тем более я так понял вы крутой програмер и сделать такое "пару движений мышью".:D
В софте Меридиана есть более серьезные баги, которые не "лечаться" годами, а вы про такой пустяк, скажите спасибо что Нортел дает даже такую доку.

PhanTom
16.01.2006, 11:22
Добрый день, напишите пожалуйста на что Вы подразумеваете говоря:- ".... серьезные баги, которые не "лечаться" годами... ."

vv11
16.01.2006, 13:12
to PhanTom
Навскидку: проблема с NCOSами при включении по R1,5(челнок), проблема с локаутами на 2-х проводках при использовании DTD...
Думаю у остальных форумчан есть список чтобы продолжить..
Никому не в обиду, софт Меридиана после того как его написание передали из Англии в "чернокожую" Францию значительно прибавил в багах и это факт, даже не взирая на то что в нем прибавилось фич.

pvalera
16.01.2006, 21:43
vv11 пишет
Ув. pvalera я так понимаю от "скромности" вы точно "не помрете" и поэтому еще раз предлагаю вам такой способ решения проблемы:
Уважаемый vv11 !

Спасибо за Ваш долгосрочный жизненный прогноз. Вообще-то хотелось бы "помереть от старости" в окружении любящих внуков и правнуков. Но то, что я "не помру от скромности" уже вселяет оптимизм и повышает настроение
:p

Касательно "способа решения проблемы" - это не ко мне. Благодаря грамотному проектированию системы в далеком 1995 году нам удалось избежать "детских болезней". Я в этом топике только подвердил факт "двойственного" поведения CDR. ;)

Что касается документации Нортеля, то более грамотной и подробной документации по CDR я не встречал с 1995 года ни у одного вендора. Так что Нортелю "зачет". :p

RXL
17.01.2006, 01:46
Кхм! Воистину, век живи - век учись - дураком помрешь. Вот кто бы мог подумать, что в файле на винте не каждый байт имеет смысл! :D Может опубликуете список байтов, которые в файле на винте не имеют смысла? А то "мужики то и не знают". :p
:D Смешно.
Может я грубо выразился, для простоты понимания. Попробую еще проще.
Смысл "управляющих кодов ASCII", надеюсь, понятен? Так же, надеюсь, понятно, что они придуманы для tty и в другом контексте могут не иметь подобного значения.
Чтоб стало еще смешнее, открой картиночный филец и найди смысл первому попавшемуся нулевому байту, а так же байтам 10, 13, 27 и т.п.

jellfish
17.01.2006, 10:16
Вариант решения проблемы без переписывания программы.

Берете между станцией и компьютером который принимает CDR строки ставите еще 1 компьютер и на нем просто убираете эти ненужные символы. Как я понял это 00h значения. С промежуточного компьютера пишете во 2 порт с которого и читаете данные вашей программой.

pvalera
18.01.2006, 15:58
RXL пишет
:D Смешно.
Может я грубо выразился, для простоты понимания. Попробую еще проще.
Стойте - стойте...
Я не имел ввиду ничего личного... :D
Просто решил пошутить...
Видимо зря...
Я Вас прекрасно понял еще с Вашего первого поста в этой ветке.
Обсуждение темы уже стало перерастать в выяснение сторонних моментов, никак не связаных с изначальным вопросом.
Автору топик, вероятно, более не интересен, впрочем как и мне. Поэтому я самоустраняюсь.
До новых и интересных дискуссий. :p
jellfish пишет
и на нем просто убираете эти ненужные символы.
Уважаемый jellfish!
В программировании _ненужных_ символов не бывает :p
То, что Вы предложили, на мой взгляд, чесание правого уха левой ногой. В принципе возможно, но неверно по определению. :p
Ничего личного, просто констатация факта.

RXL
18.01.2006, 17:48
:D

TheRam
19.01.2006, 13:59
занятно, что простая операция по фильтрации cdr вызвала такой накал страстей :-) Чуть не подрались...
Действительно, в грамотно написанном софте такие нюансы устаняются за пару минут, и не надо чесать "левым ухом правую ногу" :D

jellfish
19.01.2006, 14:06
"левым ухом правую ногу"

и вот тут

То, что Вы предложили, на мой взгляд, чесание правого уха левой ногой.

Согласен. Но как быть человеку если софт уже написан (или куплен хз где и хз когда) и в его код не влезешь...

TheRam
19.01.2006, 14:10
А вот это уже другой случай !!!
Как раз "маза" предложить свои услуги :-)