> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Chase, John
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List On Behalf Of Mike Bell
> >
> > 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.
>
> ENTRY_POINT = LOAD_POINT, but the DB2 interface was the first CSECT in the
> load module.
>
> We think we have a diagnosis; waiting for the programmer to compile/link the
> suggested change and
> verify operation. If resolved, I'll post the diagnosis we came up with. But
> the diagnosis we came up
> with raised two questions:
>
> Q1: Where does the system place the PARM= string when the program is loaded
> from a PDSE?
> Q2: Where does the system place the PARM= string when the program is loaded
> from a PDS?
>
> Our tentative diagnosis depends on there being a difference.
And absent confirmation or refutation of the proposition that the system passes
the PARM= string differently depending on whether the job step program is
loaded from a PDS vs a PDSE, we've concluded the following based on observation
and dump analysis:
1. The application program itself held the defect, in that it marked the end
of the PARM= string by moving a flag byte to the first byte after the PARM=
string: MVI PARMADDR+PARMLEN,x'80'.
2. For the decades when the application program resided in a PDS, it executed
without problem. We never knew the exact location of the PARM= string in
storage, because it never mattered. We weren't aware the program was "broken";
therefore it was never "fixed".
3. When the program was executed from a PDSE, IFF the length of the PARM=
string was exactly 16 (or perhaps any exact multiple of 8), the PARM= string
was passed to the application program with its last byte immediately preceding
the first instruction at the program's load point (which in this case was also
the program's entry point; the instruction is 90ECD00C <STM 14,12,12(13>).
4. The first CSECT in the load module is the DB2 High-level Language Interface
('HLI') stub, which was loaded at address x'00007000'. The application
program's CSECT appeared at x'000073B0', and its first instruction was also
90ECD00C.
5. At invocation, the DB2 HLI performed the STM 14,12,12(13) and "did its
thing", eventually branching to the application program's CSECT.
6. After setting up "standard linkage convention", the application program
proceeded to mark the end of the PARM= string via MVI PARMADDR+PARMLEN, x'80'
(which in the PDSE case with 16-byte parm overwrote the STM opcode in the DB2
HLI, changing it to SSM).
7. Later in its processing, the application program issued an EXEC SQL call,
which caused a branch to the DB2 HLI.
8. The DB2 HLI's first instruction having been changed to a privileged
instruction, the application abended S0C2 because it was not running in
supervisor state.
The "fix" was simple: Change the move of the flag byte to a compare of current
position within the PARM= string to its ending address.
We'd still like to know why loading the program from a PDSE apparently changed
how (and more importantly, where) the system passed the PARM= string.
-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
