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.
Edward E. Jaffe wrote:
Farley, Peter x23353 wrote:
Agreed, Bill. An anchor for persistent data is the application, and
name/token services is the "right" answer. For very small amounts of
data,
though, it just seems like overkill.
Name/token works for both large and small amounts of data. For large
amounts of data, the token is a pointer and maybe some flags. For small
amounts of data, the token itself *is* the data (up to 16 bytes).
--
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
