the first thing to check would be entry point - a non-zero entry point is one of the easiest things to loose in a LKED.
On Fri, Feb 21, 2014 at 10:37 AM, Chase, John <[email protected]> wrote: > > -----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 > -- Mike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
