Error initializing tape

[Jim Lahman_1]

All:

I am attempting to initialize a tape and I get this error:

init/media=compact $10$mka100: prdimg
%INIT-F-ABORT, abort

This occurred after I quit out of a backup procedure. What I mean is that the backup was asking for a second tape with the prompt (New, Overwrite, Quit). Realizing that I was using the incorrect tape set, I entered 'Quit' so that can use the correct tape set. I remember with previous versions of VMS, I had to reboot the computer. Is there a way to fix this problem without a reboot?

Here's the device information:

==============================

[UTL.COM]>sh dev $10$mka100:

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
$10$MKA100: (CGLHD1) Online alloc 9

sh dev $10$mka100 /full

Magtape $10$MKA100: (CGLHD1), device type COMPAQ SDT-10000, is online,
allocated, record-oriented device, file-oriented device, available to
cluster, error logging is enabled, controller supports compaction
(compaction enabled), device supports fastskip (per_io).

Error count 9 Operations completed 240039587
Owner process "PRD_JL_BMK_B" Owner UIC [SYSTEM]
Owner process ID 26659D48 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 1 Default buffer size 8192
Density DDS4 Format Normal-11
Allocation class 10

Volume status: no-unload on dismount, beginning-of-tape, odd parity.

===================================

Thanks,

Jim

[Hoff]

You should not need to reboot here, but you may have to.

Assuming the tape drive unloaded itself upon QUIT, the drive and the driver should not be wedged. (I'll assume you entered QUIT to the OPCOM message using REPLY/TO=xx QUIT or REPLY/ABORT=xx or such, since I'm guessing that this "PRD_JL_BMK_B process is probably a batch job.)

If QUIT did not work, do look for an ECO for whatever release of OpenVMS is involved here (MOUNT, BACKUP, UPDATE, FIBRE_SCSI and anything related to the MK driver would be the ECOs I'd look for), then ring up the nice folks at HP Services for help.

Also check your DCL procedure, and see if it continues its processing after the QUIT, and tries accessing the drive for the next BACKUP.

The cases I'm aware of have all cleared the device ownership correctly in all recent releases; the dangling ownership problems have largely been cleared up -- except for cases where SHARE privilege is involved, and that can really mess things up.

Assuming batch, I'd see if REPLY/PENDING showed any pending requests, and try a few REPLY/TO or REPLY/ABORT operations if so. I might well move up to deleting the process holding the drive. Then comes the shot-gun application of current ECOs and the reboot. And I'd take a look at the DCL error handling in the procedure(s) involved here.

Stephen Hoffman
HoffmanLabs