/SYSTEM and /FOREIGN on a disk on the same MOUNT command - VMS

This is a discussion on /SYSTEM and /FOREIGN on a disk on the same MOUNT command - VMS ; 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 ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

  1. /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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?

    Steve

  2. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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 ?

  3. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

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

  4. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

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

    Volker.

  5. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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

  6. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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.

  7. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

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

  8. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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

  9. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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 ?)

  10. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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.

  11. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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

  12. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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.


  13. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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.

  14. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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


  15. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

    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

  16. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

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


  17. Re: /SYSTEM and /FOREIGN on a disk on the same MOUNT command

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

+ Reply to Thread