-1

I would be very grateful for any pointer towards what exactly it is that I am doing wrong with the very minimal, very trivial COBOL program below. It performs a rounding of a result with COBOL's standard tool, the language element ROUNDED. The ulterior motive is to build a large application and apply a time metric to different modes of rounding, given a long series of operations and subsequent roundings for each mode. (The even more ulterior motive is to learn COBOL backwards, this is only a project within that plan, and then try to land a job using and developing COBOL).

The program is listed below. It performs one simple addition, and the result is passed to a variable with a smaller data width which enforces rounding. 

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. ROUNDINGTEST.
000300 ENVIRONMENT DIVISION.
000400 DATA DIVISION.
000500  WORKING-STORAGE SECTION.
000600   01 OPERAND01 PIC S9(2)V9(4) VALUE 1.4745.
000610   01 OPERAND02 PIC S9(2)V9(4) VALUE 1.9874.
000610   01 RESULT    PIC S9(2)V9(2).
000700 PROCEDURE DIVISION.
000800  PROGRAM-BEGIN.
000900   COMPUTE RESULT ROUNDED MODE NEAREST-EVEN
001000     = OPERAND01 + OPERAND02  
001010    END-COMPUTE
001020
001100  PROGRAM-DONE.
001200 STOP RUN.

Compilation with GnuCOBOL's compiler, as below, gives the results below.

martin@martin-1001PX:~/CobolProjects$ cobc -b ROUNDINGTEST.cob
ROUNDINGTEST.cob: In paragraph 'PROGRAM-BEGIN':
ROUNDINGTEST.cob:11: Error: syntax error, unexpected MODE
martin@martin-1001PX:~/CobolProjects$

No exchange of the indicated mode to any other, Truncation, Towards-Lesser...produces any change. Commenting out lines 000900, 001000 and 001010 gives an error-free response, so clearly the problem is not a cascading problem from earlier in the code or any kind of syntactical mishap later – it's the rounding that doesn't work.

GNU COBOL 2.0 (Formerly OpenCOBOL) [11FEB2012 Version] Programmer’s Guide 2nd Edition, 21 November 2013

has the COMPUTE syntax as below

COMPUTE { identifier-1 [ rounding-option ] } … =|EQUAL arithmetic-expression-1 [ size-error-clause ] [ END-COMPUTE ]

and the syntax of the qualifier ROUNDED (the rounding-option above) as

                     AWAY-FROM-ZERO
                     NEAREST-AWAY-FROM-ZERO
                     NEAREST-EVEN
 ROUNDED MODE IS     NEAREST-TOWARD-ZERO
                     PROHIBITED
                     TOWARD-GREATER
                     TOWARD-LESSER
                     TRUNCATION

where the “IS” is a non-mandatory readability option.

Compact and trivial as this might seem, no amount of revision or testing has availed me to any success. Any meaningful communication on the matter would be much appreciated.

