Error in a simple COBOL program

[Bill Woodger]

Well, a great friend of mine has managed to reproduce the issue and has passed 
the details on to me. Typical.

Steps to recreate:

Create a JCL stream to execute the compile-and-go PROC, using the original 
source as input to the compiler.
Type SUBMIT at a point where it will be recognised as a SUBMIT command (this 
may vary if using RDz, I don't know).

Pre-requisite: Using COBOL V5.2.0 (V6.1 yet to be verified).

SYSOUT for the GO step:

--- 

TO END PROGRAM, ENTER 0.
   
TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT. 

IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.   
CEE3201S The system detected an operation exception (System Completion 
Code=0C1).   
 From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +02E4 at entry offset +02E4 
  at address 237002E4.  


For V5.2.0,IGZXACP is the entryname for the ACCEPT processing. 

From the APAR previously mentioned, 
http://www-01.ibm.com/support/docview.wss?uid=isg1PI39312, it seems that V5 (at 
least) still uses IGZEINP.

I don't know that all setups running V5.2 have this failure, but I suspect so.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Bill,

From the original post:

IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.


The generated code is very simple (4.2) and is (subject to the locations of 
data and "pattern" (the PGMLIT value) and the code):

0004BE  58F0 2000   L 15,0(0,2)   V(IGZCACP )   
0004C2  4110 A15E   LA1,350(0,10) PGMLIT AT +338
0004C6  0DEFBASR  14,15 

IGZCACP is the code for ACCEPT, within IGZCPAC.

IGZCACP uses IGZEINP (separate module) which does the input itself for ACCEPT.

Then IGZCMSG (again part of IGZCPAC) is then used, presumably to output the IGZ 
run-time message. Then LE modules kick in, presumably producing the second 
(apparent) part of the message, which is missing when the S0C1 under TSO occurs.

There is an APAR for a S0C4 with V5 from IGZEINP, not related to the open of 
SYSIN.

It *seems* to be related to OPs set up. Unfortunately that's the end of it if 
we get no more information from OP and no-one can reproduce. For the amount of 
times a COBOL program under TSO uses ACCEPT without an assignment of SYSIN we 
may never hear of this again...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Don Leahy]

I have never seen one in production, but I have seen developers' tools that
use this approach to test locally developed check digit routines and other
utilities.

On Mon, Jul 11, 2016 at 8:00 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Ah, yes, I've never seen a (real) COBOL program run under TSO with user
> interaction either.
>
> On the other hand I've seen many batch programs with CONSOLE interaction
> (for better or worse!).
>
>
> As for your other question, no I would not be keen on using labels,
> PERFORM...THRU (or SECTION!!), and GO TO statements for those code
> structures; which is why I am so pleased that I can use EXIT PERFORM
> instead!
>
> Frank
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Bill Woodger <bill.wood...@gmail.com>
> Sent: Monday, July 11, 2016 4:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Error in a simple COBOL program
>
> Yes, sorry, Frank, I meant "not with interaction". I've never run a COBOL
> program under TSO, so never attempted to "interact" with it (on the
> Mainframe).
>
> I have seen some VS and VSE programs which communicated with the Operator
> (I've even seen one go into a loop, but it is not difficult to CANCEL), but
> never seen that allowed (for mere programmers) from MVS onwards.
>
> The reason for the explicit priming-read paragraph is that usually/often
> there is stuff to do on the first read which is irrelevant for subsequent
> ones.
>
> It's late here, so I'll have a look at your code tomorrow. For now, would
> you be as keen on the code structures if those were plain GO TOs (given
> that you'd have to have THRU and extra labels, but...)?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Bill Hitefield]

Quite true. We could not duplicate the job, but we could duplicate the program. 

I have done a poor job of communicating that thought.

With the provided source, the COBOL environment was (or should have been) 
fairly consistent (given the exception that different compiler levels could 
have generated slightly different code and code sequences).

The execution environment (batch vs TSO and so forth) could definitely vary. 

But, for an error as (relatively) minor as this one (no SYSIN input DD 
provided), the execution should have produced a more consistent presentation of 
the error. The DD statement was missing. Whether it was missing in z/OS 1.13 vs 
z/OS 2.1, or whether it was missing in TSO vs batch should not (in my opinion) 
have made much of an impact upon how COBOL (and LE) reported the error to the 
user. 

Yet, when COBOL/LE failed in its attempt to access the (undefined) SYSIN DD, it 
gave a mixed bag of results (as witnessed by the different responses people 
have posted).

To me, it would make more sense if COBOL would simply report the error via 
something as simple as "SYSIN DD not present, ACCEPT verb rejected". 

I apologize that my post was confusing and did not portray what I wanted it to 
portray.

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Friday, July 15, 2016 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Thu, 14 Jul 2016 23:17:17 +, Bill Hitefield wrote:

>We have a seemingly very simply COBOL program. One would expect consistent 
>results. Yet, we have seen multiple results - from what would on the surface 
>seem to be fairly similar environments.

The OP didn't give us much information to enable us to duplicate his job. All 
we can do is guess.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Tom Marchant]

On Thu, 14 Jul 2016 23:17:17 +, Bill Hitefield wrote:

>We have a seemingly very simply COBOL program. One would expect consistent 
>results. Yet, we have seen multiple results - from what would on the surface 
>seem to be fairly similar environments.

The OP didn't give us much information to enable us to duplicate his job. All 
we can do is guess.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Frank Swarbrick]

Yes:


IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +03CA at entry offset +03CA at address
 0E8003CA.
Options Report for Enclave CALC1000 07/14/16 6:08:11 PM
Language Environment V01 R13.00

LAST WHERE SET OPTION
---
DD:CEEOPTS   TRAP(OFF,NOSPIE)


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Bill Hitefield <bill.hitefi...@dino-software.com>
Sent: Thursday, July 14, 2016 5:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

Is your LE configured to allow run-time overrides?

If it is, and your overrides were honored by LE, then this is a good example of 
one of the aspects of LE that still causes me to shake my head. Given that one 
of the "fundamentals" of our industry is the repeatability of a symptom (i.e., 
if a jobs fails with a S0C7, and nothing changes (including the data), it 
should always abend with a S0C7, on either your system or mine), I am taken 
back sometimes at how easily LE will give different results - with seemingly 
the same environment.

