[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Potential modifications to COBOL relative to IEEE 754



I would suggest that yes, taking a look at one's source program to see if anything needed to be changed before attempting to compile the program on a different platform would be "conventional", and even "traditional" in the COBOL world. 
 
The SOURCE-COMPUTER and OBJECT-COMPUTER paragraphs of the ENVIRONMENT DIVISION have been around for a VERY long time and are there still, and were mandatory in '68 and '74.  Granted, their functions and utility have changed over time (the MEMORY SIZE phrase of OBJECT-COMPUTER was marked obsolete in the '02 standard), and although the implementor was not REQUIRED to make any decisions based on the names used in these paragraphs as to how to handle the source code or what characteristics to impart to the object code, they were free to do so until the '02 standard.  And yes, it would be considered normal to change the names used in these paragraphs if migrating to a different system. 
 
The ARITHMETIC clause is in the OPTIONS paragraph of the IDENTIFICATION DIVISION.  It could philosophically be argued, in fact, that the proper place to put the ARITHMETIC clause would have been in the OBJECT-COMPUTER paragraph of the ENVIRONMENT DIVISION on historical grounds, rather than where it is.  As it stands, it's much nearer the the beginning of what might be termed "boiler plate" syntax where it is.  In fact, it's entirely legitimate for the beginning of a program to read "IDENTIFICATION DIVISION.  OPTIONS.  ARITHMETIC ...".  Shouldn't be all that tough to find!    
 
    -Chuck Stevens 
 
 
> Date: Sat, 26 Feb 2011 17:25:42 -0500
> To: stds-754@xxxxxxxxxxxxxxxxx
> From: hack@xxxxxxxxxxxxxx
> Subject: RE: Potential modifications to COBOL relative to IEEE 754
>
> > > I'm curious however how a programmer would write their code to run with
> > > best performance on either BID or DPD platforms ...
> >
> > Aside from the ARITHMETIC clause in the OPTIONS paragraph of the
> > IDENTIFICATION DIVISION, the source code is EXACTLY the same whether
> > the arithmetic mode specifies binary or decimal encoding.
> >
> > The implementor would certainly be free to build object code for BOTH
> > modes, and to build into the compiled object code do an inquiry at
> > the beginning of execution to find out which mode to use at run time.
>
> It is that one line of IDENTIFICATION DIVISION that I was concerned about,
> i.e. source code portability and not object code portability.
>
> Perhaps having to edit the IDENTIFICATION DIVISION for each platform is
> considered normal in COBOL, and does not count as a source change. In
> that case my concern is indeed moot. As I said, my recollections about
> COBOL date back to 45 years ago, and even back then I only used COBOL
> (in French, actually) in homework assignments.
>
> Languages like C deal with environmental considerations by inclusion
> of standard header files, which can define platform-specific types, and
> compiler options can take care of such issues as well. This allows the
> source code to be left unchanged when compiling on different platforms.
> Perhaps something similar exists for COBOL too.
>
> Michel.
> ---Sent: 2011-02-26 22:38:06 UTC

754 | revision | FAQ | references | list archive