etmsreec@yahoo.co.uk wrote:
> Just had an interesting one...
>
> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
> you wouldn't be allowed to mount a volume system wide if you were
> mounting it foreign as you'd only want one thread/process to be able
> to squirt data at the disk.
>
> A colleague just tried doing the two qualifiers on the same command
> and it worked. Odd in my view!
>
> Is this a bug or have I got it the wrong way round in my head?

I see no reason whatsoever to even begin to consider this a bug.

Why should you not be able to do that ?

etmsreec@yahoo.co.uk writes:

>I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
>you wouldn't be allowed to mount a volume system wide if you were
>mounting it foreign as you'd only want one thread/process to be able
>to squirt data at the disk.

>A colleague just tried doing the two qualifiers on the same command
>and it worked. Odd in my view!

>Is this a bug or have I got it the wrong way round in my head?

Interesting. I just tried that and it worked. V8.3. It definitely did not
allow both /SYSTEM and /FOREIGN before. So the question is whether this
was a deliberate change or an unintended consequence of something else (a
bug).

$ HELP MOUNT/FOREIGN even discusses using /SYSTEM, so it can't be a
bug...

Volker.

R.A.Omond wrote:
> etmsreec@yahoo.co.uk wrote:
>> Just had an interesting one...
>>
>> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
>> you wouldn't be allowed to mount a volume system wide if you were
>> mounting it foreign as you'd only want one thread/process to be able
>> to squirt data at the disk.
>>
>> A colleague just tried doing the two qualifiers on the same command
>> and it worked. Odd in my view!
>>
>> Is this a bug or have I got it the wrong way round in my head?
>
> I see no reason whatsoever to even begin to consider this a bug.
>
> Why should you not be able to do that ?

Because for a couple of decades you could not.

Arne

On 7 Nov, 22:10, Arne Vajhøj wrote:
> R.A.Omond wrote:
> > etmsr...@yahoo.co.uk wrote:
> >> Just had an interesting one...
>
> >> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
> >> you wouldn't be allowed to mount a volume system wide if you were
> >> mounting it foreign as you'd only want one thread/process to be able
> >> to squirt data at the disk.
>
> >> A colleague just tried doing the two qualifiers on the same command
> >> and it worked. *Odd in my view!
>
> >> Is this a bug or have I got it the wrong way round in my head?
>
> > I see no reason whatsoever to even begin to consider this a bug.
>
> > Why should you not be able to do that ?
>
> Because for a couple of decades you could not.
>
> Arne


It's an improvement then :-)
Allthough I wonder why.

IanMiller wrote:
> On 7 Nov, 22:10, Arne Vajhøj wrote:
>> R.A.Omond wrote:
>>> etmsr...@yahoo.co.uk wrote:
>>>> Just had an interesting one...
>>>> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
>>>> you wouldn't be allowed to mount a volume system wide if you were
>>>> mounting it foreign as you'd only want one thread/process to be able
>>>> to squirt data at the disk.
>>>> A colleague just tried doing the two qualifiers on the same command
>>>> and it worked. Odd in my view!
>>>> Is this a bug or have I got it the wrong way round in my head?
>>> I see no reason whatsoever to even begin to consider this a bug.
>>> Why should you not be able to do that ?
>> Because for a couple of decades you could not.
>
> It's an improvement then :-)
> Although I wonder why.

Oh yes, it's very much an improvement. I'd go as far to say
it's fixed an, ahem, "misfeature".

I think it *might* have something to do with official support
for Jur's LD (Logical Disk) ...

R.A.Omond wrote:
> Ian Miller wrote:
>> Arne Vajhøj wrote:
>>> R.A.Omond wrote:
>>>> etmsr...@yahoo.co.uk wrote:
>>>>> Just had an interesting one...
>>>>> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
>>>>> you wouldn't be allowed to mount a volume system wide if you were
>>>>> mounting it foreign as you'd only want one thread/process to be able
>>>>> to squirt data at the disk.
>>>>> A colleague just tried doing the two qualifiers on the same command
>>>>> and it worked. Odd in my view!
>>>>> Is this a bug or have I got it the wrong way round in my head?
>>>>
>>>> I see no reason whatsoever to even begin to consider this a bug.
>>>> Why should you not be able to do that ?
>>>
>>> Because for a couple of decades you could not.
>>
>> It's an improvement then :-)
>> Although I wonder why.
>
> Oh yes, it's very much an improvement. I'd go as far to say
> it's fixed an, ahem, "misfeature".
>
> I think it *might* have something to do with official support
> for Jur's LD (Logical Disk) ...

