On 5/23/2014 5:04 AM, Peter Relson wrote:
Otherwise, execution key must be changed at entry to
the program and every GETMAIN/STORAGE OBTAIN must be coded
to explicitly specify subpool/key.
Subpool, yes. Key only if not using a subpool that supports caller-key.
For the record, I consider CALLRKY=YES to be a form of specifying the
key, especially since CALLRKY=NO is the default (for STORAGE OBTAIN).
But I'd also point out that every authorized program should almost always
specify subpool and not let it default to 0.
It is usually bad form for authorized code to get code in the "user
region" (and unnecessarily risky even in your own space, since it may risk
not being able to get storage because the region has been exhausted, when
there is still private storage available in authorized subpools.
Good point. We almost always use subpool 230 unless some "special"
attribute is needed.
Of course I agree that it is much easier when the TCB key matches the
execution key. This can be done for subtasks which is why ATTACH supports
attaching a task but not making it dispatchable initially (DISP=NO),
giving the attacher the opportunity to change the key before it is
(approximately) "too late" and then indicate ATTACH DISP=RESET. But the
PPT is the only mechanism for the jobstep program task.
Never knew specifically where DISP=NO came from. Thanks for sharing.
We've leveraged that very useful feature for many different purposes,
for example to have the attaching task construct a name/token, usable by
code running in the subtask, whose name contains the four-byte subtask
TCB address.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
