Catalog lookup for non-standard datasets doesn't work. I am sure if you want to code volsers for everything you can use it. The link provided earlier indicates SVC 26 is going to have problems with the non-standard data set name(s) and that is just the beginning of the issues.
I agree that the eight character TSO user ID is an artifice that should be "done away with"... but then I have always thought it was weird and a bit short-sighted. There were a some fixes back in the OS/390 days to enforce 7 character user IDs... I know because I was using 8 character jobnames/user IDs and ran into CLIST coding problems. I don't have a lot of hope about getting rid of it. Probably be just as easy to get rid of TSO. Rob Schramm Senior Systems Consultant Imperium Group On Tue, Dec 27, 2011 at 2:16 PM, McKown, John <[email protected] > wrote: > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Donald Zeunert > > Sent: Tuesday, December 27, 2011 12:42 PM > > To: [email protected] > > Subject: Re: Eight-character TSO Userid Support > > > > Re: Eight-character TSO Userid Support > > > > One item that has not been mentioned. The 7 char TSO userid > > was so that when you submit batch jobs it automatically > > appended 1 char to make a unique jobname to execute. If your > > TSOID is 8 then and you submitted a batch job it would either > > have to have > 8 char jobname, same and you'd have to logoff > > for it to run, or something not associated w/ your userid > > which would require SDSF or 3rd party spool product RACF > > (SAF) rules to allow you to view it. If jobname becomes > 8 > > that impacts lots of SMF records, RACF(SAF) rules, and lets > > not forget the 80 character punch card limitation for those > > pushing for 24 char userids. I know some sites already use > > TSO batch job names w/o TSOID prefix, but these are still 8 > > char names that need to be unique. > > We don't run unique 8 character job names. In the current JES2, at least, > there is a parameter for each JOBCLASS, DUPL_JOB. A value of NODELAY allows > multiple jobs with the same name to run in that class in different > initiators at the same time. We used this for recall job names when we ran > Mobius. The default for DUPL_JOB is DELAY. I run multiple SSH sessions to a > single z/OS image. They all have the same "job name", which is my RACF id. > I have also tested, in z/OS 1.12, being logged onto two separate z/OS > images in the same JES2 MAS & SYSPLEX using the same RACF id. I.e. in SDSF > DA OTSU, my RACF id showed up twice with different TSU numbers, one on each > system. > > I'm not arguing for or against 8 character TSO ids. I, personally, don't > much care. I understand the historical reasons for the restriction. And the > current impact it would have to change. I'm not convinced that the cost of > changing the code would be worth the one extra character. Now, if we start > talking about an "unlimited" length for ids and jobnames, then I can see > some possibilities. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets® > > 9151 Boulevard 26 . N. Richland Hills . TX 76010 > (817) 255-3225 phone . > [email protected] . www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. HealthMarkets® is the brand name for products underwritten and > issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake > Life Insurance Company®, Mid-West National Life Insurance Company of > TennesseeSM and The MEGA Life and Health Insurance Company.SM > > > > ---------------------------------------------------------------------- > 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
