007E0005 abend in DSNXGRDS.DSNXGDT2

Arild Løkke

007E0005 abend in DSNXGRDS.DSNXGDT2
Hi all,
We have just upgraded to DB2 9 CM mode (z/os) and are experiencing a lot of 00E70005 abends in our test system. We are running a datasharing environment with 2 members which only the first member is migrated to v9 CM mode. z/os level is 1.8.
This is what we see in dsnMSTR:
DSNL027I -DB2T SERVER DISTRIBUTED AGENT WITH 088
LUWID=P248FDE1.G1BE.C1CF8A24FF4E=23839
THREAD-INFO=TESTGEN:vswsbsa:testgen:db2jcc_application
RECEIVED ABEND=04E
FOR REASON=00E70005
And this is what we see inn dsnDBM1:
IEA794I SVC DUMP HAS CAPTURED: 054
DUMPID=012 REQUESTED BY JOB (DB2TDIST)
DUMP TITLE=DB2T,ABND=04E-00E70005,U=TESTGEN ,M=(C),C=910.LOCN=:
:146.72.250.2 ,LOC=DSNXGRDS.DSNXGDT2:M204
And this is what we see in sys1.logrec:
SEARCH ARGUMENT ABSTRACT
PIDS/5740XYR00 RIDS/DSNXGRDSÆL RIDS/DSNXGDT2 AB/S004E PRCS/00E70005
REGS/0C000 RIDS/DSNTFRCVÆR
SYMPTOM DESCRIPTION
------- -----------
PIDS/5740XYR00 PROGRAM ID: 5740XYR00
RIDS/DSNXGRDSÆL LOAD MODULE NAME: DSNXGRDS
RIDS/DSNXGDT2 CSECT NAME: DSNXGDT2
AB/S004E SYSTEM ABEND CODE: 004E
PRCS/00E70005 ABEND REASON CODE: 00E70005
REGS/0E01A REGISTER/PSW DIFFERENCE FOR R0E: 01A
REGS/0C000 REGISTER/PSW DIFFERENCE FOR R0C: 000
RIDS/DSNTFRCVÆR RECOVERY ROUTINE CSECT NAME: DSNTFRCV
OTHER SERVICEABILITY INFORMATION
DATE ASSEMBLED: 04/26/07
MODULE LEVEL: UK24490
SUBFUNCTION: RDS RSCTCACH
SERVICEABILITY INFORMATION NOT PROVIDED BY THE RECOVERY ROUTINE
RECOVERY ROUTINE LABEL
TIME OF ERROR INFORMATION
PSW: 07742001 80000000 00000000 18CFB414
INSTRUCTION LENGTH: 02 INTERRUPT CODE: 000D
FAILING INSTRUCTION TEXT: 8910000C 0A0D18CF 9C200000
We have found out which sql that causes this abend, and it is a prepare of a dynamic sql with one parameter marker. When we remove the parameter marker (question mark) and use a static variable instead, the sql works fine. BUT a lot of other sql's do have parameter markers and gets prepared and runs ok... So it seems to be a combination of "things" that causes the prepare to abend in some cases. We've searched the IBM website for any APAR's that cold apply but havn't found any.
Any help would be much appreciated!

Arild Løkke


The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Max Scarpa

Re: 007E0005 abend in DSNXGRDS.DSNXGDT2
(in response to Arild Løkke)
It seems that the level of module is a new function ergo it could be a
bug. I think you'd open (probably you did it already) a PMR (=
Pleeeaasesse Make (it) Run).

I found a similar error in the same LOC in IBM knowledge database but it's
for native SQL procedure.

Max Scarpa






Arild Løkke <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
17/01/2008 13.54
Please respond to
DB2 Database Discussion list at IDUG <[login to unmask email]>


To
[login to unmask email]
cc

Subject
[DB2-L] 007E0005 abend in DSNXGRDS.DSNXGDT2






Hi all,
We have just upgraded to DB2 9 CM mode (z/os) and are experiencing a lot
of 00E70005 abends in our test system. We are running a datasharing
environment with 2 members which only the first member is migrated to v9
CM mode. z/os level is 1.8.
This is what we see in dsnMSTR:
DSNL027I -DB2T SERVER DISTRIBUTED AGENT WITH 088
LUWID=P248FDE1.G1BE.C1CF8A24FF4E=23839
THREAD-INFO=TESTGEN:vswsbsa:testgen:db2jcc_application
RECEIVED ABEND=04E
FOR REASON=00E70005
And this is what we see inn dsnDBM1:
IEA794I SVC DUMP HAS CAPTURED: 054
DUMPID=012 REQUESTED BY JOB (DB2TDIST)
DUMP TITLE=DB2T,ABND=04E-00E70005,U=TESTGEN ,M=(C),C=910.LOCN=:
:146.72.250.2 ,LOC=DSNXGRDS.DSNXGDT2:M204
And this is what we see in sys1.logrec:
SEARCH ARGUMENT ABSTRACT
PIDS/5740XYR00 RIDS/DSNXGRDS&AElig;L RIDS/DSNXGDT2 AB/S004E PRCS/00E70005
REGS/0C000 RIDS/DSNTFRCV&AElig;R
SYMPTOM DESCRIPTION
------- -----------
PIDS/5740XYR00 PROGRAM ID: 5740XYR00
RIDS/DSNXGRDS&AElig;L LOAD MODULE NAME: DSNXGRDS
RIDS/DSNXGDT2 CSECT NAME: DSNXGDT2
AB/S004E SYSTEM ABEND CODE: 004E
PRCS/00E70005 ABEND REASON CODE: 00E70005
REGS/0E01A REGISTER/PSW DIFFERENCE FOR R0E: 01A
REGS/0C000 REGISTER/PSW DIFFERENCE FOR R0C: 000
RIDS/DSNTFRCV&AElig;R RECOVERY ROUTINE CSECT NAME: DSNTFRCV
OTHER SERVICEABILITY INFORMATION
DATE ASSEMBLED: 04/26/07
MODULE LEVEL: UK24490
SUBFUNCTION: RDS RSCTCACH
SERVICEABILITY INFORMATION NOT PROVIDED BY THE RECOVERY ROUTINE
RECOVERY ROUTINE LABEL
TIME OF ERROR INFORMATION
PSW: 07742001 80000000 00000000 18CFB414
INSTRUCTION LENGTH: 02 INTERRUPT CODE: 000D
FAILING INSTRUCTION TEXT: 8910000C 0A0D18CF 9C200000
We have found out which sql that causes this abend, and it is a prepare of
a dynamic sql with one parameter marker. When we remove the parameter
marker (question mark) and use a static variable instead, the sql works
fine. BUT a lot of other sql’s do have parameter markers and gets prepared
and runs ok… So it seems to be a combination of “things” that causes the
prepare to abend in some cases. We’ve searched the IBM website for any
APAR’s that cold apply but havn’t found any.
Any help would be much appreciated!

Arild Løkke


The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list archives, the FAQ, and delivery preferences are at www.idug.org under
the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG
conference information, and much more.
If you have not yet signed up for Basic Membership in IDUG, available at
no cost, click on Member Services

Avram Friedman

Re: 007E0005 abend in DSNXGRDS.DSNXGDT2
(in response to Max Scarpa)
Arild
You might want to report the problem to IBM.

I did a quick search on IBMLINK for "DB2 F204"
Found PK53081 that seems to match




APAR Title
ABND04E RC00E70005 DSNXGDT2M204 IN SQLPL / UDF WITH PARMS CHAR()
GRAPHIC() BLOB() FLOAT() DECIMAL() INSTEAD OF SQLCODE604


The Discription
Error description
CREATE PROCEDURE PROC1(IN V1 VARCHAR(), OUT V2 CHAR())
LANGUAGE SQL
BEGIN SET V2 = '2'; END

or use of any parm with len of 0, like
graphic(), vargraphic(), dbclob(), blob(), clob(), float() and
decimal() results in

V91A,ABND=04E-00E70005,U=SYSADM
,M=(N),C=910.LOCN=::192.168.1.1 ,LOC=DSNXGRDS.DSNXGDT2:M204
.
Instead abend, SQLCODE604, -604 should be issued.



Avram Friedman


