RENT or NORENT
Visda 060001SUB1 Visits (3300)
Is it clear why we have RENT|NORENT compiler option? Do you know that C++ always uses constructed re-enterancy? Can you imagine how applications can benefit most from this?
Recently, I developed a greater appreciation for RENT option, that is after I banged my head against the wall to REALLY understand what RENT is all about in order to fix a related bug.
Reentrancy becomes important when a rather large application have multiple users who may access it concurrently, for example Oracle. Oracle applications developed to run on z/OS will access Oracle interface which is a reentrant code.
Per z/OS Language Environment Programming Guide the following routines must be reentrant.
Furthermore, a large application with many concurrent users will benefit from reentrancy, ie runs faster, because there is less paging to auxilary storage --variables are placed in writeable static area.
This is done for you, if your application is written in C++ or is a DLL. Compile with "-qlist" and you see RENT in the Compiler Option Listing. A C program, however, can be naturally reenterant, that is the user code doesn't change the static storage.
extern int x;
is naturally reentrant because the value of x is not changed by main.
A C program can be made reentrant, constructed reenterancy by specifying
a. -qRENT on the command line (in HFS) or RENT in CPARM (in BATCH)
b. #pragma variable(x,RENT) in the source
There you have it. In a nutshell: reentrancy comes for free with C++ and DLL code, for the rest you have ways to make the code reentrant; if your code is big and is called/used by multiple users at the same time you want to take advantage of this feature because it will improve the run time performance of your application.