> Our APF auth application calls a C++ XPLINK module , and during the > initialisation we got an S0C4 in CELVH003 offset +4. > The SYSMDUMP says "loading task not secure" > The module is in SP251 KEY1 storage and the caller is in KEY8. > Why the module in SP251 KEY1 ?
"Loading task not secure" is just meaningless blather from RACF PADS. You can ignore it unless you happen to be trying to control access to datasets via RACF PADS profiles (a generally bad idea BTW.) Reentrant modules that are loaded from APF libraries are loaded into SP 252 which is key zero and NOT fetch protected. The subpool is owned by the job step task, but that's irrelevant to this discussion. Non-APF and all non-reentrant modules (APF or not) are loaded into SP251, which is also owned by the job step task, but all of its storage is in the job step key and is fetch protected - which is why your key 8 program barfed on entry to it. The ancient assumption was that programs only ran in their job step key, or in key zero, hence the choice of keys for step-owned storage. That's often spectacularly wrong as it turns out, but there's no way to change it now. The same assumption pops up all over the place in z/OS and its ancestors. Your code failed because the LE module was loaded in SP251, which means it was NOT marked RENT, -OR- that it was fetched from a non-authorized library. It seems wildly unlikely that an LE module would not actually be reentrant. But it still doesn't all add up because contents supervisor would never allow a load from a non authorized library in an address space that had a job step key in the range 0-7. There's more to this than meets the eye. There are a couple of questions here. If subpool 251 is in key 1, it means the job step was started in key 1 - presumably via a PPT entry. If so, how come your application code was running in key 8? CC ---------------------------------------------------------------------- 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
