On 8/2/12, Clark Morris <[email protected]> wrote: > 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 >><[email protected]> 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 * >>> [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 >> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN >
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
