Хочу посоветоваться с экспертами в области администрирования z/OS на предмет оптимального решения следующей задачи: Передо мной стоит задача передачи информацию из логов отработки заданий z/OS 1.10 на сервер мониторинга под управлением операционной системы linux. В настоящий момент вижу только один вариант решения этой задачи создания expect скрипта на linux сервере который с помощью telnet заходит на сервер z/OS открывает нужный лог на чтение в реальном времени (как tail в linux) и вывод записывает в файл на файловой системе Linux сервера или процессу который обрабатывает этот лог. В настоящий момент этот скрипт реализована и выполняет свою задачу. Вид лога на linux сервере немного обескуражил. Как администратор UX систем привык больше к строчным записям :) Поскольку я с z/OS даже не на Вы. Хочется услышать ваше мнение по поводу правильности решения подобной задачи и возможных вариантов ее реализации с помощью других инструментов или интерфейсов взаимодействия с внешними системами которые более привычны для администраторов попсовых систем типа unix :)
Могу сказать, как я видел реализованной эту задачу на одном из центров. Там это было сделано, на мой взгляд, хорошо. 1) был сделан USEREXIT (будем называть его дальше для простоты "врезка") в JES2 штатными методами для перехвата нужных протоколов, фильтрации и сохранения на диск. Начиналось все у них с простой врезки, которая только сохраняет на диск, а потом уж добавилась фильтрация и прочее по нужным параметрам. Получился хороший строковый протокол. 2) на мейнфрейм регулярно заходит по FTP как линукс, так и остальные разные всякие системы, и выгребают протоколы по нужным заданиям, попутно подчищая ненужные протоколы. Вообще рекомендую порыться в возможностях врезки в JES, штатные системы так и работают.
В реальном времени , кто-же над вами так издевается? Втыкайте USEREXIT в JES2, из него кстати C-шный код вызвать должно получится, ну а дальше хоть к SYSLOGD по сети.
Мне кажется вполне разумное требование к АПК на базе мейнфреймов. Их же используют не как сетевые файловые помойки :) Если серьезно нужно разбирать логи в близком к реальному времени режиме для того что бы контролировать и оперативно реагировать на нештатные ситуации. Просто потому, что в z/OS не силен пытаюсь все сделать на linux сервере. С настройкой USEREXIT мне помогли, сейчас читаю про JES на предмет более правильной реализации того, что уже сделано. Еще раз спасибо, что направили в нужном направлении.
Ребята рассказывали случай, как им попал на анализ вот такой вот syslog с серьезной продакшн системы. 400 МБ за пару десятков минут. Так что вполне резонно при решении копировать лог с фрейма на другую машину опасаться за канал. Лучше использовать родные средства MVS
SNMP? Есть конечно, только он должен быть настроен и запущен как feature TCPIP. Кстати, коммерческие средства мониторинга (например СA-Unicenter) всю свою инормацию от агентов z/OS шлют на сервер мониторинга именно по SNMP.
Добрый день. Случайно наткнулся на этот сайт, и увидел твое сообщение. Не очень понял постановку задачи, тебе нужно отследить как отработало задание т.е. его код завершения или тебе нужен именно лог работы задания причем в реальном времени или лог нужен после того как задание закончилось ? В любом случае SNMP тут вряд ли поможет ведь это только транспорт а сам лог еще как-то нужно получить. Для слежения в реальном времени я вижу 2 варианта 1. exit но это надо писать на ассемблере (я например его не знаю, и мне кажется это долго и сложно ) 2. системы типа CA/OPS или NETVIEW этот вариант мне кажется проще
OPS-а у нас нет, так что остается NETVIEW с помощью таблицы автоматизации ловишь все или часть сообщений, а дальше с помощью скрипта на rexx делаешь с ними что хочешь. Хочешь по TCP отправляешь, хочешь в файл пишешь , можно, наверно, и по SNMP отправить, но я не пробовал. Все подряд сообщения ловить не советую, и систему нагрузишь, да и не нужно это, надо отфильтровывать как можно больше на начальном этапе.
Вот мое виденье решения твоей задачи. Кстати, если нужно просто код возврата какой-то задачи отслеживать, то это можно делать с помощью уже написанного в NETVIEW exit.