On 2 Aug 2012 16:24:06 -0700, in bit.listserv.ibm-main you wrote: >My initial reaction is that this might be just an application (design) >problem. Someone thought it would never grow to get this big. > >If it were vsam, you might consider the DB2 VSAM transparency. But in >the case of this being a flat file, a bit of re-architecting is >definitely in order. > >Seems like there are plenty of good suggestions. But you might want >to consider taking a "step back" in order to see if there are just >larger problems. > From reading the original posting, the program that is abending MAY be vendor supplied and therefore untouchable. The only solution might be a front end program to read the data and pass only the "good" records to the abending program. Maybe Batch Pipes or the equivalent could be used to minimize execution time.
Clark Morris > >Rob Schramm >Senior Systems Consultant >Imperium Group > > > >On Thu, Aug 2, 2012 at 3:45 PM, McKown, John ><john.mck...@healthmarkets.com> wrote: >> 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 * >> john.mck...@healthmarkets.com * 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore >>> Sent: Thursday, August 02, 2012 2:11 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
