[Info-vax] Caution: LTT ignores ALLOCATE

[Johnny Billquist]

On 2011-10-06 22.38, Rob Brown wrote:
> On Thu, 6 Oct 2011 at 21:58 +0200, Johnny Billquist wrote:
>
>> On 2011-10-06 16.55, Dale Dellutri wrote:
>>>> On Oct 5, 10:36?am, Dale Dellutri<ddelQQQl... at panQQQix.com> wrote:
>>>>> I use LTT (Library and Tape Tool) to test tape drives and
>>>>> cartridges. I just discovered that it ignores the fact that another
>>>>> processes may have exclusive access to the drive via the ALLOCATE
>>>>> command.
>>>>>
>>>>> LTT is clearly not originally written for OpenVMS, and it shows.
>>>
>>> I didn't mean to start a long thread about this. I was just surprised
>>> that LTT ignored the allocate, and wanted to warn others so that they
>>> would be cautious using LTT.
>>>
>>> I logged in as SYSTEM, allocated the drive, loaded a cartridge, and
>>> did some tape manipulations. (The cartridge was new, and will be used
>>> as a backup tape.)
>>>
>>> =====
>>> $ allocate mkd600:
>>> %DCL-I-ALLOC, _XX$MKD600: allocated
>>> $ init mkd600: DAILY4
>>> $ mou/for/noass mkd600:
>>> %MOUNT-I-MOUNTED, DAILY4 mounted on _XX$MKD600:
>>> $ dism /nounl mkd600:
>>> $ sho dev mkd600: /full
>>>
>>> Magtape XX$MKD600:, device type COMPAQ SDLT320, is online, allocated,
>>> record-
>>> oriented device, file-oriented device, available to cluster, error
>>> logging
>>> is enabled, controller supports compaction (compaction disabled), device
>>> supports fastskip (per_io).
>>>
>>> Error count 159 Operations completed 1702975163
>>> Owner process "SYSTEM" Owner UIC [SYSTEM]
>>> Owner process ID 000BF851 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL
>>> Reference count 1 Default buffer size 512
>>> Density default Format Normal-11
>>>
>>> Volume status: no-unload on dismount, beginning-of-tape, odd parity.
>>> =====
>>>
>>> Note that I didn't deallocate the drive and I didn't log out.
>>>
>>> Then I opened a second window and logged in separately again
>>> to SYSTEM, and tried some vms commands ...
>>>
>>> =====
>>> $ allocate mkd600:
>>> %SYSTEM-W-DEVALLOC, device already allocated to another user
>>> $ init /med=com mkd600: DAILY4
>>> %SYSTEM-W-DEVALLOC, device already allocated to another user
>>> =====
>>>
>>> ... and, as expected, these commands respect the fact that
>>> another process has allocated the drive. However, I then
>>> started LTT in this second login, and it ran a read/write
>>> test on the cartridge in the drive without complaint or
>>> even warning. I'm using version 4.13 of LTT (URL below
>>> is wrapped):
>>>
>>> =====
>>> http://h20000.www2.hp.com/bizsupport/TechSupport/
>>> DriverDownload.jsp?
>>> pnameOID=406731&locale=en_US&taskId=135&
>>> prodTypeId=12169&prodSeriesId=406729
>>>
>>> HP StorageWorks Library and Tape Tools (Alpha)
>>> Type: Diagnostic
>>> Version: 4.13 SR1 (14 Sep 2011)
>>> Operating System(s): OpenVMS, OpenVMS v7.3-2,
>>> OpenVMS v8.2, OpenVMS v8.3, OpenVMS v8.4
>>> File name: hp-axpvms-ltt-v0413-0-1.zipexe (12 MB)
>>> =====
>>>
>>> If you don't want to reconstruct the URL above, just
>>> google for
>>> hp openvms library tape tool
>>>
>>> The SYSTEM account has its usual privileges. And the system is:
>>>
>>> =====
>>> $ sho sys /noproc
>>> OpenVMS V8.2 on node XX 6-OCT-2011 09:15:02.24 Uptime 542 15:16:07
>>> =====
>>
>> And if you check what privileges the SYSTEM user have, you'll notice
>> that it have SHARE, which means it can assign channels to non-shared
>> devices. Ie. it can bypass the allocate status of a device.
>
> And yet it was unable to when Dale attempted to ALLOCATE or INITIALIZE.

I might be wrong. But SHARE says you can assign channels to non-shared 
devices. The ALLOCATE command is a different operation, which does its 
own checking. SHARE does not enter in to that operation.

SHARE allows you to assign to a device allocated by someone else, which 
would otherwise not be allowed. Nothing more, or so I read it.

>> This has nothing to do with the LTT, and everything to do with who you
>> are and what privileges you have.
>
> I disagree. Dale's demonstration clearly shows that when another user
> has the device allocated, user SYSTEM (which, as you pointed out, is
> fully privileged and can bypass the allocate status of a device if it
> wants to) can *not* allocate or initialize the tape for himself.
>
> If ALLOCATE and INITIALIZE respect a device allocated to another user
> but LTT does not, I do not think that you can say that it has "nothing
> to do with the LTT".

Like I said, I might be wrong. It's been a while since I did serious 
play with VMS, so parts I derivate from my knowledge of RSX, which 
sometimes works exactly the same way, but at other times can be very 
different, so it's a bit chancy of me to do that. :-)

However, I think that ALLOCATE, as mentioned above, not related to the 
SHARE privilege. INITIALIZE, I think, requires that the device is 
allocated before it allows any operations. So it would all logically 
follow that it behaves the way described.

Now, if the OP could do operations to the device when turning off all 
extra privileges, then I could believe there might be something in the 
driver, but I really think that all this is handled in the pre-driver 
common I/O initialization code.

	Johnny