On 11/5/2010 5:42 AM, John Eells wrote:
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.
This architecture (created when memory and storage were still very expensive!)
causes the eighth character in the member name to be reserved and leads to the
7-character user ID restriction that persists today even if you use your
security database for use attributes rather than UADS.
Yup. And this has to go down in history as one of the most astonishing design
decisions ever made on this platform. :-(
UADS is a 'card' image data set (RECFM=FB LRECL=80), so there are only 80 chars
per record. The idea of overflowing information from one member to another
rather than simply onto the next 'card' within the current member seems ludicrous!
The decision truly boggles the mind because any experienced assembler language
programmer knows it's far more complex to manage multiple members using
BLDL/FIND/POINT/STOW etc. than it is simply READ or WRITE multiple 'card' images
to/from a single member.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
[email protected]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
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
