Składanie zapytań za pośrednictwem plików

Wymagania wstępne

Aby można było uruchomić partię zapytań za pośrednictwem plików, konieczne jest:

aby parametr ogólny Wykorzystanie plików wsadowych był ustawiony na Tak w parametrach serwera przetwarzania w tle.

aby parametr EXTBATCH był ustawiony na Tak. Ten parametr, należący do grupy SUP, może być definiowany na poziomie folderu i użytkownika. Możliwe jest zatem ogólne zablokowanie uruchomienia partii zapytań w ten sposób dla danego folderu, poprzez dostosowanie, jeśli to konieczne, wyjątków od określonych użytkowników.

Pliki w zapytaniu (rozszerzenie req)

Uruchomienie zapytań wsadowych może zostać przeprowadzone przez umieszczenie pliku o rozszerzeniu .job w katalogu przeznaczonym dla tych plików. Musi to być plik typu ASCII, o strukturze z wierszami zakończonymi na <CR> lub <CR><LF>, każdy wiersz określa wartość parametru w formie:

PARAMETR=WARTOŚĆ

Niektóre parametry są obowiązkowe i określają kontekstu wykonania zapytania. Inne parametry zależą od zapytań, które mają zostać uruchomione: ich nazwa odpowiada nazwie parametrów określonych na ekranie związanym z uruchomieniem zapytań. W niektórych przypadkach, tabela parametrów jest określona na ekranie; składnie jest wtedy następująca: PARAMETR(indeks)=WARTOŚĆ, indeks będący wartością numeryczną.

Aby ułatwić utworzenie takiego pliku, możliwe jest uruchomienie zapytania z programu poprzez zaznaczenie pola szablonu na ekranie uruchamiania zapytań . Po wykonaniu tych czynności, plik zawiera kompletną listę parametrów uruchomienia, a ich wartość zostanie utworzona w katalogu uruchomienia. Ten plik zostaje utworzony z nazwą zapytania oraz rozszerzeniem .mod .

W poniższej tabeli znajdują się nazwy obowiązkowych parametrów i ich definicje.

należy zauważyć, że wartości parametrów są podawane bez żadnego rozróżnienia i możliwe jest wstawienie wierszy komentarzy ze znakiem #jako prefiks. Zatem, następujące informacje mogą zostać wprowadzone w pliku zapytań:

         # Parametry obowiązkowe

         DOSSIER=DEMO (folder)

         DATA=20020614

        …

       # Parametry dodatkowe

       PARAM(1)=TEST

        PARAM(2)=ABC

Cykl przetwarzania dla plików zapytania

Serwer przetwarzania w tle sprawdza w regularnych odstępach zawartość katalogu plików zapytania. Podczas sprawdzania, odczytuje pliki obecne w katalogu umieszczając je w porządku ich klasyfikacji ASCII. Stąd, zalecanie jest stosowanie nazw plików, posiadających wspólny rdzeń i numer sekwencji o stałej długości. Mogą być nazwane, na przykład, ZAP000001.req, ZAP0000002.req

Podczas przetwarzania tego pliku, pliki są tworzone kolejno w różnych katalogach określonych parametrami serwera przetwarzania w tle. Pole te są określone poniżej:

Należy zauważyć, że istnienie pliku xxxxx.run nie musi znaczyć, iż dane zapytanie jest wykonywane. Jeżeli serwer przetwarzania w tle zatrzymał się, a trwające zapytania nie zostały przerwane, odpowiednie pliki xxxxx.run będą nadal istnieć, nawet jeśli zapytanie powinno było zakończyć ich przetwarzanie. W takim wypadku xxxxx.sta nie zostanie utworzony. Z drugiej strony, kiedy serwer przetwarzania w tle zostanie ponownie uruchomiony, plik xxxxx.run zostanie usunięty, a plik xxxxx.stazawierający specjalny status zostanie utworzony.

Liczba aktualnie przetwarzanych zapytań wsadowych może zatem być odjęta od liczby plików xxxxx.run obecnych w dedykowanym katalogu.

Opis plików XXX.sta, XXX.run, XXX.kil

