Aktualności i artykuły

Opublikowano: 20 maja 2014
Kategoria wpisu: administracjaporadniki

Bomba z opóźnionym zapłonem

Wiele serwerów IBM obsługuje software, którego czas powstania można mierzyć aktywnym węglem C14…

A tak na poważnie to wielka zaleta maszyn AS/400, że pozwalają uruchamiać starsze aplikacje na nowym sprzęcie bez jakiegokolwiek wysiłku z naszej strony. Czasami jednak starsze aplikacje mogą przysporzyć wiele kłopotu przez ustawienia plików nie stosowane w obecnych systemach. Jednym z nich jest parametr plików bazy danych, który nie zmieniony, może spowodować przerwanie działania aplikacji i wywołać duże zamieszanie…

ACCPTHSIZBomba z opóźnionym zapłonem do której nawiązuje w tytule odnosi się do parametru Wielkość ścieżki dostępu (ACCPTHSIZ) plików bazy danych.  W starszych wersjach systemów operacyjnych OS/400 parametr ten był domyślnie ustawiany na *MAX4GB. Oznaczało to, że dopuszczalna wielkość tzw. ścieżki dostępu nie może przekraczać 4 gigabajtów pamięci. Problem pojawia się w momencie kiedy dany plik był w użyciu przez kilka lat i dopuszczalna wielkość została prawie osiągnięta. W międzyczasie serwer został zmodernizowany, a nowa wersja systemu operacyjnego zapewnia wsparcie dla znacznie większych wartości parametru. Migracja aplikacji na nowy serwer odbyła się bezproblemowo (między innymi z przytaczanych na wstępie powodów) jednak nikt nie pomyślał o tym że pliki bazodanowe aplikacji zostały przeniesione z oryginalnymi parametrami.

 W momencie kiedy ścieżka dostępu pliku osiągnie wielkość ograniczoną przez parametr zbiór przestanie dopuszczać operacje na bazie danych co oczywiście objawi się awarią aplikacji i komunikatem błędu serwera o kodzie MCH2804.

MCH2804 - Tried to go larger than storage limit for object &1

Stan ten będzie utrzymywał się do momentu aż nie zmodyfikujemy parametru ACCPTHSIZ na wyższą wartość, która obecnie wynosi 1 terabajt (*MAX1TB). Możemy to zrobić za pomocą komendy Change Physical File (CHGPF) lub Change Logical File (CHGLF), a po zmianie system niezwłocznie odbuduje indeksy (ścieżki dostępu) na „operowanym” pliku. Niestety taka odbudowa może zabrać sporo czasu, blokując nadal naszą aplikację.

Problem tak naprawdę polega na tym, że dopóki nie wykryjemy wszystkich plików bazy danych w naszym systemie zagrożonych przekroczeniem „starego” progu 4 gigabajtów i nie zmienimy ich wartości zanim będzie za późno, nie będziemy świadomi, że problem istnieje aż do awarii aplikacji.

Dlatego też następnym razem o tym jak znaleźć zagrożone pliki i zmienić ich pojemność na wyższą (1 TB).

^