Programming in COBOL

With COBOL you must use only EXEC CICS commands to invoke operating system services. Some COBOL statements must not be used. Simplified based addressing using cell pointer variables and the ADDRESS special register.

This section describes COBOL language elements that you cannot use under CICS, or whose use is restricted or can cause problems under XCICS.

In general, neither the XCICS translator nor the COBOL compiler detects the use of COBOL words affected by the following restrictions. The use of a restricted word in a CICS environment may cause a failure at execution time.

The following restrictions apply to a COBOL program that is to be used as an XCICS application program. (See the appropriate COBOL programming guide for more information about these functions.)

•	Statements that produce variable-length areas, such as OCCURS DEPENDING ON, should be used with caution within the WORKING-STORAGE SECTION.

•

If you have any CICS applications written in COBOL, you may need to review the COBOL runtime options in use at your installation. In particular, if your applications are not coded to ensure that the WORKING-STORAGE SECTION is properly initialized (for example, cleared with binary zeros before sending maps), you should use the correct compiler option to prevent this (i.e. DEFAULTBYTE=0 in MFCOBOL).

•	Do not use DISPLAY . . . UPON CONSOLE and DISPLAY . . . UPON SYSPUNCH. DISPLAY to the system logical output device ( SYSOUT, SYSLIST,SYSLST) is supported.

XCICS application programs need to access data dynamically when the data is in a XCICS internal area, and only the address is passed to the program. Examples are:

•	XCICS areas such as the CWA, TWA, and TCTTE user area (TCTUA), accessed using the ADDRESS command

•	Input data, obtained by EXEC CICS commands such as READ and RECEIVE with the SET option

COBOL provides a simple method of obtaining addressability to the data areas defined in the LINKAGE SECTION using pointer variables and the ADDRESS special register.

The ADDRESS special register holds the address of a record defined in the LINKAGE SECTION with level 01 or 77. This register can be used in the SET option of any command in ADDRESS mode. These commands include GETMAIN, LOAD, READ, and READQ.

In an XCICS system, when control is transferred from the active program to an external program, but the transferring program remains active and control can be returned to it, the program to which control is transferred is called a subprogram.

In the first form, the called subprogram is explicitly named as a nonnumeric literal within quotation marks. In the second form, name refers to the COBOL data area with length equal to that required for the name of the subprogram.

The identifier is the name of a COBOL data area that must contain the name of the called subprogram.

COBOL programs can call any language programs statically or dynamically. LINK or XCTL are not required for inter-language communication, unless you wish to use CICS functions such as COMMAREA.

Each LINK command creates a new logical level, the called program being at a level one lower than the level of the calling program (XCICS is taken to be at level 0). Figure 3 in topic 1.4.4.2 shows logical levels and the effect of RETURN commands and CALL statements in linked and called programs.

The following rules describe the requirements and behavior of called or linked subprograms.

The linked subprogram must be translated if it, or any subprogram invoked from it, invokes XCICS commands.

The called subprogram must be translated if it contains CICS commands or references to the EXEC interface block (DFHEIBLK) or to the CICS communication area (DFHCOMMAREA).

The linked subprogram must be defined in PPT. If the linked subprogram is unknown or unavailable, even though autoinstall is active, the LINK fails with the PGMIDERR condition.

The linked subprogram must return using either RETURN or a native language return command such as the COBOL statement GOBACK.

Data can be passed by any of the standard CICS methods (COMMAREA, TWA, TCTUA, TS queues) if the called or linked subprogram is processed by the CICS translator.

If the COMMAREA is used, its address must be passed in the LINK command. If the linked subprogram uses 24-bit addressing, and the COMMAREA is above the 16MB line, CICS copies it to below the 16MB line, and recopies it on return.

The CALL statement may pass DFHEIBLK and DFHCOMMAREA as the first two parameters, if the called program is to issue EXEC CICS requests, or the called program can issue EXEC CICS ADDRESS commands. The COMMAREA is optional but if other parameters are passed, a dummy COMMAREA must also be passed.

When using third party programs, you must be aware of their API interface. Normally there is no problem on big endian systems, which represent binary data as the mainframe does, while there may be incompatibilities with little endian systems, which manage binary data using a inverted notation.

On little endian systems, the third party product API may require the usage of native data types (COMP-5), while XCICS/TS APIs, by default, require big endian binaries (COMP). The tipical scenario is the usage of Oracle precompiler with Linux or Windows on Intel CPUs: the oracle precompiler needs COMP-5 binaries, while XCICS/TS needs COMP fields.

A program coming from the mainframe normally provides COMP field to the middleware APIs (CICS, SQL, MQ, etc.). Therefore, in order to execute correctly the program in the above scenario , you have two options:

•	manually change the program, converting the COMP fields into COMP-5 one, where required

•	force the compiler to use COMP-5 in place of any COMP field, and instruct XCICS/TS to use COMP-5 field in its API

In this sample, with Microfocus COBOL on Linux, we set the compiler options in xcob.conf