Jeslog Performance Statistics



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Jeslog Performance Statistics

Postby cdance52 » Thu Jan 06, 2011 7:42 pm

Hello All,

I am trying to speed up a COBOL program that uses DB2. I made major changes that have paid off when the incoming file is extremely large. But when the file is small I get an even longer runtime. I am not familiar with the step statisitcs produced by JES: Here is what I am getting:

-STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK

-STEP230N PROC01 00 19225 7613 10.31 .00 38.9 3878K BATCH 0 0 0 0 (This is the 'old' version of the pgm)
-STEP230N PROC01 00 18395 5134 29.40 .00 59.2 11035K BATCH 0 0 0 0 (This is the 'new' version)

The 'clocktime' is increased by 50% between these two runs when the file is small.

What do the TCB and SRB tell me? Are there other places wheree I can get run statistics in JES?

CD
cdance52
 
Posts: 1
Joined: Thu Jan 06, 2011 7:09 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Jeslog Performance Statistics

Postby Robert Sample » Thu Jan 06, 2011 8:07 pm

TCB is the CPU time actually used by your program and its components (including compiler modules automatically included).

SRB is the CPU time used by the system (for performing I/O, for example).
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: Jeslog Performance Statistics

Postby Robert Sample » Thu Jan 06, 2011 8:11 pm

And elapsed time ("clock time") is a really, really, really bad measure to use for a program. The actual elapsed time can vary by at least 2 orders of magnitude just based upon the system workload and when you run the job (in other words, run your job when the system is busiest and it may take 100+ times as long as when you run it when the system is not busy).
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: Jeslog Performance Statistics

Postby steve-myers » Thu Jan 06, 2011 10:03 pm

Those statistics are not coming from JES2, either. They are coming from SMF data as it is being examined by the IEFACTRT SMF exit routine. One of z/OS's dirty little secrets is that CPU time, especially for quickly running jobs, is not repeatable. There are several reasons for this. The two biggest issues is that I/O, generally for other jobs, is stealing use of CPU time to access memory. Similarly, and this is especially true for modern hardware where you have cache memory and CPU instruction "pipelines," every time the CPU processes an interrupt it is a disaster for your program. First, the instruction "pipeline," which caused storage accesses to fill, is abandoned. Second, by the time the computer completes processing the interrupt, and often running some other process, the storage cache has been filled with data from someone else, and until your data has replaced the cache your program is running more slowly. When your program restarts, it has to refill the instruction "pipeline" and cache memory before it is running at 100%. All of this is charged to you. SRB time is even more flaky than the CPU time you see n your JESMSGLG and JESYSMSG datasets, especially since most of it has nothing to do with your job.

As Mr. Sample says, elapsed time is even less repeatable than CPU time, as it is very dependent on other workloads in the system.

Us mainframe types have always been obsessed with CPU time, even though it has never been very repeatable. As the real costs of CPU have declined over time, I increasingly wonder if this obsession is realistic these days, though when it is used as a rough measure of program efficiency you are making a valid use of the statistic.
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times


Return to JCL

 


  • Related topics
    Replies
    Views
    Last post