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: 0000000 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-AMOUNT PIC 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 0000000" 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
