TSO/E does not support user IDs with more than 7 characters. The reason
for this is a historical one. TSO/E user ID information was originally
stored in the user attributes data set, UADS. A PDS, UADS has an
8-character limit on member name length. To save space (remember that
2314s and core storage were prevalent when all this was designed), user
ID attributes were split into multiple members, up to 10, when all the
attributes for one user ID would not fit into one block at the block
size used to allocate UADS. If you needed more attributes than could be
contained in 10 members for one or more user IDs, you needed to increase
the block size for UADS. There's probably still the treatise about how
to optimize UADS block size in one of the TSO/E books, but unless you're
interested in "how things used to be" it's not worth the time it takes
to read it today.
"Knowing" that ID length was limited to 7 characters and always would
be, the TSO/E developers saved on memory requirements by finding myriad
strange and wonderful uses for that eighth character in many data
fields. It seems that a number of other IBM and non-IBM people likewise
rely on a 7-character maximum today.
We do understand that 8-character IDs would be useful. SHARE has helped
us understand it more clearly over the past year or so. No promises, of
course...but if you are patient and watch this space things might change
eventually. Not soon, mind you, and quite possibly never (no promises,
remember), but eventually.
Peter Hunkeler wrote:
Initially posted on RACF-L (more by mistake tang by intention). Reposting here
with emphasis on the TSO mechanisms I'd like to get some deeper insight.
We're in the process of cleaning up our technical userids. There is a job
running a REXX under IKJEFT01 that is issuing MVS commands via TSO CONSOLE. The
job is run under a new 8-character technical userid. The job fails with the
following messages in //SYSTSPRT:
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
IKJ55353I THE CONSPROF COMMAND HAS TERMINATED.+
IKJ55353I USER DOES NOT HAVE CONSOLE COMMAND AUTHORITY.
IKJ55305I THE CONSOLE COMMAND HAS TERMINATED.+
The new userid did have neither a TSO nor a OPERPARM segment. It does have READ
to OPERCMDS/MVS.MCSOPER.** and TSOAUTH/CONSOLE profiles.
I tried adding a TSO segment first, then an OPERPARM segment. Neither helped.
From what I have read in the FM and in the archives of this forum, I tend to conclude
that there is no way to authorize an 8 character userid to use the TSO CONSOLE command,
is there? To use "CONSOLE", the job needs access to TSOAUTH/CONSOLE, but this
requires the userid has got a TSO segment. While 8 character userid may have a TSO
segment in RACF, it is useless, since TSO does not even care to look for userids longer
than 7 chars. This it what msgIKJ56644I indicates. Is this correct understanding?
It definitely *is* possible to run TSO and ISPF in batch under an 8 char userid. Apart from
"try & error", How would I find which commands do *not* work in such an
environment?
Why not just change to using a 7 char userid? Well, while this would be the
easy path, our organisational structures make it a stony path. But, as said
above, my main goal is to get a deeper understanding of how TSO works.
Additional Q: Does anyone know where the "default attributes" mentioned in
msgIKJ56644I are documented?
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
