A field in a record may be tested to see if it is upper-case alphabetic (UC), lower-case alphabetic (LC), mixed case alphabetic (MC), upper-case alphabetic and numeric (UN), lower-case alphabetic and numeric (LN) or mixed-case alphabetic and numeric (MN).
Upper-case alphabetic is defined as A–Z, lower-case alphabetic is defined as a through z, and numeric is defined as 0 through 9.
The field in the record must be BI format. The comparison operator can be EQ or NE.
For example,
INCLUDE COND=(10,4,BI,EQ,LN)
will include records where the field in column 10 for 4 bytes contains only lower-case alphabetic characters and/or numeric characters.
&MULTIINDD
&MULTIINDD is used together with the MULTIIN PARM which directs MFX to read multiple input files from separate DD statements. &MULTIINDD is defined as the two-byte C’nn’ of the SORTMInn ddname (or the two-byte C’n ’ for SORTMIn) from which a record was read.
&MULTIINDD is used in place of p,l,CH to compare to a two-byte character string to determine the input record’s origin.
If the MULTIIN PARM option is not in effect, then &MULTIINDD is defined as two blanks (C' '). If an E15 or E32 exit inserts a record, &MULTIINDD will be C’EX’ for that record. There will be no change to the &MULTIINDD definition when an E15 exit accepts or changes a record.
&MULTIINDD can only be specified on the INCLUDE/OMIT statement.
See Sample INCLUDE Control Statement with &MULTIINDD for an example of how to use &MULTIINDD.
Sample INCLUDE/OMIT Control Statements
In this example, records will be included in the application if the numeric value in the field beginning in byte 24 is less than the numeric value in the field beginning in byte 28 or if the character value in the field beginning in byte 10 is equal to NY.
In this example, records will be omitted from the application if the numeric value in the field beginning in byte 1 is equal to 100 and if the character value in byte 20 is not equal to a blank (X'40').
The next set of control statements exemplifies record selection using bit level logic. The first two examples involve a comparison between a bit mask (shown coded in binary and hexadecimal format) and a binary input field. The third example is a comparison between a bit pattern and a binary field.
The record selection condition has the following elements (from left to right): a binary field (BI) of length 1 byte that starts at column 10 of the record, a comparison operator (ALL), and a bit mask (B'01001000' in binary, X'48' in hexadecimal). Counting from the left, the second and fifth bits of the bit mask are ON (1). For the selection condition to be true, the same bits must be ON in the binary input field. Therefore, if the input field contains, for example, 01001000, 01111000 or 11111111, the condition for the inclusion of records is satisfied. However, if the input field contains a bit string where both mask bits are not ON (e.g., 01000000, in which the fifth bit is not ON), the condition fails and the records are omitted.
The condition for the inclusion of records is met if at least one of the mask bits is ON in the input field. Therefore, the condition would evaluate as true, if the bit string in the binary field were 01000000 (the second bit is ON), 000010000 (the fifth bit is ON), 01001000 (both the second and fifth bit are ON). However, with the string 10000111, for instance, in the input field, the specified condition would evaluate as false (resulting in the omission of records), since neither mask bit is ON.
The above method of comparing a binary input field to a bit mask is useful for testing the contents of a "flag" byte where each bit has a different meaning.
The condition specifies a 4-byte long binary input field (BI) in column 21, a logical relationship (EQ), and a bit pattern. The bit pattern describes the required sequence of 1s and 0s in the first and last twelve bit positions. The row of periods in the pattern represents the part of the string that is irrelevant to the definition of the condition. The condition is true, if the sequence of 1s and 0s in the input field is identical to that described in the bit pattern.
The method of comparing a binary input field to a bit pattern is useful when testing for numeric digits that are one half byte each, as in the packed data format. For example, assume that the binary input field specified in the condition above is a date field in the PD format X'0mmddyyF'. Each date element is split across a byte boundary. The second half-byte of each byte (except the last) represents the first of the two digits that form a date element (mm,dd,yy). (In the last byte, the second half-byte--1111 in binary and F in hexadecimal--stands for the fact that the bit pattern encodes a packed decimal.) The first half-byte of each byte (except the first) represents the second digit of a date element (mm,dd,yy). (The first half-byte, i.e. 0000, of the bit pattern gives it the length specified for the binary field at column 21.) Mapping this scheme onto the bit pattern in the control statement results in the following.
That is, the above control statement is an instruction to select just those records in whose date field mm and yy equal 11 and 91, respectively, while dd can have any value. In other words, the records thus selected are those from November 1991.
Example 6
In this example, a record will be included in the application if either of the following conditions is true:
-
The literal 'ANYTOWN' is found in the 60-byte field starting at position 11 in the record.
-
The contents of the 3-byte field starting at position 121 matches one of the four substrings ('A01', 'A05', 'A06', or 'A09') in the constant. Because it is known that the 3-byte field does not contain any commas, there cannot be a match to the constants ‘01,’ ‘1,A’, ‘05,’ etc.
Example 7
The following sample control statements illustrate substring comparisons with various forms of pattern (wildcard) constants.
In this example, a 12-byte field starting in position 20 will be searched for strings that begin with ST and end with KU anywhere in the field, regardless of the characters in between. Hence, records with ST43624KU in positions 22 through 30 and ST12KU in columns 24 to 29 would be included, as well as records with STKU in the field.
In this case, only the record with ST12KU would be included since only two characters would be allowed between the ST and the KU character constants.
In this case, only the record with ST43624KU would be included, since three or more characters are required between the ST and KU character strings.
In this example, both statements are equivalent; the latter statement specifies the ZD format using the FORMAT=f subparameter. Records will be omitted from the application if the first field (byte 24 to byte 26) is identified as zoned decimal numeric AND the second field (byte 31 to byte 35) is identified as zoned decimal non-numeric.
Example 9
This statement will include only New York records despite differences in formatting of the input files defined by SORTMI01 and SORTMI02.
Example 10
In this example only records whose data are from the years greater than 1996 will be included in the application. If the CENTWIN parameter were set to 1980, representing a century window of 1980 to 2079, the records would be processed in the following manner:
|
Contents of Positions 20 and 21 |
Record Disposition |
|---|---|
84
|
Omitted - represents 1984
|
99
|
Included - represents 1999
|
37
|
Included - represents 2037
|
Example 11
If the application were run on April 25, 2002, the records included would have dates in the 8-byte field starting at position 5 from April 12, 2002 through and including April 25, 2002.
Applications using the INCLUDE/OMIT control statement are illustrated in How to Use the MFX Data Utility Features.