Showing posts with label RENT. Show all posts
Showing posts with label RENT. 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.

COBOL RENT Compiler Option: Reentrant Programs on z/OS

A COBOL module used by CICS, IMS preload, or a Db2 stored procedure cannot be treated like a simple one-user batch program. The RENT compiler option tells Enterprise COBOL to generate a reentrant object program, so the same program code can be shared safely while each run gets its own data.

COBOL RENT compiler option diagram showing reentrant code, Language Environment heap storage, and CICS IMS Db2 use cases
Use RENT for reentrant code.

What is the COBOL RENT compiler option?

RENT generates a reentrant object program. NORENT generates a nonreentrant object program. IBM documents RENT as the default for current Enterprise COBOL releases.

Reentrant code is designed so the executable program instructions are not modified during execution. Working data is kept separate for each run unit, task, or invocation as required by the runtime environment.

RENT vs NORENT

Option Generated program Good fit
RENT Reentrant object program. CICS programs, IMS preload, Db2 stored procedures, z/OS UNIX, DLL-enabled programs, object-oriented COBOL, and shared program storage.
NORENT Nonreentrant object program. Older batch-only programs when site rules allow nonreentrant code and storage/addressing rules are understood.

Why reentrant code matters

If more than one user, task, or address space can run the same program at the same time, the program must not overwrite shared instruction storage. IBM states that programs accessed by more than one user at the same time must be made reentrant by compiling with RENT.

This matters in online regions and shared storage. A nonreentrant program can work in a small test, then fail badly when concurrent use starts touching the same program copy.

Programs that should use RENT

IBM lists several Enterprise COBOL cases where programs must be reentrant. The most common mainframe cases are easy to recognize during a code review.

  • CICS application programs.
  • IMS programs that are preloaded.
  • Db2 stored procedures written in COBOL.
  • Programs running in the z/OS UNIX environment.
  • Programs enabled for DLL support.
  • Programs using object-oriented syntax.

WORKING-STORAGE with RENT

One practical change is where program data lives. IBM performance guidance explains that COBOL WORKING-STORAGE is allocated from Language Environment heap storage when the program is compiled with RENT. LOCAL-STORAGE is allocated from Language Environment stack storage.

You do not normally rewrite every variable just because a program uses RENT. But you should understand the storage model when debugging addressability, below-the-line storage pressure, or migration issues.

DATA and RMODE considerations

RENT interacts with DATA and RMODE. IBM notes that DATA(24|31) controls whether dynamic data areas are obtained from below the 16 MB line or from unrestricted storage. IBM also states that programs compiled with NORENT must be RMODE 24, while RENT allows the program to run above the 16 MB line.

CBL RENT,DATA(31)

IDENTIFICATION DIVISION.
PROGRAM-ID. CUSTUPD.

For modern code, DATA(31) with RENT is common, but always follow the runtime environment and site standards.

Binder and link-edit checks

Compiler options and binder attributes need to agree. IBM recommends link-editing the program object with the RENT binder option when all COBOL programs in the program object were compiled with RENT. If non-COBOL programs are included, the binder setting depends on their rules.

If any program in a program object is not reentrant, do not blindly mark the whole program object as reentrant. Check the compile listings and binder map before moving it into shared runtime use.

RENT and performance

Older guidance often says RENT adds some code to support reentrancy. IBM performance material also notes that, on average, RENT was equivalent to NORENT in its measurements. Treat performance as something to measure in the target workload.

For most modern online and shared environments, correctness and environment requirements decide the option before a small path-length discussion does.

Testing RENT safely

Test RENT changes with the same runtime shape the program uses in production. A single batch run proves basic execution, but it does not prove a CICS program, IMS preload module, or Db2 stored procedure behaves correctly under concurrent use.

For a changed program, keep three pieces of evidence: the compiler listing that shows RENT, the binder output that shows the program object attributes, and a run log from the target environment. That small paper trail saves time when a later deployment asks why the option was changed.

Migration checklist

  • Confirm whether the program runs in batch, CICS, IMS, Db2 stored procedure, z/OS UNIX, or DLL mode.
  • Check the actual compiler listing for RENT or NORENT.
  • Review DATA, RMODE, HEAP, STACK, and ALL31 settings with runtime support.
  • Confirm binder attributes in the link-edit output.
  • Check whether the program object contains only COBOL modules or mixed-language modules.
  • Test concurrent execution paths instead of proving only one single-user run.

Common mistakes

Assuming RENT means thread-safe business logic

RENT generates reentrant object code, but it does not make every external resource safe. Files, DB2 rows, queues, shared tables, and application locks still need correct design.

Ignoring the binder map

A compile listing alone does not prove the final program object is packaged correctly. Check the link-edit output, especially when several modules are bound together.

Using old defaults without checking the current compiler

Current Enterprise COBOL documentation lists RENT as the default. Do not rely on memory from an older compiler release; check the listing for the real option.

Related Mainframe Forum guides

For nearby topics, read COBOL DYNAM compiler option, COBOL THREAD compiler option, Working Storage vs Local Storage, COBOL CALL statement examples, COBOL Db2 compilation process, and COBOL performance tuning tips.

External references

IBM documents the RENT compiler option, making programs reentrant, and program residence and storage considerations.

FAQ

What does RENT mean in COBOL?

RENT tells Enterprise COBOL to generate a reentrant object program.

What is the default for RENT?

IBM documents RENT as the default for current Enterprise COBOL releases.

Is RENT required for CICS COBOL programs?

Yes. IBM lists CICS programs among the Enterprise COBOL programs that must be reentrant.

Does RENT make a program thread-safe?

No. RENT handles reentrant object code. Application data, files, queues, database rows, and locking still need proper design.

New In-feed ads