Thanks John. Now I know why the userids in UADS end in 0. Since I don't have any that end in other than 0, I'll just leave it as is at 80 bytes blocks.
Eric ---- John Eells <ee...@us.ibm.com> wrote: > > When RACF is not used for TSO/E administration, each user has at least > one member in UADS and can have several. This is at least part of the > reason TSO/E user IDs are limited to seven characters rather than eight: > The first UADS member for an ID is named userid0, the second userid1, > and so on, with the eighth character of the member name reserved for the > member sequence number. Each member is one block long. How many TSO/E > attributes a user ID has is what controls whether its data is stored in > multiple members. Those with few attributes likely fit in one member; > those with more than can fit in one block have more than one member. > > ServerPac uses a block size of 80 for UADS simply because the first > entry for IBMUSER has to be copied there during APPLY processing and the > required block size at the time is (as documented) 80. You can change > it thereafter if you wish. > > Basically, if a significant percentage of users have more than one UADS > member, increasing the block size might help reduce the size of the data > set; some experimentation (or measurement and calculation) is required > to find the "best" block size, the one that minimizes the number of > members (and thus the number of blocks). Unless you are running up > against PDS size limits for UADS, though, changing to a different block > size to minimize space has somewhat dubious value these days in my opinion. > > In any event, the TSO/E Customization book has this to say: "Choose a > block size for the data portion that makes the most efficient use of > storage. The block size should be large enough to contain all of the > logon data for most users. To determine if the block size for an > existing UADS is large enough list the data set's members. If several > users have more than one entry, you should increase the block size. Note > that one block is used for each user record." > > I would guess that any IBM performance data on UADS, if it even exists, > is probably pretty old at this point (e.g., based on uncached SLED > DASD). So if you find any, take it with a boulder of salt. > > Hope this helps... > > -- > John Eells > z/OS Technical Marketing > IBM Poughkeepsie > ee...@us.ibm.com -- Eric Bielefeld Systems Programmer Washington University St Louis, Missouri 314-935-3418 ---------------------------------------------------------------------- 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
