On Wed, Aug 07, 2019 at 06:55:53PM -0400, Tony Harminc wrote:
> Roughly forever we've loaded modules into 24- or 31-bit CSA by first
> LOADing the module normally into private storage, obtaining the actual
> length from the LOAD, DELETEing the module, getting the necessary CSA
> storage, and finally using LOAD with ADDR=. This works fine, but seems
> unduly complicated. [*1] We can't use GLOBAL=YES because the module will be
> gone at EOM, at best. We also need to store into the module right after
> loading it, and even if there was an EOM=NEVER or the like to say not to
> ever delete the module, I'm not sure any store into it would be remembered
> (if RENT is effectively treated as REFR).
> So... Just wondering if there's a Modern method of doing this that I've
> missed. We just want the code in common storage; we don't need its name to
> be made known via a CDE.
I haven't seen one but haven't been looking. The little bit I've seen
seem to want to delete my module at (EOT/EOM) which doesn't seem good...
I'd guess the "new" way would be to not have any relocatable values in
your module. Then just move a copy to CSA. With the new instructions
this seems possible...
Not new, but the way IPC (UCLA/Mail) loads it's CSA code is to do a
BLDL to get the size, get the storage, and then use LOAD DE= & ADDR=
to load the module[2]. The IPC CSA codes lives in CSA key 0 storage
but not fetch protected. It is NOT refreshable, some addresses and
other values are set in it at IPC init time.
1. Wouldn't you (or rather program fetch) overwrite storage if the low
probability happened and the the module length changed between the
two LOAD calls. Hopefully with the authorized caller issuing LOAD
DE= program fetch will use my BLDL info and catch module size changes.
2. A retro-version of IPC runs on MVS 3.8 before LOAD ADDR= existed.
Yuck.
A first cut has a module which does 2 LOADs to it's private area,
copies one to CSA and compares the two private modules to find the
relocated Acons & fixes the CSA ones. In this case all Acons are 4
bytes and on 4 byte boundaries. RX instructions seem to be designed
for this:
* relocation fixup
* - assume all relocated items are 4 bytes on 4 byte boundaries
* - scan each 4 byte word of mod1 & mod2 and note differences
* correcting them in the target module
*
* register usage:
*
* r2 - @ mod1
* r3 - @ mod2
* r4 - @ tgt
* r5 - current offset
* r6 - count of relocations
* r7 - adjustment (for valid checks)
*
SPACE 1
L R2,W#MOD1 @ mod 1
L R3,W#MOD2 @ mod 2
L R4,W#TGTA @ tgt mod
SR R5,R5 offset, start at 0
SR R6,R6 no relocs yet
SR R7,R7 no previous adjustments (yet)
SPACE 1
LI$LOOP L R0,0(R5,R2) word from mod1
S R0,0(R5,R3) match mod2?
BZ LI$NEXT
CR R0,R7 same as last offset
BE LI$RELO bif same, go reloc
LTR R7,R7 first time?
BNZ LI$BADR bif not, relocation problem
LR R7,R0 save for next time relo check
LI$RELO L R0,0(R5,R4) word from tgt
AR R0,R4 + tgt adr
SR R0,R2 - mod1 adr
ST R0,0(R5,R4) update tgt acon
LA R6,1(,R6) count reloc
LI$NEXT LA R5,4(,R5) next offset
C R5,W#MOD1+4 end of module?
BL LI$LOOP
I don't recommend this... Somewhere I have code which will load a module
and do the relocation using information from the RLD records. That's
yet another way...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
