Re: COBOL400-L Digest, Vol 14, Issue 9

"COBOL400-L" <cobol400-l-bounces@xxxxxxxxxxxx> wrote on 06/04/2016
01:00:03 PM:

----- Message from Richard Schoen <Richard.Schoen@xxxxxxxxxxxxxxx>
on Fri, 3 Jun 2016 17:33:02 +0000 -----

To:

"cobol400-l@xxxxxxxxxxxx" <cobol400-l@xxxxxxxxxxxx>

Subject:

Re: [COBOL400-L] Trapping QSNDDTAQ errors in Cobol program

Do it with a CL or RPG program call if you need to trap specific CPF

errors.

Regards,


Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com


----------------------------------------------------------------------

message: 1
date: Thu, 2 Jun 2016 19:34:35 -0400
from: Vinay Gavankar <vinaygav@xxxxxxxxx>
subject: [COBOL400-L] Trapping QSNDDTAQ errors in Cobol program

Hi,

I am an occasional Cobol user, and was wondering how I would go
about trapping an error returned by the QSNDDTAQ API called from a
Cobol program.

We want to trap the condition when Data Queue is full (CPF950A) and
go in a DLYW before trying again.

I think calling a CL program from the Cobol to call the API, instead
of calling the API directly might work, but I have been told to
check if it is possible to do without adding a new CL program call.

I tried ON EXCEPTION clause, but that seems to trap only errors on
the Call command (program not found, parameter mismatch etc), so
does not work in this case.

Any suggestions, guidance will be greatly appreciated.

Vinay

"COBOL400-L" <cobol400-l-bounces@xxxxxxxxxxxx> wrote on 06/04/2016
01:00:03 PM:

----- Message from Richard Schoen <Richard.Schoen@xxxxxxxxxxxxxxx>
on Fri, 3 Jun 2016 17:33:02 +0000 -----

To:

"cobol400-l@xxxxxxxxxxxx" <cobol400-l@xxxxxxxxxxxx>

Subject:

Re: [COBOL400-L] Trapping QSNDDTAQ errors in Cobol program

Do it with a CL or RPG program call if you need to trap specific CPF

errors.

Regards,


Richard Schoen

That's part of the equation. There's no IBM provided command to send dtaq
entries. So you can't just do a MONMSG.

This can be done in COBOL using the message APIs, but it is easier in CL.
The basic flow is 1) Send a message and save the key of the message sent.
2) Call the API. 3) Then walk through the messages using RCVMSG starting
with the key from step 1.

Here's an example of the coding: (I've hardcoded the dataq and library
names.)

PGM PARM(&DATA &DATALEN)

DCL VAR(&FOREVER) TYPE(*LGL)
DCL VAR(&STRKEYVAR) TYPE(*CHAR) LEN(4)
DCL VAR(&KEYVAR) TYPE(*CHAR) LEN(4)
DCL VAR(&LSTKEYVAR) TYPE(*CHAR) LEN(4)
DCL VAR(&DATA) TYPE(*CHAR) LEN(200)
DCL VAR(&DATALEN) TYPE(*DEC) LEN(5 0)

DCL VAR(&MSGID) TYPE(*CHAR) LEN(7)

SNDPGMMSG MSG('Temporary message anchor') TOPGMQ(*SAME) +
KEYVAR(&KEYVAR)

CHGVAR VAR(&STRKEYVAR) VALUE(&KEYVAR)

CALL PGM(QSNDDTA) PARM(DATAQ DATAQLIB &DATALEN &DATA)

DOUNTIL COND(&FOREVER)
/* Use the previous messages key to locate the next
message */
CHGVAR VAR(&LSTKEYVAR) VALUE(&KEYVAR)
RCVMSG MSGTYPE(*NEXT) MSGKEY(&LSTKEYVAR) +
KEYVAR(&KEYVAR) MSGID(&MSGID)
/* I'm leaving the message on the queue RMV(*NO) */
/* -- The default is to remove it RMV(*YES) */
IF COND(&MSGID *EQ 'CPF950A') THEN(DO)
PROCESSING {Do whatever you need done here}
/* Since I've handled the message, I'm removing it now. */
RMVMSG MSGKEY(&KEYVAR)
LEAVE
ENDDO
ENDDO

/* Clean up the temporary anchor message */
RMVMSG MSGKEY(STRKEYVAR)

ENDPGM


Of course you can tailor the basic logic as needed. Another option would
be to set up a command that did the QSNDDTAQ and see if you can do a
MONMSG for them or write the command processing program to send escape
messages so they can be monitored.

HTH,
Michael Quigley
Computer Services
The Way International
www.TheWay.org