Zap an 0C1 into the PDS version at the MVCK. I bet you will find the module loaded into a different storage area with different attributes.
> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Chase, John > Sent: Friday, February 21, 2014 8:37 AM > To: [email protected] > Subject: Re: S0C2 in DB2 application program (was Stored Procedure) IFF run > from a PDSE > > > -----Original Message----- > > From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler > > > > My question would be when was it last assembled and lnked? > > Date in the load module / program object is 2010.322. > > > It is possible it needs to be assembled and link with newer modules? > > I'll suggest that to the DBA, but it's still incomprehensible why this > particular > program would crash IFF loaded from a PDSE. > > > Is it code 24bit or 31bit? > > AMODE(24). > > > Is it using STOW or POINT functions? > > No; just EXEC SQL OPEN, FETCH, CLOSE; and QSAM OPEN, CLOSE and PUT > macros. > > > These are just guesses, but maybe it is trying to access a member > > using very specific PDS functions and the PDS/E access might be > > returning an error. I would check Logrec to see what might have occurred. > > > > Since an S0C2 is a Privileged-operation exception, it makes me think > > of some sort of CCW error is being returned. So how is it accessing > (retrieving) the data? > > See previous paragraph. > > Browsing the dumped storage around the program's load address > (x'00007000') I see: > > Event 1 CSECT DBR915B0 GPR 15 (Address 00007000) > 00007000 80ECD00C *..}. * > --------------------^^^^^^^^ > > WTF??? > > In the program source the first instruction is: > > USING *,R15 > DBR915B0 CSECT > STM R14,R12,12(R13) > > But STM's opcode is x'90', not x'80'. X'80' is SSM (Set System Mask), which > is > a(nother) privileged instruction. > > Now this is getting "interesting"; I hadn't gone down this path before. > > In the load library (PDSE), the first occurrence of x'ECD00C' has x'90' > immediately preceding: > > °Ö}. > 9ED0 > 0C0C > > The same is true of the copy in the PDS load library. > > So, it appears that for some as-yet undetermined reason, this program (to the > exclusion of all others) IFF loaded from a PDSE has its first instruction > changed > somehow from STM to SSM. Can you say "That's absurd!"? > > Looks like the program might have a "wild branch" that manifests itself IFF > loaded from a PDSE (which also is prima facie absurd; the program does not > recurse). The program is invoked as the job-step program, and except for the > EXEC SQL calls and QSAM macros does not call any other modules. > > Somewhere there is a logical explanation for this. We just have to find it. > > -jc- > > > *************************************************************** > ******* > Information contained in this e-mail message and in any attachments thereto > is confidential. If you are not the intended recipient, please destroy this > message, delete any copies held on your systems, notify the sender > immediately, and refrain from using or disclosing all or any part of its > content > to any other person. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
