Page 1 of 1

TSO inactive LOGON proc's

PostPosted: Tue May 29, 2012 12:15 am
by Viswanathchandru
Dear all,

In my shop I can find lot of LOGON PROC'S created(not sure whether all are RACF'd). Out of which i'm not prety much sure what are all the logon proc being used. I'm sure not all the proc's are being used since something are just backups of the exsisting Proc's. Is there a way i can list the active logon proc's. Any suggestions or advice would be appreciated. Not sure whether this is the correct place to ask the question if not please transfer the topic to the correct place. Apologize if i or my thoughts are wrong.


Regards,
Viswa

Re: TSO inactive LOGON proc's

PostPosted: Tue May 29, 2012 12:20 am
by NicC
Generally your everday logon person will use a standard logon script and JCL and only specific IDs may have special JCL or script. As a result you shouldn't find all that many. If you did not know this then you probably should not be doing what you are doing. If you are meant to be doing it then go to your TSO administrators and ask about the setup in use in your shop.

Re: TSO inactive LOGON proc's

PostPosted: Tue May 29, 2012 8:59 pm
by dick scherrer
Hello,

If you explain why this is now a concern, we may be able to provide some suggestions.

Re: TSO inactive LOGON proc's

PostPosted: Tue May 29, 2012 9:47 pm
by Pedro
(my site has a customized way to save profile information, so I cannot test the 'normal' method).

I think someone with the correct authority can issue a LISTUSER command to display the TSO information for each user.
LISTUSER * TSO

The command response should contain the logon procedure name set for each user.

Re: TSO inactive LOGON proc's

PostPosted: Tue May 29, 2012 10:09 pm
by steve-myers
Pedro's solution will show the current default logon proc for each user in the middle of a massive amount of noise. Another problem is it will not show what might appear to be logon procs used to run TSO in batch.

I had thought of a similar solution using RACF in a different way, but it, too, had a noise problem (though not as bad) and it also had the batch problem.

I concluded this exercise was not worth the effort. The "cost" of an unused LOGON proc is too low to justify a mass delete, coupled with the high cost of recreating a deleted, but not unused LOGON proc.