COBOL Files and Data Types 2

[StephenJSpiro]

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

 

[Guest_imported]

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).

Where on web can I view COBOL workarounds for these file types? Thanks,

 

[k5tm]

Stephen,

Good article.

I would add to the data types omitted:
Date, Time, Timestamp
The concept of date and time has been in the standard for a long time, but there exist no data types which allow nonkludgy mainpulation.

And, to be slightly pedantic: PACKED-DECIMAL is standard; most vendors also have a nonstandard, implementor-defined alias for PACKED-DECIMAL (typically COMP-3).

Tom Morrison

 

[StephenJSpiro]

For VARCHAR and VARCHAR-LONG, you build a table with OCCURS DEPENDING ON, each occurrence is one character, and the max is your best guess. For field-mark data types, use UNSTRING.

PACKED-DECIMAL is (somewhat) specified in the standard, but its format, alignment and internal representation are implementor-defined, which makes them pretty much unique to each operating system (the source code is portable, but the data is not). Most hardware/operating system implementations have some sort of PACKED-DECIMAL data-type. I am not aware of any where the COBOL compiler is responsible for creating a data-type otherwise unusable on the system. (There MAY be; but who would want to implement COBOL on such a system?)

Stephen J Spiro
Member, ANSI COBOL Standards Committee

 

[k5tm]

Most hardware/operating system implementations have some sort of PACKED-DECIMAL data-type. I am not aware of any where the COBOL compiler is responsible for creating a data-type otherwise unusable on the system. (There MAY be; but who would want to implement COBOL on such a system?)

Stephen, can you clarify this remark? For example, how does this apply to COBOL on Wintel environments?


Tom Morrison

 

[StephenJSpiro]

I have not worked with COBOL on Wintel. If Thane is watching, perhaps he can shed some light on this...

Stephen J Spiro

 

[k5tm]

There is a thriving and highly competitive market for COBOL on Windows and Unix/Linux systems. Vendors include Micro Focus, Liant (RM/COBOL), Acucorp (AcuCOBOL), and CA (CA-Realia COBOL).

Neither Intel or the various RISC processors support PACKED-DECIMAL in hardware, and I am unaware of any packed decimal data type in Windows or Unix.

It is my experience, however, that almost all COBOL applications on these platforms use packed decimal, some to the exclusion of virtually any other numeric data type. My educated guess is that this is the result of wanting to save external storage space.

Tom Morrison

 

[RonaldB]

Stephen,

i especially liked the "state-of-the-art whiz-bang computer-science leading-edge languages" bit; ou must have had it under Ctrl-V to get it exactly the same every time... LOL

Regards,
Ronald.