There are no such things as COBOL files and COBOL data types.
COBOL is, far and away, the most versatile high level language in the computer industry. From the beginning, COBOL was designed to be flexible in handling all manner of file structures and data structures.
Data types and file organization is determined by vendors to operate on particular hardware and operating system architectures. COBOL is designed to process these formats.
HIDAM databases (such as IMS) came with their own Application Programming Interfaces (APIs), so "native" COBOL syntax was never developed. Relational databases came with SQL from the beginning, so "native" COBOL syntax was never developed. The CODASYL Journal of Development had some syntax for new datatypes, but it has not been adopted because a commercial need has never developed.
COBOL syntax handles sequential, relative, and indexed files natively. "Line Sequential" should have been added to the standard, but all COBOL compilers which run on systems which use it, have it as an extension.
There was a great deal of effort to expand the new COBOL standard to handle many more datatypes than previously. Incomprehensibly, 3 data types were omitted, and they must be processed in COBOL using kludges: (SQL types VARCHAR and VARCHAR-LONG, as well as field-mark deleimited data types). Nevertheless, COBOL remains the most flexible high-level language in the industry.
A note: the format of PACKED-DECIMAL is not specified in the COBOL standard. Its internal representation varies from computer-maker to computer-maker. Not only is the internal representation different, the Syntax is not standard, either. Some call it COMP-3, others COMP-2 or anything else. ALL COMP-x data types are IMPLEMENTOR-DEFINED. They are ALL extensions to the standard.
Programmers using state-of-the-art whiz-bang computer-science leading-edge languages frequently need to access files and/or data types originally created by COBOL programs, and find that their state-of-the-art whiz-bang computer-science leading-edge languages are totally inadequate to handle anything except some subset of their systems capabilities. ERRONEOUSLY, they blame this on COBOL, rather than the inadequate state-of-the-art whiz-bang computer-science leading-edge tools which they are using.
Stephen J Spiro
Member, ANSI COBOL Standards Committee
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.