How about something like:
*/* REXX */*
*...*
*"pipe (end ?) ? < file1.data | g: gather | join | pick 1.1500 /== 1501-*",*
* "| c: count lines | literal Mismatched record pairs: | cons",*
* "? < fileb.data | g:",*
* "? c: | var BadCount"*
*exit BadCount*
It works like this:
- < reads a file.
- GATHER reads from the two input streams, alternately, one record at a
time.
- JOIN concatenates each pair of records, one from each file, into a
single record.
- PICK passes mismatches, by comparing the first 1500 bytes to the
second 1500.
- COUNT records the number of records is sees, and, at EOF, writes it to
it's secondary output, which is connected to VAR.
- VAR stores it's record into a REXX variable.
- LITERAL labels the output.
- CONS writes the output to the terminal; substitute > if you prefer.
- ? starts a new stream.
- G: and C: make connections to secondary streams.
If you want just 0 or 1 in in the return code, replace COUNT with FANOUT,
and use EXIT SYMBOL("BadCount") == "LIT". FANOUT will remove itself from
the pipe as soon as the first mismatch is found.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
On Fri, Jul 6, 2018 at 8:52 PM, Farley, Peter x23353 <
[email protected]> wrote:
> Last time I checked SUPERC (even the "advanced" version delivered in the
> HLASM Toolkit) is pretty useless beyond LRECL=200. It wouldn't even show
> the differences in bytes beyond 176, IIRC. It seems to me that SUPERC's
> design point is source-code file comparisons, and even there not so much
> for really-long-line-length-allowed languages.
>
> The commercial compare products (Comparex, INSYNC, FileMaster, etc.) do a
> pretty good job even on really large data files, if your employer is
> already paying for them. Comparex was always my favorite for the ability
> to compare files with random-order (or at least not fully sorted) keys.
>
> But Sri's DFSORT example is impressive, as usual.
>
> Peter
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of retired mainframer
> Sent: Friday, July 6, 2018 10:58 AM
> To: [email protected]
> Subject: Re: DFSORT - a quick way to compare two huge files
>
> EXTERNAL EMAIL
>
> Is there some reason SUPERC is not appropriate for this task?
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List <[email protected]> On Behalf
> > Of R.S.
> > Sent: Friday, July 06, 2018 4:04 AM
> > To: [email protected]
> > Subject: DFSORT - a quick way to compare two huge files
> >
> > We have two output files, rather huge ones (rather gigabytes than MB's)
> > with LRECL~1500, FB.
> > The goal is to compare them and find different records.
> > While I have some ideas how to do it (even ISPF Compare or ICETOOL) I
> > don't think it would effective.
> --
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> ----------------------------------------------------------------------
> 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
