Showing posts with label HEAP. Show all posts
Showing posts with label HEAP. Show all posts

Sunday, 11 August 2013

COBOL DATA Compiler Option: DATA(24), DATA(31), and 16 MB Storage

A COBOL batch program can run out of below-the-line storage long before the machine is short of memory. The DATA compiler option helps decide where some run-time data areas can be allocated: below the 16 MB line with DATA(24), or above it with DATA(31).
COBOL DATA compiler option showing DATA 24 and DATA 31 storage placement
DATA(31) is the normal choice for modern programs.

This article explains the DATA compiler option in simple terms for mainframe COBOL developers. It covers what DATA(24) and DATA(31) mean, when each setting is used, and what to check before changing an old compile option.

What the COBOL DATA Compiler Option Controls

The DATA option affects where storage is obtained for dynamic data areas in Enterprise COBOL for z/OS. IBM documents DATA(31) as the default. For reentrant programs, DATA works with the Language Environment HEAP run-time option to decide whether dynamic areas such as non-external WORKING-STORAGE and FD record areas can be placed above the 16 MB line.

The important point is addressability. A program using 31-bit addressing can address storage above the 16 MB line. An old AMODE 24 program cannot. That is why DATA(24) still appears in some old compile procedures.

DATA(31) in COBOL

DATA(31) allows eligible dynamic run-time storage to be allocated above the 16 MB line. IBM recommends DATA(31) when the program does not need to call and pass parameters to AMODE 24 subprograms. In practice, this is the normal setting for most current Enterprise COBOL applications.

Why DATA(31) Helps

Below-the-line storage is limited. If QSAM buffers, working areas, and record areas all compete for that space, a busy batch job can hit storage pressure. With DATA(31), a reentrant program can keep more eligible storage above the line, especially when the run uses HEAP(,,ANYWHERE).

//COBOL.SYSIN DD *
PROCESS RENT,DATA(31)
IDENTIFICATION DIVISION.
PROGRAM-ID. ACCTLOAD.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-ACCOUNT-AREA PIC X(4096).
/*

This does not automatically make a slow program fast. The main benefit is storage placement. It can reduce pressure below the 16 MB line when the program and run-time options are set up correctly.

DATA(24) in COBOL

DATA(24) places eligible dynamic areas below the 16 MB line. You normally use it when the COBOL program must pass data to a 24-bit subprogram that cannot address data above the line.

Typical DATA(24) Scenario

Suppose a new COBOL program calls an old assembler routine that is linked AMODE 24. If the COBOL program passes the address of a work area above the 16 MB line, the old routine may not be able to address it. In that case, the compile and link-edit settings need a careful compatibility review before the program is promoted.

       CALL "OLDASM24" USING WS-CONTROL-BLOCK.

If OLDASM24 can only use 24-bit addresses, the storage passed in WS-CONTROL-BLOCK must be reachable by that routine. That is the kind of case where DATA(24) can still be required.

DATA(24) vs DATA(31)

Setting What it means When to use it
DATA(31) Eligible dynamic storage can be obtained above the 16 MB line. Use for most modern Enterprise COBOL programs unless an AMODE 24 dependency requires below-the-line data.
DATA(24) Eligible dynamic storage is kept below the 16 MB line. Use when the program passes data to AMODE 24 code that cannot address above-the-line storage.

What DATA Does Not Control

DATA is easy to misunderstand because the name sounds broad. It does not control every COBOL data item in every situation. IBM notes that LOCAL-STORAGE is not affected by the DATA compiler option; the stack run-time option and program addressing mode matter there instead.

External data also has related addressability rules. If a program uses EXTERNAL items, old called modules, or mixed-language calls, review the compile options, link-edit attributes, and Language Environment run-time options together.

How DATA Works with RENT and HEAP

The DATA option is often discussed with RENT because reentrant programs can have different storage behavior from non-reentrant programs. IBM notes that for non-reentrant programs, the RMODE option determines where non-external data is allocated.

For a reentrant program, this combination is common in modern compile procedures:

PROCESS RENT,DATA(31)

At run time, HEAP(,,ANYWHERE) can allow non-external WORKING-STORAGE and non-external FD record areas to be allocated above the 16 MB line. This is useful for batch programs with many files, large record areas, or sizable work areas.

How to Check the DATA Option in a Compile Listing

The fastest way to confirm the active setting is to check the compiler listing. Enterprise COBOL listings show the compiler options used for the compile. Site defaults can also affect the final option set, so do not rely only on what appears in the source member.

PROCESS RENT,DATA(31),MAP,XREF

If the source does not specify DATA, check the compile JCL, cataloged procedure, compiler option file, and installation defaults. Many shops keep options in a compile PROC rather than in each COBOL source member.

Migration Checks Before Changing DATA

Changing DATA(24) to DATA(31) is usually a good cleanup target, but it should not be done blindly. Check the called modules first. The risky case is not a normal COBOL-to-COBOL call in a current environment; the risky case is old code that still expects below-the-line addresses.

Before Changing DATA(24) to DATA(31)

  • Check whether the program calls assembler, old COBOL, PL/I, C, or vendor modules.
  • Check the AMODE and RMODE of the load modules involved in the run unit.
  • Review parameters passed through CALL ... USING.
  • Run a compile listing with MAP if you need storage layout detail.
  • Test the largest realistic input, not only a tiny unit-test file.

Common Mistakes

Using DATA(24) Forever Because It Was Already There

Old compile options often survive because nobody wants to touch them. If the program has no AMODE 24 dependency, DATA(31) is usually the better setting because it can reduce pressure below the line.

Expecting DATA(31) to Fix CPU Time

DATA(31) is about storage addressability, not SQL access paths or loop design. For CPU and elapsed-time issues, check the related Mainframe Forum notes on COBOL performance tuning and COBOL performance.

Ignoring LOCAL-STORAGE

If the issue involves LOCAL-STORAGE, the DATA option may not be the setting you need to review. Read the related guide on COBOL Working Storage vs Local Storage.

Related COBOL Compiler Options

The DATA option is only one part of a compile standard. When tuning or modernizing COBOL compile procedures, also review COBOL RENT compiler option, COBOL TRUNC compiler option, COBOL NUMPROC compiler option, and COBOL program compilation process.

FAQ

What is the default DATA option in Enterprise COBOL?

IBM documents DATA(31) as the default for Enterprise COBOL. Site installation defaults can still matter, so check the compile listing for the option actually used.

When should I use DATA(24)?

Use DATA(24) when a program running in 31-bit mode must pass data to AMODE 24 code that cannot address storage above the 16 MB line.

Does DATA affect LOCAL-STORAGE?

No. IBM documents that LOCAL-STORAGE is not affected by the DATA compiler option. Stack settings and program addressing mode control that area.

Does DATA(31) improve COBOL performance?

Not directly. It can reduce below-the-line storage pressure, but it is not a CPU tuning switch. Treat it as a storage addressability option.

References

For exact syntax and current compiler behavior, use IBM documentation for the DATA compiler option, DATA(24) and DATA(31), and Enterprise COBOL compiler options.

Use DATA(31) by default for current programs, and keep DATA(24) only when a real below-the-line dependency proves it is needed.

New In-feed ads