Summary
Tape mount attempts fail in middle of job with the error: status: 1138 (error mounting tape from slot to drive) . This is due to the auto cleaning setup on the tape library.
Symptoms
The job log shows the following:
X.X.X.X 7/25/2017 8:33:51 pm SNBEHT4354E 3452: Attempted to mount tape B00010 from slot 4 to drive dev000 (node <nodename> but that slot was empty?
X.X.X.X 7/25/2017 8:33:51 pm SNBEHT4355E 3452: Leaving volser B00010 marked inuse or in-mount so that it will not be reused until all active jobs are done.
X.X.X.X 7/25/2017 8:33:51 pm SNBJH_3036E *** Drive fail reported: drive dev000 on node <nodename> in job 1500966002 ***
The tape library log (ssjuker*log) might show the following:
<time stamp> SNBDRV1221D Error 0X45D: Die Anforderung konnte wegen eines E/A-Gerätefehlers nicht ausgeführt werden. / The request could not be performed because of an I/O device error.
<time stamp> SNBDRV1221D sa_ioctl_cmd: DeviceIoControl(IOCTL_SCSI_PASS_THROUGH_DIRECT) status = 1117
<time stamp> SNBDRV1224E sa_move_medium failed: 0XFFFFFFFF <time stamp> SNBJBC5946E Sense key: No sense <time stamp> SNBJBC5945E Wrong return error value, internal value (0x9)
<time stamp> SNBLOG1010D Message REQUEST STATUS sent on socket 2 <time stamp> SNBJBC1006E Message JUKER MOUNT processing failed, rc=7000
At the same time the library’s own logs display the following cleaning requests:
<time stamp> TRC/CST <84 23 01 15 > Drive Warn or Crit Tape Alert flag
<time stamp> TRC/CST <82 01 > Drive Cleaning request
Resolution
In this instance, the library is blocking the pass-through interface at the time of the cleaning requests, which in turn causes the mount error in DPX. This is associated with some types of IBM libraries, but it happens with other vendor’s products too. This is a limitation of the library itself.
A plausible workaround is to schedule regular cleaning in order to avoid cleaning requests being issued during the backup jobs.