The requirement for a leading alphabetic/national character in so many MVS names is not a myth. It's baked into myriad processes where a user specifies a name. Using a programmatic interface, you can create almost any (for example) member name subject to the eight-character limit. But most user interfaces will disallow a non-standard name on, say, an ISPF panel.
We used to see weird member names in the old SMP (pre-E) environment. They even had non-alpha non-numeric 'characters'. These names were created and managed by SMP itself. Even now SVC modules may contain non-alpha characters. None of this negates the standard name rules. It really is true that exception(s) prove the rules. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, September 15, 2016 2:36 PM To: [email protected] Subject: (External):Re: TSO User ID Rules (Was: z/OS and code pages) On Thu, 15 Sep 2016 07:01:42 -0400, John Eells wrote: > >The MVS restriction stems from the need to name PDS members starting >with an alphabetic or national character, as all users were originally > That "need" is largely a superstition. Consider the following from an ISPF member list, retouched only to obfuscate HLQ. DSLIST User.TEMP.MIXED.CASE.LINKLIB Row 0000001 of 0000013 Command ===> Scroll ===> CSR Name Prompt Alias-of Size TTR AC AM RM _________ .FooBar 00000008 000117 00 24 24 _________ +1 00000008 000127 00 24 24 _________ $FooBar 00000008 00010F 00 24 24 _________ Foo.Bar 00000008 000211 00 24 24 _________ Foo+Bar 00000008 000137 00 24 24 _________ Foo$Bar 00000008 000219 00 24 24 _________ Foo*Bar 00000008 000147 00 24 24 _________ Foo-Bar 00000008 00013F 00 24 24 _________ Foo/Bar 00000008 000201 00 24 24 _________ Foo_Bar 00000008 00012F 00 24 24 _________ Foo=Bar 00000008 000209 00 24 24 _________ 0FooBar 00000008 000107 00 24 24 _________ 1234 00000008 00011F 00 24 24 **End** All generated by a common z/OS utility with documented options. No assembler, Rexx, or user written code; only control statements. I'll grant that some of these member names might be problematic when used with some facilities such as JCL or UNIX shell. >represented by one or more members of the User Attribute Data Set >(UADS). User IDs defined in RACF today can also be defined in UADS, >so the restriction remains. > >The 7-character length restriction comes from the same source. Users >in UADS have one or more members in that data set, depending on its >block size and the number of attributes in their user entries. The >last character is numeric, so someone with a lot of attributes might >have UADS members USERID0-USERID9. This causes the last character to >be "reserved," and as PDS members may have 1-8 character names, TSO/E >user IDs can be 1-7 characters in length. > So why not relax the 7 character restriction for customers who are willing to commit to relying on RACF and forgoing UADS? ISPF and TSO SUBMIT don't require a user ID prefix. I rarely use that; 8 characters are too precious to squander on redundant information. The TSO OUTPUT command? How many still rely on that in preference to SDSF or (E)JES. I suppose one at each site. Sigh. Does the SMP/E interactive "Command Generation" still issue "OUTPUT" after submitting a job? It won't find mine. On Thu, 15 Sep 2016 12:09:12 -0500, Tom Marchant wrote: >On Thu, 15 Sep 2016 14:41:20 +0800, Timothy Sipples wrote: >>The O in TSO is "Option," after all. > >Yes, AFAIK TSO is still an acronym for Time Sharing Option. Big deal. >TSO was an option for OS/MVT. It never was an option for MVS. > Right! Imagine the reaction from significant customers if IBM were to announce that the follow-on to z/OS 2.2 would eliminate TSO or even make it a separately (highly) priced option. But some might benefit by eliminating TSO from most LPARs. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
