|
GSMonitor/400
Zintegrowany system monitorujący
|
|
|
|
|
|
Prezentowana aplikacja „GSMonitor/400” przeznaczona jest
dla administratorów systemu OS/400 w przedsiębiorstwach produkcyjnych,
handlowych, i usługowych. Konstrukcja aplikacji pozwala na uzyskiwanie
informacji o aktualnych problemach w systemie OS/400 zarówno na dowolny
telefon komórkowy (najczęściej administratora systemu), jak również na
dowolną skrzynkę pocztową e-mail. GSMonitor/400 może działać na dowolnego
typu minikomputerze serii IBM AS/400. Ze względu na dużą moc obliczeniową
tego typu sprzętu oraz możliwości systemu operacyjnego, aplikacja
przewidziana jest dla firm średnich i dużych. Poza główną funkcją aplikacji GSMonitor/400, którą jest
„nasłuchiwanie” bieżących komunikatów pojawiających się w systemie i
przesyłanie ich pod zdefiniowany adres (telefon komórkowy, skrzynka e-mail),
przedstawiany program w dużym stopniu ułatwia pracę administratorowi AS/400
poprzez wbudowaną własną bazę danych umożliwiającą zdefiniowanie
automatycznej reakcji programu na ewentualny problem jaki pojawił się w systemie
OS/400. Aplikacja „GSMonitor/400” pozwala na zdefiniowanie dowolnej liczby
adresatów otrzymywanych komunikatów z wewnętrznej bazy danych. Założeniem projektowym prezentowanej aplikacji było, aby
program posiadał możliwość definiowania w jej bazie danych własnych dowolnych
(możliwych) reakcji programu na dowolne (odnotowane wpisem komunikatu w
„logach”) zdarzenie jakie wystąpiło w systemie. Najlepszym przykładem może
być tutaj sytuacja krytycznej wolnej przestrzeni dyskowej. System informuje o
tym administratora wysyłając wiadomość tekstową na jego telefon komórkowy
oraz może informować dowolną ilość innych adresatów. Oprócz tego aplikacja
GSMonitor/400 sama wykonuje zdefiniowaną przez administratora w wewnętrznej
bazie reakcję, np. przeładowanie systemu OS/400, skopiowanie określonych
bibliotek do innego systemu, lub wyłączenie serwera. Prosty interfejs wewnętrznej bazy danych oraz
zdefiniowane podpowiedzi dla poszczególnych pól pozwalają na ograniczenie
pracochłonności oraz zminimalizowanie ryzyka pomyłek w trakcie wprowadzania
danych. Dodatkiem do programu jest pisany właśnie interfejs
(CGI), umożliwiający operacje na bazie danych programu za pośrednictwem
przeglądarki internetowej i uruchomionego na AS/400 serwera HTTP. Takie
rozwiązanie w ogóle wyklucza potrzebę korzystania z Client Access 400. W trakcie opracowywania jest kolejna część programu
umożliwiająca wysyłanie sterowań do serwera AS/400 z telefonu komórkowego
(GSM) za pomocą wiadomości SMS. Zagadnieniem podejmowanym obecnie jest sposób
bezpiecznego wpisania się do systemu OS/400 podczas wysyłania sterowania
poprzez SMS, a jednym z możliwych rozwiązań przy braku możliwości szyfrowania
SMSów - system „jednorazowego hasła”.
2. Obsługa aplikacji „GSMonitor/400”. 2.1. Konfiguracja. Program GSMonitor/400 należy przed pierwszym
uruchomieniem skonfigurować w celu prawidłowej pracy. Służy do tego zbiór
konfiguracyjny CONFIGFILE zarządzany programem o nazwie CONFIG, uruchamianym
z poziomu narzędzia dostarczanego wraz z systemem OS/400 o nazwie DATA FILE
UTILITY. Konfiguracja polega na wypełnieniu poszczególnych pól w zbiorze
CONFIGFILE, mianowicie: podania adresu IP serwera pocztowego w firmie, nazwy
domeny w jakiej znajduje się serwer pocztowy, nazwy zbioru fizycznego (PF)
stanowiącego bazę danych komunikatów i reakcji na nie, wartości domyślnej
priorytetu (tzn. tylko wiadomości o wyższym priorytecie od domyślnego będą
wysyłane do adresatów), oraz należy podać również adres domyślny
administratora systemu (telefon komórkowy lub skrzynka e-mail), pod który
będą wysyłane komunikaty. Jeśli zbiór konfiguracyjny nie zostanie wypełniony
poprawnie, to podczas próby uruchomienia programu GSMonitor/400 zwróci on
komunikat: „Proszę wypełnić pola zbioru konfiguracyjnego”. Narzędzie do zarządzania zbiorami DFU (Data File
Utility) uruchamiany jest komendą: > STRDFU .
2.2. Uruchomienie. Program „GSMonitor/400” może być uruchamiany na kilka
sposobów: a) w podsystemie QINTER (jako zadanie interaktywne)
komendą: > CALL GSMONITOR Uwagi: przy założeniu, że biblioteka GSMONITOR jest na
tzw.„libliście” (*LIBL) lub w danej chwili znajdujemy się w bibliotece
GSMONITOR. W przeciwnym wypadku
podczas wywołania programu należy w parametrach komendy CALL podać również
bibliotekę w jakiej znajduje się program. b) w podsystemie QBATCH (jako zadanie wsadowe) komendą: > SBMJOB(CALL PGM(GSMONITOR)), Uwagi: jak w podpunkcie a). c) jako nowe wejście w Menadżerze Zadań Wsadowych (Job
Scheduler), który można wywołać np. komendą WRKJOBSCDE, następnie za
pomocą opcji nr 1 - ADD dodać
nowe wejście (Entry) i w linii komend wpisać komendę: > SBMJOB(CALL PGM(GSMONITOR)), następnie w pozostałych parametrach
zdefiniować czas, w którym program ma zostać uruchomiony np. codziennie rano od
poniedziałku do piątku o godzinie 6:00. Uruchomienie aplikacji interaktywnie wiąże się z tym, iż
po zakończeniu pracy z sesją – zadaniem (w podsystemie QINTER), w obrębie
którego zadanie GSMONITOR/400 zostało uruchomione - zakończona zostaje również praca aplikacji
GSMonitor/400. Uruchomienie programu jako zadanie wsadowe (w
podsystemie QBATCH) pozbawione jest powyższej wady, jednakże po przeładowaniu
systemu np. w nocy, trzeba program uruchamiać ponownie. Ostatni sposób jest pozbawiony obu powyższych wad. Jest
najlepszą metodą do ciągłego monitorowania pracy serwera AS/400 za pomocą
GSMonitor/400.
2.3. Praca z aplikacją
GSMonitor/400. Zarówno przed, jak też po uruchomieniu programu, możliwy
jest dostęp do wewnętrznej bazy danych (zarówno czytanie jak też modyfikacja)
oraz zmiana wartości głównego priorytetu. Priorytet główny służy do tego, aby
ustalić próg od jakiego komunikaty będą wysyłane do administratora/ów. 2.3.1. Zmiana wartości głównego
priorytetu. Priorytet główny może przyjmować wartości całkowite z
przedziału (0,9). Najniższy priorytet ma wartość 0 i wtedy program
GSMonitor/400 wysyła wszystkie komunikaty do adresatów. Najwyższy priorytet
ma wartość 9 i wtedy do adresatów wysyłane są jedynie krytyczne komunikaty
alarmowe. Do zmiany tego parametru wykorzystano obiekt typu DATAAREA o nazwie
PRIOR, którego wartość jest zmieniana za pomocą komendy: > CHGDTAARA
DTAARA(PRIOR)
VALUE(tutaj_nowa_wartosc) Po
wydaniu w/w komendy i naciśnięciu klawisza ENTER program wysyła do adresatów
tylko te komunikaty zdefiniowane w jego bazie danych, których priorytet jest
większy bądź równy wartości parametru PRIOR. Przykład: GSMonitor/400 został o 6:00 rano automatycznie
uruchomiony z domyślną wartością głównego priorytetu równą 5. Administrator
przyszedł jak zwykle do pracy na 8:00 i zaraz dowiedział się, iż za godzinę
musi się udać na ważne spotkanie. Aby zarówno mieć ciągłą kontrolę nad pracą
jego serwera AS/400 jak też móc uczestniczyć w spotkaniu, postanowił
otrzymywać informacje jedynie o krytycznych sytuacjach na serwerze. Więc przy
pomocy komendy wpisanej z linii komend: > CHGDTAARA
DTAARA(PRIOR) VALUE(9) zmienił wartość głównego priorytetu na 9. Następnie po wyjściu
z sali konferencyjnej, udał się jeszcze na drugie śniadanie, i w sumie po
dwóch godzinach postanowił, że chce monitorować sytuację na serwerze na
poziomie komunikatów z priorytetem 3 i większym, więc w tym celu wydał
komendę: > CHGDTAARA
DTAARA(PRIOR) VALUE(3) Koniec przykładu.
2.3.2. Praca z bazą danych. Baza danych została zaprojektowana w taki sposób, aby umożliwić
użytkownikowi prostą i szybką modyfikację jej rekordów, lub czytelny podgląd
zasobów. Dane z bazy znajdują się w zbiorze, którego nazwa została określona
w pliku konfiguracyjnym CONFIGFILE przed uruchomieniem aplikacji
GSMonitor/400(domyślna nazwa – MSGDATA). Każdy z rekordów posiada 5 pól
umożliwiających wpisanie odpowiednich wartości. Poniżej przestawiono
przykładowy rekord z bazy. ID: CPI7E48 PRIORYTET 8 WAGA 4 KOMENTARZ Ethernet resource failed. POLECENIE *DFT Pierwsze pole
o nazwie ID (identyfikator wiadomości), umożliwia wpisanie tzw. MSGID
charakteryzującego dany komunikat w systemie OS/400. Pole jest typu znakowego
o długości 7. Drugie pole służy do nadania wartości priorytetu danemu komunikatowi,
czyli tutaj następuje decyzja o jego ważności dla administratora/ów. Pole
jest typu znakowego o długości 1 i dla poprawnej pracy programu, może
przyjmować wartości całkowite z przedziału (0,9). Trzecie pole o nazwie WAGA (polecenia) umożliwia nadanie wagi danego
rekordu w bazie o tym samym identyfikatorze wiadomości – ta sama wartość pola
ID. Kolejność wykonywania poleceń w bazie dla tego samego komunikatu można
zmieniać przestawiając rekordy właśnie poprzez zmianę wartości pola WAGA.
Pole to jest typu znakowego o długości 1, i dla poprawnej pracy programu może
posiadać wartości całkowite z przedział (0,9) oraz wartości znakowe z
przedziału (A,Z). Wartość tego pola jest unikalna tzn. może istnieć tylko
jeden rekord w bazie z daną wartością pola. Czwarte pole o nazwie KOMENTARZ służy do wpisania w bazie komentarza/opisu
jakiej sytuacji w systemie dany rekord bazy dotyczy. Pole to jest przydatne
podczas przeglądania rekordów w bazie, jest typu znakowego o długości 62. Piąte pole w rekordzie o nazwie POLECENIE służy do wpisania reakcji jaka
ma nastąpić po tym jak konkretny komunikat pojawił się w systemie OS/400 –
rekord o odpowiednich wartościach pól ID i WAGA. W polu tym można wpisywać
polecenia języka komend (CL) dla systemu OS/400. pole to jest typu znakowego
i ma długość 375. Pole to posiada domyślną wartość *DFT, która powoduje
wysłanie treści komunikatu systemowego do administratora, którego adres
podano w pliku konfiguracyjnym CONFIGFILE. Do przeglądania i modyfikowania rekordów bazy danych
służy dostarczany wraz z aplikacją GSMONITOR program o nazwie BAZA, który
jest uruchamiany z poziomu narzędzia Data File Utility (DFU). Przykład: Administrator zdecydował, iż jeśli w systemie OS/400
wystąpi komunikat CPI7E48, aplikacja GSMonitor/400 zareaguje w następujący
sposób: 1) przełączenie linii Ethernet w stan VARY OFF., 2) odczekanie 60 sekund, 3) przełączenie linii Ethernet w stan VARY ON, 4) próba wysłania komunikatu do administratora (użytkownik MARCIN),
którego adres zdefiniowano w zbiorze konfiguracyjnym CONFIGFILE (SMS lub
e-mail), 5) próba wysłania komunikatu do użytkownika ANIA na jej telefon
GSM – Ania pracuje nad projektem sieciowym, ta informacja może się jej
przydać, 6) sprawdzenie statusu linii Ethernet – jeśli załączona, próba
wysłania komunikatu „Awaria linii Ethernet usunięta” do użytkownika
MARCIN (administrator) na jego skrzynkę e-mail. Czyli
dla jednego komunikatu administrator zdecydował o wykonaniu 6 czynności (6
rekordów w bazie o tej samej wartości pola ID), w ściśle określonej
kolejności (wartość pola WAGA). Na poprzedniej stronie podano wartości pól
rekordu w bazie odpowiadającego za wykonanie 4 polecenia z w/w przykładu. Koniec przykładu.
2.4.
Ograniczenia. Internet. Program GSMonitor/400 umożliwia wysyłanie komunikatów z
systemu OS/400 na dowolną skrzynkę e-mail w sieci Internet, więc jak na razie
wymaga stałego dostępu do Internetu. Autor pracuje nad rozwiązaniem w formie
urządzenia podłączanego bezpośrednio do AS/400 (np. karta PCI), które uczyni
aplikację GSMonitor/400 niezależną od sieci kablowych. Operator GSM. Program umożliwia wysyłanie komunikatów jako SMS na telefon
komórkowy (GSM) jedynie za pośrednictwem bramki operatora sieci Plus GSM. Autor
pracuje nad możliwością korzystania z bramki dowolnego operatora sieci GSM,
choćby ze względu na różny obszar zasięgu każdej z sieci komórkowej. Pamięć dyskowa. Ilość rekordów w wewnętrznej bazie danych ograniczona jest
wielkością posiadanej pamięci dyskowej serwera. Jeden rekord zawiera 446
znaków tekstu, i zajmuje .... bajtów pamięci dyskowej. Automatyczne działania. Każdy komunikat może posiadać przypisanych w bazie 36
poleceń (automatycznych działań) – pole WAGA przyjmuje wartości od 0 do 9 (10)
oraz od A do Z (26). Autor przyjął, iż jest to wartość wystarczająca dla
użytkowników programu oraz serwera AS/400. 3. Prawa autorskie i licencja. Autorem aplikacji GSMonitor/400 jest Artur Pacut.
Zabrania się jakiegokolwiek rozpowszechniania w/w aplikacji bez zgody jej
autora. Po zamówieniu produktu GSMonitor/400, jest on
dostarczany do klienta z licencją na konkretny serwer. Produkt posiada
zabezpieczenie – uruchomienie na innym serwerze nie jest możliwe.
|
