Хост AS400 не може отримати доступ до Data Domain VTL і скидає безперервні помилки

Команди IBMi для доступу або відображення стрічкових картриджів зазнають невдачі і призводять до помилок
скидання хостом AS400.Наслідуючи його, наведемо приклад з DSPTAPCTG, але про подібну помилку повідомляє 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 повідомляє суперечливу інформацію якомусь конкретному Read Element Status запит від AS400.
Тригером проблеми є vtl export від приводу до сховища.
Після того, як ця операція була виконана в Data Domain, або в CLI, або в графічному інтерфейсі, коли хост AS400 намагається отримати доступ до стрічкових картриджів, інформація, надана DD про експортований стрічковий картридж, є недійсною.
Якщо IBMi Read Element Status команда не запитує інформацію про штрих-код, DD VTL повідомляє про те, що накопичувач все ще завантажений.
Якщо IBMi Read Element Status команда запитує інформацію про штрих-код, DD VTL повідомляє про те, що диск порожній.

 

Суперечлива інформація, надана DD VTL, призводить до неузгодженої інвентаризації на хості AS400, і хост більше не може керувати VTL.

 

Проблему було передано до розробки Data Domain, і виправлення коду буде випущено в наступному випуску.
До пори до часу, vtl export Від приводу до сховища слід уникати.

Запропонований обхідний шлях полягає в наступному:

1. Якщо це ще не зроблено, налаштуйте CAP для всіх VTL, доступ до яких мають хости AS400.

   # vtl cap add <VTL_name> count <numer_of_CAP_slots>

2. Перевірте статус опції auto-eject для всіх налаштованих VTL.

   # vtl option show auto-eject

3. Якщо вимкнено, увімкніть опцію vtl auto-eject для всіх VTL, доступ до яких мають хости AS400

   # vtl option enable auto-eject vtl <VTL_name>

4. Використання IBMi Eject команду для переміщення стрічки з диска в CAP. Об'єкт auto-eject автоматично перемістить стрічку з CAP до Vault, емулювавши vtl export команда.

 

Якщо ви не хочете налаштовувати CAP і вмикати auto-eject Ви повинні бігти vtl export команду в 2 кроки:

1. Перемістіть стрічку з накопичувача в слот.

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

2. Експорт стрічки зі слота.

   # vtl export <VTL_name> slot <slot_number>

 

Якщо для VTL немає запущених завдань, перезапуск служби VTL може зупинити дамп хоста і дозволити AS400 знову отримати доступ до стрічкових картриджів.
Якщо виконується резервне копіювання або відновлення за допомогою протоколу VTL, після завершення завдання можна запланувати перезапуск служби VTL.

Якщо ви знаєте касетний картридж, експортований із диска, який спричинив проблему, імпорт стрічки назад на той самий диск також має тимчасово вирішити проблему без побічних ефектів на виконання завдань.