IGZ0201W: File attribute mismatch

What it means

When a COBOL program opens a file, the runtime compares the file as the program describes it (the FD and its record descriptions) with the real data set named on the DD statement. IGZ0201W is the message it writes when they don't agree. The common form names the file and the program. It then gives the record length the program expects and the record length the data set has.

The OPEN fails and the runtime sets file status 39. What happens next depends on the program. If the file has a FILE STATUS clause, control returns to the program, which must test the status. If it doesn't, the runtime treats it as a severe error and ends the program with IGZ0035S.

Matching rules depend on the record format. For fixed records (F or FB), the program's record length must equal the data set's LRECL. For variable or spanned records (V, VB, VS), the program's longest record must be exactly 4 bytes less than the LRECL, because the LRECL includes the 4-byte record descriptor word. For undefined records (U) the lengths must match exactly. Printer files may get one extra byte for the carriage-control character, depending on the ADV compiler option, and the data set's LRECL has to include it.

Common causes

• The copybook changed and the program was recompiled, but the data set still has the old length, or the other way round.
• The JCL points at the wrong data set, for example last month's version with a different layout.
• A variable file whose LRECL was set to the record length, forgetting the 4 bytes for the RDW.
• A print file where the carriage-control byte was added by the compiler but not allowed for in the LRECL, or the reverse.
• A new output data set was created with DCB values that don't match the program.

How to find the problem

1. Read the two record lengths in IGZ0201W. The first is the program's, the second is the data set's.
2. Check the data set's RECFM and LRECL in ISPF 3.4 (type I next to the name) or with LISTCAT.
3. Check the FD in the program listing. The listing shows the record length the compiler worked out, including any RECORDING MODE.
4. Look for IGZ0035S after IGZ0201W. If it is there, the program had no FILE STATUS for that file and the run ended with U4038 under Language Environment.
5. If the program has a FILE STATUS clause, check that it tests for 39 after the OPEN. A program that ignores the status can loop or fail later.

How to fix it

• Make the FD and the data set agree. Either correct the record description and recompile, or recreate the data set with the right LRECL.
• For variable files, set the LRECL to the longest record plus 4.
• Point the DD statement at the right data set.
• For new output files, leave LRECL and RECFM off the DD statement where your standards allow, and let the program's description supply them.
• Add a FILE STATUS clause and test it after every OPEN, so the program stops cleanly with a clear message.

What it looks like

IGZ0201W A file attribute mismatch was detected. File PAYIN in program PAYEXTR had a record length of 200 and the file specified in the ASSIGN clause had a record length of 250.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your z/OS release.