On Fri, 5 Nov 2010 08:42:45 -0400, John Eells wrote:

>Robert Birdsall wrote:
>> 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?

-- gil

----------------------------------------------------------------------
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

Reply via email to