gefira blog

Wszyscy wiedzą, że przy hurtowym tworzeniu obiektów WebSphere MQ najlepiej posługiwać się poleceniem runmqsc, raczej nikomu nie przychodzi do głowy, żeby tworzyć 300 kolejek korzystając z WebSphere MQ Explorera lub – skądinąd całkiem niezłego – support packa MO71. Co jednak zrobić gdy queue manager znajduje się w systemie z/OS? Korzystanie z paneli ISPF do utworzenia kilkuset obiektów także nie należy do ciekawych zajęć. Co prawda można zestawić połączenia proxy pomiędzy queue managerami, i np. polecenia wysyłane do queue managera na Linuksie będą forwardowane do innego queue managera uruchomionego w systemie z/OS, ale jednak wymaga to dodatkowych zabiegów administracyjnych i jest kolejną rzeczą, o której trzeba pamiętać przy konfiguracji środowisk.

Na ratunek przychodzi freeware’owy support pack MO72, udostępniający polecenie mqsc, które najłatwiej można określić jako zdalne runmqsc. Dzięki MO72 możemy wywoływać polecenia MQSC na zdalnych queue managerach, w tym także na queue managerach zainstalowanych w systemie z/OS.

Przykładowe wywołanie MO72, sprawdzające przez kanał CRM.TO.EAI.1 głębokość kolejki S/CRM.TO.EAI.1 queue managera EAI.QM.1 uruchomionego na hoście 192.168.1.79, z listenerem uruchomionym na porcie 1424  wygląda tak

C:\>mqsc -m EAI.QM.1 -l -c CRM.TO.EAI.1 -h 192.168.1.79(1424) -C “DIS QLOCAL(S/CRM.TO.EAI.1) CURDEPTH”

Powyższe polecenie zadziała jednak tylko na systemach innych niż z/OS – dla queue managerów uruchomionych na z/OS-ach wymagane jest podanie switcha -z w wywołaniu polecenia. Zakładając więc, że mamy plik “zos-objects.mqsc”, w którym znajdują się polecenia CREATE QLOCAL tworzące kilkaset obiektów, w taki oto sposób można je szybko utworzyć na z/OS-ach:

C:\>mqsc -m EAI.QM.1 -l -z -c CRM.TO.EAI.1 -h 192.168.1.79(1424) < ./zos-objects.mqsc

Prawda, że jest to wygodniejsze niż panele?

Tym razem będzie krótko i na temat. Sytuacja wydarzyła się co prawda kilka tygodni temu, ale powtórzyć się może najwcześniej za rok, i mam nadzieję, że zaoszczędzę komuś trochę czasu gdy się z tym spotka.

Jeśli w drugą niedzielę marca  – a dzień ten wyznaczył amerykański Kongres – Twoje flowy uruchomione na WebSphere Message Brokerze na mainframie z/OS nagle zaczną tworzyć timestampy przesunięte o jedną godzinę do przodu, to upewnij się, że broker korzysta ze strefy czasowej MEZ.

Okazuje się, że broker na z/OS musi różnić się od całej reszty świata i CET (Central European Time) nie jest poprawną strefą czasową dla Polski. Właściwą strefą czasową dla Polski jest MEZ (Mitteleuropäische Zeit).

CET działa prawie dobrze, czyli tworzy dobre timestampy, ale jednocześnie w drugą niedzielę marca chętnie zauważa, że w Stanach przesuwane są zegarki, więc aplikuje taką zmianę również u siebie. Przy ustawionej strefie MEZ broker zachowuje się poprawnie

Co prawda CET i MEZ powinny oczywiście oznaczać to samo, ale jakoś mnie nie dziwi, że na mainframie tak nie jest..

@fourthrealm