[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gnubol: "Extensions" that aid in C/COBOL ILC
I just remembered another area that needs to be looked at:
"upper-/lower-case" equivalence in "externally known" names, eg PROGRAM-ID
(ID division and CALL statement), COPY statement, EXTERNAL data, etc.
Bill Klein
wmklein <at> ix.netcom.com
> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of William M. Klein
> Sent: Tuesday, December 28, 1999 12:24 PM
> To: gnu
> Subject: gnubol: "Extensions" that aid in C/COBOL ILC
>
>
> 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.
--
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.