> I am finally getting around to modifying our IEFUSI exit to do 
> something sensible with MEMLIMIT as more tasks exploit 64-bit 
> storage. This exit has lain untouched for many many years, although 
> it still functions correctly for the things it is supposed to do 
> with region size.
> 
> However, now I come to look at it, it becomes my responsibility to 
> fix any anomalies I find. 
> 
> The first of these is the alarming comment:
> 
> *   ON ENTRY R10 POINTS TO THE LCT.
> *   SEE MICROFICHE OF IEFSMFIE AT CURRENT PTF LEVEL COS IT'S
> *   POSSIBLE FOR THIS TO CHANGE
> 
> The documentation for IEFUSI makes no reference to R10 pointing to 
> the LCT, indeed it states that R2-R12 are not applicable.
> My investigations have determined that R10 does indeed point to the 
> LCT, but how long this will remain the case is not for me to gamble 
> on, so I have to find another way.
> 
> The exit uses LCTSCTVA as input to SWAREQ to get to the SCTX via the
> SCT. It then takes a copy of the SCTX using IEFQMREQ and updates (in
> certain circumstances) the SCTXSTL value and re-writes the SCTX 
> using IEFQMREQ.
> 
> Given that I can?t rely on R10 pointing to the LCT, should I be 
> using JSCSCTP from the JSCB to get the SCT SVA token for SWAREQ 
> (even though it is not part of GUPI)?

  I remember what happened in 1991 in SP4.2.0 when a
code change and recompile of IEFSMFIE resulted in R10 no longer
containing the address of the LCT when IEFUSE was invoked. 
But, rather than rely on my
memory, I dug up the problem record in the old development
PTM database. (PTM was Program Trouble Memorandum, for those who 
enjoy obscure IBM acronyms.) 

<quote>

 EXTERNAL DESCRIPTION TEXT: PH32142 
 
********************************* Top of Data **************************
External users of SMF exits IEFUSI and IEFUJI require access to the 
Scheduler "Linkage Control Table" (LCT).  This access has been through 
the UNDOCUMENTED dependency that Reg 10 Point to the LCT upon entry to 
these exits.  These users include the system test tool "JMON", some 
tools used by Santa Teresa Lab (similar to or actual copies of JMON), 
and the OP/CA Product (AND IF OP/CA uses this pointer then OTHER 
products do too which means that this pointer MUST be documented). 
...(Skip's notes)... Opening this problem per conversation w/Bill 
Rxxxxxxxx.  4.2.0 eio accounts South Road Lab and Santa Teresa Lab are 
currently experiencing (or have experienced) "problems" in these exits. 
Bill has agreed to make the necessary changes to change these exits back
the way they used to be regarding register contents. 
Documentation for the exits will also be changed. 
Need usermod for this to support drivers 19 and 20 for eio's. 

 PTM SOLUTION ENTRY: PH32142 
 
 Enter up to 50 lines of Solution only. 
 Press END key (PF3) to save Solution or "CANCEL" to return to previous 
********************************* Top of Data ***************************
The module that invokes both these exits (IEFSMFIE) included changes 
in DCR 163 that required that module to get access to Register 10 for 
'other' reasons (besides addressing the LCT).  It was later determined 
that EXTERNAL users of these exits are dependent upon the address of the 
Scheduler LCT being in Reg 10 upon entry (even though this is NOT 
documented as a part of the interface to these exits).  SO, the module 
was changed to set Reg 10 to the address of the LCT prior to invoking 
the exits (copying the value from a local variable) AND arrangements 
are being made to update the interface documentation in the User Exits 
books to include this information. 

<end quote>

  So that's what happened, although it looks like the documentation
either didn't happen, or subsequently got lost. 


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to