Divining the full pathname of a file, all logicals translated - VMS

This is a discussion on Divining the full pathname of a file, all logicals translated - VMS ; I'm looking at ways to generate the full "low level" pathname to a file with no logicals, concealed, terminal, or otherwise involved, and in standard format. So far the way that seems to work closest to what I need using ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 31

Thread: Divining the full pathname of a file, all logicals translated

  1. Divining the full pathname of a file, all logicals translated

    I'm looking at ways to generate the full "low level" pathname to a
    file with no logicals, concealed, terminal, or otherwise involved, and
    in standard format.

    So far the way that seems to work closest to what I need using only
    VMS provided tools follows. THis is (currently) a DCL command
    procedure searching multiple directories (using F$SEARCH with a
    wildcard, and generally with a logical in the search term):

    - F$SEARCH returns the filename.
    - The return from F$SEARCH will already have translated non-
    terminal logicals; for example in the SYSTEM account searching for SYS
    $LOGIN:LOGIN.COM returns SYS$COMMON:[SYSMGR]LOGIN.COM;12

    - Take the output of F$SEARCH and feed it to F$PARSE with
    argument "NO_CONCEAL" as the parse type.

    This returns:

    NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12

    Thats workable but I really need it to be normalized as

    NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12

    I can put in conditional code to clean up the f$parse output but I'd
    rather find a way to have the clean pathname returned. Is there a way
    to do this using normal lexical functions?

    =====

    One other alternative seems to be to use one of the FID to NAME
    programs; since I can locate the file in question I have its FID and
    can run it through a program (seen online here in COV, also perhaps on
    freeware) and get the full raw pathname back. That would be
    acceptable too but if anyone's done it and has recommendations I'd
    appreciate hearing back. It would mean many thousands of image
    activations running the FID to Name program.

    Thanks for any thoughts. Yes I checked the FAQ first but didn't see
    anything that appeared relevant.

    Rich
    CCS


  2. Re: Divining the full pathname of a file, all logicals translated

    Rich Jordan wrote:
    > I'm looking at ways to generate the full "low level" pathname to a
    > file with no logicals, concealed, terminal, or otherwise involved, and
    > in standard format.
    >
    > So far the way that seems to work closest to what I need using only
    > VMS provided tools follows. THis is (currently) a DCL command
    > procedure searching multiple directories (using F$SEARCH with a
    > wildcard, and generally with a logical in the search term):
    >
    > - F$SEARCH returns the filename.
    > - The return from F$SEARCH will already have translated non-
    > terminal logicals; for example in the SYSTEM account searching for SYS
    > $LOGIN:LOGIN.COM returns SYS$COMMON:[SYSMGR]LOGIN.COM;12
    >
    > - Take the output of F$SEARCH and feed it to F$PARSE with
    > argument "NO_CONCEAL" as the parse type.
    >
    > This returns:
    >
    > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12
    >
    > Thats workable but I really need it to be normalized as
    >
    > NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12
    >
    > I can put in conditional code to clean up the f$parse output but I'd
    > rather find a way to have the clean pathname returned. Is there a way
    > to do this using normal lexical functions?
    >
    > =====
    >
    > One other alternative seems to be to use one of the FID to NAME
    > programs; since I can locate the file in question I have its FID and
    > can run it through a program (seen online here in COV, also perhaps on
    > freeware) and get the full raw pathname back. That would be
    > acceptable too but if anyone's done it and has recommendations I'd
    > appreciate hearing back. It would mean many thousands of image
    > activations running the FID to Name program.
    >
    > Thanks for any thoughts. Yes I checked the FAQ first but didn't see
    > anything that appeared relevant.
    >
    > Rich
    > CCS
    >


    How about just appending a -"][" to the F$SEARCH statement?

    It may be ugly but it should get the job done! For that matter, the
    ugly original should work. Is "pretty" worth the effort required?



  3. Re: Divining the full pathname of a file, all logicals translated

    On 19 Mar 2008, you wrote in comp.os.vms:

    >
    > This returns:
    >
    > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12
    >
    > Thats workable but I really need it to be normalized as
    >
    > "NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12


    When I've needed to do this I've used lexical functions:

    Given string = "NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12"

    loc = F$LOCATE(".][", string)
    len = F$LENGTH(string)
    IF loc .GT. len THEN
    string = F$EXTRACT(0,loc,string) + "." + F$EXTRACT(loc+3,len,string)
    ENDIF

    Not terribly concise, but no image activation involved!

    I don't recall if it's possible to get more than one ".]["
    sequence in a string ... if it is then you may need a loop.

    Antonio

  4. Re: Divining the full pathname of a file, all logicals translated

    Rich Jordan wrote:
    >
    > I'm looking at ways to generate the full "low level" pathname to a
    > file with no logicals, concealed, terminal, or otherwise involved, and
    > in standard format.
    >
    > So far the way that seems to work closest to what I need using only
    > VMS provided tools follows. THis is (currently) a DCL command
    > procedure searching multiple directories (using F$SEARCH with a
    > wildcard, and generally with a logical in the search term):
    >
    > - F$SEARCH returns the filename.
    > - The return from F$SEARCH will already have translated non-
    > terminal logicals; for example in the SYSTEM account searching for SYS
    > $LOGIN:LOGIN.COM returns SYS$COMMON:[SYSMGR]LOGIN.COM;12
    >
    > - Take the output of F$SEARCH and feed it to F$PARSE with
    > argument "NO_CONCEAL" as the parse type.
    >
    > This returns:
    >
    > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12
    >
    > Thats workable but I really need it to be normalized as
    >
    > NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12
    >
    > I can put in conditional code to clean up the f$parse output but I'd
    > rather find a way to have the clean pathname returned. Is there a way
    > to do this using normal lexical functions?
    >
    > =====
    >
    > One other alternative seems to be to use one of the FID to NAME
    > programs; since I can locate the file in question I have its FID and
    > can run it through a program (seen online here in COV, also perhaps on
    > freeware) and get the full raw pathname back. That would be
    > acceptable too but if anyone's done it and has recommendations I'd
    > appreciate hearing back. It would mean many thousands of image
    > activations running the FID to Name program.
    >
    > Thanks for any thoughts. Yes I checked the FAQ first but didn't see
    > anything that appeared relevant.


    Antonio's solution will work, of course.

    Myself, I'd lean toward Rich Gilbert's idea of simply reducing "][" out
    of the string unconditionally:

    $ target = F$PARSE( source,,,,, "NO_CONCEAL" ) - "]["

    David J Dachtera
    (formerly dba) DJE Systems

  5. Re: Divining the full pathname of a file, all logicals translated

    On Wed, 19 Mar 2008 15:41:40 -0700, Rich Jordan wrote:

    > I'm looking at ways to generate the full "low level" pathname to a
    > file with no logicals, concealed, terminal, or otherwise involved, and
    > in standard format.


    This might help

    http://www.kednos.com/pli_examples/0...00-1C01E7.HTML

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

  6. Re: Divining the full pathname of a file, all logicals translated

    On Mar 19, 6:15 pm, "Richard B. Gilbert"
    wrote:
    > Rich Jordan wrote:
    > > I'm looking at ways to generate the full "low level" pathname to a
    > > file with no logicals, concealed, terminal, or otherwise involved, and
    > > in standard format.

    >
    > > So far the way that seems to work closest to what I need using only
    > > VMS provided tools follows. THis is (currently) a DCL command
    > > procedure searching multiple directories (using F$SEARCH with a
    > > wildcard, and generally with a logical in the search term):

    >
    > > - F$SEARCH returns the filename.
    > > - The return from F$SEARCH will already have translated non-
    > > terminal logicals; for example in the SYSTEM account searching for SYS
    > > $LOGIN:LOGIN.COM returns SYS$COMMON:[SYSMGR]LOGIN.COM;12

    >
    > > - Take the output of F$SEARCH and feed it to F$PARSE with
    > > argument "NO_CONCEAL" as the parse type.

    >
    > > This returns:

    >
    > > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12

    >
    > > Thats workable but I really need it to be normalized as

    >
    > > NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12

    >
    > > I can put in conditional code to clean up the f$parse output but I'd
    > > rather find a way to have the clean pathname returned. Is there a way
    > > to do this using normal lexical functions?

    >
    > > =====

    >
    > > One other alternative seems to be to use one of the FID to NAME
    > > programs; since I can locate the file in question I have its FID and
    > > can run it through a program (seen online here in COV, also perhaps on
    > > freeware) and get the full raw pathname back. That would be
    > > acceptable too but if anyone's done it and has recommendations I'd
    > > appreciate hearing back. It would mean many thousands of image
    > > activations running the FID to Name program.

    >
    > > Thanks for any thoughts. Yes I checked the FAQ first but didn't see
    > > anything that appeared relevant.

    >
    > > Rich
    > > CCS

    >
    > How about just appending a -"][" to the F$SEARCH statement?
    >
    > It may be ugly but it should get the job done! For that matter, the
    > ugly original should work. Is "pretty" worth the effort required?


    Richard
    its not pretty that matters, its consistency and the possibility
    that a future requirement for sorting the pathnames may be imposed.

  7. Re: Divining the full pathname of a file, all logicals translated

    In article , Antonio Carlini writes:
    >
    > I don't recall if it's possible to get more than one ".]["
    > sequence in a string ... if it is then you may need a loop.


    No, but it is legititmate to have ".><", ".>[", or ".]<" at that
    location unless you're sure that the string has been returned from
    one of VMS' parsers. (File names can be entered with <> for
    directory delimiters, but they are always translated to [] during
    parsing.)


  8. Re: Divining the full pathname of a file, all logicals translated

    On Mar 20, 6:58 am, "Tom Linden" wrote:
    > On Wed, 19 Mar 2008 15:41:40 -0700, Rich Jordan wrote:
    > > I'm looking at ways to generate the full "low level" pathname to a
    > > file with no logicals, concealed, terminal, or otherwise involved, and
    > > in standard format.

    >
    > This might help
    >
    > http://www.kednos.com/pli_examples/0...00-1C01E7.HTML
    >
    > --
    > PL/I for OpenVMSwww.kednos.com


    Tom,
    thanks! Now if only I had a PL-1 compiler

    Actually the programs I found online use that library function;
    they're in 'C', which I have access to, so that is my fallback method
    for doing this.

    Rich

  9. Re: Divining the full pathname of a file, all logicals translated

    On Thu, 20 Mar 2008 09:01:28 -0700, Rich Jordan wrote:

    > On Mar 20, 6:58 am, "Tom Linden" wrote:
    >> On Wed, 19 Mar 2008 15:41:40 -0700, Rich Jordan
    >> wrote:
    >> > I'm looking at ways to generate the full "low level" pathname to a
    >> > file with no logicals, concealed, terminal, or otherwise involved, and
    >> > in standard format.

    >>
    >> This might help
    >>
    >> http://www.kednos.com/pli_examples/0...00-1C01E7.HTML
    >>
    >> --
    >> PL/I for OpenVMSwww.kednos.com

    >
    > Tom,
    > thanks! Now if only I had a PL-1 compiler


    If it is for hobbyist use, you can get it for free.

    Otherwise, it isn't to difficult to translate it to a lower level
    language:-)

    >
    > Actually the programs I found online use that library function;
    > they're in 'C', which I have access to, so that is my fallback method
    > for doing this.
    >
    > Rich




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

  10. RE: Divining the full pathname of a file, all logicals translated

    >...
    > One other alternative seems to be to use one of the FID to
    > NAME programs; since I can locate the file in question I have
    > its FID and can run it through a program (seen online here in
    > COV, also perhaps on
    > freeware) and get the full raw pathname back. That would be
    > acceptable too but if anyone's done it and has
    > recommendations I'd appreciate hearing back. It would mean
    > many thousands of image activations running the FID to Name

    program.
    >...


    If you are running a newer version of VMS then there is the
    F$FID_TO_NAME lexical;

    Lexicals

    F$FID_TO_NAME

    Valid for Alpha and I64 systems only.

    Translates a file identification to a file specification.

    Format

    F$FID_TO_NAME(device-name,file-id)




    Additional information available:

    Return_Value Arguments Example

    Lexicals F$FID_TO_NAME Subtopic? exa




    LEXICALS

    F$FID_TO_NAME

    Example


    $ WRITE SYS$OUTPUT
    F$FID_TO_NAME("SYS$SYSDEVICE","(2901,33,0)")
    DISK$NODE1:[VMS$COMMON.SYSEXE]SHOW.EXE;1

    This example demonstrates that the file with
    identifier
    "2901,33,0" on the system disk is file SHOW.EXE. Note:
    You
    can omit the parentheses around the file identifier,
    provided
    it is enclosed by double quotation marks.



    Lexicals F$FID_TO_NAME Subtopic?


  11. Re: Divining the full pathname of a file, all logicals translated

    David J Dachtera wrote in
    news:47E1C21E.953D8662@spam.comcast.net:

    > Antonio's solution will work, of course.
    >
    > Myself, I'd lean toward Rich Gilbert's idea of simply reducing "][" out
    > of the string unconditionally:


    So would I now that I see how obvious it is :-)

    Too much Perl and Ruby lately I guess !

    Antonio

  12. Re: Divining the full pathname of a file, all logicals translated

    On Mar 20, 11:26 am, "Peter Weaver"
    wrote:
    > >...
    > > One other alternative seems to be to use one of the FID to
    > > NAME programs; since I can locate the file in question I have
    > > its FID and can run it through a program (seen online here in
    > > COV, also perhaps on
    > > freeware) and get the full raw pathname back. That would be
    > > acceptable too but if anyone's done it and has
    > > recommendations I'd appreciate hearing back. It would mean
    > > many thousands of image activations running the FID to Name

    > program.
    > >...

    >
    > If you are running a newer version of VMS then there is the
    > F$FID_TO_NAME lexical;
    >
    > Lexicals
    >
    > F$FID_TO_NAME
    >
    > Valid for Alpha and I64 systems only.
    >
    > Translates a file identification to a file specification.
    >
    > Format
    >
    > F$FID_TO_NAME(device-name,file-id)
    >
    > Additional information available:
    >
    > Return_Value Arguments Example
    >
    > Lexicals F$FID_TO_NAME Subtopic? exa
    >
    > LEXICALS
    >
    > F$FID_TO_NAME
    >
    > Example
    >
    > $ WRITE SYS$OUTPUT
    > F$FID_TO_NAME("SYS$SYSDEVICE","(2901,33,0)")
    > DISK$NODE1:[VMS$COMMON.SYSEXE]SHOW.EXE;1
    >
    > This example demonstrates that the file with
    > identifier
    > "2901,33,0" on the system disk is file SHOW.EXE. Note:
    > You
    > can omit the parentheses around the file identifier,
    > provided
    > it is enclosed by double quotation marks.
    >
    > Lexicals F$FID_TO_NAME Subtopic?


    Peter,
    unfortunately the system in question is not current and the VMS
    versions installed does not support that lexical.

  13. Re: Divining the full pathname of a file, all logicals translated

    On Mar 19, 5:41 pm, Rich Jordan wrote:
    > I'm looking at ways to generate the full "low level" pathname to a
    > file with no logicals, concealed, terminal, or otherwise involved, and
    > in standard format.
    >
    > So far the way that seems to work closest to what I need using only
    > VMS provided tools follows. THis is (currently) a DCL command
    > procedure searching multiple directories (using F$SEARCH with a
    > wildcard, and generally with a logical in the search term):
    >
    > - F$SEARCH returns the filename.
    > - The return from F$SEARCH will already have translated non-
    > terminal logicals; for example in the SYSTEM account searching for SYS
    > $LOGIN:LOGIN.COM returns SYS$COMMON:[SYSMGR]LOGIN.COM;12
    >
    > - Take the output of F$SEARCH and feed it to F$PARSE with
    > argument "NO_CONCEAL" as the parse type.
    >
    > This returns:
    >
    > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12
    >
    > Thats workable but I really need it to be normalized as
    >
    > NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12


    Why, pray tell? If you *really* need it this way, just subtract all
    possible combinations of square and angle brackets. (I think that's
    pretty safe, but unanticipated situations and upgrades can break
    manual parsing in general.) I assume you're writing about files on an
    ODS-2 volume, right? You might get into trouble doing this on an ODS-5
    volume, but I'm not sure.

    >
    > I can put in conditional code to clean up the f$parse output but I'd
    > rather find a way to have the clean pathname returned. Is there a way
    > to do this using normal lexical functions?
    >
    > =====
    >
    > One other alternative seems to be to use one of the FID to NAME
    > programs; since I can locate the file in question I have its FID and
    > can run it through a program (seen online here in COV, also perhaps on
    > freeware) and get the full raw pathname back. That would be
    > acceptable too but if anyone's done it and has recommendations I'd
    > appreciate hearing back. It would mean many thousands of image
    > activations running the FID to Name program.


    Peter Weaver answered this. But why is it so important to remove the "]
    ["?

    AEF

    >
    > Thanks for any thoughts. Yes I checked the FAQ first but didn't see
    > anything that appeared relevant.
    >
    > Rich
    > CCS



  14. Re: Divining the full pathname of a file, all logicals translated


    "Antonio Carlini" wrote in message
    news:Xns9A66EE72E7524arcarliniONieeorg@80.5.182.99 ...
    > On 19 Mar 2008, you wrote in comp.os.vms:
    >
    >>
    >> This returns:
    >>
    >> NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12
    >>
    >> Thats workable but I really need it to be normalized as
    >>
    >> "NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12

    >
    > When I've needed to do this I've used lexical functions:
    >
    > Given string = "NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12"
    >
    > loc = F$LOCATE(".][", string)
    > len = F$LENGTH(string)
    > IF loc .GT. len THEN
    > string = F$EXTRACT(0,loc,string) + "." + F$EXTRACT(loc+3,len,string)
    > ENDIF
    >
    > Not terribly concise, but no image activation involved!
    >
    > I don't recall if it's possible to get more than one ".]["
    > sequence in a string ... if it is then you may need a loop.
    >
    > Antonio


    Also can be done simply: string = string - "]["

    Regards,
    Teijo



  15. Re: Divining the full pathname of a file, all logicals translated

    On Mar 20, 8:05 am, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article , Antonio Carlini writes:
    >
    >
    >
    > > I don't recall if it's possible to get more than one ".]["
    > > sequence in a string ... if it is then you may need a loop.

    >
    > No, but it is legititmate to have ".><", ".>[", or ".]<" at that
    > location unless you're sure that the string has been returned from
    > one of VMS' parsers. (File names can be entered with <> for
    > directory delimiters, but they are always translated to [] during
    > parsing.)


    True, which is why I used to write this sort of thing so:

    $ string = string - "][" - "]<" - ">[" - "><"

    That pretty much covers all cases. And "subtracting" a substring
    that doesn't exist from another string is a no-op, so no worries. :-)

    -Ken

  16. Re: Divining the full pathname of a file, all logicals translated

    Antonio Carlini wrote:
    >
    > David J Dachtera wrote in
    > news:47E1C21E.953D8662@spam.comcast.net:
    >
    > > Antonio's solution will work, of course.
    > >
    > > Myself, I'd lean toward Rich Gilbert's idea of simply reducing "][" out
    > > of the string unconditionally:

    >
    > So would I now that I see how obvious it is :-)
    >
    > Too much Perl and Ruby lately I guess !


    I just had a conversation yesterday with a Cerner AIX guy who still does
    some VMS. He said he found DCL harder to code in then shell scripting.

    *SIGH*

    David J Dachtera
    (formerly dba) DJE Systems

  17. Re: Divining the full pathname of a file, all logicals translated

    David J Dachtera wrote:
    > Antonio Carlini wrote:
    >
    >>David J Dachtera wrote in
    >>news:47E1C21E.953D8662@spam.comcast.net:
    >>
    >>
    >>>Antonio's solution will work, of course.
    >>>
    >>>Myself, I'd lean toward Rich Gilbert's idea of simply reducing "][" out
    >>>of the string unconditionally:

    >>
    >>So would I now that I see how obvious it is :-)
    >>
    >>Too much Perl and Ruby lately I guess !

    >
    >
    > I just had a conversation yesterday with a Cerner AIX guy who still does
    > some VMS. He said he found DCL harder to code in then shell scripting.
    >
    > *SIGH*


    I think that all that proves is that you can grow accustomed to
    anything! I can do either DCL or shell but I find DCL easier even
    though it requires more typing.




  18. Re: Divining the full pathname of a file, all logicals translated

    In article <692bd5d0-fcdc-4df7-9279-1955a49d7022@e23g2000prf.googlegroups.com>, Ken.Fairfield@gmail.com writes:
    > $ string = string - "][" - "]<" - ">[" - "><"
    >
    >That pretty much covers all cases. And "subtracting" a substring
    >that doesn't exist from another string is a no-op, so no worries. :-)


    But you should worry about a directory with mixed brackets as result

    $ DIR DSA0:[SYS0.SYSCOMMON.SYSMGR>
    %DCL-W-DIRECT, invalid directory syntax - check brackets and other delimiters
    \DSA0:[SYS0.SYSCOMMON.SYSMGR\

    $ DIR DSA0:[SYS0.SYSCOMMON.]

    Directory DSA0:[SYS0.SYSCOMMON.]
    ....

    So, better keep it string = string - "]["

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

  19. Re: Divining the full pathname of a file, all logicals translated

    On Mar 20, 5:16 pm, AEF wrote:
    > On Mar 19, 5:41 pm, Rich Jordan wrote:
    >
    >
    >
    > > I'm looking at ways to generate the full "low level" pathname to a
    > > file with no logicals, concealed, terminal, or otherwise involved, and
    > > in standard format.

    >
    > > So far the way that seems to work closest to what I need using only
    > > VMS provided tools follows. THis is (currently) a DCL command
    > > procedure searching multiple directories (using F$SEARCH with a
    > > wildcard, and generally with a logical in the search term):

    >
    > > - F$SEARCH returns the filename.
    > > - The return from F$SEARCH will already have translated non-
    > > terminal logicals; for example in the SYSTEM account searching for SYS
    > > $LOGIN:LOGIN.COM returns SYS$COMMON:[SYSMGR]LOGIN.COM;12

    >
    > > - Take the output of F$SEARCH and feed it to F$PARSE with
    > > argument "NO_CONCEAL" as the parse type.

    >
    > > This returns:

    >
    > > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12

    >
    > > Thats workable but I really need it to be normalized as

    >
    > > NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12

    >
    > Why, pray tell? If you *really* need it this way, just subtract all
    > possible combinations of square and angle brackets. (I think that's
    > pretty safe, but unanticipated situations and upgrades can break
    > manual parsing in general.) I assume you're writing about files on an
    > ODS-2 volume, right? You might get into trouble doing this on an ODS-5
    > volume, but I'm not sure.
    >
    >
    >
    > > I can put in conditional code to clean up the f$parse output but I'd
    > > rather find a way to have the clean pathname returned. Is there a way
    > > to do this using normal lexical functions?

    >
    > > =====

    >
    > > One other alternative seems to be to use one of the FID to NAME
    > > programs; since I can locate the file in question I have its FID and
    > > can run it through a program (seen online here in COV, also perhaps on
    > > freeware) and get the full raw pathname back. That would be
    > > acceptable too but if anyone's done it and has recommendations I'd
    > > appreciate hearing back. It would mean many thousands of image
    > > activations running the FID to Name program.

    >
    > Peter Weaver answered this. But why is it so important to remove the "]
    > ["?
    >
    > AEF
    >


    Currently ODS-2 and virtually certain to remain so. The full
    pathnames are being recorded and although VMS utilities handle the
    various permutations of divided directory paths properly, a
    prospective program that uses the archives may not, especially if its
    used or needed by people unfamiliar with VMS filename syntax. I want
    to make the archived info as uniform and straightforward as possible
    to avoid any future problems.

    If I have to deal with the divided directory paths and multiple
    directory path delimiters I will but it complicates the code; I'm just
    seeing if there's a better way than doing it manually. Apparently
    there is but only in later versions of VMS for DCL, or by using a
    called program.

  20. Re: Divining the full pathname of a file, all logicals translated

    On Mar 22, 9:42*pm, Rich Jordan wrote:
    > On Mar 20, 5:16 pm, AEF wrote:
    > > On Mar 19, 5:41 pm, Rich Jordan wrote:

    >
    > > > I'm looking at ways to generate the full "low level" pathname to a
    > > > file with no logicals, concealed, terminal, or otherwise involved, and
    > > > in standard format.


    I hear that and believe it to be a flawed requirement which will lead
    bad decision.
    concealed logical are defined for a reason. Respect that.
    Specifically you do NOT want to go back down to the physical device...
    IMHO of course.
    What if the DKA controller is gonzo but DKB works fine?
    What if you restore the data to a different place?
    Maybe to a DGA or DRA? I guess you could restore to $x$DGA1234:
    [DKA100] and then define a (concealed! :-) logical DKA100 to point to
    that huh?


    > > > * * *NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12
    > > > * * *NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12


    > > Why, pray tell? If you *really* need it this way, just subtract all
    > > possible combinations of square and angle brackets.


    Just subtract the "][" if you have to.

    I uses to be one of the first to shout 'not clean: what about the "<>"
    directories', trying to show off.
    Nonsense. nobody uses that, and you know whether your target system
    uses them. It doesn't.
    If some application actually does use those, then it deserves to
    fail.... IMHO of course.


    > > > I can put in conditional code to clean up the f$parse output but I'd
    > > > rather find a way to have the clean pathname returned. *Is there a way
    > > > to do this using normal lexical functions?


    An unconditional - "][" on the same line as the parse, right after it
    will do fine.

    > > > One other alternative seems to be to use one of the FID to NAME
    > > > programs; since I can locate the file in question I have its FID and


    I don't think that is reasonable.
    FID_TO_NAME is a 'best effort'.
    It does not know how the script foudn the file, it only tries to
    figure out how somene could find the file.
    To wit:

    $ dir /file/nohead/notrail/wid=file=40 sys$system:show.exe
    SYS$COMMON:[SYSEXE]SHOW.EXE;1 (37406,57,0)
    $ WRITE SYS$OUTPUT F$FID_TO_NAME("SYS$SYSDEVICE","(37406,57,0)")
    DISK$ALPHASYS:[VMS$COMMON.SYSEXE]SHOW.EXE;1
    $ WRITE SYS$OUTPUT F$PARSE(F$FID_TO_NAME("SYS
    $SYSDEVICE","(37406,57,0)"),,,,"NO_CONCEAL")
    EISNER$DRA0:[VMS$COMMON.SYSEXE]SHOW.EXE;1
    $ WRITE SYS$OUTPUT F$PARSE(f$search("sys
    $system:show.exe"),,,,"NO_CONCEAL") - "]["
    EISNER$DRA0:[SYS0.SYSCOMMON.SYSEXE]SHOW.EXE;1


    > > > can run it through a program (seen online here in COV, also perhaps on
    > > > freeware) and get the full raw pathname back. *That would be
    > > > acceptable too but if anyone's done it and has recommendations I'd
    > > > appreciate hearing back. *It would mean many thousands of image
    > > > activations running the FID to Name program.


    I made a program to do just that. Included below.
    The bigger performance overhead is more likely from back-tracing
    FID --> header: DID --> directory header.DID ... --> DID = (4,4,0)
    The program is in C, so its activation will be more work than a simple
    MACRO version.
    I almost started to recode. However: "Anything not worth doing is not
    worth doing well"

    > prospective program that uses the archives may not, especially if its
    > used or needed by people unfamiliar with VMS filename syntax.


    I fear you'll end up with something neither the OpenVMS folks, nor the
    new guard understands.
    my sample FID_TO_NAME program below.
    In the context I needed it, I had the FID pieces already. so it takes
    those as seperate arguments.
    Wouldn't take too long to make it parse '(x,y,z)'.

    $fid_name :== "$my_tools:fid_to_name " ! ** CHANGE **
    :
    $ file_name=f$fid_name(FILE_ID_DEVICE,file_id) ! V8
    $!7.3-2 fid_to_name 'FILE_ID_DEVICE' 'file_id_low' 'file_id_mid'
    'file_id_hi' file_name


    Cheers,
    Hein.

    /*
    ** fid_to_name.c Hein van den Heuvel, 2007
    **
    ** Usage: Define as external DCL command and pass filespec as param.
    ** Result: DCL Symbol defined with filename as value
    ** $fid_to_name device index-lo sequence index-hi symbol
    */

    #include
    #include
    #include

    void set_symbol(char *symbol, char *value)
    {
    void lib$set_symbol();
    struct {int len; char *addr;} symbol_desc, value_desc;
    symbol_desc.addr = symbol;
    symbol_desc.len = strlen(symbol);
    value_desc.addr = value;
    value_desc.len = strlen (value);
    lib$set_symbol ( &symbol_desc, &value_desc);
    }

    main (int argc, char *argv[])
    {

    char device_name[128],file_name[256];
    int i, s, lib$fid_to_name();
    short fid[4];
    struct {int len; char *addr;} device_name_desc, file_name_desc;
    if (6 != argc) {
    printf ("Usage: $fid_to_name device index-lo sequence index-hi
    symbol\n");
    printf (" index-lo : fid-word-0, 16 lsb bits for file-id\n");
    printf (" index-hi : fid-word-2, 8 msb bits for file-id plus rvn
    byte\n");
    printf (" Symbol : DCL symbol to be defined with resulting
    filespec\n");
    exit (16);
    }
    device_name_desc.addr = argv[1];
    device_name_desc.len = strlen(argv[1]);
    file_name_desc.addr = file_name;
    file_name_desc.len = sizeof file_name - 1;
    fid[0] = atoi ( argv[2] );
    fid[1] = atoi ( argv[3] );
    fid[2] = atoi ( argv[4] );
    s = lib$fid_to_name ( &device_name_desc, &fid, &file_name_desc,
    &fid[3] );
    file_name[ fid[3] ] = 0;
    set_symbol ( argv[5], file_name );
    }


+ Reply to Thread
Page 1 of 2 1 2 LastLast