On Thu, 17 Jan 2008 13:54:27 +0100, Arild Løkke <[login to unmask email]> wrote:

>Hi all,
>We have just upgraded to DB2 9 CM mode (z/os) and are experiencing a lot
of 00E70005 abends in our test system. We are running a datasharing
environment with 2 members which only the first member is migrated to v9 CM
mode. z/os level is 1.8.
>This is what we see in dsnMSTR:
>DSNL027I -DB2T SERVER DISTRIBUTED AGENT WITH 088
> LUWID=P248FDE1.G1BE.C1CF8A24FF4E=23839
> THREAD-INFO=TESTGEN:vswsbsa:testgen:db2jcc_application
> RECEIVED ABEND=04E
> FOR REASON=00E70005
>And this is what we see inn dsnDBM1:
>IEA794I SVC DUMP HAS CAPTURED: 054
>DUMPID=012 REQUESTED BY JOB (DB2TDIST)
>DUMP TITLE=DB2T,ABND=04E-00E70005,U=TESTGEN ,M=(C),C=910.LOCN=:
> :146.72.250.2 ,LOC=DSNXGRDS.DSNXGDT2:M204
>And this is what we see in sys1.logrec:
>SEARCH ARGUMENT ABSTRACT
> PIDS/5740XYR00 RIDS/DSNXGRDSƌ RIDS/DSNXGDT2 AB/S004E
PRCS/00E70005
> REGS/0C000 RIDS/DSNTFRCVƒ
> SYMPTOM DESCRIPTION
> ------- -----------
> PIDS/5740XYR00 PROGRAM ID: 5740XYR00
> RIDS/DSNXGRDSƌ LOAD MODULE NAME: DSNXGRDS
> RIDS/DSNXGDT2 CSECT NAME: DSNXGDT2
> AB/S004E SYSTEM ABEND CODE: 004E
> PRCS/00E70005 ABEND REASON CODE: 00E70005
> REGS/0E01A REGISTER/PSW DIFFERENCE FOR R0E: 01A
> REGS/0C000 REGISTER/PSW DIFFERENCE FOR R0C: 000
> RIDS/DSNTFRCVƒ RECOVERY ROUTINE CSECT NAME: DSNTFRCV
>OTHER SERVICEABILITY INFORMATION
> DATE ASSEMBLED: 04/26/07
> MODULE LEVEL: UK24490
> SUBFUNCTION: RDS RSCTCACH
>SERVICEABILITY INFORMATION NOT PROVIDED BY THE RECOVERY ROUTINE
> RECOVERY ROUTINE LABEL
>TIME OF ERROR INFORMATION
> PSW: 07742001 80000000 00000000 18CFB414
> INSTRUCTION LENGTH: 02 INTERRUPT CODE: 000D
> FAILING INSTRUCTION TEXT: 8910000C 0A0D18CF 9C200000
>We have found out which sql that causes this abend, and it is a prepare of a
dynamic sql with one parameter marker. When we remove the parameter
marker (question mark) and use a static variable instead, the sql works fine.
BUT a lot of other sql's do have parameter markers and gets prepared and
runs ok... So it seems to be a combination of "things" that causes the prepare
to abend in some cases. We've searched the IBM website for any APAR's that
cold apply but havn't found any.
>Any help would be much appreciated!
>
>Arild L?>
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG
Online Learning Center, Tech Library and Code Place, see the latest IDUG
conference information, and much more. If you have not yet signed up for
Basic Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Arild L&oslash;kke

007E0005 abend in DSNXGRDS.DSNXGDT2
(in response to Avram Friedman)
Hi

We have looked at PK53081 and this seems to apply only to creating native sql procedures and in our case the abends happens on SELECT sql's.

Arild

