Re: Eight-character TSO Userid Support

[Paul Gilmartin]

On Wed, 8 Feb 2017 12:08:47 -0600, Walt Farrell wrote:
>
>In theory, similar supported located at the "edge" between z/OS and network 
>apps would also allow mapping from a 32-character Linux ID to an 8-character 
>z/OS ID, without user action. 
> 
Or even 7, for maximum TSO compatibility?  

>It's not a perfect solution for what gil wants to see, but it would solve a 
>lot of compatibility issues without requiring all the applications to change. 
>Only the security products. 
>
This seems to meet most requirements: TSO, UNIX, and LDAP.  Why, then, is there
any need for OA51203 or USERIDALIASTABLE?  And EIM appears to be done with RACF
which is the correct component for identity management.

http://www-01.ibm.com/support/docview.wss?uid=swg1OA51203


>z/OS also provides functions, today, that applications can use for something 
>similar: z/OS Enerprise Identity Mapping. For more about that you can see its 
>Guide and Reference:
>  
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/eima1170/CCONTENTS?SHELF=all13be9=SA22-7875-09=20100617152016
>or
>  http://preview.tinyurl.com/znostgd

Thanks.


On Mon, 6 Feb 2017 20:37:41 -0500, Tom Conley wrote:
>
>> 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
>   ...
>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.
>
And I'll continue to disagree.  Not so much with Tom as with IBM's chaotic
design practices.  Given two very similar requirements (and perhaps a third),
expanding the user name spaces in TSO and UNIX System services, why:
o provide two separate solutions, OA51203 and USERIDALIASTABLE for UNIX
  when a single one should suffice?
o And why implement USERIDALIASTABLE, at the expense of decreased
  performance, outside RACF, the proper platform for identity management?

It appears that EIM should have been the single solution.

-- gil

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

Re: Eight-character TSO Userid Support

[Walt Farrell]

On Tue, 7 Feb 2017 12:35:10 -0800, Ed Jaffe  wrote:

>Any notion of extending to 32 characters would be sheer folly. That
>would require changes to the three major security products, z/OS
>subsystems, ISV products, customer code, etc. It would never get done.
>Never, ever...

RACF (and presumably the other security products if they're properly 
maintaining RACF compatibility) already support mapping long identities into 
8-character user IDs. Think, for example, of scenarios such as a user's tn3270e 
client presenting a digital certificate to the server over SSL/TLS and getting 
logged on to an application such as TSO/E, CICS, etc. automatically without 
further action on the user's part.

In theory, similar supported located at the "edge" between z/OS and network 
apps would also allow mapping from a 32-character Linux ID to an 8-character 
z/OS ID, without user action. 

It's not a perfect solution for what gil wants to see, but it would solve a lot 
of compatibility issues without requiring all the applications to change. Only 
the security products. 

z/OS also provides functions, today, that applications can use for something 
similar: z/OS Enerprise Identity Mapping. For more about that you can see its 
Guide and Reference:
  
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/eima1170/CCONTENTS?SHELF=all13be9=SA22-7875-09=20100617152016
or
  http://preview.tinyurl.com/znostgd

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

Re: Eight-character TSO Userid Support

[Ed Jaffe]

On 2/6/2017 5:37 PM, Tom Conley wrote:


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@#$%. 


Indeed. And, remember the issue here is with TSO/E only. Not z/OS.

RACF, CA-ACF2, CA-TSS and z/OS subsystems already support 8-character 
userids. You can define 8-character userids, use them with CICS, IMS, 
DB2, etc. You can use 8-character userids with any Phoenix Software 
products and I suspect the same is true for products from other ISVs as 
well as much user/customer code. Ironically, you even assign an 
8-character userid to the TCAS started task itself, but not to the end 
users that attempt to logon to TSO/E via that TCAS. LOL!


TSO/E is the outlier. This support corrects that imbalance and makes all 
well with the world again.


Any notion of extending to 32 characters would be sheer folly. That 
would require changes to the three major security products, z/OS 
subsystems, ISV products, customer code, etc. It would never get done. 
Never, ever...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Eight-character TSO Userid Support

[Elardus Engelbrecht]

Patrick Loftus wrote:

>Looks like 8 character TSO userid support in z/OS v2r3
>http://www-01.ibm.com/support/docview.wss?uid=swg1OA51203

At last, many thanks, but that APAR is for a third party product? 

I believe many program modules and control blocks might need to be revised. 
That is a major project on its own... Of course RACF and SDSF for example, are 
already fixed by now to handle ids with length 1 - 8 chars.

When we're at v2.3, I need to revise that TSO PREFIX to see if any changes are 
needed and my ISPF exit 16 for example. 

John McKown wrote:

>​Very true. I know of a lot of control block which look something like:
>USERID   DS 0CL8
>USERIDL  DS FL1
>USERIDV  DS CL7​

