AS400-verten får ikke tilgang til Data Domain VTL, og dumper kontinuerlige feil

IBMi-kommandoer for å få tilgang til eller vise båndkassetter mislykkes og forårsake at AS400-verten dumper feil.
Det er et eksempel med DSPTAPCTG, men lignende feil rapporteres av 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 motstridende informasjon til noen spesifikke Read Element Status forespørsel fra AS400.
Utløseren for problemet er en vtl export fra stasjon til hvelv.
Etter at denne operasjonen er utført på Data Domain, enten i CLI eller GUI, når AS400-verten prøver å få tilgang til båndkassetter, er informasjonen fra DD om den eksporterte båndkassetten ikke gyldig.
Hvis IBMi Read Element Status kommandoen ber ikke om strekkodeinformasjon. DD VTL rapporterer at stasjonen fortsatt er lastet inn.
Hvis IBMi Read Element Status kommando ber om strekkodeinformasjon, DD VTL rapporterer stasjonen som tom.

 

Motstridende informasjon fra DD VTL fører til inkonsekvent beholdning på AS400-verten, og verten kan ikke administrere VTL lenger.

 

Problemet har blitt eskalert til Data Domain Engineering, og en kodeløsning vil bli utgitt i en fremtidig utgivelse.
For øyeblikket vtl export fra stasjon til hvelv bør unngås.

Den foreslåtte løsningen er som følger:

1. Hvis dette ikke allerede er gjort, konfigurerer du CAP for alle VTL-er som er tilgjengelig for AS400-verter.

   # vtl cap add <VTL_name> count <numer_of_CAP_slots>

2. Kontroller status for alternativet auto-eject for alle VTL-er som er konfigurert.

   # vtl option show auto-eject

3. Hvis dette alternativet er deaktivert, aktiverer du vtl-alternativet auto-eject for alle VTL-er som åpnes av AS400-verter

   # vtl option enable auto-eject vtl <VTL_name>

4. Bruk IBMi Eject kommando for å flytte tapen fra stasjon til CAP. Informasjonen i auto-eject vil alternativet automatisk flytte tapen fra CAP til Vault og emulere vtl export Kommandoen.

 

Hvis du ikke ønsker å konfigurere CAP og aktivere auto-eject du bør kjøre vtl export kommando i 2 trinn:

1. Flytt tapen fra stasjon til spor.

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

2. Eksporter tape fra sporet.

   # vtl export <VTL_name> slot <slot_number>

 

Hvis det ikke er noen kjørende jobber for VTL, kan omstart av VTL-tjenesten stoppe vertsloggen og tillate AS400 å få tilgang til båndkassetter på nytt.
Hvis sikkerhetskopiering eller gjenoppretting ved hjelp av VTL-protokollen kjører, kan en omstart av VTL-tjenesten planlegges etter at jobben er fullført.

Hvis du vet at båndkassetten som ble eksportert fra stasjonen som utløste problemet, bør import av tapen tilbake i samme disk midlertidig løse problemet, uten bivirkninger på å kjøre jobber.