Author: Robert Sample
Posted: Mon Mar 20, 2017 10:02 pm (GMT 5.5)
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.
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.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
Posted: Mon Mar 20, 2017 10:02 pm (GMT 5.5)
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 |
- 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.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth