Determining if a shared device is busy

[Aaron Lewis_1]

I am installing a 4 drive EML series library. This will be used by a half dozen stand-alone Alpha servers as well as our Windows environment. Some of the Alphas are not on the same network, only connected to the EML through the fiber / eva. I need to make sure, at least on the Alpha side, that I am not trying to use a tape drive that is busy serving another system, either an Alpha, I can't see, or one of the windows servers. Is there a way to query the device to see if it is busy, or a way to mount it, so that othere systems see it as busy? Logicals will only work for the Alphas that share a network, and not at all for the windows side of things.

[John Gillings]

Aaron,

Short answer, no.

Longer answer:

This is not possible, even in theory. Consider this sequence

System 1: Are you free?
System 2: Are you free?
response 1: yes
response 2: yes
System 1: use device
System 2: use device

OK, so the library could have some kind of locking mechanism so it becomes:

System 1: Can I use you?
System 2: Can I use you?
Response 1: (sets lock) yes
Response 2: no
System 1: use device
System 2: waits...
System 1: (eventually?) release device

but here's the rub, what if System 1 doesn't play fair and release the device? How does System 2 know when it becomes free? What if (say) System 3 comes along and doesn't play by the rules? etc.. etc..

If the device can't, or won't do this for you, it can be implemented in software on the hosts. Such software does exist, one example is called OpenVMS Clusters ;-)

[Hoff]

Contact HP, and ask them formally. See if it exists, or if it can be added.

It appears feasible, if all the software folks involved across all the platforms were willing to modify various driver pieces. There are allocate commands within SCSI: PERSISTENT RESERVE OUT and PERSISTENT RESERVE IN.

But I'd not expect to see this implemented without the participation of the driver writers across the various platforms.

[Aaron Lewis_1]

John, it is possible, at least with the robot in the library. There is a ROBOT RESERVE command, when you issue it from one system, it blocks all others from issuing ROBOT commands, until the reserving system issues a ROBOT RELEASE command.

Hoff, Why not suggest that I need to kick myself in the head... ;)

I was hoping that this would be as easy as checking a 'status' bit on the device itself, instead of reling on the system to set it when it starts using a device.

Unless somebody comes up with something better, what I'm going to do is: set a logical when a system loads a drive, then check for the logical before unloading, if it was not loaded from this system, warn the operator, wait 30 seconds (this will force them to read the message, since there will be nothing else to do), then have them enter an override code to procede with the unload.

In a perfect world this situation will never exist, but it has to work with non-alpha systems as well, so perfect is out of the question.

[Hoff]

If you know what other boxes might be accessing the drive, use task-to-task networking and go peek in their run-time context. Link up to your task, see what's going on.

It's also possible to toss DIAGNOSE I/O commands at the device directly from OpenVMS, so there's a shot you can see if the device is busy from another platform -- the robot might well issue reservations.

(And as for your head and your headache, HP probably writes the drivers for these tape drives for all the platforms, so there is one company that might well be able to provide some sort of interlocking. And I assume HP is selling the gear for these mixed environments, so some sort of coordination is an obvious step. No headaches intended.)

[Vladimir Fabecic]

The only right way would be Dataprotector backup software.
But it is not cheap, that is the problem.
Another idea:
you can use $ ROBOT SHOW DRIVE 0
if empty, you may try to use it, i.e. load cartridge, mount etc.
If not empty or not respond, that would mean that drive is busy.
Not sure about this, but you try. Do not know how to do it on windoze, but maybe MRU for windows can do the same.
I had a simular situation: TRU64 cluster, two linux hosts and several windoze hosts should access the FC tape.
We fixed the problem using Dataprotector.
That was the only way, but very expensive.

[Aaron Lewis_1]

Hoff, I did spend about 2 hours on the phone with HP this morning(kick - ouch!), half in the VMS group, and the other half in the storage group. The VMS team agreed that it is a good idea, and would submit it to development for future consideration(kick). The storage team suggested buying a management module, secure path, I think, to control which machines could see what drives, or buy a backup package that is supported on VMS and Windows and use it to manage everything(kick, kick, kick!).


As for DIAGNOSE, I took a quick look and didn't see I/O as a parameter or qualifer. I'm running 7.3-2, is this only in 8+ or am I missing something?


Vladimir, I agree. We looked at DataProtector, but way to expensive. I am already looking for empty drives, but have no way to determine in a non-empty drive is actually being used, or somehow just had a tape left in it.

[Uwe Zessin]

>The storage team suggested buying a management module,
> secure path, I think,

No. Secure Path is a multipath filter for some operating systems.

> to control which machines could see what drives,

Ah, that is 'Secure Manager ABCXYZ'(sorry, don't recall the exact spelling), but it is not available for all library products and the feature (mapping of the robot and tape drives to hosts) is embedded for free in some SCSI/FC 'routers'.

> or buy a backup package that is supported on VMS and
> Windows and use it to manage everything(kick, kick, kick!).

That is the only 'secure' way.

> As for DIAGNOSE, I took a quick look and didn't see I/O
> as a parameter or qualifer.

I don't think that is a good idea. You might screw up active I/O operations. User see such things very often with software that polls the tape drive with 'TEST UNIT READY' commands.

> I'm running 7.3-2, is this only in 8+ or am I missing something?

IO$_DIAGNOSE is quite old, but see above.

> We looked at DataProtector, but way to expensive.

HA! Then you have not seen other backup software.

> I am already looking for empty drives,

Sorry, that is not free from race conditions. You do need ONE single arbiter: a central backup solution.

[Vladimir Fabecic]

Yes, I agree. DataProtector is too expensive.
About empty tape drive:
First I had four TRU64 machines that were using one drive. I did time calculations for jobs. Every script began with ROBOT LOAD SLOT x DRIVE 0 and ended with ROBOT HOME DRIVE 0.
So no job should have left tape in drive.
If drive was not empty, job was in progres.
So trick with asking for empty drive was usefull (OK, not too much), at least for debuging logs.
What did you expect from HP?
They allready have a product (but very expensive, kick, kick, kick!)

[Hoff · Accepted solution]

If a valid SCSI command (of the baseline SCSI "always works" command set) issued on one platform derails device activity on another platform, and multiple platforms and connections into the device are supported, then this would appear to be a device bug and certainly worth a call to the support center.

While I agree that overriding access and tossing random commands into a device is bad, having multiple platforms is just itching to have parallel access -- if the device can't tolerate this, then there must be a means provided to prevent it (as each OS has, and which is the means to prevent parallel access on one box), or the configuration must be outside that which is formally supported.

If normal activity on one platform can screw up access on another platform and multiple platforms and multiple connections into the device are supported, this is a bug.

And as for coordinating access above the level of the device drivers or outside some vendor application, the approach using locally-written daemons is to run your own reservation system, this if the underlying operating systems are unable to deal with this condition correctly.

Activities on each platform involving the library would synchronize through your software and your network of daemons.

If the device vendor does not support parallel and heterogeneous device access and it were me creating a requisite coordination mechanism -- and for ease of coding -- I'd likely message requests over to the VMS system and use the distributed lock manager (DLM) for the heavy lifting. The clients would use local calls and network connections to determine access and availability as required. That, or I'd port over one of the available portable DLMs, and run that configuration-wide. Since I can have control over what hits the drive configuration-wide during all normal operations, I can wrap the calls with device acquisition and release operations.

A local daemon-based DLM is mildly ugly approach here and certainly not as easy as this should be, but there are open-source DLMs available -- the EML should provide this for you. (It occurs that RTR might also be pressed into service as a form of DLM, but that has its own costs and requirements.)

[Aaron Lewis_1]

.