|
How about copying your files into a temporary file without the time fields and doing the compare on those files... Of course if you want to compare the time stamp fields your kinda out of luck... just a thought, never done it myself.. tim > -----Original Message----- > From: Stone, Joel [SMTP:StoneJ@GourmetAward.com] > Sent: Friday, August 25, 2000 11:50 AM > To: 'RPG400-L@midrange.com' > Subject: RE: testing a batch RPG pgm which uses the TIME opcode > > Great idea, and I normally do this in my pgms. But I am testing other > pgms, some of which I may not have access to source, others I cannot > modify. > > Is it impossible to modify the TIME result for a specific job? > > -----Original Message----- > From: Buck Calabro [ <mailto:buck.calabro@aptissoftware.com>] > Sent: Friday, August 25, 2000 12:25 PM > To: rpg400-l@midrange.com > Subject: RE: testing a batch RPG pgm which uses the TIME opcode > > > Joel Stone wrote: > > >I am trying to test a new version > >of an RPG4 pgm. I run the old > >and new pgm versions, then use > >CMPPFM to compare the output > >files field by field. > > > >3) The RPG pgm uses the TIME > >opcode to time-stamp fields in the > >records. Since the old version and > >new version run a few seconds apart, > >none of the output records ever match. > > Don't use TIME. Build your own function, say, createTimeStamp. Within > it, > hard code a fixed time stamp for the duration of your testing. When you > go > live, use the TIME op code again. That way you won't have to chase all > over > creation replacing TIME with hardcoding and vice versa. > > The CMPPFM problems are unpleasant. I typically use 3 SQL statements: > > join where records are in old and new > records in old but not new > records in new but not old > > Buck Calabro > Aptis; Albany, NY > "We are what we repeatedly do. > Excellence, then, is not an act, but a habit." --Aristotle > > > Billing Concepts Corp., a NASDAQ Listed Company, Symbol: BILL > +--- > | This is the RPG/400 Mailing List! > | To submit a new message, send your mail to RPG400-L@midrange.com. > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-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 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.