+

Search Tips   |   Advanced Search

COBOL container overview

The COBOL container enables COBOL modules to be loaded into the batch address space, and they are invoked directly.

The container can be created and destroyed multiple times within the lifecycle of an application server. Each container is created with a Language Environment (LE) enclave separate from the server. The container is assured of a clean LE each time it is created.

Java programs can pass parameters into COBOL and retrieve the results. The COBOL call stub generator tool. is provided to create the Java call stubs and data bindings based on the data and linkage definitions in the COBOL source. Additionally, JDBC Type 2 connections created by the Java program can be shared with the COBOL program under the same transactional context.


Value of the COBOL container

The product provides a comprehensive execution environment for Java batch processing. Part of the design of batch support is the integration with other information processing. COBOL has been a part of batch processing since the very early days of computers, and there is significant investment in COBOL assets. The COBOL container provides a means of direct integration of COBOL into Java processing.


Programming restrictions for COBOL programs

COBOL programs that run in the product environment have the following programming restrictions:


COBOL compilation requirements

We must compile all COBOL modules that you use in the environment with the following options:

dll

COBOL modules must be in DLL format.

rent

COBOL modules must contain reentrant code.

thread

COBOL modules must be thread safe.

outdd(WCGILOUT)

Required for COBOL DISPLAY output to appear in product job logs.

SQL('ATTACH(RRSAF)')

Required for DB2 access.

We can specify these options in the COBOL source:

We can also specify these options as inputs to the COBOL compiler. For example, enter the following on the cob2 command line:


Restrictions for the COBOL container

The product hosting the COBOL container must be configured with a workload profile of ISOLATE.

For information about how to configure the workload profile, read about ORB services advanced settings on the z/OS platform.


JDBC data source restrictions for the COBOL container

The restrictions listed in this section apply to any JDBC data source containing DB2 type-2 connections that are shared between the Java and COBOL code through ILContainer.setDB2Connection. [Also, specify the object type for ILContainer.setDB2Connection.]

These restrictions ensure that any DB2 data constructs that are opened by the COBOL code and that persist across COMMIT boundaries, such as WITH HOLD CURSORs, are properly cleaned up when the JDBC connection is closed.

Connection pooling must be DISABLED. We can disable connection pooling using the disableWASConnectionPooling property. To set this property using the console, click Resources > JDBC > Data sources > data_source_name > Custom properties > New. Add a custom property named disableWASConnectionPooling and set the value to true.

Connection sharing must be set to UNSHARED. Connection sharing for the data source can be set to UNSHARED using the globalConnectionTypeOverride property. To set this property using the console, click Resources > JDBC > Data sources > data_source_name > Connection pool properties > Connection pool custom properties > New. Add a custom property named globalConnectionTypeOverride and set the value to unshared.

For more information about these properties, read about Tuning connection pools.


Related tasks

  • Tune connection pools
  • Develop COBOL container batch applications
  • Create a COBOL call stub Java class
  • Compiling COBOL call stub Java classes
  • Dynamically updating a COBOL module
  • Generating COBOL call stubs

  • COBOL call stub Java class usage example
  • COBOL RETURNING, RETURN-CODE, getReturnValue, and getReturnCode parameters
  • COBOL container for batch troubleshooting