× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



PGM1 has to be written to accept an indicator as the parameter, then it has to set that indicator *ON when there is an error - NOT send the message.

Of course, IF it is just a *DIAG or *INFO type of message, you can still send it, you just won't be using it without more code than this, to retrieve it.

On 12/18/2019 7:32 AM, techie21 IT wrote:
actually main thing is this logical indicator fails when i tried this
advised program and unnecessarily going to pgm2 evenif pgm1 had some
customized error messages like 'record not found'
'unable to open file'...etc.
means it has some if else conditions based on these conditions these rpgle
programs throw these customized error messages.
how to use this &errorcode where to put it i mean any example for this
please?

Thanks

On Wed, Dec 18, 2019 at 2:04 PM Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

To expand even a little more - if you have more than one condition that
could mean failure in the RPG, use an error code variable, say &ERRCODE
*CHAR(1) or whatever length you need. Then use a series of IF/DO/ENDDO
constructs to handle each one.

Vern

On 12/18/2019 7:11 AM, Vernon Hamberg wrote:
To expand on this - if you know the messages PGM1 will send (as
*ESCAPE in order to be monotpred), then put a MONMSG after the call to
PGM1 to catch them. In the MONMSG, use the EXEC parameter to execute a
DO loop.

PGM
MONMSG MSGID(CPF0000) EXEC(GOTO ERROR)
CALL PGM1
MONMSG MSG0001 EXEC(DO)
GOTO SKIP
ENDDO
CALL PGM2
SKIP:
RETURN
ERROR:
SNDPGMMSG MSGID(CPF9898) MSGF(QSYS/QCPFMSG) +
MSGDTA('Unexpected errors detected, see +
messages in job log') TOPGMQ(*PRV *) +
TOMSGQ(*TOPGMQ) MSGTYPE(*ESCAPE)
ENDPGM

You would still have the generic handler for unexpected CPF* errors.

Now I prefer what I think someone else suggested - use a "return code"
parameter, maybe as a *LGL if you are interested only in pass/fail.

PGM
DCL &ERROR *LGL
MONMSG MSGID(CPF0000) EXEC(GOTO ERROR)
CALL PGM1 &ERROR
IF (*NOT &ERROR) DO
CALL PGM2
ENDDO
RETURN
ERROR:
SNDPGMMSG MSGID(CPF9898) MSGF(QSYS/QCPFMSG) +
MSGDTA('Unexpected errors detected, see +
messages in job log') TOPGMQ(*PRV *) +
TOMSGQ(*TOPGMQ) MSGTYPE(*ESCAPE)
ENDPGM

I also prefer always using DO/ENDDO blocks - just in case I might add
code in the future.

HTH
Vern

On 12/18/2019 6:34 AM, Buck Calabro wrote:
On Wed, 18 Dec 2019 at 04:27, techie21 IT <techiei876@xxxxxxxxx> wrote:

For this I tried below code :-
PGM
MONMSG MSGID(CPF0000) EXEC(GOTO ERROR)
CALL PGM1
CALL PGM2
RETURN
ERROR:
SNDPGMMSG MSGID(CPF9898) MSGF(QSYS/QCPFMSG) +
MSGDTA('Unexpected errors detected, see +
messages in job log') TOPGMQ(*PRV *) +
TOMSGQ(*TOPGMQ) MSGTYPE(*ESCAPE)
ENDPGM

but it is unnecessarily itrying to execute PGM2 whereas it did not
bother
whether there were some errors found in PGM1 itself why is it happening
like this
The general approach seems fine, so that means the implementation is
the issue.
In PGM1, how are the errors 'thrown'?
If they are not *ESCAPE messages, the MONMSG in the CLP will not be
asserted and execution will continue.
Perhaps the 'error messages' are *DIAG or *INFO?
If that is the case, you'll need to set up a RCVMSG loop between CALL
PGM1 and CALL PGM2 to receive these types of messages.

If this reply did not seem helpful, please post the RPG code that is
'throwing the error message', or even better, write an entirely new,
tiny RPG program that simply throws a message of the kind you want to
trap in the CLP and post that. This way the list can run the exact
same code that you are.

--buck
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.