We have a seemingly very simply COBOL program. One would expect consistent 
results. Yet, we have seen multiple results - from what would on the surface 
seem to be fairly similar environments.

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com<http://www.dino-software.com>
[http://www.dino-software.com/wp-content/uploads/2015/07/RORGadon-1920x500-800x208.jpg]<http://www.dino-software.com/>

Dino-Software | Enterprise-Wide Solutions<http://www.dino-software.com/>
www.dino-software.com
Dino-Software Corporation (Dino-Software) develops enterprise-wide solutions 
for the optimization of complex IT environments




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Thursday, July 14, 2016 7:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

For what its worth, I just ran it (in batch) with TRAP(OFF,NOSPIE) and I still 
don't get a S0C1 (or any different result at all, that I can see).


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Bill Hitefield <bill.hitefi...@dino-software.com>
Sent: Thursday, July 14, 2016 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

It is quite possible the OP is running with different LE options.

For example, the TRAP option controls some aspects of LE error trapping. (There 
are others that govern things like SPIE processing).

If LE does not "trap" the abend, and z/OS is allowed to process it, you will 
probably see some sort of S0Cx abend (depending upon the version of the 
compiler and LE run-time libraries).
If LE does "trap" the abend, you will see some sort of user abend (generated by 
LE).

A U4038 abend is typically I/O related. Unfortunately, it is an extremely 
generic abend code. The extra messages supplied by Frank show how necessary 
they are with LE.

I am going to guess that his LE options are such that LE is asked to trap 
"exceptional conditions" (LE's terms) and funnel them through its processing, 
with the result usually being (1) LE messages, (2) an LE "SNAP mini-dump", and 
(3) a user abend of some sort (typically in the U4xxx series).

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com<http://www.dino-software.com<http://www.dino-software.com<http://www.dino-software.com>>
[http://www.dino-software.com/wp-content/uploads/2015/07/RORGadon-1920x500-800x208.jpg]<http://www.dino-software.com/>

Dino-Software | Enterprise-Wide Solutions<http://www.dino-software.com/>
www.dino-software.com<http://www.dino-software.com>
Dino-Software Corporation (Dino-Software) develops enterprise-wide solutions 
for the optimization of complex IT environments




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Thursday, July 14, 2016 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was 
done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following 
are the results:


IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 address 0E9082A6.
User abend 4,038 dec 

Re: Error in a simple COBOL program

[Bill Hitefield]

Is your LE configured to allow run-time overrides?

If it is, and your overrides were honored by LE, then this is a good example of 
one of the aspects of LE that still causes me to shake my head. Given that one 
of the "fundamentals" of our industry is the repeatability of a symptom (i.e., 
if a jobs fails with a S0C7, and nothing changes (including the data), it 
should always abend with a S0C7, on either your system or mine), I am taken 
back sometimes at how easily LE will give different results - with seemingly 
the same environment.

We have a seemingly very simply COBOL program. One would expect consistent 
results. Yet, we have seen multiple results - from what would on the surface 
seem to be fairly similar environments.

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Thursday, July 14, 2016 7:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

For what its worth, I just ran it (in batch) with TRAP(OFF,NOSPIE) and I still 
don't get a S0C1 (or any different result at all, that I can see).


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Bill Hitefield <bill.hitefi...@dino-software.com>
Sent: Thursday, July 14, 2016 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

It is quite possible the OP is running with different LE options.

For example, the TRAP option controls some aspects of LE error trapping. (There 
are others that govern things like SPIE processing).

If LE does not "trap" the abend, and z/OS is allowed to process it, you will 
probably see some sort of S0Cx abend (depending upon the version of the 
compiler and LE run-time libraries).
If LE does "trap" the abend, you will see some sort of user abend (generated by 
LE).

A U4038 abend is typically I/O related. Unfortunately, it is an extremely 
generic abend code. The extra messages supplied by Frank show how necessary 
they are with LE.

I am going to guess that his LE options are such that LE is asked to trap 
"exceptional conditions" (LE's terms) and funnel them through its processing, 
with the result usually being (1) LE messages, (2) an LE "SNAP mini-dump", and 
(3) a user abend of some sort (typically in the U4xxx series).

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com<http://www.dino-software.com>
[http://www.dino-software.com/wp-content/uploads/2015/07/RORGadon-1920x500-800x208.jpg]<http://www.dino-software.com/>

Dino-Software | Enterprise-Wide Solutions<http://www.dino-software.com/>
www.dino-software.com
Dino-Software Corporation (Dino-Software) develops enterprise-wide solutions 
for the optimization of complex IT environments




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Thursday, July 14, 2016 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was 
done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following 
are the results:


IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 address 0E9082A6.
User abend 4,038 dec occurred processing command 'CALL'.
ISPD210  CMD abended - 'CALL' terminated abnormally.


So... Same results as in batch.  No S0C1.


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 14, 2016 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

I can't see to find the original post that started all of this.  Can someone 
find it and quote it here?

The reason I ask is I swear that the original issue was a compile time issue, 
not a run-time issue.

Or perhaps I'm mixing up two different conversations.


FWIW, I'm going to see what happens if I run my example in TSO.

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Andy Wood <woo...@ozemail.com.au>
Sent: Wednesday, July 13, 2016 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exa

Re: Error in a simple COBOL program

[Frank Swarbrick]

For what its worth, I just ran it (in batch) with TRAP(OFF,NOSPIE) and I still 
don't get a S0C1 (or any different result at all, that I can see).


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Bill Hitefield <bill.hitefi...@dino-software.com>
Sent: Thursday, July 14, 2016 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

It is quite possible the OP is running with different LE options.

For example, the TRAP option controls some aspects of LE error trapping. (There 
are others that govern things like SPIE processing).

If LE does not "trap" the abend, and z/OS is allowed to process it, you will 
probably see some sort of S0Cx abend (depending upon the version of the 
compiler and LE run-time libraries).
If LE does "trap" the abend, you will see some sort of user abend (generated by 
LE).

A U4038 abend is typically I/O related. Unfortunately, it is an extremely 
generic abend code. The extra messages supplied by Frank show how necessary 
they are with LE.

I am going to guess that his LE options are such that LE is asked to trap 
"exceptional conditions" (LE's terms) and funnel them through its processing, 
with the result usually being (1) LE messages, (2) an LE "SNAP mini-dump", and 
(3) a user abend of some sort (typically in the U4xxx series).

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com<http://www.dino-software.com>
[http://www.dino-software.com/wp-content/uploads/2015/07/RORGadon-1920x500-800x208.jpg]<http://www.dino-software.com/>

Dino-Software | Enterprise-Wide Solutions<http://www.dino-software.com/>
www.dino-software.com
Dino-Software Corporation (Dino-Software) develops enterprise-wide solutions 
for the optimization of complex IT environments




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Thursday, July 14, 2016 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was 
done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following 
are the results:


IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 address 0E9082A6.
User abend 4,038 dec occurred processing command 'CALL'.
ISPD210  CMD abended - 'CALL' terminated abnormally.


So... Same results as in batch.  No S0C1.


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 14, 2016 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

I can't see to find the original post that started all of this.  Can someone 
find it and quote it here?

The reason I ask is I swear that the original issue was a compile time issue, 
not a run-time issue.

Or perhaps I'm mixing up two different conversations.


FWIW, I'm going to see what happens if I run my example in TSO.

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Andy Wood <woo...@ozemail.com.au>
Sent: Wednesday, July 13, 2016 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exactly scream out "... expect 
operation exception to follow this message."

> Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Cameron, the person with the original problem, got the S0C1 when running the 
program under TSO.

Frank, who was kind enough to recreate the situation, did not get the S0C1 but 
was running it as a batch job.

As far as I can see, and this is perhaps where I missed something, Cameron did 
not try the program in batch, and nor did Frank try it under TSO.

Myself, I would not spend much time on it, but I wouldn't just ignore it 
either. But, enough said.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-

Re: Error in a simple COBOL program

[Bill Hitefield]

(Sorry if this is a duplicate post. I think I messed up and lost my response 
during my initial attempt to post)



It is quite possible the OP is running with different LE options.

For example, the TRAP option controls some aspects of LE error trapping. (There 
are others that govern things like SPIE processing).

If LE does not "trap" the abend, and z/OS is allowed to process it, you will 
probably see some sort of S0Cx abend (depending upon the version of the 
compiler and LE run-time libraries).
If LE does "trap" the abend, you will see some sort of user abend (generated by 
LE).

A U4038 abend is typically I/O related. Unfortunately, it is an extremely 
generic abend code. The extra messages supplied by Frank show how necessary 
they are with LE.

I am going to guess that his LE options are such that LE is asked to trap 
"exceptional conditions" (LE's terms) and funnel them through its processing, 
with the result usually being (1) LE messages, (2) an LE "SNAP mini-dump", and 
(3) a user abend of some sort (typically in the U4xxx series).


Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Thursday, July 14, 2016 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

Several people pointed me to the OP.  Thank you.

Thanks.  I'm guessing the student was scared off my the topic diversion, but 
anyway...  I just tested what the student posted, but I am not getting 
identical results.

Firstly, the student ran the "compile/link/GO" procedure.  And yes, the compile 
and link were successful, but the GO failed because of the lack of a SYSIN for 
the GO step.  The following are the relevant outputs I am seeing:

JESMSGLG:
 THURSDAY,  14 JUL 2016 
 IRR010I  USERID DVFJSIS ASSIGNED TO THIS JOB.
 IEF677I WARNING MESSAGE(S) FOR JOB CALC1000 ISSUED
 ICH70001I DVFJSLAST ACCESS AT 09:58:25 ON THURSDAY, JULY 14, 2016
 $HASP373 CALC1000 STARTED - INIT 1- CLASS A - SYS ZOSD
 IEF403I CALC1000 - STARTED - TIME=10.05.15
 -  -TIMINGS (MINS.)--  
-PAGING COUNTS
 -STEPNAME PROCSTEPRC   EXCP   CONN   TCB   SRB  CLOCK  
SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
 -STEP1COBOL   00414 92   .00   .00 .0   
770  TSTBAT   0 0 0 0
 -STEP1LKED00171 40   .00   .00 .0   
445  TSTBAT   0 0 0 0
 IEC130I SYSINDD STATEMENT MISSING
 IEF450I CALC1000 GO STEP1 - ABEND=S000 U4038 REASON=0001  214
 TIME=10.05.16
 -STEP1GO   U4038204 91   .00   .00 .0   
433  TSTBAT   0 0 0 0
 IEF404I CALC1000 - ENDED - TIME=10.05.16
 -CALC1000 ENDED.  NAME-A. STUDENT   TOTAL TCB CPU TIME=  .00 TOTAL 
ELAPSED TIME=.0
 $HASP395 CALC1000 ENDED

GO.SYSOUT DD:
---
TO END PROGRAM, ENTER 0.
TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.

GO.CEEMSG  DD:
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +03CA at entry offset +03CA at address
 0E8003CA.

And calling it under TSO, the output to my terminal was this:

TO END PROGRAM, ENTER 0.
TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +03CA at entry offset +03CA at address
 0EB483CA.
User abend 4,038 dec occurred processing command 'CALL'.
ISPD210  CMD abended - 'CALL' terminated abnormally.


Not an S0C1 in sight, so I'm at a loss to understand the student's result, 
unless there is some information he neglected to provide.

Frank


From: IBM Mainframe Discussion List 
<IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Frank 
Swarbrick <frank.swarbr...@outlook.com<mailto:frank.swarbr...@outlook.com>>
Sent: Thursday, July 14, 2016 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: Error in a simple COBOL program

For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was 
done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following 
are the results:


IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 

Re: Error in a simple COBOL program

[Bill Hitefield]

It is quite possible the OP is running with different LE options. 

For example, the TRAP option controls some aspects of LE error trapping. (There 
are others that govern things like SPIE processing).

If LE does not "trap" the abend, and z/OS is allowed to process it, you will 
probably see some sort of S0Cx abend (depending upon the version of the 
compiler and LE run-time libraries).
If LE does "trap" the abend, you will see some sort of user abend (generated by 
LE).

A U4038 abend is typically I/O related. Unfortunately, it is an extremely 
generic abend code. The extra messages supplied by Frank show how necessary 
they are with LE.

I am going to guess that his LE options are such that LE is asked to trap 
"exceptional conditions" (LE's terms) and funnel them through its processing, 
with the result usually being (1) LE messages, (2) an LE "SNAP mini-dump", and 
(3) a user abend of some sort (typically in the U4xxx series). 

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Thursday, July 14, 2016 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was 
done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following 
are the results:


IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 address 0E9082A6.
User abend 4,038 dec occurred processing command 'CALL'.
ISPD210  CMD abended - 'CALL' terminated abnormally.


So... Same results as in batch.  No S0C1.


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 14, 2016 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

I can't see to find the original post that started all of this.  Can someone 
find it and quote it here?

The reason I ask is I swear that the original issue was a compile time issue, 
not a run-time issue.

Or perhaps I'm mixing up two different conversations.


FWIW, I'm going to see what happens if I run my example in TSO.

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Andy Wood <woo...@ozemail.com.au>
Sent: Wednesday, July 13, 2016 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exactly scream out "... expect 
operation exception to follow this message."

> Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Cameron, the person with the original problem, got the S0C1 when running the 
program under TSO.

Frank, who was kind enough to recreate the situation, did not get the S0C1 but 
was running it as a batch job.

As far as I can see, and this is perhaps where I missed something, Cameron did 
not try the program in batch, and nor did Frank try it under TSO.

Myself, I would not spend much time on it, but I wouldn't just ignore it 
either. But, enough said.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Frank Swarbrick]

Certainly anything is possible.  I used Enterprise COBOL 4.2 for my tests.


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Lizette Koehler <stars...@mindspring.com>
Sent: Thursday, July 14, 2016 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

I not sure of the z/OS or OS/390 level he might be working on or the level of
the compiler.

That might make the difference


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: Thursday, July 14, 2016 9:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Error in a simple COBOL program
>
> Several people pointed me to the OP.  Thank you.
>
> Thanks.  I'm guessing the student was scared off my the topic diversion, but
> anyway...  I just tested what the student posted, but I am not getting
> identical results.
>
> Firstly, the student ran the "compile/link/GO" procedure.  And yes, the
> compile and link were successful, but the GO failed because of the lack of a
> SYSIN for the GO step.  The following are the relevant outputs I am seeing:
>
> JESMSGLG:
>  THURSDAY,  14 JUL 2016 
>  IRR010I  USERID DVFJSIS ASSIGNED TO THIS JOB.
>  IEF677I WARNING MESSAGE(S) FOR JOB CALC1000 ISSUED
>  ICH70001I DVFJSLAST ACCESS AT 09:58:25 ON THURSDAY, JULY 14, 2016
>  $HASP373 CALC1000 STARTED - INIT 1- CLASS A - SYS ZOSD
>  IEF403I CALC1000 - STARTED - TIME=10.05.15
>  -  -TIMINGS (MINS.)--
> -PAGING COUNTS
>  -STEPNAME PROCSTEPRC   EXCP   CONN   TCB   SRB  CLOCK
> SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
>  -STEP1COBOL   00414 92   .00   .00 .0
> 770  TSTBAT   0 0 0 0
>  -STEP1LKED00171 40   .00   .00 .0
> 445  TSTBAT   0 0 0 0
>  IEC130I SYSINDD STATEMENT MISSING
>  IEF450I CALC1000 GO STEP1 - ABEND=S000 U4038 REASON=0001  214
>  TIME=10.05.16
>  -STEP1GO   U4038204 91   .00   .00 .0
> 433  TSTBAT   0 0 0 0
>  IEF404I CALC1000 - ENDED - TIME=10.05.16
>  -CALC1000 ENDED.  NAME-A. STUDENT   TOTAL TCB CPU TIME=  .00
> TOTAL ELAPSED TIME=.0
>  $HASP395 CALC1000 ENDED
>
> GO.SYSOUT DD:
> ---
> TO END PROGRAM, ENTER 0.
> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
>
> GO.CEEMSG  DD:
> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> unsuccessful.
>  From compile unit CALC1000 at entry point CALC1000 at compile unit
> offset +03CA at entry offset +03CA at address
>  0E8003CA.
>
> And calling it under TSO, the output to my terminal was this:
>
> TO END PROGRAM, ENTER 0.
> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
> IEC130I SYSINDD STATEMENT MISSING
> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> unsuccessful.
>  From compile unit CALC1000 at entry point CALC1000 at compile unit
> offset +03CA at entry offset +03CA at address
>  0EB483CA.
> User abend 4,038 dec occurred processing command 'CALL'.
> ISPD210  CMD abended - 'CALL' terminated abnormally.
>
>
> Not an S0C1 in sight, so I'm at a loss to understand the student's result,
> unless there is some information he neglected to provide.
>
> Frank
>
> ____________
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Frank Swarbrick <frank.swarbr...@outlook.com>
> Sent: Thursday, July 14, 2016 9:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Error in a simple COBOL program
>
> For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was
> done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following
> are the results:
>
>
> IEC130I SYSINDD STATEMENT MISSING
> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> unsuccessful.
>  From compile unit ACC at entry point ACC at statement 7 at compile
> unit offset +02A6 at entry offset +02A6 at
>  address 0E9082A6.
> User abend 4,038 dec occurred processing command 'CALL'.
> ISPD210  CMD abended - 'CALL' terminated abnormally.
>
>
> So... Same results as in batch.  No S0C1.
>
>
> Frank
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Frank Swarbrick <frank.swarbr...@outlook.com>
> Sent: Thursday, July 14, 2016 9:38 AM
> To: IBM-MA

Re: Error in a simple COBOL program

[Lizette Koehler]

I not sure of the z/OS or OS/390 level he might be working on or the level of
the compiler.

That might make the difference


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: Thursday, July 14, 2016 9:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Error in a simple COBOL program
> 
> Several people pointed me to the OP.  Thank you.
> 
> Thanks.  I'm guessing the student was scared off my the topic diversion, but
> anyway...  I just tested what the student posted, but I am not getting
> identical results.
> 
> Firstly, the student ran the "compile/link/GO" procedure.  And yes, the
> compile and link were successful, but the GO failed because of the lack of a
> SYSIN for the GO step.  The following are the relevant outputs I am seeing:
> 
> JESMSGLG:
>  THURSDAY,  14 JUL 2016 
>  IRR010I  USERID DVFJSIS ASSIGNED TO THIS JOB.
>  IEF677I WARNING MESSAGE(S) FOR JOB CALC1000 ISSUED
>  ICH70001I DVFJSLAST ACCESS AT 09:58:25 ON THURSDAY, JULY 14, 2016
>  $HASP373 CALC1000 STARTED - INIT 1- CLASS A - SYS ZOSD
>  IEF403I CALC1000 - STARTED - TIME=10.05.15
>  -  -TIMINGS (MINS.)--
> -PAGING COUNTS
>  -STEPNAME PROCSTEPRC   EXCP   CONN   TCB   SRB  CLOCK
> SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
>  -STEP1COBOL   00414 92   .00   .00 .0
> 770  TSTBAT   0 0 0 0
>  -STEP1LKED00171 40   .00   .00 .0
> 445  TSTBAT   0 0 0 0
>  IEC130I SYSINDD STATEMENT MISSING
>  IEF450I CALC1000 GO STEP1 - ABEND=S000 U4038 REASON=0001  214
>  TIME=10.05.16
>  -STEP1GO   U4038204 91   .00   .00 .0
> 433  TSTBAT   0 0 0 0
>  IEF404I CALC1000 - ENDED - TIME=10.05.16
>  -CALC1000 ENDED.  NAME-A. STUDENT   TOTAL TCB CPU TIME=  .00
> TOTAL ELAPSED TIME=.0
>  $HASP395 CALC1000 ENDED
> 
> GO.SYSOUT DD:
> ---
> TO END PROGRAM, ENTER 0.
> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
> 
> GO.CEEMSG  DD:
> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> unsuccessful.
>  From compile unit CALC1000 at entry point CALC1000 at compile unit
> offset +03CA at entry offset +03CA at address
>  0E8003CA.
> 
> And calling it under TSO, the output to my terminal was this:
> 
> TO END PROGRAM, ENTER 0.
> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
> IEC130I SYSINDD STATEMENT MISSING
> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> unsuccessful.
>  From compile unit CALC1000 at entry point CALC1000 at compile unit
> offset +03CA at entry offset +03CA at address
>  0EB483CA.
> User abend 4,038 dec occurred processing command 'CALL'.
> ISPD210  CMD abended - 'CALL' terminated abnormally.
> 
> 
> Not an S0C1 in sight, so I'm at a loss to understand the student's result,
> unless there is some information he neglected to provide.
> 
> Frank
> 
> ________
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Frank Swarbrick <frank.swarbr...@outlook.com>
> Sent: Thursday, July 14, 2016 9:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Error in a simple COBOL program
> 
> For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was
> done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following
> are the results:
> 
> 
> IEC130I SYSINDD STATEMENT MISSING
> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> unsuccessful.
>  From compile unit ACC at entry point ACC at statement 7 at compile
> unit offset +02A6 at entry offset +02A6 at
>  address 0E9082A6.
> User abend 4,038 dec occurred processing command 'CALL'.
> ISPD210  CMD abended - 'CALL' terminated abnormally.
> 
> 
> So... Same results as in batch.  No S0C1.
> 
> 
> Frank
> 
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Frank Swarbrick <frank.swarbr...@outlook.com>
> Sent: Thursday, July 14, 2016 9:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Error in a simple COBOL program
> 
> I can't see to find the original post that started all of this.  Can someone
> find it and quote it here?
> 
> The reason I ask is I swear that the original issue was a compile time issue,
> not a run-time issue.
> 
> Or perhaps I'm mi

Re: Error in a simple COBOL program

[Frank Swarbrick]

Several people pointed me to the OP.  Thank you.

Thanks.  I'm guessing the student was scared off my the topic diversion, but 
anyway...  I just tested what the student posted, but I am not getting 
identical results.

Firstly, the student ran the "compile/link/GO" procedure.  And yes, the compile 
and link were successful, but the GO failed because of the lack of a SYSIN for 
the GO step.  The following are the relevant outputs I am seeing:

JESMSGLG:
 THURSDAY,  14 JUL 2016 
 IRR010I  USERID DVFJSIS ASSIGNED TO THIS JOB.
 IEF677I WARNING MESSAGE(S) FOR JOB CALC1000 ISSUED
 ICH70001I DVFJSLAST ACCESS AT 09:58:25 ON THURSDAY, JULY 14, 2016
 $HASP373 CALC1000 STARTED - INIT 1- CLASS A - SYS ZOSD
 IEF403I CALC1000 - STARTED - TIME=10.05.15
 -  -TIMINGS (MINS.)--  
-PAGING COUNTS
 -STEPNAME PROCSTEPRC   EXCP   CONN   TCB   SRB  CLOCK  
SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
 -STEP1COBOL   00414 92   .00   .00 .0   
770  TSTBAT   0 0 0 0
 -STEP1LKED00171 40   .00   .00 .0   
445  TSTBAT   0 0 0 0
 IEC130I SYSINDD STATEMENT MISSING
 IEF450I CALC1000 GO STEP1 - ABEND=S000 U4038 REASON=0001  214
 TIME=10.05.16
 -STEP1GO   U4038204 91   .00   .00 .0   
433  TSTBAT   0 0 0 0
 IEF404I CALC1000 - ENDED - TIME=10.05.16
 -CALC1000 ENDED.  NAME-A. STUDENT   TOTAL TCB CPU TIME=  .00 TOTAL 
ELAPSED TIME=.0
 $HASP395 CALC1000 ENDED

GO.SYSOUT DD:
---
TO END PROGRAM, ENTER 0.
TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.

GO.CEEMSG  DD:
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +03CA at entry offset +03CA at address
 0E8003CA.

And calling it under TSO, the output to my terminal was this:

TO END PROGRAM, ENTER 0.
TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +03CA at entry offset +03CA at address
 0EB483CA.
User abend 4,038 dec occurred processing command 'CALL'.
ISPD210  CMD abended - 'CALL' terminated abnormally.


Not an S0C1 in sight, so I'm at a loss to understand the student's result, 
unless there is some information he neglected to provide.

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 14, 2016 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was 
done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following 
are the results:


IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 address 0E9082A6.
User abend 4,038 dec occurred processing command 'CALL'.
ISPD210  CMD abended - 'CALL' terminated abnormally.


So... Same results as in batch.  No S0C1.


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 14, 2016 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

I can't see to find the original post that started all of this.  Can someone 
find it and quote it here?

The reason I ask is I swear that the original issue was a compile time issue, 
not a run-time issue.

Or perhaps I'm mixing up two different conversations.


FWIW, I'm going to see what happens if I run my example in TSO.

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Andy Wood <woo...@ozemail.com.au>
Sent: Wednesday, July 13, 2016 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exactly scream out "... expect 
operation exception to follow this message."

> Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Cameron, the person with the original problem, got the 

Re: Error in a simple COBOL program

[Frank Swarbrick]

For my TSO test I did a DDLIST and freed the SYSIN allocation.  Once that was 
done I executed my program: TSO CALL 'DVFJS.APPLIB.LOAD(ACC)'.  The following 
are the results:


IEC130I SYSINDD STATEMENT MISSING
IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 address 0E9082A6.
User abend 4,038 dec occurred processing command 'CALL'.
ISPD210  CMD abended - 'CALL' terminated abnormally.


So... Same results as in batch.  No S0C1.


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Thursday, July 14, 2016 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

I can't see to find the original post that started all of this.  Can someone 
find it and quote it here?

The reason I ask is I swear that the original issue was a compile time issue, 
not a run-time issue.

Or perhaps I'm mixing up two different conversations.


FWIW, I'm going to see what happens if I run my example in TSO.

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Andy Wood <woo...@ozemail.com.au>
Sent: Wednesday, July 13, 2016 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exactly scream out "... expect 
operation exception to follow this message."

> Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Cameron, the person with the original problem, got the S0C1 when running the 
program under TSO.

Frank, who was kind enough to recreate the situation, did not get the S0C1 but 
was running it as a batch job.

As far as I can see, and this is perhaps where I missed something, Cameron did 
not try the program in batch, and nor did Frank try it under TSO.

Myself, I would not spend much time on it, but I wouldn't just ignore it 
either. But, enough said.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Frank Swarbrick]

I can't see to find the original post that started all of this.  Can someone 
find it and quote it here?

The reason I ask is I swear that the original issue was a compile time issue, 
not a run-time issue.

Or perhaps I'm mixing up two different conversations.


FWIW, I'm going to see what happens if I run my example in TSO.

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Andy Wood <woo...@ozemail.com.au>
Sent: Wednesday, July 13, 2016 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exactly scream out "... expect 
operation exception to follow this message."

> Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Cameron, the person with the original problem, got the S0C1 when running the 
program under TSO.

Frank, who was kind enough to recreate the situation, did not get the S0C1 but 
was running it as a batch job.

As far as I can see, and this is perhaps where I missed something, Cameron did 
not try the program in batch, and nor did Frank try it under TSO.

Myself, I would not spend much time on it, but I wouldn't just ignore it 
either. But, enough said.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Charles Mills]

Touché.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, July 13, 2016 5:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Tue, 12 Jul 2016 14:19:26 -0700, Charles Mills wrote:

>
>
>The op code is ... just a binary byte in any event, not hex.

In some cases there are more bits than the first byte of an instruction that 
are part of the opcode. Opcodes can be 8, 12, or 16 bits, depending on the 
instruction. The first 8 bits of the opcode are always in bits 0-7 of the 
instruction. Bits 8-11 of a 12-bit opcode are always in bits 12-15, and bits 
8-15 of a 16-bit opcode are either in bits 8-15 or bits 40-47, depending on the 
value in the first 8 bits. For example, if the byte in bits 0-7 contains X'E3', 
the remaining bits of the opcode are in bits 40-47.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Scott Ford]

Yep a 1 a 1 in hex,dec, Oct.

On Tuesday, July 12, 2016, Steve Thompson  wrote:

> On 07/12/2016 05:27 PM, Bill Woodger wrote:
>
>> Well, I guess my question was, then, is the 1 in PIC 1, base 10 or base
>> 16? I now know it to be base 16. I think.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> Forgive me but even if it were octal, it would still be 1.
>
> However, truth be told, for the IBM type Mainframes, it is a "register"
> within the machine that gets reflected to PSA as a program interrupt code
> (see the Principles of Op -- and the latest has more than the S/370-ESA
> version). This is all done as part of the Program Interrupt processing.
>
> HTH
> Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Andy Wood]

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger  wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exactly scream out "... expect 
operation exception to follow this message."

> Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Cameron, the person with the original problem, got the S0C1 when running the 
program under TSO.

Frank, who was kind enough to recreate the situation, did not get the S0C1 but 
was running it as a batch job.

As far as I can see, and this is perhaps where I missed something, Cameron did 
not try the program in batch, and nor did Frank try it under TSO.  

Myself, I would not spend much time on it, but I wouldn't just ignore it 
either. But, enough said. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

"IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful."

Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Sure, it is not ideal that under TSO there is a S0C1 instead, but its not that 
we are so used to S0C1s from COBOL that we didn't notice, it's that the issue 
has already been fully elaborated. Yes, if it happened in front of my face, I'd 
probably notice it, and be curious (as it would be unexpected).

For the amount of Enterprise COBOL which is likely to be running under TSO, I'm 
not sure a fix would be worth it, but that's something bad happened somewhere 
that someone should ideally look at, to see if there are other consequences. 
May even be a small fix.

IGZ run-time messages ending in S always end execution of the program. I wonder 
if any IGZ-with-S under TSO gets a S0C1? Who knows.

S0C1s are rare in COBOL. If you don't check the linkedit/binder and there's 
something unresolved which can't be resolved at run-time (that's hardly COBOL's 
fault) and if you squish your procedure code and happen to hit a S0C1 before 
anything else.

Now we have another "use case". Run under TSO with ACCEPT (implicitly from 
SYSIN) without assigning SYSIN. Possibly other COBOL run-time errors do the 
same thing.

If anyone wants to try, a simple run-time error is with "de-editing".

01  FILLER VALUE SPACE.
05  edited-field PIC +9.
01  a-number PIC S9.

MOVE edited-field TO a-number

Will get "IGZ0063S An invalid sign was detected in a numeric edited sending 
field in  on line number ."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Andy Wood]

On Wed, 13 Jul 2016 00:51:41 -0500, Bill Woodger  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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Tom Marchant]

On Tue, 12 Jul 2016 14:19:26 -0700, Charles Mills wrote:

>
>
>The op code is ... just a binary byte in any event, not hex.

In some cases there are more bits than the first byte of an instruction that 
are part of the opcode. Opcodes can be 8, 12, or 16 bits, depending on the 
instruction. The first 8 bits of the opcode are always in bits 0-7 of the 
instruction. Bits 8-11 of a 12-bit opcode are always in bits 12-15, and bits 
8-15 of a 16-bit opcode are either in bits 8-15 or bits 40-47, depending on the 
value in the first 8 bits. For example, if the byte in bits 0-7 contains X'E3', 
the remaining bits of the opcode are in bits 40-47.

>

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

I can't directly use the link to look at the RFE, but COBOL V5+ already uses 
DFP instructions (I don't know if that should be "at least some") with OPT 1 or 
2 and ARCH(10) or higher. Their uses is mentioned in the COBOL tuning guides, 
which are PDFs which can be linked from the presentation of the documentation 
for Enterprise COBOL in the KnowledgeCentre (or search-engineing COBPF51.pdf 
and COBPF61.pdf).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Andy,

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.

There is an explicit run-time message which explains the issue.

The S0C1 is unexpected. It is some artefact of running that program under TSO. 
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. Maybe the program even S0C1s once the direct problem is fixed 
(SYSIN assinged), who knows?

It should be raised with IBM if it can be reproduced, and if such reproduction 
confirms that it is not a user-error.

Going back to the original compile-and-go, the go part is redundant if the 
intention is to run the program under TSO. Cameron needs to sit down with 
someone, if possible, and go through the process that was attempted.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Steve, I'm not sure what was difficult about the question. The intent behind it 
is "if when next I see reference to a non-COBOL PIC, if it happens to be 11, I 
know whether it means 11 or 17". Is it somehow a question which can only be 
asked when the answer is needed? "Hey, it's 0-9, who gives a rats' toenail what 
base it is in". 

I would think that the presumption that the question was about the magnitude of 
"1" would lie solely in the domain of some esoteric branch of higher 
mathematics. No, add some subset of sysprogs to that as well. I had one, 
fortunately only one, all others I've encountered have been extremely helpful, 
who would only answer "yes", "no" or smile to a question (that's how he treated 
contractors). Meant you needed to know the answer to your own question before 
asking. After trying this once, my only further involvement was to "bait" him a 
couple of times, until he caught on.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Cheryl Watson]

Hi Peter,

Bill Klein actually submitted a SHARE requirement for Decimal Floating Point, 
and it's now an 'Uncommitted candidate' on the RFE system - 
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=89952, so 
it's actually closer than you might think.

Cheryl Watson

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, July 12, 2016 6:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

Write it in assembler and call it from COBOL.  Or bribe the IBM COBOL team to 
slip in support for Decimal Floating Point variables next year whether it is 
profitable to IBM or not.

Oh, and BIT variables would be cool too.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 12, 2016 6:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error in a simple COBOL program

The PoP gets me wondering how to create a "Simulated Quantum Exception" from 
COBOL...

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Steve Thompson]

On 07/12/2016 05:27 PM, Bill Woodger wrote:

Well, I guess my question was, then, is the 1 in PIC 1, base 10 or base 16? I 
now know it to be base 16. I think.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Forgive me but even if it were octal, it would still be 1.

However, truth be told, for the IBM type Mainframes, it is a 
"register" within the machine that gets reflected to PSA as a 
program interrupt code (see the Principles of Op -- and the 
latest has more than the S/370-ESA version). This is all done as 
part of the Program Interrupt processing.


HTH
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Andy Wood]

