-----------------------------------<snip>-------------------------------
This is a curiosity question sparked by another thread.
The limitation of 7 characters for TSO IDs has caused us extra work in the
past (we use IDs of 3-8 characters across the institution, but the mainframe
can't use the institutional IDs in part because of this limitation).
True, very true. It's a cultural/environmental fact that IBM should
be sensitive to; it falls in the category of "Plays Well with Others".
IBM should even consider leapfrogging the competition and allowing
more than 8, such as 25 or 50, or even flexible upper limit.
I believe RACF will allow creating an OMVS segment with an 8-character
ID, compatible with prevalent institutional IDs. What would happen if
a user with such an ID submitted a batch job, or issued the Rexx
"address TSO" instruction?
Originally, TSO/E user IDs were kept in the User Attribute Data Set
(UADS), a PDS. User IDs with few attributes fit in a single member.
User IDs with many attributes overflow into multiple members. The
member naming convention is USERIDn, where n is a digit from 0 (the
first member) to 9. You can control when IDs overflow by changing the
block size; smaller block sizes split sooner, and larger ones split later.
TSO/E looks at all the USERIDn members when you log on to retrieve all
your user attributes.
I'm trying to imagine what could have limited the size of each
UADS member? Was each member required to fit in one block?
Surely issuing a single FIND and multiple READS should have
been cheaper than concocting multiple member names and issuing
a FIND for each, then READs.
Was the processing sensitive to block boundaries, with the only
way to control the placement of block boundaries being creation
of artificial member boundaries?
---------------------------------------------<unsnip>---------------------------------------
The original UADS dataset blksize was dictated by the DASD devices of
the time, which sometimes included track sizes of 2000 bytes (2321, for
example). The design of UADS and the code that used it would not allow
multiple blocks per member, because no second block was ever considered
necessary. Later, when the information content increased, the solution
implemented was multiple members, based on the seven-character (or less)
user id, suffixed with a numeric digit. The sequence always started with
zero and went up from there.
Also, some of the TSO control blocks contained the USERID length in the
first character, followed by up to a seven-character userid. Alignment
sensitivies required that this information all fit into a double-word,
so that succeeding fields in the block could be kept aligned and still
minimize the space required. Recall that the S/360, where TSO was
originally designed, was very sensitive to alignment issues and there
was no virtual storage to expand blocks, etc. S0C5 abends were quite
common, whereas they are almost unheard-of today.
Considering how old TSO really is, I'm surprised that it still works as
well as it does today, while still maintaining backward compatability. :-)
Rick
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
