In the beginning there was SYS1.UADS. In there the member name (and you can find this in the archives) could only be a maximum of 7 chars. This is because the last char (position 8 if using 7 chars) was the "chain" to the next entry for that ID. This thread from 2005 may be helpful https://listserv.ua.edu/cgi-bin/wa?A2=IBM-MAIN;8cda2805.0505
The TSO/E Admin guide should also provide some insight. IIRC - So you would see in UADS for ID TSO0001 the following members TSO00010 TSO00011 TSO00012, and so forth. It was the way the developers of TSO and UADS chose to provide additional entries when there was an "overflow" condition. Should the information maintained in UADS exceeded the current entries size. You could associated multiple account numbers to a single TSO ID and this could lead to the creation (by the system) of more entries in UADS for the one TSOID. Over time, there was never an 8 Char TSO ID. Instead several alterations were made that allowed the TSO ID to "look" like 8 chars. In the past when you submitted a job in TSO it had to be the TSOID+1 char. Otherwise you were not able to use OUTPUT to view your jobs. This is well before ISPF/SPF. Just native TSO. The restriction was/is TSOID +1. As exits and restrictions became lifted, it looked like an 8 char TSOID. But when UADS was shoved to the side in favor of the SAF handling the info, then in many cases, 8 chars could be used. However LOGON I think is still restricted in TSO to a 7 char max ID name. Then user exits, IKJEFT10, allowed shops to start bypassing the 7char restrictions. And then more changes came. TSO provides a rudimentary security and access control implemented through the use of the TSO User Attribute dataset (SYS1.UADS), which is created during System Generation. TSO User IDs are administered (added, changed, and deleted) by using the Account TSO command. Access to the TSO system, and the functions the user is allowed to complete once access is granted are controlled by settings in the profile of the ID record in this dataset. Before any TSO commands may be entered, the LOGON command must be used with a valid TSO User ID. But the basic 7 characters maximum is due to UADS and the extension records for TSO USER IDs. A quick search on www.ibm.com for IKJ6554I gets the following hit MSGIKJ56644I 'no valid TSO userid, default attribute used' may or may not be issued, which indicates that the default of NOPREFIX is taken Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Peter Hunkeler > Sent: Tuesday, July 08, 2014 12:04 AM > To: [email protected] > Subject: Authorizing 8 char technical userid to use TSO CONSOLE command > > 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? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