On Tue, 12 Jul 2016 00:04:15 -0500, Bill Woodger  wrote:

. . .
>
>There are no S0C1s from COBOL IO. 
>

For the reason that I explained previously, a missing DD statement can cause 
S0C1. As far as I am concerned, that should never happen, but I know it is an 
easy mistake to make in assembly code, where one has to explicitly check that 
the OPEN worked. Some OPEN errors cause Sx13 abends, but OPEN does not issue an 
abend for a missing DD.

I don't expect the same S0C1 from Cobol, and I pointed out that Cobol obviously 
does check that OPENs work, because it produced a message saying that the OPEN 
was unsuccessful. So, if that did not cause the S0C1, what did?

I guess I was just wondering if everybody was so conditioned to seeing a 
missing DD statement cause S0C1 that they no longer question it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Good-oh. ARCH(10) and ARCH(11) use DFP. Perhaps more so in V6, but the Tuning 
Guides are good on that. May see a question about it yet, then :-)

May I expect some Higgs boson could be produced, they are something to do with 
quantum exceptions? Rats. That's "quantum excitation". Never mind.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Farley, Peter x23353]

Write it in assembler and call it from COBOL.  Or bribe the IBM COBOL team to 
slip in support for Decimal Floating Point variables next year whether it is 
profitable to IBM or not.

