Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 I've lost the link I had to documentation on USEZOSV1R9RULES; USEZOSV1R9RULES is documented. For z/OS 1.13 this can be found in the Init Tuning reference's DIAGxx chapter such as at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2c1/31.6?ACTION=MATCHESREQUEST=USEZOSV1R9RULESTYPE=FUZZYSHELF=iea2bkb4.bksDT=20120130114834CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANKScrollTOP=FIRSTHIT#FIRSTHIT Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 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. That doesn't make much sense; The Initiator processes the PARM *before* it attaches the job step. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-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'7000'. The application
program's CSECT appeared at x'73B0', 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 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? 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. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-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 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'7000' 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 simply does a GETMAIN for the storage. If the size of the module is at least 2 pages, but not a page multiple, the Getmained storage (and thus the load module) will be aligned to end on a 4K boundary if D DIAG shows VSM USEZOSV1R9RULES(YES) or it will be aligned to start on a 4K boundary if you have VSM USEZOSV1R9RULES(NO) Your results suggest that you are using the default of VSM USEZOSV1R9RULES(YES). I would expect the location of the PARM= string to be the same, regardless of PDS vs. PDSE. However, I would expect that changing the setting for VSM USEZOSV1R9RULES will change the location of the PARM= string. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-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, they are generally going to start at a 4K boundary. When loading from a PDS, fetch processing simply does a GETMAIN for the storage. If the size of the module is at least 2 pages, but not a page multiple, the Getmained storage (and thus the load module) will be aligned to end on a 4K boundary if D DIAG shows VSM USEZOSV1R9RULES(YES) or it will be aligned to start on a 4K boundary if you have VSM USEZOSV1R9RULES(NO) Your results suggest that you are using the default of VSM USEZOSV1R9RULES(YES). Correct. So that suggests that, when the program was loaded from a PDS, it got loaded at whatever doubleword-aligned address the GETMAIN happened to acquire, which was not necessarily on a page boundary. In fact, the load module is more than two pages in length but less than three pages, so it appears it was just lucky that the insertion of the flag byte at the end of the PARM string didn't cause (even) a S0C4. I think we discussed changing to VSM USEZOSV1R9RULES(NO) when we migrated from 1.9 to 1.11, but apparently it got lost in the shuffle. And now we're preparing for z/OS 2.1 (or its follow-on), from 1.13. I would expect the location of the PARM= string to be the same, regardless of PDS vs. PDSE. However, I would expect that changing the setting for VSM USEZOSV1R9RULES will change the location of the PARM= string. I think I've lost the link I had to documentation on USEZOSV1R9RULES; can you provide a current one, please? Thanks, -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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 are both below and above | the line to be implemented. Thus DQEs can be merged where possible. | The default is YES to provide a seamless migration. However, IBM | recommends that you specify USEZOSV1R9RULES(NO) to obtain a | performance benefit for applications with long DQE/FQE chains for | user-region private area subpools. /quote On Mon, Feb 24, 2014 at 11:46 AM, Chase, John jch...@ussco.com wrote: -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, they are generally going to start at a 4K boundary. When loading from a PDS, fetch processing simply does a GETMAIN for the storage. If the size of the module is at least 2 pages, but not a page multiple, the Getmained storage (and thus the load module) will be aligned to end on a 4K boundary if D DIAG shows VSM USEZOSV1R9RULES(YES) or it will be aligned to start on a 4K boundary if you have VSM USEZOSV1R9RULES(NO) Your results suggest that you are using the default of VSM USEZOSV1R9RULES(YES). Correct. So that suggests that, when the program was loaded from a PDS, it got loaded at whatever doubleword-aligned address the GETMAIN happened to acquire, which was not necessarily on a page boundary. In fact, the load module is more than two pages in length but less than three pages, so it appears it was just lucky that the insertion of the flag byte at the end of the PARM string didn't cause (even) a S0C4. I think we discussed changing to VSM USEZOSV1R9RULES(NO) when we migrated from 1.9 to 1.11, but apparently it got lost in the shuffle. And now we're preparing for z/OS 2.1 (or its follow-on), from 1.13. I would expect the location of the PARM= string to be the same, regardless of PDS vs. PDSE. However, I would expect that changing the setting for VSM USEZOSV1R9RULES will change the location of the PARM= string. I think I've lost the link I had to documentation on USEZOSV1R9RULES; can you provide a current one, please? Thanks, -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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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
from a PDSE
-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'7000'. The application
program's CSECT appeared at x'73B0', 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 jch...@ussco.com It appears from our tentative diagnosis that the MVCK instruction -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 Enterprise COBOL v5.1 we are converting load libraries from PDS to PDSE. Our DBAs have found ONE (so far) DB2 Stored Procedure that runs correctly if loaded from a PDS, but suffers an Abend S0C2 if loaded from a PDSE. In the dump I examined, the failing instruction is MVCK. The Stored Procedure was running in problem state, and the PrOps manual says it needs to be in Supervisor state to issue MVCK under many circumstances. The error is occurring in CSECT DSNHLI, according to Fault Analyzer. We will open a PMR with IBM later today, but first a couple of questions: Q1. Any idea why the Stored Procedure would abend S0C2 but IFF loaded from a PDSE? Q2. Against which IBM component should we open the PMR? /snip ** 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 the assembler program is incorrectly coded and is looking at some random storage that used to be OK for the logic of the program and now the random storage has changed to something that is not OK. Just last week I debugged a program for our tools group that had worked for many years and now was failing on z/OS V2R1. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-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. The rest of the symptoms and questions remain as originally stated. Hi John, My guess is that the assembler program is incorrectly coded and is looking at some random storage that used to be OK for the logic of the program and now the random storage has changed to something that is not OK. Just last week I debugged a program for our tools group that had worked for many years and now was failing on z/OS V2R1. Thanks. We're going through the source code now, but so far nothing says Lookee Here! It's really difficult to comprehend what could be causing the failure IFF loaded from a PDSE; the program runs fine if loaded from a PDS. -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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 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? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chase, John Sent: Friday, February 21, 2014 8:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE -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. The rest of the symptoms and questions remain as originally stated. Hi John, My guess is that the assembler program is incorrectly coded and is looking at some random storage that used to be OK for the logic of the program and now the random storage has changed to something that is not OK. Just last week I debugged a program for our tools group that had worked for many years and now was failing on z/OS V2R1. Thanks. We're going through the source code now, but so far nothing says Lookee Here! It's really difficult to comprehend what could be causing the failure IFF loaded from a PDSE; the program runs fine if loaded from a PDS. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-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'7000') I see: Event 1 CSECT DBR915B0 GPR 15 (Address 7000) 700080ECD00C*..}.* 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 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'7000') I see: Event 1 CSECT DBR915B0 GPR 15 (Address 7000) 700080ECD00C*..}.* 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-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. -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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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, 2014 8:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE -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'7000') I see: Event 1 CSECT DBR915B0 GPR 15 (Address 7000) 700080ECD00C*..}.* 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-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 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 before transferring control to the user program. This is a situation where Fault Analyzer was a little too helpful in presenting instructions around (before) the point of failure. -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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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*..}.* 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. And one that the program could not have survived executing; it is not only privileged, but in most cases you will encounter on z/OS will produce a special operation exception if your program *is* in supervisor state. So, assuming this is the entry point of the program, that is, the first instruction to be executed and not only the first one physically in the module, it seems very likely that this instruction was modified after some part of the program had already executed. 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!? That's absurd!. But I can also say as above that it's unlikely it was loaded that way. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
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 before transferring control to the user program. It surely doesn't place it on top of your program code... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
