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.
It didn't change how. As to where, the answer remains as it always has
been: wherever GETMAIN found the needed space to hold the string.
I think
In
aa6ff5ba011f44418bf62c515f71757d21bed...@ch2wpexch1.na.ds.ussco.com,
on 02/21/2014
at 07:58 PM, Chase, John jch...@ussco.com said:
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
-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
On Mon, Feb 24, 2014 at 9:02 AM, Chase, John jch...@ussco.com 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
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of John McKown
On Mon, Feb 24, 2014 at 9:02 AM, Chase, John jch...@ussco.com wrote:
snip
We'd still like to know why loading the program from a PDSE apparently
changed how (and more importantly, where) the
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.
PDSEs are 4K page oriented, so when loaded, they are generally
going to start at a 4K boundary. When loading from a PDS,
fetch processing
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jim Mulder
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.
PDSEs are 4K page oriented, so when loaded,
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/31.6
quote
| *VSM* *USEZOSV1R9RULES(NO|YES)*
| YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from
| its historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior
| for user-region private area subpools that
Excellent forensics. And thanks for the detailed explanation.
Bill Fairchild
- Original Message -
From: John Chase jch...@ussco.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, February 24, 2014 9:02:54 AM
Subject: Re: S0C2 in DB2 application program (was Stored Procedure) IFF run
In syslog, the abend produces messages about the abend. What does the line
DATA AT PSW show? It shows a total of 12 bytes (6 before the PSW and 6
after). The abending instruction could be either at or before the 6th byte.
Jon Perryman.
- Original Message -
From: Chase, John
The DBA who first encountered the problem informs me that it is a plain old
Assembler application, and NOT a Stored Procedure.
The rest of the symptoms and questions remain as originally stated.
-jc-
snip
Running z/OS 1.13 and DB2 v10 (conversion mode). In preparation
for
On Fri, 21 Feb 2014 14:36:10 +, Chase, John jch...@ussco.com wrote:
The DBA who first encountered the problem informs me that it is a plain old
Assembler application, and NOT a Stored Procedure.
The rest of the symptoms and questions remain as originally stated.
Hi John,
My guess is that
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Doug Henry
On Fri, 21 Feb 2014 14:36:10 +, Chase, John jch...@ussco.com wrote:
The DBA who first encountered the problem informs me that it is a plain old
Assembler application,
and NOT a Stored Procedure.
My question would be when was it last assembled and lnked? It is possible it
needs to be assembled and link with newer modules?
Is it code 24bit or 31bit?
Is it using STOW or POINT functions?
These are just guesses, but maybe it is trying to access a member using very
specific PDS functions
-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
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 jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler
My
-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
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:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Chase, John
Sent: Friday, February 21,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave
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.
It appears from our tentative diagnosis that the MVCK
On 21 February 2014 11:37, Chase, John jch...@ussco.com wrote:
Browsing the dumped storage around the program's load address (x'7000') I
see:
Event 1 CSECT DBR915B0 GPR 15 (Address 7000)
700080ECD00C*..}.*
On 21 February 2014 15:28, Chase, John jch...@ussco.com wrote:
It appears from our tentative diagnosis that the MVCK instruction was not
in executable code, but rather was just data
in the PARM passed to the program at invocation. Thus the questions about
where the system places PARM data
21 matches
Mail list logo