Oh, and BIT variables would be cool too.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 12, 2016 6:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error in a simple COBOL program

The PoP gets me wondering how to create a "Simulated Quantum Exception" from 
COBOL...

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

The PoP gets me wondering how to create a "Simulated Quantum Exception" from 
COBOL...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Yes, Ed. That was the reason for me needing to ask which base it was. If it had 
said PIC C, I'd have wildly assumed it was base 16 (given the two presumed 
choices).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Ed Jaffe]

On 7/12/2016 2:27 PM, Bill Woodger wrote:

Well, I guess my question was, then, is the 1 in PIC 1, base 10 or base 16? I 
now know it to be base 16. I think.


LOL. One is one in all bases. No?

PIC codes are normally expressed in hex. So, a PIC 39 
(region-first-translation exception) is shorthand for PIC x'039'


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Mike Schwab]

Program Interrupt generally end up as S0Cx abends.
Virtual memory interrupts often assign more memory or recall the page
from dasd to a memory frame.
I/O interrupts handle the completed I/O.
etc.

On Tue, Jul 12, 2016 at 3:32 PM, Bill Woodger  wrote:
> Thanks Mike, and now Steve as well. It's all knowledge. Now, is that 1 
> decimal, or hexadecimal? Is a PIC (non-PICture) a subset of abend-codes (does 
> it include SB37, S222)? I should find something to read. OK, got it. Hex, and 
> "10 and above - Program checks associated with system-related interrupts."
>
>
> On Tuesday, 12 July 2016 22:19:52 UTC+2, Mike Schwab  wrote:
>> I believe that is the Program Interrupt Code 1 as System 360+ hardware
>> defines it.  z/OS translates it to Abend S0C1 abend.
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Well, I guess my question was, then, is the 1 in PIC 1, base 10 or base 16? I 
now know it to be base 16. I think.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Charles Mills]

The op code is not a "hex value." Hex is a way of representing binary values 
for easy-to-grasp human consumption: X'D2' is more compact and easier to grasp 
than 11010010 and a better representation for some purposes than 210. The op 
code is a value in storage and it simply is what it is. Some opcodes are in 
fact a printable EBCDIC code point -- MVC = X'D2' = 'K' comes to mind -- and an 
invalid op code might certainly represent a printable character -- or not. But 
it's just a binary byte in any event, not hex.

So the PoOp simply says "An operation exception is recognized when the CPU 
attempts to execute an instruction with an invalid operation code." No "hex" in 
there. The CPU knows nothing about hex. To paraphrase the advertising slogan, 
hex is for people.



Just a "thing" of mine.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Tuesday, July 12, 2016 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

PIC 1 == Program Interrupt Code 1. Occurs when one attempts to execute a Hex 
value that is not an instruction. Example: X''. 
If executable code falls into that (or branches to it, or jumps to it) one will 
get a PIC 1.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Tom Marchant]

On Tue, 12 Jul 2016 15:32:07 -0500, Bill Woodger wrote:

>Thanks Mike, and now Steve as well. It's all knowledge. Now, is that 1 
>decimal, or hexadecimal? Is a PIC (non-PICture) a subset of abend-codes (does 
>it include SB37, S222)?

Kind of. MVS turns some program interrupts into S0Cx abends. e.g. a data 
exception (PIC 7) becomes a S0C7. PIC 10 is commonly called a page fault. If 
the page is not allocated, MVS treats that similarly to a protection exception 
and issues a S0C4 abend.

>I should find something to read.

That would be the Principles of Operation. The section on Program 
Interruptions. These are detected by the processor as instructions are executed.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Thanks Mike, and now Steve as well. It's all knowledge. Now, is that 1 decimal, 
or hexadecimal? Is a PIC (non-PICture) a subset of abend-codes (does it include 
SB37, S222)? I should find something to read. OK, got it. Hex, and "10 and 
above - Program checks associated with system-related interrupts."


On Tuesday, 12 July 2016 22:19:52 UTC+2, Mike Schwab  wrote:
> I believe that is the Program Interrupt Code 1 as System 360+ hardware
> defines it.  z/OS translates it to Abend S0C1 abend.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Steve Thompson]

PIC 1 == Program Interrupt Code 1. Occurs when one attempts to 
execute a Hex value that is not an instruction. Example: X''. 
If executable code falls into that (or branches to it, or jumps 
to it) one will get a PIC 1.


This then gets converted to a S0C1 on a MVS system (or z/OS for 
today).


HTH
Steve Thompson



On 07/12/2016 03:48 PM, Bill Woodger wrote:

Just to add, I have absolutely no clue (outside of ICL COBOL) what PIC 1 is. 
I'm just an applications person. The world of sysprogs is beyond me, and whilst 
I always enjoy the conversations here, mostly it is metres above my head :-)

In ICL COBOL, PIC 1 defines a bit. PIC 1(3) is three bits, etc. You may also have to define it as 
COMP-5, but it is not "our" COMP-5. One of those COBOL things. "COMPUTATIONAL" 
means a numeric definition, implementor-defined. Fortunately up as far as COMP-3, there is general 
agreement. Mostly.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Mike Schwab]

I believe that is the Program Interrupt Code 1 as System 360+ hardware
defines it.  z/OS translates it to Abend S0C1 abend.

On Tue, Jul 12, 2016 at 2:48 PM, Bill Woodger  wrote:
> Just to add, I have absolutely no clue (outside of ICL COBOL) what PIC 1 is. 
> I'm just an applications person. The world of sysprogs is beyond me, and 
> whilst I always enjoy the conversations here, mostly it is metres above my 
> head :-)
>
> In ICL COBOL, PIC 1 defines a bit. PIC 1(3) is three bits, etc. You may also 
> have to define it as COMP-5, but it is not "our" COMP-5. One of those COBOL 
> things. "COMPUTATIONAL" means a numeric definition, implementor-defined. 
> Fortunately up as far as COMP-3, there is general agreement. Mostly.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Just to add, I have absolutely no clue (outside of ICL COBOL) what PIC 1 is. 
I'm just an applications person. The world of sysprogs is beyond me, and whilst 
I always enjoy the conversations here, mostly it is metres above my head :-)

In ICL COBOL, PIC 1 defines a bit. PIC 1(3) is three bits, etc. You may also 
have to define it as COMP-5, but it is not "our" COMP-5. One of those COBOL 
things. "COMPUTATIONAL" means a numeric definition, implementor-defined. 
Fortunately up as far as COMP-3, there is general agreement. Mostly.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

No, that is not so. COBOL will not attempt a "get" if the file is not open. It 
will: return the file-status field, or do what is indicated in DECLARATIVES, or 
give the U4038, depending on the presence or otherwise of FILE STATUS and 
DECLARATIVES.

TRAP(ON) or TRAP(OFF), no S0C1.

Someone kindly pointed out the "classic" S0C1 in COBOL. A "static" CALL 
unresolved. If you don't have the correct LE library in the linkedit/binder 
step, you can get LE to give you a S0C1.

If you delete the IO routines from the LE library, you'd get a S0C1 for IO. If 
you linkedit/binderer an old LE library, you may well get a S0C1 (or something 
else). If you overwrite the executable code, you may get a S0C1.

You can't get a S0C1 (without intent to do exactly that) from COBOL IO. 
(Enterprise COBOL, anyway).

I can keep denying the possibility forever. Why doesn't someone attempt to do 
it, rather than assert? I've tried, recently (not with V5+, but I strongly 
doubt it has changed, and its a bug if it has). I can't do it (except with 
deliberation) so feel free to try and report back. Just saying "it does" 
doesn't (shouldn't) cut ice anywhere.

On Tuesday, 12 July 2016 20:42:01 UTC+2, Tom Marchant  wrote:
> On Tue, 12 Jul 2016 11:40:22 -0500, Bill Woodger wrote:
> 
> >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).
> 
> The PIC 1 still occurs when a COBOL (or other LE enabled) program tries to 
> read when the DCB isn't open, whether because the open failed, was never 
> issued, or the DCB was closed. The LE  ESPIE exit will intercept that PIC 1 
> and convert it to a U4038.
> 
> >
> >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.
> 
> That depends on your LE options. IIRC, if you have TRAP(OFF), you will get 
> the S0C1
> 
> 
> >On Tuesday, 12 July 2016 14:59:20 UTC+2, Tom Marchant  wrote:
> >> 
> >> 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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Tom Marchant]

On Tue, 12 Jul 2016 11:40:22 -0500, Bill Woodger wrote:

>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).

The PIC 1 still occurs when a COBOL (or other LE enabled) program tries to read 
when the DCB isn't open, whether because the open failed, was never issued, or 
the DCB was closed. The LE  ESPIE exit will intercept that PIC 1 and convert it 
to a U4038.

>
>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.

That depends on your LE options. IIRC, if you have TRAP(OFF), you will get the 
S0C1


>On Tuesday, 12 July 2016 14:59:20 UTC+2, Tom Marchant  wrote:
>> 
>> 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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

OPEN with no FILE STATUS for the file, and no DECLARATIVES for the file, will 
get a U4038 if it fails, a Language Environment abend. 

Yes, having defined a FILE STATUS it should *always* be checked. The 
consequences of not checking far outweigh any "saving".

FILE STATUS cannot prevent/identify the "file full" stuff. Without system 
software to "deal" with an X37, that's just the X37 abend. 

You can code an LE Abend Handler to identify the X37s (and lots of other 
things).

On Tuesday, 12 July 2016 15:51:17 UTC+2, Clark Morris  wrote:
> That depends on whether a status code field is defined for the file.
> If no status code is defined for a file, a failed OPEN will cause an
> abend of some type.  Note that if a status code is defined for a file,
> it must be checked after ALL I-O statements for the file.  Otherwise
> interesting problems could occur such as ignoring B37 and D37 type
> failures on output.  One client's programs actually only checked the
> OPEN statements.  Without the status code I-O failures such as READ
> past end of file and B37/D37 conditions will cause abends.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

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 +, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Tom Marchant]

On Tue, 12 Jul 2016 00:29:08 +, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Pre-design background.

System normally closes at 20:00 on another machine and that days' data files 
are created and delivered to the IBM for reporting.

The files are normally to be received before midnight.

That the correct data file, from the correct business day, is used, needs to be 
verified.

OS: DOS/VSE

Design.

It is fine if the COBOL program is running after 20:00 and before midnight. 
But... what about the date, is it correct? So, ask the OPs. Get confirmation 
that "today" is today. Oooh. That midnighty thing. Better check for that as 
well. If it is after midnight, need to subtract one from the date. Get them to 
confirm that. Hey, this is exciting. Oooh. Leap years as well. Code 'em up, 
always fun.

Implementation.

