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 ; On Mar 21, 1:33 pm, pe...@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) wrote: > In article , Ken.Fairfi...@gmail.com writes: > > > $ string = string - "][" - "] [" - "> > > >That pretty much covers all cases. And "subtracting" ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

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

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

    On Mar 21, 1:33 pm, pe...@langstoeger.at (Peter 'EPLAN' LANGSTOeGER)
    wrote:
    > In article <692bd5d0-fcdc-4df7-9279-1955a49d7...@e23g2000prf.googlegroups.com>, Ken.Fairfi...@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\


    Ah, you're absolutely correct. I suspect that where I actually
    used this,I also stripped the outer brackets and put them back
    after the subtraction. I don't have the DCL from when I did that,
    but now that you point this out, I seem to recall testing this
    case and making sure it worked...

    > $ DIR DSA0:[SYS0.SYSCOMMON.]
    >
    > Directory DSA0:[SYS0.SYSCOMMON.]
    > ...
    >
    > So, better keep it string = string - "]["


    If you're trying to create a root logical, you need to go
    all the way back to a device and full directory path, so
    there *are* reasons to do this.

    -Ken


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

    On Mar 22, 11:29 pm, Hein RMS van den Heuvel
    wrote:
    > 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 );
    >
    > }


    Hein,
    first, thanks for responding! T

    The fact of a location/device change would be considered
    noteworthy in this environment. A concealed logical would normally
    hide the fact that SYS$SYSDEVICE (and all the other SYS$... logicals)
    are now pointing somewhere else, as well as make the File ID also
    being stored useless for tracking that change, but with the device
    (part of that full path) those who wish to know will be informed by
    the programs' operation that:

    image yadayada.exe, File ID {12345,6,7), location changed;
    old location: NODE$DKA0:[SYS0.SYSCOMMON.SYSEXE]
    new location: NODE$DKB0:[SYS0.SYSCOMMON.SYSEXE]

    Only the generated database of file info has the full (canonical) path
    name of the file, and it also stores the file ID. The file ID is not
    of much use unless the base device is also identified, which mandates
    cutting through some concealed logicals (such as SYS$SYSROOT or SYS
    $COMMON, down to at least SYS$SYSDEVICE in the example above) in any
    case.

    The config file that tells the program which directories to scan uses
    normal syntax with logicals and all, so comparing a changed 'live'
    system to the stored info would catch the device name change and
    report it as required. If it scanned SYS$SYSTEM:*.EXE it could get
    the file IDs, pull that record from the database, compare the stored
    to the current path, and report the variance. If we stored only the
    logical path SYS$COMMON:[SYSEXE] or even SYS$SYSDEVICE:
    [SYS0.SYSCOMMON.SYSEXE] then we would not know that there had been a
    change (unless some other piece of stored and compared data showed
    that up).

    Having the F$FID_TO_NAME lexical return different results from using
    the FID versus the filename is interesting (and unfortunate, honestly)
    but its not an immediate issue since the system we're building on
    doesn't have that lexical. Too old. I believe the program you
    thoughtfully included is different from the other 'C' version I found;
    we'll give it a try.

    I appreciate your input, and in general agree with it, but in this
    specific case I really do need to get the raw pathnames.

    OBTW the comment about people unfamiliar with VMS syntax; I expect
    they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
    follow it since we'd be telling them. I'd prefer not to give them
    variances that might be confusing (extra "][" and missing ".") so it
    makes sense to use the most basic and consistent syntax in the stored
    information.

    Thanks!

    Rich

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

    Ken.Fairfield@gmail.com wrote:
    > 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


    Why not try the following? The idea is to translate DSK7. Note: with this
    routine, I believe that DSK7 could even point to a different disk than the
    one that SYS$LOGIN is on.

    We use THREE LEXICALS: f$parse, f$file_attributes, and f$fid_to_name .


    $ filename = "DSK7:[OPS.VNEWS.DEC.VNEWS]VNEWS.DOC"
    $ _device = f$parse(filename,,,"DEVICE","NO_CONCEAL")
    $ _id = f$file_att(filename,"FID")
    $ write sys$output f$fid(_device,_id)
    RAD1:[DATA.OPS.DSK7.OPS.VNEWS.DEC.VNEWS]VNEWS.DOC;1


    Notice how the above routine translated the DSK7 logical all
    the way back to the top-level directory on RAD1.

    .. fred bach ..

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

    On Apr 10, 5:08 pm, Fred Bach wrote:
    [...]
    > Why not try the following? The idea is to translate DSK7. Note: with this
    > routine, I believe that DSK7 could even point to a different disk than the
    > one that SYS$LOGIN is on.
    >
    > We use THREE LEXICALS: f$parse, f$file_attributes, and f$fid_to_name .
    >
    > $ filename = "DSK7:[OPS.VNEWS.DEC.VNEWS]VNEWS.DOC"
    > $ _device = f$parse(filename,,,"DEVICE","NO_CONCEAL")
    > $ _id = f$file_att(filename,"FID")
    > $ write sys$output f$fid(_device,_id)
    > RAD1:[DATA.OPS.DSK7.OPS.VNEWS.DEC.VNEWS]VNEWS.DOC;1


    1) To satisfy the OP, you still need to run F$Parse against this
    result
    (twice) to get the "path", i.e., device:[dir], to the file.

    2) We don't have F$Fid on V7.3-2 (and earlier)...

    -Ken


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

    Ken.Fairfield@gmail.com wrote:
    > On Apr 10, 5:08 pm, Fred Bach wrote:
    > [...]
    >> Why not try the following? The idea is to translate DSK7. Note: with this
    >> routine, I believe that DSK7 could even point to a different disk than the
    >> one that SYS$LOGIN is on.
    >>
    >> We use THREE LEXICALS: f$parse, f$file_attributes, and f$fid_to_name .
    >>
    >> $ filename = "DSK7:[OPS.VNEWS.DEC.VNEWS]VNEWS.DOC"
    >> $ _device = f$parse(filename,,,"DEVICE","NO_CONCEAL")
    >> $ _id = f$file_att(filename,"FID")
    >> $ write sys$output f$fid(_device,_id)
    >> RAD1:[DATA.OPS.DSK7.OPS.VNEWS.DEC.VNEWS]VNEWS.DOC;1

    >
    > 1) To satisfy the OP, you still need to run F$Parse against this
    > result
    > (twice) to get the "path", i.e., device:[dir], to the file.
    >
    > 2) We don't have F$Fid on V7.3-2 (and earlier)...
    >
    > -Ken
    >

    1) Yes indeed. We still have plenty of code here where we remove square brackets,
    code from earlier days. I was here long before VMS was born, although I believe
    that most of our DCL code was reworked after Rev 5. Just "subtracting" the brackets
    from the path string seemed quite a popular technique with other DCL coders here.
    I have been known to do it to when in a hurry, or use F$LOCATE for ".][" and then
    piece the directory string back together. Over time, quite a bit of my code was
    changed to use a series of F$PARSE statements to extract each portion of the path name.
    With the new technique above, as you say, we still need to use F$PARSE to get the
    individual fields, but I think it's cleaner and possibly more reliable.

    2) With the NO_CONCEAL directive, F$PARSE will translate logicals in the
    directory path:

    $ show logical dsk7
    "DSK7" = "RAD1:[DATA.OPS.DSK7.]" (LNM$PROCESS_TABLE)

    $ filename == "DSK7:[OPS.VNEWS.DEC.VNEWS]VNEWS.DOC;1"
    $ write sys$output f$parse(filename,,,"Directory","NO_CONCEAL")
    [DATA.OPS.DSK7.][OPS.VNEWS.DEC.VNEWS]

    and then you have to remove all the "][" character pairs in the string.
    I believe you could have more than one set .

    The device is not translated by F$PARSE without the "NO_CONCEAL" directive.
    However, if I use "NO_CONCEAL", RAD1: comes back as its physical device :

    $ write sys$output f$parse(filename,,,"DEVICE")
    DSK7:
    $ write sys$output f$parse(filename,,,"DEVICE","NO_CONCEAL")
    $1$DGA3:


    F$FID_TO_NAME comes back with RAD1 for the device. Just off hand I don't know a
    fast, clean way of translating $1$DGA3: back into RAD1: for V7.3-2 and earlier.


    .. fred bach ..

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

    On Mar 24, 4:27 pm, Rich Jordan wrote:
    [...]
    > OBTW the comment about people unfamiliar with VMS syntax; I expect
    > they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
    > follow it since we'd be telling them. I'd prefer not to give them
    > variances that might be confusing (extra "][" and missing ".") so it
    > makes sense to use the most basic and consistent syntax in the stored
    > information.
    >
    > Thanks!
    >
    > Rich


    Please, what are you trying to do? What is the purpose of this list?
    What are the users looking for when they use this list? What are they
    going to do with the file-spec when they find the one they want? Are
    they expected to retrieve the file from disk or tape? If so, why do
    they need the list? And how are they going to do anything with it if
    they don't have even a clue as to VMS file-specs? Etc.

    My apologies if I'm missing something obvious, but I have no clue as
    to what the point of all this is.

    If the OP is not following this thread anymore, I' asking anyone else
    who is to explain to me what the whole point of this is.

    As usual, without the original motivation it is difficult to come up
    with reasonably "optimized" (for lack of a better word I can't think
    of offhand) solution.

    Thanks!

    AEF

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

    On Apr 11, 10:01 pm, AEF wrote:
    > On Mar 24, 4:27 pm, Rich Jordan wrote:
    > [...]
    >
    > > OBTW the comment about people unfamiliar with VMS syntax; I expect
    > > they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
    > > follow it since we'd be telling them. I'd prefer not to give them
    > > variances that might be confusing (extra "][" and missing ".") so it
    > > makes sense to use the most basic and consistent syntax in the stored
    > > information.

    >
    > > Thanks!

    >
    > > Rich

    >
    > Please, what are you trying to do? What is the purpose of this list?
    > What are the users looking for when they use this list? What are they
    > going to do with the file-spec when they find the one they want? Are
    > they expected to retrieve the file from disk or tape? If so, why do
    > they need the list? And how are they going to do anything with it if
    > they don't have even a clue as to VMS file-specs? Etc.
    >
    > My apologies if I'm missing something obvious, but I have no clue as
    > to what the point of all this is.
    >
    > If the OP is not following this thread anymore, I' asking anyone else
    > who is to explain to me what the whole point of this is.
    >
    > As usual, without the original motivation it is difficult to come up
    > with reasonably "optimized" (for lack of a better word I can't think
    > of offhand) solution.
    >
    > Thanks!
    >
    > AEF


    Auditing changes to or moves of designated files for compliance to
    certain government regulations.

    A physical change of location (hidden by logicals) is still an
    auditable event requiring documentation. Hence the need to know the
    physical path at the time the audit database is generated, in order to
    compare it to the "current" state when an audit report is run. A hash
    of each file is retained, along with file create/modify timestamps and
    FID; the FID is only meaningful on a given logical drive unit so the
    drive name needs to be retained also, unmasked from any logicals.

    The auditors are (as expected) well trained in suboptimal operating
    systems like windows, but are not VMS-aware. Providing basic VMS file
    specification information is not a problem but avoiding potentially
    confusing variants such as paths with the embedded ][ is just a good
    thing to do. Normalizing the stored pathnames also makes later
    comparison and parsing more efficient and less likely to generate a
    'false positive' path change event.

    The auditors may never see the actual database. They will see a
    report generated comparing the current 'state' of the system against
    the archived state recorded in the database. The pathnames in that
    report will come from one or the other (or both) locations when an
    exception is noted.

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


    If the database contains filenames that were not parsed with no_conceal,
    then the online filename and the database filename need to be parsed with
    no_conceal to see if they match and if they do, don't generate an exception.

    Or maybe a table could be created using "Show Logical */table=*" that could
    be used to verify that such-and-such device is the same as such-and-such-other
    device.

    I didn't know about an f$fid_to_name(), but I can see that it would probably
    return the filename using the disk logical that the disk was mounted with.
    To see what the disk was mounted with use f$getdvi(disk,"logvolnam").


    Rich Jordan wrote:
    > On Apr 11, 10:01 pm, AEF wrote:
    >> On Mar 24, 4:27 pm, Rich Jordan wrote:
    >> [...]
    >>
    >>> OBTW the comment about people unfamiliar with VMS syntax; I expect
    >>> they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
    >>> follow it since we'd be telling them. I'd prefer not to give them
    >>> variances that might be confusing (extra "][" and missing ".") so it
    >>> makes sense to use the most basic and consistent syntax in the stored
    >>> information.
    >>> Thanks!
    >>> Rich

    >> Please, what are you trying to do? What is the purpose of this list?
    >> What are the users looking for when they use this list? What are they
    >> going to do with the file-spec when they find the one they want? Are
    >> they expected to retrieve the file from disk or tape? If so, why do
    >> they need the list? And how are they going to do anything with it if
    >> they don't have even a clue as to VMS file-specs? Etc.
    >>
    >> My apologies if I'm missing something obvious, but I have no clue as
    >> to what the point of all this is.
    >>
    >> If the OP is not following this thread anymore, I' asking anyone else
    >> who is to explain to me what the whole point of this is.
    >>
    >> As usual, without the original motivation it is difficult to come up
    >> with reasonably "optimized" (for lack of a better word I can't think
    >> of offhand) solution.
    >>
    >> Thanks!
    >>
    >> AEF

    >
    > Auditing changes to or moves of designated files for compliance to
    > certain government regulations.
    >
    > A physical change of location (hidden by logicals) is still an
    > auditable event requiring documentation. Hence the need to know the
    > physical path at the time the audit database is generated, in order to
    > compare it to the "current" state when an audit report is run. A hash
    > of each file is retained, along with file create/modify timestamps and
    > FID; the FID is only meaningful on a given logical drive unit so the
    > drive name needs to be retained also, unmasked from any logicals.
    >
    > The auditors are (as expected) well trained in suboptimal operating
    > systems like windows, but are not VMS-aware. Providing basic VMS file
    > specification information is not a problem but avoiding potentially
    > confusing variants such as paths with the embedded ][ is just a good
    > thing to do. Normalizing the stored pathnames also makes later
    > comparison and parsing more efficient and less likely to generate a
    > 'false positive' path change event.
    >
    > The auditors may never see the actual database. They will see a
    > report generated comparing the current 'state' of the system against
    > the archived state recorded in the database. The pathnames in that
    > report will come from one or the other (or both) locations when an
    > exception is noted.


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

    Hi again.

    What do you use to create a hash code for files in the [sys$ldr] directory?
    My thought was that they are mostly opened for exclusive access when the
    system is booted up and you would get a "file open by another user" type
    of error.



    Rich Jordan wrote:
    > On Apr 11, 10:01 pm, AEF wrote:
    >> On Mar 24, 4:27 pm, Rich Jordan wrote:
    >> [...]
    >>
    >>> OBTW the comment about people unfamiliar with VMS syntax; I expect
    >>> they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
    >>> follow it since we'd be telling them. I'd prefer not to give them
    >>> variances that might be confusing (extra "][" and missing ".") so it
    >>> makes sense to use the most basic and consistent syntax in the stored
    >>> information.
    >>> Thanks!
    >>> Rich

    >> Please, what are you trying to do? What is the purpose of this list?
    >> What are the users looking for when they use this list? What are they
    >> going to do with the file-spec when they find the one they want? Are
    >> they expected to retrieve the file from disk or tape? If so, why do
    >> they need the list? And how are they going to do anything with it if
    >> they don't have even a clue as to VMS file-specs? Etc.
    >>
    >> My apologies if I'm missing something obvious, but I have no clue as
    >> to what the point of all this is.
    >>
    >> If the OP is not following this thread anymore, I' asking anyone else
    >> who is to explain to me what the whole point of this is.
    >>
    >> As usual, without the original motivation it is difficult to come up
    >> with reasonably "optimized" (for lack of a better word I can't think
    >> of offhand) solution.
    >>
    >> Thanks!
    >>
    >> AEF

    >
    > Auditing changes to or moves of designated files for compliance to
    > certain government regulations.
    >
    > A physical change of location (hidden by logicals) is still an
    > auditable event requiring documentation. Hence the need to know the
    > physical path at the time the audit database is generated, in order to
    > compare it to the "current" state when an audit report is run. A hash
    > of each file is retained, along with file create/modify timestamps and
    > FID; the FID is only meaningful on a given logical drive unit so the
    > drive name needs to be retained also, unmasked from any logicals.
    >
    > The auditors are (as expected) well trained in suboptimal operating
    > systems like windows, but are not VMS-aware. Providing basic VMS file
    > specification information is not a problem but avoiding potentially
    > confusing variants such as paths with the embedded ][ is just a good
    > thing to do. Normalizing the stored pathnames also makes later
    > comparison and parsing more efficient and less likely to generate a
    > 'false positive' path change event.
    >
    > The auditors may never see the actual database. They will see a
    > report generated comparing the current 'state' of the system against
    > the archived state recorded in the database. The pathnames in that
    > report will come from one or the other (or both) locations when an
    > exception is noted.


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

    On Apr 14, 11:40 am, Rich Jordan wrote:
    > On Apr 11, 10:01 pm, AEF wrote:
    >
    >
    >
    > > On Mar 24, 4:27 pm, Rich Jordan wrote:
    > > [...]

    >
    > > > OBTW the comment about people unfamiliar with VMS syntax; I expect
    > > > they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
    > > > follow it since we'd be telling them. I'd prefer not to give them
    > > > variances that might be confusing (extra "][" and missing ".") so it
    > > > makes sense to use the most basic and consistent syntax in the stored
    > > > information.

    >
    > > > Thanks!

    >
    > > > Rich

    >
    > > Please, what are you trying to do? What is the purpose of this list?
    > > What are the users looking for when they use this list? What are they
    > > going to do with the file-spec when they find the one they want? Are
    > > they expected to retrieve the file from disk or tape? If so, why do
    > > they need the list? And how are they going to do anything with it if
    > > they don't have even a clue as to VMS file-specs? Etc.

    >
    > > My apologies if I'm missing something obvious, but I have no clue as
    > > to what the point of all this is.

    >
    > > If the OP is not following this thread anymore, I' asking anyone else
    > > who is to explain to me what the whole point of this is.

    >
    > > As usual, without the original motivation it is difficult to come up
    > > with reasonably "optimized" (for lack of a better word I can't think
    > > of offhand) solution.

    >
    > > Thanks!

    >
    > > AEF

    >
    > Auditing changes to or moves of designated files for compliance to
    > certain government regulations.
    >
    > A physical change of location (hidden by logicals) is still an
    > auditable event requiring documentation. Hence the need to know the


    So if a disk dies and you restore on another disk, that's auditable?

    > physical path at the time the audit database is generated, in order to
    > compare it to the "current" state when an audit report is run. A hash
    > of each file is retained, along with file create/modify timestamps and
    > FID; the FID is only meaningful on a given logical drive unit so the
    > drive name needs to be retained also, unmasked from any logicals.
    >
    > The auditors are (as expected) well trained in suboptimal operating
    > systems like windows, but are not VMS-aware. Providing basic VMS file


    Ah, so what we have here is auditing by the blind. A few short lessons
    in VMS seem in order here. Yes, I know, it's not up to you, and you
    need to do these silly things.

    And what's to prevent anyone from faking the report? Faking the
    modification dates, or the disk names? How would they even know you
    changed disks if your reported had the logical names. Just tell them
    the logical names are the disk names? How would they know?

    So these Blind Watchdogs are goind to save us from file manipulation
    shenanigans. Whatever.

    > specification information is not a problem but avoiding potentially
    > confusing variants such as paths with the embedded ][ is just a good
    > thing to do. Normalizing the stored pathnames also makes later
    > comparison and parsing more efficient and less likely to generate a
    > 'false positive' path change event.


    Tell then the logical names are the disks names and that would be yet
    more efficient! :-)

    >
    > The auditors may never see the actual database. They will see a
    > report generated comparing the current 'state' of the system against
    > the archived state recorded in the database. The pathnames in that
    > report will come from one or the other (or both) locations when an
    > exception is noted.


    And how are these Blind Auditors going to know the report is not
    fudged?

    Again, I lay no blame upon you. I'm just saying the entire situation
    seems a bit absurd to me.

    Thanks for clearing this up.

    AEF

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

    On Apr 14, 11:40 am, Rich Jordan wrote:
    > On Apr 11, 10:01 pm, AEF wrote:
    >
    >
    >
    > > On Mar 24, 4:27 pm, Rich Jordan wrote:
    > > [...]

    >
    > > > OBTW the comment about people unfamiliar with VMS syntax; I expect
    > > > they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
    > > > follow it since we'd be telling them. I'd prefer not to give them
    > > > variances that might be confusing (extra "][" and missing ".") so it
    > > > makes sense to use the most basic and consistent syntax in the stored
    > > > information.

    >
    > > > Thanks!

    >
    > > > Rich

    >
    > > Please, what are you trying to do? What is the purpose of this list?
    > > What are the users looking for when they use this list? What are they
    > > going to do with the file-spec when they find the one they want? Are
    > > they expected to retrieve the file from disk or tape? If so, why do
    > > they need the list? And how are they going to do anything with it if
    > > they don't have even a clue as to VMS file-specs? Etc.

    >
    > > My apologies if I'm missing something obvious, but I have no clue as
    > > to what the point of all this is.

    >
    > > If the OP is not following this thread anymore, I' asking anyone else
    > > who is to explain to me what the whole point of this is.

    >
    > > As usual, without the original motivation it is difficult to come up
    > > with reasonably "optimized" (for lack of a better word I can't think
    > > of offhand) solution.

    >
    > > Thanks!

    >
    > > AEF

    >
    > Auditing changes to or moves of designated files for compliance to
    > certain government regulations.
    >
    > A physical change of location (hidden by logicals) is still an
    > auditable event requiring documentation. Hence the need to know the


    Say what? What is the point of this? If the files don't change, who
    gives a f---?

    What's important is the path via which the files are accessed. If
    they're accessed from

    logical_name:[*...]

    then all that counts is if files under that set of paths changes or
    not. What possible difference could changing the physical disk make,
    and if you move to another disk, just document that. "I moved the
    files from disk A to disk B and they are still under logical name C."
    THAT would be EFFICIENT! You can still compare the files and run a new
    report and comparing reports and files (or hashes or whatever) would
    be easier and more efficient. What is the objections to a scheme like
    this?

    > physical path at the time the audit database is generated, in order to
    > compare it to the "current" state when an audit report is run. A hash
    > of each file is retained, along with file create/modify timestamps and
    > FID; the FID is only meaningful on a given logical drive unit so the
    > drive name needs to be retained also, unmasked from any logicals.


    What is the point of the FID unless the files are actually accessed
    via it?

    This whole thing seems needlessly complicated and taken to the level
    at which there are more important problems of trust to worry about.

    Again, I'm not blaming you for any of this.

    Thanks for clearing up the motivation of all this.

    AEF UPPERCASE AND PROUD OF IT!

    >
    > The auditors are (as expected) well trained in suboptimal operating
    > systems like windows, but are not VMS-aware. Providing basic VMS file
    > specification information is not a problem but avoiding potentially
    > confusing variants such as paths with the embedded ][ is just a good
    > thing to do. Normalizing the stored pathnames also makes later
    > comparison and parsing more efficient and less likely to generate a
    > 'false positive' path change event.
    >
    > The auditors may never see the actual database. They will see a
    > report generated comparing the current 'state' of the system against
    > the archived state recorded in the database. The pathnames in that
    > report will come from one or the other (or both) locations when an
    > exception is noted.



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2