|
Although I can't speak to your specific situation Rick, I can only say that in my limited experience with MR, even with the scenario you describe (and I have seen this - you're right, MR handles this nicely, if the programmer understands it), I would like to offer my perhaps not-so-humble-opinion. In the olden days, you couldn't call other programs from within an RPG, systems were slow, files didn't have alternate indexes (ie, LF), and keys on the file had to be contiguous, and tasks that required everything be done in one RPG program, all of these made MR a necessity. I would argue, natch, suggest that with all of the tools we have at our disposal today, tools which are far easier to use and understand than MR (these include SQL, modular programming, systems with orders of magnitude more processing power). Thus, it is likely easier for a programmer to maintain applications that have been redesigned to eliminate MR. By gosh, I have spent way more time on this topic than any sane person should. I am done with it. GA --- rick.baird@xxxxxxxxxxxxxxx wrote: > for the record, the only example I can think of that Matching records > processing has over any of the others techniques described to replace > it, is in this particular situation > > you have two or more files and you need to read each and every record of > each file (or a specific subset, of each file) and do one thing if it > has a match in the other files, or do something else if there is not a > match. > > no sql technique or setll/read that I know of will process this scenario > more efficiently than matching records. > > I had this situation once, and that was the last time I wrote an MR > program. > > and that was more years ago than I care to remeber. ;) > > rick __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
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.