On 2017-02-06, at 12:51, Jesse 1 Robinson wrote:

> In one sense, TSO userids have always 'tied up' 8 bytes, but the first byte 
> by convention has always been the length of the actual userid in the next 7 
> characters. This structure is utterly pervasive throughout TSO(/E). Not just 
> IBM processes but countless RYO and third party processes as well. Even the 
> structure of UADS for a user is set of multiple members named as 
> userid+digit, which requires an id of 7 characters or less.  
>  
UADS has outlived its usefulness.

> The motivation for the increased length seems to me entirely a matter of 
> responding (dare I say catering?) to grousing from the non-mainframe world 
> where in many shops, the TSO id has to be different from the all other 
> applications that allow a full 8 characters. I don't find that requirement 
> offensive because in many shops, TSO ids are assigned by a pattern 
> representing department affiliation, where the first few characters indicate 
> the users' function. This actually simplifies access rules, since all, say, 
> STORxxx users can be granted elevated DASD management authority. If the 
> person changes function, you want the userid to lose the old authority in 
> favor of whatever comes next.  
>  
I categorize it as "Plays well with others."  (Not!)  One more impediment
for the sales force to overcome.

> I've never been a promoter of increased userid length because I don't think 
> it's worth the enormous trouble it will cause. I think the vast majority of 
> shops will refrain from pulling the 8-character trigger and live comfortable 
> with the world as it's always been.  
>  
Dismayingly ironically, the need has been addressed by UNIX System Services:
        • z/OS 2.2.0
        • z/OS UNIX System Services
        • z/OS UNIX System Services Planning
        • Customizing z/OS UNIX
        • Customizing the BPXPRMxx member of SYS1.PARMLIB
        • Defining system features
        • USERIDALIASTABLE
This augments the character vocabulary of login IDs by mapping them
onto classic user IDs.  But:
o It retains for aliases the 8-character limit prevalent for user
  IDs elsewhere in z/OS.  (Only TSO has the 7-character limit.)
  It would have been an excellent opportunity to go to longer IDs
  such as the 32 which I understand Linux supports.
o It applies only to UNIX logons, not to ID management in general.
  Compatibility obstacles are nicely overcome because UNIX syscalls
  deal in the aliases, classic facilities in the classic IDs.
o Most dismayingly, it uses a collateral (UNIX) file with attendant
  performance impact, described as varying directly with the number
  of IDs aliased.  This should have properly been implemented
  uniformly in the RACF DB.

Conway's Law again, dammit!  A solution is devised but its applicability
is restricted because of deficient communication among development
groups.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to