Questions About COBOL And Its Data Types 11

[Dimandja]

Questions about COBOL data types arise all too regularly on this forum. In fact, even seasoned COBOL programmers do get confused about some of the answers. I think this is the single most misunderstood area of COBOL, and the most controversial, and the most "improvised" by compiler designers. I think a FAQ (a thorough FAQ) is in order.

Another thing: are all these "exotic" data types helpful to the COBOL language, or are they mostly contributing to the isolation of COBOL from other computer languages?

Some COBOL compilers have been designed with data types that match the types used by most modern languages. For example, Nonstop COBOL programmers use the type NATIVE to duplicate the type INTEGER which is used by most other languages - eliminating puzzling questions about how much memory is used by data elements, and allowing data to be passed to and from COBOL with less headaches.

Isn't it about time that COBOL got rid of all these COMPs et al? Do those types really add anything to the language, or do they hurt it?

What do you think?

Remember, most other languages were largely designed by the programmers who use them. Must we leave the design of COBOL in the hands of committees and vendors?

Dimandja

 

[webrabbit]

That still doesn't address the problem of accessing data from outside the program, especially since such data does not even neccesarily come from the same machine. If there were truly "universal" data types that were not implementor/machine/language dependent, then that would not be a problem. But I haven't seen such an animal.

 

[Dimandja]

When you eliminate language dependency you have eliminated some headaches: which is the point of this thread.

 

[slade]

Thanx for the star Glenn.

 

[ceh4702]

What I cant stand is how we store a SSN. Since a lot of SSN start with 3,4,5 at one point we changed the order of the ssn and put part of the front in the rear. Then we packed the SSN and redefined it as a 5 character field. Part of the reason was saving space and prart of the reason was to be able to sort files faster. We use the SSN as the KEY, so we are stuck with it for now. This is just one more reason not to use the SSN as a key in any file. It would have made more sense in one file to have put it both ways so we could just look it up instead of trying to convert it all the time.

If you do not like my post feel free to point out your opinion or my errors.

 

[webrabbit]

ceh4702

What was the point of modifying the seqence of the characters in the SSN? Do you know, or is it just a historical anomally that you have to put up with?

Converting it to packed decimal does not seem to be a problem to me, except then treating it as a 5-byte alphameric field does seem fraught with danger. I suppose that some file/database system(s) required that the key be an alphameric field.