Edward E. Jaffe wrote:
Joel C. Ewing wrote:
The concept of Name/Token pairs is aesthetically pleasing and
obviously less likely to get you into trouble, but has anyone done any
serious study on the cost of using this service?
I will confess that we have used and continue to use TCBUSER field as
an anchor for some persistent installation data that is potentially
accessed a VERY LARGE number of times per day. The cost of only a few
load fullword instructions to chase pointers to locate data through a
TCBUSER field has got to be impossible to beat from an efficiency
standpoint, but just what kind of performance can one expect from
Name/Token lookup? It would be nice some day to get rid of the
TCBUSER field dependencies, but if that were to impact transaction
times adversely or force an earlier hardware upgrade it would be
awfully hard to justify replacing something that is working effectively.
This particular poster is running unauthorized code. What is the cost to
setup and invoke an authorized service to update TCBUSER? How much of an
exposure might be created in doing so?
Negligible overhead in the contexts we use it. The only authorized code
is in an installation SVC which allocates several types of additional
"installation" storage and sets TCBUSER as a pointer once during life of
a task (a functional request that requires this storage invokes the SVC
only if the storage doesn't already exist). In one context, the
allocated storage is key 8 and subsequently used as a common work area
100,000's of times without further need to use the creating SVC. In
another context, the storage is protected read-only storage that is also
initialized by the SVC, and after creation read many times (controlling
which ISPF panel options will be displayed to a specific ISPF user).
So, although TCBUSER is accessed frequently, the setting of TCBUSER is a
relatively rare event.
We take a similar approach in using CVTUSER. Installation storage in
protected storage is created, initialized, and pointed to using
authorized code that is invoked as part of our automated IPL process.
Although modification after creation is also supported, this is very
rare. Normally all references to CVTUSER and its associated storage
after the IPL process are READ accesses by non-authorized code.
TCBUSER is intended for *installation* use. Not IBM use. Not ISV use.
Not "shareware" product use. Not "freeware" product use. Speaking from
an ISV standpoint, we have no choice but to use Name/Token or roll our
own alternative. (In the old days, we used to use ENQ SCOPE=STEP to save
a TCB-level "token" and GQSCAN to retrieve it.)
If your (already) authorized code is using TCBUSER for its intended
purpose (for example to save data for use by installation exits or
system modifications), then don't worry. There's no reason to change a
thing. That's what it's for!
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
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
