On 2/6/2017 7:37 PM, Paul Gilmartin wrote:
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
I must say one thing. This entire post by Gil is untrue. His
conjecture about we should have done 32 characters would have made this
project wait at least another, and possibly two releases of z/OS. The
line about deficient communication is unadulterated bull@#$%. A large
number of people at both IBM and OEM vendors have been working for years
to deliver 8-character TSO support. The work these people have done is
worthy of praise, not damnation. A non-disclosure prevents me from
saying more at this time, but for the folks on the list, you need to
know that Gil is completely wrong on this issue.
Regards,
Tom Conley
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
