Impact of TEST suboptions on program object size

As detailed in TEST in the Enterprise COBOL for z/OS® Programming Guide, the TEST and NOTEST options have several suboptions in V6. The SOURCE/NOSOURCE, DWARF/NODWARF and SEPARATE/NOSEPARATE suboptions directly control if extra information used for debugging should or should not be included in the program object, and therefore can change the size of the object significantly.

The TEST option by itself and the suboption EJPD will also affect the program object size, but making it either greater or lesser, as these options may change the amount and types of optimizations performed by the compiler (so the resulting code and literal data areas may be smaller or larger).

Note that although the added debugging information will affect the size of the resulting program object, this will not affect the LOADed size.

Since the debugging information is in NOLOAD class segments, these parts of the program object are not loaded when the program is run, unless Debug Tool or Fault Analyzer or CEEDUMP processing explicitly requests it. So, unlike COBOL V4 and earlier versions, the size of the program object related to debugging information does not affect LOAD times or execution performance.

Since each suboption will impact the object size in a different way, let’s examine each suboption separately. Results will be shown for OPTIMIZE(0) and OPTIMIZE(1) for each case, and all other options are kept at their default settings.

The size comparisons were gathered from a large selection of COBOL tests in our performance verification suite of applications.

First, let’s compare the NOTEST suboption DWARF/NODWARF. The DWARF setting will cause basic DWARF diagnostic information to be included in the object.
Table 1. NOTEST(DWARF) % size increase over NOTEST(NODWARF)
Average Size NOTEST(DWARF) % size increase over NOTEST(NODWARF)
OPTIMIZE(0) 96.1%
OPTIMIZE(1) 105.7%

So at both OPTIMIZE settings measured the overall object size roughly doubles when specifying DWARF overall the default NODWARF setting.

For TEST, let’s first look at the option by itself versus NOTEST. The differences in object size in this case are due to a few reasons:
  • The first major reason for the size increase is that TEST always causes full DWARF debugging information to be included in the object
  • The second major reason for the size increase is that TEST by default enables the SOURCE suboption, so the generated DWARF debug information includes the expanded source code
  • The third reason, and this generally matters less than the previous two reasons, is that TEST slightly inhibits optimization, and this may result in object size increases or decreases depending on the characteristics of the program
    Table 2. TEST % size increase over NOTEST
    Average Size TEST % size increase over NOTEST
    OPTIMIZE(0) 216.7%
    OPTIMIZE(1) 237.8%

Next, let’s look at the impact of the SOURCE/NOSOURCE suboption. This increase is directly related to the size of your expanded source file as it will be included in the DWARF debug information when TEST(SOURCE) is specified.

Despite the object size increase it causes, the advantage of specifying SOURCE is that since the DWARF information will contain the expanded source, a separate compiler listing will not be required by IBM® Debug Tool.

Table 3. TEST(SOURCE) % size increase over TEST(NOSOURCE)
Average Size TEST(SOURCE) % size increase over TEST(NOSOURCE)
OPTIMIZE(0) 27.5%
OPTIMIZE(1) 27.0%

Finally, let’s look at the impact to object size from toggling the TEST suboption EJPD/NOEJPD. This option does not change the amount or type of DWARF debug information included in the object, but only impacts the amount and types of optimizations performed by the compiler in order to meet the debugging requirements of EJPD.

Table 4. TEST(EJPD) % size increase over TEST(NOEJPD)
Average Size TEST(EJPD) % size increase over TEST(NOEJPD)
OPTIMIZE(0) 0%
OPTIMIZE(1) 4.0%

The 0% change at OPTIMIZE(0) makes sense, as this lowest level of optimization is already low enough to be not restricted by the extra debugging requirements of EJPD.

At OPTIMIZE(1), the more restrictive EJPD setting generally inhibits optimizations that would have resulted in smaller, and likely faster performing, executable code.