|
View previous topic :: View next topic
|
| Author |
Message |
gandikk
New User
Joined: 16 Mar 2017
Posts: 8
Location: Center Valley, PA
|
|
|
|
| Hi, I have merged 2 cobol pgms to read the input only once. I have tested the new program with 10 million records. In the spool I found the details - CPU: 0 HR 10 MIN 38.06 SEC SRB: 0 HR 00 MIN 05.97 SEC for old pgms and CPU: 0 HR 10 MIN 50.81 SEC SRB: 0 HR 00 MIN 02.34 SEC for new pgm. The CPU got increased little bit and there is 50% reduction in the SRB time. Can you help me to understand how SRB time affects overall run time of the job and Can I consider SRB time reduction as valid savings? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Google is your friend. Googling tcb srb returns about 86,400 hits and many on the first page of results explain the differences. For your second question, yes SRB time reduction is valid savings. HOWEVER, your program went from 644.03 seconds of CPU time (TCB + SRB) to 653.15 seconds of CPU time (TCB + SRB) -- so your "savings" is actually an increase of 1.4% (roughly) in CPU time overall.
| Quote: |
| Can you help me to understand how SRB time affects overall run time of the job |
Run time of jobs on z/OS systems is little impacted by SRB time (and, for that matter, TCB time). More important to run time are things like:
- WLM policy and how the job is classified
- Number of jobs executing
- Relative priority of your job against other jobs
- LPAR percentage CPU usage
- Disk and tape and channel utilization
etc
At a previous employer, a batch compile job could run in 5 minutes 90% of the time. However, when the site was doing month-end processing, the CPU utilization went to 100% and stayed there for 3 days or so -- and during that time, a compile would typically take 5 hours or more to complete. Same program, same CPU (TCB and SRB), same JCL -- the run time difference was due to the CPU running 100% with batch compiles being treated as discretionary work by WLM. |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India
|
|
|
|
Hi Robert,
| Code: |
CPU: 0 HR 10 MIN 38.06 SEC SRB: 0 HR 00 MIN 05.97 SEC
CPU: 0 HR 10 MIN 50.81 SEC SRB: 0 HR 00 MIN 02.34 SEC |
I believe the CPU mentioned on the message is total of TCB and SRB.
IEF032I message says
| Code: |
CPU: xxxxx HR xx MIN xx.xx SEC
For processor time, which includes enclave time, preemptive class SRB
time, client SRB time, and normalized IFA service time, xxxxx HR
specifies the number of hours, xx MIN specifies the number of minutes
and xx.xx SEC specifies the number of seconds (in seconds and
hundredths of a second). |
So the calcualtion has to be
%CPU variance = ((650.81 - 638.06) / 638.06) * 100 = 1.99 = 2 percent increase in CPU compared to the old version. |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India
|
|
|
|
| Quote: |
| Can I consider SRB time reduction as valid savings? |
You have to add the SRB and TCB time and compare the two runs, to assess if your program has performance improvement.
TCB is the time required to execute the program statements.
SRB is the time spent on system tasks on behalf of the program. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
I'm used to the user exit format for CPU timings:
| Code: |
-----TIMINGS (MINS.)------
STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK SERV
ZPARM 00 2233 31 .00 .00 .0 2705
CONFZMF 00 85 1 .00 .00 3.2 499
ZOSMF 00 44724K 11186 145.31 7.33 7963.8 19313169080 |
where the TCB and SRB times are separated. My apologies for not realizing the format of the OP's message wasn't the same.
However, the bottom line remains for the OP -- yes, SRB time went down but the overall CPU time went up. As shown above, SRB is typically much lower than TCB (although the SRB usage depends upon how the program is using system resources), but both are CPU time and are combined to get total CPU usage. |
|
| Back to top |
|
|
gandikk
New User
Joined: 16 Mar 2017
Posts: 8
Location: Center Valley, PA
|
|
|
|
| Thank you Robert & Vasanthz!! Your explanation helped me to understand the difference between TCB and SRB. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
You have taken two COBOL programs which read the same data, and made them into one program? For 10m records you should have noticeable savings.
Did you thoroughly test the new program before tossing a lot of records into it? There's something wrong, which either affects the logic or you've picked a bad way to do something. |
|
| Back to top |
|
|
gandikk
New User
Joined: 16 Mar 2017
Posts: 8
Location: Center Valley, PA
|
|
|
|
Bill, I have tested this program with 1000 and 250K samples to compare the results. One of the tech in our team used the new pgm over the weekend to run his code for 270 million records. We have identified savings in this case.
Old Code:
CPU: 1 HR 56 MIN 38.73 SEC SRB: 0 HR 02 MIN 11.39 SEC - 1st Cobol pgm
CPU: 3 HR 25 MIN 45.14 SEC SRB: 0 HR 02 MIN 33.42 SEC - 2nd Cobol pgm
New Code:
CPU: 5 HR 15 MIN 00.85 SEC SRB: 0 HR 02 MIN 07.18 SEC |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
Mr. Woodger is correct about testing the new program very carefully.
The method you used to combine the two programs may have introduced overheads that would pretty much negate any TCB CPU time savings, leaving a small SRB time savings. Since there is no practical way for an ordinary program to control the amount of SRB CPU time the program uses, I would discount this "savings."
Still, it looks to me you got back 15 minutes or so. Not bad at all! |
|
| Back to top |
|
|
gandikk
New User
Joined: 16 Mar 2017
Posts: 8
Location: Center Valley, PA
|
|
|
|
Vasanthz, you have mentioned that CPU is the total of TCB and SRB. But in one of my jobs, CPU is less than the SRB time.
CPU: 0 HR 03 MIN 50.88 SEC SRB: 0 HR 10 MIN 17.11 SEC
It is a sort step is pulling the records based on some criteria. Why do we have CPU less than SRB?
Thank you!! |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India
|
|
|
|
| Quote: |
But in one of my jobs, CPU is less than the SRB time.
CPU: 0 HR 03 MIN 50.88 SEC SRB: 0 HR 10 MIN 17.11 SEC |
Wow. I got no explanation for that. Maybe the time is actually TCB and I was wrong all along.
Let me check couple of things. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| gandikk, is there an IEF032I message identifier anywhere in your output? If not, CPU may represent TCB time -- CPU is the total for IEF032I, but not necessarily for any other message. |
|
| Back to top |
|
|
|
|
