Re: Mainframe user ID length
To summarize: There are many ways to skin a cat. You can use LDAP. You can have looong user id's within LDAP. You can type anything in JCL (especially in comments or DD *). You also should distinguish between z/OS and RACF (TSS, ACF2), and JCL and JES2. However for security you have to keep max-8-characters userids and those userids may have permits or group connects. BTW: It is also possible to have some front-end GUI application, when user provides loong ID or just choose his favorite animal on picture and the application maps it to old stinkin' 8-character user ID in RACF/TSS/ACF2/PIES/Thunderbolt. (I'm sorry, I couldn't resist) -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Wed, 6 May 2020 22:14:40 -0500, Tim Hare wrote: >... they boil down to authenticating using some non-RACF method, ... > Ouch! Sounds as if RACF needs an RFE, if true. But what does ssh do, for example? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
As many have stated you are limited to 8 upper case characters, 7 if you still use UADS; however if the MQ user is off-platform, perhaps one of the various tools for mapping other IDs to a RACF ID could be used? These are all part of RACF (not sure about ACF2 or Top Secret) but as I see it they boil down to authenticating using some non-RACF method, then taking that ID and mapping it to a RACF ID, which would be the ID used in the ACEE (and probably other places), but the user wouldn't necessarily need to know it. There are probably people on this list far more expert in those than I am, having never had to implement one of them, but I know they exist. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
> If there's a complaint about something I wrote, OK, fine, but how about making sure it's a complaint about something I wrote? :-) You wrote several things. Different responses referred to different things you wrote. I don't recall anybody claiming that you can't have a long userid in instream data. What they have claimed, accurately, is that you can't have a long userid in your JCL. Now for a technical question. If some component validates a long userid via LDAP, creates an ACEE for the user and copies a jobstream to the Internal Reader, will the job inherit the correct authentication credentials? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Wednesday, May 6, 2020 1:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Tom Marchant wrote: >What is your point? The contents of in-stream data is not part of >JCL, any more than the contents of some other data set referenced >in a DD statement is. Paul Gilmartin wrote: >There's a qualitative difference. The Reader or Converter must >inspect every record of an in-stream data set, and the Interpreter >or Access Method must scan for substitutable symbols. Not so with >some other data set. >And the in-line data appear in the SUBMITted member commonly called >JCL. If anyone still cares, here's what I actually wrote: >If you want to pass a longer user ID to something else >using a different vocabulary, JCL isn't going to stop you. >Example: Try using JCL to invoke z/OS's FTP client to transfer a file to >an arbitrary FTP server, specifying a user ID longer than 8 characters. >Can it be done? Of course it can; it's perfectly routine. You just don't >use JES-related syntax, that's all. 100% true! If there's a complaint about something I wrote, OK, fine, but how about making sure it's a complaint about something I wrote? :-) Who says mainframe professionals aren't the most friendly, helpful individuals willing to go the extra mile (or kilometer) to help solve user problems? Why, they never say "Can't be done!" and refuse to help. That's just ridiculous. :-) :-) It's usually not this platform that's getting in the way of progress. Here's yet another such case. For over two decades (closer to three) we've been submitting JCL to JES2 or JES3 to do such (awful) things as sending and receiving files via FTP, with absolutely no trouble specifying a user ID that's longer than 8 characters. We haven't even given it a second thought, really. JCL hasn't and isn't standing in your way here, obviously. Since the OS/390 days you've been able to present a X.509 digital certificate to RACF in lieu of a user ID for authentication and authorization. These features aren't state secrets. If you have z/OS, you have in-stream data in JCL. (How long has that been?) You also have the IBM Directory Server for z/OS. If you have the z/OS Security Server, you have RACF client certificate authentication. If you don't like maximum 8 character user IDs, OK, don't trouble your users with them! There are other viable, sensible approaches available -- handed to you, really. Plenty of organizations are already using them and aren't troubling their users with maximum 8 character IDs. So let's cut the nonsense and start leading progress rather than inhibiting it, OK? A few more "Wow, that's pretty interesting!" remarks would be welcome. (Thanks, Bob.) Deal? And sure, if there's something missing that you want or need, by all means ask (IBM RFE). OK, back to problem solving - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- 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: Mainframe user ID length
Tom Marchant wrote: >What is your point? The contents of in-stream data is not part of >JCL, any more than the contents of some other data set referenced >in a DD statement is. Paul Gilmartin wrote: >There's a qualitative difference. The Reader or Converter must >inspect every record of an in-stream data set, and the Interpreter >or Access Method must scan for substitutable symbols. Not so with >some other data set. >And the in-line data appear in the SUBMITted member commonly called >JCL. If anyone still cares, here's what I actually wrote: >If you want to pass a longer user ID to something else >using a different vocabulary, JCL isn't going to stop you. >Example: Try using JCL to invoke z/OS's FTP client to transfer a file to >an arbitrary FTP server, specifying a user ID longer than 8 characters. >Can it be done? Of course it can; it's perfectly routine. You just don't >use JES-related syntax, that's all. 100% true! If there's a complaint about something I wrote, OK, fine, but how about making sure it's a complaint about something I wrote? :-) Who says mainframe professionals aren't the most friendly, helpful individuals willing to go the extra mile (or kilometer) to help solve user problems? Why, they never say "Can't be done!" and refuse to help. That's just ridiculous. :-) :-) It's usually not this platform that's getting in the way of progress. Here's yet another such case. For over two decades (closer to three) we've been submitting JCL to JES2 or JES3 to do such (awful) things as sending and receiving files via FTP, with absolutely no trouble specifying a user ID that's longer than 8 characters. We haven't even given it a second thought, really. JCL hasn't and isn't standing in your way here, obviously. Since the OS/390 days you've been able to present a X.509 digital certificate to RACF in lieu of a user ID for authentication and authorization. These features aren't state secrets. If you have z/OS, you have in-stream data in JCL. (How long has that been?) You also have the IBM Directory Server for z/OS. If you have the z/OS Security Server, you have RACF client certificate authentication. If you don't like maximum 8 character user IDs, OK, don't trouble your users with them! There are other viable, sensible approaches available -- handed to you, really. Plenty of organizations are already using them and aren't troubling their users with maximum 8 character IDs. So let's cut the nonsense and start leading progress rather than inhibiting it, OK? A few more "Wow, that's pretty interesting!" remarks would be welcome. (Thanks, Bob.) Deal? And sure, if there's something missing that you want or need, by all means ask (IBM RFE). OK, back to problem solving - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Tue, 5 May 2020 15:07:59 -0500, Tom Marchant wrote: >On Tue, 5 May 2020 15:03:06 +0800, Timothy Sipples wrote: > >>Shmuel Metz wrote: >>>Regardless of why it is coded that way, the code is in >>>the C/I and the error message comes from the C/I. >> >>Yes, and in-stream data is an intrinsic feature of the Job Control >>Language (JCL). It says so right here, among other places: >> >>https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zjcl/zjclt_exercise_crtNsubmitjob.htm > >What is your point? The contents of in-stream data is not part of JCL, any >more >than the contents of some other data set referenced in a DD statement is. > There's a qualitative difference. The Reader or Converter must inspect every record of an in-stream data set, and the Interpreter or Access Method must scan for substitutable symbols. Not so with some other data set. And the in-line data appear in the SUBMITted member commonly called JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Tue, 5 May 2020 15:03:06 +0800, Timothy Sipples wrote: >Shmuel Metz wrote: >>Regardless of why it is coded that way, the code is in >>the C/I and the error message comes from the C/I. > >Yes, and in-stream data is an intrinsic feature of the Job Control >Language (JCL). It says so right here, among other places: > >https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zjcl/zjclt_exercise_crtNsubmitjob.htm What is your point? The contents of in-stream data is not part of JCL, any more than the contents of some other data set referenced in a DD statement is. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Shmuel Metz wrote: >Regardless of why it is coded that way, the code is in >the C/I and the error message comes from the C/I. Yes, and in-stream data is an intrinsic feature of the Job Control Language (JCL). It says so right here, among other places: https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zjcl/zjclt_exercise_crtNsubmitjob.htm Frank Swarbrick wrote: >On a separate line, are you saying is it possible for z/OS to use >a non-z/OS LDAP server for authentication (and authorization?), >including user IDs and passwords? "z/OS" is a big, grand place, so yes is the answer. For example, that's exactly what the z/OS Container Extensions do(es) if you simply turn on its LDAP feature. Naturally you do that from the z/OS Management Facility. >But this would that still require TSO and CICS (and IMS? and others?) >signon processes to be able to handle those user IDs? OK, now you're naming names (specific subsystems), and then "it depends." Let's pick CICS as an example. If you want to authenticate and authorize a user against a LDAP server (highly preferably the one on z/OS) for purposes of executing a CICS transaction, then one way to do that is to have a CICS Liberty region on the front side handling the job. CICS Liberty can definitely authenticate and authorize based on LDAP's guidance (with ID mapping), and there's some pretty good documentation explaining how to do that. TSO/E is "classic," and thus it understands up to 8 character maximum user IDs (up from 7 previously). However, as I sketched out, the end user need not necessarily know that. It'd be wonderful if somebody creates a TSO/E sign on screen analogous to z/VSE's that accepts a long user ID and passphrase which is then checked against LDAP on z/OS to decide whether to log the user on. LDAP on z/OS would then supply the mapped short name, without the user's active involvement. >What I would love to see is some sort of "single signon" option, >where a user would only need to sign on to their personal workstation >and not need to explicitly sign on to z/OS at all. There are many products that do that, including from IBM. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
I know on my MQ instance I have installed on my home Windows machine, MQ truncates my Windows user ID "Frank Swarbrick" to "Frank Swarbr". From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Monday, May 4, 2020 2:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length The maximum length on Linux is 32; whether MQ will work with a name longer than 12 is a separate issue. There are also Linux commands that will display the UID instead of a username longer than 8. LDAP can map long names to short. I don't know about non-IBM LDAP. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Monday, May 4, 2020 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Wow! That's a lot to digest. A couple of things. First, I see the following documented: “On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 characters.” From https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm I wonder how this works if RACF user IDs are only allowed up to 8 characters. Would an alternate SAF product be required? I can't see anything documented to explain how this might work. On a separate line, are you saying is it possible for z/OS to use a non-z/OS LDAP server for authentication (and authorization?), including user IDs and passwords? But this would that still require TSO and CICS (and IMS? and others?) signon processes to be able to handle those user IDs? It sounds like both of these things are true, but I want to make sure I am not misunderstanding you. From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Saturday, May 2, 2020 12:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here f
Re: Mainframe user ID length (not ... Digest ...)
On Mon, 4 May 2020 15:31:52 -0500, Tom Marchant wrote: >On Mon, 4 May 2020 19:14:31 +, Frank Swarbrick wrote: > >>What I would love to see is some sort of "single signon" option, where a user >>would only need >>to sign on to their personal workstation and not need to explicitly sign on >>to z/OS at all. > >IMO, this is a bad idea unless you can count on everyone's workstation being >at least as secure >as z/OS is. All you need is one user who gets their PC hacked and the hacker >has access to z/OS, >with whatever authority that user has. > But the user will keep credentials on a desktop system (I've done so with ssh) or on a Post-It on the terminal screen, etc. Multi-factor? Real-time facial recognition with challenge-response? Remember, Watson won at Jeopardy, and could probably beat captchas. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
The maximum length on Linux is 32; whether MQ will work with a name longer than 12 is a separate issue. There are also Linux commands that will display the UID instead of a username longer than 8. LDAP can map long names to short. I don't know about non-IBM LDAP. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Monday, May 4, 2020 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Wow! That's a lot to digest. A couple of things. First, I see the following documented: “On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 characters.” From https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm I wonder how this works if RACF user IDs are only allowed up to 8 characters. Would an alternate SAF product be required? I can't see anything documented to explain how this might work. On a separate line, are you saying is it possible for z/OS to use a non-z/OS LDAP server for authentication (and authorization?), including user IDs and passwords? But this would that still require TSO and CICS (and IMS? and others?) signon processes to be able to handle those user IDs? It sounds like both of these things are true, but I want to make sure I am not misunderstanding you. From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Saturday, May 2, 2020 12:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example.
Re: Mainframe user ID length
MQ does, in fact, support that, and I've used it. It's the "Channel Authentication" user mapping feature. I was just wondering if it was "directly supported" without a mapping, if the presented user ID was more than 8 characters. Thanks. From: IBM Mainframe Discussion List on behalf of Walt Farrell Sent: Sunday, May 3, 2020 7:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length On Thu, 30 Apr 2020 19:46:04 +, Frank Swarbrick wrote: >Is z/OS still limited in all cases to 8 upper case characters? I am curious >if a user that only has access to MQ might be able to have a longer and >ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. It is in theory possible for an application (such as MQ) to use z/OS security services to map an alternative identity (which might have different characteristics from a z/OS user ID) into a standard z/OS user ID. That can be done, for example, when applications support authentication via digital certificates, or via Kerberos (e.g., Windows Active Directory), or via LDAP. And there are additional mechanisms besides those three that z/OS supports. I have no idea whether MQ supports any of those alternative mechanisms, nor which ones, nor whether they're applicable in your environment. -- Walt -- 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: Mainframe user ID length
> As a side note, why won't JCL accept all legal e-mail address? I thought there was an IBM stated aim to get to this, but I cannot find it. Certainly the recently added (Z/OS 1.3 I think) email field (WAEMAIL) in the RACF WORKATTR segment has a requirement to be unique within the RACF database. So there is a one-to-one mapping between email addresses and RACF userids. Looks like this is paving the way to achieving what you suggest. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 04 May 2020 17:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Mainframe user ID length Your claim was "You can specify pretty much anything you want in JCL." Regardless of why it is coded that way, the code is in the C/I and the error message comes from the C/I. The fact remains that you are limited in what you can specify in JCL. My first thought was that you meant that JECL had looser limits, but I couldn't find thoses paraemters in either JES2 JECL or JES3 JECL. As a side note, why won't JCL accept all legal e-mail address? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Monday, May 4, 2020 1:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Shmuel Metz wrote: >According to MVS JCL Reference, SA23-1385-40, both USER=abcdefghi and >EMAIL=foo+...@patriot.net are illegal. That's not a JES issue. It is JES's issue. JCL is simply respecting JES limits there using that particular syntax. If you want to pass a longer user ID to something else using a different vocabulary, JCL isn't going to stop you. Example: Try using JCL to invoke z/OS's FTP client to transfer a file to an arbitrary FTP server, specifying a user ID longer than 8 characters. Can it be done? Of course it can; it's perfectly routine. You just don't use JES-related syntax, that's all. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Wow! That's a lot to digest. A couple of things. First, I see the following documented: “On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 characters.” From https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm I wonder how this works if RACF user IDs are only allowed up to 8 characters. Would an alternate SAF product be required? I can't see anything documented to explain how this might work. On a separate line, are you saying is it possible for z/OS to use a non-z/OS LDAP server for authentication (and authorization?), including user IDs and passwords? But this would that still require TSO and CICS (and IMS? and others?) signon processes to be able to handle those user IDs? It sounds like both of these things are true, but I want to make sure I am not misunderstanding you. From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Saturday, May 2, 2020 12:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on scree
Re: Mainframe user ID length
Your claim was "You can specify pretty much anything you want in JCL." Regardless of why it is coded that way, the code is in the C/I and the error message comes from the C/I. The fact remains that you are limited in what you can specify in JCL. My first thought was that you meant that JECL had looser limits, but I couldn't find thoses paraemters in either JES2 JECL or JES3 JECL. As a side note, why won't JCL accept all legal e-mail address? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Monday, May 4, 2020 1:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Shmuel Metz wrote: >According to MVS JCL Reference, SA23-1385-40, both >USER=abcdefghi and EMAIL=foo+...@patriot.net are >illegal. That's not a JES issue. It is JES's issue. JCL is simply respecting JES limits there using that particular syntax. If you want to pass a longer user ID to something else using a different vocabulary, JCL isn't going to stop you. Example: Try using JCL to invoke z/OS's FTP client to transfer a file to an arbitrary FTP server, specifying a user ID longer than 8 characters. Can it be done? Of course it can; it's perfectly routine. You just don't use JES-related syntax, that's all. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- 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: Mainframe user ID length
Shmuel Metz wrote: >According to MVS JCL Reference, SA23-1385-40, both >USER=abcdefghi and EMAIL=foo+...@patriot.net are >illegal. That's not a JES issue. It is JES's issue. JCL is simply respecting JES limits there using that particular syntax. If you want to pass a longer user ID to something else using a different vocabulary, JCL isn't going to stop you. Example: Try using JCL to invoke z/OS's FTP client to transfer a file to an arbitrary FTP server, specifying a user ID longer than 8 characters. Can it be done? Of course it can; it's perfectly routine. You just don't use JES-related syntax, that's all. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
This, by the way, has been a fascinating discussion, for me at least. My
thanks to Mr Sipples for contradicting what I thought I knew without
question.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Being a programmer is one thing above all else: It is understanding how
things work. -from the introduction to "Assembly Language Step-by-Step" (2nd
edition) by Jeff Nuntemann */
-Original Message-
From: Bob Bridges [mailto:robhbrid...@gmail.com]
Sent: Sunday, May 3, 2020 10:24
So maybe - maybe, I don't know either - if I sign on to z/OS with a
certificate, or LDAP, or anything other than the usual, the sign-on routine
MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
everything works fine, I guess.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Saturday, May 2, 2020 16:26
FWIW, authentication ("signing on") and authorization ("permissions") are
separate issues. RACF (and its sisters) do both, so it is easy to run them
together, but they are separate issues.* You are correct -- one might
authenticate with an iris scanner, but you still need a decision "can Bob
update SYS1.LINKLIB or not?"
RACROUTE takes a USERID of up to 8 characters, but generally works not
directly from a USERID but rather from an existing ACEE. But yes, the ACEE
includes -- you guessed it -- the basic 1+8 USERID. Not every ACEE has a
USERID filled in, so perhaps -- perhaps, I don't know -- perhaps one could
go from certificate authentication to an ACEE to authorization.
*I heard Barry Shrager, a father of mainframe security, say words to the
effect that authentication is the more important issue, because without good
authentication that you really are RBRIDGES, what difference does it make
what resources RBRIDGES has access to?
-Original Message-
From: Bob Bridges
Sent: Saturday, May 2, 2020 11:10 AM
But...but... (Still expostulating, here, you see.) When I want to open a
dataset for editing in TSO, the OS sends a question to the security system,
asking "is allowed to ?".
To identify it specifies my ID. The question is routed to
RACF, ACF2 or Top Secret, and the part of the OS that is performing the
action doesn't know and doesn't care which one - but before it performs the
open, it requires an answer from the security system, and all three of them
have an 8-byte limit on the ID.
You talk about authenticating with a certificate, but how would permissions
work in that case? Isn't RACROUTE the funneling point for all such checks?
And doesn't RACROUTE require an 8-byte ID to identify the actor?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
So maybe - maybe, I don't know either - if I sign on to z/OS with a
certificate, or LDAP, or anything other than the usual, the sign-on routine
MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
everything works fine, I guess.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Democracy is where you can say what you think even if you don't think. */
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Saturday, May 2, 2020 16:26
FWIW, authentication ("signing on") and authorization ("permissions") are
separate issues. RACF (and its sisters) do both, so it is easy to run them
together, but they are separate issues.* You are correct -- one might
authenticate with an iris scanner, but you still need a decision "can Bob
update SYS1.LINKLIB or not?"
RACROUTE takes a USERID of up to 8 characters, but generally works not
directly from a USERID but rather from an existing ACEE. But yes, the ACEE
includes -- you guessed it -- the basic 1+8 USERID. Not every ACEE has a
USERID filled in, so perhaps -- perhaps, I don't know -- perhaps one could
go from certificate authentication to an ACEE to authorization.
*I heard Barry Shrager, a father of mainframe security, say words to the
effect that authentication is the more important issue, because without good
authentication that you really are RBRIDGES, what difference does it make
what resources RBRIDGES has access to?
-Original Message-
From: Bob Bridges
Sent: Saturday, May 2, 2020 11:10 AM
But...but... (Still expostulating, here, you see.) When I want to open a
dataset for editing in TSO, the OS sends a question to the security system,
asking "is allowed to ?".
To identify it specifies my ID. The question is routed to
RACF, ACF2 or Top Secret, and the part of the OS that is performing the
action doesn't know and doesn't care which one - but before it performs the
open, it requires an answer from the security system, and all three of them
have an 8-byte limit on the ID.
You talk about authenticating with a certificate, but how would permissions
work in that case? Isn't RACROUTE the funneling point for all such checks?
And doesn't RACROUTE require an 8-byte ID to identify the actor?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Thu, 30 Apr 2020 19:46:04 +, Frank Swarbrick wrote: >Is z/OS still limited in all cases to 8 upper case characters? I am curious >if a user that only has access to MQ might be able to have a longer and >ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. It is in theory possible for an application (such as MQ) to use z/OS security services to map an alternative identity (which might have different characteristics from a z/OS user ID) into a standard z/OS user ID. That can be done, for example, when applications support authentication via digital certificates, or via Kerberos (e.g., Windows Active Directory), or via LDAP. And there are additional mechanisms besides those three that z/OS supports. I have no idea whether MQ supports any of those alternative mechanisms, nor which ones, nor whether they're applicable in your environment. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
> You can specify pretty much anything you want in JCL. According to MVS JCL Reference, SA23-1385-40, both USER=abcdefghi and EMAIL=foo+...@patriot.net are illegal. That's not a JES issue. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Saturday, May 2, 2020 2:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on screen. >...Even if I've logged on from some other OS using a longer ID, >inside z/OS the system is still using an 8-byte ID. But "who cares?" Users presenting longer IDs or client certificates certainly don't. "If a tree falls in the woods" As long as there is at least adequate granularity in providing enough different security contexts it shouldn't particularly matter. For all we know (and I don't know) RACF already does something internally that has more breadth than maximum 8 character TSO/E user IDs would ord
Re: Mainframe user ID length
> You talk about authenticating with a certificate, but how would
permissions work in that case?
FWIW, authentication ("signing on") and authorization ("permissions") are
separate issues. RACF (and its sisters) do both, so it is easy to run them
together, but they are separate issues.* You are correct -- one might
authenticate with an iris scanner, but you still need a decision "can Bob
update SYS1.LINKLIB or not?"
RACROUTE takes a USERID of up to 8 characters, but generally works not
directly from a USERID but rather from an existing ACEE. But yes, the ACEE
includes -- you guessed it -- the basic 1+8 USERID. Not every ACEE has a
USERID filled in, so perhaps -- perhaps, I don't know -- perhaps one could
go from certificate authentication to an ACEE to authorization.
*I heard Barry Shrager, a father of mainframe security, say words to the
effect that authentication is the more important issue, because without good
authentication that you really are RBRIDGES, what difference does it make
what resources RBRIDGES has access to?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bob Bridges
Sent: Saturday, May 2, 2020 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe user ID length
But...but... (Still expostulating, here, you see.) When I want to open a
dataset for editing in TSO, the OS sends a question to the security system,
asking "is allowed to ?".
To identify it specifies my ID. The question is routed to
RACF, ACF2 or Top Secret, and the part of the OS that is performing the
action doesn't know and doesn't care which one - but before it performs the
open, it requires an answer from the security system, and all three of them
have an 8-byte limit on the ID.
You talk about authenticating with a certificate, but how would permissions
work in that case? Isn't RACROUTE the funneling point for all such checks?
And doesn't RACROUTE require an 8-byte ID to identify the actor?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Sat, 2 May 2020 14:34:26 +0800, Timothy Sipples wrote: >Frank Swarbrick wrote: >>"more than 8"? What's the limit, if any? > >The z/OS LDAP Server's CN limit is 256 characters, so it's at least that >large. > >>Which system components/products permit/prohibit this? >>(Start your list with JCL.) > >You can specify pretty much anything you want in JCL. Do you mean JES2? If >so, that'll use maximum 8 character user IDs. > That appears to be the exception that proves the rule, so will JES3 (as opposed to JES2) accept such as: //TEST JOB 'D83,123456',USER='Влади́мир_Пу́тин',PASSWORD=ABCD ... if that user has been defined in RACF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
But...but... (Still expostulating, here, you see.) When I want to open a dataset for editing in TSO, the OS sends a question to the security system, asking "is allowed to ?". To identify it specifies my ID. The question is routed to RACF, ACF2 or Top Secret, and the part of the OS that is performing the action doesn't know and doesn't care which one - but before it performs the open, it requires an answer from the security system, and all three of them have an 8-byte limit on the ID. You talk about authenticating with a certificate, but how would permissions work in that case? Isn't RACROUTE the funneling point for all such checks? And doesn't RACROUTE require an 8-byte ID to identify the actor? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* To be humble to superiors is duty, to equals courtesy, to inferiors nobleness. -Poor Richard */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Saturday, May 2, 2020 02:34 RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ic ha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on screen. --- Bob Bridges wrote: >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how >does RACF-or-whatever determine permissions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on screen. >...Even if I've logged on from some other OS using a longer ID, >inside z/OS the system is still using an 8-byte ID. But "who cares?" Users presenting longer IDs or client certificates certainly don't. "If a tree falls in the woods" As long as there is at least adequate granularity in providing enough different security contexts it shouldn't particularly matter. For all we know (and I don't know) RACF already does something internally that has more breadth than maximum 8 character TSO/E user IDs would ordinarily suggest. Analogously, does it matter much that Microsoft Windows still only supports a maximum of 26 single character drive letters (A to Z)? Not really, no. Microsoft (and IBM) sidestepped that limitation a long time ago by providing an alternate way to refer to disks: \\DiskABC123456\... (for example). Older software (that only understands D:\...) doesn't break because you can assign and reassign the old drive letters, while newer software and user interfaces forge ahead. You then decide whether and how quickly you'd like to move forward. I
Re: Mainframe user ID length
On Fri, 1 May 2020 12:37:58 -0400, Bob Bridges wrote: >... >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? The OS asks whether has >access to datasets or other resources - and that question allows 8 bytes for >. Even if I've logged on from some other OS using a longer ID, >inside z/OS the system is still using an 8-byte ID. > Mapping should be an approach, even as most UNIX internally rely on numeric UIDs, usually not more than 32 bits, mapping to/from user names for display. First enhance RACF to map long IDs, mixed-case, perhaps UNICODE, to traditional 8-byte IDs, generated when necessary. Progressively enhance various utilities to accept the new form, and display it, optionally as with the difference between "ls -l" and "ls -n": https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_04 Begin with the important ones: JCL and TSO LOGON; others as selected by RFE. provide a utility to display the mapping as "/bin/id" does. Provide ubiquitous JCL symbols for compatibility and z/OS should aspire to be on the leading edge rather than trailing with the USERIDALIASTABLE kludge. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
You sound like you know what you're talking about, so please interpret the following expostulations more as questions than as outright contradictions: TS> First of all, user authentication isn't necessarily required. Me> Sure, as for example in CICS. In that case CICS supplied a default userID, and the security guys (should) make sure that that ID can run only a few harmless transactions - time of day, current bid on the company's common stock, that sort of thing. But in that case the ID, even if the user is unware of it, is still a max of eight bytes long. Or you could say that in that case the user isn't ~using~ an ID (true in a way), in which case it's meaningless to say that it can be longer than eight bytes. TS> The IBM Directory Server for z/OS supports more than 8 upper case character user IDsMQ for z/OS and CICS Transaction Server for z/OS can authenticate users via LDAP. Me> I'm about to expose my ignorance here: IDS and LDAP, aren't they just IBM's attempt to let z/OS talk to non-z/OS systems? The same for MQ; the only purpose of MQ allowing IDs longer than eight characters is so MQ can do its thing across systems. The OP's question is about z/OS; if z/OS provides a mechanism for tracking IDs that I may use on other operating systems, that doesn't really count as allowing longer than 8-byte IDs internally. Or put it this way: If you say I can be authenticated via LPAR using a longer ID, and then perform tasks on the mainframe using that ID, how does RACF-or-whatever determine permissions? The OS asks whether has access to datasets or other resources - and that question allows 8 bytes for . Even if I've logged on from some other OS using a longer ID, inside z/OS the system is still using an 8-byte ID. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If everyone is thinking alike, then someone isn't thinking. -Geoge S Patton */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Friday, May 1, 2020 01:42 --- Frank Swarbrick wrote: >Is z/OS still limited in all cases to 8 upper case characters? No. The IBM Directory Server for z/OS supports more than 8 upper case character user IDs. That's a standard, included, IBM supported feature in the base z/OS operating system. --- Bob Bridges wrote: >MQ, TSO, CICS, IMS - whatever the environment, the ID has to be >authenticated by RACF (or ACF2, or TSS). Not as you've written it, no, that's not correct. First of all, user authentication isn't necessarily required. However, I and many others argue that these systems should at least be authorizing user requests. TSO/E, yes, that subsystem supports user IDs up to a maximum of 8 characters. Otherwise, I know that MQ for z/OS and CICS Transaction Server for z/OS can authenticate users via LDAP (ideally the IBM Directory Server for z/OS) at least in certain contexts. See here for example: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/ q127976_.htm I would have to dig a little deeper with respect to IMS if anyone is interested. Interestingly even the "classic" 3270 z/VSE sign on screen supports "long" user ID authentication via LDAP-based sign on, although it requires "mapping" to a short user ID under the covers: https://www.ibm.com/support/knowledgecenter/SSB27H_6.2.0/fa2ad_ovw_ldap_sign -on_process.html Users don't really have to know all that, though. They just sign on with LDAP user ID "AliceCooper1990" (or whatever). Maybe somebody would like to submit a Request for Enhancement (RFE) for something similar with TSO/E? I don't think IBM provides a "stock" sign on screen with z/OS that'll do this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Fri, 1 May 2020 13:41:54 +0800, Timothy Sipples wrote: >Frank Swarbrick wrote: >>Is z/OS still limited in all cases to 8 upper case characters? > >No. The IBM Directory Server for z/OS supports more than 8 upper case >character user IDs. That's a standard, included, IBM supported feature in >the base z/OS operating system. > "more than 8"? What's the limit, if any? Which system components/products permit/prohibit this? (Start your list with JCL.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Frank Swarbrick wrote: >Is z/OS still limited in all cases to 8 upper case characters? No. The IBM Directory Server for z/OS supports more than 8 upper case character user IDs. That's a standard, included, IBM supported feature in the base z/OS operating system. Bob Bridges wrote: >MQ, TSO, CICS, IMS - whatever the environment, the ID has to be >authenticated by RACF (or ACF2, or TSS). Not as you've written it, no, that's not correct. First of all, user authentication isn't necessarily required. However, I and many others argue that these systems should at least be authorizing user requests. TSO/E, yes, that subsystem supports user IDs up to a maximum of 8 characters. Otherwise, I know that MQ for z/OS and CICS Transaction Server for z/OS can authenticate users via LDAP (ideally the IBM Directory Server for z/OS) at least in certain contexts. See here for example: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q127976_.htm I would have to dig a little deeper with respect to IMS if anyone is interested. Interestingly even the "classic" 3270 z/VSE sign on screen supports "long" user ID authentication via LDAP-based sign on, although it requires "mapping" to a short user ID under the covers: https://www.ibm.com/support/knowledgecenter/SSB27H_6.2.0/fa2ad_ovw_ldap_sign-on_process.html Users don't really have to know all that, though. They just sign on with LDAP user ID "AliceCooper1990" (or whatever). Maybe somebody would like to submit a Request for Enhancement (RFE) for something similar with TSO/E? I don't think IBM provides a "stock" sign on screen with z/OS that'll do this. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
The past, yes, obviously. Also obviously: Not so very dead. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If everyone is thinking alike, then someone isn't thinking. -Geoge S Patton */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, April 30, 2020 21:59 I prefer to use meaningful job names. What TSO SUBMIT does sort of made sense before RACF, but I regard it as a vestige of the dead past. From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wayne Bickerdike [wayn...@gmail.com] Sent: Thursday, April 30, 2020 9:44 PM We use max 7 char user IDS. Often I can't be bothered putting a job card on a quick job, TSO SUBMIT uses your user ID and asks for a character to add to the job. Since a jobname is limited to 8 chars, makes life simple. --- On Fri, May 1, 2020 at 8:21 AM Bob Bridges wrote: > MQ, TSO, CICS, IMS - whatever the environment, the ID has to be > authenticated by RACF (or ACF2, or TSS). As far as I know they're all > limited to the usual 39 characters, and a max length of eight. > > -Original Message- > From: Frank Swarbrick > Sent: Thursday, April 30, 2020 15:46 > > Is z/OS still limited in all cases to 8 upper case characters? I am > curious if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or > IMS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
I suspect that it's tied in to two other 8 character limits: 1. components of a dsname 2. job names, whether batch, STC of TSO But why couldn't they have put the length before the 8 character userid and a reserved area after, so that it would be easier to expand the limit in the future? :-( -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Thursday, April 30, 2020 9:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length On Thu, 30 Apr 2020 19:46:04 +, Frank Swarbrick wrote: >Is z/OS still limited in all cases to 8 upper case characters? I am curious >if a user that only has access to MQ might be able to have a longer and >ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > Extending TSO UserIDs from 7 to 8 was egregious underreaching. Still a limit of 8, but for lower case see USERIDALIASTABLE in: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/urprr.htm Why, why: o Did rhey do this outside RACF? Conway's Law? o Did they not go to far more than 8 when many other systems allow a few dozen? -- gil -- 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: Mainframe user ID length
I prefer to use meaningful job names. What TSO SUBMIT does sort of made sense before RACF, but I regard it as a vestige of the dead past. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wayne Bickerdike [wayn...@gmail.com] Sent: Thursday, April 30, 2020 9:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length We use max 7 char user IDS. Often I can't be bothered putting a job card on a quick job, TSO SUBMIT uses your user ID and asks for a character to add to the job. Since a jobname is limited to 8 chars, makes life simple. On Fri, May 1, 2020 at 8:21 AM Bob Bridges wrote: > MQ, TSO, CICS, IMS - whatever the environment, the ID has to be > authenticated by RACF (or ACF2, or TSS). As far as I know they're all > limited to the usual 39 characters, and a max length of eight. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* If everyone is thinking alike, then someone isn't thinking. -Geoge S > Patton */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Thursday, April 30, 2020 15:46 > > Is z/OS still limited in all cases to 8 upper case characters? I am > curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or > IMS. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- 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: Mainframe user ID length
On Thu, 30 Apr 2020 19:46:04 +, Frank Swarbrick wrote: >Is z/OS still limited in all cases to 8 upper case characters? I am curious >if a user that only has access to MQ might be able to have a longer and >ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > Extending TSO UserIDs from 7 to 8 was egregious underreaching. Still a limit of 8, but for lower case see USERIDALIASTABLE in: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/urprr.htm Why, why: o Did rhey do this outside RACF? Conway's Law? o Did they not go to far more than 8 when many other systems allow a few dozen? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
We use max 7 char user IDS. Often I can't be bothered putting a job card on a quick job, TSO SUBMIT uses your user ID and asks for a character to add to the job. Since a jobname is limited to 8 chars, makes life simple. On Fri, May 1, 2020 at 8:21 AM Bob Bridges wrote: > MQ, TSO, CICS, IMS - whatever the environment, the ID has to be > authenticated by RACF (or ACF2, or TSS). As far as I know they're all > limited to the usual 39 characters, and a max length of eight. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* If everyone is thinking alike, then someone isn't thinking. -Geoge S > Patton */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Thursday, April 30, 2020 15:46 > > Is z/OS still limited in all cases to 8 upper case characters? I am > curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or > IMS. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
MQ, TSO, CICS, IMS - whatever the environment, the ID has to be authenticated by RACF (or ACF2, or TSS). As far as I know they're all limited to the usual 39 characters, and a max length of eight. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If everyone is thinking alike, then someone isn't thinking. -Geoge S Patton */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Thursday, April 30, 2020 15:46 Is z/OS still limited in all cases to 8 upper case characters? I am curious if a user that only has access to MQ might be able to have a longer and ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
ITYM that TSO used to have a limit of 7, and if you use UADS then it still does. If you use SAF then you can use 8. In neither case is '07'X a valid character. Don't confuse the userid with either a length field or a record number field. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Schwab [mike.a.sch...@gmail.com] Sent: Thursday, April 30, 2020 4:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length USERID length can be 8. TSO USED to have a limit of 8, with the SYS1.UADS emergency logon adding a digit to access multiple records, and job submission adding a character for the jobname. The 8th character was/is the length in Binary, x'01'-x'07'. Now you can specify an 8 byte TSO USERID, with the 8th character being > x'07'. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0za100/ch1tso_23_8char.htm. On Thu, Apr 30, 2020 at 8:21 PM Frank Swarbrick wrote: > > I'm asking about the user ID, not the password/pass phrase. But thanks. > > > From: IBM Mainframe Discussion List on behalf of > Jesse 1 Robinson > Sent: Thursday, April 30, 2020 2:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Mainframe user ID length > > RACF can now handle 'password phrase' of considerable length and/or > upper/lower case passwords. If you allow lower case, you can end up with a > mess. With traditional upper-only system option, a password typed e.g. via > TSO gets automatically translated to upper case with no user notification. > With the system option set to lower case allowed, that translation does not > occur. This means that every password entry *must* also be lower case. Some > logon environments may not allow lower case. Worse, if there is a severe > problem that requires fallback to upper only, a user with a lower case > password may not be able to logon at all. > > This is an all or nothing option. Allowing or disallowing lower case affects > all environments at the same time. > > . > . > 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 On Behalf Of > Frank Swarbrick > Sent: Thursday, April 30, 2020 12:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Mainframe user ID length > > CAUTION EXTERNAL EMAIL > > Is z/OS still limited in all cases to 8 upper case characters? I am curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Mainframe user ID length
I used TSO under OS/360's MVT release 20 in the early or mid 70's. I remember a 7 character TSO userid length limit with the 'submit' command able to add an eighth character to allow for multiple job submissions. /s/ Anthony L. Zak -Original Message- >From: David Spiegel >Sent: Apr 30, 2020 5:02 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: [IBM-MAIN] Mainframe user ID length > >TSO used to have a limit of 7. > >On 2020-04-30 16:43, Mike Schwab wrote: >> USERID length can be 8. >> >> TSO USED to have a limit of 8, with the SYS1.UADS emergency logon >> adding a digit to access multiple records, and job submission adding a >> character for the jobname. >> >> The 8th character was/is the length in Binary, x'01'-x'07'. Now you >> can specify an 8 byte TSO USERID, with the 8th character being > >> x'07'. >> >> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.e0za100%2Fch1tso_23_8char.htmdata=02%7C01%7C%7C57136fbee2814281b18408d7ed47603c%7C84df9e7fe9f640afb435%7C1%7C0%7C637238763120777692sdata=VumiQcDjPdQQ9B1ZFQXiQHRSwCBEs%2FSKsKS9G62LpIM%3Dreserved=0. >> >> On Thu, Apr 30, 2020 at 8:21 PM Frank Swarbrick >> wrote: >>> I'm asking about the user ID, not the password/pass phrase. But thanks. >>> >>> >>> From: IBM Mainframe Discussion List on behalf of >>> Jesse 1 Robinson >>> Sent: Thursday, April 30, 2020 2:03 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Mainframe user ID length >>> >>> RACF can now handle 'password phrase' of considerable length and/or >>> upper/lower case passwords. If you allow lower case, you can end up with a >>> mess. With traditional upper-only system option, a password typed e.g. via >>> TSO gets automatically translated to upper case with no user notification. >>> With the system option set to lower case allowed, that translation does not >>> occur. This means that every password entry *must* also be lower case. Some >>> logon environments may not allow lower case. Worse, if there is a severe >>> problem that requires fallback to upper only, a user with a lower case >>> password may not be able to logon at all. >>> >>> This is an all or nothing option. Allowing or disallowing lower case >>> affects all environments at the same time. >>> >>> . >>> . >>> 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 On Behalf Of >>> Frank Swarbrick >>> Sent: Thursday, April 30, 2020 12:46 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: (External):Mainframe user ID length >>> >>> CAUTION EXTERNAL EMAIL >>> >>> Is z/OS still limited in all cases to 8 upper case characters? I am >>> curious if a user that only has access to MQ might be able to have a longer >>> and ideally mixed case user ID. They wouldn't have access to TSO or CICS >>> or IMS. >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
TSO used to have a limit of 7. On 2020-04-30 16:43, Mike Schwab wrote: USERID length can be 8. TSO USED to have a limit of 8, with the SYS1.UADS emergency logon adding a digit to access multiple records, and job submission adding a character for the jobname. The 8th character was/is the length in Binary, x'01'-x'07'. Now you can specify an 8 byte TSO USERID, with the 8th character being > x'07'. https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.e0za100%2Fch1tso_23_8char.htmdata=02%7C01%7C%7C57136fbee2814281b18408d7ed47603c%7C84df9e7fe9f640afb435%7C1%7C0%7C637238763120777692sdata=VumiQcDjPdQQ9B1ZFQXiQHRSwCBEs%2FSKsKS9G62LpIM%3Dreserved=0. On Thu, Apr 30, 2020 at 8:21 PM Frank Swarbrick wrote: I'm asking about the user ID, not the password/pass phrase. But thanks. From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, April 30, 2020 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length RACF can now handle 'password phrase' of considerable length and/or upper/lower case passwords. If you allow lower case, you can end up with a mess. With traditional upper-only system option, a password typed e.g. via TSO gets automatically translated to upper case with no user notification. With the system option set to lower case allowed, that translation does not occur. This means that every password entry *must* also be lower case. Some logon environments may not allow lower case. Worse, if there is a severe problem that requires fallback to upper only, a user with a lower case password may not be able to logon at all. This is an all or nothing option. Allowing or disallowing lower case affects all environments at the same time. . . 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 On Behalf Of Frank Swarbrick Sent: Thursday, April 30, 2020 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Mainframe user ID length CAUTION EXTERNAL EMAIL Is z/OS still limited in all cases to 8 upper case characters? I am curious if a user that only has access to MQ might be able to have a longer and ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
My bad. Yeah 8 char userid’s are still the standard but I’d never allocate one more than 7. Sent from Yahoo Mail for iPhone On Thursday, April 30, 2020, 4:02 PM, Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: I looked at SYS1.MACLIB(IHAACEE) ACEEUSER DS 0CL9 USERID INFORMATION ACEEUSRL DS AL1 USERID LENGTH ACEEUSRI DS CL8 CONTAINS THE VALID RACF USERID @02C * UNLESS (1) THE USERID ON THE @02C * VERIFY CALL WAS '*BYPASS*' FOR @02A * AUDITABLE WORK THAT BYPASSES @02A * AUTHORIZATION CHECKING, OR @02A * (2) NO USERID WAS GIVEN SO THE @02A * FIELD CONTAINS AN '*'. @02A Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, April 30, 2020 3:46 PM, Frank Swarbrick wrote: > Is z/OS still limited in all cases to 8 upper case characters? I am curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > > - > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Pass phrases are permitted. For years now. Sent from Yahoo Mail for iPhone On Thursday, April 30, 2020, 3:54 PM, Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: Looks like it. I tried to add a userid with 9 characters, it wouldn't accept it. i didn't try lower case in a batch job, but I'd assume it would be converted to uppercase. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, April 30, 2020 3:46 PM, Frank Swarbrick wrote: > Is z/OS still limited in all cases to 8 upper case characters? I am curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > > - > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
USERID length can be 8. TSO USED to have a limit of 8, with the SYS1.UADS emergency logon adding a digit to access multiple records, and job submission adding a character for the jobname. The 8th character was/is the length in Binary, x'01'-x'07'. Now you can specify an 8 byte TSO USERID, with the 8th character being > x'07'. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0za100/ch1tso_23_8char.htm. On Thu, Apr 30, 2020 at 8:21 PM Frank Swarbrick wrote: > > I'm asking about the user ID, not the password/pass phrase. But thanks. > > > From: IBM Mainframe Discussion List on behalf of > Jesse 1 Robinson > Sent: Thursday, April 30, 2020 2:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Mainframe user ID length > > RACF can now handle 'password phrase' of considerable length and/or > upper/lower case passwords. If you allow lower case, you can end up with a > mess. With traditional upper-only system option, a password typed e.g. via > TSO gets automatically translated to upper case with no user notification. > With the system option set to lower case allowed, that translation does not > occur. This means that every password entry *must* also be lower case. Some > logon environments may not allow lower case. Worse, if there is a severe > problem that requires fallback to upper only, a user with a lower case > password may not be able to logon at all. > > This is an all or nothing option. Allowing or disallowing lower case affects > all environments at the same time. > > . > . > 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 On Behalf Of > Frank Swarbrick > Sent: Thursday, April 30, 2020 12:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Mainframe user ID length > > CAUTION EXTERNAL EMAIL > > Is z/OS still limited in all cases to 8 upper case characters? I am curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Thanks. From: IBM Mainframe Discussion List on behalf of Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> Sent: Thursday, April 30, 2020 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Looks like it. I tried to add a userid with 9 characters, it wouldn't accept it. i didn't try lower case in a batch job, but I'd assume it would be converted to uppercase. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, April 30, 2020 3:46 PM, Frank Swarbrick wrote: > Is z/OS still limited in all cases to 8 upper case characters? I am curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > > - > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
I'm asking about the user ID, not the password/pass phrase. But thanks. From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, April 30, 2020 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length RACF can now handle 'password phrase' of considerable length and/or upper/lower case passwords. If you allow lower case, you can end up with a mess. With traditional upper-only system option, a password typed e.g. via TSO gets automatically translated to upper case with no user notification. With the system option set to lower case allowed, that translation does not occur. This means that every password entry *must* also be lower case. Some logon environments may not allow lower case. Worse, if there is a severe problem that requires fallback to upper only, a user with a lower case password may not be able to logon at all. This is an all or nothing option. Allowing or disallowing lower case affects all environments at the same time. . . 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 On Behalf Of Frank Swarbrick Sent: Thursday, April 30, 2020 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Mainframe user ID length CAUTION EXTERNAL EMAIL Is z/OS still limited in all cases to 8 upper case characters? I am curious if a user that only has access to MQ might be able to have a longer and ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. -- 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: Mainframe user ID length
On 4/30/2020 1:03 PM, Jesse 1 Robinson wrote: RACF can now handle 'password phrase' of considerable length and/or upper/lower case passwords. If you allow lower case... All true, but he was asking about userids, not passwords... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
RACF can now handle 'password phrase' of considerable length and/or upper/lower case passwords. If you allow lower case, you can end up with a mess. With traditional upper-only system option, a password typed e.g. via TSO gets automatically translated to upper case with no user notification. With the system option set to lower case allowed, that translation does not occur. This means that every password entry *must* also be lower case. Some logon environments may not allow lower case. Worse, if there is a severe problem that requires fallback to upper only, a user with a lower case password may not be able to logon at all. This is an all or nothing option. Allowing or disallowing lower case affects all environments at the same time. . . 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 On Behalf Of Frank Swarbrick Sent: Thursday, April 30, 2020 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Mainframe user ID length CAUTION EXTERNAL EMAIL Is z/OS still limited in all cases to 8 upper case characters? I am curious if a user that only has access to MQ might be able to have a longer and ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
I looked at SYS1.MACLIB(IHAACEE) ACEEUSER DS0CL9 USERID INFORMATION ACEEUSRL DSAL1 USERID LENGTH ACEEUSRI DSCL8 CONTAINS THE VALID RACF USERID @02C * UNLESS (1) THE USERID ON THE @02C * VERIFY CALL WAS '*BYPASS*' FOR @02A * AUDITABLE WORK THAT BYPASSES @02A * AUTHORIZATION CHECKING, OR @02A * (2) NO USERID WAS GIVEN SO THE @02A * FIELD CONTAINS AN '*'. @02A Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, April 30, 2020 3:46 PM, Frank Swarbrick wrote: > Is z/OS still limited in all cases to 8 upper case characters? I am curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > > - > > 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: Mainframe user ID length
Looks like it. I tried to add a userid with 9 characters, it wouldn't accept it. i didn't try lower case in a batch job, but I'd assume it would be converted to uppercase. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, April 30, 2020 3:46 PM, Frank Swarbrick wrote: > Is z/OS still limited in all cases to 8 upper case characters? I am curious > if a user that only has access to MQ might be able to have a longer and > ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. > > - > > 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
Mainframe user ID length
Is z/OS still limited in all cases to 8 upper case characters? I am curious if a user that only has access to MQ might be able to have a longer and ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