I'd think it does have to do with the Infoserver utility. From the
V8.3 New Features, section 6.1.2, "CREATE SERVICE":

Usage rules:

- All devices must be mounted systemwide to prevent them from being
dismounted when a process logs out.

- A device that has read/write service must be mounted /FOREIGN so
that it is not visible to OpenVMS.

- A device that has read-only service must be mounted with either the
/NOWRITE qualifier or the /FOREIGN qualifier so that no one can
change it locally.

cu,
Martin
--
One OS to rule them all | Martin Vorlaender | OpenVMS rules!
One OS to find them | work: mv@pdv-systeme.de
One OS to bring them all | http://vms.pdv-systeme.de/users/martinv/
And in the Darkness bind them.| home: martin.vorlaender@t-online.de

Question:

If I MOUNT/FOREIGN/SYSTEM a disk.

Is that ANY locking done for the disk when more than one user tries to
access it at the same time ? (I realise that file or record based
locking is not relevant in a foreign disk, but what about block or disk
based locking (aka: if use 1 opens a channel to the disk read/write,
can user 2 also do the same ?)

moroney@world.std.spaamtrap.com (Michael Moroney) writes:

>>Is this a bug or have I got it the wrong way round in my head?

>Interesting. I just tried that and it worked. V8.3. It definitely did not
>allow both /SYSTEM and /FOREIGN before. So the question is whether this
>was a deliberate change or an unintended consequence of something else (a
>bug).

I was corrected on this via email, apparently you could do
$ MOUNT/SYSTEM/FOREIGN since the '90s or maybe earlier. The oldest system
I have access to is V7.3 which allows it.

On 9 Nov, 02:54, moro...@world.std.spaamtrap.com (Michael Moroney)
wrote:
> moro...@world.std.spaamtrap.com (Michael Moroney) writes:
> >>Is this a bug or have I got it the wrong way round in my head?
> >Interesting. *I just tried that and it worked. V8.3. It definitely didnot
> >allow both /SYSTEM and /FOREIGN before. *So the question is whether this
> >was a deliberate change or an unintended consequence of something else (a
> >bug).
>
> I was corrected on this via email, apparently you could do
> $ MOUNT/SYSTEM/FOREIGN since the '90s or maybe earlier. *The oldest system
> I have access to is V7.3 which allows it.

My thinking was obviously flawed then, but my thinking was like this:
I mount a disk that I want to do an image restore to /FOREIGN and /
SYSTEM
Would the /SYSTEM cause problems to that since I could potentially
have two users doing an image restore to the same disk at the same
time.

Steve

In article <0007bc82$0$32289$c3e8da3@news.astraweb.com>, JF Mezei writes:
> Question:
>
> If I MOUNT/FOREIGN/SYSTEM a disk.
>
> Is that ANY locking done for the disk when more than one user tries to
> access it at the same time ? (I realise that file or record based
> locking is not relevant in a foreign disk, but what about block or disk
> based locking (aka: if use 1 opens a channel to the disk read/write,
> can user 2 also do the same ?)

When you say /foreign you tell VMS that it has no idea what's going
on on that disk. If the device is shareable then multiple processes
can access it, and disk devices are shareable. You can narrow this
down with mount qualifiers and device protection, but it's up to the
users to coordinate thier access.

I've never tried using an HLL's exclusive open on a shareable device
other than a Files-11 disk, where VMS enforses the access at the file
level. It would be an interesting experiment.

etmsreec@yahoo.co.uk wrote:
> On 9 Nov, 02:54, moro...@world.std.spaamtrap.com (Michael Moroney)
> wrote:
>> moro...@world.std.spaamtrap.com (Michael Moroney) writes:
>>>> Is this a bug or have I got it the wrong way round in my head?
>>> Interesting. I just tried that and it worked. V8.3. It definitely did not
>>> allow both /SYSTEM and /FOREIGN before. So the question is whether this
>>> was a deliberate change or an unintended consequence of something else (a
>>> bug).
>> I was corrected on this via email, apparently you could do
>> $ MOUNT/SYSTEM/FOREIGN since the '90s or maybe earlier. The oldest system
>> I have access to is V7.3 which allows it.
>
> My thinking was obviously flawed then, but my thinking was like this:
> I mount a disk that I want to do an image restore to /FOREIGN and
> /SYSTEM

You would *not* want to do this.

> Would the /SYSTEM cause problems to that since I could potentially
> have two users doing an image restore to the same disk at the same
> time.

Yes, it would cause problems.

Hence: you do *not* want to Mount /System a disk you want to use
privately.

Arne Vajhøj wrote:
> R.A.Omond wrote:
>> etmsreec@yahoo.co.uk wrote:
>>> Just had an interesting one...
>>>
>>> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
>>> you wouldn't be allowed to mount a volume system wide if you were
>>> mounting it foreign as you'd only want one thread/process to be able
>>> to squirt data at the disk.
>>>
>>> A colleague just tried doing the two qualifiers on the same command
>>> and it worked. Odd in my view!
>>>
>>> Is this a bug or have I got it the wrong way round in my head?
>>
>> I see no reason whatsoever to even begin to consider this a bug.
>>
>> Why should you not be able to do that ?
>
> Because for a couple of decades you could not.

I got a private email from someone more knowledgeable than
me that pointed me to clear proof that I was wrong.

It has been possible since before I started with VMS.

I remembered wrong.

Arne

On Mon, 10 Nov 2008 18:39:20 -0800, Arne Vajhøj wrote:

> Arne Vajhøj wrote:
>> R.A.Omond wrote:
>>> etmsreec@yahoo.co.uk wrote:
>>>> Just had an interesting one...
>>>>
>>>> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
>>>> you wouldn't be allowed to mount a volume system wide if you were
>>>> mounting it foreign as you'd only want one thread/process to be able
>>>> to squirt data at the disk.
>>>>
>>>> A colleague just tried doing the two qualifiers on the same command
>>>> and it worked. Odd in my view!
>>>>
>>>> Is this a bug or have I got it the wrong way round in my head?
>>>
>>> I see no reason whatsoever to even begin to consider this a bug.
>>>
>>> Why should you not be able to do that ?
>> Because for a couple of decades you could not.
>
> I got a private email from someone more knowledgeable than
> me that pointed me to clear proof that I was wrong.
-- I
>
> It has been possible since before I started with VMS.
>
> I remembered wrong.
>
> Arne
>



--
PL/I for OpenVMS
www.kednos.com

> I think it *might* have something to do with official support
> for Jur's LD (Logical Disk) ...

No, not at all. It's already possible for a long long time (as long
as I can remember :-))

Jur.

R.A.Omond wrote:
> IanMiller wrote:
>> On 7 Nov, 22:10, Arne Vajhøj wrote:
>>> R.A.Omond wrote:
>>>> etmsr...@yahoo.co.uk wrote:
>>>>> Just had an interesting one...
>>>>> I'd always taken that /SYSTEM and /FOREIGN were mutually exclusive -
>>>>> you wouldn't be allowed to mount a volume system wide if you were
>>>>> mounting it foreign as you'd only want one thread/process to be able
>>>>> to squirt data at the disk.
>>>>> A colleague just tried doing the two qualifiers on the same command
>>>>> and it worked. Odd in my view!
>>>>> Is this a bug or have I got it the wrong way round in my head?
>>>> I see no reason whatsoever to even begin to consider this a bug.
>>>> Why should you not be able to do that ?
>>> Because for a couple of decades you could not.
>>
>> It's an improvement then :-)
>> Although I wonder why.
>
> Oh yes, it's very much an improvement. I'd go as far to say
> it's fixed an, ahem, "misfeature".
>
> I think it *might* have something to do with official support
> for Jur's LD (Logical Disk) ...