The COBOL Language

| iMatix home page
| Libero home page | Libero documentation
| << | < | > | >>

Libero
Version 2.32

The COBOL Language

Overview

What Is COBOL?: COBOL is a standard language for business software, a job that it does well. It is heavily used in the mainframe world. COBOL has an undeserved reputation for inefficiency, and a deserved reputation for verbosity. Today, many COBOL applications are being moved from mainframes to UNIX boxes.
Portability: Deaf, dumb, blind COBOL programs can be very portable. Otherwise you can use external libraries to achieve 100% portability (catch: you may have to write these libraries yourself).
Pros and Cons: Pros: easy to use and teach. An excellent language for mediocre developers, which includes me at least two days of the week. Cons: Tends to encourage large, monolithic programs. Like unreadable C code, this is a question of discipline. COBOL provides no way to define data types directly, and has a verbose and over-rich syntax. COBOL compilers are often unimpressive. This is actually putting it mildly: on several systems that I've worked on, a simple loop in COBOL runs from 100 to 1000 times slower than the same loop coded in assembler. I've seen just one COBOL compiler (Versions 2 and 3 of Realia) that could produce truly excellent code.
How To Get It: No free implementations exist, despite various attempts -- including one by me: if a COBOL compiler is Mt. Everest, I got as far as London Heathrow airport. You need to find a commercial COBOL vendor for your system.
Libero Supports: ANSI 74 COBOL and ANSI 85 COBOL.

Working With COBOL

Schema: lrschema.cob.
Program model: main program without linkage or called program with linkage.
Good for: COBOL batch programs and subroutines.
Files used/made: own work in MYPROG.cob; generates a copy book MYDIALOG.cbl.
Module functions: MODULE-FUNCTION-NAME.
Private functions: PRIVATE-FUNCTION-NAME.
Naming style: schema sets -style=cobol automatically
Limits: 999 states, events, modules. (Libero allows 1000 of anything.) All tables are defined statically. Some compilers restrict any one 01-level item to 32K bytes.
Development cycle: run lr after you change the dialog. Edit the source program, then recompile and link.

Example of code

Code fragments:

*****************   MODULE FUNCTION NAME   *****************

 MODULE-FUNCTION-NAME.
     EXIT
     .

 PRIVATE-FUNCTION-NAME.
     MOVE OK-EVENT TO THE-NEXT-EVENT

     MOVE ERROR-EVENT TO THE-EXCEPTION-EVENT
     MOVE    "YES"    TO EXCEPTION-RAISED
     .

A fuller example.

Notes

The dialog file can't have same name as the program (on some systems the extension for a program and a copy book is the same); the schema gives an error message in this case. I suggest you use the -plusd option in your dialog.
Since there is no way to distinguish the dialog paragraphs ('modules') from private paragraphs, the schema turns-off idle module checking.
With some compilers (typically on IBM systems) you need to add a QUOTES option to compile the generated code. The generated code uses quotes, not apostrophes - this is more portable, though maybe unusual for IBM'ers.
There is no FEEDBACK variable or RAISE-EXCEPTION function, in contrast with most other schemas.
Assumes the old-fashioned 80-column format with 6-digit sequence number and 8-character comment at right-hand side. Generates upper-case text.

COBOL has a reputation for encouraging large unwieldy programs. This is justified to the extent that the language is verbose. I think it's more due to the fact that COBOL programs tend to be written and maintained under particular pressures: get it working, now, and who cares if it is a little unwieldy. You don't often see COBOL code competing on the open market for software where program size and speed are important.

People working in COBOL expect monsters, so often get them. Now, I've spent a lot of my life writing COBOL - perhaps half a million lines or so, and I know that this unnecessary suffering. Of course it is possible to write clean, organised, commented code without Libero. It is just a lot more effort, and I'm lazy.

This schema is for batch programs and subroutines. Batch programs are often the largest and most complex COBOL programs, and often benefit from a dialog. I've not seen a lot of subroutines that really needed a a dialog; the expression calculator is one example. Also, if you split a large batch program into smaller subroutines, these can be complex enough to warrant a dialog. Very roughly, I would reckon that a COBOL program of more than 1000 lines is worth building around a dialog.

Specific Schema Options

-opt:ext=xxx xxx is extension for copybook. Default value is cbl. Recommended values are: cob for MS-DOS Realia, cbl for UNIX, lib for VAX/VMS.
-opt:model=main The generated code does not define any linkage section. This is the default model.

-opt:model=called The generated code defines a linkage section that contains a single 01-level data item. You must detail this data item in a copybook called MYPROGR. The copybook must follow this general format, with a 01-level header, then a comment line containing the text '*CONTENTS', then the details of the linkage section. For example:

000100 01  CALCPK-CONTROL.
000200*CONTENTS
000300     02  CALCPK-OPERATION        PIC X.
000400     02  CALCPK-FEEDBACK         PIC X.
000500     02  CALCPK-POINT-CHAR       PIC X.
000600     02  CALCPK-ERROR-RETURN.
000700         03  CALCPK-ERROR-CODE   PIC X(2).
000800         03  CALCPK-ERROR-MESG   PIC X(30).
000900     02  CALCPK-ERROR-POSN       PIC 9(2).
001000     02  CALCPK-EXPRESSION.
001100         03  EXPR-CHAR           PIC X          OCCURS 80 TIMES.
001200     02  CALCPK-RESULT           PIC S9(9)V9(9).
001300     02  CALCPK-VARIABLE         PIC S9(9)V9(9) OCCURS 5 TIMES.

-opt:level=ansi74 Generate ANSI 74 COBOL. Some heritage COBOL compilers don't support ANSI 85 COBOL. This is the default level.
-opt:level=ansi85 Generate ANSI 85 COBOL. The ANSI 85 code runs a little faster, since it uses an EVALUATE statement against a series of IF statements in the ANSI 74 code.
-opt:console=name Display trace output and error messages on specified device. By default blank. Some systems do not like DISPLAY by itself, and require an output device name. For example, to generate statements DISPLAY ... UPON CONSOLE, use 'opt:console="UPON CONSOLE"'. Note that you must place quotes around the value for two reasons: it contains a space, and you want to keep it in uppercase.