We solved this. Our calling sequence is somewhat complex: our processing is going to block, so we need to get off the QR. So we have a two-level call: the user transaction calls our first-level program, which does an EXEC CICS LINK to the second-level program, which is defined OPENAPI and THREADSAFE to get us off the QR.
It turns out that the CEDA definition of the second-level program was EXECKEY(USER); changing it to EXECKEY(CICS) fixed our problem. Here's what we believe happened, depending on the STGPROT setting: With STGPROT=NO: - All storage was key 8. - Our MODESET worked fine, we were able to access user storage from the started task. With STGPROT=YES: - User storage (in the transaction) was key 8 (running on the QR). - Transaction called our first-level program, which was also running in key 8, also on the QR. - Our first-level program did an EXEC CICS LINK to the second-level program to get off the QR. However, our second-level program was also defined as EXECKEY(USER), and thus ran in key 9. When we got control in the Started Task, our MODESET worked, putting us into key 9 - which was, of course, A Bad Thing at that point. - Once our second-level program was changed to EXECKEY(CICS), it also ran in key 8, and thus our MODESET puts us into key 8 and all is well. Thanks to all for assistance and speculation - while (due to our vague understanding!) it wasn't all on-target, it surrounded the problem well enough that it helped us figure it out. Definitely pays for our IBM-MAIN subscription for the year J .phsiii ---------------------------------------------------------------------- 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
