I recently had to do a similar research function like this one, I found you have to use whatever data you can glean from your batch scheduler (at a minimum), and even then you can miss PROC's used by STC's started at IPL rather than by a scheduler as well as "on demand" jobs requested outside of the scheduler.
SORT JOINKEYS is your very good friend for this effort. Use your SCLM to identify which PROC's are used by which jobs (the XREF product from DCMS, Inc. [https:// www.dcmsi.com] does an excellent job at that task), match the job names against the scheduled jobs list and if there are no matches then try to find who last touched the PROC in your SCLM and ask that person / team tell you if it is obsolete or not. It doesn't cover 100% of cases but it will catch most of them. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Carmen Vitullo Sent: Thursday, April 14, 2022 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: System Proclibs, Member management EXTERNAL EMAIL Prolly wandering somewhat off topic... Lionel sez; "but if you do it under an official change control process at least you've documented what you're doing and received official approval for doing it." At a former shop that was the only way application proclibs and jcl members were added updated and deleted, using CA-LIBRARIAN and their CCF, still not 100% because you are still relying on the applications programmers to manage the PROC's and JCL but it was much more manageable and easy to restore back, the ownership of the process then was the change management team, something nowadays has gone the way of the dinosaur Carmen On 4/14/2022 9:47 AM, Lionel B. Dyck wrote: > There is always the approach of making a copy and then deleting - or just > renaming suspect members and waiting for the fallout. > > This can be dangerous but if you do it under an official change control > process at least you've documented what you're doing and received official > approval for doing it. Is it worth the effort - only if you really need to > recover the disk space, which is doubtful at this point in time. > > Plus these old/obsolete elements may prove useful, if only as examples to > work from at some point. > > > Lionel B. Dyck <>< > Website:https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!agrnuavPffXJPLatRvFxIDSsMzsN5ua6ra97mWgAxdtXTQWFPs7lF6C-zcovTZ_vHt2weA$ > > Github:https://urldefense.com/v3/__https://github.com/lbdyck__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!agrnuavPffXJPLatRvFxIDSsMzsN5ua6ra97mWgAxdtXTQWFPs7lF6C-zcovTZ_C2xcklA$ > > > “Worry more about your character than your reputation. Character is what you > are, reputation merely what others think you are.” - - - John Wooden > > -----Original Message----- > From: IBM Mainframe Discussion List<IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Radoslaw Skorupka > Sent: Thursday, April 14, 2022 09:38 AM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: System Proclibs, Member management > > My humble opinion: NO. No way. > I have seen discussion about tracking library access, hopefully at member > level. > So what? > Let's imagine member ABC has not been touched for 5 months. > Can you delete it? > No, you are not sure about half-year or once-a-year processes. > > Of course, detailed report of recently read members allows you to eliminate > majority (or minority?) of members in the library. > However the rest has to be manually checked. And this is less technical, more > organizational task. You have to find an owner or at least a person who knows > anything about given member and talk to him. > > My €0.02 > > > BTW: I have found a member dated on 1981 recently. Fortunately I'm pretty > sure it is just a piece of junk nowadays. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > W dniu 12.04.2022 o 16:41, Mark Jacobs pisze: >> Does anyone do this in other than a manual method? Deletion of obsolete >> members and like things. If so, can you share your methods? >> Mark Jacobs > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- /I am not bound to win, but I am bound to be true. I am not bound to succeed, but I am bound to live by the light that I have. I must stand with anybody that stands right, and stand with him while he is right, and part with him when he goes wrong. *Abraham Lincoln*/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