-----Original Message-----
From: Avram Friedman [mailto:[login to unmask email]
Sent: 17. januar 2008 14:46
To: [login to unmask email]; Arild Løkke
Subject: Re: 007E0005 abend in DSNXGRDS.DSNXGDT2

Arild
You might want to report the problem to IBM.

I did a quick search on IBMLINK for "DB2 F204"
Found PK53081 that seems to match




APAR Title
ABND04E RC00E70005 DSNXGDT2M204 IN SQLPL / UDF WITH PARMS CHAR()
GRAPHIC() BLOB() FLOAT() DECIMAL() INSTEAD OF SQLCODE604


The Discription
Error description
CREATE PROCEDURE PROC1(IN V1 VARCHAR(), OUT V2 CHAR())
LANGUAGE SQL
BEGIN SET V2 = '2'; END

or use of any parm with len of 0, like
graphic(), vargraphic(), dbclob(), blob(), clob(), float() and
decimal() results in

V91A,ABND=04E-00E70005,U=SYSADM
,M=(N),C=910.LOCN=::192.168.1.1 ,LOC=DSNXGRDS.DSNXGDT2:M204
.
Instead abend, SQLCODE604, -604 should be issued.



Avram Friedman


On Thu, 17 Jan 2008 13:54:27 +0100, Arild Løkke <[login to unmask email]> wrote:

>Hi all,
>We have just upgraded to DB2 9 CM mode (z/os) and are experiencing a lot
of 00E70005 abends in our test system. We are running a datasharing
environment with 2 members which only the first member is migrated to v9 CM
mode. z/os level is 1.8.
>This is what we see in dsnMSTR:
>DSNL027I -DB2T SERVER DISTRIBUTED AGENT WITH 088
> LUWID=P248FDE1.G1BE.C1CF8A24FF4E=23839
> THREAD-INFO=TESTGEN:vswsbsa:testgen:db2jcc_application
> RECEIVED ABEND=04E
> FOR REASON=00E70005
>And this is what we see inn dsnDBM1:
>IEA794I SVC DUMP HAS CAPTURED: 054
>DUMPID=012 REQUESTED BY JOB (DB2TDIST)
>DUMP TITLE=DB2T,ABND=04E-00E70005,U=TESTGEN ,M=(C),C=910.LOCN=:
> :146.72.250.2 ,LOC=DSNXGRDS.DSNXGDT2:M204
>And this is what we see in sys1.logrec:
>SEARCH ARGUMENT ABSTRACT
> PIDS/5740XYR00 RIDS/DSNXGRDSƌ RIDS/DSNXGDT2 AB/S004E
PRCS/00E70005
> REGS/0C000 RIDS/DSNTFRCVƒ
> SYMPTOM DESCRIPTION
> ------- -----------
> PIDS/5740XYR00 PROGRAM ID: 5740XYR00
> RIDS/DSNXGRDSƌ LOAD MODULE NAME: DSNXGRDS
> RIDS/DSNXGDT2 CSECT NAME: DSNXGDT2
> AB/S004E SYSTEM ABEND CODE: 004E
> PRCS/00E70005 ABEND REASON CODE: 00E70005
> REGS/0E01A REGISTER/PSW DIFFERENCE FOR R0E: 01A
> REGS/0C000 REGISTER/PSW DIFFERENCE FOR R0C: 000
> RIDS/DSNTFRCVƒ RECOVERY ROUTINE CSECT NAME: DSNTFRCV
>OTHER SERVICEABILITY INFORMATION
> DATE ASSEMBLED: 04/26/07
> MODULE LEVEL: UK24490
> SUBFUNCTION: RDS RSCTCACH
>SERVICEABILITY INFORMATION NOT PROVIDED BY THE RECOVERY ROUTINE
> RECOVERY ROUTINE LABEL
>TIME OF ERROR INFORMATION
> PSW: 07742001 80000000 00000000 18CFB414
> INSTRUCTION LENGTH: 02 INTERRUPT CODE: 000D
> FAILING INSTRUCTION TEXT: 8910000C 0A0D18CF 9C200000
>We have found out which sql that causes this abend, and it is a prepare of a
dynamic sql with one parameter marker. When we remove the parameter
marker (question mark) and use a static variable instead, the sql works fine.
BUT a lot of other sql's do have parameter markers and gets prepared and
runs ok... So it seems to be a combination of "things" that causes the prepare
to abend in some cases. We've searched the IBM website for any APAR's that
cold apply but havn't found any.
>Any help would be much appreciated!
>
>Arild L?>
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG
Online Learning Center, Tech Library and Code Place, see the latest IDUG
conference information, and much more. If you have not yet signed up for
Basic Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms