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.
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
RENTorNORENT. - Review
DATA,RMODE,HEAP,STACK, andALL31settings 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.