Yeah, I rethought my post. I was visualizing the case where a program issues OPEN then a series of READs or WRITEs. On OPEN fail, the program can take some alternate action. For DISPLAY or ACCEPT, OTOH, the program takes complete control. There's no option to take a sharp turn. OPEN and I/O all occur on the basis of one COBOL statement.
I agree that COBOL should not behave this way. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andy Wood Sent: Monday, July 11, 2016 8:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Error in a simple COBOL program On Tue, 12 Jul 2016 00:29:08 +0000, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: . . . > In my experience, S0C1 is the most likely consequence, I presume > because some location that should contain a valid instruction after > open does not. The key to solving this problem is the message 'file-name DD > MISSING'. Figure out why that's happening, fix it, and move on. The "traditional" cause is a program not checking that the OPEN was successful, and proceeding to issue an I/O request, say a PUT, to the DCB. The PUT involves calling a routine, the address of which would have been placed in the DCB by the OPEN, but which is not filled in if the OPEN fails. We can debate exactly what will happen as a result of this, but I think we can agree it is not going to end well. Here, the IGZ0017S message clearly shows that the code does check if the OPEN succeeded, so you would hope that it would not proceed to try to use the DCB as if nothing had gone wrong. The fact that Frank did not see the same S0C1 as is visible in the original post here, when he recreated the situation, probably confirms that something else is also going wrong. I'll agree that it is a fair bet that the S0C1 will go away then the missing DD statement issue is resolved, but there could be some other bug there, waiting for an opportunity to come out and bite. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
