[OpenVMS] Context lexical functions - VMS

This is a discussion on [OpenVMS] Context lexical functions - VMS ; As you might know there are some lexical functions for getting information of a particular entity (like F$GETDVI, F$GETJPI, F$FILE_ATTRIBUTE) and a companion lexical function for wildcard searches of these entities (like F$DEVICE, F$CONTEXT/F$PID, F$SEARCH). Now with ODS5 and/or symbolic ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [OpenVMS] Context lexical functions

  1. [OpenVMS] Context lexical functions

    As you might know there are some lexical functions for getting information
    of a particular entity (like F$GETDVI, F$GETJPI, F$FILE_ATTRIBUTE) and
    a companion lexical function for wildcard searches of these entities
    (like F$DEVICE, F$CONTEXT/F$PID, F$SEARCH).

    Now with ODS5 and/or symbolic links, I think, there should be some
    improvement in the F$SEARCH function area.

    eg. How to specify that F$SEARCH should not follow a subdirectory
    (just like a DIR/EXC does, but lexical functions are there to not need to
    parse DCL output in temporary files, right?) or symbolic link?
    This would be handy to avoid an endless loop via SYS$COMMON:[GNV.MNT...]
    (which is an alias for usually SYS$SYSDEVICE:[PSX$ROOT.MNT...])

    eg. How to specify that F$SEARCH should look case sensitive?
    Is the SET PROCESS/CASE_LOOKUP the (only) way to go?

    Does anyone know of planned feature enhancements here?
    A F$FILCTX perhaps?

    TIA

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  2. Re: [OpenVMS] Context lexical functions

    Peter 'EPLAN' LANGSTOeGER wrote:
    > As you might know there are some lexical functions for getting information
    > of a particular entity (like F$GETDVI, F$GETJPI, F$FILE_ATTRIBUTE) and
    > a companion lexical function for wildcard searches of these entities
    > (like F$DEVICE, F$CONTEXT/F$PID, F$SEARCH).
    >
    > Now with ODS5 and/or symbolic links, I think, there should be some
    > improvement in the F$SEARCH function area.
    >
    > eg. How to specify that F$SEARCH should not follow a subdirectory
    > (just like a DIR/EXC does, but lexical functions are there to not need to
    > parse DCL output in temporary files, right?) or symbolic link?
    > This would be handy to avoid an endless loop via SYS$COMMON:[GNV.MNT...]
    > (which is an alias for usually SYS$SYSDEVICE:[PSX$ROOT.MNT...])


    I solved the endless loop problem a different way:

    See ftp://ftp.encompasserve.org/gnv/ . In particular
    gnv_com_2_1_patch_important_readme.txt .

    I have also submitted that to the HP GNV maintainer, but have not seen a
    response yet.

    Since then I found out that setting hard link or a mount point to "/"
    deeper in a directory tree is a "BAD THING" on UNIX and will cause the
    same type of endless looping problems in a directory search.

    It seems that you must not ever put a mount point or a hard link of a
    parent directory anywhere that it could be a child of that directory.
    The O'Reilly "Learning Perl" manual implies that most UNIXes prevent
    such a hard link from being made.

    And since "/" is the parent of all, it must never have a mount point or
    a hard link pointing to it.

    So if GNV and POSIX compliant pathnames need to be compatible with UNIX,
    they will need a fix.

    > eg. How to specify that F$SEARCH should look case sensitive?
    > Is the SET PROCESS/CASE_LOOKUP the (only) way to go?


    I suspect so.

    > Does anyone know of planned feature enhancements here?
    > A F$FILCTX perhaps?


    I do not.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  3. Re: Context lexical functions

    On Aug 25, 10:29 am, "John E. Malmberg" wrote:
    > Peter 'EPLAN' LANGSTOeGER wrote:
    > > As you might know there are some lexical functions for getting information
    > > of a particular entity (like F$GETDVI, F$GETJPI, F$FILE_ATTRIBUTE) and
    > > a companion lexical function for wildcard searches of these entities
    > > (like F$DEVICE, F$CONTEXT/F$PID, F$SEARCH).

    >
    > > Now with ODS5 and/or symbolic links, I think, there should be some
    > > improvement in the F$SEARCH function area.

    >
    > > eg. How to specify that F$SEARCH should not follow a subdirectory
    > > (just like a DIR/EXC does, but lexical functions are there to not need to
    > > parse DCL output in temporary files, right?) or symbolic link?
    > > This would be handy to avoid an endless loop via SYS$COMMON:[GNV.MNT...]
    > > (which is an alias for usually SYS$SYSDEVICE:[PSX$ROOT.MNT...])

    >
    > I solved the endless loop problem a different way:
    >
    > Seeftp://ftp.encompasserve.org/gnv/. In particular
    > gnv_com_2_1_patch_important_readme.txt .
    >
    > I have also submitted that to the HP GNV maintainer, but have not seen a
    > response yet.
    >
    > Since then I found out that setting hard link or a mount point to "/"
    > deeper in a directory tree is a "BAD THING" on UNIX and will cause the
    > same type of endless looping problems in a directory search.


    What? How can "/" be deeper than itself?

    > It seems that you must not ever put a mount point or a hard link of a
    > parent directory anywhere that it could be a child of that directory.
    > The O'Reilly "Learning Perl" manual implies that most UNIXes prevent
    > such a hard link from being made.


    Can you please give an example? I don't understand what you're saying.
    Don't make a parent directory a child of what directory? You mean make
    no siblings, or cousins, or cousins once removed? Do you mean "any
    parent", "the parent", any child, etc.? Please clarify, preferably
    with a clear, explicit example. Grandparents, uncles, aunts,
    grandchildren, nieces, and nephews?

    > And since "/" is the parent of all, it must never have a mount point or
    > a hard link pointing to it.


    So I assume you mean that you should not link directories such that
    link A is a subdirectory of link B or vice versa, right? (Where a
    subdirectory can be any number of levels down from the referenced
    directory. Thus, given [A.B.C.D], then [A.B], [A.B.C], [A.B.C.D] are
    all subdirectories of [A].)

    If this is right, no example will be needed.

    [...]
    > -John
    > wb8...@qsl.network
    > Personal Opinion Only


    Thanks!

    AEF


  4. Re: Context lexical functions

    AEF wrote:
    >
    > So I assume you mean that you should not link directories such that
    > link A is a subdirectory of link B or vice versa, right? (Where a
    > subdirectory can be any number of levels down from the referenced
    > directory. Thus, given [A.B.C.D], then [A.B], [A.B.C], [A.B.C.D] are
    > all subdirectories of [A].)


    You should not have a link to A as a subdirectory anywhere under A. So
    B, C, D, can not be links to A.

    > If this is right, no example will be needed.


    That is right, and it also applies to mount points, as they can cause
    the same looping.

    You can have [a.b.c.d] and [a.e.c.d], where e.dir is a link of b.dir

    So there is no problem with /bin having /disk/vms$common/gnv/bin mounted
    on it because there is no loop in the directory. If it is the same
    device than an alias or a hard link could be used instead of a mount point.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  5. Re: [OpenVMS] Context lexical functions

    In article <46cf570b$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) writes:
    >As you might know there are some lexical functions for getting information
    >of a particular entity (like F$GETDVI, F$GETJPI, F$FILE_ATTRIBUTE) and
    >a companion lexical function for wildcard searches of these entities
    >(like F$DEVICE, F$CONTEXT/F$PID, F$SEARCH).


    Yes, there is F$GETSYI and the companion F$CSID, too,
    but it doesn't matter here. Were talking about F$SEARCH and F$FILE now...

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  6. Re: [OpenVMS] Context lexical functions

    In article , "John E. Malmberg" writes:
    >I solved the endless loop problem a different way:
    >
    >See ftp://ftp.encompasserve.org/gnv/ . In particular
    >gnv_com_2_1_patch_important_readme.txt .


    GNV is not the only sort of endless loops. But it is a common one now...

    eg.
    $ CREATE/DIR [.A]
    $ CREATE/DIR [.B]
    $ SET FILE/ENTER=[.A]B.DIR B.DIR
    $ SET FILE/ENTER=[.B]A.DIR A.DIR
    $ DIR [.A...]

    works (some kind of) on OpenVMS VAX (until the eight dir levels are used up)
    and on OpenVMS Alpha/I64 loops until RMS can no longer display the
    (ever increasing) directory levels (and then only the FIDs are displayed)
    but unfortunately the loop doesn't stop...

    Yes, GNV should be fixed if it has a problem (which I currently can't
    comment on) but I'm looking for a (lexical) way to influence F$SEARCH
    (to not follow subdirectories and/or aliases and/or symbolic links).

    I (perhaps !) can workaround with some nested F$SEARCH (with IFs and more),
    but F$CONTEXT led me to think, that there must/could be a much smarter way.

    TIA

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

+ Reply to Thread