Page 1 of 1

Need to find Obsolete (dynamically loaded) PROC from JCLs

PostPosted: Fri Feb 24, 2017 2:53 pm
by xgdot001
Hello,

Our system has a bunch of jobs (JCLs) that call programs which themselves call programs,...
I need to list programs that are NOT called in any jobs.

I saw the post from mohdmustafa__m (11/2013)
"Need to find Obsolete PROC from JCLs"

... but my case is somewhat different: I cannot do a static code analysis because some programs are 'dynamically bound'.
The program to be called depends on the result of a calculation, a value in a file,...

Question:
Is there a way to track (log) the programs that are executed (loaded) at runtime?
If yes, I would be logging that info for a "representative period of time"... and thus identify programs that are 'never' used in a batch context.

I know there is a (system) log for CICS which logs things such as 'Resource definition for PGMXXX has been autoinstalled using model YYYYY'
... and since, in our system, CICS are restarted every day, collecting theses logs every day give me which programs are used in CICS every day.

Question is thus, is there something similar for batch (subsystems) ?

Thx for your answers...

Re: Need to find Obsolete (dynamically loaded) PROC from JCL

PostPosted: Fri Feb 24, 2017 9:14 pm
by Robert Sample
The SMF record type 30 records the program being executed for a step. However, I don't believe that it will give you any subprograms (whether called statically or dynamically), just the main program. So that's a start, but you cannot say that programs not referenced in a job are not being used -- they could be called from another program many times without the system indicating that.

Re: Need to find Obsolete (dynamically loaded) PROC from JCL

PostPosted: Fri Feb 24, 2017 10:52 pm
by enrico-sorichetti
unfortunately before the final cleanup You will have to wait
at least for the longest run cycle to catch all the loaded modules

Re: Need to find Obsolete (dynamically loaded) PROC from JCL

PostPosted: Sat Feb 25, 2017 11:22 pm
by prino
There is a system, it's called "Clean the Fan". You simply move all programs that are not referenced anywhere in JCL to a separate load library, and every time the brown stuff hits that fan, because something's abending, you move the missing load module back.

Re: Need to find Obsolete (dynamically loaded) PROC from JCL

PostPosted: Mon Feb 27, 2017 1:29 pm
by xgdot001
Thank you for your answers: I truly appreciate all your insights.
@Robert:
  • the most important is indeed to identify the sub-programs: we can already list the main (entry) programs... we will dig into SMF record type 30 and see what we can have from there (keeping yo up to date)
  • yes, the conclusion can only be "this program is used"... and these not in the list "may not be used" (but this will be a starting point for a "second round" analysis)

@Enrico:
I'm not sure to understand: waiting is not an issue... but how can I catch the loaded modules (sub-programs)?
You seem to indicate a "final cleanup" that would dump that info. If yes, could you elaborate (is there some flag to set, how to get that log?)

@Prino:
This approach is not affordable to us: we would abend much too much... and even potentially during a large period time (since sub-programs are called based on calculation,...)

... continuing my investigations...

Re: Need to find Obsolete (dynamically loaded) PROC from JCL

PostPosted: Mon Feb 27, 2017 6:29 pm
by willy jensen
You do not say so, but I get the idea that you are looking for freeware. To the best of my knowledge there isn't one. I know that Serena markets a product called 'Changeman SSM' which can report on members loaded when and by who. There are alternatives, but no free ones.

Re: Need to find Obsolete (dynamically loaded) PROC from JCL

PostPosted: Fri Mar 03, 2017 12:50 pm
by xgdot001
@Willy
Thank you for opening our (my) mind: I was initially not considering an 'external' tool (being free or not)... and I was only looking to the problem with the "sysadmin" glasses.
It happens that we have Changeman SSM installed... and I start investigating that path too