Re: Bypass mount/system request at boot time? - VMS

This is a discussion on Re: Bypass mount/system request at boot time? - VMS ; From: PR > Is there any easy way around this? Will just pulling the drive enable > it to bypass? If the device does not exist, the MOUNT should fail quickly and easily: ALP $ mount /system dkc0: fred %MOUNT-F-NOSUCHDEV, ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Re: Bypass mount/system request at boot time?

  1. Re: Bypass mount/system request at boot time?

    From: PR

    > Is there any easy way around this? Will just pulling the drive enable
    > it to bypass?


    If the device does not exist, the MOUNT should fail quickly and
    easily:

    ALP $ mount /system dkc0: fred
    %MOUNT-F-NOSUCHDEV, no such device available
    ALP $

    I'd try pulling the drive.

    ------------------------------------------------------------------------

    Steven M. Schweda sms@antinode-info
    382 South Warwick Street (+1) 651-699-9818
    Saint Paul MN 55105-2547

  2. Re: Bypass mount/system request at boot time?

    Steven M. Schweda wrote:
    > From: PR
    >
    >>Is there any easy way around this? Will just pulling the drive enable
    >>it to bypass?

    >
    >
    > If the device does not exist, the MOUNT should fail quickly and
    > easily:
    >
    > ALP $ mount /system dkc0: fred
    > %MOUNT-F-NOSUCHDEV, no such device available
    > ALP $
    >
    > I'd try pulling the drive.
    >


    .... and put a "$ set noon" at the beginning of systartup_vms.com :-)

    Otherwise, the startup will abort on the fatal "no such device error",
    and may leave the system up but inaccessible.

    I tried mounting a non-existent disk with both /assist and /noassist
    on Alpha VMS 8.3, and in both cases for the "%MOUNT-F-NOSUCHDEV"
    error, so I agree pulling the drive should make it get past this
    point, whatever the details of the mount command.

    With the disk present but unmountable, you are in this Catch-22:
    the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet
    and logins aren't enabled yet, so you can't log in to reply to the
    mount request. You should add /noassist to the mounts in
    systartup_vms.com, or stick them in a batch job that doesn't get
    executed until after logins are enabled and the rest of the system
    is up. (But you probably need the disks mounted to start the
    application, so I would go with mount/noassist. Then at least you
    can log in and fix things if a disk goes south.)

    HTH.

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  3. Re: Bypass mount/system request at boot time?

    On Oct 14, 9:26*pm, s...@antinode.info (Steven M. Schweda) wrote:
    > From: PR
    >
    > > Is there any easy way around this? Will just pulling the drive enable
    > > it to bypass?

    >
    > * *If the device does not exist, the MOUNT should fail quickly and
    > easily:
    >
    > ALP $ mount /system dkc0: fred
    > %MOUNT-F-NOSUCHDEV, no such device available
    > ALP $
    >
    > * *I'd try pulling the drive.
    >
    > ------------------------------------------------------------------------
    >
    > * *Steven M. Schweda * * * * * * * sms@antinode-info
    > * *382 South Warwick Street * * * *(+1) 651-699-9818
    > * *Saint Paul *MN *55105-2547


    Thanks guys - pulling the drive got past the issue, and allowed me to
    bring the system up remotely from the MP. I edited the
    systartup_vms.com file as suggested, and all is now - sort of well.
    The disk is reinitialized and I copied the data back onto it from the
    production volume.

    Oh, for that to make sense you would need to know that this particular
    volume is a volume I initialize and copy all the data from production
    to at 6pm each day. Then I mount the thing with /NOWRITE so it is
    available as a read-only reference during the day, and run the tape
    backups off the copied data. Cheap way to keep the data consistant. I
    just copied todays data back onto the disk.

    Amazing isn't it that someone would think that a disk mounted /NOWRITE
    must be broken and needs to be fixed under Linux?
    (*sigh*)

    Anyone that responded and wants a six-pack of their favorite brew-
    send me your address via the e-mail address above.

    Thanks!
    -Paul


    P.S. The incompetent boob who caused this problem is, I understand,
    banned from ever setting foot in the site again.

  4. Re: Bypass mount/system request at boot time?

    In article , John Santos
    writes:

    > With the disk present but unmountable, you are in this Catch-22:
    > the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet
    > and logins aren't enabled yet, so you can't log in to reply to the
    > mount request. You should add /noassist to the mounts in
    > systartup_vms.com, or stick them in a batch job that doesn't get
    > executed until after logins are enabled and the rest of the system
    > is up. (But you probably need the disks mounted to start the
    > application, so I would go with mount/noassist. Then at least you
    > can log in and fix things if a disk goes south.)


    I agree! MOUNT/NOASSIST in the startup, especially if you expect things
    to come up automatically out of the box after, say, an emergency reboot,
    power failure etc.


  5. Re: Bypass mount/system request at boot time?

    "Phillip Helbig---remove CLOTHES to reply"
    wrote in message news:gd3v58$vsg$1@online.de...
    > In article , John Santos
    > writes:
    >
    >> With the disk present but unmountable, you are in this Catch-22:
    >> the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet
    >> and logins aren't enabled yet, so you can't log in to reply to the
    >> mount request. You should add /noassist to the mounts in
    >> systartup_vms.com, or stick them in a batch job that doesn't get
    >> executed until after logins are enabled and the rest of the system
    >> is up. (But you probably need the disks mounted to start the
    >> application, so I would go with mount/noassist. Then at least you
    >> can log in and fix things if a disk goes south.)

    >
    > I agree! MOUNT/NOASSIST in the startup, especially if you expect things
    > to come up automatically out of the box after, say, an emergency reboot,
    > power failure etc.
    >


    At startup you should not need to specify /NOASSIST. This should - in
    theory - be the default.
    VMS$BASEENVIRON-050_VMS.COM sets up the symbol 'mount' and equates it to
    'mount/noassist'.
    So long as this procedure runs (and you spell 'mount' correctly) you should
    not need to use the /NOASSIST qualifier.

    Regards,

    Ed Dennison



  6. Re: Bypass mount/system request at boot time?

    In article , PR writes:
    >On Oct 14, 9:26=A0pm, s...@antinode.info (Steven M. Schweda) wrote:
    >> From: PR
    >>
    >> > Is there any easy way around this? Will just pulling the drive enable
    >> > it to bypass?

    >>
    >> =A0 =A0If the device does not exist, the MOUNT should fail quickly and
    >> easily:
    >>
    >> ALP $ mount /system dkc0: fred
    >> %MOUNT-F-NOSUCHDEV, no such device available
    >> ALP $
    >>
    >> =A0 =A0I'd try pulling the drive.
    >>
    >> ------------------------------------------------------------------------
    >>
    >> =A0 =A0Steven M. Schweda =A0 =A0 =A0 =A0 =A0 =A0 =A0 sms@antinode-info
    >> =A0 =A0382 South Warwick Street =A0 =A0 =A0 =A0(+1) 651-699-9818
    >> =A0 =A0Saint Paul =A0MN =A055105-2547

    >
    >Thanks guys - pulling the drive got past the issue, and allowed me to
    >bring the system up remotely from the MP. I edited the
    >systartup_vms.com file as suggested, and all is now - sort of well.
    >The disk is reinitialized and I copied the data back onto it from the
    >production volume.
    >
    >Oh, for that to make sense you would need to know that this particular
    >volume is a volume I initialize and copy all the data from production
    >to at 6pm each day. Then I mount the thing with /NOWRITE so it is
    >available as a read-only reference during the day, and run the tape
    >backups off the copied data. Cheap way to keep the data consistant. I
    >just copied todays data back onto the disk.
    >
    >Amazing isn't it that someone would think that a disk mounted /NOWRITE
    >must be broken and needs to be fixed under Linux?
    >(*sigh*)
    >
    >Anyone that responded and wants a six-pack of their favorite brew-
    >send me your address via the e-mail address above.
    >
    >Thanks!
    >-Paul
    >
    >
    >P.S. The incompetent boob who caused this problem is, I understand,
    >banned from ever setting foot in the site again.


    He's now a non-sultant.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  7. Re: Bypass mount/system request at boot time?

    On Oct 14, 11:51*pm, PR wrote:
    > Amazing isn't it that someone would think that a disk mounted /NOWRITE
    > must be broken and needs to be fixed under Linux?
    > (*sigh*)


    Clearly he's someone that thinks OpenVMS is a Unix/Linux variant.

  8. Re: Bypass mount/system request at boot time?

    In article , "Ed Dennison"
    writes:

    > > I agree! MOUNT/NOASSIST in the startup, especially if you expect things
    > > to come up automatically out of the box after, say, an emergency reboot,
    > > power failure etc.

    >
    > At startup you should not need to specify /NOASSIST. This should - in
    > theory - be the default.
    > VMS$BASEENVIRON-050_VMS.COM sets up the symbol 'mount' and equates it to
    > 'mount/noassist'.
    > So long as this procedure runs (and you spell 'mount' correctly) you should
    > not need to use the /NOASSIST qualifier.


    I guess the OP had a procedure which was not called from the startup
    procedure, but was submitted as a batch job, run as a detached process
    etc---otherwise he wouldn't have had the problem.


  9. Re: Bypass mount/system request at boot time?

    On Oct 15, 7:50*am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
    remove CLOTHES to reply) wrote:
    > In article , "Ed Dennison"
    >
    > writes:
    > > > I agree! *MOUNT/NOASSIST in the startup, especially if you expect things
    > > > to come up automatically out of the box after, say, an emergency reboot,
    > > > power failure etc.

    >
    > > At startup you should not need to specify /NOASSIST. This should - in
    > > theory - be the default.
    > > VMS$BASEENVIRON-050_VMS.COM sets up the symbol 'mount' and equates it to
    > > 'mount/noassist'.
    > > So long as this procedure runs (and you spell 'mount' correctly) you should
    > > not need to use the /NOASSIST qualifier.

    >
    > I guess the OP had a procedure which was not called from the startup
    > procedure, but was submitted as a batch job, run as a detached process
    > etc---otherwise he wouldn't have had the problem.


    Or abbreviated "mount": the symbol is defined so:

    $mount := mount/noassist

    with no asterisk to allow truncation.

    BTW, I *always* fully spell out DCL command verbs
    and symbols in *procedures* I write, including
    SYSTARTUP_VMS.COM, etc.. I can't tell you how
    many old procedures I encounter have things like "del"
    and "cop" in them for no apparent reason, or "say" with
    no local definition (as Write Sys$Output). I fix them if
    I have to touch them.

    -Ken

  10. Re: Bypass mount/system request at boot time?

    On Oct 15, 12:30*am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
    remove CLOTHES to reply) wrote:
    > In article , John Santos
    >
    > writes:
    > > With the disk present but unmountable, you are in this Catch-22:
    > > the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet
    > > and logins aren't enabled yet, so you can't log in to reply to the
    > > mount request. *You should add /noassist to the mounts in
    > > systartup_vms.com, or stick them in a batch job that doesn't get
    > > executed until after logins are enabled and the rest of the system
    > > is up. *(But you probably need the disks mounted to start the
    > > application, so I would go with mount/noassist. *Then at least you
    > > can log in and fix things if a disk goes south.)

    >
    > I agree! *MOUNT/NOASSIST in the startup, especially if you expect things
    > to come up automatically out of the box after, say, an emergency reboot,
    > power failure etc.


    I believe that MOUNT/NOASSIST is the default at boot time.

    -Paul


  11. Re: Bypass mount/system request at boot time?

    On Oct 15, 5:52*am, FrankS wrote:
    > On Oct 14, 11:51*pm, PR wrote:
    >
    > > Amazing isn't it that someone would think that a disk mounted /NOWRITE
    > > must be broken and needs to be fixed under Linux?
    > > (*sigh*)

    >
    > Clearly he's someone that thinks OpenVMS is a Unix/Linux variant.


    LOL! Very good assessment - very good indeed!

    -Paul


  12. Re: Bypass mount/system request at boot time?

    Ken.Fairfield@gmail.com wrote:
    > On Oct 15, 7:50 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
    > remove CLOTHES to reply) wrote:
    >
    >>In article , "Ed Dennison"
    >>
    >> writes:
    >>
    >>>>I agree! MOUNT/NOASSIST in the startup, especially if you expect things
    >>>>to come up automatically out of the box after, say, an emergency reboot,
    >>>>power failure etc.

    >>
    >>>At startup you should not need to specify /NOASSIST. This should - in
    >>>theory - be the default.
    >>>VMS$BASEENVIRON-050_VMS.COM sets up the symbol 'mount' and equates it to
    >>>'mount/noassist'.
    >>>So long as this procedure runs (and you spell 'mount' correctly) you should
    >>>not need to use the /NOASSIST qualifier.

    >>
    >>I guess the OP had a procedure which was not called from the startup
    >>procedure, but was submitted as a batch job, run as a detached process
    >>etc---otherwise he wouldn't have had the problem.

    >
    >
    > Or abbreviated "mount": the symbol is defined so:
    >
    > $mount := mount/noassist
    >
    > with no asterisk to allow truncation.


    Or systartup_vms.com redefines mount back to "mount/assist", or
    removes the redefinition of mount ($ delete/symbol mount), or
    does an explicit "$ mount/assist...", etc. There are infinite
    ways an ingenious system mangler can muck things up!

    We really need to see systartup_vms.com to know for sure.

    >
    > BTW, I *always* fully spell out DCL command verbs
    > and symbols in *procedures* I write, including
    > SYSTARTUP_VMS.COM, etc.. I can't tell you how
    > many old procedures I encounter have things like "del"
    > and "cop" in them for no apparent reason, or "say" with
    > no local definition (as Write Sys$Output). I fix them if
    > I have to touch them.


    A truly excellent standard practice.

    >
    > -Ken



    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  13. Re: Bypass mount/system request at boot time?

    In article , "Ed Dennison" writes:
    > "Phillip Helbig---remove CLOTHES to reply"
    > wrote in message news:gd3v58$vsg$1@online.de...
    >> In article , John Santos
    >> writes:
    >>
    >>> With the disk present but unmountable, you are in this Catch-22:
    >>> the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet
    >>> and logins aren't enabled yet, so you can't log in to reply to the
    >>> mount request. You should add /noassist to the mounts in
    >>> systartup_vms.com, or stick them in a batch job that doesn't get
    >>> executed until after logins are enabled and the rest of the system
    >>> is up. (But you probably need the disks mounted to start the
    >>> application, so I would go with mount/noassist. Then at least you
    >>> can log in and fix things if a disk goes south.)

    >>
    >> I agree! MOUNT/NOASSIST in the startup, especially if you expect things
    >> to come up automatically out of the box after, say, an emergency reboot,
    >> power failure etc.
    >>

    >
    > At startup you should not need to specify /NOASSIST. This should - in
    > theory - be the default.
    > VMS$BASEENVIRON-050_VMS.COM sets up the symbol 'mount' and equates it to
    > 'mount/noassist'.
    > So long as this procedure runs (and you spell 'mount' correctly) you should
    > not need to use the /NOASSIST qualifier.


    I have never seen the definition you describe. Here is the result of
    $ SHOW SYMBOL/GLOBAL/ALL at the beginning of a 7.3-2 SYSTARTUP_VMS.COM:

    $RESTART == "FALSE"
    $SEVERITY == "0"
    $STATUS == "%X00038140"
    OPC$OVERRIDE_CLASSES == ""
    PREFIX_STRING == "DECW$GRAPHICS_,SYS$,DECW$"
    STARTUP$AUTOCONFIGURE_ALL == 1 Hex = 00000001 Octal = 00000000001
    STARTUP$INTERACTIVE_LOGINS == 64 Hex = 00000040 Octal = 00000000100
    STDRV$AUDIT == "true"
    STDRV$ERROR_CODE == "%X000182B2"
    STDRV$SECSRV == "true"

    [there's no local symbol present for MOUNT, either].

    Perhaps you are being misled by the _other_ documented behavior, that
    $ MOUNT becomes $ MOUNT/NOASSIST if there are no operator terminals
    at the time able to receive mount requests.

    $ MOUNT/ASSIST is normally appropriate at mount time, but if you have
    shadow sets you may want to consider /POLICY=REQUIRE_MEMBERS as well,
    since this gives you a chance to reject the mounting of a single
    member when it may be possible that the single member that is seen
    at boot is not the one with the most current data.

    --
    George Cornelius cornelius A T eisner D O T decus D O T org
    cornelius A T mayo D O T edu

  14. Re: Bypass mount/system request at boot time?

    In article , "Ed Dennison" writes:
    > "Phillip Helbig---remove CLOTHES to reply"
    > wrote in message news:gd3v58$vsg$1@online.de...
    >> In article , John Santos
    >> writes:
    >>
    >>> With the disk present but unmountable, you are in this Catch-22:
    >>> the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet
    >>> and logins aren't enabled yet, so you can't log in to reply to the
    >>> mount request. You should add /noassist to the mounts in
    >>> systartup_vms.com, or stick them in a batch job that doesn't get
    >>> executed until after logins are enabled and the rest of the system
    >>> is up. (But you probably need the disks mounted to start the
    >>> application, so I would go with mount/noassist. Then at least you
    >>> can log in and fix things if a disk goes south.)

    >>
    >> I agree! MOUNT/NOASSIST in the startup, especially if you expect things
    >> to come up automatically out of the box after, say, an emergency reboot,
    >> power failure etc.
    >>

    >
    > At startup you should not need to specify /NOASSIST. This should - in
    > theory - be the default.
    > VMS$BASEENVIRON-050_VMS.COM sets up the symbol 'mount' and equates it to
    > 'mount/noassist'.


    It's done as a local symbol, and, per my prior post, is not present
    when SYSTARTUP_VMS.COM is entered. The symbol went away when the
    VMS$BASEENVIRON* file completed execution.

    --
    George Cornelius cornelius A T eisner D O T decus D O T org
    cornelius A T mayo D O T edu

  15. Re: Bypass mount/system request at boot time?

    I wrote:

    > $ MOUNT/ASSIST is normally appropriate at mount time [...]

    ^^^^^^
    oops, /NOASSIST

    --
    George Cornelius cornelius A T eisner D O T decus D O T org
    cornelius A T mayo D O T edu

+ Reply to Thread