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.

-- 
Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)

On Oct 5, 9:36 am, Dale Dellutri <ddelQQQl...@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.

   Define "exclusive".

      pipe show proc /priv | sear sys$input " share "

Some folks can be harder to exclude than others.

On 10/5/2011 11:05 AM, Steven Schweda wrote:
> On Oct 5, 9:36 am, Dale Dellutri<ddelQQQl...@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.
>
>     Define "exclusive".

Try the dictionary definition: "Not shared with others"
>
>        pipe show proc /priv | sear sys$input " share "
>
> Some folks can be harder to exclude than others.

On Oct 5, 12:08 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:

> >     Define "exclusive".
>
> Try the dictionary definition: "Not shared with others"

   Define "others".  _All_ others?  Normal others?

>        pipe show proc /priv | sear sys$input " share "

   As I said, ...

> Some folks can be harder to exclude than others.

   Some others are more other than other others.

On 10/5/2011 1:22 PM, Steven Schweda wrote:
> On Oct 5, 12:08 pm, "Richard B. Gilbert"<rgilber...@comcast.net>
> wrote:
>
>>>      Define "exclusive".
>>
>> Try the dictionary definition: "Not shared with others"
>
>     Define "others".  _All_ others?  Normal others?
>
>>         pipe show proc /priv | sear sys$input " share "
>
>     As I said, ...
>
>> Some folks can be harder to exclude than others.
>
>     Some others are more other than other others.

How about "ANY OTHERS"!

On 2011-10-05 16.36, Dale Dellutri 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.

Hum. Yes, as Steven asked, define "exclusive".
ALLOCATE, as such, is something I think is handled by VMS, and is not up 
to devices to care, or not care about. Not even device drivers. It's all 
handled before they get involved.

However, are these devices attached to the local machine, or are we also 
talking about something through some NAS?

	Johnny

On 2011-10-05 19.27, Richard B. Gilbert wrote:
> On 10/5/2011 1:22 PM, Steven Schweda wrote:
>> On Oct 5, 12:08 pm, "Richard B. Gilbert"<rgilber...@comcast.net>
>> wrote:
>>
>>>> Define "exclusive".
>>>
>>> Try the dictionary definition: "Not shared with others"
>>
>> Define "others". _All_ others? Normal others?
>>
>>> pipe show proc /priv | sear sys$input " share "
>>
>> As I said, ...
>>
>>> Some folks can be harder to exclude than others.
>>
>> Some others are more other than other others.
>
> How about "ANY OTHERS"!

If you have privileges allowing you to bypass exclusive access 
protections of others, and the OS gives you those rights, is that then a 
bug in the device that these "others" can get access.

I think that was the point that was trying to be made...

	Johnny

On 10/5/2011 1:57 PM, Johnny Billquist wrote:
> On 2011-10-05 19.27, Richard B. Gilbert wrote:
>> On 10/5/2011 1:22 PM, Steven Schweda wrote:
>>> On Oct 5, 12:08 pm, "Richard B. Gilbert"<rgilber...@comcast.net>
>>> wrote:
>>>
>>>>> Define "exclusive".
>>>>
>>>> Try the dictionary definition: "Not shared with others"
>>>
>>> Define "others". _All_ others? Normal others?
>>>
>>>> pipe show proc /priv | sear sys$input " share "
>>>
>>> As I said, ...
>>>
>>>> Some folks can be harder to exclude than others.
>>>
>>> Some others are more other than other others.
>>
>> How about "ANY OTHERS"!
>
> If you have privileges allowing you to bypass exclusive access
> protections of others, and the OS gives you those rights, is that then a
> bug in the device that these "others" can get access.
>
> I think that was the point that was trying to be made...
>
> Johnny

I'd much prefer that the point be made with greater clarity and earlier 
in the thread!

On 2011-10-05 23.14, Richard B. Gilbert wrote:
> On 10/5/2011 1:57 PM, Johnny Billquist wrote:
>> On 2011-10-05 19.27, Richard B. Gilbert wrote:
>>> On 10/5/2011 1:22 PM, Steven Schweda wrote:
>>>> On Oct 5, 12:08 pm, "Richard B. Gilbert"<rgilber...@comcast.net>
>>>> wrote:
>>>>
>>>>>> Define "exclusive".
>>>>>
>>>>> Try the dictionary definition: "Not shared with others"
>>>>
>>>> Define "others". _All_ others? Normal others?
>>>>
>>>>> pipe show proc /priv | sear sys$input " share "
>>>>
>>>> As I said, ...
>>>>
>>>>> Some folks can be harder to exclude than others.
>>>>
>>>> Some others are more other than other others.
>>>
>>> How about "ANY OTHERS"!
>>
>> If you have privileges allowing you to bypass exclusive access
>> protections of others, and the OS gives you those rights, is that then a
>> bug in the device that these "others" can get access.
>>
>> I think that was the point that was trying to be made...
>>
>> Johnny
>
> I'd much prefer that the point be made with greater clarity and earlier
> in the thread!

