Re: gnubol: Anyone actually working on Cobol

[RKRayhawk@aol.com]

In a message dated 11/10/99 1:26:31 PM EST,
 Christopher Clark,   compudata@cadvision.com writes in part

...
<< 
             gnubol extension:  Also permit ADD number TO pointer identifier,
 SUBTRACT number FROM pointer-identifier?
 >>
...

The post was great over-all, but the quoted part is problematic. The problem 
is the unit of measure. If you get a pointer set to a table element then 
humans are going to think that
"Add 1" to the pointer bumps it to the next occurence, which would not be 
true.

Indexes can be intrinsically associated with OCCURS clauses or ODOs (OCCURS 
DEPENDING ON). those can be bumped by SET UP/DOWN syntax, just as the indexes 
that are not associated with a table per se, because a compiler actually 
treats these two as very distinct data types. Thus the identical syntax has 
distinct semantics.

Pointers on the other hand are never intrinsically tied to a data element. 
Regrettably what we fluid thinking humans mean by 'ADD 1' to a pointer 
actually varies (that is there are distinct semantics intended).  

I am not trying to be nit picking here, but with compilers I have used that 
have syntax such as you have suggested, actually the two ideas

        SET pointer-identifier UP BY arithmetic-expression
        SET pointer-identifier DOWN BY arithmetic-expression

would also have to be considered as extensions. Really only 

        SET index-identifier UP BY arithmetic-expression
        SET index-identifier DOWN BY arithmetic-expression

are legal.  And that is very different.

You could do what was suggested if you limit pointers to non-subscriptable 
data; but that would be a step backwards.

It is very inconvenient to many folks but addressing manipulation at the byte 
level is actually
performed with reference modification (by new programmers) or subscripting of 
an array that
redefines the matter being scanned (by old geezers). 

But I wish to state that you are emphatically on the right track, it would be 
nice to have an alternative! 

I point out in another post that in some of the newer compilers there is yet 
another type, PROCEDURE-POINTER that is distinct from mere POINTER, which is 
significant for authors of the grammar(s). As obtuse as it seems at first, 
maybe we need a CLARK-POINTER, that would allow your syntax, help avoid the 
old geezer rigmaroll, and just get real diagnostical if you attempt to 
harness an indexable item (element OR group) with it. Do you see what I mean?

In fact if you like overkill, and some COBOLers do, maybe a CLARK-POINTER 
could be used only on something declared elegible, like a CLARK-DATA (element 
or group). That has potential.  If you think about it, considering the value 
stored on COBOL databases, it might not be a bad first approach to say we 
don't want pointers scanning just any old thing, and we want auditors to be 
able to find the CLARK-POINTERs and CLARK-DATA readily!

By the way can you clarify something for me.  Most of the syntax you are 
suggesting looks to me like COBOL 85.  Is that not right? (We are aiming at 
COBOL 85). But I do not recognize the ALLOCATE and FREE commands. Are those 
also COBOL 85? Can you state what compiler familiarized you with that?

Best Wishes
Bob Rayhawk
RKRayhawk@aol.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.