When there are only specific load modules in specific libraries for
which tracking is needed, there IS an approach that does not require any
fancy new measurement tools or software, but does require cooperation
from the RACF administrator. It is possible to set up RACF Program
profiles specific to the load modules and libraries in question, not to
restrict access to the load modules, but to allow the enabling of RACF
auditing of all access to the modules, which results in generation of
RACF SMF records when access occurs. It's been some time since I've
done this (for some modules that were an issue during Y2K remediation),
but I'm pretty sure RACF auditing can be set to cut a record for any
module access, initial program load or dynamic fetch. Those RACF SMF
records can be extracted and accumulated for what is deemed a sufficient
period of time. Although not elegant, RACF also includes standard
reporting tools that will format and list information from the RACF SMF
records.
You will of course have to make a judgment of how long a period (days,
months, years) RACF SMF data must continue to be collected and analyzed
before there is a high confidence all important references have been
occurred and been recorded.
If RACF Program profiles are not already in use at the installation, one
must of course be careful to set things up properly to preserve existing
default access before enabling.
Joel C. Ewing
On 08/09/2017 01:10 PM, Farley, Peter x23353 wrote:
> 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.
> --
>
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
