Page 1 of 1

Analize the runing job

PostPosted: Mon Nov 12, 2018 3:30 pm
by maci84
Hi all!
Is there a method or a tool to check how many time the system works with a job on its each operation?
I mean I have only 1 step and it takes too much time to run down (I know that i can check the overall time, CPU time, CPU% and so on) But my idea is to check somehow what operations the job do (Which is defined in DD statements) and how many time it takes on every operation.

Re: Analize the runing job

PostPosted: Mon Nov 12, 2018 3:41 pm
by expat
If you need to know where all of the resource is used, and what waits / resource constraints are encountered I would talk to your performance and capacity people.

As to what the job is doing, knowing the DD names is not at all helpful. What you need to know is what the program code is doing.

Re: Analize the runing job

PostPosted: Mon Nov 12, 2018 9:57 pm
by steve-myers
In an analysis of this type, the analyst must know - and this is just the start -
  • The I/O counts for each DD statement used by the program.
  • Many sites provide a roughly equivalent capability for the first bullet in the JESYSMSG data set.
Some years ago I wrote a small program to provide a more direct report -
//JOBLIB   DD  DISP=(SHR,PASS),DSN=&SYSUID..LOAD        
//X       EXEC PGM=EXECSUM,PARM=IEBGENER
//EXECSUM  DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=SHR,DSN=&SYSUID..ASM(EXECSUM)
//SYSUT2   DD  DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,(3,2)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)
//SYSIN    DD  DUMMY

The EXECSUM program creates a report in the data set with DD name EXECSUM. The JCL tells the system to run a program called EXECSUM. PARM=IEBGENER tells EXECSUM to run a program called IEBGENER. The report looks like this -
EXECSUM IEBGENER                                                                
IEBGENER  XXXXXXJ X   STARTED AT 10:54:18 ENDED AT 10:54:18, 0.06 CPU, 0.08 ELAPASED
DDNAME   ADDRESS  EXCPS VOLUME  DATA SET
JOBLIB     0A38       2 VVVV08 XXXXXX.LOAD
EXECSUM    DUMY       0        XXXXXX.XXXXXXJ.JOB03666.D0000101.?
SYSPRINT   DUMY       0        XXXXXX.XXXXXXJ.JOB03666.D0000102.?
SYSUT1     0A7B       3 VVVV31 XXXXXX.ASM(EXECSUM)
SYSUT2     0A2C      64 WRK000 SYS18316.T105417.RA000.XXXXXXJ.R0107555
SYSIN      DUMY       0        NULLFILE

Even a half witted (let's see what maci84 can deduce here) analyst can quickly deduce the reason the data set specified by the DD statement with DD name SYSUT2 has so many more EXCPs than the data set specified by the SYSUT1 DD statement.

I never published EXECSUM. There are too many limitations. It can't run APF authorized programs, and programs that make extensive use of dynamic allocation can confuse EXECSUM.

Re: Analize the runing job

PostPosted: Mon Nov 12, 2018 10:48 pm
by enrico-sorichetti
I mean I have only 1 step and it takes too much time to run down

define too much time :evil:

Re: Analize the runing job

PostPosted: Tue Nov 13, 2018 2:54 pm
by willy jensen
The tradtional starting point is RMF. My very personal opinion is that RMF III in ISPF is quite good. Of course it is even better if the installation has other analysis tools at hand like Omegamon. If you want to beak down execution of a running program then you have to buy a tool. And all tools comes with a learning curve, teaching someone the intricacies of RMF is outside the scope of this forum I would imagine.
But the question by enrico-sorichetti remains, what do you mean by too much time? What do you compare against?

Re: Analize the runing job

PostPosted: Wed Nov 14, 2018 1:34 am
by Pedro
But my idea is to check somehow what operations the job do


Is this a program that you have the source for? I suggest you review the code if it is locally written. Look for repeatedly allocating, opening and closing the same file.

I vaguely recall that the High Level Assembler comes with a dis-assembler. You can dis-assemble a program to determine 'what operations the job do'. (though, some licenses prohibit trying to reverse engineer a product). I doubt you will be able to 'fix' a problem, so I question why even try to find a problem, though you may be able to report a problem to the vendor.

If there is a significant problem, you should be able to report to the vendor and they should be able to help you to gather information.