For 6 and a half months a Clist ran perfectly well in a batch TSO job, until 20th October 2008. Then, although the Clist step of the batch job continued to complete with return code 0, the output file from the Clist contained obvious errors.
The code below is at the beginning of the Clist and when run in debug mode (CONLIST and SYMLIST activated) it was shown that the problem was here.
/* READ FIRST RECORD FROM ID020
IF &SUBSTR(1:4,&NRSTR(&ID020FIL)) = &NRSTR(BAP1) THEN +
SET BANKID = &SUBSTR(5:7,&NRSTR(&ID020FIL))
/* READ SECOND RECORD FROM ID020
IF &SUBSTR(1:4,&NRSTR(&ID020FIL) = &NRSTR(BAP2) THEN +
SET FILETYPE = &SUBSTR(5:7,&NRSTR(&ID020FIL)
Specifically, the input file (DDname ID020FIL) contains 5 or 6 160-byte FB records.
The first GETFILE reads record one into variable ID020FIL. The subsequent code
tests bytes 1 to 4 against a value of â€œBAP1â€. The record contains â€œBAP1â€ in the first four bytes â€“ everything is OK.
The second GETFILE reads record two into ID020FIL. However, the test of bytes 1to 4 shows that the Clist is attempting to test the whole 160 bytes against â€œBAP2â€. Not OK!!
After extensive investigations, running the job with previous input files that worked etc., the conclusion was as follows:
The layout below shows the first 21 bytes of the second record.
C2 C1 D7 F2 C1 D5 C4 C9 00 00 00 2C 02 00 81 02 0C D5 3C 00 40
Bytes 1 to 4 are obviously â€œBAP2â€ (xC2C1D7F2) and should have satisfied the test. But the packed date, starting in column 13, value: 02 00 81 02 0C (2008-10-20), contains hex 02 in column 16. This would, for instance, have contained hex 92 when the date was 2009-09-20 and this date worked. It only contains 02 for dates from 20th to 29th October!!
What is so special about hex 02 in that byte? Any answers anybody?
The work-around? After each GETFILE we inserted SET TESTFLD = &ID020FIL
and then used &TESTFLD everywhere that &ID020FIL was previously used. OK!