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