AS400-værten kan ikke få adgang til Data Domain VTL og dumper kontinuerlige fejl

IBMi-kommandoer til at få adgang til eller vise båndkassetter mislykkes og får AS400-værten til at dumpe fejl.
Det er et eksempel med DSPTAPCTG, men lignende fejl rapporteres af 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 rapporterer modstridende oplysninger til visse specifikke Read Element Status anmodning fra AS400.
Udløseren for problemet er en vtl export fra drev til boksen.
Når denne handling er udført på Data Domain, enten i CLI eller GUI, når AS400-værten forsøger at få adgang til båndpatroner, er de oplysninger, der leveres af DD om den eksporterede båndpatron, ikke gyldige.
Hvis IBMi Read Element Status kommandoen anmoder ikke om stregkodeoplysninger. DD VTL rapporterer, at drevet stadig er indlæst.
Hvis IBMi Read Element Status kommandoen anmoder om stregkodeoplysninger, DD VTL rapporterer, at drevet er tomt.

 

Modstridende oplysninger leveret af DD VTL medfører et inkonsistent lager på AS400-værten, og værten kan ikke længere administrere VTL.

 

Problemet er blevet eskaleret til Data Domain Engineering, og en koderettelse frigives i en fremtidig udgivelse.
I øjeblikket vtl export fra drev til boksen bør undgås.

Den foreslåede løsning er som følger:

1. Hvis det ikke allerede er gjort, skal du konfigurere CAP for alle VTL'er, der tilgås af AS400-værter.

   # vtl cap add <VTL_name> count <numer_of_CAP_slots>

2. Kontroller status for indstillingen auto-eject for alle VTL'er, der er konfigureret.

   # vtl option show auto-eject

3. Hvis den er deaktiveret, skal du aktivere vtl-indstillingen auto-eject for alle VTL'er, som AS400-værter har adgang til

   # vtl option enable auto-eject vtl <VTL_name>

4. Brug IBMi Eject for at flytte båndet fra båndstationen til CAP. Ikonet auto-eject vil indstillingerne automatisk flytte tapen fra CAP til Vault og derefter vtl export Kommando.

 

Hvis du ikke vil konfigurere CAP og aktivere auto-eject du bør køre vtl export kommando i 2 trin:

1. Flyt båndstationen fra drevet til slottet.

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

2. Eksporter bånd fra slot.

   # vtl export <VTL_name> slot <slot_number>

 

Hvis der ikke er nogen kørende job for VTL, kan en genstart af VTL-tjenesten stoppe værtsdumpfil og give AS400 adgang til båndpatroner igen.
Hvis sikkerhedskopiering eller gendannelse vha. VTL-protokollen kører, kan en genstart af VTL-tjenesten planlægges efter fuldførelsen af jobbet.

Hvis du kender den båndpatron, der eksporteres fra et drev, der udløste problemet, bør import af båndet tilbage på samme drev også midlertidigt løse problemet uden nogen bivirkninger på kørende job.