> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of John McKown

> 
> On Mon, Feb 24, 2014 at 9:02 AM, Chase, John <[email protected]> wrote:
> 
> > <snip>
> >
> 
> 
> > 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-
> >
> >
> I would consider this explanation to be unlikely. The PARM is where it always 
> was. But what _may_ have
> changed is where the program was loaded. I would consider it very likely that 
> program fetch from a PDS
> is "old code"
> and program fetch from a PDSE is likely totally different code. Have you 
> confirmed that the load
> address in both cases is the same and that the PARM address is different?

Not with this specific program (remember, it never abended when loaded from a 
PDS).  But generally, I've observed that the job step program (EXEC 
PGM=program) gets loaded on a page boundary, usually at the "bottom" of private 
region (x'00007000' in our case) when below the line (and this application is 
AMODE(24) ).

> Another thought could be that if the program is fetched to the same location, 
> perhaps the initiator is
> doing something else which is causing a different set of STORAGE OBTAINs and 
> RELEASEs which could
> affect where the "free storage" exists which is gotten for the PARM.  So 
> perhaps just being in a PDSE
> does cause a difference, but not a deliberate difference. It may be a "just 
> because" difference.
> 
> Just a couple of weird thoughts. Maybe I've been looking at weird HLASM 
> generated code from the C
> compiler too long.

Speaking of "weird thoughts", how's this:  If loaded from a PDS, the PARM= 
buffer is 102 bytes long, with the parm length stored in the first halfword and 
the parm string left-justified.  If loaded from a PDSE, the parm string is 
RIGHT-justified in the PARM= buffer so the first byte is on a doubleword 
boundary, and the parm length is prepended to it in the halfword immediately 
preceding the first byte of the PARM string.

That is what appears to be happening, anyway.  :-)

    -jc-

<You don't have the patent on "weird".  :-) >

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

Reply via email to