Вторник, 26.09.2017, 12:04
Приветствую Вас Гость | RSS
Главная | Консоль и syslog - Форум | Регистрация | Вход
Форма входа
Логин:
Пароль:
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 212»
Форум » Технические форумы » MVS (OS/390, zOS) » Консоль и syslog
Консоль и syslog
artДата: Среда, 13.07.2011, 17:46 | Сообщение # 1
Лейтенант
Группа: Доверенные
Сообщений: 60
Репутация: 3
Статус: Offline
Спецы MVS должны подсказать.

Когда мы работаем из master-console в MVS, то понятно, что у нас туда вывод идет буферизованный. Соответственно, в syslog (SDSF) попадает вообще все.

В результате, при некоторых настройках консоли могут случатся интересные ситуации - программа уже отработала, а сообщения в мастер-консоль еще не попали (лежат в буфере). Тогда может произойти purge буферов консоли и в результати часть сообщений на ней мы так и не увидим. Но, повторюсь, все (даже спурженные) сообщения появятся в syslog.

Вопрос: как сделать так, чтобы все сообщения из консолького буфера таки доходили до мастер-консоли?

Или, с другой стороны, вывод в мастер-консоль был небуферизованный.
 
akostДата: Среда, 13.07.2011, 21:20 | Сообщение # 2
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
Не претендуя на знание MVS до уровня буферизации сообщений консоли, замечу следующее.
Мне почему-то помнится, что purge можно сделать только на сообщения определенных маршрутных кодов (если я правильно назвал). То есть тем сообщениям, которые нужно, чтобы их точно увидели, привязываются маршрутные коды, которые нельзя удалить.
Пусть меня поправят.
 
artДата: Четверг, 14.07.2011, 12:17 | Сообщение # 3
Лейтенант
Группа: Доверенные
Сообщений: 60
Репутация: 3
Статус: Offline
хм. Ну я полазил в настройках MPF, там можно какие-то сообщения перехватывать, блокируя их вывод на консоль, раскрашивать, ну и много других полезностей. Но ничего конкретного про буфер не нашел. Гугл пока тоже не отвечает.
 
akostДата: Четверг, 14.07.2011, 18:02 | Сообщение # 4
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
вот и я тоже не нашел, как запретить буферизацию...
 
stas9132Дата: Пятница, 15.07.2011, 11:49 | Сообщение # 5
Сержант
Группа: Проверенные
Сообщений: 23
Репутация: 0
Статус: Offline
Из 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.
 
AlexVДата: Понедельник, 18.07.2011, 12:23 | Сообщение # 6
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Может я чего не так понял, но что-то не припомню, что б на мастер консоль чего не выдавалось...
На мастер консоль можно явно запретить выдачу ряда сообщений разными способами. В том числе через MPF раздел или установкой выходов.
Но вообще говоря, все сообщения, предназначенные для вывода, проходили всегда без проблем.

А бывало такое, что обсуждаемые сообщения (кстати, что это за сообщения?) то выводятся на консоль, то нет?
 
artДата: Понедельник, 18.07.2011, 15:09 | Сообщение # 7
Лейтенант
Группа: Доверенные
Сообщений: 60
Репутация: 3
Статус: Offline
Quote (AlexV)
А бывало такое, что обсуждаемые сообщения (кстати, что это за сообщения?) то выводятся на консоль, то нет?

Скорее успевает выводиться разное количество сообщений в зависимости от нагрузки на железо. Вполне возможно, что где-то внутри самого приложения зашита команда пуржить буфер. Так глубоко я еще не залез.
 
AlexVДата: Понедельник, 18.07.2011, 15:49 | Сообщение # 8
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Вообще-то если буфер и очищается - то это функция системы. В приложении такого быть не должно.
Можно пошерстить документацию на предмет размера буферов консоли и попробовать из уменьшить-увеличить. Если это допустимо. Возможно, это даже в настройках дисплейной станции (предполагаю, что у вас консоли подключены в канал через станцию).
 
akostДата: Понедельник, 18.07.2011, 17:28 | Сообщение # 9
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
Дык это, бывает что командой пуржатся невыведенные на консоль сообщения. И количество буферов увеличивается командой. Значит, при определенной сноровке можно сделать тоже самое и из приложения.
 
AlexVДата: Понедельник, 18.07.2011, 18:01 | Сообщение # 10
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Quote (akost)
Дык это, бывает что командой пуржатся невыведенные на консоль сообщения. И количество буферов увеличивается командой. Значит, при определенной сноровке можно сделать тоже самое и из приложения.


