Thanks for all responses.
Sam Siegal asked: 1) Does this only happen on second and subsequent load?
Since it loads correctly all the time except for rare situations in a multitasking environment, we are assuming it is related to a second load running concurrently with the first load.
2) What attributes (rent, reus, etc.) are present on the load module?
Refr, rent and reus
3) is this under CICS? Or a proprietary multitasking region?
This is under a WLM-managed DB2 Stored Procedure Address Space (SPAS).
4) Is code all ASM? Or is there an HLL in the mix?
All assembler, although the caller is probably HLL.
5) was the module recently changed? or is it a new module?
The LOAD technique was changed, along with several other things to address more general problems in this environment. We formerly did a standard LOAD, but then the loaded module disappeared if the TCB which loaded it was detached. So we now enter sup state via a PC, and acquire subpool 131 memory in which to do the load, so it outlasts the TCB. We also made other changes at the same time.
Abe Kornelis wrote: In one of my first programs, I inadvertently defined a Vcon double. It gave me exactly the result you describe. It led me to conclude that the loader simply adds the offset to the base value. If you define (or load) twice, the addition is performed twice as well... Looks like you will need a lock or latch of some kind after all. Or pre-load, maybe. I'm sure you'll be able to determine what will work best for your product.
We're quite sure we don't double define the VCON, since the LOAD normally works perfectly
Greg Dyck said: Normal (non-directed) LOAD processing serializes fetch processing for a module and only performs relocation of ACONs/VCONs once when the module is fetched. The only way I could see what you describe happen is if there were two RLD entries for the same VCON and it would happen with one load or 20.
Thanks for this reassurance. That's what i understood and why I thought this was unusual behaviour.
For directed LOAD processing serialization is the issuers responsibility. If two tasks concurrently did a directed load of the same load module to the same storage address (why they would, I do not know) this could possibly happen... though it would be random as to which ACONs/VCONs were messed up.
Thanks for this. I did not know that directed load was not serialized. I'm not sure why we would be loading to the same memory, since the getmain precedes the load, but we will shift our research. This also makes us more confident that serializing the directed load will address the problem, rather than mask it. Gary Weinhold Data Kinetics, Ltd. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
