1: I'm being picky and technical, here - I'm sure you both know this - but the TSO segment's PROC value doesn't tell me what was last used, nor what procs are allowed, only what would be the default proc the next time the user logs on. (Maybe RACF checks the proc's ACL before allowing PROC to be set; I'm not sure.) Still, I agree with Radek that practically speaking it's a great indication of what procs are in use.
2: VIPs (we're talking about corporate upper management, right?) almost never use the mainframe, and even when they use it they almost never need to. Many of them don't even have an ID, and if they were assigned one it's only because they're "important". I'm not much worried about surprises from them. Still, there are IDs that get used only for quarter- or year-end functions. But they're covered by #1, aren't they? If this were my task, and if we didn't have some product like CA-CLEANUP running so that I could see for sure what logon procs had been used in the last 18 months, I think I'd ask my boss to approve this plan: a) Examine the DBU for all the IDs that can log on to TSO, and that have been used in the last 18 months, and record their PROC values. All those procs are to be considered in use. b) If you have time, by all means turn on AUDIT for the other PROCs and wait to see whether any of them are used. But I don't expect there'll be many surprises there. c) Once you've done that, disable the remainder for some test period, say two years. If during that period someone complains, turn it back on; you now know that one, too, is in use. But if there are 40 procs out there, and 18 of them are now disabled, you may have to restore zero, one or two of them. Politically speaking this is a small risk. d) Any proc that hasn't been used in two years you can safely discard. I'm tempted to add that you can post an announcement about the procs you propose to delete. But at some organizations the confusion and fear you get from the users as a result might outweigh the benefit. I'm a geek, and have never been politically savvy; I think I'd leave the decision about an announcement to my boss. --- Bob Bridges, [email protected], cell 336 382-7313 /* Don't be daunted and intimidated by the thought police. Despite what they'd have you believe, you are not a criminal. Stick to your principle; don't be afraid to unapologetically admit your belief in those corny old traditional values. Ultimately, this will get you respect. Once you have respect, then you will have the ability to persuade. That's the way to reclaim our culture. -from "See, I Told You So" by Rush Limbaugh */ -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Seymour J Metz Sent: Friday, May 20, 2022 07:13 1. TSO segments will only tell you what is allowed; you still need SMF to tell how often they are logging on. 2. What about logon procs used for an activity that is only needed at long intervals? ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Radoslaw Skorupka [[email protected]] Sent: Thursday, May 19, 2022 8:03 PM 1. Review users' TSO segments - you will find last logon procedure used. Of course you cannot exclude that some user likes to change his procedure every week, or just because of some needs. But this is unlikely. 2. Use RACF features like AUDIT. You will get SMF record everytime the procedure is used. Advice: first eliminate "popular" procedures because you already know they are used. Of course this method means change audit today and wait for results. How long? You have to decide. And again - you cannot exclude some VIP will logon using his favourite proc next month. 3. Look at SMF30. Create some report, omit the most popular names, etc. --- W dniu 16.05.2022 o 04:33, James C. pisze: > I needed to make a change to the logon procs but noticed that there were quite a few. I'd like to know which procs are actually being recently used. Does this information get recorded by SMF? If so, which record type? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
