Leo, We move the modules to a LNKLST library, so we are sure they are seen by LLA when they are fetched. Yes, CSVFETCH has more capabilities, but just for the task of catching certain, old, modules, the LLA trick is more simple.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: 23 March, 2016 18:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CSVFETCH exit Kees, The exit is called with the local lock held, so BPX4SMF wouldn't work, I couldn't find the requirements for SMFWTM but if that also doesn't like the exit's environment I guess you would have to do something like writing information to a dataspace and then get the data using another address space. Definitely more complex than what you have now. But you are comparing two different things; for example, CSVFETCH would get control if a user is fetching a module by steplib/joblib, which LLA EXIT2 wouldn't do. So your current solution doesn’t "determine if certain loadmodules are still being used", but rather if they are being fetched using LLA. Regards, Leo -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Wednesday, March 23, 2016 11:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CSVFETCH exit To determine if certain loadmodules are still being used, we use LLA EXIT2 since decades. We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches from this library and write an SMF record for the event. CSVFETCH apparently is able to catch more loads, provide more info, but also seems more complicated to use. As to the question, what can you do with the information CSVFETCH makes available: can I write an SMF record from CSVFETCH? Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: 21 March, 2016 14:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CSVFETCH exit I have a different question relative to this exit. I've been looking for doc on line and have found two manuals that have CSVFETCH as an exit point defined, and one has the parm area info. Peter did a presentation last week, and unfortunately for me, I had a hard conflict and couldn't attend, but I did get the "slide deck" and listened to the recording this morning. There is a question that I have, and hopefully someone here will have the answer (We have not yet set up 2.2 on a test LPAR, but we have it on a sandbox LPAR where I can play with it): Will a "fetch" of a CLIST or REXX be caught by this exit? At this point, I have not seen how one could tell a executable module from a "script" (script because one might need this on the POSIX side of the system). I could see using this exit in place of the SMF type 32 (with its overhead and tables in common...). Meanwhile, I see where this exit could help a shop determine what obsolete subroutines are being used in production... Regards, Steve Thompson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
