CONTROL ERRORS RETURN and other means of catching errors

thoma...@swedbank.se

unread,

Oct 3, 2011, 6:15:36 AM10/3/11

to

Hi,

Are any way to catch errors like
" ISPN106
Ddname not allocated
Ddname 'APCPLIB' specified on LIBDEF service not allocated.

Current dialog statement:
LIBDEF ISPPLIB LIBRARY ID(APCPLIB"

so I don't "fall out" of the calling "parent" rexx.

The rexx does:

Address Ispexec 'CONTROL ERRORS RETURN'
Address Ispexec 'SELECT CMD(%APC) SUSPEND'

(At the error above I "fall out" to ISPF primary menu.)

(There is also an accompanying (following) error that I think is of lesser importance for my problem:
BPXP018I THREAD 28CF6E0000000001, IN PROCESS 17236388, ENDED
WITHOUT BEING UNDUBBED WITH COMPLETION CODE 0013E000
, AND REASON CODE 00000000.)

As this rexx services a menu that is supposed to be common for all applications I would prefer to keep the control despite a failing application.
Any suggestions ?

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

John P Kalinich

unread,

Oct 3, 2011, 7:59:21 AM10/3/11

to

Thomas,

Have you tried adding the CONTROL ERRORS RETURN to the %APC exec?

Regards,
John K

From: thoma...@SWEDBANK.SE

To: ISP...@listserv.nd.edu

Date: 10/03/2011 05:15 AM

Subject: CONTROL ERRORS RETURN and other means of catching errors

thoma...@swedbank.se

unread,

Oct 3, 2011, 8:16:50 AM10/3/11

to

No, as the point of my effort is to not have to rely on the execs belonging to the applications.
There is a lot of applications and they are changing very often (new versions from the vendors or new app execs coming in because of changes of vendors etc.).

I want to have a robust menu "infra structure" so application failures don't wreak havoc with the users ISPF setup (current screens, applications etc.).

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För John P
> Kalinich
> Skickat: den 3 oktober 2011 13:59
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: CONTROL ERRORS RETURN and other means of catching errors

Ward Able, Grant

unread,

Oct 3, 2011, 9:25:09 AM10/3/11

to

Thomas - have you explored OUTTRAP and MSG ?

Regards - Grant.
Telephone Internal: x1496 London
Telephone External: +44 (0)207 650 1496

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

Steve Coalbran

unread,

Oct 3, 2011, 9:26:05 AM10/3/11

to

Hej Thomas
Sorry, I never have this problem - everything here works perfectly! 8-D

So this is probably unhelpful guesswork but...
I would suspect that the error is localized to the "APC" task,
But might a...
"FAILURE: RETURN" at the foot of the caller routine
or...
"SIGNAL OFF FAILURE" at its head
do any good - or just royally screw things up ?

Two other SELECT options I have never touched are BARRIER and NEST.
NEST may help pass back GLOBAL ERRORS (If you're really lucky!!!)

:-/

> Date: Mon, 3 Oct 2011 14:15:30 +0200
> From: thoma...@SWEDBANK.SE
> Subject: SV: CONTROL ERRORS RETURN and other means of catching errors
> To: ISP...@LISTSERV.ND.EDU

Steve Coalbran

unread,

Oct 3, 2011, 9:28:23 AM10/3/11

to

worth a try

CALL OUTTRAP "O."
mv = MSG("ON")
....call your lower level....
mv = MSG(mv)

CALL OUTTRAP "OFF"
DO i = 1 TO O.0
SAY o.i
END

:-/

> Date: Mon, 3 Oct 2011 13:24:18 +0000
> From: GWar...@DTCC.COM
> Subject: Re: CONTROL ERRORS RETURN and other means of catching errors
> To: ISP...@LISTSERV.ND.EDU

thoma...@swedbank.se

unread,

Oct 3, 2011, 9:36:11 AM10/3/11

to

Ok, I worded it badly. With "catch" I meant to *get the control* in case of an error - instead of "falling out" of the rexx.
Here I don't care of the cause of error. Or even that it's an error.

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----

> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Ward Able,
> Grant
> Skickat: den 3 oktober 2011 15:24

thoma...@swedbank.se

unread,

Oct 3, 2011, 9:40:03 AM10/3/11

to

Tried NEST - no change.

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Steve
> Coalbran
> Skickat: den 3 oktober 2011 15:26
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: SV: CONTROL ERRORS RETURN and other means of catching errors

thoma...@swedbank.se

unread,

Oct 3, 2011, 9:42:04 AM10/3/11

to

Se my answer to Ward.

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----

> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Steve
> Coalbran
> Skickat: den 3 oktober 2011 15:28

Steve Coalbran

unread,

Oct 3, 2011, 9:42:31 AM10/3/11

to

All I can suggest is try out a combination of: NEST, BARRIER, OUTTRAP....- or all !

If I get some time (or get bored) I will try and develop something that fails horribly 8-D)
...then I can try some combinations out too.

Or you might get some helpful response from someone who actually knows what they are talking about, say from Perth ? 8-O

/S

> Date: Mon, 3 Oct 2011 15:35:22 +0200
> From: thoma...@SWEDBANK.SE

> Subject: SV: CONTROL ERRORS RETURN and other means of catching errors

> To: ISP...@LISTSERV.ND.EDU

thoma...@swedbank.se

unread,

Oct 3, 2011, 9:46:18 AM10/3/11

to

Well I have tried most of it. I think that the point is that it's ISPF that detects the error - so it seems that it by BAD (Bad As Designed) behaves by purpose like this.
A pity.

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----

> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Steve
> Coalbran
> Skickat: den 3 oktober 2011 15:42
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: SV: CONTROL ERRORS RETURN and other means of catching errors

Bob Stark

unread,

Oct 3, 2011, 10:34:28 AM10/3/11

to

I suspect that the REXX error handler could save your program.

CALL ON ERROR NAME ERRHANDLE
SIGNAL ON SYNTAX NAME SYNHANDLE

...
code that might fail while calling ISPF
...

ERRHANDLE:
...
Code that gets control if a host command returns a non-zero return code.
With CALL ON ERROR, you can return to the point of failure

You can handle a syntax error, and signal back to the top of your program to
retry, CALL ON SYNTAX is not supported, so you cannot return back to the
point of error

thoma...@swedbank.se

unread,

Oct 3, 2011, 10:48:19 AM10/3/11

to

Nope, that didn't help. Probably because the rexx is

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

started thru "SELECT CMD(%REXX)".

> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Bob Stark
> Skickat: den 3 oktober 2011 16:34

> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: CONTROL ERRORS RETURN and other means of catching errors
>

thoma...@swedbank.se

unread,

Oct 3, 2011, 10:48:19 AM10/3/11

to

A new try:

Nope, that didn't help. Probably because the rexx is started thru "SELECT CMD(%REXX)".

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Bob Stark
> Skickat: den 3 oktober 2011 16:34
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: CONTROL ERRORS RETURN and other means of catching errors
>

Steve Coalbran

unread,

Oct 4, 2011, 3:27:20 AM10/4/11

to

Hej Thomas,
is it the same if you start it from a CLIST (OMG!!! did I say that !?!?!)

PROC 0
CONTROL MAIN NOMSG
ERROR DO
SET RC = &LASTCC
CONTROL MSG
WRITE An error occurred but I caught it!
EXIT CODE(&LASTCC) QUIT
END
ISPEXEC SELECT CMD(%REXX)

> Date: Mon, 3 Oct 2011 16:47:50 +0200
> From: thoma...@SWEDBANK.SE
> Subject: SV: CONTROL ERRORS RETURN and other means of catching errors
> To: ISP...@LISTSERV.ND.EDU

Steve Coalbran

unread,

Oct 4, 2011, 4:39:06 AM10/4/11

to

Hej Thomas,
I tried a CLIST driver...

-IPT- EDIT SE16661.USER.CLIST(QDRIVE) - 01.03
Command ===>
****** ***************************** Top of Data *****
000001 PROC 0
000002 WRITE QDRIVE STARTING
000003 CONTROL MAIN MSG PROMPT LIST
000004 ERROR DO
000005 SET RC = &LASTCC
000006 WRITE QFAIL TRIGGERED ERROR RC=&RC
000007 EXIT CODE(&RC) QUIT
000008 END
000009 ISPEXEC CONTROL ERRORS CANCEL
000010 ISPEXEC SELECT CMD(%QFAIL)
000011 WRITE QFAIL ENDED RC=&LASTCC
000012 EXIT CODE(0)
****** **************************** Bottom of Data ***

with a REXX designed to error...
-IPT- EDIT SE16661.USER.EXEC(QFAIL) - 01.04
Command ===>
****** ***************************** Top of Data *****
000001 /*REXX*/ TRACE "R"
000002 ADDRESS ISPEXEC
000003 "CONTROL ERRORS RETURN"
000004 "DISPLAY PANLE(SPLATT)"
****** **************************** Bottom of Data ***

which gives ...

QDRIVE STARTING
ISPEXEC CONTROL ERRORS CANCEL
ISPEXEC SELECT CMD(%QFAIL)
2 *-* ADDRESS ISPEXEC
3 *-* "CONTROL ERRORS RETURN"
>>> "CONTROL ERRORS RETURN"
4 *-* "DISPLAY PANLE(SPLATT)"
>>> "DISPLAY PANLE(SPLATT)"
+++ RC(20) +++
QFAIL ENDED RC=0
***

EDITing the FAIL member with...
000005 EXIT RC

I get...
. . .
5 *-* EXIT RC
>>> "20"
QFAIL TRIGGERED ERROR RC=20

Changing the FAILing member to have...
000003 "CONTROL ERRORS RETURN"
to
000003 "CONTROL ERRORS CANCEL"

does NOT return control to QDRIVE...

QDRIVE STARTING
ISPEXEC CONTROL ERRORS CANCEL
ISPEXEC SELECT CMD(%QFAIL)
2 *-* ADDRESS ISPEXEC
3 *-* "CONTROL ERRORS CANCEL"
>>> "CONTROL ERRORS CANCEL"
4 *-* "DISPLAY PANLE(SPLATT)"
>>> "DISPLAY PANLE(SPLATT)"
***

***

> Date: Mon, 3 Oct 2011 16:47:50 +0200
> From: thoma...@SWEDBANK.SE

> Subject: SV: CONTROL ERRORS RETURN and other means of catching errors
> To: ISP...@LISTSERV.ND.EDU

thoma...@swedbank.se

unread,

Oct 4, 2011, 4:43:48 AM10/4/11

to

The same. It seems that ISPF is the sole commander here...

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----

> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Steve
> Coalbran
> Skickat: den 4 oktober 2011 09:25
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: SV: CONTROL ERRORS RETURN and other means of catching errors

thoma...@swedbank.se

unread,

Oct 4, 2011, 4:47:39 AM10/4/11

to

Yes, but have You tried with an error like this ?:

S000TBE E5DELTA ISPF Dialog Error
Command ===>

******************************************************************************
* ISPN106 *
* *
* Ddname not allocated *
* Ddname 'APCPLIB' specified on LIBDEF service not allocated. *
* *
* *
* *
* *
* *
* *
* Current dialog statement: *
* LIBDEF ISPPLIB LIBRARY ID(APCPLIB) *
* *
* Enter HELP command for further information regarding this error. *
* Press ENTER key to terminate the dialog. *
* *
* *
* *
* *
******************************************************************************

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----

> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Steve
> Coalbran

> Skickat: den 4 oktober 2011 10:37
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: SV: CONTROL ERRORS RETURN and other means of catching errors

Steve Coalbran

unread,

Oct 4, 2011, 4:57:44 AM10/4/11

to

If I change to CONTROL ERRORS RETURN - which is pretty normal?
AND I keep the EXIT RC in the failing routine, I get...

QDRIVE STARTING
ISPEXEC CONTROL ERRORS CANCEL
ISPEXEC SELECT CMD(%QFAIL)
2 *-* ADDRESS ISPEXEC
3 *-* "CONTROL ERRORS RETURN"
>>> "CONTROL ERRORS RETURN"

4 *-* "LIBDEF ISPPLIB LIBRARY ID(APCPLIB)"
>>> "LIBDEF ISPPLIB LIBRARY ID(APCPLIB)"
+++ RC(16) +++
5 *-* EXIT RC
>>> "16"
QFAIL TRIGGERED ERROR RC=16
***

so it does appear to TRAP the error

> Date: Tue, 4 Oct 2011 10:45:39 +0200
> From: thoma...@SWEDBANK.SE
> Subject: SV: SV: CONTROL ERRORS RETURN and other means of catching errors

thoma...@swedbank.se

unread,

Oct 4, 2011, 5:33:51 AM10/4/11

to

But if QFAIL don't have CONTROL ERRORS RETURN - and You don't have the possibility to add that there...

Regards,
Thomas Berg
_________________________________________
Thomas Berg Specialist A M SWEDBANK

> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För Steve
> Coalbran

> Skickat: den 4 oktober 2011 10:56
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: SV: SV: CONTROL ERRORS RETURN and other means of catching errors

adrianstern

unread,

Nov 7, 2011, 4:14:35 AM11/7/11

to

I wonder if you're in USS 'cos under tso I keep control with control
errors return and just get an error message IKJ56500I
unfortunately I don't think this can be suppressed
Adrian

Wilco Boschman

unread,

Nov 30, 2011, 3:31:47 PM11/30/11

to

Hello,

I suspect the returncode of your ISPF (rexx) is not returned because
ISPF ends with a returncode of 0. If you want your rexx returncode
returned, you have to set a special ISPF variable ZISPFRC to the desired
returncode. Then, you can end your REXX. The value of ZISPFRC will be
used as the returncode when ISPF ends.

Hope this helps

Wilco Boschman
z/OS System programmer

Op 03-10-11 16:34, Bob Stark schreef: