Тогда защитить консоли, запретив операции по удалению сообщений. Написать докладную руководству, что деятельность некоторых программистов создаёт проблемы пользователям...
Я в своё время писал несколько приложений на REXX, использующих чтение сообщений с консоли. Одно из них было для старта и останова задач по списку. Проблем с чтением вроде бы не было. И потом, REXX использует не системную консоль, насколько помню. Я создавал особого пользователя TSO, разрешал ему использование определённых команд. И тогда используется консоль, привязанная к имени данного пользователя. Но это не та консоль, которой пользуются операторы.
Так что лучше всего защитить мастер-консоли от вмешательства. Если проблема действительно в этом, что в логе появятся сообщения защиты о попытке доступа к ресурсу.
Так что лучше всего защитить мастер-консоли от вмешательства. Если проблема действительно в этом, что в логе появятся сообщения защиты о попытке доступа к ресурсу.
Да мы свои проблемы решили - комплексом мер. А вот топик-стартеру что можно посоветовать? Либо запрещение команд (что имеет и свои плюсы, и минусы), либо экзиты. Но представить, что что-то пропало из буферов вывода само по себе, я не могу.
Что посоветовать? Если это действительно кто-то затирает (всё-таки слабо верится), то скорее всего остальные меры не помогут. Так что я бы первым делом защитил консоль. Потом.
1. Навести ревизию в сообщениях. Наверняка среди того, что вываливается на консоль есть много ненужных сообщений. Вообще, на сей счёт слышал два противоположных мнения. Одни за то, что бы всё шло на консоль. Другие - за то, что если на консоль что-то появилось, это уже проблема и её нужно решать. Т.е. в нормальной работе на консоль ничего не должно идти. Я не сторонник крайностей, но второй вариант мне ближе. На консоль должны идти только существенные сообщения: то, что требует вмешательства оператора, сообщения об ошибках или критических состояниях и подобное. Определить, что должно входить в последнюю категорию порой довольно сложно, так что сразу может и не получиться.
2. Выходы помогают обратить внимание на некоторые сообщения. Кардинально они проблему не решают. Хотя можно присваивать сообщениям руткод и по нему направлять на отдельную консоль. Это, наверное, может решить означенную проблему. У меня где-то сохранились тексты некоторых выходов. Могу поделиться. В общем-то они пишутся по шаблону, так что можно по ним наплодить.
3. В Инете где-то встречалось типа "Ask expert"... там по большим железякам эксперты дают советы. Пару раз доводилось пользоваться но это было давно. сейчас ссылку найти не могу. Но можно поискать. Есть так же форумы на Гугле.
4. Был один интересный случай... Кажется дело касалось атрибутов сообщения. Долго бились. А оказалось, что проблема в настройках дисплейной станции. Если правильно помню, там в настройках конфигурации можно выбирать разные типы дисплеев. Хотя не уверен - с тех пор уж больше десятка лет минуло. Короче, я бы напряг технорей на предмет покопаться и тщательно исследовать возможности станции в смысле настроек. Особое внимание уделить возможностям выделения памяти для дисплеев, характеристикам... Желательно - под контролем и вместе с системщиком.
Ого, весьма неплохо нагенерили, есть что читать. Каюсь, мало дал входной информации. Вот более конкретно.
Есть CУБД IMS, которая что-то там поделала, а потом оператор решил дать команду CHE FREEZE (выключить). Теперь посекундно.
Как только дали команду 06.42.40 R 29,/CHE FREEZE. 06.42.40 JOB00317 IEE600I REPLY TO 29 IS;/CHE FREEZE. 06.42.40 JOB00317 DFS058I 06:42:40 CHECKPOINT COMMAND IN PROGRESS 06.42.40 JOB00317 *31 DFS996I *IMS READY* SYS3
Далее начинается "магия". Появляется длинная прямая черта (символы "|") напротив сообщений IMS (префикс DFS): - 06.42.40 R 29,/CHE FREEZE. 06.42.40 JOB00317 IEE600I REPLY TO 29 IS;/CHE FREEZE. | 06.42.40 JOB00317 DFS058I 06:42:40 CHECKPOINT COMMAND IN PROGRESS | 06.42.40 JOB00317 *31 DFS996I *IMS READY* SYS3 | 06.42.40 JOB00317 DFS3715I DEDB AREA CLOSE PROCESS STARTED, RSN | SYS3 | 06.42.40 JOB00317 DFS3719I DEDB AREA CLOSE PROCESS COMPLETED, R | SYS3 | 06.42.42 JOB00317 DFS2731I MSDB CHECKPOINT STARTED SYS3
И все, сразу: 06.42.42 STC00318 $HASP395 DLIQCTAM ENDED 06.42.42 STC00318 $HASP150 DLIQCTAM OUTGRP=1.1.1 ON PRT1 185 ( RECORDS 06.42.42 $HASP160 PRT1 INACTIVE - CLASS=01234AZFWXY 06.42.42 STC00318 $HASP250 DLIQCTAM PURGED -- (JOB KEY WAS C81686C
Теперь если заглянуть в джоблог или syslog, то увидим, что было выкинуто полно сообщений: 06:42:40.55 ZS1BMSTR 00000210 R 29,/CHE FREEZE. 06:42:40.56 JOB00317 00000010 IEE600I REPLY TO 29 IS;/CHE FREEZE. 06:42:40.57 JOB00317 00000010 DFS058I 06:42:40 CHECKPOINT COMMAND IN PROGRESS SYS3 06:42:40.57 JOB00317 00000010 *31 DFS996I *IMS READY* SYS3 06:42:40.59 JOB00317 00000010 DFS3715I DEDB AREA CLOSE PROCESS STARTED, RSN=00 SYS3 06:42:40.59 JOB00317 00000010 DFS3719I DEDB AREA CLOSE PROCESS COMPLETED, RSN=00 SYS3 06:42:42.67 JOB00317 00000010 DFS2731I MSDB CHECKPOINT STARTED SYS3 06:42:42.67 JOB00317 00000010 DFS2719I MSDB CHECKPOINT WRITTEN TO MSDBCP2 SYS3 06:42:42.71 JOB00317 00000010 DFS994I *CHKPT 11199/064242**FREEZE* SYS3 06:42:42.71 JOB00317 00000010 DFS3499I ACTIVE DDNAMES: MODBLKSA IMSACBA FORMATA MODSTAT ID: 1 SYS3 06:42:42.72 JOB00317 00000010 DFS3804I LATEST RESTART CHKPT: 11199/064242, LATEST BUILDQ CHKPT: 11199/064108 SYS3 06:42:42.74 STC00318 00000010 DFS603I IMS DLS CLEANUP ( EOT ) COMPLETE FOR JS DLIQCTAM.DLIQCTAM. ,RC=00 06:42:42.75 STC00318 00000010 IEF352I ADDRESS SPACE UNAVAILABLE 06:42:42.75 STC00318 00000010 $HASP395 DLIQCTAM ENDED 06:42:42.75 JOB00317 00000010 DFS2731I MSDB CHECKPOINT STARTED SYS3 06:42:42.76 00000201 IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=003C. 06:42:42.78 STC00318 00000010 $HASP150 DLIQCTAM OUTGRP=1.1.1 ON PRT1 185 (185) RECORDS 06:42:42.79 JOB00317 00000010 DFS2731I MSDB CHECKPOINT STARTED SYS3 06:42:42.79 JOB00317 00000010 DFS2719I MSDB CHECKPOINT WRITTEN TO MSDBCP2 SYS3 06:42:42.80 00000010 $HASP160 PRT1 INACTIVE - CLASS=01234AZFWXYTV 06:42:42.80 JOB00317 00000010 DFS2719I MSDB CHECKPOINT WRITTEN TO MSDBCP2 SYS3 06:42:42.80 STC00318 00000010 $HASP250 DLIQCTAM PURGED -- (JOB KEY WAS C81686CE) 06:42:42.81 JOB00317 00000010 DFS994I *CHKPT 11199/064242**FREEZE* SYS3 06:42:42.81 JOB00317 00000010 DFS994I *CHKPT 11199/064242**FREEZE* SYS3 06:42:42.81 JOB00317 00000010 DFS3499I ACTIVE DDNAMES: MODBLKSA IMSACBA FORMATA MODSTAT ID: 1 06:42:42.82 JOB00317 00000010 DFS3499I ACTIVE DDNAMES: MODBLKSA IMSACBA FORMATA MODSTAT ID: 1 06:42:42.82 JOB00317 00000010 DFS3804I LATEST RESTART CHKPT: 11199/064242, LATEST BUILDQ CHKPT: 11199/064108 SYS3 06:42:42.82 JOB00317 00000010 DFS3804I LATEST RESTART CHKPT: 11199/064242, LATEST BUILDQ CHKPT: 11199/064108 SYS3 06:42:42.94 JOB00317 00000010 DFS3257I ONLINE LOG CLOSED ON DFSOLP02 SYS3 06:42:42.94 JOB00317 00000010 DFS3257I ONLINE LOG CLOSED ON DFSOLS02 SYS3 06:42:42.94 JOB00317 00000010 DFS3257I ONLINE LOG CLOSED ON DFSOLP02 SYS3 06:42:42.94 JOB00317 00000010 DFS3257I ONLINE LOG CLOSED ON DFSOLP02 SYS3 06:42:42.95 JOB00317 00000010 DFS3257I ONLINE LOG CLOSED ON DFSOLS02 SYS3 06:42:42.95 JOB00317 00000010 DFS3257I ONLINE LOG CLOSED ON DFSOLS02 SYS3 06:42:42.96 JOB00317 00000010 DFS092I IMS LOG TERMINATED SYS3 06:42:42.96 JOB00317 00000010 DFS092I IMS LOG TERMINATED SYS3 06:42:42.96 JOB00317 00000010 DFS092I IMS LOG TERMINATED SYS3 06:42:42.97 JOB00317 00000010 DFS2091I IMS TIMER SERVICE SHUTDOWN COMPLETE SYS3 06:42:42.98 JOB00317 00000010 DFS0617I RDS BUFFERS HAVE BEEN SUCCESSFULLY PURGED SYS3 06:42:43.07 JOB00317 00000010 DFS994I IMS SHUTDOWN COMPLETED SYS3 06:42:43.07 00000010 IEE400I THESE MESSAGES CANCELLED - 31.
То есть, если мне например хочется отследить сообщение DFS3257I, что логи были успешно закрыты, то только через syslog или джоблог. Если это делает человек, то не очень сложно. Но если какие-нибудь надстроенные средства автоматизации, то уже сложнее (NetView не в счет). Вот я и захотел раскопать побольше информации.
Однако, чем больше читаю ответы, доки по консоли MVS, то все больше склоняюсь, что этот эффект есть какое-то внутреннее проявление IMS механизмов.
То есть пропадают сообщения, начиная с 06:42:42.67 до 06:42:42.75 (я не стал приводить строки полностью, достаточно указания времени). А бывают ситуации когда эти сообщения выводятся? И есть ли какая связь между JOB00317 и STC00318? Что за процедура DLIQCTAM?
Из всего выше сказанного я понял, что сообщение DFS3257I то попадает, то чудесным образом не попадает на консоль?
Или оно вообще никогда не было замечено на консоли? Если так то может ему и не надо отражаться на консоли. Программисты писавшие IMS могли спроектировать вывод только в syslog.
Хотелось бы для показанных сообщений увидеть первый столбец, который отображается в sd.log, там показываются руткоды. Для этого нужно по F11 сместить экран вывода. Пример того, чего хочется увидеть: N 0140000 SYS4 11203 14:32:43.26 STC00421 00000090 EZZ0621I AUTOLOG FORCIN NI0000000 SYS4 11203 14:32:43.27 STC00421 00000290 CANCEL TN3270,A=003F NR0000000 SYS4 11203 14:32:43.29 STC00421 00000090 IEE838I TN3270
Если так то может ему и не надо отражаться на консоли. Программисты писавшие IMS могли спроектировать вывод только в syslog.
Поэтому можно попробовать повесить экзит на это сообщение, и посмотрим, что из этого выйдет... Можно так же изменить ему руткод и направить на отдельную консоль (раз уж эти сообщения так важны). И вообще, для IMS, коль на то дело пошло, можно выделить специальную консоль. И направлять все сообщения DFS* туда.
Да, частично. Сильно зависит от производительности системы. По наблюдениям если приложение сложилось быстро, то меньше сообщение попадет на консоль. Если медленно, то часть из того что попало на syslog в примере, попадет на консоль.
Quote (AlexV)
И есть ли какая связь между JOB00317 и STC00318? Что за процедура DLIQCTAM?
JOB00317 - это джоба, которая и есть IMS. STC00318 - это started task MVS. DLIQCTAM - это имя процедуры IMS, который стартует ее в определенной конфигурации. На этой системе мы запускаем IMS примерно так: S DLIQCTAM. Соответственно порождается STC, которая скорее всего вызывает IEBGENER, чей аутпут идет на JES INIRDR. Ну с ридера уже запускается батчевый джоб JOB. Такой вот замороченный способ запуска. Почему так сделали, я хз, надо долго раскуривать документацию.
Quote (akost)
а не запустило ли задание JOB00317 некую процедуру STC00318?
Скорее наоборот. Выше описание.
Quote (AlexV)
IEF352I ADDRESS SPACE UNAVAILABLE
Для данной системы это "нормальное" сообщение. Его можно игнорировать.
Quote (stas9132)
Если так то может ему и не надо отражаться на консоли. Программисты писавшие IMS могли спроектировать вывод только в syslog.
Программисты по видимому решили оставить появление или не появление этого сообщения на волю случая. В зависимости от текущей загрузки системы, ну и соответственно скорости складывания IMS. Если подробнее, то в IMS сообщения могут выводиться 3 способами: WTO, MTO, BOTH. Судя по докам, есть некая подсистема AOI (Automated Operator Interface) в IMS, который управляет этим мессенджигом. Когда IMS складывается, то она поочередно выгружает подсистемы. Дело в том, что AOI выгружается не последним, а, похоже, среди первых. Что и приводит к тому, что остальные сообщения не выдаются на консоль.
Так что это все же фишка софта, а не системы В принципе можно обойти по разному контроль появления этого сообщения. Можно в конце концов и TSO поднять с SDSF и посмотреть. Обычно, этим никто не парится, потому что необходимость выключить IMS у людей возникает раз в год, если система в продакшене. Ну а для таких редких случаев можно и в syslog посмотреть.
OB00317 - это джоба, которая и есть IMS. STC00318 - это started task MVS. DLIQCTAM - это имя процедуры IMS, который стартует ее в определенной конфигурации. На этой системе мы запускаем IMS примерно так: S DLIQCTAM. Соответственно порождается STC, которая скорее всего вызывает IEBGENER, чей аутпут идет на JES INIRDR. Ну с ридера уже запускается батчевый джоб JOB. Такой вот замороченный способ запуска.
Мысль, собсьвенно, такая. На сообщение IEF352I ADDRESS SPACE UNAVAILABLE, можно, конечно внимания не обращать. Но "головным" адресным пространством у вас, получается, является то, что порождается процедурой. Когда это AS сворачивается, оно может дезактивировавать какие-нибудь буфера, типа предназначенных для вывода сообщений. Хотя, судя по логу, сообщения идут от джоба. Но кто его знает, какова внутренняя иерархия всяких там пулов. Если AS сворачивается медленно, то в таком случае сообщения и будут успевать проскакивать на консоль (пока "головной" AS, не перекрыл пути вывода). Если сворачивание происходит быстро - пути гасятся быстро и сообщения не успевают выйти.
Это, понятное дело, только рабочая гипотеза.
Добавлено (26.07.2011, 09:44) --------------------------------------------- Кстати, сообщение IEF352I не такое уж безобидное. В параметрах системы задаётся определённое количество адресных пространств. При выдаче данного сообщения одно адресное пространство вычёткивается из списка доступных. Это может привести к тому, что при очередном старте чего-нибудь система скажет, что доступных пространств нет. За этим делом нужно следить. Кажется, MXI может показывать нужную информацию.
В принципе можно обойти по разному контроль появления этого сообщения. Можно в конце концов и TSO поднять с SDSF и посмотреть. Обычно, этим никто не парится, потому что необходимость выключить IMS у людей возникает раз в год, если система в продакшене. Ну а для таких редких случаев можно и в syslog посмотреть.