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).

^