> -----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
