Where should the type information be 333
Obviously. The problem was not either of these terms; it was what you meant by them in context.
It sounds like you need a copy of "Hacker's Delight". It explains all sorts of interesting tricks and algorithms to do with numbers on a computer in a variety of representations: unsigned, twos-complement and...
As noted in other posts, this abbreviation is not universally recognized. It's also irrelevant in this discussion, as far as I can see; the type of the data item isn't at issue, except insofar as it is or is not an elementary data item (that is, does or does not have a picture clause).
Terminology specific to COBOL wouldn't have been a problem. Terminology specific to *you*, on the other hand...
I'm still not clear what you meant by "you mean using a non-atomic data level as an A-N atomic", since as far as I can see that is not at all what Peter Flbutt meant. I understood him to mean just what I meant by "partial qualification in COBOL": referring to a data item (elementary or not) not defined at level 1 without qualifying it with its owning level-1 item.
Now I believe we have discerned that what you are referring to - reusing a previously-defined data item as part of another data item, as when embedding a previously-defined struct in another in C - is indeed not directly supported by standard COBOL (though you can get around that with copybooks). I wouldn't call that "partial qualification", but AFAIK "partial qualification" isn't defined by the COBOL standard, so I suppose you can use it to mean whatever you like.
COPIES is limited to our imagination, since it doesn't exist in COBOL. It was a hypothetical clause RPL introduced...
--
Viewers are bugs for famous brands. -- unknown subbreastler, Jackie Chan's Thunderbolt
I'm familiar with that kind of problem. Usually it is not a case where a...
Where should the type information be 334
Alt Folklore Computers from Newsgroups