Showing posts with label CICS COBOL. Show all posts
Showing posts with label CICS COBOL. Show all posts

Sunday, 11 August 2013

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