I believe in validity processing. I.e. SALARY > 0 AND <1000000 type things, unless done by the data source (such as DB2 validity constraints). So adding an IS NUMERIC doesn't seem like much of an addition to me.
I've used ON units in PL/I to trap errors. Does the latest COBOL have verbs to trap things like an S0C7. Or are you talking about LE exception handling? And, of course, there is the trade off of the CPU used testing before using, versus the overhead of setting up the condition handler, and it's invocation if an error occurs. In this case, processing millions of records, the "per record processed" cost of setting up the condition handler is likely miniscule compared to the total cost of processing. The overhead of the invocation if an error occurs depends on how "good" the data is. It is it 99+% good, it isn't much. If 50% of the records cause a trap, then it might be costly. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of John Gilmore > Sent: Thursday, August 02, 2012 2:11 PM > To: [email protected] > Subject: Re: File Processing > > John McKown writes > > <begin extract> > Why not fix your processing program to not abend? In COBOL, try > verifying the record data before processing it. Perhaps a IF NOT > NUMERIC type test. > <end extract> > > and it would be impossible to disagree with the substance of this > recommendation. > > There are, however, two very different ways to accomplish > this objective. > > One can, as John suggests, scrub the input data before they > are processed. > > Alternatively, one can arrange to handle input-data errors only if and > as they occur. Interrupt-driven condition handling of this sort, long > possible in PL/I, is now possible in COBOL too. > > The rationale for this second approach if of course that most input > data are not incorrect. Some are, and they must be detected and > corrected or set aside; but it is more efficient, very much more > efficient, to deal only with bad input data than to test all of them. > > John Gilmore, Ashland, MA 01721 - USA > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
