Rick Fochtman wrote:
----------------------------------<snip>----------------------------
R.S. wrote:
Eric Bielefeld pisze:
I'm almost hesitant to ask this, as this is something that should
have been dealt with over a decade ago, but is there any difference
in having SYS1.UADS as 80 byte records or 172 byte records? Any real
advantages? Peformance issues? I noticed that the system
distributed in ServerPac for 1.9 allocates UADS with an 80 byte
lrecl, and our UADS is still at 80. I remember converting to the 172
byte lrecl probably in the early 90s at P&H Mining. When I briefly
read some of the doc a few weeks ago, I didn't see anything that you
couldn't do with the 80 byte records.
<snip>
IIRC, a single user can only have a single record in the UADS dataset,
so the 172-byte record was desirable from a capacity standpoint.
Remember that UADS described the LOGON procs that were permissible for
that user, as well as PROFILE/privelege data and PASSWORD info.
Converting from UADS control to RACF control eliminates the need for
large UADS records.
When I converted Clearing, there was a very helpful utility that made
the task very easy and painless; I don't know if that still exists or
not. I would not be surprised, or upset, if support for UADS went away
completely in the not-too-distant future.
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
[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
