|
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:
midrange.com
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 / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
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.
