× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Compare Files/Records
  • From: Glenn Ericson <Glenn-Ericson@xxxxxxx>
  • Date: Thu, 09 Sep 1999 23:14:42 -0400

At 05:36 PM 9/9/99 -0400, you wrote:
>
>
>John,
>
>At first glance, I thought of CMPPFM, but that won't help you determine which
>fields in a changed record have changed. I can't think of any other system
>utility to do what you'd like it to. So, I'm guessing you'd have to write 500
>programs. Wait! I'm thinking you may be able to write one program to generate
>the code for those 500 programs. Your program would take the DSPFFD outfile
>data (could be from API, too), and generate the necessary code to do whatever
>comparisons you want. From your description, I can't see why this can't be
>totally automated.
>
>On the chance that someone will jump in with the perfect solution you're looking
>for, I'll save my breath and wait to give more details of what I'm talking about
>if nobody else comes up with anything.
>
>Have you thought about using journaling for your validation test? Still some
>programming involved but I think this could be a one-program solution. It would
>also give you more details about when, who, and what. And I just realized that
>my original idea wouldn't handle adds and deletes very gracefully; you'd
>probably have to do "matching records" (yechhh!). Whereas journaling would
>report adds and deletes nicely.
>
>- Dan Bale
>
><On Thursday, 09 Sep 1999 13:18:10, John wrote:>
>I need to compare about 500 files with 500 other files to see if any
>records in the files are different and which fields have changed. All
>the files are externally described. This is going to be used as part of
>a software validation test for some conversions we are doing. i.e.
>convert the data-run the new software in parallel with the old
>software. Then convert the data to another library and the files should
>be identical. Something like CMPREC OLDFILE(TESTLIB1/FILE1)
>NEWFILE(TESTLIB2/FILE1)
>
>Obviously I would prefer to have the computer do all the work :)
>
>+---
There are Y2K data/file comparitor tools that do this type thing.

Usually used durin gtesting to compare baseline to test script results


Regards,

Glenn
_______________________________________________
Glenn Ericson, IBM Certified Specialist
Phoenix Consulting LLC
P. O. Box 701164 East Elmhurst NY 11370-3164 USA
Phone 718 898 9805 Fax 718 446 1150
mailto:Glenn-Ericson@att.net
AS/400 & Year 2000- - Solutions Specialists
© copyright 1996 - 1999 all rights reserved
_______________________________________________

+--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.