Yes it is important to the organization, but since apparently no SMF record has 
this information for dynamically LOADed programs there is no real point to 
asking for DAF or any other SMF reporting tool to be used.

Knowing the module name loaded is kind of the point - that's what we need to 
know.  There are very few application load libraries but many thousands and 
more of programs and more than that in jobs using those programs all day long 
and all night long.

Not having any keys to the system programmer kingdom I would not have any 
access to a test system even if I knew it existed.  And a test system would 
probably not be very much help anyway due to the large number of potential 
main-program users of the subroutines that would need to be individually tested 
one at a time.  This is a need to get LOAD information for several shop-wide 
utility subroutines potentially used across the enterprise.  It is a 
needle-in-a-haystack problem to find the one place that a seldom-used but 
possibly critical utility routine is actually used at run time.  Sometimes 
actual use of a utility routine is data dependent, and you may or may not have 
the data available to drive particular program usage at any given time.

As several fictional characters in the entertainment world have opined, "It's 
complicated".

Having LOADed program statistics in SMF historical data would, of course, solve 
the problem immediately, but we don't have those.

Thanks for the suggestions and for trying to help.  Appreciated.

Peter

>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of retired mainframer
>Sent: Wednesday, August 09, 2017 1:06 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Any SMF statistics available for LOAD of a program?
>
>If the problem you are trying to solve is important to the organization, ask 
>the people who can run DAF for what you need and let them sanitize the output 
>for you.

>Alternately, if the number of libraries containing the modules in question is 
>not too large and you can convince the security admins to help, you could 
>create dataset profiles for the libraries in WARNING mode with access NONE.
>Every load would then generate a message in the system log.  It wouldn't tell 
>you which module was loaded but it would tell you which library was being 
>accessed by which job step.
>
>For a brute force method, if you have a test system you can use, recreate the 
>libraries without the members.  As each LOAD fails, add that member.
>When the jobs finally run successfully, any members not added are likely 
>unused.
>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Farley, Peter x23353
>> Sent: Wednesday, August 09, 2017 8:02 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Any SMF statistics available for LOAD of a program?
>> 
>> Unfortunately I have no access to any SMF data here and I am 
>> prohibited from running DCOLLECT for myself by security rules, so DAF while 
>> no doubt useful to others is not much use to me here.
>> 
>> These are old dynamically LOADed and called COBOL subroutines that we 
>> are not sure of the actual usage.  If they ever do get LOADed and called 
>> they will 
>> DISPLAY identifying information in SYSOUT, but that then requires reading 
>> the SYSOUT  archive extensively to determine whether they were ever actually 
>> used.  That also only  answers the question of
>> usage for as far back as the SYSOUT archive holds, which can be an 
>> issue if actual usage is (for instance) yearly or less often.
>> 
>> Archive scanning is tedious but doable.  My initial request was part 
>> of  deciding whether we need to use the tedious path or not.

--

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

Reply via email to