> -----Original Message-----
> From: Jay Chandru
>
> Unfortunately, everyone uses the same user. Isnt there any
> other way in
> which we can find the session id of the user who has overlaid
> the source.

*IF* you log FCLOSE events AND job init/terminate events, *THEN* there is a
possible way to get this information... [see below]

> Also isnt there any way in which i can get this from a log as
> to which all
> commands were executed by a user on a particular day.

Unless you have a custom ci.pub.sys that does this sort of logging, no.  MPE
doesn't log commands (I was going to suggest that the ".sh_history" file
might help if the user used the posix "shell", but them I realized everyone
SHARES the ".sh_history" file since they all use the same MPE user ID...)

The system logging events you are interested in are FCLOSE (105?), NM FCLOSE
(160?) and possibly FOPEN, (but that's somewhat redundant at this point) as
well as the JOB INIT record (type 102 I think).  The reason you need the job
init records is that all related records only contain the job/session ID,
not the full logon.  Tracing back to the matching job init record gives you
the logon information for that particular job/session.

Picking through these by hand (i.e., with logtool or sysdiag's log scanning
utility) will be tedious.  VEsoft has a little known command called LISTLOG
which allows you to search for specific events and automatically ties them
back to the session ID if the session ID is still in the log file(s)
scanned...  Part of the reason it is "little known" is that it isn't the
easiest to comprehend, and the other part is that it was built into the
VEAUDIT product rather than MPEX (however you need BOTH products to actually
use it)  With some carefull study of the expression programming used for
this, it is possible to make a report that truly "points the finger" at the
culprit  [I wrote such a command while I was there and called it
"did2file" -- it took a filename (or fileset) as a parameter, and reported
on everything that anyone "did" to the file... (copy, purge, etc.)]

Unfortunately, you need to have these logging events ENABLED prior to the
time when you suspect the file was overwritten -- turning on these events
now would be akin to closing the barn door after the horses have left...

(I'm reasonably certain you do NOT have the FCLOSE events enabled because
these are EXTREMELY common events and will fill your log file(s) VERY
quickly -- something like two or three FULL log files per day on a mid-sized
machine...)

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