How File Matching Works

File Matching › File Matching › How File Matching Works

How File Matching Works

When CA Culprit encounters more than one INPUT parameter, it recognizes a match run and proceeds as follows:

Searches the first record on all files for a match:
If a SELECT statement is used on any file, the SELECT logic is performed before any match-file processing.

If a SELECT BUFFER statement is used, the SELECT logic is performed after the match processing and before type 7 logic is completed.
Searches the remaining file for a match:
If a match among all files is found, the matching records are delivered to the input buffer and type 7 processing is performed.

If a match is not found,
1. The record with the lowest key value is moved into the input buffer.
2. The remainder of the input buffer is nulled out by setting numeric key fields to zeros, alphanumeric key fields to spaces, and the rest of the record to spaces.
3. Type 7 processing is performed.

The figure below shows the contents of the input buffer during a simple match-file run:

Buffer Contents During a Match-file Run

┌───────────────────────────────────┬─────────────────┬──────────────┐
│       PHYSICAL RECORD SEQUENCE    │  INPUT BUFFER   │              │
├─────────────────┬─────────────────┼-------─┬────────┼-------------─┤
│ FILE 1 (SYS010) │ FILE 2 (SYS011) │ SYS010 │ SYS011 │ INPUT BUFFER │
│                 │                 │  AREA  │  AREA  │    NUMBER    │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        A        │       A         │   A    │   A    │      1       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        C        │       B         │   *    │   B    │      2       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        D1       │       D         │   C    │   *    │      3       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        D2       │       E1        │   D1   │   D    │      4       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        E1       │       E2        │   D2   │   *    │      5       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        E2       │       E3        │   E1   │   E    │      6       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        G        │       F         │   E2   │   E    │      7       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        H        │       G1        │   *    │   E    │      8       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│                 │       G2        │   *    │   F    │      9       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│                 │                 │   G    │   G    │     10       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│                 │                 │   *    │   G    │     11       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│                 │                 │   H    │   *    │     12       │
└─────────────────┴─────────────────┴────────┴────────┴──────────────┘

Note: D1, D2, E1, and so on, represent records with duplicate key values. An asterisk (*) indicates a null chapter of the buffer.

Keeping a Record in the Buffer

When a record needs to be processed against more than one record with a matching key value, the MB=KEEP option of the INPUT parameter is used. MB=KEEP is most commonly used on one file only.

The contents of the input buffer when the MB=KEEP option is used is shown in the figure below:

Buffer Contents with the KEEP Option

┌───────────────────────────────────┬─────────────────┬──────────────┐
│       PHYSICAL RECORD SEQUENCE    │  INPUT BUFFER   │              │
├─────────────────┬─────────────────┼-------─┬────────┼-------------─┤
│ FILE 1 (SYS010) │ FILE 2 (SYS011) │ SYS010 │ SYS011 │ INPUT BUFFER │
│                 │                 │  AREA  │  AREA  │    NUMBER    │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        A        │       A         │   A    │   A    │      1       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        C        │       B         │   *    │   B    │      2       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        D1       │       D         │   C    │   B    │      3       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        D2       │       E         │   D1   │   D    │      4       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        E1       │       F         │   D2   │   D    │      5       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        E2       │       G         │   E1   │   E    │      6       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        G        │                 │   E2   │   E    │      7       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│        H        │                 │   *    │   F    │      8       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│                 │                 │   G    │   G    │      9       │
├─────────────────┼-----------------┼--------┼--------┼-------------─┤
│                 │                 │   H    │   G    │     10       │
└─────────────────┴─────────────────┴────────┴────────┴──────────────┘

Note: D1, D2, E1, and E2 represent records with duplicate key values. An asterisk (*) indicates a null chapter of the buffer.

Checking the File Status

When CA Culprit reformats the input buffer for a match file run, it adjusts the starting position of the input fields by inserting two additional bytes for use in checking the status of the files:

The first byte is an input file status byte specific to each file in the run.
The second byte, called M*ID, is a composite input file status indicator consisting of a binary combination of the file-specific status bytes for all files in the run.

If the return value of M*ID is not 0, test the file-specific status bit to locate the file or files containing an error condition:

Define the file-specific status bit on a REC parameter:

If binary: REC FILE4-STATUS 0  1  1

If bit: REC FILE4-STATUS 0  81  5
(Bit format uses a 2-digit length specification,
indicating FILE4-STATUS is a single bit that occurs
in the eighth bit position of start position 0.)

Test the value of the bit in type 7 logic for a non-zero (0) value.

The bit layout within the M*ID and the file-specific status bit fields are shown in the table below.

The Bit Layout Within M*ID

Bit position	Condition	Decimal value of M*ID
5	File(s) out of sequence	8
6	Duplicate key value	4
8	End of file(s) value	1
0	Off	0

Demonstration

The following examples list the values of the file-specific status byte and the M*ID under error conditions:

The first example attempts a match-file run with an unsorted transaction file.
The second example attempts a match-file run with an unsorted transaction file and an unsorted master file.

Complete Code

col. 2
▼
IN 80 MK=M-ACCOUNT
REC M-FILE-STATUS 0    1   1       'M-FILE' 'STATUS'
REC M-ACCOUNT              1    5           'ACCOUNT'
REC M-NAME               620
IN 80 MK=T-ACCOUNT
REC T-FILE-STATUS  0    1   1   'T-FILE' 'STATUS'
REC T-ACCOUNT          1    5           'ACCOUNT'
REC T-PAYMENT          6    8   2  DP=2 'PAYMENT'
02OUT D
0251*005 M*ID                    HH 'M*ID'
0251*010 T-FILE-STATUS         HR
0251*015 M-FILE-STATUS         HR
0251*020 M-ACCOUNT                HR

Unsorted Transaction File

REPORT NO. 02 JANUARY PAYMENTS RECEIVED mm/dd/yy PAGE 1 T-FILE M-FILE M*ID STATUS STATUS ACCOUNT 1 1 15060 1 1 21056 1 1 29557 1 1 30115 1 1 33470 1 1 69876 1 1 99083 8 8 8 8 . . . . . .

Unsorted Master and Transaction Files

REPORT NO. 02 JANUARY PAYMENTS RECEIVED mm/dd/yy PAGE 1 T-FILE M-FILE M*ID STATUS STATUS ACCOUNT 8 8 8 8 8 8 8 8 8 4 4 4 4 4 4 . . . . . . . . .