And lots of similar control blocks/macros in RACF, say from 
SYS1.MACLIB(IHAACEE):

ACEEUSER DS0CL9
ACEEUSRL DSAL1 
ACEEUSRI DSCL8 

Yes, my sample above is for a full 8 char id, but this show that layout is 
similar and generally used for many such fields.

Generally, these layouts are definition of full field starting with length and 
rest of that field sometimes padded to right with x'40'.


Paul Gilmartin wrote:

>> USERID   DS 0CL8
>> USERIDL  DS FL1
>> USERIDV  DS CL7​
 
>Why in that order rather than the reverse?

Do you have any samples of the reverse? Just curious of course.

But about 'why' - It is simply because how Assembler is working with [yet 
unknown at start of processing] offsets inside a record trying to figure out 
length of individual fields and offsets of each.



> UADS has outlived its usefulness.

False. If RACF is dead, what then? Yes, there are 1001 other ways to recover 
[1] from that scenario, but having an 7 char TSO id in UADS, simply eliminates 
many [or some if you like] steps to recovery. (with several replies on console 
during a RACF FAILSOFT time)

Groete / Greetings
Elardus Engelbrecht

[1] - You must be fully prepared BEFORE any failure of course, otherwise you're 
SOL!

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

Re: Eight-character TSO Userid Support

[David Cole]

Two things, Skip...

First, your assumption is quite understandable. 
As a severely CDO programmer, I have always been 
deeply offended by IBM's placement of the 
username length field in the PSCB and UPT.


Second, I think the most likely way IBM will deal 
with this is to do what it has done in the past...

  1) Create new fields to hold the longer names and their lengths.
  2) Create a flag to indicate that the new fields exist.
  3) For names that will fit, put that name into both fields.
  4) For names that won't fit, put it only in the new field,
 and set the old field to some indicative keyword such as
 " INVALD", "!WRONG", "*NOTHIS" or some such.






At 2/6/2017 04:57 PM, Jesse 1 Robinson wrote:
I stand edified. Had not seen the inverse, which 
I feel is kind of unusual. In general, when a 
field is governed by a length indicator, it 
seems that most often the length comes first. In 
this case, since the overall field itself is 
fixed, it doesn't much matter where you put the 
length. Maybe an EXecute MVC or CLC is a tad 
simpler if the thing being handled comes first. 
In any case, finding room for an 8th meaningful 
character is going to be a massive undertaking. 
Besides OA51203 (which looks like Omegamon), 
there are going to be a ton of supporting APARs.


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List 
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Cole

Sent: Monday, February 06, 2017 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Eight-character TSO Userid Support

At 2/6/2017 02:51 PM, 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."


Uh no. In a couple of major TSO cblocks, it's a 
7 character field FOLLOWED by the length field...



Examples:

PSCBUSER DSCL7  USERID PADDED RIGHT WITH
BLANKS 03-IKJPSCB
PSCBUSRL DSCL1  LENGTH OF
USERID03-IKJPSCB


and


UPTPREFX DSCL7  DSNAME
PREFIXY02669 03-IKJUPT
UPTPREFL DSBL1  LENGTH OF DSNAME
PREFIX  Y02669 03-IKJUPT


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware


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


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:<mailto:dbc...@colesoft.com>dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware  


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

Re: Eight-character TSO Userid Support

[Tom Conley]

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

Re: Eight-character TSO Userid Support

[Paul Gilmartin]

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

Re: Eight-character TSO Userid Support

[Jesse 1 Robinson]

I stand edified. Had not seen the inverse, which I feel is kind of unusual. In 
general, when a field is governed by a length indicator, it seems that most 
often the length comes first. In this case, since the overall field itself is 
fixed, it doesn't much matter where you put the length. Maybe an EXecute MVC or 
CLC is a tad simpler if the thing being handled comes first. In any case, 
finding room for an 8th meaningful character is going to be a massive 
undertaking. Besides OA51203 (which looks like Omegamon), there are going to be 
a ton of supporting APARs.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Cole
Sent: Monday, February 06, 2017 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Eight-character TSO Userid Support

At 2/6/2017 02:51 PM, 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."

Uh no. In a couple of major TSO cblocks, it's a 7 character field FOLLOWED by 
the length field...

Examples:

PSCBUSER DSCL7  USERID PADDED RIGHT WITH 
BLANKS 03-IKJPSCB
PSCBUSRL DSCL1  LENGTH OF 
USERID03-IKJPSCB

and

UPTPREFX DSCL7  DSNAME 
PREFIXY02669 03-IKJUPT
UPTPREFL DSBL1  LENGTH OF DSNAME 
PREFIX  Y02669 03-IKJUPT

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware


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

Re: Eight-character TSO Userid Support

