How to send a scsi log sense command?

[Tom O'Toole]

I want to write a program which sends a scsi log sense command to tape drives to see if the 'cleaning requested' bit has been set. This would allow us to get a message when it's time to clean drives. I have found doc on doing an inquiry data/mode sense, but nothing about a log sense - I don't know what IO function to call. Anybody know how to do this? THANKS!

[Robert Brooks_1 · Accepted solution]

IO$_DIAGNOSE is the "swiss army knife" to the various device drivers. For the SCSI class drivers SYS$DKDRIVER and SYS$MKDRIVER (and SYS$GKDRIVER), you'll need to understand the SCSI protocol, to the extent that you're responsible for building your own CDB, etc ...

If you ask nicely, I might be able to convince someone in VMS Engineering (or someone who otherwise has access to the sources) to return that information via $GETDVI, assuming that information is actually squirreled away somewhere in the tape device's UCB ($GETDVI cannot do any I/O as part of its item code processing).

-- Rob

[Steven Schweda]

I know nothing, but perhaps the code for
SYS$ETC:SCSI_INFO.EXE or
SYS$ETC:SCSI_MODE.EXE could be tweaked to do
this job. Strangely, I don't see anything in
SYS$EXAMPLES which looks like source for
these programs.

As for log v. mode, I know even less than
usual.

[Hoff]

You're using the raw I/O interface. Its the same for all raw commands. You're lobbing low-level SCSI commands at the device, reading and writing status information.

Here's the quick tour:

acquire phy_io privilege, and try to keep share turned off if you have it. This to avoid hijacking a device.

assign an I/O channel to the device

build a scsi command data block (cdb)

build the parameter block required by the cdb, if any

call $qio with the IO$_DIAGNOSE function, with the cdb as the argument.

Process any return status.

You may need to lob a status or TEST UNIT READY command at the device, depending on how it reacts.

The approach can be improved by allocating the device, or otherwise tapping into the locking to prevent shared access. Random commands arriving at a SCSI device can cause the device to become tangled.

I've certainly written more than my share of this stuff. There's a more detailed tour of this sort of operation here: http://64.223.189.234/node/24

GKDRIVER applies if there's no other driver for the device, but you have MKDRIVER here. So you can and should use MKDRIVER here.

If you're on V8.3, the undocumented CDDVD/INQUIRE gets a whole lot more data back from your average device. See SYS$ETC:CDDVD$TOOLS.CLD and the referenced tools for some details. (I coded that tool to work with CD and DVD devices, as well as with tapes and magnetic disks.)

There's a baseline example of lobbing raw IO$_DIAGNOSE commands at a device in the DECwindows CD Player tool; in DECW$EXAMPLES:. There are other examples of IO$_DIAGNOSE around. Also look at T10DEF in LIB.

Stephen Hoffman
HoffmanLabs LLC

[Wim Van den Wyngaert]

We're not using it but many loaders (e.g. msl5000) have the option of doing a clean without human intervention (a clean tape is used every xxx). The clean tape must be in a configured slot and it must be enabled.

Wim

[Tom O'Toole]

Thanks for all the great info. So it sounds like I can generate most any scsi command using io$_diagnose. The examples I've seen are using io$_diagnose to perform other scsi commands, so I will work from there (I also have doc on the format of the log sense command).

If VMS does have/save this info somewhere, it would be brilliant to have getdvi and/or show dev/full return this info (there are two flags: cleaning requested and cleaning required). But I think doing a log sense might be needed to get the info from the drive, although when "cleaning required" is set, the drive begins to send errors back to VMS.

If I may have the temerity to ask a couple more questions:-)

Will I need diagnose privilege in addition to phy_io?

I want to run this on both directly-attached scsi and fibre attached. Any special considerations for MG devices?

Again, much thanks, the info-sharing here is incredible.

[Hoff]

Yes, DIAGNOSE privilege is typically needed for IO$_DIAGNOSE. DIAGNOSE is a PHY_IO-class ALL-class privilege.

Special considerations? When tossing IO$_DIAGNOSE calls at devices, yes, there can be considerations. This sort of operation is device-dependent, so you'll be learning what happens for each device. Some device drivers have the API, some do not. Some devices respond to SCSI commands as expected, and some do not.

I've not tried tossing a log sense at a Fibre Channel SAN device driver, so I don't know what will happen here.

Probably my biggest concern here would involve avoiding interspersing your SCSI commands into another data stream active with the device. Some SCSI commands permit this, and some devices can get confused.

I'd not experiment on a production system.

[Tom O'Toole]

Thanks Hoff,

Fortunately I do have a test system to work with. Also fortunate - I don't need to query already active devices, so I will allocate/deallocate strictly. I think/hope there is enough of a 'grace period' between cleaning requested and cleaning required (hitting the second threshold means the device stops working and throws errors until cleaned) that I can run this prog. before each backup starts. This program can alert us to proactively clean the drive, which is operationally much easier than: in the middle of the night, recognizing the error condition as cleaning required, cleaning during a backup operation, and successfully resuming/restarting that backup.