Когда мы работаем из master-console в MVS, то понятно, что у нас туда вывод идет буферизованный. Соответственно, в syslog (SDSF) попадает вообще все.
В результате, при некоторых настройках консоли могут случатся интересные ситуации - программа уже отработала, а сообщения в мастер-консоль еще не попали (лежат в буфере). Тогда может произойти purge буферов консоли и в результати часть сообщений на ней мы так и не увидим. Но, повторюсь, все (даже спурженные) сообщения появятся в syslog.
Вопрос: как сделать так, чтобы все сообщения из консолького буфера таки доходили до мастер-консоли?
Или, с другой стороны, вывод в мастер-консоль был небуферизованный.
Не претендуя на знание MVS до уровня буферизации сообщений консоли, замечу следующее. Мне почему-то помнится, что purge можно сделать только на сообщения определенных маршрутных кодов (если я правильно назвал). То есть тем сообщениям, которые нужно, чтобы их точно увидели, привязываются маршрутные коды, которые нельзя удалить. Пусть меня поправят.
хм. Ну я полазил в настройках MPF, там можно какие-то сообщения перехватывать, блокируя их вывод на консоль, раскрашивать, ну и много других полезностей. Но ничего конкретного про буфер не нашел. Гугл пока тоже не отвечает.
Из WTO macro If messages with descriptor codes 1, 2, 3, or 11 also have descriptor code 7, the system deletes them automatically at task termination. Видимо это ваш случай.
Строчки из MVS Installation Exits IEAVMXIT — Installation-Specified MPF Exits You can use IEAVMXIT or an MPF exit routine to: -Modify the presentation of messages by: -Changing the text and descriptor codes of selected messages Changing the descriptor code can alter the retention of the message on a console screen and in the Action Message Retention Facility (AMRF). It can also affect the color of a message when it is displayed on a console with color capabilities.
Может я чего не так понял, но что-то не припомню, что б на мастер консоль чего не выдавалось... На мастер консоль можно явно запретить выдачу ряда сообщений разными способами. В том числе через MPF раздел или установкой выходов. Но вообще говоря, все сообщения, предназначенные для вывода, проходили всегда без проблем.
А бывало такое, что обсуждаемые сообщения (кстати, что это за сообщения?) то выводятся на консоль, то нет?
А бывало такое, что обсуждаемые сообщения (кстати, что это за сообщения?) то выводятся на консоль, то нет?
Скорее успевает выводиться разное количество сообщений в зависимости от нагрузки на железо. Вполне возможно, что где-то внутри самого приложения зашита команда пуржить буфер. Так глубоко я еще не залез.
Вообще-то если буфер и очищается - то это функция системы. В приложении такого быть не должно. Можно пошерстить документацию на предмет размера буферов консоли и попробовать из уменьшить-увеличить. Если это допустимо. Возможно, это даже в настройках дисплейной станции (предполагаю, что у вас консоли подключены в канал через станцию).
Дык это, бывает что командой пуржатся невыведенные на консоль сообщения. И количество буферов увеличивается командой. Значит, при определенной сноровке можно сделать тоже самое и из приложения.
Дык это, бывает что командой пуржатся невыведенные на консоль сообщения. И количество буферов увеличивается командой. Значит, при определенной сноровке можно сделать тоже самое и из приложения.
Теоретически можно, но сильно сомнительно. Надо бы внимательно посмотреть CONSOLxx. А в нём - INIT MLIM. Если сообщения не попадают на консоль, то это скорее всего проблемы с WTO.
да без всякой особой трудности - один мастер-ломастер в своем REXX с помощью команды CONSOLE сначала пуржил все, что было не выведено на мастер-консоль, потом выводил свои говно-сообщения. Он так, видите ли, гарантировал вывод своих запросов. В результате, если было все хорошо, то все успевало выводиться. А когда машина немного не успевала (сообщений 20-30 при лимите в 3000), то запросто смахивал информацию от других заданий. При этом в syslog все сохранялось, конечно, а операторы-дамы на самой консоли не видели.
Полагаю, что в данном случае прогу писал не ломастер. Хотя и от ломастеров можно отбиться, насколько помню, для очистки нужно иметь авторизацию соответствующую. Можно защитить консоль от грубого вмешательства в её работу, и пусть таковые мастера подстраиваются под данность...
Может быть, конечно, всяко. Но в серьёзных комплексах задач я такого не встречал, особенно если задача писалась ещё старыми программистами. В данном случае мы ничего не знаем ни о задаче, которая якобы чистит буфера... Да вообще ничего. Потому можно строить только предположения. Наиболее реальное предположение - поток сообщений настолько велик, что размера буфера не хватает. В результате часть сообщений затирается. Моё мнение, что такого потока вообще быть не должно. Какой смысл их выводить, если оператор всё-одно их не успеет прочитать. Можно подумать о том, как ограничить сей поток. Наверняка есть сообщения, которые не сильно-то и нужны (например часть сообщений MVS и JES2 дублируют друг друга). Если сообщение сильно критическое, то можно поставить Exit, который будет менять ему атрибуты и сообщение будет мигать красным или каким другим цветом. Можно сделать его не убираемым. А так же направить на отдельную консоль. И тогда независимо от нагрузки важные сообщения теряться не будут.
А если сообщение не такое уж важно - то и пусть теряется с консоли. В логе оно всё-равно будет.
Насколько я понял проблема заключается не в переполнении буфера, а в невыдаче сообщений на консоль. Одна из причин по которой это может случится заключается в: 1) Программа планирует выдачу сообщения на консоль через WTO 2) Сообщение попадает в буфер, ставится в очередь на выдачу на консоль 3) Программа завершает работу, и если "descriptor codes 1, 2, 3, or 11 also have descriptor code 7" система проводит чистку сообщений в рамках task termination routine
Как лечить, сменить комбинацию "descriptor codes": 1) За ассемблер и писать EXIT 2) На мой взгляд проще "Changing the descriptor code can alter the retention of the message on a console screen and in the Action Message Retention Facility (AMRF)"
В результате, при некоторых настройках консоли могут случатся интересные ситуации - программа уже отработала, а сообщения в мастер-консоль еще не попали (лежат в буфере). Тогда может произойти purge буферов консоли и в результати часть сообщений на ней мы так и не увидим. Но, повторюсь, все (даже спурженные) сообщения появятся в syslog.
ну вроде как по исходной постановке (в первом сообщении) ни о каком аварийном завершении нет речи, все отрабатывает штатно, и сообщения в буфере. тут кто-то буфер чистит - командной, например. как гарантировать защиту сообщений от удаления и вывод на мастер-консоль? думаю, только маршрутными кодами и юзер-экзитами. другого варианта ну никак не вижу.
Наиболее реальное предположение - поток сообщений настолько велик, что размера буфера не хватает. В результате часть сообщений затирается. Моё мнение, что такого потока вообще быть не должно.
Такого не бывает. Сообщения сами не затираются. Когда кончаются буфера, система приостанавливает работу адресных пространств, так что новые сообщения не появляются, пока для них не освободятся ресурсы. Нам так объясняли. И у меня были ситуации с нехваткой буферов - по разным причинам. И тогда стояло все, пока я не развязывал буфера. Так что единственный случай, когда сообщение не появляется на мастер-консоли - это принудительное удаление буферов. И никакой самодеятельности!