In the 12 programs, coded by three different programmers, there were four 
different ways the conversation with the OPS was carried out, and four ways the 
leap years was deal with. All. All. Of each. All. Were either wrong or plain 
stupid beyond comprehension.

Steps were included in one 12-step job.

All were secretly "coached" through various tests by those responsible for the 
code. Operations were trained.

Productionon

Needless to say, when "for real" came along the batch was actually starting at 
23:30-00:30. 

DOS has a "TIME card" (it just punches-in with the rest of us). You want to 
change the current day (for this JOB), just put in a TIME card. 

Which meant that some jobs needed a TIME card, some didn't. Some needed one 
"part way through", some needed one for their entirety. Some programs, because 
of the "conversation" started before midnight but actually got into their work 
after midnight.

This lasted a week. Some of the logs and complaints from OPs were hilarious.

Did I mention that one of the files transferred contained the business date? 
No? OK, I'll mention it now. It was the 12th file. 

After a week of this nuttiness, we junked the 12 programs (can you imagine, a 
simple read-a-file-write-a-file program which was so bad it was not worth 
retaining?), wrote 12 new ones (OK, one new one and 12 copies, OK two new ones 
and 11 copies). Transferred the date file first, with all transfers in 
individual JOBs, and verified everything to the date file, using the new 
headers on the transfer files, and verifying the new trailers for counts and 
hash-totals. No operator involvement at all, no errors (not their fault, it 
wasn't even running long enough for them to accidentally screw it up, but it 
would have happened).

Even when all is well, operators are users. They make typos. Having entered 
something correctly they can typo the verification. Having entered something 
incorrectly, they can typo the verification. Without a load of "DID YOU REALLY 
MEAN THAT?" 'conversation', find another way to do it. It'll be vastly simpler.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

ACCEPT does not involve a COBOL file (meaning there is no SELECT, no OPEN, 
CLOSE or any other IO statement, no FD).

ACCEPT therefore has no possible mechanism to "check the open worked". The sole 
"fix" for SYSIN missing is to include SYSIN (usually in the JCL - I don't think 
it can be dynamically added, certainly SYSOUT cannot, and I'd initially go with 
SYSIN not for the same general reasons).

In my experience, ACCEPT is used very little in Mainframes. If you want control 
over something, define it as a file, use OPEN/READ/CLOSE as normal. Then it is 
just a file, which happens to be 80-bytes fixed.

Beyond the potential usefulness (or otherwise) of a "conversation" with OPs, I 
don't think there should be ACCEPTs in a Production program. Just make it a 
file.

My use of ACCEPT is for those little programs to try things out. For a start, 
ACCEPTed data fools the compiler (with OPT) in a way that literals don't. 

This is not to say that ACCEPT doesn't have its cuteness: define a PIC X(240), 
ACCEPT with that field, and watch (well, not watch, it's COBOL, what are you 
going to see?), observe that it sucks of three input cards at once.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

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

Re: Error in a simple COBOL program

[Jesse 1 Robinson]

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 +, 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

Re: Error in a simple COBOL program

[Andy Wood]

On Tue, 12 Jul 2016 00:29:08 +, Jesse 1 Robinson  
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

Re: Error in a simple COBOL program

[Jesse 1 Robinson]

Unsuccessful open is not necessarily the end of the world. The application 
might choose to issue a message and terminate. Or open some other file. Or 
proceed without file input. It's not wise to forge ahead trying to perform I/O 
to an unopen file, but nothing systemically prevents you. 

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. 

.
.
.
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 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Error in a simple COBOL program

On Mon, 11 Jul 2016 17:19:17 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

>It's a Severe run-time error. Nothing can be done about it (except make the 
>appropriate correction). Well, possibly you could use an LE abend handler, but 
>why?
>
>Plain ACCEPT does not have a SELECT statement, so you can't specify FILE 
>STATUS. It is not a "file" to the COBOL program, I don't think you can get at 
>it with DECLARATIVES (I should check).
>
>I think you meant S0C4, not S0C1.

No, I didn't mean S0C4:

> CEE3201S The system detected an operation exception (System Completion 
> Code=0C1

Serve error or not, why confound things with an operation exception?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Frank Swarbrick]

Where are you seeing this S0C1?

When I do an ACCEPT and don't have SYSIN in my JCL I see the following on the 
console:


IEC130I SYSINDD STATEMENT MISSING
IEA995I SYMPTOM DUMP OUTPUT  559
  USER COMPLETION CODE=4093 REASON CODE=001C
 TIME=18.18.23  SEQ=05662  CPU=  ASID=0036
 PSW AT TIME OF ERROR  078D1000   864B638C  ILC 2  INTC 0D
   NO ACTIVE MODULE FOUND
   NAME=UNKNOWN
   DATA AT PSW  064B6386 - 00181610  0A0DA7F4  001C1811
   GR 0: 0001_8400   1: _84000FFD
  2: _001C   3: _0001
  4: _0FD74C50   5: _0FD74118
  6: _0FD73520   7: _0FD739D0
  8: _8000   9: _8000
  A: _0001   B: _864B62B8
  C: _0FD67018   D: _0FD63538
  E: _86622032   F: _001C
 END OF SYMPTOM DUMP
IEF450I MEMTEST ONE - ABEND=S000 U4038 REASON=0001  561
TIME=18.18.23


And in CEEMSG I see:

IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
 From compile unit ACC at entry point ACC at statement 7 at compile 
unit offset +02A6 at entry offset +02A6 at
 address 0E8002A6.




From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Andy Wood <woo...@ozemail.com.au>
Sent: Monday, July 11, 2016 4:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

On Mon, 11 Jul 2016 17:19:17 -0500, Bill Woodger <bill.wood...@gmail.com> wrote:

>It's a Severe run-time error. Nothing can be done about it (except make the 
>appropriate correction). Well, possibly you could use an LE abend handler, but 
>why?
>
>Plain ACCEPT does not have a SELECT statement, so you can't specify FILE 
>STATUS. It is not a "file" to the COBOL program, I don't think you can get at 
>it with DECLARATIVES (I should check).
>
>I think you meant S0C4, not S0C1.

No, I didn't mean S0C4:

> CEE3201S The system detected an operation exception (System Completion 
> Code=0C1

Serve error or not, why confound things with an operation exception?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Frank Swarbrick]

Ah, yes, I've never seen a (real) COBOL program run under TSO with user 
interaction either.

On the other hand I've seen many batch programs with CONSOLE interaction (for 
better or worse!).


As for your other question, no I would not be keen on using labels, 
PERFORM...THRU (or SECTION!!), and GO TO statements for those code structures; 
which is why I am so pleased that I can use EXIT PERFORM instead!

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Bill Woodger <bill.wood...@gmail.com>
Sent: Monday, July 11, 2016 4:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error in a simple COBOL program

Yes, sorry, Frank, I meant "not with interaction". I've never run a COBOL 
program under TSO, so never attempted to "interact" with it (on the Mainframe).

I have seen some VS and VSE programs which communicated with the Operator (I've 
even seen one go into a loop, but it is not difficult to CANCEL), but never 
seen that allowed (for mere programmers) from MVS onwards.

The reason for the explicit priming-read paragraph is that usually/often there 
is stuff to do on the first read which is irrelevant for subsequent ones.

It's late here, so I'll have a look at your code tomorrow. For now, would you 
be as keen on the code structures if those were plain GO TOs (given that you'd 
have to have THRU and extra labels, but...)?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Andy Wood]

On Mon, 11 Jul 2016 17:19:17 -0500, Bill Woodger  wrote:

>It's a Severe run-time error. Nothing can be done about it (except make the 
>appropriate correction). Well, possibly you could use an LE abend handler, but 
>why?
>
>Plain ACCEPT does not have a SELECT statement, so you can't specify FILE 
>STATUS. It is not a "file" to the COBOL program, I don't think you can get at 
>it with DECLARATIVES (I should check).
>
>I think you meant S0C4, not S0C1.

No, I didn't mean S0C4:

> CEE3201S The system detected an operation exception (System Completion 
> Code=0C1

Serve error or not, why confound things with an operation exception?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Yes, sorry, Frank, I meant "not with interaction". I've never run a COBOL 
program under TSO, so never attempted to "interact" with it (on the Mainframe). 

I have seen some VS and VSE programs which communicated with the Operator (I've 
even seen one go into a loop, but it is not difficult to CANCEL), but never 
seen that allowed (for mere programmers) from MVS onwards.

The reason for the explicit priming-read paragraph is that usually/often there 
is stuff to do on the first read which is irrelevant for subsequent ones.

It's late here, so I'll have a look at your code tomorrow. For now, would you 
be as keen on the code structures if those were plain GO TOs (given that you'd 
have to have THRU and extra labels, but...)?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

It's a Severe run-time error. Nothing can be done about it (except make the 
appropriate correction). Well, possibly you could use an LE abend handler, but 
why?

Plain ACCEPT does not have a SELECT statement, so you can't specify FILE 
STATUS. It is not a "file" to the COBOL program, I don't think you can get at 
it with DECLARATIVES (I should check).

I think you meant S0C4, not S0C1.


On Monday, 11 July 2016 23:40:12 UTC+2, Andy Wood  wrote:
> I have seen countless ABEND0C1s due to some rookie programmer not checking 
> that an OPEN was successful.
> 
> Here, the code clearly does check:
> 
> > IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> > unsuccessful.
> 
> Am I the only one here to question why it would then ignore this discovery? 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Andy Wood]

I have seen countless ABEND0C1s due to some rookie programmer not checking that 
an OPEN was successful.

Here, the code clearly does check:

> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful.

Am I the only one here to question why it would then ignore this discovery? 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Frank Swarbrick]

Bill, I thought you just said you'd never seen this before on the mainframe!  
:-)


I'm going to sidetrack this a bit to try to plug EXIT PERFORM.  Yes, I know you 
(Bill) don't like it.  But I'm curious on others thoughts about the following 
(taking your program and changing it):

+1+2+3+4+5+6+7--
   ID DIVISION.
   PROGRAM-ID. CALC1000.
   DATA DIVISION.
   FILE SECTION.
   WORKING-STORAGE SECTION.
   01  PIC X VALUE LOW-VALUES.
   88  EXIT-OF-PERFORM   VALUE HIGH-VALUES.
   01  INPUT-DATA.
   05  FILLER.
   88  END-OF-INTERACTIVE-SESSION  VALUE HIGH-VALUES
 ZERO.
   10  SALES-AMOUNTPIC 9(5)V99.
   05  FILLER  PIC X(73).
   01  SALES-TAX   PIC Z,ZZZ.99.
   PROCEDURE DIVISION.
   PERFORM UNTIL EXIT-OF-PERFORM
   PERFORM  READ-DATA
   IF END-OF-INTERACTIVE-SESSION
   EXIT PERFORM
   END-IF
   PERFORM  CALCULATE-ONE-SALES-TAX
   END-PERFORM
   GOBACK
   .
   CALCULATE-ONE-SALES-TAX.
   COMPUTE SALES-TAX ROUNDED= SALES-AMOUNT
 * 0.0785
   DISPLAY
   SALES-AMOUNT
   " SALES TAX = "
   SALES-TAX
   PERFORM  READ-DATA
   .
   READ-DATA.
   MOVE HIGH-VALUES TO INPUT-DATA
   ACCEPT INPUT-DATA
   .


The good (in my mind):

- There is one and only one "point of input".  No explicit "priming read".

- It is more obvious that you are processing the input and then looping back to 
read the next input.  (And then exiting without processing (*) if there is no 
more input.)


The bad (in my mind):

