утро доброе.

переключился на другой проц (дабы до аудита провеить резервирование), инциденты пропали, ни одного за сутки не появилось, хотя базы то одинаковые . похоже проблема именно на основном процессоре.
будем искать в чём.

дня доброго всем.
vad, броадкаст был включен, после рестарта подождал часа 2 и сделал симуляцию аудита, похоже пришло время сделать аудит, симуляция показала много мелких нестыковок, странно что по броадкасту не прописалось.

вывод инцидентов перезапустил, заметных изменений нет.

ничего нет, чисто

после аудита отпишусь что да как.

vad,
ха000002 - это данный процессор(на сейчас MAIN), на стенд бае всё тихо.
аудит и броадкаст завтра проверю, оч интересная мысль!!!, учитывая что чуть больше месяца назад было замечено что базы разбежались на двух процах, на стендбае была примерно 2х недельной давности...


не совсем понял где это искать, если не затруднит подскажите (предположительно где то в апликейшенах? )



по итогам завтра отпишусь. благодарствую за наводки.

Vlad 46, этот инцидент не то что бы мешает...его и отфильтровать можно при желании что бы не засорял логи, переживаю что потом что  нибудь отвалится и придётся срочно ехать посреди ночи колдовать....
спасибо что подтвердил мои догадки насчёт сети, буду трясти сетевиков

доброго всем дня!!
после выхода из отпуска стал постоянно валиться инцидент такого вида
02/07/13 08:33:41 000002M|--/--/-/---|=0:2678=IPC IPC SEND err: appli CMISE
err -7 fd 0 ord 12 dest. ?Incid2Trap:xa000002

станция кристалл, 2 проца, R7.1,
в incinfo как всегда всё предельно непонятно )))

примерно раз в минуту появляется, иногда совпадал с отказом ABC-F по IP, но не всех линков а единичных соединений, линки практически сразу же поднимаются ...

подскажите с чем может быть связано такое поведение станции?

PS: в сети 14 станций, ещё на одной станции в сети(R7.1 MG) тоже иногда такой появляется, но намного реже...

не получится просто так заменить линух, не трогая телефонную зачачу... скомпилить всё вместе не получится, т к нужно знать все связи ядра и специфических пакетов и модулей отвечающих за телефонию...

поставьте на неактивную партицию стандартным ПС инсталером(для надёги   ), а с существующей попробуйте подсунуть каталоги, боюсь только перекомпилировать ядро палюбому придётся....

из под рута рпм пакет попробуйте обновить, как в любом линухе, хотя целесообразность сего действа мне тоже понятна.

можно из под рута сам демон перегрузить...если остановка телефонии критична и знаний по никсам достаточно

Vlad 46, спасибо огромное за ответ, тоже уже поменял значение на 300D , пока вроде ошибок нет...

ПС: иногда просят сделать хитрый отчёт по прошлому году или конкретному месяцу за какой либо год, есть прога самописная которая паралельно сливает тикеты в сиквельную базу, но там нет фильтров как 4760, только по вн номеру... а в 4760 мне очень нравится гибкость репортов(особенно когда получается их создавать), да ещё и даграммы всякие лепить умеет что б самому не заморачиваться

ещё раз благодарю..

смотря куда устанавливал? в корне на С или D нету папки 4760?
помимо 4760, должны быть ещё SQL тулзы
посмотри службы которые запустились, должно быть около 15ти  nmc***  2 Sun и ORBacus..

коллеги, подскажите хоть предельно допустимые значения в Clean-Up Delay, и обязательно ли указывать литеру D ?

смотрели список конфликтующих софтов в мануале 2.2 Software Compatibility? этот список не полный, часто бывает что не ставится на рабочую машину...
Java была установлена или ставилась из дистрибутива 4760?

ИМХО - проще поднять виртуалку на компе и на чистую винду ставить

Доброго времени суток.

Возникла необходимость хранить архивные тикуте бесконечно долго , ну или максимально возможное время   .
до этого, эти действия делал скрипт, который заходил в C:\4760_ARC\Accounting\tickets и копировал оттуда файлы и папки на другой сервак... в силу определённых причин скрипт ушёл в небытиё
по докам нарыл следующее
"-Each archive file is conserved for 94 days, which means that records may be kept for up to 125 days maximum (94 days maximum conservation + 31 days archiving delay). After this time, records are deleted."  

по моему это как то не правильно, зачем тереть когда места вагон...
подскажите где правильнее делать изменение Clean-Up Delay ?
1- System Directory: NMC > Name server > Servers > Server_name > Accounting (тут в поле Clean-Up Delay стоит значение 94D)

или

2- System directory: NMC > Server_name > Servers > Server_name > NMCDat aBase(тут поле Clean-Up Delay вообще пустое )

надеюсь на Вашу подсказку, а то на боевой системе метод тыка не годится...

модель не подскажите?

возможно аппарат роняли, внутри он состоит из двух плат(радио блок и мат плата на которой кнопки и экран) которые соединяются разъёмом без защёлок, сталкивался что после падения контакт в разъёме терялся, лечилось "вытащить-вставить"