> 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 [[email protected]] on behalf of Timothy Sipples [[email protected]] Sent: Wednesday, May 6, 2020 1:45 AM To: [email protected] 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: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
