RE: [open-cobol-list] looking for ideas: more on internals (intrinsics)

[Bill Klein]

I haven't seen many (any?) replies to this one.

One of the big "issues" (or questions) with intrinsic functions is WHAT do
you do about invalid parameters.  In fact, this was the issue that actually
delayed the '89 Intrinsic Function amendment (originally it assigned
"invalid" returned values for all functions - and this was AWFUL).

IBM, for example, "ABENDs" when an invalid date is passed to INTEGER-OF-DATE
(which is HARDLY user-friendly).

On the other hand, at least one other compiler vendor (I can't remember
which) returns the value for 16100101 - if an invalid date is passed - and
doesn't give any "clue" that something has gone wrong!!!

I think that the '02 Standard has it "right" when it sets an "exception
condition" to exist when an invalid argument is passed, but the '02 "common
exception handling" feature is pretty complex - so I don't know that you
want to implement all of that - at least at first.

I don't have a good/portable/easy solution to this question - but did want
to raise the issue - before you spent a lot of development time on it.

One POSSIBLE approach would be to:
   A) establish some "new" special register that shows as "good or bad" (and
is set by each function)
   B) set a "default" returned value for when a "bad" argument was passed
   C) in the case of "nested" functions, set the special register to "bad"
if any level had a problem

***

Another issue with Intrinsic Functions is the "ALL" subscript.  This is
(possibly) the hardest - but also one of the more useful - features of
*some* intrinsic functions.  

"ALL" plus the fact that not all arguments need to have the same PIC/USAGE
is why it is difficult (impossible in STANDARD COBOL) to implement the
intrinsic functions in COBOL itself.

Two other "issues" that some vendors have had are:
 1) what to do with "figurative constants" (how long are they)?
 2) what to do with "zero-length" group items, i.e. a group item with an
OCCURS 0 below it.

Functions that need to compare either of the above can lead to "confusing"
implementations AND results.

***

Finally, my (limited) experience is that the DATE functions are the most
commonly used ones (on IBM mainframes at least - and to some extent with
Micro Focus).  I would certainly recommend implementing them first. 

If you do, then I would suggest implementing the TEST-xxxx functions from
the '02 Standard at the same time.

Also commonly used is the NUMVAL and NUMVAL-C functions.  
Also CHAR and ORD  (remembering - of course that X'00" = ORD(1) not "0")

 ***

I would certainly NOT implement ORD-MIN or ORD-MAX *unless* you are able to
handle the "ALL" subscript.


________________________________

        From: address@hidden
[mailto:address@hidden On Behalf Of Tim Nixon
        Sent: Tuesday, November 30, 2004 7:55 AM
        To: address@hidden
        Subject: [open-cobol-list] looking for ideas: more on internals
(intrinsics)
        
        

        We would like to add some of the internal cobol routines for code
we're supporting. For example: ORD-MAX, ORD-MIN, CURRENT-DATE and the like.
My initial concept is to write these in c, and modify the compiler to
understand the FUNCTION statement and map it to the appropriate library
routine, It would be important that the compiler could verify that each was
being supplied with the correct # (and type in the general sense) of
arguments. The implementation of the intrinsics would match the standard for
size, type etc for both arguments and return values. I also would like to
make the implementation robust in the sense that if we began with a few
routines we could easily add others as needed without modifying large
sections of code. Does anyone have any ideas that would be beneficial for
this project?

         

        Tim Nixon