I have around 50,000 records to be omitted from a reference file.
For eg, the SORT CARD is as below:
SORT FIELDS=(5,7,PD,A)
OMIT COND=(5,7,PD,EQ,2220000005647,
OR,5,7,PD,EQ,2220000005657,
OR,5,7,PD,EQ,2220000005668,
OR,5,7,PD,EQ,2220000005678,
OR,5,7,PD,EQ,2220000005689,
OR,5,7,PD,EQ,2220000005699..... count goes upto 50K
The reference file is a TAPE File and declared as VB.
Similary the output is a GDG , Tape file Declared as VB.
JCL for the above requirement goes as below,
(DCI0000),CIS,CLASS=T,MSGCLASS=X,NOTIFY=&SYSUID,
// REGION=0M
//STEP0010 EXEC PGM=SORT,
// PARM='HIPRMAX=OPTIMAL'
//SYSUDUMP DD SYSOUT=D
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SORTIN DD DSN=CI.M204DEV3.CIVS9202.DATA.G0002V00,DISP=SHR -->Referencefile (tape file)
//SORTOUT -->GDG version getting generated
// SORTWRK1 --> 12 SORTWRK files are used.
//SYSIN DD DSN=CI.M204DEV3.INCOR.FINALNS.NODUPFIL.SYSIN,DISP=SHR
--> this file contains the SORT CARD(example as above)
//*
Result for above execution:
THe job gets executed only for 500 (max) records, otherwise it gives an error TOO MANY OMIT CONDITIONS with MAxCC 16
That could have been the solution, but in this case the input file, TAPE FILE is huge with 150 million records.
With such scenario, will the two file comparison still work, & to add on, the TAPE file takes too much of time to read and compare.
but in this case the input file, TAPE FILE is huge with 150 million records.
With such scenario, will the two file comparison still work, & to add on, the TAPE file takes too much of time to read and compare.
If a time is a constraint you may dump your tape file on faster disk drives
(through IEBGENER) and then apply match logic using ICETOOL. There are many examples in this forum (search the DFSORT forum for samples).
but in this case the input file, TAPE FILE is huge with 150 million records.
If You are running a sort the tape will have to be read anyway...
it also depends whether the field used for the omit/include processing
is the sequence key or not ( it looks like it is !!!) and if the tape file is
already sorted on that key...
if the tape file is already sorted then there should be no performance issue
just make sure that the file used for the match is sorted
( not even the need to sort again, a straightt file match should be enough )
.jpg)
