W jaki sposób administrator przy użyciu jednego przycisku może rozesłać informację do wszystkich użytkowników, a za pomocą drugiego sprawdzić, kto jeszcze pracuje i czy w ogóle coś robi, czy też może zasnął za biurkiem.

Wraz z powstaniem technologii klient-serwer pewnemu oddaleniu uległa kwestia kontrolowania poczynań stacji roboczych. O ile problem ten zupełnie nie istnieje przy przetwarzaniu centralnym w trybie host-terminal, gdzie aplikacja centralna zajmuje się także sterowaniem pracą terminali i w związku z tym może mieć pod kontrolą wszystko, o tyle w przetwarzaniu typu klienckiego taką spójnością informacyjną nie dysponujemy, co nie znaczy, że w pewnym stopniu nie jest to możliwe do osiągnięcia. Oczywiście zarówno w trybie centralnego, jak i klienckiego przetwarzania tego typu zabiegi wymagają opracowania stosownych procedur programowych zajmujących się monitorowaniem.

Jedynym w zasadzie mechanizmem pozwalającym na odnotowywanie poczynań rozproszonych klientów jest utworzenie wspólnego pliku gromadzącego niezbędne informacje. Organizacja pliku może być dowolna, niemniej najwygodniej, gdy jest to ten sam rodzaj bazy danych, na którym pracuje nasza aplikacja kliencka. Jeśli więc programy działają z bazą danych typu SQL, wówczas plik informacyjny powinien także być tabelą w tej bazie.

Co warto kontrolować

Bogactwo możliwości jest praktycznie ograniczone do pomysłowości autorów aplikacji oraz zapotrzebowania użytkowników. Podstawę monitorowania stanowią zazwyczaj informacje dotyczące:

• czasu rozpoczęcia pracy aplikacji na konkretnej stacji

• nazwy komputera i użytkownika aplikacji

• ostatnio wykonanego zadania w ramach programu

• pomiaru aktywności użytkownika

• aktualnie używanych zasobów.

Zbieranie informacji o tego typu zdarzeniach okazuje się niezwykle pomocne w wielu działaniach, zwłaszcza tych prowadzonych przez administratora systemu, chociaż nie tylko. Po pierwsze, na bazie gromadzonych zapisów można zbudować konsolę administracyjną (KA), stanowiącą jeden z elementów zarządzania systemem i dostępną dla operatorów uprzywilejowanych, a pozwalającą na śledzenie pracy wszystkich użytkowników systemu.

Po drugie, zgromadzone informacje o aplikacjach klienckich pozwalają na pewien rodzaj sterowania i komunikację poprzez wspólny zasób danych. Podstawowym założeniem jest to, że wszelkie informacje gromadzone w pliku sterującym TM (TM - Tabela Monitora) są zapisywane przez oprogramowanie bez ingerencji użytkowników, co wymaga umieszczenia odpowiednich procedur PM (PM - Procedura Monitorująca) w kodzie aplikacji AM (AM - Aplikacja Monitorowana).

Jak to działa, czyli algorytm w zarysie Uruchomienie programu AM na dowolnej stacji powoduje założenie dla danej stacji rekordu RMK (RMK - Rekord Monitorujący Klienta) w tabeli monitora TM. Ponieważ rekord jest powiązany z komputerem przez jego nazwę RMK(nk), gdzie nk jest unikalną nazwą komputera, dla każdej stacji będzie istniał tylko jeden rekord monitorujący, aż do czasu zakończenia pracy z aplikacją AM. Podczas pracy z programem, zależnie od poziomu monitorowania, do rekordu RMK(nk) mogą być zapisywane obecne stany dotyczące np. nazwy planszy wyświetlanej aktualnie na stacji klienckiej, czasu, od jakiego jest wyświetlana, ewentualnie inne charakterystyczne informacje. W momencie kończenia pracy z programem AM, jako jedna z ostatnich procedur PM, jest wykonywane usunięcie rekordu RMK(nk) związanego z tym komputerem. Tak więc poprzez tabelę monitora stacja jest widziana od momentu uruchomienia programu aż do jego zakończenia. Brak informacji w tabeli TM określa jasno, że na danej stacji roboczej nie pracuje już program AM.

W rozwiązaniu tym przyjęto założenie, że istnieje jeden wpis dla jednego komputera, czyli na komputerze może być uruchomiona tylko jedna instancja aplikacji AM. Chcąc sytuację dokładniej przeanalizować, wówczas należałoby inaczej skonstruować tabelę i wpisy identyfikować np. numerami sesji, co oznaczałoby, że dany komputer miałby w TM więcej wierszy niż jeden.

Podany tu sposób ewidencji poprzez tworzenie rekordu podczas uruchamiania programu AM i jego usunięcie w chwili kończenia pracy AM działa poprawnie, jeśli nie zajdą nieoczekiwane, aczkolwiek towarzyszące czasami środowisku przetwarzania, warunki. Nieprzewidziane wyłączenie stacji roboczej, np. z powodu braku zasilania, spowoduje, że aplikacja nie będzie miała szans na usunięcie swego rekordu RMK(nk) w tabeli monitorowania, co oznacza, że pozostawi po sobie "osierocony" zapis działający dezinformująco. Aby uniknąć tego typu utrudnień, należy przewidzieć sposoby usuwania "zanieczyszczeń" informacyjnych. Po pierwsze, program AM podczas uruchamiania, zanim założy swój rekord informacyjny RMK(nk), sprawdza najpierw, czy nie pozostał w tabeli TM zapis "osierocony" z tego właśnie komputera - jeśli tak, usuwa go. Taki algorytm zdaje egzamin, jeśli po nie kontrolowanym przerwaniu pracy wznawiamy ją na tej samej stacji - pamiętajmy, że jako wyróżnik przyjęliśmy nazwę komputera. Jeśli jednak uszkodzeniu uległ komputer, powodując, że nie można go uruchomić, program nie będzie mógł usunąć własnego zapisu dotyczącego tej stacji roboczej. W związku z tym należy zastosować inne mechanizmy pozwalające na automatyczne usuwanie wpisów "osieroconych" przez inne stacje. Łatwiejsze jest wprowadzenie procedur kontrolnych działających w chwili uruchamiania aplikacji na dowolnej stacji. Otóż przy okazji sprawdzania własnych wpisów "osieroconych" każda stacja może usunąć z tabeli TM wszystkie wpisy o zbyt długiej nieaktywności. Czas ten definiuje się jako parametr i może wynosić kilka godzin lub kilka dni. Bardzo istotne jest, aby interwał czasu nieaktywności, po jakim jest usuwany "osierocony" zapis, był wystarczający - zbyt krótki spowoduje, że będą usuwane RMK stacji ciągle aktywnych (użytkownik poszedł na obiad, więc przez kilkadziesiąt minut na komputerze nie były wykonywane żadne operacje) lub będą zalegać zbyt długo, co będzie uniemożliwiało przeprowadzenie pewnych procedur opisanych dalej. Rozsądny wydaje się taki przedział czasowy, który powoduje, że nieaktywne wpisy nie są widoczne następnego dnia.