On 3/13/2012 10:52 AM, Paul Gilmartin wrote:
Why should this peculiarly affect IEFBR14? (Although, to be
fair, Gerhard never denied that it affected all programs.)
Given enough dd statements, on a slow processor, it will take enough
time to exceed a small standard time limit.
Wouldn't a better solution than a specialized IEFUTL be to increase
the standard time limit, at least enough to accommodate IEFBR14?
The jobs in question were running at a service bureau, thus we
could not just arbitrarily change user's time specifications;
while we imposed limits by job class, we did not supply
defaults. In general, JOB statements did not have TIME
parameters, and I've never seen an IEFBR14 step with a TIME
value. The system initiator scheduled the IEFBR14 step with the
requested time, 0, and I found it more interesting that this
ever worked. Since we already had an IEFUTL (to remind operators
of unhandled tape mounts, etc., and to grant extensions to
special jobs), adding a quick test for IEFBR14, and granting a
minimal extension, was trivial.
AFAIK, IBM addressed the problem by using a non-zero TIME to
dispatch an IEFBR14 step.
Gerhard Postpischil
Bradford, VT
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