You are probably right. But I think that the original questioner was 
asking if this was the case. Not merely claiming it, since it is unknown.
That was also the reason for the "show proc /priv" command, since it 
would have told if this was the case. (Or so I think.)

	Johnny

On Oct 5, 10:36=A0am, Dale Dellutri <ddelQQQl...@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.
>
> --
> Dale Dellutri <ddelQQQl...@panQQQix.com> (lose the Q's)

Dale,

Some more details would be helpful. Including:
- URL of product description
- a full SHOW PROCESS of your process
- a listing of the account used from the SYSUAF (including all
privileges and rights)
- a SHOW DEVICE/FULL for the tape drive in question

It could be a poor port, or there could be other reasons. Without data
there cannot be a definitive diagnosis.

- Bob Gezelter, http://www.rlgsc.com

On Wed, 5 Oct 2011 16:12:29 -0700 (PDT), Bob Gezelter <gezelter@rlgsc.com> wrote:
> On Oct 5, 10:36?am, Dale Dellutri <ddelQQQl...@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.

> Dale,
> Some more details would be helpful. Including:
> - URL of product description
> - a full SHOW PROCESS of your process
> - a listing of the account used from the SYSUAF (including all
> privileges and rights)
> - a SHOW DEVICE/FULL for the tape drive in question
> It could be a poor port, or there could be other reasons. Without data
> there cannot be a definitive diagnosis.
> - Bob Gezelter, http://www.rlgsc.com

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
=====

-- 
Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)

On 2011-10-06 16.55, Dale Dellutri wrote:
> On Wed, 5 Oct 2011 16:12:29 -0700 (PDT), Bob Gezelter<gezelter@rlgsc.com>  wrote:
>> On Oct 5, 10:36?am, Dale Dellutri<ddelQQQl...@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.
>
>> Dale,
>> Some more details would be helpful. Including:
>> - URL of product description
>> - a full SHOW PROCESS of your process
>> - a listing of the account used from the SYSUAF (including all
>> privileges and rights)
>> - a SHOW DEVICE/FULL for the tape drive in question
>> It could be a poor port, or there could be other reasons. Without data
>> there cannot be a definitive diagnosis.
>> - Bob Gezelter, http://www.rlgsc.com
>
> 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.

This has nothing to do with the LTT, and everything to do with who you 
are and what privileges you have.

This was what the original questioner asked about first of all. Do the 
user have the SHARE privilege. (Asked by, by asking for the result of 
the command

pipe show proc /priv | sear sys$input " share "

So it had everything to do with who you define "others" as, since 
obviously there are "others" who have more rights than a normal user, 
and thus can bypass all the protections you can think of.
And all of this is done within VMS, and the device driver, or other code 
is not involved in it.

So, now you know a bit more about VMS. :-)

	Johnny

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...@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.

> 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".

- Rob


-- 

Rob Brown                        b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd.      (780)438-9343 (voice)
Edmonton                         (780)437-3367 (FAX)
                                  http://gmcl.com/

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...@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

In article <alpine.LFD.2.00.1110061426120.21944@libra.gmcl.internal>,
 Rob Brown <mylastname@gmcl.com> wrote:

> On Thu, 6 Oct 2011 at 21:58 +0200, Johnny Billquist wrote:
> 
> > 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".


I agree.  MOUNT, BACKUP. COPY, DIRECTORY et el follow the same rules as 
ALLOCATE and INITIALIZE here.

-- 
Paul Sture

In article <paul.nospam-CAFE0D.17103208102011@pbook.sture.ch>,
 Paul Sture <paul.nospam@sture.ch> wrote:

> In article <alpine.LFD.2.00.1110061426120.21944@libra.gmcl.internal>,
>  Rob Brown <mylastname@gmcl.com> wrote:
> 
> > On Thu, 6 Oct 2011 at 21:58 +0200, Johnny Billquist wrote:
> > 
> > > 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".
> 
> 
> I agree.  MOUNT, BACKUP. COPY, DIRECTORY et el follow the same rules as 
> ALLOCATE and INITIALIZE here.

Well, yes, except COPY and DIRECTORY depend on MOUNT providing the 
necessary environment.

-- 
Paul Sture