COBOL usage considerations

Language processor DD statements

The following table lists the DD statements for the COBOL language processor.

COBOL samples and program names

The following is a list of members in the CSS installation library that contain sample JCL for executing the COBOL language processor:

The following program names are used for the COBOL language processor: 

Using the zIIP processor

You can enhance the performance of the language processor by running selected portions of the language processor on a zIIP processor. Running the language processor on a zIIP processor can result in less billable CPU time used and significantly fewer I/O operations.

Enabling the language processor to run on a zIIP processor buffers much of the I/O operations to DASD into memory. This increases the amount of virtual storage used by the language processor. Therefore, if your system has a high paging rate, we recommend that you disable zIIP processing.

zIIP processing is enabled by default. You can use the ZIIP command to disable zIIP processing and control memory allocation. Alternatively, you can disable zIIP processing during language processor run by specifying a //CXZPIGNR DD DUMMY statement in your language processor JCL stream.

Creating an AMODE 64 application

To generate an AMODE 64 (64-bit) application with the related language features enabled, use the LP (64) compiler. For more information about creating a COBOL language AMODE 64 application, see the IBM Language Environment Programming Guide for 64-bit Virtual Addressing Mode and Enterprise COBOL for z/OS Programming Guide.

Other usage considerations

Processing multiple compile units in a single execution

The compiler listing output that results from batched compilation can be fed into the postprocessor as any other COBOL listing. All of the normal requirements for using the postprocessor apply: the specification of the required compiler options during the actual compilation and the use of the standard COBOL postprocessor DD statements. As such, no special requirements or changes are needed in order to handle a batch compile listing.

When processing multiple source code units with the preprocessor, which invokes the compiler during its processing, there are some special considerations. Normally, the preprocessor determines the necessary compiler options required and sets them prior to invoking the compiler. When processing multiple source code units, the required compile options are not automatically determined and must be specified either on the EXEC PARM field for the step invoking the COBOL preprocessor program or in the LANGPARM command in the LP parameter input data set. For a list of the required compiler options, see COBOL-compiler-options.

Also, you must specify $NO on the PROCESSOR command when processing multiple source code units.

To summarize the requirements necessary to use batched source programs with the COBOL preprocessor, specify the following in your CWPPRMO input options or in your EXEC PARM field:

The following are restrictions for processing multiple compile units in a single step (preprocessor or postprocessor):

• Exercise caution in specifying options in a CBL or PROCESS statement that change the characteristics of the source code or the listing format. For example, specifying PROCESS APOST on one source program and having the next source program specify PROCESS QUOTE changes the characteristics of the way the source is analyzed. As another example, specifying PROCESS LIST for one source program and PROCESS NOLIST,OFFSET for the next source program changes the format of the listing output. Other combinations exist besides these scenarios; uses of options in this manner are not supported.
• For the preprocessor, CBL and PROCESS statements are permitted within the source to control individual compiler options used for each separate compilation of the source program. However, the options specified on any such CBL or PROCESS statements must not nullify the specification of any required compiler options.
• Output from the COBOL Language Processor in the form of an Enhanced or CobolAID listing that was also batched together cannot be re-input into the processor for reprocessing. Only single Enhanced listings are supported for reprocessing.

Using alternative reserved word tables

The alternative reserved word feature of the COBOL language processor lets you create synonyms for compiler reserved words, package them into a load module table for later use, and instruct the compiler to allow COBOL programs to use these synonyms. For example, you could set CALCULATE to be a synonym for COMPUTE. The compiler will then recognize CALCULATE and treat it in every instance as if it were a COMPUTE word.

The WORD option is not supported when $NO or $NG is specified. Since $NO bypasses the dummy compile and flexible options processing, CSS is unable to detect the presence of the WORD option.

To invoke the WORD option for the CSS COBOL preprocessor, use one of the following methods:

 The WORD command can only be used in the CSS preprocessor.