The COBOL standard (#) does not support:

- a comparison of two literals (IF 0 = 1)

- a "infinite/unbounded loop" (PERFORM UNTIL EXIT)


MicroFocus COBOL and GNU COBOL both have the "non-standard" PERFORM UNTIL EXIT 
/ PERFORM FOREVER.

Fujitsu COBOL has the "non-standard" PERFORM WITH NO LIMIT.

IBM Enterprise COBOL has nothing similar and IBM refuses to implement one.  
(Yes, I'm obsessive and upset about this.)


(*) The following might make it more apparent that we're not doing processing 
if there is no more input:

   PERFORM UNTIL EXIT-OF-PERFORM
   PERFORM  READ-DATA
   IF END-OF-INTERACTIVE-SESSION
   EXIT PERFORM
   ELSE
   PERFORM  CALCULATE-ONE-SALES-TAX
   END-IF
   END-PERFORM

Frank




From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Bill Woodger <bill.wood...@gmail.com>
Sent: Sunday, July 10, 2016 11:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error in a simple COBOL program

Here's one with the priming read, and a little trick for multiple ACCEPTs, 
because ACCEPT doesn't give "end of file".

+1+2+3+4+5+6+7--
   ID DIVISION.
   PROGRAM-ID. CALC1000.
   DATA DIVISION.
   FILE SECTION.
   WORKING-STORAGE SECTION.
   01  INPUT-DATA.
   05  FILLER.
   88  END-OF-INTERACTIVE-SESSION  VALUE HIGH-VALUES
 ZERO.
   10  SALES-AMOUNTPIC 9(5)V99.
   05  FILLER  PIC X(73).
   01  SALES-TAX   PIC Z,ZZZ.99.
   PROCEDURE DIVISION.
   PERFORM  PRIMING-READ
   PERFORM  CALCULATE-ONE-SALES-TAX
   UNTIL END-OF-INTERACTIVE-SESSION
   GOBACK
   .
   CALCULATE-ONE-SALES-TAX.
   COMPUTE SALES-TAX ROUNDED= SALES-AMOUNT
 * 0.0785
   DISPLAY
   SALES-AMOUNT
   " SALES TAX = "
   SALES-TAX
   PERFORM  READ-DATA
   .
   PRIMING-READ.
   PERFORM  READ-DATA
   .
   READ-DATA.
   MOVE HIGH-VALUES TO INPUT-DATA
   ACCEPT INPUT-DATA
   .


The trick is through the knowledge that when ACCEPT operates and there is no 
remaining data, the target field (INPUT-DATA) remains unchanged. So set the 
target-field to a known value which cannot exist (logically) in the input, and 
you have an end-of-file test. In this case this is a catch-all for if

Re: Error in a simple COBOL program

[Frank Swarbrick]

I use ACCEPT within a loop "all the time" for simple "SYSIN processing".


MOVE LOW-VALUES TO INPUT-AREA

ACCEPT INPUT-AREA

PERFORM UNTIL INPUT-AREA = LOW-VALUES

PERFORM PROCESS-INPUT-AREA

MOVE LOW-VALUES TO INPUT-AREA

ACCEPT INPUT-AREA

END-PERFORM


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Bill Woodger <bill.wood...@gmail.com>
Sent: Sunday, July 10, 2016 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error in a simple COBOL program

No. If you look at the SYSIN dataset that was used in the original JCL, it is 
has a DSN on it, a member of a PDS. The entire "session" responses can be 
included within that dataset without a problem. Or with a problem if the data 
does not conform to what the COBOL program "expects". It makes no difference 
whether the program is run in batch or TSO with that DSN, it does matter that 
the DSN is in the correct place.

If the intention was to have an actual interactive session there would be no 
need to put data in that dataset (assumed) and attempt a compile-and-go with it.

As an example of Mainframe COBOL for a beginner, it is a poor one, as I can 
count on the toes of one hand the number of times I've seen ACCEPT used in a 
loop on the Mainframe. It is a common type of example for a beginners' 
non-Mainframe COBOL course. It has been applied, by someone, to the Mainframe.

Yes, you could use TSO, but to what advantage? To see the magnificent GUI that 
you can create? The options for input (which require that you code everything)?

The immediate problem, as has been mentioned, is the override "misses" (or 
perhaps was not even attempted).

The wider issue is that ACCEPT (and DISPLAY) in IBM COBOLs are very simple. 
Every other Vendor and their dog has Extended ACCEPT and DISPLAY - because they 
don't run on Mainframes, and you need something other than punched cards to 
communicate to the user with.

Mainframe training for batch COBOL needs to be about file processing. 
Non-Mainframe training for COBOL needs to deal with the ACCEPT, DISPLAY (and 
maybe SCREEN SECTION) of the implementation of COBOL being trained for.

The interest in this particular task is "you have to code it all yourself" 
which is, in fact., a somewhat more advanced task than the example.

On Sunday, 10 July 2016 15:18:54 UTC+2, Keith Smith  wrote:
> What is missing is a method of making the program "know" that you want it
> to get input from your screen. (or so it seems)
>
> If you want terminal input you need to use CICS or ISPF PANEL processing.
> Or possibly execute this program from TSO. It has been a while but I know
> of no way to tie a batch job to your terminal.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Steve Smith]

The SYSIN file in the OP's JCL was the source member for the compile.  
It has no relation to the program's execution other than the coincidence 
of the name SYSIN.  Very likely, this caused some confusion.


Obviously the OP is working on learning COBOL and JCL, and possibly many 
other things.  Feel free to continue training, but you should consider 
the audience's level of understanding, not to mention the limitations of 
an email list for instruction.


sas

On 7/10/2016 14:15, Bill Woodger wrote:

Sure. And there is a dataset with SYSIN data on it, which implies no human 
intervention. What do we do now, explode due to the contradiction?

As I said, my guess is a non-Mainframe training example applied to the 
Mainframe.

For a COBOL program on the Mainframe, I see no point in "interacting" in TSO. 
It doesn't happen in the wild. Why learn how to do it? Learning for learning, sure, but 
not as training for COBOL on a Mainframe.

On Sunday, 10 July 2016 19:59:02 UTC+2, Dan Skomsky  wrote:

The original program includes the following statements:

DISPLAY "TO END PROGRAM, ENTER 0.".
DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".

The above statements are executed prior to "ACCEPT"ing every inputted amount.   
If the intent of this program was to receive input from a file, why would these 
statements be within the source?  Why would they be repeatedly executed?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Ah. My carefully crafted scheme has failed. The SYSIN is the COBOL program, and 
I suppose it is "some considerable number of years" since it needed the 
step-name for that to work.

Thanks Walt for pointing that out.

OK, run it under TSO. Don't compile-and-go, just compile and link. Assign the 
input and output and run the program. Interact away. Enjoy, you'll never be 
doing it for real.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Sure. And there is a dataset with SYSIN data on it, which implies no human 
intervention. What do we do now, explode due to the contradiction?

As I said, my guess is a non-Mainframe training example applied to the 
Mainframe. 

For a COBOL program on the Mainframe, I see no point in "interacting" in TSO. 
It doesn't happen in the wild. Why learn how to do it? Learning for learning, 
sure, but not as training for COBOL on a Mainframe.

On Sunday, 10 July 2016 19:59:02 UTC+2, Dan Skomsky  wrote:
> The original program includes the following statements:
> 
>DISPLAY "TO END PROGRAM, ENTER 0.".
>DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".
> 
> The above statements are executed prior to "ACCEPT"ing every inputted amount. 
>   If the intent of this program was to receive input from a file, why would 
> these statements be within the source?  Why would they be repeatedly executed?
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Dan Skomsky]

The original program includes the following statements:

   DISPLAY "TO END PROGRAM, ENTER 0.".
   DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".

The above statements are executed prior to "ACCEPT"ing every inputted amount.   
If the intent of this program was to receive input from a file, why would these 
statements be within the source?  Why would they be repeatedly executed?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Sunday, July 10, 2016 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error in a simple COBOL program

Here's one with the priming read, and a little trick for multiple ACCEPTs, 
because ACCEPT doesn't give "end of file".

+1+2+3+4+5+6+7--
   ID DIVISION. 
   PROGRAM-ID. CALC1000. 
   DATA DIVISION. 
   FILE SECTION. 
   WORKING-STORAGE SECTION. 
   01  INPUT-DATA. 
   05  FILLER. 
   88  END-OF-INTERACTIVE-SESSION  VALUE HIGH-VALUES 
 ZERO. 
   10  SALES-AMOUNTPIC 9(5)V99. 
   05  FILLER  PIC X(73). 
   01  SALES-TAX   PIC Z,ZZZ.99. 
   PROCEDURE DIVISION. 
   PERFORM  PRIMING-READ 
   PERFORM  CALCULATE-ONE-SALES-TAX 
   UNTIL END-OF-INTERACTIVE-SESSION 
   GOBACK 
   . 
   CALCULATE-ONE-SALES-TAX. 
   COMPUTE SALES-TAX ROUNDED= SALES-AMOUNT 
 * 0.0785 
   DISPLAY 
   SALES-AMOUNT 
   " SALES TAX = " 
   SALES-TAX 
   PERFORM  READ-DATA 
   . 
   PRIMING-READ. 
   PERFORM  READ-DATA 
   . 
   READ-DATA. 
   MOVE HIGH-VALUES TO INPUT-DATA 
   ACCEPT INPUT-DATA 
   . 


The trick is through the knowledge that when ACCEPT operates and there is no 
remaining data, the target field (INPUT-DATA) remains unchanged. So set the 
target-field to a known value which cannot exist (logically) in the input, and 
you have an end-of-file test. In this case this is a catch-all for if the 
"user" gets the "I don't want any more" response wrong when using a dataset for 
input. 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

Here's one with the priming read, and a little trick for multiple ACCEPTs, 
because ACCEPT doesn't give "end of file".

+1+2+3+4+5+6+7--
   ID DIVISION. 
   PROGRAM-ID. CALC1000. 
   DATA DIVISION. 
   FILE SECTION. 
   WORKING-STORAGE SECTION. 
   01  INPUT-DATA. 
   05  FILLER. 
   88  END-OF-INTERACTIVE-SESSION  VALUE HIGH-VALUES 
 ZERO. 
   10  SALES-AMOUNTPIC 9(5)V99. 
   05  FILLER  PIC X(73). 
   01  SALES-TAX   PIC Z,ZZZ.99. 
   PROCEDURE DIVISION. 
   PERFORM  PRIMING-READ 
   PERFORM  CALCULATE-ONE-SALES-TAX 
   UNTIL END-OF-INTERACTIVE-SESSION 
   GOBACK 
   . 
   CALCULATE-ONE-SALES-TAX. 
   COMPUTE SALES-TAX ROUNDED= SALES-AMOUNT 
 * 0.0785 
   DISPLAY 
   SALES-AMOUNT 
   " SALES TAX = " 
   SALES-TAX 
   PERFORM  READ-DATA 
   . 
   PRIMING-READ. 
   PERFORM  READ-DATA 
   . 
   READ-DATA. 
   MOVE HIGH-VALUES TO INPUT-DATA 
   ACCEPT INPUT-DATA 
   . 


The trick is through the knowledge that when ACCEPT operates and there is no 
remaining data, the target field (INPUT-DATA) remains unchanged. So set the 
target-field to a known value which cannot exist (logically) in the input, and 
you have an end-of-file test. In this case this is a catch-all for if the 
"user" gets the "I don't want any more" response wrong when using a dataset for 
input.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

On Sunday, 10 July 2016 15:56:12 UTC+2, Eric Mendelson  wrote:
> From tso allocate Sysin to your terminal and call the load module from tso 
> 

Then re-type the test data from the dataset.

Thinking further, I have used ACCEPT to obtain a variable number of input 
cards. Just not tried it "interactively" with message to the user and such...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Bill Woodger]

No. If you look at the SYSIN dataset that was used in the original JCL, it is 
has a DSN on it, a member of a PDS. The entire "session" responses can be 
included within that dataset without a problem. Or with a problem if the data 
does not conform to what the COBOL program "expects". It makes no difference 
whether the program is run in batch or TSO with that DSN, it does matter that 
the DSN is in the correct place.

If the intention was to have an actual interactive session there would be no 
need to put data in that dataset (assumed) and attempt a compile-and-go with it.

As an example of Mainframe COBOL for a beginner, it is a poor one, as I can 
count on the toes of one hand the number of times I've seen ACCEPT used in a 
loop on the Mainframe. It is a common type of example for a beginners' 
non-Mainframe COBOL course. It has been applied, by someone, to the Mainframe.

Yes, you could use TSO, but to what advantage? To see the magnificent GUI that 
you can create? The options for input (which require that you code everything)?

The immediate problem, as has been mentioned, is the override "misses" (or 
perhaps was not even attempted).

The wider issue is that ACCEPT (and DISPLAY) in IBM COBOLs are very simple. 
Every other Vendor and their dog has Extended ACCEPT and DISPLAY - because they 
don't run on Mainframes, and you need something other than punched cards to 
communicate to the user with.

Mainframe training for batch COBOL needs to be about file processing. 
Non-Mainframe training for COBOL needs to deal with the ACCEPT, DISPLAY (and 
maybe SCREEN SECTION) of the implementation of COBOL being trained for.

The interest in this particular task is "you have to code it all yourself" 
which is, in fact., a somewhat more advanced task than the example.

On Sunday, 10 July 2016 15:18:54 UTC+2, Keith Smith  wrote:
> What is missing is a method of making the program "know" that you want it
> to get input from your screen. (or so it seems)
> 
> If you want terminal input you need to use CICS or ISPF PANEL processing.
> Or possibly execute this program from TSO. It has been a while but I know
> of no way to tie a batch job to your terminal.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Eric Mendelson]

From tso allocate Sysin to your terminal and call the load module from tso 


Sent from my iPhone 

