On 18/11/2006, at 7:10 PM, DMartin@xxxxxxxxxxxxx wrote:
I don't see any reason for a GOTO after a MONMSG when there is no
branch in the program logic regardless of the outcome of the command.
That kind of coding just adds unnecessary bytes to the source and
cycles to the execution (even if only about three of those).
I'm sure you don't see any reason. Thanks for letting me know in which
category to place you.
MONMSG at the global level should ALWAYS have a GOTO and corresponding
error logic to resignal the exception.
Global MONMSG should only ever be for CPF9999 or CPF0000 (in some
circumstances MCH0000 may also be acceptable). Reason being global
MONMSG can only run GOTO. GOTO lacks a RETURNTO or COMEFROM so there is
no clean way to continue execution.
MONMSG after a command should ALWAYS be followed by a RCVMSG to clean
up the job log. If you monitor and therefore handle the exception don't
leave the message cluttering up the job log. It's misleading to see
"Data area MYDTAARA not created" when it didn't cause a problem. Same
goes for "Data area MYDTAARA exists in MYLIB".
Anything else is simply lazy. Perhaps an example will make this
clearer. I've seen much CL like the following:
PGM
DCL &DATA *CHAR 50
MONMSG CPF1000
CRTDTAARA MYLIB/MYDTAARA TYPE(*CHAR) LEN(100)
/* Do other stuff */
RTVDTAARA MYLIB/MYDTAARA RTNVAR(&DATA)
/* Do other stuff here */
DLTDTAARA MYLIB/MYDTAARA
ENDPGM
The lazy programmer who wrote this is committing at least the following
sins:
1) Presuming that the most likely cause of error is the data area
already exists
2) Not handling failure due to missing library
3) Not handling failure due to insufficient authority
4) Not handling failure due to missing data area
5) Presuming the CRT was successful therefore the RCV and DLT will
also be successful
6) Not having a global error handler to catch and resignal unexpected
errors
Sin 1 causes the job log to contain unnecessary error messages. If it's
OK that the data area already exists then remove the exception from the
job log so it doesn't confuse later diagnosis of a real problem. Better
practice is to check for existence first and only create if not found.
Clean up both the "not found" exception and the "created successfully
messages.
Sins 2, 3, and 4 allow the program to continue even though a necessary
object is not found. Best case is a failure at some later point in the
program. Worst case is normal completion with no indication of a
problem.
Sin 5 might cause the program to fail at the end and send an
investigator down a spurious path until the real cause, much earlier in
the program, is discovered.
Sin 6 causes other exceptions that may be signalled to invoke the
default error handler which will send an inquiry message to the user
who is probably the least qualified to deal with such a message.
There is one exception: A menu driver program that catches all
exceptions from lower-level options and displays them in a message
sub-file may use a global CPF0000 with no corresponding GOTO because
the message sub-file will be used to display the message.
I'm sure you and a number of others will object to my comments but that
just means you're wrong. This isn't an argument about style choices.
It's simple: handle the expected exceptions, clean up after yourself,
and handle the unexpected conditions in a graceful manner. A global
MONMSG without an EXEC specified cannot satisfy these objectives.
Even the performance argument that all these CHKOBJ, MONMSG, and RCVMSG
operations will make the program run slower is spurious. Yes, the
program might run a teensy tiny bit slower but the time saved by not
having to examine misleading error messages in the job log outweighs
the performance gain.
Also, applications that expose the default exception handler to an end
user are simply sloppy. Much more professional to catch errors, collect
diagnostic material programmatically, notify the help desk
programmatically, and tell the end user that a problem occurred and
someone from IT will contact them shortly.
More work for the developer? True, but significantly more robust
applications as a result.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software AS/400 Technical Specialists
http://www.flybynight.com.au/
Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\
Fax: +61 3 9419 0175 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
