As far as I can tell, it is the TSO CALL command that has gone south with the S0C1. Like Frank, in batch, I'd expect the run-time message and an LE User Abend.
Enterprise COBOL does not produce S0C1's when IO is attempted on a file which is an unexpected state. COBOL simply returns a "status". How that status is dealt with depends on whether the FILE STATUS clause of the SELECT is used, whether IO DECLARATIVES are used for the file or whether neither are used. For the first two it is under programmer control as to what happens (including the programmer forgetting to actually bother about it). If neither are the case, LE produces a User Abend and reports the value of the status and the usual type of stuff telling you exactly where it occurred. There are no S0C1s from COBOL IO. You can arrange a S0C4 directly for COBOL IO, but I really mean arrange. It would take a mistake, and the wrong analysis of the mistake to get a S0C4 on IO by accident. Where S0C4 comes into it is in referencing the "record" under the FD when a file is not open. The "IO" in COBOL ensures that you do only "logical" things (like it is wrong to OPEN a file that is already OPEN, or READ a file which is not OPEN) and also deals with things like records being larger than expected, permanent IO errors and stuff. No S0C1s for COBOL IO (unless the code has been overwritten). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