> On Jul 10, 2016, at 9:18 AM, Keith Smith <keith.sm...@shawinc.com> wrote:
> 
> What is missing is a method of making the program "know" that you want it
> to get input from your screen. (or so it seems)
> 
> If you want terminal input you need to use CICS or ISPF PANEL processing.
> Or possibly execute this program from TSO. It has been a while but I know
> of no way to tie a batch job to your terminal.
> 
>> On Sat, Jul 9, 2016 at 2:40 AM, Cameron Seay <cws...@gmail.com> wrote:
>> 
>> I am experiencing a run time error with a simple COBOL program.  It
>> compiles fine.  Here is the source code
>> IDENTIFICATION DIVISION.
>>  *
>>   PROGRAM-ID. CALC1000.
>>  *
>>   ENVIRONMENT DIVISION.
>>  *
>>   INPUT-OUTPUT SECTION.
>>  *
>>   DATA DIVISION.
>>  *
>>   FILE SECTION.
>>  *
>>   WORKING-STORAGE SECTION.
>>  *
>>   77  END-OF-SESSION-SWITCH   PIC X   VALUE "N".
>>   77  SALES-AMOUNTPIC 9(5)V99.
>>   77  SALES-TAX   PIC Z,ZZZ.99.
>>  *
>>   PROCEDURE DIVISION.
>>  *
>>   000-CALCULATE-SALES-TAX.
>>  *
>>   PERFORM 100-CALCULATE-ONE-SALES-TAX
>>   UNTIL END-OF-SESSION-SWITCH = "Y".
>>   DISPLAY "END OF SESSION.".
>>   STOP RUN.
>>  *
>>   100-CALCULATE-ONE-SALES-TAX.
>>  *
>>   DISPLAY "---".
>>   DISPLAY "TO END PROGRAM, ENTER 0.".
>>   DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".
>>   ACCEPT SALES-AMOUNT.
>>   IF SALES-AMOUNT = ZERO
>>   MOVE "Y" TO END-OF-SESSION-SWITCH
>>   ELSE
>>   COMPUTE SALES-TAX ROUNDED =
>>   SALES-AMOUNT * .0785
>>   DISPLAY "SALES TAX = " SALES-TAX.
>> 
>> Here is the JCL:
>> 
>> ==MSG>   your edit profile using the command RECOVERY ON.
>> 000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY=
>> 000110 //**
>> 000120 //* COMPILE COBOL PROGRAM
>> 000130 //**
>> 000140 //STEP1 EXEC IGYWCLG
>> 000150 //SYSINDD DSN=(CALC1001),DISP=SHR
>> 000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR
>> 000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR
>> 
>> Here is the error:
>> 
>> ---
>> TO END PROGRAM, ENTER 0.
>> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
>> IEC130I SYSINDD STATEMENT MISSING
>> ***
>> 
>> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN
>> was uns
>> uccessful.
>> CEE3201S The system detected an operation exception (System Completion
>> Code=0C1
>> ).
>>  From compile unit CALC1000 at entry point CALC1000 at compile
>> unit off
>> set +02DC at entry offset +02DC
>>   at address 1EE312DC.
>> Abend 0C1000 hex occurred processing command 'CALL'.
>> ***
>> 
>> I can't find what is missing.
>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> -- 
> Keith Smith
> Engineer-Enterprise Sys Sr.-IT Capacity & Performance
> Shaw Industries Inc.
> Subsidiary of Berkshire Hathaway
> 616 E Walnut Ave
> Mail Drop 072-04
> Dalton, GA 30721
> Email: keith.sm...@shawinc.com  Office: 706.532.3244
> 
> Please consider the environment before printing.
> 
> -- 
> **
> Privileged and/or confidential information may be contained in this 
> message. If you are not the addressee indicated in this message (or are not 
> responsible for delivery of this message to that person) , you may not copy 
> or deliver this message to anyone. In such case, you should destroy this 
> message and notify the sender by reply e-mail.
> If you or your employer do not consent to Internet e-mail for messages of 
> this kind, please advise the sender.
> Shaw Industries does not provide or endorse any opinions, conclusions or 
> other information in this message that do not relate to the official 
> business of the company  or its subsidiaries.
> **
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Keith Smith]

What is missing is a method of making the program "know" that you want it
to get input from your screen. (or so it seems)

If you want terminal input you need to use CICS or ISPF PANEL processing.
Or possibly execute this program from TSO. It has been a while but I know
of no way to tie a batch job to your terminal.

On Sat, Jul 9, 2016 at 2:40 AM, Cameron Seay <cws...@gmail.com> wrote:

> I am experiencing a run time error with a simple COBOL program.  It
> compiles fine.  Here is the source code
>  IDENTIFICATION DIVISION.
>   *
>PROGRAM-ID. CALC1000.
>   *
>ENVIRONMENT DIVISION.
>   *
>INPUT-OUTPUT SECTION.
>   *
>DATA DIVISION.
>   *
>FILE SECTION.
>   *
>WORKING-STORAGE SECTION.
>   *
>77  END-OF-SESSION-SWITCH   PIC X   VALUE "N".
>77  SALES-AMOUNTPIC 9(5)V99.
>77  SALES-TAX   PIC Z,ZZZ.99.
>   *
>PROCEDURE DIVISION.
>   *
>000-CALCULATE-SALES-TAX.
>   *
>PERFORM 100-CALCULATE-ONE-SALES-TAX
>UNTIL END-OF-SESSION-SWITCH = "Y".
>DISPLAY "END OF SESSION.".
>STOP RUN.
>   *
>100-CALCULATE-ONE-SALES-TAX.
>   *
>DISPLAY "---".
>DISPLAY "TO END PROGRAM, ENTER 0.".
>DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".
>ACCEPT SALES-AMOUNT.
>IF SALES-AMOUNT = ZERO
>MOVE "Y" TO END-OF-SESSION-SWITCH
>ELSE
>COMPUTE SALES-TAX ROUNDED =
>SALES-AMOUNT * .0785
>DISPLAY "SALES TAX = " SALES-TAX.
>
> Here is the JCL:
>
>  ==MSG>   your edit profile using the command RECOVERY ON.
>  000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY=
>  000110 //**
>  000120 //* COMPILE COBOL PROGRAM
>  000130 //**
>  000140 //STEP1 EXEC IGYWCLG
>  000150 //SYSINDD DSN=(CALC1001),DISP=SHR
>  000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR
>  000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR
>
> Here is the error:
>
> ---
> TO END PROGRAM, ENTER 0.
> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
> IEC130I SYSINDD STATEMENT MISSING
> ***
>
>  IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN
> was uns
> uccessful.
>  CEE3201S The system detected an operation exception (System Completion
> Code=0C1
> ).
>   From compile unit CALC1000 at entry point CALC1000 at compile
> unit off
> set +02DC at entry offset +02DC
>at address 1EE312DC.
>  Abend 0C1000 hex occurred processing command 'CALL'.
>  ***
>
> I can't find what is missing.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Keith Smith
Engineer-Enterprise Sys Sr.-IT Capacity & Performance
Shaw Industries Inc.
Subsidiary of Berkshire Hathaway
616 E Walnut Ave
Mail Drop 072-04
Dalton, GA 30721
Email: keith.sm...@shawinc.com  Office: 706.532.3244

Please consider the environment before printing.

-- 
**
Privileged and/or confidential information may be contained in this 
message. If you are not the addressee indicated in this message (or are not 
responsible for delivery of this message to that person) , you may not copy 
or deliver this message to anyone. In such case, you should destroy this 
message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of 
this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or 
other information in this message that do not relate to the official 
business of the company  or its subsidiaries.
**


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Jesse 1 Robinson]

I defer to Bill in all matters COBOL as he has set me straight on many such 
matters. Including something similar in my early ABO adventures. However, this 
is not a COBOL problem. It's a JCL problem. S0C1 and missing SYSIN are not 
coincidental. S0C1 is caused by the inability of the system to find the SYSIN 
DD statement coded. That pretty much always happens with 'missing' DD. In this 
case, MVS cannot associate the coded SYSIN with the executed step. Whether the 
program works as intended (mine did not), JCL must be constructed so that the 
coded SYSIN is provided as input to the problem program. 

Just look at the expanded PROC in the runtime job and 'connect' SYSIN to the 
GO-time step via 'stepname.SYSIN DD'. Then you can begin to debug your actual 
program. 

.
.
.
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 Bill Woodger
Sent: Saturday, July 09, 2016 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Error in a simple COBOL program

On Saturday, 9 July 2016 18:20:58 UTC+2, Dan Skomsky  wrote:
> Once you get the JCL ironed out, I think you need to make some changes to the 
> COBOL source itself.
> 
> The DISPLAY and ACCEPT verbs without targets default to SYSIN and SYSPRINT 
> accordingly.  If you wish to communicate to the console you must code 
> 'DISPLAY ... UPON CONSOLE' and 'ACCEPT ... FROM CONSOLE'.  From the way the 
> code is written, the program will go into an infinite loop looking for SYSIN 
> and printing on SYSPRINT.
> 

Without seeing the data, this need not be true :-)

However, it is an excellent point for someone new to COBOL who may think this 
is "zero" in the context of that ACCEPT.

0

It isn't. 

You data for that program must always, always, contain:

000

Ensure you have a TIME= in your JCL, and make it very small. Small as you can.

Are you running the program under TSO? The "***" is throwing me. In my 
experience, use of the CONSOLE is not permitted for application programmers. 
TSO is one answer, and you can get "interactive", but actual application 
programs won't be running that way, and interactive for the... fun of it... 
does not mean much.

I'd suggest not using the compile-and-go. Use the compile-and-link and set up 
some JCL for yourself to execute the program. When you late want to find some 
reference to what you did, having an actual bit of JCL with the date/time it 
was last edited is useful. 

Since you are learning COBOL, some tips. Should provoke others :-)

Don't use 77s. They were always untidy, but served a purpose when storage for a 
program was more limited. Like in the 1970s. Today they do no space-saving and 
are still untidy.

Use the END- constructs to terminate the scope of conditions. You'll have to do 
that for...

Don't use a single full-stop/period in the PROCEDURE DIVISION that is not 
needed. A world-wide total of $74 trillion* (1964 prices) has been lost through 
the errant (present in the wrong place, or missing altogether) 
full-stop/period. Since COBOL II it has been a needless loss.

Don't test and set a flag if the value itself can be used to control the loop. 
Use an 88 on the source field, and always use an 88 over defining literals in 
the PROCEDURE DIVISION.

Formatting a program is good. Placing a blank comment-line after each line of 
code will drive everyone** nuts when you give them code to find issues with.

COBOL is a language of words. You can use symbols, like =, but why...?

Here's a small rewrite:

+1+2+3+4+5+6+7--
   ID DIVISION. 
   PROGRAM-ID. CALC1000. 
   DATA DIVISION. 
   FILE SECTION. 
   WORKING-STORAGE SECTION. 
   01  SALES-AMOUNTPIC 9(5)V99. 
   88  END-OF-INTERACTIVE-SESSION  VALUE ZERO. 
   01  SALES-TAX   PIC Z,ZZZ.99. 
   PROCEDURE DIVISION. 
   PERFORM CALCULATE-ONE-SALES-TAX 
   UNTIL END-OF-INTERACTIVE-SESSION 
   DISPLAY "END OF SESSION." 
   GOBACK 
   . 
   CALCULATE-ONE-SALES-TAX. 
   DISPLAY 
   "---" 
   DISPLAY 
   "TO END PROGRAM, ENTER 000" 
   DISPLAY 
   "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT," 
   DISPLAY 
   "WITH SEVEN DIGITS, INCLUDING TWO DECIMAL DIGITS," 
   DISPLAY 
   "BUT WITH NO DECIMAL POINT, AND DON'T EVEN " 
   DISPLAY 
   "CONSIDER USING A SIGN FOR A REVERSAL." 
   ACCEPT SALES-AMOUNT 
   COMPUTE SALES-

Error in a simple COBOL program

[Bill Woodger]

On Saturday, 9 July 2016 18:20:58 UTC+2, Dan Skomsky  wrote:
> Once you get the JCL ironed out, I think you need to make some changes to the 
> COBOL source itself.
> 
> The DISPLAY and ACCEPT verbs without targets default to SYSIN and SYSPRINT 
> accordingly.  If you wish to communicate to the console you must code 
> 'DISPLAY ... UPON CONSOLE' and 'ACCEPT ... FROM CONSOLE'.  From the way the 
> code is written, the program will go into an infinite loop looking for SYSIN 
> and printing on SYSPRINT.
> 

Without seeing the data, this need not be true :-)

However, it is an excellent point for someone new to COBOL who may think this 
is "zero" in the context of that ACCEPT.

0

It isn't. 

You data for that program must always, always, contain:

000

Ensure you have a TIME= in your JCL, and make it very small. Small as you can.

Are you running the program under TSO? The "***" is throwing me. In my 
experience, use of the CONSOLE is not permitted for application programmers. 
TSO is one answer, and you can get "interactive", but actual application 
programs won't be running that way, and interactive for the... fun of it... 
does not mean much.

I'd suggest not using the compile-and-go. Use the compile-and-link and set up 
some JCL for yourself to execute the program. When you late want to find some 
reference to what you did, having an actual bit of JCL with the date/time it 
was last edited is useful. 

Since you are learning COBOL, some tips. Should provoke others :-)

Don't use 77s. They were always untidy, but served a purpose when storage for a 
program was more limited. Like in the 1970s. Today they do no space-saving and 
are still untidy.

Use the END- constructs to terminate the scope of conditions. You'll have to do 
that for...

Don't use a single full-stop/period in the PROCEDURE DIVISION that is not 
needed. A world-wide total of $74 trillion* (1964 prices) has been lost through 
the errant (present in the wrong place, or missing altogether) 
full-stop/period. Since COBOL II it has been a needless loss.

Don't test and set a flag if the value itself can be used to control the loop. 
Use an 88 on the source field, and always use an 88 over defining literals in 
the PROCEDURE DIVISION.

Formatting a program is good. Placing a blank comment-line after each line of 
code will drive everyone** nuts when you give them code to find issues with.

