• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Re: Calling JDE from external menus

rtuohy

Member
Re: Calling JDE from external menus

John,

To see what the CL is actually doing, and to understand what I am getting
at, please try the following very small CL and run it under source debug
with break points on the GOTO ENDPGM and the RTVJOBA. You will notice that
the individual MONMSG overrides the global (ISDB does not stop at labels).
This is what I am talking about when I suggest a catchall. Obviously you
have to ensure that you catch all the errors you need to trap at command
level, but the point is that if you do not have to trap the errors that do
not matter, the global MONMSG allows the program to continue quite happily
doing what has to be done without a considerable amount of unnecessary code
which can make the program difficult to read and without falling over
because the programmer has neglected to trap every eventuality.
PGM
DCL VAR(&JOB) TYPE(*CHAR) LEN(10)
MONMSG MSGID(CPF0000 CPC0000 CPD0000) EXEC(GOTO +
CMDLBL(ABEND))
CALL PGM(JTEST) /* NON EXISTENT PROGRAM */
MONMSG MSGID(CPF0000 CPC0000 CPD0000) EXEC(GOTO +
CMDLBL(EXIT))
ABEND:
GOTO CMDLBL(ENDPGM)
EXIT:
RTVJOBA JOB(&JOB)
ENDPGM: ENDPGM
>

I do understand what you are getting at, and obviously this technique should
not be used without an understanding of how it works, but feel you are
negating a perfectly valid use of MONMSG. In fact, if you look at most of
the JDE programs which use the global to point to ABEND, you will notice the
SNDPGMMSG has a separate MONMSG attached to stop it being picked up by the
global MONMSG and looping round the ABEND. Thus you can trap and act on
individual errors while still using the global to handle what is not
important.

Regards
Ron
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
 
G

Guest

Guest
Re: Calling JDE from external menus

Ron,

I think we're in basic agreement here. This line from your code
sample:

> MONMSG MSGID(CPF0000 CPC0000 CPD0000) EXEC(GOTO +
> CMDLBL(ABEND))

is one example of how errors should be handled. Your MONMSG does
something with the errors that it catches (the something being: GOTO
ABEND).


This line (which I spotted in the original program):

MONMSG MSGID(CPF0000)

Is what generated my original complaint because it doesn't do anything
with the errors that it traps (other than hide them from the view of
the user and the support staff). I'm sure you agree that their are
major differences in how these two lines of code would affect
operations. Your sample code is another example of how to correctly
handle errors in a CL program. A MONMSG MSGID(CPF0000) without an
error handling directive is dangerous.

jte


--
John Earl - VP / CTO
The PowerTech Group
Kent, Washington - 253-872-7788
johnearl@powertechgroup.com
www.400security.com
--
 

rtuohy

Member
Re: Calling JDE from external menus

John,

You've missed my point which was to show that despite a global MONMSG, the
individual MONMSG took precedence, as my program ably illustrates, not to
show that a GOTO was necessary. The purpose of the ABEND was to show on
debug exactly which code was being processed. I think we'll just have to
agree to disagree on this one, but when one of your programs falls over
because you haven't dotted every 'i' and crossed every 't', remember this
conversation. I've learned from experience, and will continue to use
'dangerous' code which gets the job done. I say again - if you trap the
fatal errors, the non fatal errors can look after themselves with a global
MONMSG no GOTO. If you are unable to work out which errors are fatal and
need trapping, yes, the global catchall is dangerous, otherwise it is a
perfectly valid process. If you were in a position to run the Euro
conversion PTF, you would understand exactly what I was getting at when the
whole thing bombed out due to the absence of the Japanese Date Era file (not
used in Europe normally, of no consequence, and no reason for a night's
processing to fail) necessitating regenerating the environment, and running
a repeat, because the programmer thought he was omnipotent and didn't put in
either a specific or a global catchall.

Regards
Ron

>
>Ron,
>
>I think we're in basic agreement here. This line from your code
>sample:
>
> > MONMSG MSGID(CPF0000 CPC0000 CPD0000) EXEC(GOTO +
> > CMDLBL(ABEND))
>
>is one example of how errors should be handled. Your MONMSG does
>something with the errors that it catches (the something being: GOTO
>ABEND).
>
>
>This line (which I spotted in the original program):
>
> MONMSG MSGID(CPF0000)
>
>Is what generated my original complaint because it doesn't do anything
>with the errors that it traps (other than hide them from the view of
>the user and the support staff). I'm sure you agree that their are
>major differences in how these two lines of code would affect
>operations. Your sample code is another example of how to correctly
>handle errors in a CL program. A MONMSG MSGID(CPF0000) without an
>error handling directive is dangerous.
>
>jte
>
>
>--
>John Earl - VP / CTO
>The PowerTech Group
>Kent, Washington - 253-872-7788
>johnearl@powertechgroup.com
>www.400security.com
>--
>
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=W&Number=6934
>*************************************************************
>This is the JDEList World Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
 
Top