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

On Apr 11, 10:01 pm, AEF <spamsink2...@xxxxxxxxx> wrote:
On Mar 24, 4:27 pm, Rich Jordan <jor...@xxxxxxxxxxx> 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.
.

Relevant Pages

  • Re: Divining the full pathname of a file, all logicals translated
    ... What do you use to create a hash code for files in the directory? ... compare it to the "current" state when an audit report is run. ... The auditors may never see the actual database. ...
    (comp.os.vms)
  • Re: Access 2000: Version comparison
    ... In this database, there is one table with about 150 ... >them in the report, and do the same from the backup so she can compare the ...
    (microsoft.public.access.modulesdaovba)
  • Re: Access 2000: Version comparison
    ... >>My boss wants to ensure that data entered into this database is correct ... >>them in the report, and do the same from the backup so she can compare the ...
    (microsoft.public.access.modulesdaovba)
  • Access 2000: Version comparison
    ... My boss wants to ensure that data entered into this database is correct ... - The report should take the fields that were updated in the "live" db, ... and do the same from the backup so she can compare the ...
    (microsoft.public.access.modulesdaovba)
  • RE: updated numbers in report
    ... for making an input to the database. ... textbox will be located alongside with the combobox where the belonging ... belonging query for the report. ... ElapsedTime([Date First Time Onboard], ...
    (microsoft.public.access.dataaccess.pages)