• Add WORD(tabl) to the list of parameters (PARM=) included on the EXEC statement that executes CWPCMAIN.
• Include LANGP(WORD(tabl)) on a separate line in the data set specified by the CWPPRMO DD statement.

The tabl variable should be replaced with the name (up to 4 characters) of the alternative reserved word table that has been created or NOOO if the IBM alternate table is desired.

Processing listings with errors

Unpredictable results may occur if you postprocess a compiler listing with serious errors. If you use the preprocessor, you can avoid these potential problems. The preprocessor, in conjunction with the CONDDDIO command, internally checks the return code from the compiler and doesn’t write out a DDIO listing that contains errors. Using the preprocessor prevents unnecessary processing of an error-filled compiler listing by not calling the postprocessor. For more information on the CONDDDIO command, see CONDDDIO (CONDD).

Language processing output considerations

  If you route your SYSPRINT, CWPPRTL, or CWPPRTO output to a PDS or sequential data set, please consider the following DCB restriction.

• The preprocessor will force the SYSPRINT file to be LRECL=133 and RECFM=FBA.
• The preprocessor will force CWPPRTL file to be a LRECL=133 and RECFM=FBA
• The postprocessor will force the CWPPRTO file to be LRECL=133 and RECFM=FBA.

When using the CWPPRTL DD statement, you must route your output to a PDS/PDSe or sequential data set and specify option ZIIP(NO) in your Language Processor Command section.

SYSPRINT can be routed to a PDS or sequential data set, with following restrictions that the preprocessor will force the SYSPRINT file to be LRECL=133 and RECFM=FBA. Therefore, you'll have your listing with errors in a data set, but losing the Workbench for Eclipse feature as stated above.   If you want your compile listing saved to a PDS during the compile STEP job execution and not lose the Workbench for Eclipse feature to “Show Compile Diagnostics”, you can specify a CWPPRTL DD statement in your JCL compile STEP.

Prevent truncated messages

Compiler messages are always truncated to 110 characters within the listing. To prevent this truncation and obtain the complete message, use the PROCESSOR($NO) preprocessor option. for more information on this option, see PROCESSOR (PROC).

Handling suppressed statements

The postprocessor will not support listings that contain suppressed statements. If the listing contains suppressed statements, you must run the preprocessor. Suppressed statements include statements that are not generated in the compiler listing due to a COPY SUPPRESS for COBOL. If the postprocessor is run and it encounters any suppressed statements, you will receive the following message and the postprocessor will stop immediately.

You can bypass this restriction by using the PROCESSOR($ASUP) parameter. This parameter allows a listing with suppressed statements to be postprocessed. Specify this parameter to postprocess listings with suppressed statements that have been stored in machine-readable format. $ASUP should be used with caution since there may be problems postprocessing a listing containing suppressed statements and using this listing with your BMC AMI products.

Effect of optimization logic on execution pointer

While the language processor supports the use of optimized code, occasionally the code execution pointer could follow a different path than expected due to the optimization logic. The effect of optimization on the COUNTS command may show unexpected results. This consideration only applies to BMC AMI DevX Code Debug for TSO and BMC AMI DevX Code Debug for CICS users.

Insufficient primary space allocation

During preprocessing, you may receive a B37 abend on the CWPPRTI DD statement. This is due to insufficient space on the temporary volume used by MVS for the dynamically allocated data set. To correct this problem, first try resubmitting the job. If the problem persists, you can include your own CWPPRTI DD statement in the preprocessor JCL. Be sure to allocate enough primary space to contain your compile listing. DCB= (RECFM=FBA, LRECL=133, BLKSIZE=16093)

Support to Workbench for Eclipse

The COBOL and PL/I language processors have been enhanced to provide additional support to the BMC AMI DevX Workbench for Eclipse. Workbench users can take advantage of this support which allows them to display error messages resulting from a compilation in an easy to use Problems View. Using the window controls, users can position directly to the original source line within their program or in a copy member that is identified by the error message. Users can also position directly to the line within the compiler listing containing the error to view the surrounding statements.

