Volume label. - VMS

This is a discussion on Volume label. - VMS ; I have a ds10 with 2 disks. One is named alphasys which is the system disk and one named userdisk (which equates to user$disk). Is there a way to add an alias name to user$disk so that when an application ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 42

Thread: Volume label.

  1. Volume label.

    I have a ds10 with 2 disks. One is named alphasys which is the
    system disk and one named userdisk (which equates to user$disk).
    Is there a way to add an alias name to user$disk so that when
    an application wants to access web$disk it will access the
    user$disk?

    Thanks in advance.

  2. Re: Volume label.

    On Dec 19, 2:12 pm, Chuck Aaron wrote:
    > I have a ds10 with 2 disks. One is named alphasys which is the
    > system disk and one named userdisk (which equates to user$disk).
    > Is there a way to add an alias name to user$disk so that when
    > an application wants to access web$disk it will access the
    > user$disk?
    >
    > Thanks in advance.


    Issue the following command ...

    $ SHOW LOGICAL /FULL USER$DISK

    If it says the logical is system-wide, and exec mode (which it should
    be) then you can issue a ...

    $ DEFINE /SYSTEM /EXEC WEB$DISK USER$DISK:

    which will do the mapping you're asking for. You would also add the
    same $DEFINE command to either the SYS$MANAGER:SYLOGICALS.COM or SYS
    $MANAGER:SYSTARTUP_VMS.COM procedure.

  3. Re: Volume label.

    In article , Chuck Aaron writes:
    > I have a ds10 with 2 disks. One is named alphasys which is the
    > system disk and one named userdisk (which equates to user$disk).
    > Is there a way to add an alias name to user$disk so that when
    > an application wants to access web$disk it will access the
    > user$disk?


    You need to study up on logical names.


  4. Re: Volume label.

    On Dec 19, 2:12 pm, Chuck Aaron wrote:
    > I have a ds10 with 2 disks. One is named alphasys which is the
    > system disk and one named userdisk (which equates to user$disk).
    > Is there a way to add an alias name to user$disk so that when
    > an application wants to access web$disk it will access the
    > user$disk?
    >
    > Thanks in advance.


    Chuck,

    As has been noted, logical names are the answer to this need. For
    safety's sake, my standard recommendation to clients with a situation
    such as this is to define a logical name WEB$DISK in terms of the
    already existent name for USER$DISK making use of DCL Lexical
    functions, to wit:

    $ ASSIGN [various qualifiers as appropriate] 'F
    $TRNLNM("USER$DISK")' WEB$DISK

    Logical names, and for that matter, DCL lexical functions, are one of
    the most powerful tools on OpenVMS. A thorough read of the relevant
    manuals such as the DCL Dictionary, Programming Concepts, and System
    Services manuals (all of which are available on the OpenVMS WWW site
    at http://www.hp.com/go/openvms ) is highly recommended.

    I also published a series of columns on the use of logical names on
    OpenVMS.org. The first of these "The OpenVMS Consultant: Logical Names
    (Part 1)", is available at http://www.openvms.org/stories.php?s.../09/24/5441505

    The power of logical names was also the subject of my OpenVMS
    Technical Journal paper " Inheritance Based Environments in Stand-
    alone OpenVMS Systems and OpenVMS Clusters", a reprint of which is
    available from either the OpenVMS WWW site or my site at
    http://www.rlgsc.com/publications/vm...heritance.html

    There are also several presentations on related topics available from
    my various DECUS presentations, available via http://www.rlgsc.com/presentations.html

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



  5. Re: Volume label.

    On Dec 20, 7:42 am, Bob Gezelter wrote:
    > On Dec 19, 2:12 pm, Chuck Aaron wrote:
    >
    > > I have a ds10 with 2 disks. One is named alphasys which is the
    > > system disk and one named userdisk (which equates to user$disk).
    > > Is there a way to add an alias name to user$disk so that when
    > > an application wants to access web$disk it will access the
    > > user$disk?

    >
    > > Thanks in advance.

    >
    > Chuck,
    >
    > As has been noted, logical names are the answer to this need. For
    > safety's sake, my standard recommendation to clients with a situation
    > such as this is to define a logical name WEB$DISK in terms of the
    > already existent name for USER$DISK making use of DCL Lexical
    > functions, to wit:
    >
    > $ ASSIGN [various qualifiers as appropriate] 'F
    > $TRNLNM("USER$DISK")' WEB$DISK


    That depends on his particular needs, no? Some might instead need
    something like

    $ DEFINE /SYSTEM/EXEC WEB$DISK USER$DISK:

    so that reDEFINEing USER$DISK would automatically reDEFINE both
    logical names. It depends on your what your site needs.

    Be sure to include the colon in the equivalence name in this command
    (you should *NOT* use the colon inside the F$TRNLNM function as in Bob
    Gezelter's example above)! Otherwise you may get problems with certain
    commands (like SET DEFAULT). You should always include the trailing
    colon in the equivalence name whenever it is a disk or another logical
    name that ultimately translates to a generalized file specification.
    [...]

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


    AEF

  6. Re: Volume label.

    Bob Gezelter wrote:

    >
    > I also published a series of columns on the use of logical names on
    > OpenVMS.org. The first of these "The OpenVMS Consultant: Logical Names
    > (Part 1)", is available at http://www.openvms.org/stories.php?s.../09/24/5441505
    >
    >


    Bob,

    Nice material. I learned something. Thanks.

    Part 3 has no forwarding URL to Part 4.

    .. fred bach ..

  7. Re: Volume label.

    On Dec 20, 4:04 pm, Fred Bach wrote:
    > Bob Gezelter wrote:
    >
    > > I also published a series of columns on the use of logical names on
    > > OpenVMS.org. The first of these "The OpenVMS Consultant: Logical Names
    > > (Part 1)", is available athttp://www.openvms.org/stories.php?story=02/09/24/5441505

    >
    > Bob,
    >
    > Nice material. I learned something. Thanks.
    >
    > Part 3 has no forwarding URL to Part 4.
    >
    > .. fred bach ..


    Fred,

    I am glad that the material was useful. The Technical Journal article
    was particularly fun to write and diagram.

    I have forwarded your report of a missing (hyper)link to Ken Farmer at
    OpenVMS.org.

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

  8. Re: Volume label.

    On Dec 20, 10:34 am, AEF wrote:
    > On Dec 20, 7:42 am, Bob Gezelter wrote:
    >
    >
    >
    > > On Dec 19, 2:12 pm, Chuck Aaron wrote:

    >
    > > > I have a ds10 with 2 disks. One is named alphasys which is the
    > > > system disk and one named userdisk (which equates to user$disk).
    > > > Is there a way to add an alias name to user$disk so that when
    > > > an application wants to access web$disk it will access the
    > > > user$disk?

    >
    > > > Thanks in advance.

    >
    > > Chuck,

    >
    > > As has been noted, logical names are the answer to this need. For
    > > safety's sake, my standard recommendation to clients with a situation
    > > such as this is to define a logical name WEB$DISK in terms of the
    > > already existent name for USER$DISK making use of DCL Lexical
    > > functions, to wit:

    >
    > > $ ASSIGN [various qualifiers as appropriate] 'F
    > > $TRNLNM("USER$DISK")' WEB$DISK

    >
    > That depends on his particular needs, no? Some might instead need
    > something like
    >
    > $ DEFINE /SYSTEM/EXEC WEB$DISK USER$DISK:
    >
    > so that reDEFINEing USER$DISK would automatically reDEFINE both
    > logical names. It depends on your what your site needs.
    >
    > Be sure to include the colon in the equivalence name in this command
    > (you should *NOT* use the colon inside the F$TRNLNM function as in Bob
    > Gezelter's example above)! Otherwise you may get problems with certain
    > commands (like SET DEFAULT). You should always include the trailing
    > colon in the equivalence name whenever it is a disk or another logical
    > name that ultimately translates to a generalized file specification.
    > [...]
    >
    > > - Bob Gezelter,http://www.rlgsc.com

    >
    > AEF


    AEF,

    Or not, as the case may be.

    Defining the equivalence name to point to a logical name means that
    the evaluation of WEB$DISK is deferred till it is actually used. If it
    is pointing to an area used by the WWW server, it can be confusing for
    it to follow another part of one's logical name context.

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

  9. Re: Volume label.

    On Dec 21, 5:42 am, Bob Gezelter wrote:
    > On Dec 20, 10:34 am, AEF wrote:
    >
    >
    >
    > > On Dec 20, 7:42 am, Bob Gezelter wrote:

    >
    > > > On Dec 19, 2:12 pm, Chuck Aaron wrote:

    >
    > > > > I have a ds10 with 2 disks. One is named alphasys which is the
    > > > > system disk and one named userdisk (which equates to user$disk).
    > > > > Is there a way to add an alias name to user$disk so that when
    > > > > an application wants to access web$disk it will access the
    > > > > user$disk?

    >
    > > > > Thanks in advance.

    >
    > > > Chuck,

    >
    > > > As has been noted, logical names are the answer to this need. For
    > > > safety's sake, my standard recommendation to clients with a situation
    > > > such as this is to define a logical name WEB$DISK in terms of the
    > > > already existent name for USER$DISK making use of DCL Lexical
    > > > functions, to wit:

    >
    > > > $ ASSIGN [various qualifiers as appropriate] 'F
    > > > $TRNLNM("USER$DISK")' WEB$DISK

    >
    > > That depends on his particular needs, no? Some might instead need
    > > something like

    >
    > > $ DEFINE /SYSTEM/EXEC WEB$DISK USER$DISK:

    >
    > > so that reDEFINEing USER$DISK would automatically reDEFINE both
    > > logical names. It depends on your what your site needs.

    >
    > > Be sure to include the colon in the equivalence name in this command
    > > (you should *NOT* use the colon inside the F$TRNLNM function as in Bob
    > > Gezelter's example above)! Otherwise you may get problems with certain
    > > commands (like SET DEFAULT). You should always include the trailing
    > > colon in the equivalence name whenever it is a disk or another logical
    > > name that ultimately translates to a generalized file specification.
    > > [...]

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

    >
    > > AEF

    >
    > AEF,
    >
    > Or not, as the case may be.
    >
    > Defining the equivalence name to point to a logical name means that
    > the evaluation of WEB$DISK is deferred till it is actually used.


    So why is that a bad thing? With SYS$MANAGER, SYS$SYSROOT isn't
    evaluated until it is used, e.g.

    > If it
    > is pointing to an area used by the WWW server, it can be confusing for
    > it to follow another part of one's logical name context.


    I don't understand this comment. If I do SHOW LOG WEB$DISK and I get
    USER$DISK, then I know that WEB$DISK is supposed to be USER$DISK. If I
    use your method, then all I see upon running SHOW LOG is the final
    translation and I then have no clue that it is supposed to be whatever
    USER$DISK is. For example, consider SYS$SYSROOT, SYS$SPECIFIC, and SYS
    $COMMON. By running SHOW LOGICAL on all of these, it is not clear
    whether SYS$SPECIFIC is the same as the first equivalence name of SYS
    $SYSROOT by design or coincidence. In fact, people have several times
    here asked why SYS$SYSROOT wasn't defined to be SYS$SPECIFIC, SYS
    $COMMON. (Can you answer that?)

    Just to emphasize, which method you want to use will depend on your
    needs.

    >
    > - Bob Gezelter,http://www.rlgs.com


    AEF

  10. Re: Volume label.

    On Dec 21, 10:39 am, Bob Gezelter wrote:
    > On Dec 20, 4:04 pm, Fred Bach wrote:
    >
    > > Bob Gezelter wrote:

    >
    > > > I also published a series of columns on the use of logical names on
    > > > OpenVMS.org. The first of these "The OpenVMS Consultant: Logical Names
    > > > (Part 1)", is available athttp://www.openvms.org/stories.php?story=02/09/24/5441505

    >
    > > Bob,

    >
    > > Nice material. I learned something. Thanks.

    >
    > > Part 3 has no forwarding URL to Part 4.

    >
    > > .. fred bach ..

    >
    > Fred,
    >
    > I am glad that the material was useful. The Technical Journal article
    > was particularly fun to write and diagram.
    >
    > I have forwarded your report of a missing (hyper)link to Ken Farmer at
    > OpenVMS.org.
    >
    > - Bob Gezelter,http://www.rlgsc.com



    The links between parts 1 to 5 have now been fixed

  11. Re: Volume label.

    On Dec 21, 5:42 am, Bob Gezelter wrote:
    > On Dec 20, 10:34 am, AEF wrote:
    >
    >
    >
    > > On Dec 20, 7:42 am, Bob Gezelter wrote:

    >
    > > > On Dec 19, 2:12 pm, Chuck Aaron wrote:

    >
    > > > > I have a ds10 with 2 disks. One is named alphasys which is the
    > > > > system disk and one named userdisk (which equates to user$disk).
    > > > > Is there a way to add an alias name to user$disk so that when
    > > > > an application wants to access web$disk it will access the
    > > > > user$disk?

    >
    > > > > Thanks in advance.

    >
    > > > Chuck,

    >
    > > > As has been noted, logical names are the answer to this need. For
    > > > safety's sake, my standard recommendation to clients with a situation
    > > > such as this is to define a logical name WEB$DISK in terms of the
    > > > already existent name for USER$DISK making use of DCL Lexical
    > > > functions, to wit:

    >
    > > > $ ASSIGN [various qualifiers as appropriate] 'F
    > > > $TRNLNM("USER$DISK")' WEB$DISK

    >
    > > That depends on his particular needs, no? Some might instead need
    > > something like

    >
    > > $ DEFINE /SYSTEM/EXEC WEB$DISK USER$DISK:

    >
    > > so that reDEFINEing USER$DISK would automatically reDEFINE both
    > > logical names. It depends on your what your site needs.

    >
    > > Be sure to include the colon in the equivalence name in this command
    > > (you should *NOT* use the colon inside the F$TRNLNM function as in Bob
    > > Gezelter's example above)! Otherwise you may get problems with certain
    > > commands (like SET DEFAULT). You should always include the trailing
    > > colon in the equivalence name whenever it is a disk or another logical
    > > name that ultimately translates to a generalized file specification.
    > > [...]

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

    >
    > > AEF

    >
    > AEF,
    >
    > Or not, as the case may be.
    >
    > Defining the equivalence name to point to a logical name means that
    > the evaluation of WEB$DISK is deferred till it is actually used. If it
    > is pointing to an area used by the WWW server, it can be confusing for
    > it to follow another part of one's logical name context.
    >
    > - Bob Gezelter,http://www.rlgs.com


    You mistyped your Web address! This one is for sale.

  12. Re: Volume label.

    AEF wrote:
    >> Defining the equivalence name to point to a logical name means that
    >> the evaluation of WEB$DISK is deferred till it is actually used.

    >
    > So why is that a bad thing? With SYS$MANAGER, SYS$SYSROOT isn't
    > evaluated until it is used, e.g.


    If you truly want to emulate the logical that is created when you mount
    the disk, then I would put in a identical logical name definition.

    consider the difference between:

    > $define/system/exec/trans=(conc,terminal) $mydisk 'f$trnlnm("$DISK2")
    > $define/system/exec/trabs=(conc) $mydisk $DISK2


    in cases where you want to:

    > $define/system/trans=(conc,term) $myroot 'f$trnlnm("$mydisk")'[myroot.]


    The first case will work. The second case won't work because $myroot
    will point to $disk2 which won't translate to whatever disk drive it is
    pointing to.


  13. Re: Volume label.

    On Dec 21, 10:22 am, JF Mezei wrote:
    > AEF wrote:
    > >> Defining the equivalence name to point to a logical name means that
    > >> the evaluation of WEB$DISK is deferred till it is actually used.

    >
    > > So why is that a bad thing? With SYS$MANAGER, SYS$SYSROOT isn't
    > > evaluated until it is used, e.g.

    >
    > If you truly want to emulate the logical that is created when you mount
    > the disk, then I would put in a identical logical name definition.


    What if you don't?

    >
    > consider the difference between:
    >
    > > $define/system/exec/trans=(conc,terminal) $mydisk 'f$trnlnm("$DISK2")
    > > $define/system/exec/trabs=(conc) $mydisk $DISK2


    You forgot to include the trailing colon in the second command.

    >
    > in cases where you want to:
    >
    > > $define/system/trans=(conc,term) $myroot 'f$trnlnm("$mydisk")'[myroot.]

    >
    > The first case will work. The second case won't work because $myroot
    > will point to $disk2 which won't translate to whatever disk drive it is
    > pointing to.


    The second case won't work because you forgot to include the trailing
    colon and because you didn't omit "term" in the command that defines
    $MYROOT.

    *** Always include the trailing colon (after apostrophe substitution,
    if any) in equivalence names that are file-oriented devices or logical
    names which ultimately translate to any valid subset of a full file-
    spec. ***

    (Seems to me I heard this somewhere before -- possibly even in this
    thread!)

    If you look at SYS$SYSROOT, the SYS$COMMON portion of it drops the
    "term" part for this very reason. Notice also that SYS$COMMON is
    followed by a trailing colon.

    $ SHOW LOG SYS$SYSROOT/FUL
    "SYS$SYSROOT" [exec] = "EISNER$DRA5:[SYS0.]" [concealed,terminal]
    (LNM$SYSTEM
    _TABLE)
    = "SYS$COMMON:"
    ^^^^^^^^^^^^^----- no concealed or terminal for this one
    (terminal being the relevant item here)
    1 "SYS$COMMON" [exec] = "EISNER$DRA5:
    [SYS0.SYSCOMMON.]" [concealed,terminal] (L
    NM$SYSTEM_TABLE)
    $

    AEF

  14. Re: Volume label.

    AEF wrote:

    > The second case won't work because you forgot to include the trailing
    > colon and because you didn't omit "term" in the command that defines
    > $MYROOT.


    Which is my point. If you want to define a logical that behaves exactly
    like that of the logical created when you mount a drive, you need to
    have it translate directly because that logical might be used in
    situations where it is translated to form a new "translation=terminal"
    logical.


  15. Re: Volume label.

    On Dec 21, 12:17 pm, JF Mezei wrote:
    > AEF wrote:
    > > The second case won't work because you forgot to include the trailing
    > > colon and because you didn't omit "term" in the command that defines
    > > $MYROOT.

    >
    > Which is my point. If you want to define a logical that behaves exactly
    > like that of the logical created when you mount a drive, you need to
    > have it translate directly because that logical might be used in
    > situations where it is translated to form a new "translation=terminal"
    > logical.


    First of all, when you DEFINE or logical name you should ***ALWAYS***,
    ***ALWAYS***, ***ALWAYS*** include a trailing colon (after apostrophe
    substitution) in the equivalence name if it is a file-oriented device
    or a logical name that iteratively translates to any valid subset (or
    all) of a full file-spec. Period. (For batch queues -- and perhaps
    some of the other types of logical names -- you SHOULDN'T include a
    trailing colon!)

    Second, what if you don't and what difference does it make anyway
    other than what I already pointed out?

    Nothing you posted contradicts what I originally said: It depends on
    what your site's needs are.

    I do agree that if you want A you need to do A. But if you want B, you
    have to do B, which is what I already said before. Interestingly, in
    the case of SYS$SYSROOT, both A *and* B are used! Like I said, it
    depends on your needs.

    AEF

    Reminder: When you DEFINE or logical name you should ***ALWAYS***,
    ***ALWAYS***, ***ALWAYS*** include a trailing colon (after apostrophe
    substitution) in the equivalence name if it is a file-oriented device
    or a logical name that iteratively translates to any valid subset (or
    all) of a full file-spec. Period. (For batch queues -- and perhaps
    some of the other types of logical names -- you SHOULDN'T include a
    trailing colon!)

    In case you missed it the first two times:

    Reminder: When you DEFINE or logical name you should ***ALWAYS***,
    ***ALWAYS***, ***ALWAYS*** include a trailing colon (after apostrophe
    substitution) in the equivalence name if it is a file-oriented device
    or a logical name that iteratively translates to any valid subset (or
    all) of a full file-spec. Period. (For batch queues -- and perhaps
    some of the other types of logical names -- you SHOULDN'T include a
    trailing colon!)

  16. Re: Volume label.

    On Dec 21, 12:38 pm, AEF wrote:
    > On Dec 21, 12:17 pm, JF Mezei wrote:
    >
    > > AEF wrote:
    > > > The second case won't work because you forgot to include the trailing
    > > > colon and because you didn't omit "term" in the command that defines
    > > > $MYROOT.

    >
    > > Which is my point. If you want to define a logical that behaves exactly
    > > like that of the logical created when you mount a drive, you need to
    > > have it translate directly because that logical might be used in
    > > situations where it is translated to form a new "translation=terminal"
    > > logical.

    >
    > First of all, when you DEFINE or logical name you should ***ALWAYS***,
    > ***ALWAYS***, ***ALWAYS*** include a trailing colon (after apostrophe
    > substitution) in the equivalence name if it is a file-oriented device
    > or a logical name that iteratively translates to any valid subset (or
    > all) of a full file-spec. Period. (For batch queues -- and perhaps
    > some of the other types of logical names -- you SHOULDN'T include a
    > trailing colon!)
    >
    > Second, what if you don't and what difference does it make anyway
    > other than what I already pointed out?
    >
    > Nothing you posted contradicts what I originally said: It depends on
    > what your site's needs are.
    >
    > I do agree that if you want A you need to do A. But if you want B, you
    > have to do B, which is what I already said before. Interestingly, in
    > the case of SYS$SYSROOT, both A *and* B are used! Like I said, it
    > depends on your needs.
    >
    > AEF
    >
    > Reminder: When you DEFINE or logical name you should ***ALWAYS***,
    > ***ALWAYS***, ***ALWAYS*** include a trailing colon (after apostrophe
    > substitution) in the equivalence name if it is a file-oriented device
    > or a logical name that iteratively translates to any valid subset (or
    > all) of a full file-spec. Period. (For batch queues -- and perhaps
    > some of the other types of logical names -- you SHOULDN'T include a
    > trailing colon!)
    >
    > In case you missed it the first two times:
    >
    > Reminder: When you DEFINE or logical name you should ***ALWAYS***,
    > ***ALWAYS***, ***ALWAYS*** include a trailing colon (after apostrophe
    > substitution) in the equivalence name if it is a file-oriented device
    > or a logical name that iteratively translates to any valid subset (or
    > all) of a full file-spec. Period. (For batch queues -- and perhaps
    > some of the other types of logical names -- you SHOULDN'T include a
    > trailing colon!)


    Oops! That should be "When you DEFINE *a* logical name...", of course.

    Sorry.

    From your example

    > > > $define/system/exec/trans=(conc,terminal) $mydisk 'f$trnlnm("$DISK2")
    > > > $define/system/exec/trabs=(conc) $mydisk $DISK2

    > >
    > > in cases where you want to:
    > >
    > > > $define/system/trans=(conc,term) $myroot 'f$trnlnm("$mydisk")'[myroot.]


    So it's really the difference between

    (A) $mydisk = dka0:[myroot.] conc,term

    and

    (B) $mydisk = $disk2:[myroot.] conc

    The key difference is that if you later redefine $disk2 to something
    else, A will still point to dka0: but B will be redirected to
    [myroot.] on the new equivalence name of $disk2. In some cases you may
    want A and in others you may want B.

    That's all I was trying to say.

    AEF

  17. Re: Volume label.

    In article
    , AEF
    writes:

    > I don't understand this comment. If I do SHOW LOG WEB$DISK and I get
    > USER$DISK, then I know that WEB$DISK is supposed to be USER$DISK. If I
    > use your method, then all I see upon running SHOW LOG is the final
    > translation and I then have no clue that it is supposed to be whatever
    > USER$DISK is. For example, consider SYS$SYSROOT, SYS$SPECIFIC, and SYS
    > $COMMON. By running SHOW LOGICAL on all of these, it is not clear
    > whether SYS$SPECIFIC is the same as the first equivalence name of SYS
    > $SYSROOT by design or coincidence. In fact, people have several times
    > here asked why SYS$SYSROOT wasn't defined to be SYS$SPECIFIC, SYS
    > $COMMON. (Can you answer that?)


    Didn't you answer that here a while back?


  18. Re: Volume label.

    In article <476bda4f$0$22049$c3e8da3@news.astraweb.com>, JF Mezei
    writes:

    > > $define/system/exec/trans=(conc,terminal) $mydisk 'f$trnlnm("$DISK2")
    > > $define/system/exec/trabs=(conc) $mydisk $DISK2

    >
    > in cases where you want to:
    >
    > > $define/system/trans=(conc,term) $myroot 'f$trnlnm("$mydisk")'[myroot.]

    >
    > The first case will work. The second case won't work because $myroot
    > will point to $disk2 which won't translate to whatever disk drive it is
    > pointing to.


    Yes. However, if you really need to define a (CONC,TERM) logical name,
    I would recommend writing a procedure which uses F$PARSE, NOCONCEAL etc
    to define it properly whatever parameter is passed to it.


  19. Re: Volume label.

    In article
    , AEF
    writes:

    > On Dec 21, 12:17 pm, JF Mezei wrote:
    > > AEF wrote:
    > > > The second case won't work because you forgot to include the trailing
    > > > colon and because you didn't omit "term" in the command that defines
    > > > $MYROOT.

    > >
    > > Which is my point. If you want to define a logical that behaves exactly
    > > like that of the logical created when you mount a drive, you need to
    > > have it translate directly because that logical might be used in
    > > situations where it is translated to form a new "translation=terminal"
    > > logical.

    >
    > First of all, when you DEFINE or logical name you should ***ALWAYS***,
    > ***ALWAYS***, ***ALWAYS*** include a trailing colon (after apostrophe
    > substitution) in the equivalence name if it is a file-oriented device
    > or a logical name that iteratively translates to any valid subset (or
    > all) of a full file-spec. Period.


    Shouldn't that be "colon"? :-)


  20. Re: Volume label.

    On Dec 22, 6:24 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
    remove CLOTHES to reply) wrote:
    > In article
    > , AEF
    >
    > writes:
    > > I don't understand this comment. If I do SHOW LOG WEB$DISK and I get
    > > USER$DISK, then I know that WEB$DISK is supposed to be USER$DISK. If I
    > > use your method, then all I see upon running SHOW LOG is the final
    > > translation and I then have no clue that it is supposed to be whatever
    > > USER$DISK is. For example, consider SYS$SYSROOT, SYS$SPECIFIC, and SYS
    > > $COMMON. By running SHOW LOGICAL on all of these, it is not clear
    > > whether SYS$SPECIFIC is the same as the first equivalence name of SYS
    > > $SYSROOT by design or coincidence. In fact, people have several times
    > > here asked why SYS$SYSROOT wasn't defined to be SYS$SPECIFIC, SYS
    > > $COMMON. (Can you answer that?)

    >
    > Didn't you answer that here a while back?


    No. What I did do was explain what was behind the confusion of why SYS
    $SYSROOT appears to take two roles:

    (1) A logical name translating to the search list SYS$SPECIFIC (or the
    translation of SYS$SPECIFIC, which is effectively the same thing, of
    course), SYS$COMMON

    (2) Part of the header of the SYS$SPECIFIC portion of the output of a
    DIRECTORY command that has SYS$SYSROOT (implied or otherwise) as part
    of its argument.

    I never said why VMS uses SYS$SPECIFIC's translation when constructing
    SYS$SYSROOT instead of just the name SYS$SPECIFIC itself. I suspect
    either something in the boot process makes it easier that way or
    someone at DEC just wanted to do it that way (I think Hoff once stated
    a preference for that style, e.g.) or something else. I never saw a
    convincing definitive answer to this.

    There *was* the issue of why the first equivalence name of SYS$SYSROOT
    (SYS$SPECIFIC) is concealed and the answer to THAT was so that you get
    SYS$SYSROOT instead of the translation of SYS$SPECIFIC when you PARSE
    it. And I have to give credit to someone else (I forget whom) for
    that. And it is for this reason that even if you did explicitly use
    the name SYS$SPECIFIC in constructing SYS$SYSROOT, you'd still need it
    to be concealed and you'd still get the same "confusing" DIRECTORY SYS
    $SYSROOT... output. But it would make it more obvious to the
    uninitiated what SYS$SYSROOT is when running the command SHOW LOGICAL
    SYS$SYSROOT, except for the "confusing" DIRECTORY SYS$SYSROOT...
    output, of course.

    AEF

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast