For this post I assume the previously described lab environment setup and specially the minimal set of COBOL environment variables previously mentioned (and usually provided by the setup utility). Furthermore, I don't bother with any advanced or specialized scenarios. My goal is very basic: simply get started.
It's not difficult to translate a COBOL source-code (.CBL) file into a corresponding object-code (.OBJ) file of the same name, while also generating a nice and convenient source-code listing (.LST) file of the same name and taking all the defaults compiler directives. For instance, to compile MAIN.CBL into MAIN.OBJ and also get a MAIN.LST the command-line could be:
COBOL MAIN,,MAIN.LST;
In fact, following the above invocation of the compiler executable (COBOL or XCOBOL), there can be up to 5 comma-delimited parameters, possibly prematurely ended by a semi-colon. They are in order:
- The source-code file name (MAIN in the example).
Assumed to have the .CBL extension.
- The empty parameter ("in between" consecutive commas).
By default, assumes MAIN.OBJ (in the example) will be generated.
- An arbitrarily chosen name of the source-code listing file.
This has been chosed as MAIN.LST on the given example..
- The object-code listing file (containing Assembly instructions).
Not present on the previous example, hence ignored.
- A vast series of optional compiler directives.
Each directive is started by a / (none is present on the example).
This means I'm taking all the default directives.
The last step is to turn the object-code (.OBJ) into an executable-image (.EXE) which can be run on the computer. This is accomplished by the so-called linker (or link-editor), which invocation, in the simplest case, is rather straightforward as well. For the previous example, the command-line could be:
LINK MAIN;
In fact, following the invocation of the linker executable (LINK), there can be also at most 5 comma-delimited parameters, possibly prematurely ended by a semi-colon as well. They are respectively:
- The object-code file name (MAIN in the example).
Reasonably assumed to have the .OBJ extension.
In fact, it can be a series of object files, if needed.
- Usually an empty parameter (in-between commas).
Assumes, on the example, the executable-image will be MAIN.EXE.
Not explicitly present on the example, but taken by default.
- The (binary) map file name (.MAP).
When NUL, the default, assumes nothing will be generated.
Not present on the example, hence also taking the default.
- A series of "non-default" library (.LIB) files.
When empty, the default, only default libraries are considered.
Not present on the example, so using just the default libraries.
- A module definition (.DEF) for advanced builds.
By default, assumed NUL as for "nothing especial".
Not present on the example, so taking the default too.
And here is the whole picture of this (the easiest) case: