1 H 2 H* 3 H* MERGE CUSTOMER CARDS (1-2-3) CREATING CUSTOMER TAPE 4 H* 5 FINCARDS IPE F 80 80 READ40 6 FOUTTAPE O F2900 116 TAPE S 7 IINCARDS 011 01 1 C1 8 I 3 90CUST# 9 I 11 21 FNAME 10 I 23 23 INITL 11 I 25 34 LNAME 12 I 36 60 ADDR 13 I 021 02 1 C2 14 I 3 90CUST# 15 I 11 30 CITY 16 I 32 33 STATE 17 I 35 39 ZIP 18 I 031 03 1 C3 19 I 3 90CUST# 20 I 11 11 SEX 21 I 13 22 PHONE 22 I 24 310BDATE 23 I 33 400ADATE 24 I 42 490LDATE 25 OOUTTAPE D 03 26 O LDATE 116 27 O ADATE 108 28 O BDATE 100 29 O PHONE 92 30 O SEX 82 31 O ZIP 81 32 O STATE 76 33 O CITY 74 34 O ADDR 54 35 O LNAME 29 36 O INITL 19 37 O FNAME 18 38 O CUST# 7 |
Statements 5-6 are the File Description Specifications for the card input (INCARDS) and the tape output (OUTTAPE) files. Note that the tape RECFM will be Fixed Blocked because the block size (columns 20-23 = 2900) is the value of the record size (columns 24-27 = 116) multiplied by 25. The output tape will contain standard labels (column 53 = S).
Statements 7, 13, and 18 define the three types of records that should occur in the input file INCARDS. The sequence field (columns 15-16) for these three statements contain 01, 02, and 03 respectively. This specifies that records in the file appear in groups, and within each group these three records should occur in this sequence. The number field (column 17) for each statement contains 1 to specify that exactly one of each record must be present. If these tests are not met, sequence and count, for each input group the program will terminate abnormally. Record indicators 01, 02 and 03 are specified to be turned on when the corresponding record type has been read by the program. To identify the input data to the input specification, columns 21-27 specify that card column one will contain either a 1, 2, or 3 to differentiate each input record read from the three possibilities.
Statements 8-12, 14-17, and 19-24 define the input fields associated with each record type. Note that the customer number is defined for all three record types in the same position and using the same field name. It is not necessary to define a separate field name for each record for the customer number, although that could have been done in order to verify that all three records read were actually for the same customer.
Statement 25 defines the conditions under which the output record is to be written to the tape file (OUTTAPE). Because I want the tape record to contain all the fields from all three input records, I condition the output to occur when the third record has been read (indicator 03 is on). All of the fields from the first two records are also available to me at this time, so I can use data fields from all three input records to build the composite output record.
Statements 26-38 specify the data fields to write to the output tape record and include all input fields read from all three input record types. It is my personal convention to specify output fields in order from the rightmost position in the record to the left, so the fields have been specified in the reverse order to which they appear in the record..
The compiler listing and an IEBPTPCH listing of the created tape dataset are available for viewing here: Example 2 SYSOUT.
Note that there are two warnings in the compiler listing. This is because I assigned record indicators to all three input record types, but I only referenced indicator 03 to condition any action. The indicators associated with record types '1' and '2' are never referenced subsequent to their definition.
The jobstream, complete with JCL, RPG source, input data, and an IEBPTPCH step to list the resulting tape dataset are available for download here: Example 2 jobstream. You will need to ensure that the tape volume serial number is correct for your MVT system before running the jobstream.
When record tests are specified as I have in this program, testing for input records occurring in a specific sequence and in a specific number, the testing is carried out automatically. If the input data fails the tests, Halt indicator 0 (H0) will be turned on and the program will be terminated at the end of the detail cycle. H0 is similar to the errors raised in COBOL programs which can be tested by Declaratives. There are some cases when H0 can be detected using Calculation Specifications, the problem resolved, and H0 set off thereby avoiding an ABEND. Usually input sequence errors are not the type that can be corrected programmatically and it will be necessary to examine the input data to determine how the input was in error.
This page was last updated on January 17, 2015.