If you can locate the ISPF panel(s) that allow setting of the log
options, you could have an installation-customized version of the panel
that eliminates all options but "3". To initially set up users, you
would either have to somehow "force" each user to select option "3" or
locate and change the appropriate character in their profile dataset to
set that lock option (hint, the field values are a letter, not the
digits 1-4).
But,...
if your intent is for this to be an audit trail, not a diagnostic tool,
forget it. Any sequential dataset that the user can create and log
records to, he can also wipe records from. Also I don't think there is
any easy way you can prevent the user from using "LOG KEEP" to create a
new log file and then just completely deleting the old LOG. One would
have to assume that any user savvy enough to be a risk requiring an
audit trail would also be savvy enough to purge any incriminating ISPF
log entries. Also you would have to daily offload and purge the log
datasets if using option 3, to avoid them filling up.
We have one case where we have used ISPF LOG retention: One marginally
trained, clerical-type, ISPF user was periodically complaining she had
created some PDS member months ago and it had since disappeared. SMF
data showed no one else touching the dataset. To track down what was
really going on, we forced the user's profile into LOG mode "4" (to
avoid one dataset filling up), implemented a nightly batch process using
batch REXX to archive all the user's daily LOG files into a daily GDG
and delete old LOG files, and modified an installation edit macro that
is invoked on entering EDIT or VIEW to create an ISPF LOG entry with the
dataset/member name (ISPF by default creates a log entry only when a
member is saved). Now if a similar complaint occurs, we can verify
whether the described member ever was really edited, and if so, whether
it was ever saved. We also suggested (once again) several possible ways
the user could have failed to save their data. Amazingly enough the
problem has yet to re-occur now that the user knows logging is in place.
Another problem with ISPF logging is that the data is very limited
(e.g., no data on panels used or panel field values), so unless you have
installation dialogs written to log things of interest, you get a very
limited view of what went on in the ISPF session. This feature appears
to be intended more for logging diagnostic information than for an
activity audit trail.
Jacky Bright wrote:
Like deletion of TSO datasets. Issuing TSO commands etc.
These activities are recorded in log dataset when user logs off from the
system
dataset name like <user>.SPFLOG1.LIST
When user logs off user gets following option
1. Print data set and delete
2. Delete data set without printing
3. Keep data set - Same
(allocate same data set in next session)
4. Keep data set - New
(allocate new data set in next session)
I want to disable 1 , 2 and 4 option.
JAcky
On 2/14/07, Binyamin Dissen <[EMAIL PROTECTED]> wrote:
On Wed, 14 Feb 2007 12:28:28 +0530 Jacky Bright <[EMAIL PROTECTED]>
wrote:
:>I want to force all my TSO users to keep TSO Log dataset so that
activities
:>carried out by all TSO users can be recorded.
What activities?
:>AS of now all users are able to delete the datasets while logging off
from
:>the system.
Also during the run.
The also can turn off logging.
:>How to configure this ?
What data are you truly trying to collect?
--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
