On 5 Nov 2010 07:18:14 -0700, in bit.listserv.ibm-main you wrote: >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.
But then you come up against the 8 character limitation on jobnames that is pervasive in SMF, the various JES control blocks and a whole lot of other control block. The TSO User id becomes the job name in some cases (such as in the TSO logon if I recall correctly). Step names and proc names also have the inhibition. Clark Morris > >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 ---------------------------------------------------------------------- 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