Są to pliki ASCII, zakodowane w 8-bitowym systemie ASCII, obecne w różnych katalogach, zgodnie z parametrami:

• Plik .kil może być pusty lub zawierać uwagę, która zostanie pobrana do pliku o rozszerzeniu .sta
• Plik .run zawiera wiersz zgodny z poniżej zdefiniowaną strukturą, zarejestrowane informacje to: numer zapytania, data i godzina rozpoczęcia oraz kod zadania (pozostałe informacje zostaną uzupełnione wartością 0 lub spacjami)
• Plik .sta zawiera wiersz, którego format znajduje się poniżej, wszystkie pola zostają uzupełnione.

Struktura jedynego wiersza zawartego w plikach .run oraz .sta jest następująca:

• Wiersz składa się z ośmiu pól o stałej długości, z separatorami (znak dwukropka „ :”).
• Całkowita długość to od 154 do 155 znaków

Dokładna struktura jest następująca:

Pole komentarza służy do wytłumaczenia kodu błędu, jeśli jest to konieczne. Jego stała długość to 80 znaków (jeśli komunikat jest krótszy, musi zostać uzupełniony spacjami).

Numer zapytania ma 8 znaków, w razie konieczności używa się prefiksu 0. Ten number służy do identyfikacji nazwy logu wygenerowanej przy wykonywaniu zapytania. Plik nosi nazwę RQTNNNNNNNN.tra (NNNNNNNN nazwa zlecenia zawierająca 8 znaków). Jest zlokalizowany w pod-katalogu TRA folderu SERVX3. Należy zauważyć, że numer ten może mieć wartość null, w przypadku niektórych błędów, kiedy żadne zapytanie nie może zostać uruchomione.

Kod zadania odpowiada zadaniu lub uruchomionym zadaniom powiązanym, pod tą nazwą występuje w tabeli zadanie/zadania połączone.

Kod statusu, mający ponad 5 znaków numerycznych, służy do identyfikowania wykonania zapytania. Pierwsza cyfra określa ogólny wynik z wykonania, następne cyfry to dodatkowe informacje. Kiedy zapytanie zostaje zakończone bez błędów i ostrzeżeń, kod błędu jest równy 0000. Szczegóły tego kodu podane są poniżej:

Uwagi

Należy zauważyć, że w przypadku szablonów zadań przetwarzania w tle (szablon GTRAITE), dla użytkownika dostępne są następujące zmienne, dostępne w zadaniach specjalnych/niestandardowych, lub w zadaniach standardowych poprzez entry points:

• Zmienna GOK odpowiada zaktualizowanemu statusowi uruchomienia zadania. Będzie równa 1, jeśli nie wystąpią żadne problemy, 0 w przypadku problemu blokującego, -1 w przypadku innych poważnych błędów i 2 w wypadku poważnego błędu spójności w serwerze. Ta zmienna jest zarządzana przez standardowe zadania: jeśli nie jest równa 1 na końcu przetwarzania wsadowego, zadanie będzie miało status Błąd w zarządzaniu zadaniem; w przypadku, kiedy zadanie należy do grupy zadań, pozostałe zadania zostaną zablokowane i nie zostaną ponownie uruchomione.
• Zmienna GERREUR aktualizuje tylko pustą wartość w przypadku błędu podczas wykonywania instrukcji (numer błędu odpowiadający wyjątkowi przetworzonemu przez instrukcję Onerrgo). Jeżeli ta zmienna nie jest pusta na końcu zadania, status zadania zostanie ustawiony na Przerwane w zarządzaniu zadaniem, jeśli zadanie należy do grupy zadań, pozostałe zadania zostaną zablokowane.
• Zmienna GERRTRACE służy do obliczania liczby wierszy błędu w logu utworzonym przez zadanie. Jest ona zarządzana zadaniami standardowymi. Jeśli ma ona wartość pozytywną, zadanie zostanie umieszczone w zarządzaniu zadaniem jako Błąd , jednak bez blokowania trwających lub pozostałych zadań w grupie. Jest to liczba wierszy błędów, które nie są krytyczne.
• Zmienna GERRBATCH jest dodatkową zmienną numeryczną, która służy do podania kodu błędu w zależności od zadania, jeśli nie zostało ono poprawnie zakończone (nie zależy to od tego, czy wiersze logu błędu zostały wygenerowane). Jeżeli wartość GERRBATCH jest mniejsza niż 100, błąd nie jest uznawany za krytyczny. Jeśli natomiast wartość GERRBATCH jest większa lub równa 100, status zadania w funkcji zarządzania zadaniem przechodzi w Błąd na końcu wykonania, a jeśli zadanie należy do grupy, trwanie pozostałych zadań zostaje przerwane. Ta zmienna została stworzona, aby umożliwić zarządzanie specjalnymi/niestandardowymi błędami poprzez entry point..
• Zmienna GMESSBATCH jest zmienną alfanumeryczną, która służy do przedstawiania dodatkowych komunikatów o błędach. Taki komunikat staje się częścią pliku i ma rozszerzenie .sta , jeżeli wystąpi błąd.