Titchmarsh
  • 9
  • 4
  • A paragraph/SECTION must end with a full-stop/period. I get different results from your failure (I've using V2,0 of the compiler, not the released 1.1) but still a failure. The message could be better(!), if you want to log that at the GnuCOBOL space at SourceForge.net, it could provoke a useful improvement. Hey, you could even look to code it up yourself. – Bill Woodger Feb 12 '16 at 12:52
  • A paragraph/SECTION must indeed end with a full-stop/period, and so they all do in my code, inclusive of PROGRAM-BEGIN. and PROGRAM-DONE. nearest to the failure point. What particular message is it that could be better, the error message from the compiler through the shell? Do you want me to set compiler options so there's more meat in the error message? Hm. I feel I've got the search area narrowed down nicely as it is. – Titchmarsh Feb 12 '16 at 15:27
  • SourceForge is an excellent next stop, though. Good suggestion. Be looking into that shortly. – Titchmarsh Feb 12 '16 at 15:28
  • 1
    You have terminated the paragraph labels, but not the paragraph itself prior to `PROGRAM-DONE`. END-COMPUTE does not terminate the paragraph, there's no full-stop/period, so the compiler is coming across PROGRAM-DONE and thinking it is an identifier. In my compiler, which is 2.0. – Bill Woodger Feb 12 '16 at 16:54

1 Answers1

1

(This should likely be a comment, not an answer, but wanted the code listing to show up).

This works, as Bill pointed out:

000100 IDENTIFICATION DIVISION.                                         
000200 PROGRAM-ID. ROUNDINGTEST.                                        
000300 ENVIRONMENT DIVISION.                                            
000400 DATA DIVISION.                                                   
000500  WORKING-STORAGE SECTION.                                        
000600   01 OPERAND01 PIC S9(2)V9(4) VALUE 1.4745.                      
000610   01 OPERAND02 PIC S9(2)V9(4) VALUE 1.9874.                      
000610   01 RESULT    PIC S9(2)V9(2).                                   
000700 PROCEDURE DIVISION.                                              
000800  PROGRAM-BEGIN.                                                  
000900   COMPUTE RESULT ROUNDED MODE NEAREST-EVEN                       
001000     = OPERAND01 + OPERAND02                                      
001010    END-COMPUTE                                                   
001020  .                                                                
001100 PROGRAM-DONE.                                                    
001200 STOP RUN.

The period on 1020 changes the state of the compiler from looking for another statement in the paragraph to looking for a new paragraph or statement, which might be a label.

Brian Tiffin
  • 3,978
  • 1
  • 24
  • 34
  • All that you tell me makes perfect sense, my feeling for how COBOL programs should be apportioned is exactly corroborated by what you write, only my compiler keeps giving me the exact same error message for all combinations, whether without the period, with the period alone on 1020 or with the period right after END-COMPUTE. Likely, my compiler has a bug, or GnuCOBOL isn't ready for this yet. – Titchmarsh Feb 12 '16 at 22:29
  • It's clear this is a lost cause. No reason to get bogged down in this. I am a newbie here and I am not allowed to vote yet, so I'll just write a thank you right here to Messrs. Tiffin and Woodger for their time and consideration. – Titchmarsh Feb 12 '16 at 22:46
  • @Titchmarsh Looking closer, your version of the compiler isn't 2.0, it's an earlier version that doesn't support ROUNDED MODE IS. Try a version with `COMPUTE RESULT ROUNDED *> MODE NEAREST-EVEN`, commenting out the MODE. Not a lost cause, just a blip. – Brian Tiffin Feb 13 '16 at 03:52
  • I don't mean to contradict you, you ARE "the man who wrote the book" on GnuCOBOL, but looking at GnuCOBOL's official hosting site https://sourceforge.net/projects/open-cobol/ I notice that the latest available version is gnu-cobol-1.1, which is the version I have. Is there any way I can avail myself of a more recent version, that would support ROUNDED MODE IS? Of course, taking out the MODE gave a viable executable after compilation with 1.1, as you said. – Titchmarsh Feb 13 '16 at 19:16
  • @Titchmarsh Yep, GnuCOBOL 2.0 is in the SVN Code repository. And under the file section, there are snapshots. Latest cut by Simon is Rev 658, https://sourceforge.net/projects/open-cobol/files/gnu-cobol/2.0/gnu-cobol-2.0_nightly_r658.tar.gz/download Not to spill any beans, but 2.0 official release candidate 1 is about 7 days away. I don't like giving these kind of dates, as being volunteers, things like real life can happen and getting hopes up can be bad for free software as people get antsy and impatient. But, official release of 2.0 is just around the corner. For now, snapshots. – Brian Tiffin Feb 13 '16 at 21:05
  • Thanks 1000,000. No rush, this is a volunteer project. I'll work on other COBOL topics during the wait. And if the fates should smile at me, I might be a volunteer myself one of these not too distant days, and work with the whole source code->C equivalent->executable apparatus of GnuCOBOL that you and Mr.Woodger shepherd so beautifully. :-) – Titchmarsh Feb 13 '16 at 22:42
  • When in comes to COBOL, in Bill We Trust. :-) We'd be glad for more volunteers @Titchmarsh. As soon as 2.0 is posted, (and any flurry of fixes that may occur) we start in on 2.something with ReportWriter (a branch that has been waiting in the wings for some two years now), and a Doxygen comment pass (on hold for over 4 years), along with plans for easing institutional deployments; so students don't have to fuss with installs and instructors (and professionals) have better tools for managing. The GnuCOBOL we have, is great, the GnuCOBOL we want, is somewhere over the horizon. – Brian Tiffin Feb 16 '16 at 08:00
  • Alright, @BrianTiffin, now that you have said A, perhaps you would also be kind enough to say B. Exactly which skills would volunteers preferably bring to the table - C, GCC, GDB, other? Would there be a way that a volunteer that provided something materially useful could also, in return, ask to have you, Mr. Woodger, Mr. Klein or some other senior officer on the project supply the quickest reference by mail to a prospective employer? – Titchmarsh Feb 16 '16 at 21:55
  • @Titchmarsh; to play fair with the rules of StackOverflow, let's take the rest of this conversation to SourceForge where we can openly discuss details. https://sourceforge.net/p/open-cobol/discussion/ In short though; any skills, as there is a wide area to cover; and yes we'd likely provide references once skills are demonstrated. – Brian Tiffin Feb 17 '16 at 11:37