Assembler LP usage considerations

Language Processor DD Statements

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

Assembler Samples and Program Names

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

The following program names are used for the Assembler 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 PL/I language AMODE 64 application, see the IBM Language Environment Programming Guide for 64-bit Virtual Addressing Mode and z/OS MVS Programming: Assembler Services Guide.

Other Usage Considerations

This section describes special considerations for using the Assembler language processor. For a list of Assembler language processor restrictions, see Assembler-LP-usage-restrictions.

Processing Listings with Errors

Unpredictable results may occur when you postprocess an assembly listing with serious errors. If you use the preprocessor, however, you can avoid these potential problems. The preprocessor, in conjunction with the CONDDDIO parameter, internally checks the return code from the assembler and does not write out a listing that contains errors. Using the preprocessor prevents unnecessary processing of an error-filled assembly listing by not calling the postprocessor. For information on the CONDDDIO parameter, refer to CONDDDIO (CONDD) Command.

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 card in the preprocessor JCL. Be sure to allocate enough primary space to contain your assembly listing.

Handling Suppressed Statements

The postprocessor will not support listings that contain suppressed statements. The preprocessor must be run if the listing contains suppressed statements. Suppressed statements include statements that are not generated in the assembly listing due to a PRINT OFF or a PRINT NOGEN for Assembler. If the postprocessor is run and it encounters any suppressed statements, you will receive the following message, and the postprocessor will stop immediately.

You should run the preprocessor if PRINT OFF or PRINT NOGEN is specified. You can bypass this restriction by using the PROCESSOR($ASUP) parameter. This parameter allows a listing with suppressed statements to be postprocessed. You should specify this parameter when you want 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. For more information on the PROCESSOR($ASUP) parameter, please refer to PROCESSOR (PROC) Command.

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. This data is required for Assembler language to do source member matching of the DDIO file to the executable load module.

If the program was assembled with the GOFF (Generalized Object File Format) option or the XOBJECT option, an additional record is used to store the IDR record located in a single TXT record (structured record data). This additional record contains:

• 1-byte language release (BMC AMI internal code)
• x’00’
• 8-byte CSECT-Name
• 6-byte compile time (hhmmss)
• The rest contains x'00'.

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 timestamp on the object module
• PROC(IDENTNO) — Bypass the placement of an IDENTIFY record on the object module.

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