X-no-Archive:yes
What Tracy said.

It depends on the file. If it's a text file or a web page, then, yes, I want
to know when it was read. If it is source code, I want to know when it was
compiled (although one could, with non-trivial effort, possibly prevent
standard command-line compilation, and enforce use of a version control
system). If it's a job or command file, I want to know when it was last
executed. It is far less useful to know that something happened to access
the file on a given date, but that may have only been a diff / compare, or a
grep / string search, or a PRINT just to see "what is this file?". And all
of this for reasons already stated, to manage what is on the system, and
whether or not it is being used.

Furthermore, if it is any kind of file at all, I want to know when a file of
that name was created. Period. I realize there is NO GOOD way around this,
if someone purges the file first. But I would want to know how long a
binary, a work file, an IMAGE file, ANY file, has lived on my system, and
when it was last modified, and when it was last accessed, for the reasons
given. For instance, if a job creates a work file of data from an IMAGE
dataset, or I have a KSAM file, and one day, that record length changes,
then I believe my only option is to rebuild the file with the new length
(allowing that there may be certain options for certain, but not all, cases
of this). I want to be able to see and know that on this date, when this
record length changed, and the following copybook(s) were also affected,
this dataset, KSAM or work file(s) was also changed. By managing these and
avoiding purge / builds, I probably do not need to change any jobs. Where I
keep old copies, I rename / move the original to its holding group or backup
name, and then copy it back to the regular name, to preserve the information
from the older generation of the file.

The paradox is, that on better managed and well used systems, this
information is more available, and less useful because it is less likely to
be needed. And on poorly managed and abused systems, this information will
probably not be available.

I had the displeasure of being in a shop with an "overstuffed" 3000, which
hosted both production and its development, with NO blueprint whatsoever for
distinguishing between which was which. There was a hodgepodge of old and
new code, and test and temp files, and "recovery" jobs. LISTF @[log in to unmask]@ was a
disappointing experience. Why was any given file TEMP? No one could be sure.
And we had MPEX, but very little understanding of what it could have done
for us, had we but used it. Still, it was late in the game. At best, we
could have begun managing these issues better, but there was already too
much loss of information.

As it is, I would have to work around MPE's way of handling file times. Much
of this, I can live with and work around. It's a fundamental part of the OS,
so I do not expect it to change. But I have wished more than once that it
could change, or at least be much, much easier. And this little nit is
pretty much the only thing I do not like about MPE, perhaps because I have
little hope of it being remedied. There are things I don't like, like the
less than complete integration of HFS / POSIX and MPE / CI, but I think that
could be remedied.

Greg Stigers
http://www.cgiusa.com

-----Original Message-----
From: Steve Dirickson (Volt) [mailto:[log in to unmask]]
Sent: Thursday, July 05, 2001 6:13 PM
To: [log in to unmask]
Subject: Re: Setup security within an account?

> access time, but there is no MPE way that I've found to
> directly view or
> grep a file without MPE considering it being accessed. So,

OK, I'll bite: why should viewing the file not be considered as an
access?

The only significant fault I've found in MPE's handling of file dates is
that copied files don't get the same datestamps as the original.
Although the current handling might fit into a strict, blind
interpretation of "creating a copy", it doesn't match with what we see
on most other systems.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *