Host AS400 nie może uzyskać dostępu do VTL domeny danych i powoduje ciągłe błędy zrzutów

Polecenia IBMi dotyczące uzyskiwania dostępu lub wyświetlania kaset taśmowych zawiodą i powodują błędy zrzutu hosta AS400.
Poniżej przedstawiono przykład z DSPTAPCTG, ale podobny błąd jest zgłaszany przez WRKTAPCTG:

 

DSPTAPCTG DEV(TAPMLB14)                                             
Dump output directed to spooled file 1, job 784780/ECCJAK/QPADEV0001
  created on system ECC on 01/13/23 14:49:44.                       
Dump output directed to spooled file 2, job 784780/ECCJAK/QPADEV0001
  created on system ECC on 01/13/23 14:49:44.                       
Ownership of object QSC1350912 in QSYS type *LIB changed.           
Ownership of object QSCAPAROQ in QSC1350912 type *OUTQ changed.     
Ownership of object QSCAPARMST in QSC1350912 type *USRSPC changed.  
Ownership of object QSCPROBLEM in QSC1350912 type *USRSPC changed.  
Ownership of object QSCASF000A in QSC1350912 type *USRSPC changed.  
Ownership of object QSCASF000D in QSC1350912 type *USRSPC changed.  
Ownership of object QSCASF001A in QSC1350912 type *USRSPC changed.  
Ownership of object QSCASF001D in QSC1350912 type *USRSPC changed.  
Save APAR Data function completed                                   
Problem information created for 2301350912.                         
Cartridge command was not successful.

 

VTL zgłasza sprzeczne informacje do niektórych konkretnych Read Element Status żądanie as400.
Wyzwalaczem problemu jest vtl export z dysku do magazynu.
Po wykonaniu tej operacji w domenie danych, w interfejsie CLI lub GUI, gdy host AS400 próbuje uzyskać dostęp do kaset taśmowych, informacje dostarczone przez DD na temat wyeksportowanego kasety taśmowej nie są prawidłowe.
Jeśli IBMi Read Element Status polecenie nie żąda informacji o kodzie kreskowym, DD VTL zgłasza, że dysk nadal jest wczytany.
Jeśli IBMi Read Element Status żądania polecenia informacje o kodzie kreskowym, DD VTL zgłasza, że dysk jest pusty.

 

Sprzeczne informacje dostarczane przez DD VTL powodują niespójne inwentaryzację na hoście AS400, a host nie może już zarządzać VTL.

 

Problem został przekazany do działu inżynieryjnego Data Domain, a poprawka kodu zostanie wydana w przyszłej wersji.
Na razie vtl export z dysku do magazynu należy unikać.

Sugerowane obejście problemu jest następujące:

1. Jeśli nie zostało to jeszcze zrobione, skonfiguruj WPR dla wszystkich VCL dostępnych przez hosty AS400.

   # vtl cap add <VTL_name> count <numer_of_CAP_slots>

2. Sprawdź stan opcji auto-eject dla wszystkich skonfigurowanych VTL.

   # vtl option show auto-eject

3. Jeśli ta opcja jest wyłączona, włącz opcję vtl auto-eject dla wszystkich VTL, do które mają dostęp hosty AS400

   # vtl option enable auto-eject vtl <VTL_name>

4. Użyj interfejsu IBMi Eject polecenie przeniesienia taśmy z napędu do cap. Klawisz auto-eject opcja automatycznie przeniesie taśmę z CAP do magazynu, emulując vtl export Polecenia.

 

Jeśli nie chcesz konfigurować nakładów inwestycyjnych i włączać auto-eject należy uruchomić vtl export polecenie w 2 krokach:

1. Przesuń taśmę z napędu do gniazda.

   # vtl tape move <VTL_name> source drive <drive_number>  destination slot <slot_number>

2. Wyeksportuj taśmę z gniazda.

   # vtl export <VTL_name> slot <slot_number>

 

Jeśli nie ma uruchomionych zadań dla VTL, ponowne uruchomienie usługi VTL może zatrzymać zrzut hosta i zezwolić as400 na ponowny dostęp do kaset taśmowych.
W przypadku uruchomienia kopii zapasowej lub przywracania przy użyciu protokołu VTL można zaplanować ponowne uruchomienie usługi VTL po zakończeniu zadania.

Jeśli wiesz, że kaseta taśmowa wyeksportowana z napędu, która spowodowała problem, zaimportowanie taśmy z powrotem do tego samego dysku powinno również tymczasowo rozwiązać problem, bez skutków ubocznych dla uruchomionych zadań.