OK, I can't help poking this topic with a stick. For all you whipper
snappers who don't remember UADS, it's a tree structure repository with
data organized from top down like this:
1. Userid along with unique attributes like OPER, ACCT, JCL, etc. that are
defined only once per userid.
2. Password, of which there can be as many as desired per userid. (Password
is ignored with RACF installed but still occupies a slot in UADS.)
3. Account number, of which there can be as many as desired per password.
4. Logon proc, of which there can be as many as desired per account number.
This level also includes default region size and unit name.
At the late great Security Pacific Bank, charge-back accounting was
implemented throughout the shop. If a TSO user set about to work on project
123, she would logon with account number xx123xx, which would eventually
record the time against that project. When it came time to work on project
789, she would logon with account number xx789xx to get the time
appropriately recorded. Given the multiplicity of account numbers, UADS
entries got pretty complex. It was not uncommon for application programmers
to end up with several UADS members: -0, -1, etc. I doubt that anyone ever
reached -9, but I remember seeing some pretty hefty entries.
When TSO/E came along, we dutifully increased UADS LRECL to 172 as
recommended, but I guess I never really knew why. I do remember once
experimenting with a larger blocksize that for ordinary files would have
been more DASD-efficient. I was aghast at how big UADS grew because it
still used one block per userid regardless of the number of members per id.
So much for that experiment.
I don't know how many shops still run with UADS, but those you find are
likely to be older larger installations with decades of managing lots of
users who already needed managing long before RACF emerged.. Procedures and
RYO tools were already in place by the time SAF came along. The commands
used to manage RACF-defined users are a lot different from those used for
UADS-only users. At Security, we could never persuade the software security
folks to switch. For one thing, a single display command under ACCOUNT
shows a great deal about what a user can or cannot do. With a TSO/E
segment, a number of commands involving many classes are required to show
the same info. A common business unit request like 'make a new userid
modeled on XYZ001' is a lot simpler with UADS than with RACF, where
attributes and privileges are scattered all over the landscape.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
John Eells
<ee...@us.ibm.com
> To
Sent by: IBM IBM-MAIN@bama.ua.edu
Mainframe cc
Discussion List
<ibm-m...@bama.ua Subject
.edu> Re: SYS1.UADS Format
01/30/2009 10:02
AM
Please respond to
IBM Mainframe
Discussion List
<ibm-m...@bama.ua
.edu>
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
----------------------------------------------------------------------
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