The language processors automatically generate the information for the Workbench during their execution. This additional information is written out to an output DD statement named CWPWBNV. In order to take advantage of this support, the job output from the compilation should remain in the JES output queues so that the Workbench can obtain the information from the CWPWBNV DD statement output. The job output can be purged at any time as necessary, but the Workbench can obtain the information only from jobs whose output is in the JES output queues.

If the CWPWBNV DD output is not desired or if your installation is not using the Workbench, the feature can be disabled two ways:

• To stop an individual language processor job from producing the CWPWBNV DD output, specify the PROCESSOR($NOWB) preprocessor option.

• To stop all language processor jobs from producing the CWPWBNV DD output, use the Customer Modification Facility (CMF) parameter WBNV to alter the default behavior. Set the parameter to N to stop producing CWPWBNV output. For example, using the CXCFGINI sample member of the SLCXCNTL data set as a guide, the parameter would be coded as shown here:

  *    KEYWORD    VALUE
  
            WBNV            N

 For more information about how to specify CMF parameters to change Shared Services behaviors, see Using-the-Customer-Modification-facility.

Updating the OBJECT Deck

The BMC AMI language preprocessor and postprocessor, when correctly coded as described in Language Processor DD Statements, will update the OBJECT deck by placing an IDR record in the END card containing the program name, the compile date/timestamp and a 1-byte code to indicate the release of the compiler.

The END card, which is linked into the load module, has historically been used by all products utilizing source support to find this data in one single location. The data is used for DDIO source matching to the executable load module. The END card is used by all supported languages. If this data is not present in the END card, the product will need to search the IBM Signature area for this information.

Additionally, the language processors will insert an IDENTIFY record into the OBJECT deck. The IDENTIFY record is used to contain the program name and the name of the DDIO file the program was written to in an encrypted format. This information can be utilized by CSS to dynamically allocate the file when debugging a program in Code Debug, merging source into a report for BMC AMI DevX Abend-AID, or incorporating source into a Strobe profile. The benefit is to provide the ability to locate matching source when the DDIO file where the member resides has not been defined to the product that requires source support. As long as the DDIO files are defined to the products that use them, the IDENTIFY record is not needed.

To disable the updating of the OBJECT deck, pass the following parameters via the CWPPRMO DD statement in the language processor step:

• PROC($NIDR) — Bypass the placement of the date and time stamp on the object module
• PROC(IDENTNO) — Bypass the placement of an IDENTIFY record on the object module

For more information on these override parameter, see  IDENTYES or IDENTNO for more details on these override parameters.

Output parameter considerations

The OUTPUT parameter is the most commonly used COBOL language processor parameter. The OUTPUT parameter controls which type of listing (compiler or enhanced) is written to a DDIO file. This section discusses the DDIO and PRINT values for the parameter.

OUTPUT - DDIO value

Use the DDIO value in the COBOL(OUTPUT) parameter or PROCESSOR(OUTPUT) parameter to specify which type of listing to write to the DDIO file. Only one type of listing can be written to a source listing file. The language processor uses the last-supplied parameter.

• If COBOL(OUTPUT(DDIO)) is specified, then the compiler listing is written to the DDIO file.
• If PROC(OUTPUT(DDIO)) is specified, then the enhanced listing is written to the DDIO file.

OUTPUT - PRINT value

Use the PRINT value in the COBOL(OUTPUT) parameter or PROCESSOR(OUTPUT) parameter to specify which type of listing to print. One or both of these listings can be printed.

• If COBOL(OUTPUT(PRINT)) is specified, then the compiler listing is printed.
• If PROC(OUTPUT(PRINT)) is specified, then the enhanced listing is printed.

Performance considerations

When using the COBOL command instead of the PROCESSOR command, the COBOL language processor uses less CPU time and performs fewer input/output operations.

Using the DDIO command to suppress the writing of certain sections of the compiler listing to a source listing file accomplishes the following:

• Performance is improved because the number of CPU cycles and input/output operations is reduced.
• Less space is used in the source listing file.