Chyba że wystąpi błąd spójności podczas uruchamiania, standardowe zadania przetwarzania w tle w programie nigdy nie uznają błędów, które wystąpiły za krytyczne i aktualizują log powiększając GERRTRACE. Oznacza to, że jakikolwiek błąd krytyczny, który przerywa proces musi zostać przetworzony w specjalny/niestandardowy sposób, poprzez entry point, nadając zmiennej GERRBATCH wartość większą niż 100.

Opis pliku serwer.tra

Plik obecny w pod-katalogu TRA w katalogu SERVX3, zawiera log serwera. Struktura wierszy jest zgodna ze strukturą klasycznego logu (standardowe statusy nagłówka i statusy numeryczne powyżej 5 znaków). Każdy wiersz składa się z tekstu potencjalnie zawierającego prefiks numeryczny (ten numer jest poprzedzony znakiem <, jeśli jest uznawany za błąd; a znakiem =, jeśli jest ostrzeżeniem).

Istnieją następujące numery statusu (z prefiksem 4 i 5 dla spójności z poprzednimi statusami). Należy zauważyć, że statusy zaczynające się od 4, są uważane za krytyczne i nie powinny wystąpić podczas normalnej operacji (aktualizacja, zarządzanie zadaniem, problemy blokujące serwera przetwarzania w tle) i mogą być problemami systemowymi, spowodowanymi, na przykład, nieprawidłową instalacją. Statusy zaczynające się od 5 to normalne statusy aktywności serwera przetwarzania w tle:

Opis plików RQTNNNNNNNN.tra

Te pliki obecne w pod-katalogu TRA, katalogu SERVX3 zawierają log związany z samym zapytaniem. Struktura wierszy jest zgodna ze strukturą klasycznego logu (standardowe statusy nagłówka i statusy numeryczne powyżej 5 znaków). Każdy wiersz składa się z tekstu, z numerycznym prefiksem (ten numer jest poprzedzony znakiem <, jeśli jest uznawany za błąd lub ostrzeżenie). Te pliki mogą zostać odczytane bezpośrednio z zarządzania zapytaniem, poprzez kliknięcie prawym przyciskiem myszy / Log odczytu.

Po wierszu nagłówka, pierwszy wiersz w tym pliku wyświetlany jest w formie wiersza o następującym formacie (łącznie ze statusem Aktywacja zadaniaopisanym powyżej) :

51000 NNNNNNNNDD/MM/RR gg :mm :ss Aktywacja zadania (51000)

(NNNNNNNNprzedstawia numer zadania w tej sytuacji)

Klasyczne wiersze logu dla zadań następują po pierwszym wierszu (jeśli dany proces nie został uruchomiony jako grupa, te wiersze zostaną zapisane w klasycznym logu FNNNNN.tra w katalogu TRA folderu uruchomienia). Następnie, poza sytuacją, w której zadanie zostało zatrzymane (na przykład przez killadx), końcowy wiersz o identycznej strukturze zostanie znaleziony, gdzie numer odpowiada statusowi odpowiedniego zakończenia (00000) lub błędowi (1NNNN) opisanemu powyżej.

Użyte tabele

Następujące tabele są używane przez tę funkcję:

• Tabela ABATRQT
• Tabela ABATTAC
• Tabela ABATGRP