gnubol: "Extensions" that aid in C/COBOL ILC

["William M. Klein" <wmklein@ix.netcom.com>]

In an earlier set of notes, I indicated that I would provide some input on
extensions that I would recommend getting a relatively high priority.  This
note is targeted at (what we at Micro Focus used to call C-ification) those
features that aid in inter-language communication between COBOL and C.  (This
also helps COBOL applications use APIs that are written assuming a C-type
interface.) In some cases, I am "recommending" going with (at least 1st) the
"draft" definition of some things - even though there are existing
(non-portable) extensions that already exist in some (many?) implementations.

1) USAGE POINTER
  This also includes the
       SET ADDRESS OF
          and
       SET pointer-data-item TO ADDRESS OF
  variations of the SET statement.

  Some existing implementations ONLY allow you to get the address (or to set
the address) of LINKAGE SECTION items.  I would recommend allowing you to GET
the address of any item (WS or Linkage).  You should only be allowed to SET
THE ADDRESS of an 01-level (possibly a 77-level).  Personally, I would be
"happy" with this being limited to Linkage Section, but wouldn't object to it
including Working-Storage as well.

2) USAGE PROCEDURE-POINTER
   Does *not* seem as critical to me - but may be viewed as important by
others.  It seems to me that it is most useful if you also add the extension
which allows RECURSIVE programs in COBOL.  If you are going to do that, you
will also need to add the LOCAL-STORAGE SECTION.  (I certainly would
recommend AGAINST adding the whole OO system from the draft - at least in a
"first" implementation.)

3)CALL extensions.
  I would recommend supporting the "BY VALUE" phrase and the "RETURNING"
phrase.  Both of these are fairly common extensions already and are supported
in the draft.

4) CALL-CONVENTION
   This is a pretty "non-portable" feature (even in the draft Standard) but I
think does need to be included in any API-friendly environment.

5) Floating-Point data items.
  The draft adds USAGE
	 FLOAT-SHORT
	 FLOAT-LONG
	 FLOAT-EXTENDED
  which I think should be added.

IBM (and those that emulate it) use COMP-1 and COMP-2.  FYI,  several of the
"PC" emulators do try and give a choice between S/390 floating-point and IEEE
floating-point.  This does NOT seem necessary to me in a first
implementation, but is something to think about.

NOTE WELL:
  The draft Standard also includes "floating-point numeric-edited" data items
for "displaying" floating-point items.  This is not critical to C/COBOL
interfaces, but is probably desirable for any implementation that includes
the "internal" floating-point data-types. There is also the concept of
"ARITHMETIC IS STANDARD" in the draft - which is "really nice" but adds a LOT
of complexity to the language. It also relates to the expansion of numeric
data types from 18 to 31 digits.

6) "BINARY data"
 At a minimum, I would recommend adding (from the draft) USAGE
	 BINARY-CHAR
	 BINARY-SHORT
	 BINARY-LONG
	 BINARY-DOUBLE
		(each with SIGNED/UNSIGNED sub-options)

 In addition, you may want to look at COMP-5 which is an X/Open extension
(which unlike the draft USAGES does include a PICTURE clause - which can
include a decimal point).

The "biggest" questions are what to do about the existing extensions which
handle:
   - Big-Endian/Little-Endian issues (different PC vendors handle this in
different ways)
   - TRUNC/NOTRUNC compiler options which "override" the rules for decimal
truncation on USAGE BINARY items
   - What does "COMP" mean.  (Although it is COMMON for COMP to equal BINARY;
there are also implementations where it equals PACKED-DECIMAL and even a few
where it equals DISPLAY).  In addition, you may want to look at COMP-3 (often
PACKED-DECIMAL) and COMP-4 (often BINARY) and COMP-6 (often UNSIGNED
Packed-DECIMAL)

   ****

A couple of other things that are worth CONSIDERING from the draft Standard
(but not as critical in my opinion):

A) User-Defined functions.
  If you are going to "write your own intrinsic functions in COBOL" - then
you will need MOST of the stuff required by the draft for these.  On the
other hand, there are things that the intrinsic functions require that are
NOT included in the draft Standard for user-defined functions (such as the
"ALL" subscript and FUNCTION MAX being able to take a variety of types of
arguments).

B) CALL (and function) "proto-types" which allow for argument checking at
compile-time. (I know that this was mentioned in another thread, so I am
including it here.  It is in the draft, but not in the '85 Standard).

C) (*NOT* in the draft Standard)  You need to think very early about whether
or not you are going to try and provide any "real" EBCDIC support.  If you
are interested in providing a "supportive" environment for (many) existing
COBOL programs, this becomes a real issue.  HOWEVER, providing such an
environment is a LOT of work.

 ****

I may think of more items for "C-ificiation" - but did think that this was a
good starting place for a discussion (both of the desirability and the
difficulty of some of these extensions).


Bill Klein
  wmklein <at> ix.netcom.com


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.