El host AS400 no puede acceder a la VTL de Data Domain y arroja errores continuos

Los comandos de IBMi para acceder o mostrar cartuchos de cinta fallan y provocan errores de volcado del host AS400.
A continuación, se muestra un ejemplo con DSPTAPCTG, pero se informa un error similar 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 informa información contradictoria a información específica Read Element Status solicitud de AS400.
El desencadenante del problema es un vtl export de la unidad al vault.
Después de que se ejecuta esta operación en Data Domain, ya sea en cli o GUI, cuando el host AS400 intenta acceder a los cartuchos de cinta, la información proporcionada por DD sobre el cartucho de cinta exportado no es válida.
Si IBMi Read Element Status el comando no solicita información de código de barras; DD VTL informa que la unidad aún está cargada.
Si IBMi Read Element Status el comando solicita información de código de barras; DD VTL informa la unidad como vacía.

 

La información en conflicto proporcionada por DD VTL provoca un inventario incoherente en el host AS400 y el host ya no puede administrar VTL.

 

El problema se escaló al departamento de ingeniería de Data Domain y se lanzará una corrección de código en una versión futura.
Por el momento, vtl export de la unidad a la vault se debe evitar.

La solución alternativa sugerida es la siguiente:

1. Si aún no lo ha hecho, configure el CAP para todos los VTL a los que acceden los hosts AS400.

   # vtl cap add <VTL_name> count <numer_of_CAP_slots>

2. Comprobar el estado de la opción auto-eject para todas las VTL configuradas.

   # vtl option show auto-eject

3. Si está deshabilitada, habilite la opción vtl auto-eject para todas las VTL a las que acceden los hosts AS400

   # vtl option enable auto-eject vtl <VTL_name>

4. Usar IBMi Eject para mover la cinta de la unidad al CAP. El menú auto-eject la opción moverá automáticamente la cinta de CAP a Vault, emulando vtl export comando.

 

Si no desea configurar cap y habilitar auto-eject debe ejecutar vtl export comando en 2 pasos:

1. Mueva la cinta de la unidad a la ranura.

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

2. Exporte la cinta desde la ranura.

   # vtl export <VTL_name> slot <slot_number>

 

Si no hay trabajos en ejecución para VTL, el reinicio del servicio de VTL puede detener el volcado del host y permitir que AS400 vuelva a acceder a los cartuchos de cinta.
En caso de que se ejecute un respaldo o una restauración mediante el protocolo de VTL, se puede programar un reinicio del servicio de VTL después de la finalización del trabajo.

Si conoce el cartucho de cinta exportado desde la unidad que desencadenó el problema, la importación de la cinta nuevamente en la misma unidad también debe corregir el problema temporalmente, sin efectos secundarios en los trabajos en ejecución.