Prerequisites to use ESS
This topic describes the changes required to use ESS.
JCL changes
Setting up ESS does not cause any JCL changes to the current CSS usage. To set up ESS, you can use one of the following methods:
- Simple JCL changes for specific jobs
- Change to a shared JCL Procedure (PROC) for a group of personnel desires ESS usage.
- Code the option as ESS(YES).
CLASSDDIO_FLENGTH =5C29ATTRIBUTES=CAT,NOLOAD
-------------
SECTIONCLASS --------SOURCE--------
OFFSETOFFSETNAMETYPELENGTHDDNAMESEQMEMBER
0UTFCLASCSECT5C29SYSLIN01**NULL**
CLASSDDIO_FLENGTH =5C29ATTRIBUTES=CAT,NOLOAD
-------------
SECTIONCLASS --------SOURCE--------
OFFSETOFFSETNAMETYPELENGTHDDNAMESEQMEMBER
0UTFCLASCSECT5C29SYSLIN01**NULL**
PARMLIB changes
You can use the ESS parameter to enable ESS globally without making any JCL changes.
You can set up CSS PARMLIB members during Common Mainframe Services Controller (CMSC) configuration. Because this is a PARMLIB setup task, the appropriate ECC site administrator must run the setup instructions as described in Configuring-CMSC-for-a-new-install.
ESS program object DASD size changes
Because CSS stores the COBOL listing in the COBOL-produced program object, the program object size increases overtime. This increase should be almost exactly the same size as if the listing was written to a DDIO file, database, or shared directory entry.
BMC focused the architecture of the ESS implementation on many requirements, but the most important was to design an access method for the program object that would minimize DASD usage. Measuring the DASD usage and comparison to the current DDIO method were paramount requirements. The engineering team has successfully implemented ESS to write the same number of records byte by byte as is written to a DDIO file, database, or shared directory. Hence, we know the exact size increase, a well-known and familiar number.
ESS z/OS Binder sections
You can view the exact size of the ESS records written to a program object from the SYSPRINT output from the z/OS Binder run that creates the program object.
Specifying PARM='LIST,XREF,MAP' is necessary when you run the z/OS Binder to view the needed lines of SYSPRINT output. MAP gives you a module-by-module breakdown, and the CLASS named DDIO_F, written with the NOLOAD attribute comprises the ESS listings.
Example of z/OS Binder output showing DDIOF CLASS with NOLOAD Attribute
CLASSDDIO_FLENGTH =5C29ATTRIBUTES=CAT,NOLOAD
-------------
SECTIONCLASS --------SOURCE--------
OFFSETOFFSETNAMETYPELENGTHDDNAMESEQMEMBER
0UTFCLASCSECT5C29SYSLIN01**NULL**
COBOL DDIO OUTPUT compression
The COBOL Language Processor DDIO OUTPUT command features a NOCOMPRESS/COMPRESS subcommand. You can use this subcommand to significantly reduce the size of a COBOL listing in the DDIO file.
Syntactically, DDIO(OUTPUT(COMPRESS)) compresses the COBOL listing.
Laboratory tests have achieved 40% or higher compression on very large COBOL listings with more than a million lines of SYSPRINT output. Your output and results might vary, but the benefit might be substantial for your environment with these numbers
ESS compression
ESS listings are virtually identical to DDIO listings and compression results should be identical to it.
To enable compression, use the existing compression command for DDIO files by using the DDIO command, as shown in the following example and as recommended in Compile and Assembly JCL Examples.
Selective size reduction
DDIO and ESS listings are logically divided into two partitions, and each of which contains a pre-formatted analytical data, which is extracted from the compiler listing and other auxiliary files. such as INCLUDES and COPY SECTIONS.
- The pre-formatted analytical data is used by all the companion products, such as Abend-AID or Code Debug to implement product functions. You cannot adjust its size.
- The compiler listing of CSS Utilities and Abend-AID Viewer is used to print, view or modify the listing. You can reduce the size of the compiler that is saved in both DDIO and ESS listing files by using the DDIO(OUTPUT) options.
Most of these options correspond to the physical part of the compiler listing.
For example, if the COBOL XREF is available in the COBOL listing and you also use the DDIO(OUTPUT(NOXREF)) statement while creating the DDIO or ESS Listing, then the XREF section will not be available when you apply the VIEW command (by using Workbench) or the PRINT command (by using the Language processor utility program CWDDALLU).
To exemplify the savings, we ran laboratory tests with the following DDIO(OUPUT) options (including COMPRESS), running an actual, large, about 500 KB–line COBOL program.
Scenario | DDIO(OUTPUT) options | Listing Size (in bytes) | Description |
|---|---|---|---|
1 | FIND,COMPRESS,XREF,PMAP,DMAP,LIST,CLIST,OFFSET | 127,976,251 | Contains all compiler listing sections. You can use this option if you need to modify the compiler listing of any function of your product and CSS Utilities. |
2 | FIND,COMPRESS,NOXREF,NOPMAP,NODMAP,NOLIST,NOCLIST,NOOFFSET | 70,909,989 | Required for the BMC AMI DevX Code Debug for TSO enhanced FIND feature when the compiler listing is not required. If necessary, you can generate the compiler listing by alternate methods. |
3 | NOFIND,COMPRESS,NOXREF,NOPMAP,NODMAP,NOLIST,NOCLIST,NOOFFSET | 59,212,206 | Recommended if you are not using BMC AMI DevX Code Debug for TSO and the compiler listing is not required. If necessary, you can generate the compiler listing by alternate methods. |
These options represent the maximum output with only FIND option, while suppressing all optional sections.
Recommendations:
- The #1 option contains all listing sections. Most of them will likely not be used.
- The #2 option is required for the Code Debug for TSO enhanced find feature.
- The #3 option is recommended if not using Code Debug for TSO enhanced find. Enhanced Find is not available in Workbench.
For more information about syntax and description of each option, see COBOL-LP-Command-Descriptions-and-Syntax.