COBOL is a language of words. You can use symbols, like =, but why...?

Here's a small rewrite:

+1+2+3+4+5+6+7--
   ID DIVISION. 
   PROGRAM-ID. CALC1000. 
   DATA DIVISION. 
   FILE SECTION. 
   WORKING-STORAGE SECTION. 
   01  SALES-AMOUNTPIC 9(5)V99. 
   88  END-OF-INTERACTIVE-SESSION  VALUE ZERO. 
   01  SALES-TAX   PIC Z,ZZZ.99. 
   PROCEDURE DIVISION. 
   PERFORM CALCULATE-ONE-SALES-TAX 
   UNTIL END-OF-INTERACTIVE-SESSION 
   DISPLAY "END OF SESSION." 
   GOBACK 
   . 
   CALCULATE-ONE-SALES-TAX. 
   DISPLAY 
   "---" 
   DISPLAY 
   "TO END PROGRAM, ENTER 000" 
   DISPLAY 
   "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT," 
   DISPLAY 
   "WITH SEVEN DIGITS, INCLUDING TWO DECIMAL DIGITS," 
   DISPLAY 
   "BUT WITH NO DECIMAL POINT, AND DON'T EVEN " 
   DISPLAY 
   "CONSIDER USING A SIGN FOR A REVERSAL." 
   ACCEPT SALES-AMOUNT 
   COMPUTE SALES-TAX ROUNDED= SALES-AMOUNT 
 * 0.0785 
   DISPLAY 
   "SALES TAX = " 
   SALES-TAX 
   . 

If you run that (an remember to obey the instructions, as in obey), you'll 
encounter some issues. You have effectively a "heading", and you output it each 
time. Looks tacky. And that cool way of stopping the loop doesn't seem to work. 
Look to use a PERFORM to do the heading, and look at how to do a "priming read" 
(and put your read in a PERFORM, in this case an ACCEPT).

Then you can consider some flexibility. ACCEPT (Format 1, in the Language 
Reference) will always give you input as though your target field is 
alpha-numeric. It will be left-justified, and padded to the end with blanks. 
Exercise (non-trivial) allow the user to enter numbers in the normal types of 
way.

* this may be considered to be an overestimate
** may be an overstatement

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Dan Skomsky]

Once you get the JCL ironed out, I think you need to make some changes to the 
COBOL source itself.

The DISPLAY and ACCEPT verbs without targets default to SYSIN and SYSPRINT 
accordingly.  If you wish to communicate to the console you must code 'DISPLAY 
... UPON CONSOLE' and 'ACCEPT ... FROM CONSOLE'.  >From the way the code is 
written, the program will go into an infinite loop looking for SYSIN and 
printing on SYSPRINT.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Saturday, July 09, 2016 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Error in a simple COBOL program

First, I would go to www.ibm.link and look up the details on the compiler procs 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea200/clccat2.htm

These have not changed in a long time so any version of z/OS or OS/390 should 
be okay to use for understanding the JCL.

Next, review the JCL Manual to understand how to use the PROCs and override JCL 
statements.

When executing a proc, it can be made up of multiple Steps.  Each step will 
have a requirement for input and output.  From your error of

IEC130I SYSINDD STATEMENT MISSING

That is a JCL error and should be addressed. 

The other errors
  IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
  CEE3201S The system detected an operation exception (System Completion 
Code=0C1 ).
   From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +02DC at entry offset +02DC
at address 1EE312DC.
  Abend 0C1000 hex occurred processing command 'CALL'.
  ***

Are related to your missing SYSIN DD Statement.

When you resolve your SYSIN DD Missing condition the other errors should be 
resolved.


I might suggest that you add some error handling to your COBOL program for 
failed opens.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Cameron Seay
> Sent: Friday, July 08, 2016 11:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Error in a simple COBOL program
> 
> I am experiencing a run time error with a simple COBOL program.  It 
> compiles fine.  Here is the source code  IDENTIFICATION DIVISION.
>   *
>PROGRAM-ID. CALC1000.
>   *
>ENVIRONMENT DIVISION.
>   *
>INPUT-OUTPUT SECTION.
>   *
>DATA DIVISION.
>   *
>FILE SECTION.
>   *
>WORKING-STORAGE SECTION.
>   *
>77  END-OF-SESSION-SWITCH   PIC X   VALUE "N".
>77  SALES-AMOUNTPIC 9(5)V99.
>77  SALES-TAX   PIC Z,ZZZ.99.
>   *
>PROCEDURE DIVISION.
>   *
>000-CALCULATE-SALES-TAX.
>   *
>PERFORM 100-CALCULATE-ONE-SALES-TAX
>UNTIL END-OF-SESSION-SWITCH = "Y".
>DISPLAY "END OF SESSION.".
>STOP RUN.
>   *
>100-CALCULATE-ONE-SALES-TAX.
>   *
>DISPLAY "---".
>DISPLAY "TO END PROGRAM, ENTER 0.".
>DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".
>ACCEPT SALES-AMOUNT.
>IF SALES-AMOUNT = ZERO
>MOVE "Y" TO END-OF-SESSION-SWITCH
>ELSE
>COMPUTE SALES-TAX ROUNDED =
>SALES-AMOUNT * .0785
>DISPLAY "SALES TAX = " SALES-TAX.
> 
> Here is the JCL:
> 
>  ==MSG>   your edit profile using the command RECOVERY ON.
>  000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY=
>  000110 //**
>  000120 //* COMPILE COBOL PROGRAM
>  000130 //**
>  000140 //STEP1 EXEC IGYWCLG
>  000150 //SYSINDD DSN=(CALC1001),DISP=SHR
>  000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR
>  000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR
> 
> Here is the error:
> 
> ---
> TO END PROGRAM, ENTER 0.
> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
> IEC130I SYSINDD STATEMENT MISSING
> ***
> 
>  IGZ0017S The open of DISPLAY or ACCEPT file with environment name 
> SYSIN was uns uccessful.
>  CEE3201S The system detected an operation exception (System 
> Completion
> Code=0C1
> ).
>   From compile unit CALC1000 at entry point CALC1000 at 
> compile unit off set +02DC at entry offset +02DC
>at address 1EE312DC.
>  Abend 0C1000 hex occurred processing command 'CALL'.
>  ***
> 
> I can't find wha

Re: Error in a simple COBOL program

[Lizette Koehler]

First, I would go to www.ibm.link and look up the details on the compiler procs
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea200/clccat2.htm

These have not changed in a long time so any version of z/OS or OS/390 should 
be okay to use for understanding the JCL.

Next, review the JCL Manual to understand how to use the PROCs and override JCL 
statements.

When executing a proc, it can be made up of multiple Steps.  Each step will 
have a requirement for input and output.  From your error of

IEC130I SYSINDD STATEMENT MISSING

That is a JCL error and should be addressed. 

The other errors
  IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
unsuccessful.
  CEE3201S The system detected an operation exception (System Completion 
Code=0C1 ).
   From compile unit CALC1000 at entry point CALC1000 at compile unit 
offset +02DC at entry offset +02DC
at address 1EE312DC.
  Abend 0C1000 hex occurred processing command 'CALL'.
  ***

Are related to your missing SYSIN DD Statement.

When you resolve your SYSIN DD Missing condition the other errors should be 
resolved.


I might suggest that you add some error handling to your COBOL program for 
failed opens.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Seay
> Sent: Friday, July 08, 2016 11:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Error in a simple COBOL program
> 
> I am experiencing a run time error with a simple COBOL program.  It compiles
> fine.  Here is the source code  IDENTIFICATION DIVISION.
>   *
>PROGRAM-ID. CALC1000.
>   *
>ENVIRONMENT DIVISION.
>   *
>INPUT-OUTPUT SECTION.
>   *
>DATA DIVISION.
>   *
>FILE SECTION.
>   *
>WORKING-STORAGE SECTION.
>   *
>77  END-OF-SESSION-SWITCH   PIC X   VALUE "N".
>77  SALES-AMOUNTPIC 9(5)V99.
>77  SALES-TAX   PIC Z,ZZZ.99.
>   *
>PROCEDURE DIVISION.
>   *
>000-CALCULATE-SALES-TAX.
>   *
>PERFORM 100-CALCULATE-ONE-SALES-TAX
>UNTIL END-OF-SESSION-SWITCH = "Y".
>DISPLAY "END OF SESSION.".
>STOP RUN.
>   *
>100-CALCULATE-ONE-SALES-TAX.
>   *
>DISPLAY "---".
>DISPLAY "TO END PROGRAM, ENTER 0.".
>DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".
>ACCEPT SALES-AMOUNT.
>IF SALES-AMOUNT = ZERO
>MOVE "Y" TO END-OF-SESSION-SWITCH
>ELSE
>COMPUTE SALES-TAX ROUNDED =
>SALES-AMOUNT * .0785
>DISPLAY "SALES TAX = " SALES-TAX.
> 
> Here is the JCL:
> 
>  ==MSG>   your edit profile using the command RECOVERY ON.
>  000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY=
>  000110 //**
>  000120 //* COMPILE COBOL PROGRAM
>  000130 //**
>  000140 //STEP1 EXEC IGYWCLG
>  000150 //SYSINDD DSN=(CALC1001),DISP=SHR
>  000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR
>  000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR
> 
> Here is the error:
> 
> ---
> TO END PROGRAM, ENTER 0.
> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.
> IEC130I SYSINDD STATEMENT MISSING
> ***
> 
>  IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> uns
> uccessful.
>  CEE3201S The system detected an operation exception (System Completion
> Code=0C1
> ).
>   From compile unit CALC1000 at entry point CALC1000 at compile unit
> off
> set +02DC at entry offset +02DC
>at address 1EE312DC.
>  Abend 0C1000 hex occurred processing command 'CALL'.
>  ***
> 
> I can't find what is missing.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Error in a simple COBOL program

[Jeremy Nicoll]

On Sat, 9 Jul 2016, at 07:40, Cameron Seay wrote:

> Here is the JCL:
> 
>  ==MSG>   your edit profile using the command RECOVERY ON. 
>  000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY=   
>  000110 //**   
>  000120 //* COMPILE COBOL PROGRAM  
>  000130 //**   
>  000140 //STEP1 EXEC IGYWCLG   
>  000150 //SYSINDD DSN=(CALC1001),DISP=SHR  
>  000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR
>  000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR

Your   IGYWCLG  procedure, judging from its name  is a  Compile  Link 
Go  one, which 
therefore probably expands to three separate steps.  It's the third
step, the GO one
for which you'd need to define SYSIN.So the JCL (which does have a
SYSIN statement
now) is probably applying that to the first step of three.

Depending on what the stepname of the GO step is, you probably need to
code eg 

//stepname.SYSIN DD ...

-- 
Jeremy Nicoll - my opinions are my own.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Error in a simple COBOL program

[Cameron Seay]

I am experiencing a run time error with a simple COBOL program.  It compiles 
fine.  Here is the source code
 IDENTIFICATION DIVISION.
  *
   PROGRAM-ID. CALC1000.
  *
   ENVIRONMENT DIVISION.
  *
   INPUT-OUTPUT SECTION.
  *
   DATA DIVISION.
  *
   FILE SECTION.
  *
   WORKING-STORAGE SECTION.
  *
   77  END-OF-SESSION-SWITCH   PIC X   VALUE "N".
   77  SALES-AMOUNTPIC 9(5)V99.
   77  SALES-TAX   PIC Z,ZZZ.99.
  *
   PROCEDURE DIVISION.
  *
   000-CALCULATE-SALES-TAX.
  *
   PERFORM 100-CALCULATE-ONE-SALES-TAX
   UNTIL END-OF-SESSION-SWITCH = "Y".
   DISPLAY "END OF SESSION.".
   STOP RUN.
  *
   100-CALCULATE-ONE-SALES-TAX.
  *
   DISPLAY "---".
   DISPLAY "TO END PROGRAM, ENTER 0.".
   DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.".
   ACCEPT SALES-AMOUNT.
   IF SALES-AMOUNT = ZERO
   MOVE "Y" TO END-OF-SESSION-SWITCH
   ELSE
   COMPUTE SALES-TAX ROUNDED =
   SALES-AMOUNT * .0785
   DISPLAY "SALES TAX = " SALES-TAX.

Here is the JCL:

 ==MSG>   your edit profile using the command RECOVERY ON. 
 000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY=   
 000110 //**   
 000120 //* COMPILE COBOL PROGRAM  
 000130 //**   
 000140 //STEP1 EXEC IGYWCLG   
 000150 //SYSINDD DSN=(CALC1001),DISP=SHR  
 000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR
 000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR

Here is the error:

--- 
TO END PROGRAM, ENTER 0.
TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT. 
IEC130I SYSINDD STATEMENT MISSING   
*** 

 IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was uns
uccessful.  
 CEE3201S The system detected an operation exception (System Completion Code=0C1
).  
  From compile unit CALC1000 at entry point CALC1000 at compile unit off
set +02DC at entry offset +02DC 
   at address 1EE312DC. 
 Abend 0C1000 hex occurred processing command 'CALL'.   
 ***
  
I can't find what is missing.   
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN