In a recent note, Martin Kline said:
> Date: Thu, 14 Jul 2005 14:40:42 -0500
>
> > Don't you think the optimization should be in ATTACH SVC
> > code rather than in the initiator, so it would benefit
> > programmers who ATTACH IEFBR14 from programs as well as
> > from JCL?
>
> First, why would a programmer do that?
>
If the question is rhetorical, the answer is, "Never mind;
someone will." For example, how about a no-op to be
used as a default user exit.
> Second, the attaching program may expect a TCB to be
> created and an ECB to be posted. So, ATTACH processing
> would still have to do at least that much. If the
> initiator didn't call ATTACH, didn't issue a WAIT, etc.
> that would avoid more overhead.
>
Agreed. And the more I think about this, the more
complicated it becomes.
o Does "EXEC PGM=IEFBR14" result in cutting an SMF record?
(I suspect it does; else how was someone able to count
30,000/day?) Should the bypassed IEFBR14 cut the same
SMF record? There's unlikely to be administrator consensus
on this; it might need to be made a PARMLIB option.
o The CLC; BE test you propose must be done _after_ the
search of STEPLIB/TASKLIB/JOBLIB in order that a
programmer who has supplied a customized IEFBR14 in
STEPLIB not find his efforts thwarted. This argues
that the test be put in ATTACH so the initiator
needn't perform the STEPLIB search separately.
- The code that would need to be changed is likely
shared among ATTACH, LINK, LOAD, and XCTL. The
shortcut exit must handle each of these differently.
- LINK: (simple) Clear R15 and return to caller.
- XCTL: Clear R15 and issue EXIT SVC.
- ATTACH: As you said, POST ECB, enter exit routine,
clear R15, return.
- LOAD: return the address of a {LA|XR|SR|SLR} R15,R15
(processor dependent) instruction sequence. Create
a CS entry so DELETE of a bypassed loaded IEFBR14
will function properly.
o To support installations whicn may have customized
IEFBR14 in LINKLIST/LPALIST there must be some support
for not bypassing IEFBR14. Another PARMLIB option?
The default would have to be not bypass in order not
to change existing behavior.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
