Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IEFACTRT changed in z/os 1.13 was: Drowning in service units on z/os 1.13 after migrating from v1.11
461 views
Skip to first unread message
Jim Mooney
Jul 27, 2012, 2:00:02 PM7/27/12
to
Well, after a review of smf30 records we find that those here who mentioned IEFACTRT win the gold (even though the open cermonies don't start until later tonight in London). The IBM supplied sample member IEEACTRT for z/os 1.13 has changed the calculation for service units. The v1.11 exit 'service units' included only SRB time, while the v1.13 exit 'service units' include TCB, SRB, I/O and MSO. Here is the comment from the source that indicates there has been a change:
*/*$P7= OA31624 HBB7770 100128 PDRJ: IEEACTRT USING WRONG FIELD @P7A*/
*/* FOR TOTAL SERVICE UNITS @P7A*/
*/* (SUG APAR) @P7A*/
So those using the vanilla IEFACTRT should expect this new calculation.
As for us, we continue chasing the other half of this issue - increased wait times for our batch jobs. We have been here before. We were cpu constrained on z/os v1.11. Two months ago we took several measures to improve our batch 'window'. And now, after upgrading to v1.13 (with no hdwr or memory changes) we have again become a bit more cpu constrained.
This is my theory: z/os v1.13 = more overhead.
Does anyone here claim that we should be observing *less* overhead on v1.13 compared to v1.11?
Thx again for the excellent guidance. -Jim
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
*/*$P7= OA31624 HBB7770 100128 PDRJ: IEEACTRT USING WRONG FIELD @P7A*/
*/* FOR TOTAL SERVICE UNITS @P7A*/
*/* (SUG APAR) @P7A*/
So those using the vanilla IEFACTRT should expect this new calculation.
As for us, we continue chasing the other half of this issue - increased wait times for our batch jobs. We have been here before. We were cpu constrained on z/os v1.11. Two months ago we took several measures to improve our batch 'window'. And now, after upgrading to v1.13 (with no hdwr or memory changes) we have again become a bit more cpu constrained.
This is my theory: z/os v1.13 = more overhead.
Does anyone here claim that we should be observing *less* overhead on v1.13 compared to v1.11?
Thx again for the excellent guidance. -Jim
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Bill Fairchild
Jul 27, 2012, 2:13:18 PM7/27/12
to
Are any of the IEFACTRT-mentioners inclined to share some of that gold with William of Occam? :-)
Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane • Franklin, TN 37069-2526 • USA
t: +1.617.614.4503 • e: bfair...@rocketsoftware.com • w: www.rocketsoftware.com
Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane • Franklin, TN 37069-2526 • USA
t: +1.617.614.4503 • e: bfair...@rocketsoftware.com • w: www.rocketsoftware.com
Dick Bond
Jul 30, 2012, 6:20:46 PM7/30/12
to
If you feel you must back it out, just *reverse* the following code change
in IEFACTRT (text from APAR OA31624):
LOCAL FIX:
Reassemble the exit and change the label under the
GET INFORMATION FROM PERFORMANCE SECTION
from
LG R01,SMF30SRB_L GET SERVICE UNITS USED
to
LG R01,SMF30SRV_L GET SERVICE UNITS USED
in IEFACTRT (text from APAR OA31624):
LOCAL FIX:
Reassemble the exit and change the label under the
GET INFORMATION FROM PERFORMANCE SECTION
from
LG R01,SMF30SRB_L GET SERVICE UNITS USED
to
LG R01,SMF30SRV_L GET SERVICE UNITS USED
Gerhard Adam
Jul 30, 2012, 6:32:17 PM7/30/12
to
Doesn't "backing out" normally refer to restoring a module to remove a
problem? In this case, it would be to restore the problem.
There is no valid reason for such an action.
>If you feel you must back it out, just *reverse* the following code change
>in IEFACTRT (text from APAR OA31624):
>LOCAL FIX:
> Reassemble the exit and change the label under the
> GET INFORMATION FROM PERFORMANCE SECTION
> from
> LG R01,SMF30SRB_L GET SERVICE UNITS USED
> to
> LG R01,SMF30SRV_L GET SERVICE UNITS USED
problem? In this case, it would be to restore the problem.
There is no valid reason for such an action.
>If you feel you must back it out, just *reverse* the following code change
>in IEFACTRT (text from APAR OA31624):
>LOCAL FIX:
> Reassemble the exit and change the label under the
> GET INFORMATION FROM PERFORMANCE SECTION
> from
> LG R01,SMF30SRB_L GET SERVICE UNITS USED
> to
> LG R01,SMF30SRV_L GET SERVICE UNITS USED
0 new messages