Теоретически можно, но сильно сомнительно.
Надо бы внимательно посмотреть CONSOLxx. А в нём - INIT MLIM. Если сообщения не попадают на консоль, то это скорее всего проблемы с WTO.
 
akostДата: Понедельник, 18.07.2011, 18:13 | Сообщение # 11
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
Quote (AlexV)
Теоретически можно, но сильно сомнительно.

да без всякой особой трудности - один мастер-ломастер в своем REXX с помощью команды CONSOLE сначала пуржил все, что было не выведено на мастер-консоль, потом выводил свои говно-сообщения. Он так, видите ли, гарантировал вывод своих запросов. В результате, если было все хорошо, то все успевало выводиться. А когда машина немного не успевала (сообщений 20-30 при лимите в 3000), то запросто смахивал информацию от других заданий. При этом в syslog все сохранялось, конечно, а операторы-дамы на самой консоли не видели.
 
AlexVДата: Понедельник, 18.07.2011, 18:32 | Сообщение # 12
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Полагаю, что в данном случае прогу писал не ломастер.
Хотя и от ломастеров можно отбиться, насколько помню, для очистки нужно иметь авторизацию соответствующую. Можно защитить консоль от грубого вмешательства в её работу, и пусть таковые мастера подстраиваются под данность...

Может быть, конечно, всяко. Но в серьёзных комплексах задач я такого не встречал, особенно если задача писалась ещё старыми программистами.
В данном случае мы ничего не знаем ни о задаче, которая якобы чистит буфера... Да вообще ничего. Потому можно строить только предположения.
Наиболее реальное предположение - поток сообщений настолько велик, что размера буфера не хватает. В результате часть сообщений затирается. Моё мнение, что такого потока вообще быть не должно. Какой смысл их выводить, если оператор всё-одно их не успеет прочитать. Можно подумать о том, как ограничить сей поток. Наверняка есть сообщения, которые не сильно-то и нужны (например часть сообщений MVS и JES2 дублируют друг друга).
Если сообщение сильно критическое, то можно поставить Exit, который будет менять ему атрибуты и сообщение будет мигать красным или каким другим цветом. Можно сделать его не убираемым. А так же направить на отдельную консоль. И тогда независимо от нагрузки важные сообщения теряться не будут.

А если сообщение не такое уж важно - то и пусть теряется с консоли. В логе оно всё-равно будет.
 
stas9132Дата: Понедельник, 18.07.2011, 19:46 | Сообщение # 13
Сержант
Группа: Проверенные
Сообщений: 23
Репутация: 0
Статус: Offline
Насколько я понял проблема заключается не в переполнении буфера, а в невыдаче сообщений на консоль.
Одна из причин по которой это может случится заключается в:
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)"
 
akostДата: Понедельник, 18.07.2011, 19:55 | Сообщение # 14
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
Quote (art)
В результате, при некоторых настройках консоли могут случатся интересные ситуации - программа уже отработала, а сообщения в мастер-консоль еще не попали (лежат в буфере). Тогда может произойти purge буферов консоли и в результати часть сообщений на ней мы так и не увидим. Но, повторюсь, все (даже спурженные) сообщения появятся в syslog.

ну вроде как по исходной постановке (в первом сообщении) ни о каком аварийном завершении нет речи, все отрабатывает штатно, и сообщения в буфере. тут кто-то буфер чистит - командной, например. как гарантировать защиту сообщений от удаления и вывод на мастер-консоль? думаю, только маршрутными кодами и юзер-экзитами. другого варианта ну никак не вижу.
 
akostДата: Понедельник, 18.07.2011, 22:06 | Сообщение # 15
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
Quote (AlexV)
Наиболее реальное предположение - поток сообщений настолько велик, что размера буфера не хватает. В результате часть сообщений затирается. Моё мнение, что такого потока вообще быть не должно.

Такого не бывает. Сообщения сами не затираются. Когда кончаются буфера, система приостанавливает работу адресных пространств, так что новые сообщения не появляются, пока для них не освободятся ресурсы. Нам так объясняли. И у меня были ситуации с нехваткой буферов - по разным причинам. И тогда стояло все, пока я не развязывал буфера. Так что единственный случай, когда сообщение не появляется на мастер-консоли - это принудительное удаление буферов. И никакой самодеятельности!
 
Форум » Технические форумы » MVS (OS/390, zOS) » Консоль и syslog
Страница 1 из 212»
Поиск: