It might be a Word-Alignment problem. COBOL will pad certain items to
the nearest even address. Later versions pad out to the nearest fullword
boundary (but you can turn this off with a $CONTROL statement. I don't
remember now what this is but I think it's ALIGN or something. So if you
have an X(1) item followed by an S9(9) COMP item, the compiler might be
inserting an invisible slack byte or three.

"Leonard S. Berkowitz" wrote:
>
> One of our jobs, on a test system, blew up with a COBOL file status 39 when
> dealing with a CM KSAM file
>
> File's fixed attributes diffeer from program (39) record size (COBERR 648)
>
> And then in the tombstone did indeed report a RECORD SIZE different from the
> FD/01 in the COBOL program. The tombstone reported the RECORD SIZE incorrectly,
> however (70 bytes when the file is actually 74 bytes, matching the FD/01). We
> recompiled the program with $CONTROL MAP to validate the FD/01. We checked the
> file equations, the access date and we were pointing to the correct file.
>
> One suggestion was that the issue was the large quantity of deleted records in
> the data file. A copy of this KSAM duo was copied from another machine, and the
> job is now OK.
>
> Can someone explain what happened here?
>
> Thanks.
> ===================
> Leonard S. Berkowitz
> Perot Health Care Systems
> (Harvard Pilgrim Health Care account)
> voice: 617-509-1212
> fax:   617-509-3737 (eff. 2/15/2000)