Tom,
I don't know when RENT changed, but here's how it was born. This passage
was OCR'd from GC28-6535-0 (OS/360 Concepts and Facilities, copyright
1964) Note that the idea of REFR wasn't around at that time. (I think
that REFR was added when some boy genius "proved" that a self-modifying
program could meet a narrow definition of reenterability... or it might
have come with the first protection exception when a possibly bogus
"RENT" program loaded in protected space tried to modify itself.)
Reenterable. Such a program is designed so that it does not in any way
modify itself during execution. It is "read-only." Reenterable load
modules fetched from the system's link library (defined further in
Section 5, "Job Management.") are loaded in storage areas protected with
the same storage key that is used for the supervisor program. Since only
the control program operates with a matching PSW protection key, such
programs are protected against accidental modifica¬tion from any other
user programs. Since a reenterable load module is never modified during
its execution, it can be loaded once, and used freely by any task in the
system at any time. Specifically, it can be used concurrently by two or
more tasks in multi task operations. One task may use it, and before the
module execution is completed, an interruption may give control to a
second task which in turn may reenter the module. This in no way
interferes with the first task resuming its execution of the module at a
later time.
In a multitask environment, simultaneous use of a load module is
considered to be normal operation. Such use is an important factor in
minimizing main storage space requirements and program reloading time.
Many of the control program routines are written in reenterable form, so
that they can be shared between tasks, and reused within a single task.
(The data storage and retrieval routines that are requested during
execution of the OPEN macro-instruction are examples of
supervisor-provided reenterable programs.) A load module of this
category can be executed correctly even though the protection key in the
program status word during task execution is different from the
supervisor storage key. This is possible because the protection key
comparison must be satisfied only when the contents of the addressed
storage area are to be altered. The contents of storage areas containing
reenterable programs are not altered in any way during execution.
If a reenterable load module is not fetched from the link library, but
rather from a private library or the job library, it is made available
only to tasks originating from the same job step.
Design of Reenterable Programs
A reenterable program is designed to use the general purpose and
floating point registers for addressability and variables where
practical, and to use temporary storage areas that "belong" to the task,
and are protected with the task's storage protection key. Temporary or
working storage areas of this sort can be provided to the reenterable
program by the calling program, which uses a linkage parameter as a
pointer to the area. Temporary storage areas can also be obtained
dynamically by the reenterable program itself, using the GETMAIN
macro-instruction. This macro-instruction is a request to the supervisor
to allocate additional main storage to the task, and to point out the
location of the area to the requesting program. Note that the storage
area obtained is assigned to the task, and not to the program that
requested the space. The space may be subsequently returned to the
supervisor's control by a FREEMAIN macro-instruction, or by task completion.
If a reenterable program is interrupted for any reason, the register
contents and program status word (PSW) are saved by the supervisor in an
area associated with the interrupted task, and restored later when
program execution is to continue for that task. No matter what use is
then made of the reenterable module, the interrupted task can resume its
use of the module at a Later time. The supervisor merely keeps the
task's working storage area intact, and when required, restores the
contents of the saved registers and the program status word. The
reenterable load module is not affected, and is unaware of which task is
using it at any instant. Each task will have its own temporary storage
area for use by the reenterable module.
Tom Marchant wrote:
On Wed, 25 Oct 2006 16:03:21 -0400, Arthur T. <[EMAIL PROTECTED]> wrote:
On 25 Oct 2006 11:22:43 -0700, in bit.listserv.ibm-main
(Message-ID:<[EMAIL PROTECTED]>)
[EMAIL PROTECTED] (Tom Marchant) wrote:
And moot, now that they have redefined RENT to say that "A
reenterable module cannot modify its own code." I don't see
that there's a distinction between that and REFR any more.
..
As for the redefinition of RENT ("A reenterable
module cannot modify its own code."):
..
Now that I've posted (twice!) that the definition of RENT has
been changed, I tried to find out when it changed. I found
this on bitsavers:
http://bitsavers.trailing-edge.com/pdf/ibm/370/GC26-3813-
3_vmLinkEdt_May75.pdf
That will probably wrap, so: http://tinyurl.com/yn2tnz
It's a Linkage Editor manual for OS/VS2 release 2 from 1975.
On page 86 is pretty much the same definiton of RENT.
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
