On Wed, 13 Jul 2016 00:51:41 -0500, Bill Woodger <[email protected]> wrote:
> The S0C1 with that exact set-up does not "normally" happen in COBOL (by which > I mean, > by COBOL running in batch). > > COBOL programs are not "normally" run under TSO. You may consider it to not be normal, but there is no reason that Cobol programs cannot run under TSO, with or without ISPF. If you look in the right places, you will even find IBM-provided examples. > There is an explicit run-time message which explains the issue. I missed that message. If you mean: > Abend 0C1000 hex occurred processing command 'CALL '. I would interpret that as meaning that the CALL command, or, more likely, the program invoked by the CALL command, suffered a S0C1. That is not much of an explanation. On the other hand, if you mean this message: > CEE3201S The system detected an operation exception (System Completion > Code=0C1). That also does not explain much. Given it is an LE message, and the CALL command itself does not use LE, it perhaps gives support to my supposition that something below the CALL command is the likely source of the S0C1. Down a few notches in the levels of probability - perhaps there was more than one S0C1. > The S0C1 is unexpected. No argument there. > It is some artefact of running that program under TSO. Possible, but I don't see anything to prove that. > It was easy to miss not through ignoring it because it always happens, but > through not hunting for something additional when you hit a message stating > the exact cause. I still have not hit that message. Where is it? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
