Contents
Sequential Updates – Merge with
Copy
Preventing
Output – Important Concepts
With [Merge] the Logic/Batch Program dialog will create a program that will merge two sequential files. It is possible to update the first file by creating a copy of it with updates from the second input file. Both files must be in ascending sequence.
File Merging is very similar to Easytrieve Synchronized File Processing, and you may be approaching this topic from the perspective of an EZT conversion. If so, you should read this page together with the Help page Easytrieve Logic, particularly the two sections on Synchronized File Processing. There are significant differences in the approach taken by MANASYS compared to the Easytrieve approach.
Start with Logic/Batch Program and enter the first input file name(FILE1). Then click button [Merge], and a panel appears to fill in the details for a sequential merge. Click the Skeys buttons to select key fields from each of the files being merged. You can select any number of sequence fields for File1, you must select the same number of fields for File2.
Now, click [Finish] and the form will be checked and, if valid, a Jazz program created. With Merge, additional checks include that both File1 and File2 can be read sequentially, and that their corresponding sequence keys can be compared. Detail rules are given below, but simply, comparisons such as “IF KEY1A = KEY1B” must be valid. This is not true if either is a group, or one is a character and the other is a number. You may not check ORDER, WHERE or Validate Definition.
From the dialog above, MANASYS will generate a program with a PROCESS statement like this: -
PROCESS File1 MERGE File2 SKEYS (FILE1.KEY1A,FILE2.KEY1B);
This creates logic as follows: -
Read
initial records from both files
Loop
until both files finished
…
(e.g., logic from PRINT)
IF
File1 <= File2
Read next File2
ELSE
Read next File1
END
IF
END
Loop
·
The
first file, FILE1, is considered to be a master file, and should have only one
record for each key value. If there are duplicate records (i.e. same
key value) in the master file, then any updates will be applied to the first
record, and others will be unchanged.
·
The
second file is the transaction file. It may contain any number of records for
any particular key value, and may include key values that are not represented
on the input master file.
·
The
SKEYS option specifies the collating condition, as
above.
SKEYS (FILE1.KEY1A,FILE2.KEY1B)
·
The
logic critically depends on the master file and transaction file being
presented to the program in ascending key sequence. Key values at the beginning of files must be
the lowest of all records, and at end of file are considered to be higher than
any possible record. Logic generated by MANASYS allows records to have key
values of 0, LOW-VALUES and HIGHVALUES, and the smallest and largest possible
values that the key field(s) can contain.
If you know that an input file is in the wrong sequence, check the SORT
option. If you are almost 100%
confident that they are in the correct sequence but want to check this, check
the Check option. You can specify these
options for either or both input files.
The pseudocode logic above
IF
File1 <= File2
is actually a comparison of the
corresponding SKEY values, in this case
IF FILE1.KEY1A <= FILE2.KEY1B
Here there is only one pair of SKEY values, but there may be several. For example, in another program IN1 (Master file) was merged with IN1Tran (transactions) based on three pairs of SKEY values: -
PROCESS in1 SORT MERGE IN1Tran SORT SKEYS (IN1.Region,IN1.District,IN1.Name,IN1Tran.Region,IN1Tran.District,IN1Tran.Name)…
The IF logic required by the PROCESS … MERGE loop becomes complex with many key pairs, so a special values JZ.$CMerge and JZ.$CMergeOut are available. $CMerge has value 0 if the SKEY values are equal, negative if FILE1 is less than FILE2, and positive if FILE1 is greater than FILE2.
$CMergeOut is used when the PROCESS … MERGE … includes a COPY option. It is similar to $CMerge except that it compares FILEOUT with FILE2
You will see $CMerge printed in the examples below, and used in the conditions that you write to handle update logic. Normally you’ll only compare JZ.$CMerge with 0, but where there are multiple key pairs, as in the PROCESS statement above, you can find which field determines the comparison from the value returned by JZ.$CMerge. The value will be +1 or -1 if the first SKEY pair (IN1.Region,IN1Tran.Region) differs, +2 or -2 if they are the same but the second pair (IN1.District,IN1Tran.District) differ, and so on for as many key pairs as are used.
Like any PROCESS statement,
PROCESS FILE1 MERGE FILE2 SKEYS (FILE1.KEY1A,
FILE2.KEY1B);
defines an I/O loop in which a record is read and
processed, but when the PROCESS statement names two files, the loop iteration
may read from either file. Only one record is read per iteration, so the
program EITHER reads the next File1 record OR the next File2
record. FILE1 is read if FILE1.KEY1A < FILE2.KEY1B, so FILE2 is read if
FILE1.KEY1A >= FILE2.KEY1B.
The logic is best understood with an example. FILE1 and FILE2 have been defined, and test
data created, like this: -
DEFINE FILE1 FB DATA( KEY1A PIC '999' RANGE (1:20), BALANCE MONEY(7,2), NbrA SMALLINT) DSNAME 'JAZZUSER.Files.File1'; |
DEFINE FILE2 FB DATA( KEY1B PIC '999' RANGE (1:20), PAYMENT MONEY(7,2), NbrB SMALLINT) DSNAME 'JAZZUSER.Files.File2'; |
0KEY1A *--BALANCE-* *NbrA-* 0 002 $1,236.56 1 004 $1,238.56 2 005 $1,239.56 3 007 $1,241.56 4 008 $1,242.56 5 010 $1,244.56 6 011 $1,245.56 7 013 $1,247.56 8 015 $1,249.56 9 017 $1,251.56 10 |
0KEY1B *--PAYMENT-* *NbrB-* 0 002 $234.56CR 1 002 $1,000.00 2 005 $500.00 3 005 $270.44 4 011 $1,245.56CR 5 012 $2,468.35 6 014 $1,000.00 7 014 $2,500.00 8 017 $500.00 9 017 $500.00 10 |
This simple program merges these two files: -
PROGRAM Batch BATCH;
COPY FILE1;
COPY FILE2;
PROCESS FILE1 MERGE FILE2 SKEYS(FILE1.KEY1A,FILE2.KEY1B) COUNT JZ2.IX1 SID(21);
PRINT
(JZ2.IX1,', ',FILE1.*,', ', FILE2.*,JZ.$CMerge) ;
END PROCESS MERGE;
Initially the program reads the first record from both
files, then the PROCESS loop is executed until both files have finished. Each
iteration of the loop reads a record from either FILE1 or FILE2, so that there
are 20 iterations. The FILE2 record is
read when it’s sequence key is less than or equal to the FILE1 sequence key, i.e. FILE2.KEY1B <= FILE1.KEY1A, or $CMerge >= 0. Here are the results from the PRINT statement
1Printed at 19 Feb 2023,
12:22:15 RepNbr1 Page 1
0*-IX1-* KEY1A *--BALANCE-* *NbrA-* KEY1B
*--PAYMENT-* *NbrB-* $CMerge
0 1, 002
$1,236.56 1, 002
$234.56CR 1 0
2, 002
$1,236.56 1, 002
$1,000.00 2 0
3, 002
$1,236.56 1, 005
$500.00 3 -1
4, 004
$1,238.56 2, 005
$500.00 3 -1
5, 005
$1,239.56 3, 005
$500.00 3 0
6, 005
$1,239.56 3, 005
$270.44 4 0
7, 005
$1,239.56 3, 011
$1,245.56CR 5 -1
8, 007
$1,241.56 4, 011
$1,245.56CR 5 -1
9, 008
$1,242.56 5, 011
$1,245.56CR 5 -1
10, 010
$1,244.56 6, 011
$1,245.56CR 5 -1
11, 011
$1,245.56 7, 011
$1,245.56CR 5 0
12, 011
$1,245.56 7, 012
$2,468.35 6 -1
13, 013
$1,247.56 8, 012
$2,468.35 6 1
14, 013
$1,247.56 8, 014
$1,000.00 7 -1
15, 015
$1,249.56 9, 014
$1,000.00 7 1
16, 015
$1,249.56 9, 014
$2,500.00 8 1
17, 015
$1,249.56 9, 017
$500.00 9 -1
18, 017
$1,251.56 10, 017
$500.00 9 0
19, 017
$1,251.56 10, 017
$500.00 10 0
20, 017
$1,251.56 10, 999
$500.00 10 -1
* * * END OF RepNbr1 * * *
Notice that the last FILE2 record has been given a key of 999, but there is no such input record. The loop executes until both input files have finished: here the last records have key 017 so on the penultimate loop iteration both FILE1 and FILE2 are positioned on their last record. With equal keys FILE2 is read, causing FILE2-ENDFILE to be set true and FILE2.KEY1B to be set to the highest possible value. For a PIC '999' variable this is 999. The loop is executed for the last time with FILE1.KEY1A = 017 and FILE2.KEY1B = 999, so FILE1 is read. Now both files have finished, and the PROCESS loop terminates.
It is critical that the input files are presented in the correct sequence. In the example above,
PROCESS FILE1 MERGE FILE2 SKEYS (FILE1.KEY1A,
FILE2.KEY1B) COUNT
JZ.IX1;
FILE1 must be in ascending order of FILE1.KEY1A, and FILE2 in ascending order of FILE2.KEY1B. FILE1R and FILE2R are copies of FILE1 and FILE2 sorted into random order, and so results will be incorrect with
PROCESS FILE1R MERGE FILE2R SKEYS (FILE1R.KEY1A,
FILE2R.KEY1B) COUNT
JZ.IX1;
However, if you’ve checked their SORT options the dialog adds SORT, as here
PROCESS FILE1R SORT MERGE FILE2R SORT SKEYS (FILE1R.KEY1A, FILE2R.KEY1B) COUNT JZ.IX1;
If you checked the Check option,
SEQCHECK will be inserted instead of SORT (you can’t check both). SORT / SEQCHECK must immediately follow the relevant file
names, FILE1R and/or FILE2R, they are invalid anywhere else in this statement.
When a PROCESS statement like that above is Checked for the first time, extra definition(s) are added like this: -
DEFINE IFILE1R
LIKE FILE1R MERGESORT;
DEFINE IFILE2R
LIKE FILE2R MERGESORT;
PROCESS FILE1R SORT MERGE FILE2R SORT SKEYS (FILE1.KEY1A,
FILE2.KEY1B) COUNT
JZ.IX1;
#263 S
Definition inserted for IFILE1R. Click CHECK again
#263 S Definition inserted for IFILE2R. Click CHECK again
Click [Check] again and this becomes
DEFINE IFILE1R LIKE FILE1R MERGESORT;
#492 W DSNAME FOR FILE1R changed to &&FILE1R
#492 I DSNAME 'JAZZUSER.Files.File1R'
DEFINE IFILE2R LIKE FILE2R MERGESORT;
#492 W DSNAME FOR FILE2R changed to &&FILE2R
#492 I DSNAME 'JAZZUSER.Files.File2R'
PROCESS FILE1R SORT MERGE FILE2R SORT SKEYS (FILE1.KEY1A, FILE2.KEY1B)
COUNT JZ.IX1;
Because
of SORT, before PROCESS the input files are read and sorted, for example with
004000 SORT SORTWORK ON ASCENDING KEY KEY1A OF JZ-SORTWORK USING Batch4
004010 IFILE1R GIVING FILE1R. Batch4
004020 OPEN INPUT FILE1R. Batch4
The #492 messages tell us that IFILE1R uses FILE1R’s DSNAME. FILE1R is written by the sort with DSNAME &&FILE1R, and read back by the following program. Here is the JCL that will be generated for this program: -
//JAZZUSER JOB ,CLASS=A,MSGCLASS=A
//GO EXEC PGM=BATCHR,TIME=(0,10)
//SYSOUT DD SYSOUT=*
//PRTERR DD SYSOUT=*
//SNAP DD SYSOUT=* USED BY JZSTXIT
//* Inserted DD
statements based on program
//FILE1R DD DSNAME=&&FILE1R,DISP=(NEW,PASS)
//FILE2R DD DSNAME=&&FILE2R,DISP=(NEW,PASS)
//IFILE1R DD DSNAME=JAZZUSER.FILES.FILE1R,DISP=SHR
//IFILE2R DD
DSNAME=JAZZUSER.FILES.FILE2R,DISP=SHR
//REPNBR1 DD SYSOUT=*
Sequential
files are updated by creating a new copy of File1, which is based on the
records read from File1 with changes made by the processing logic. To create a program with this logic, name an
output file in the Copy To Textbox. When you clicked [MERGE], [ü] LIKE Input was be automatically
checked and disabled. Because you’ve
named an output file MANASYS will insert a definition of your output file into
your Jazz program, like this.
DEFINE FILE1OUT LIKE FILE1;
The output file (FILEOUT) will have exactly the same file
type and record layout as the input (FILE1), the only difference will be that
the DSNAME of FILEOUT will be different to that of FILE1.
Because
we’ve given a name for an output file, FILEOUT, logic will be included to copy
FILE1 to FILEOUT. Where the transaction
file (FILE2) has a new sequence key (for example 012) that is not in the master
file (FILE1), a new record is created in FILEOUT. The output record is initialized by: -
·
The sequence field (KEY1A) will be set to the values
from the FILE2 record.
·
Other fields will be initialised according to their
default values in the FILE1 definition (normally zeros and blanks).
The record can then
be updated by your logic between PROCESS FILE1 MERGE … and END PROCESS MERGE. As before, it’s easier to understand with an
example: this program will update FILE1 from FILE2, writing the updated records
to FILEOUT: -
PROGRAM Batch BATCH;
COPY FILE1;
DEFINE FILEOUT LIKE FILE1;
#492 I DSNAME 'JAZZUSER.FILES.FILEOUT'
COPY FILE2;
PROCESS FILE1 MERGE FILE2 SKEYS(FILE1.KEY1A,FILE2.KEY1B) COUNT JZ2.IX1 COPY FILEOUT SID(21);
IF FILEOUT.KEY1A =
FILE2.KEY1B;
FILEOUT.BALANCE
+= File2.Payment;
END IF;
PRINT
(JZ2.IX1,', ',FILE1.*,', ', FILE2.*,', ',FILEOUT.*, JZ.$CMerge) ;
END PROCESS MERGE COPY FILEOUT;
From the PROCESS statement to END PROCESS, and
including any routines that are performed from within the PROCESS loop, the FILE1,
FILE2, and FILEOUT records exist and can be referenced. The FILEOUT record will be written at END PROCESS MERGE COPY FILEOUT; when the logic recognizes that a new FILEOUT
record is needed.
Note that
the condition above compares the OUTPUT record with FILE2. This makes the logic above correct when a
FILE2 record does not match with an existing FILE1 record, or if there are
several FILE2 records matching the output record. There is a special value, $CMergeOut, which
you can use like $CMerge: -
IF JZ.$CMergeOut=0;
This is particularly
useful when there are several key pairs.
Here are
the records produced from this program using the test data above: -
KEY1A *--BALANCE-* *NbrA-*
002 $2,002.00 1
004 $1,238.56 2
005 $2,010.00 3
007 $1,241.56 4
008 $1,242.56 5
010 $1,244.56 6
011 $0.00 7
012 $2,468.35 0
013 $1,247.56 8
014 $3,500.00 0
015 $1,249.56 9
017 $2,251.56 10
And here is
the printout produced from the program’s PRINT statement: -
1Printed at 19 Feb 2023, 13:07:08 RepNbr1 Page 1
0*-IX1-*
KEY1A *--BALANCE-* *NbrA-* KEY1B *--PAYMENT-* *NbrB-* KEY1A *--BALANCE-* *NbrA-*
$CMerge
0 1, 002
$1,236.56 1, 002
$234.56CR 1, 002
$1,002.00 1 0
2, 002
$1,236.56 1, 002
$1,000.00 2, 002
$2,002.00 1 0
3, 002
$1,236.56 1, 005
$500.00 3, 002
$2,002.00 1 -1
4, 004
$1,238.56 2, 005
$500.00 3, 004
$1,238.56 2 -1
5, 005
$1,239.56 3, 005
$500.00 3, 005
$1,739.56 3 0
6, 005
$1,239.56 3, 005
$270.44 4, 005
$2,010.00 3 0
7, 005
$1,239.56 3, 011
$1,245.56CR 5, 005
$2,010.00 3 -1
8, 007
$1,241.56 4, 011
$1,245.56CR 5, 007
$1,241.56 4 -1
9, 008
$1,242.56 5, 011
$1,245.56CR 5, 008
$1,242.56 5 -1
10, 010
$1,244.56 6, 011
$1,245.56CR 5, 010
$1,244.56 6 -1
11, 011
$1,245.56 7, 011
$1,245.56CR 5, 011
$0.00 7 0
12, 011
$1,245.56 7, 012
$2,468.35 6, 011
$0.00 7 -1
13, 013
$1,247.56 8, 012
$2,468.35 6, 013
$1,247.56 8 1
14, 013
$1,247.56 8, 014
$1,000.00 7, 013
$1,247.56 8 -1
15, 015
$1,249.56 9, 014
$1,000.00 7, 015
$1,249.56 9 1
16, 015
$1,249.56 9, 014
$2,500.00 8, 015
$1,249.56 9 1
17, 015
$1,249.56 9, 017
$500.00 9, 015
$1,249.56 9 -1
18, 017
$1,251.56 10, 017
$500.00 9, 017
$1,751.56 10 0
19, 017
$1,251.56 10, 017
$500.00 10, 017
$2,251.56 10 0
20, 017
$1,251.56 10, 999
$500.00 10, 017
$2,251.56 10 -1
* * * END OF RepNbr1 * *
*
The program above shows the key features of a PROCESS … MERGE … COPY program: -
1. The output file is defined with LIKE
DEFINE FILEOUT LIKE FILE1;
#492 I DSNAME 'JAZZUSER.Files.FILEOUT'
This means that its layout is exactly the same as FILE1: as you can see from the printout it has the same field names, each with the same format. The only thing that is different is the DSNAME: Message #492 tells us how this has been changed.
2.
For the entire program the FILE1, FILE2, and
FILEOUT records exist and can be referenced, but their values are not defined
before
PROCESS FILE1 …;
At this point the first record from FILE1 and FILE2 will have been read, and the FILEOUT record will be empty (initial values).
3.
At END PROCESS MERGE COPY FILEOUT; the
loop logic reads the next record from either FILE1 or FILE2, and then
determines whether to write a record to FILEOUT. If a record is written, the next FILEOUT
record is created in memory.
If
File1 <= File2 it is initialized
as a copy of the FILE1 record
Else
it is initialized from default values and it’s key (FILEOUT.KEY1A) is set from
File2’s key(FILE2.KEY1B).
4. Within the
PROCESS loop you can refer
to fields from either of the input files and the output file, and also JZ.$CMerge for
comparisons. The FILEOUT record is the next record to be written, so that the
logic
IF JZ.$CMergeOut = 0; [equivalent to IF
Fileout.KEY1A = FILE2.KEY1B;]
FILEOUT.BALANCE
+= File2.Payment;
END IF;
adds the payment to the output balance.
When you [Process] the Jazz program, MANASYS creates COBOL and JCL. If you’re creating FILEOUT for the first time, then you must exit the JCL that has been generated, changing
//FILEOUT DD DSNAME=JAZZUSER.FILES.FILEOUT,DISP=SHR
to
//FILEOUT DD DSNAME=JAZZUSER.FILES.FILEOUT,DISP=(NEW,CATLG)
If you’re using Micro Focus Enterprise Developer, do this before you submit the run JCL. If you’re using zOS then right-click [Process] and click [JCL], then edit the JCL before submitting the job to compile and run your program.
If FILEOUT exists then you can leave the default JCL with DISP=SHR unless FILEOUT is different to the previously-catalogued data set.
If you’re
used to writing similar programs with COBOL or Easytrieve then you’ll be
expecting to have to code a WRITE FileOut statement
somewhere, but MANASYS generates this for you at the right place so you don’t
have to. This is fine if you are happy
with the default logic rules of MANASYS, which will write updated records for
each master file (FILE1) record after it’s been updated, and will write new
records if a transaction does not match with any master file record. This may not be what you want. In this case you must prevent the record from
being written.
If you don’t want a record to be written,
write
Copy-wanted =
false;
where it will be executed. [Check] will change this to
JZ.COPY-WANTED = false;
preventing a record from being written at the end of
the PROCESS
loop. For example, suppose the
transaction file had a field Function, and you wanted to “Delete” records
matched with transactions where this had value 'D'. You could write logic like this: -
PROCESS FILE1 MERGE FILE2 SKEYS (FILE1.KEY1A,
FILE2.KEY1B) COPY
FILEOUT COUNT(IX);
IF JZ.$CMergeOut = 0;
FILEOUT.BALANCE
+= FILE2.PAYMENT;
IF
File2.Function =
'D';
JZ.COPY-WANTED
= false;
END
IF;
END IF;
PRINT (JZ.IX, FILE1.*, FILE2.*, FILEOUT.*) ;
END PROCESS MERGE COPY FILEOUT;
This will prevent END PROCESS from
writing the FILEOUT record.
JZ.COPY-WANTED remains
set False until FILEOUT.KEY1A changes and END PROCESS tries to write
a record. Suppose that we wrote
PROCESS FILE1 MERGE FILE2 SKEYS (FILE1.KEY1A,
FILE2.KEY1B) COPY
FILEOUT COUNT(IX);
IF JZ.$CMergeOut = 0;
FILEOUT.BALANCE
+= FILE2.PAYMENT;
IF
FILEOUT.BALANCE =
0;
JZ.COPY-WANTED
= false;
END
IF;
END IF;
PRINT
(JZ.IX, FILE1.*, FILE2.*, FILEOUT.*) ;
END PROCESS MERGE COPY FILEOUT;
With the test data used so far, this would cause the
output record
011 $0.00 7
to be omitted.
But since there might be several transactions for this key value, in a
general case the results might be incorrect.
Imagine that record 5 of FILE2 were followed by another transaction for
key value 011, resetting FILEOUT.BALANCE to a non-zero value.
The record would still be deleted (not copied). If situations like this are possible, the
logic should be
PROCESS FILE1 MERGE FILE2 SKEYS (FILE1.KEY1A,
FILE2.KEY1B) COPY
FILEOUT COUNT(IX);
IF JZ.$CMergeOut = 0;
FILEOUT.BALANCE
+= FILE2.PAYMENT;
IF
FILEOUT.BALANCE =
0;
JZ.COPY-WANTED
= false;
ELSE;
JZ.COPY-WANTED
= true;
END
IF;
END IF;
PRINT
(JZ.IX, FILE1.*, FILE2.*, FILEOUT.*) ;
END PROCESS MERGE COPY FILEOUT;
By default,
MERGE … COPY logic will
insert new records into the output file if the transaction record has an
unmatched key. To prevent this happening,
set Copy-Wanted to False if the File1 key is greater than the File2 key. The transaction file (File2) is read in
preference to the master file (File1), i.e. END PROCESS MERGE logic is
If File2 <= File1
Read File2
ELSE
Read File1
This means
that unmatched File2 records will result in the PROCESS loop being executed with File2’s key is
greater than File1’s key.
DEFINE W DATA(X CHAR(1));
PROCESS FILE1 MERGE FILE2 ON FILE1.KEY1A=FILE2.KEY1B COPY FILEOUT COUNT JZ.IX1;
IF JZ.$CMergeOut = 0;
FILEOUT.BALANCE +=
FIle2.Payment;
IF JZ.$CMerge
> 0;
JZ.COPY-WANTED = false;
END IF;
END IF;
W.X = JZ.COPY-WANTED;
#319 W Actual Code is assigned
PRINT (JZ.IX1, FILE1.*, FILE2.*, FILEOUT.*, W.X) ;
END PROCESS MERGE COPY FILEOUT;
To
illustrate this, the value of Copy-Wanted is moved to a printable field, W.X,
so that the last field shows Y or N corresponding to True or False values.
Printout
from this is
0*-IX1-* KEY1A *--BALANCE-* *NbrA-*
KEY1B *--PAYMENT-* *NbrB-* KEY1A *--BALANCE-* *NbrA-* X
0
1 002 $1,236.56 1
002 $234.56CR 1
002 $1,002.00 1 Y
2 002 $1,236.56 1
002 $1,000.00 2
002 $2,002.00 1 Y
3 002 $1,236.56 1
005 $500.00 3
002 $2,002.00 1 Y
4 004 $1,238.56 2
005 $500.00 3
004 $1,238.56 2 Y
5 005 $1,239.56 3
005 $500.00 3
005 $1,739.56 3 Y
6 005 $1,239.56 3
005 $270.44 4
005 $2,010.00 3 Y
7 005 $1,239.56 3
011 $1,245.56CR 5
005 $2,010.00 3 Y
8 007 $1,241.56 4
011 $1,245.56CR 5
007 $1,241.56 4 Y
9 008 $1,242.56 5
011 $1,245.56CR 5
008 $1,242.56 5 Y
10 010 $1,244.56 6
011 $1,245.56CR 5
010 $1,244.56 6 Y
11 011 $1,245.56 7
011 $1,245.56CR 5
011 $0.00 7 Y
12 011 $1,245.56 7
012 $2,468.35 6
011 $0.00 7 Y
13 013 $1,247.56 8
012 $2,468.35 6
012 $2,468.35 0 N
14 013 $1,247.56 8
014 $1,000.00 7
013 $1,247.56 8 Y
15 015 $1,249.56 9
014 $1,000.00 7
014 $1,000.00 0 N
16 015 $1,249.56 9
014 $2,500.00 8
014 $3,500.00 0 N
17 015 $1,249.56 9
017 $500.00 9
015 $1,249.56 9 Y
18 017 $1,251.56 10
017 $500.00 9
017 $1,751.56 10 Y
19 017 $1,251.56 10
017 $500.00 10
017 $2,251.56 10 Y
20 017 $1,251.56 10
999 $500.00 10
017 $2,251.56 10 Y
FILEOUT does not contain records for key values 12 or 14.
Merge
logic, particularly when producing a new copy file, depends critically on the
input sequence. Errors will occur if
either file is out of sequence, and the results of any update are undetermined
if there are duplicate key values in FILE1.
You can check [ü]Check
and/or [ü] Chk when the program is generated: -
These cause
SEQCHECK to be inserted into the PROCESS statement, and definitions inserted
into the program to enable sequence checking: -
PROGRAM Batch1 BATCH;
COPY FILE1;
DEFINE FILEOUT LIKE FILE1;
#492 I DSNAME 'JAZZUSER.FILES.FILEOUT'
COPY FILE2;
DEFINE FILE1-SEQCHECK DATA(
KEY1A LIKE FILE1.KEY1A);
DEFINE FILE2-SEQCHECK DATA(
KEY1B LIKE FILE2.KEY1B);
PROCESS FILE1 SEQCHECK MERGE FILE2 SEQCHECK SKEYS (FILE1.KEY1A,FILE2.KEY1B) COPY FILEOUT;
END PROCESS MERGE COPY FILEOUT;
SEQCHECK causes
logic to be included so that the input sequence is checked. If the file is out of sequence
then a message is displayed on SYSOUT and the program is aborted.
When [ü] Copy Stats is checked and a Merge
program is generated, three input counters are generated. Here is the program generated from the
dialog above: -
PROGRAM Batch1 BATCH;
* You may need to edit these statements
COPY FILE1;
DEFINE FILEOUT LIKE FILE1;
#492 I DSNAME 'JAZZUSER.Files.FILEOUT'
DEFINE Copy-Stats DATA(
* Add any fields to be
summed. For especially large files
ensure fields have enough digits
Input-Count
INTEGER,
FILE1-Input-Count
INTEGER,
FILE2-Input-Count
INTEGER,
Output-Count
INTEGER);
COPY FILE2;
PROCESS FILE1 MERGE FILE2 SKEYS (FILE1.KEY1A,FILE2.KEY1B) COPY FILEOUT COUNT Copy-Stats.Input-Count;
PRINT
(FILE1.*, FILE2.*) ;
END PROCESS MERGE COPY FILEOUT COUNT Copy-Stats.Output-Count;
PRINT (Copy-Stats.*) FIELDTABLE;
When run
with the test data above, the report from the final PRINT (Copy-Stats.*) FIELDTABLE; shows: -
* Field Name * PR-LTH
VALUE
Copy-Stats.Input-Count :
14: 20
Copy-Stats.FILE1-Input-Count: 14: 10
Copy-Stats.FILE2-Input-Count: 14: 10
Copy-Stats.Output-Count :
14: 12