This may be true in Assembler, unless you code otherwise, but it is not true in COBOL, where the compiler generates the code for you (and uses its own/LE/"system" routines).
A simple test is to READ a file which is has not been successfully OPENed, or WRITE (a record to) a file which has not been successfully OPENed. There will be no S0C1. This is COBOL. Any "puts" or "gets" are done beyond our control, and are done only when it is logically possible to do them. A READ (or WRITE) with a file that is not successfully open will just get a status code (if FILE STATUS has been coded on the SELECT in the program) or will be actioned in the DECLARATIVES if used (not seen much of that) or will simply get a User Abend (U4038, not to be confused with U4083). There will be no S0C1. Referencing "data" from an area "under" an FD will get a S0C4 if the file is not currently open (and if it is not subject to APPLY WRITE-ONLY, or compiler option AWO, or SAME RECORD AREA, or a VSAM file). No S0C1, nowhere, unless your procedure code happens to get overwritten and that happens to give you a S0C1. On Tuesday, 12 July 2016 14:59:20 UTC+2, Tom Marchant wrote: > On Tue, 12 Jul 2016 00:29:08 +0000, Jesse 1 Robinson wrote: > > >Unsuccessful open is not necessarily the end of the world... > > >In my experience, S0C1 is the most likely consequence, I presume because > >some location that should contain a valid instruction after open does not. > > Yes. The address of the GET or PUT routine has not been filled in. as a > result, > that location contains zero. Branch to location zero causes a S0C1. > > -- > Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