[David Cole]

At 2/6/2017 02:51 PM, 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."


Uh no. In a couple of major TSO cblocks, it's a 7 character field 
FOLLOWED by the length field...


Examples:

PSCBUSER DSCL7  USERID PADDED RIGHT WITH 
BLANKS 03-IKJPSCB
PSCBUSRL DSCL1  LENGTH OF 
USERID03-IKJPSCB


and

UPTPREFX DSCL7  DSNAME 
PREFIXY02669 03-IKJUPT
UPTPREFL DSBL1  LENGTH OF DSNAME 
PREFIX  Y02669 03-IKJUPT


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

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

Re: Eight-character TSO Userid Support

[Jesse 1 Robinson]

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.  

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'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.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, February 06, 2017 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Eight-character TSO Userid Support

On 2017-02-06, at 08:29, John McKown wrote:

> On Mon, Feb 6, 2017 at 8:45 AM, Edward Gould <edgould1...@comcast.net>
> wrote:
>> 
>> Thanks, I wonder how much  IBM and user code is going to have to 
>> change to allow this?
>>  
I suppose it depends on whether your installation exploits the feature.

DSN prefix?  SUBMIT?  OUTPUT?  (I'd prefer to see SUBMIT modified to relax the 
F80 limit.)

> ​Very true. I know of a lot of control block which look something like:
> 
> USERID   DS 0CL8
> USERIDL  DS FL1
> USERIDV  DS CL7​
>  
Why in that order rather than the reverse?

All in all, it's underreaching to break compatibility for a 15% increase.  
While 8 is a pervasive enterprise convention, many OSes (Linux? OS X? (I just 
succeeded with 32)) allow far more.  Better to allow a long login name to map 
to a short UID.

-- gil


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

Re: Eight-character TSO Userid Support

[Paul Gilmartin]

On 2017-02-06, at 08:29, John McKown wrote:

> On Mon, Feb 6, 2017 at 8:45 AM, Edward Gould 
> wrote:
>> 
>> Thanks, I wonder how much  IBM and user code is going to have to change to
>> allow this?
>>  
I suppose it depends on whether your installation exploits the feature.

DSN prefix?  SUBMIT?  OUTPUT?  (I'd prefer to see SUBMIT modified to
relax the F80 limit.)

> ​Very true. I know of a lot of control block which look something like:
> 
> USERID   DS 0CL8
> USERIDL  DS FL1
> USERIDV  DS CL7​
>  
Why in that order rather than the reverse?

All in all, it's underreaching to break compatibility for a
15% increase.  While 8 is a pervasive enterprise convention,
many OSes (Linux? OS X? (I just succeeded with 32)) allow far
more.  Better to allow a long login name to map to a short UID.

-- gil

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

Re: Eight-character TSO Userid Support

[Binyamin Dissen]

On Mon, 6 Feb 2017 08:45:28 -0600 Edward Gould 
wrote:

:>Thanks, I wonder how much  IBM and user code is going to have to change to 
allow this?

They can require/default a PROFILE NOPREFIX. This will address almost all
dataset issues.

Then the FIB commands will need some slight changes.

:>> On Feb 6, 2017, at 6:57 AM, Patrick Loftus  
wrote:
:>> Looks like 8 character TSO userid support in z/OS v2r3
:>> http://www-01.ibm.com/support/docview.wss?uid=swg1OA51203

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Eight-character TSO Userid Support

[Patrick Loftus]

I guess it would involved A LOT of changes for IBM, ISVs, and users.
I suppose it will be optionally enabled,vuntil z/OS v3r1 :)

Shouldn't the 2.3 preview be released about now?  Maybe other APARs will reveal 
other snippets.

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

Re: Eight-character TSO Userid Support

[John McKown]

On Mon, Feb 6, 2017 at 8:45 AM, Edward Gould 
wrote:

> Patrick:
> Thanks, I wonder how much  IBM and user code is going to have to change to
> allow this?
> Ed
>

​Very true. I know of a lot of control block which look something like:

USERID   DS 0CL8
USERIDL  DS FL1
USERIDV  DS CL7​

-- 
Our calculus classes are an integral part of your education.

Maranatha! <><
John McKown

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

Re: Eight-character TSO Userid Support

[Edward Gould]

Patrick:
Thanks, I wonder how much  IBM and user code is going to have to change to 
allow this?
Ed
> On Feb 6, 2017, at 6:57 AM, Patrick Loftus  wrote:
> 
> Looks like 8 character TSO userid support in z/OS v2r3
> http://www-01.ibm.com/support/docview.wss?uid=swg1OA51203
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Eight-character TSO Userid Support

[Patrick Loftus]

Looks like 8 character TSO userid support in z/OS v2r3
http://www-01.ibm.com/support/docview.wss?uid=swg1OA51203

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