Re: Eight-character TSO Userid Support
Yea, I complained about beling allowed to create the segment only to have it ignored and wondered why I wasn't warned when I defined it. I was politely pointed to the: IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED ... as my warning/error message. I believe that RACF should fail the RDEF attempt. But some disagree. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Friday, December 30, 2011 3:13 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Eight-character TSO Userid Support On 12/27/2011 12:29 PM, McKown, John wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. USER=LONGUSER NAME=LONG USERID OWNER=SYS1 CREATED=11.364 DEFAULT-GROUP=DEV PASSDATE=00.000 PASS-INTERVAL=180 PHRASEDATE=N/A ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE LAST-ACCESS=UNKNOWN CLASS AUTHORIZATIONS=NONE NO-INSTALLATION-DATA NO-MODEL-NAME LOGON ALLOWED (DAYS) (TIME) - ANYDAY ANYTIME GROUP=DEV AUTH=USE CONNECT-OWNER=SYS1 CONNECT-DATE=11.364 CONNECTS=00 UACC=NONE LAST-CONNECT=UNKNOWN CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE SECURITY-LEVEL=NONE SPECIFIED CATEGORY-AUTHORIZATION NONE SPECIFIED SECURITY-LABEL=NONE SPECIFIED TSO INFORMATION --- ACCTNUM= 1 HOLDCLASS= T JOBCLASS= A MSGCLASS= T PROC= TSOLOGON SIZE= MAXSIZE= SYSOUTCLASS= T USERDATA= -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
Peter Relson wrote on 12/27/2011 4:49 AM: What PARMLIB member is it that allows8 characters between periods? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1 As Paul Gilmartin posted, this is a reference to: MODIFY CATALOG,DISABLE(DSNCHECK) FWIW, I wouldn't bet that most z/OS componentry pays attention to this. Back when I was working at the University of Southern California, which ran many different operating systems, I submitted a REQUEST (essentially a single-customer version of a SHARE requirement) with the following core: Allow, at installation option, relaxation of most restrictions on MVS dsnames catalloged in ICF catalogs. IBM should create an installation-replaceable dsname validity checking routine, supplied in source form. All MVS components which validity check dsnames should call this routine. After a two-hour conference call with the managers of a number of MVS components, their managers, and their managers, IBM gave USC the official response That's a reaonable request but we're not going to do it. When pressed for why not?, eventually IBM told us that it's because there were upwards of a hundred different places that all did dsname checking. That was the whole point of the REQUEST- centralize it into one place. Apparently 25 years later we're still no closer to having it done right. I was willing to let IBM piece-meal it, if they would just create the routine and then accept and fix apars opened against each component which didn't call that routine. IBM was not interested in any way. A few years later USC got rid of the MVS system. Every other system except VM/CMS allowed nearly unrestricted dsnames. This may not have been the cause of USC ditching the MVS system, but it was emblematic of perceived user-unfriendliness of the system. Most user-unfriendliness of MVS can be masked by ISPF and REXX wrappers. The dsname problem can't be. IBM really needs to implement the routine that I asked for; there's simply excuse for the same function to be independently coded in 100+ different places. It might be entertaining to try if you can make sure not to pollute your existing catalogs The support says only that it will allow you to create data sets (it does not actually say that you can necessarily use them wherever you'd want to use them). And it even warns you that you may not be able to remove them from the catalog.. If there are catalog entries stuck in a catalog, one can use the CatalogRecoveryPlus or Advanced Catalog Management MERGECAT command to move the records to a junk catalog and then just delete the junk catalog. I'll admit that I didn't even know that this option existed. I know of many places that validate data set names that have no knowledge of the state of this option. See above. Please. Please. Please. Fixing all of those many places is absolutely the wrong way to go. Create the central callable routine, and change everything to call it. Peter Relson z/OS Core Technology Design /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On 12/30/2011 2:25 PM, Paul Gilmartin wrote: Good question. How would he get the notification? But did you try: o ftp MVS user LONGUSER password quote site FILE=JES put ...? o //STEP EXEC PGM=IKJEFT01 with that owner? (possibly in the job submitted via FTP) I used FTP PUT to send the following: //LONGUSER JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=SYSUID // EXEC PGM=IKJEFT01,REGION=64M //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * LISTA STA HI // As it should, the job received a JCL error indicating NOTIFY was too long: IEF642I EXCESSIVE PARAMETER LENGTH IN THE NOTIFY FIELD Once I removed that, the job ran to completion exactly as expected: IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED READY LISTA STA HI --DSORG--CREATED-EXPIRES-SECURITY--DDNAME---DISP-- LONGUSER.LONGUSER.J0256439.D00A.? SYSTSPRT DELETE IKJ58300I HISTORY NOT AVAILABLE+ IKJ58300I LOCATE ERROR CODE 08 LONGUSER.LONGUSER.J0256439.D009.? SYSTSIN DELETE IKJ58300I HISTORY NOT AVAILABLE+ IKJ58300I LOCATE ERROR CODE 08 READY END - Invoke ISPF LM services under that TMP? ISPF LM services should work fine. They don't depend on TSO services. o ssh LONGUSER@MVS then, in Rexx, address TSO time ./timerexx IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED IKJ56650I TIME-04:44:34 PM. CPU-00:00:00 SERVICE-268 SESSION-00:00:00 DECEMBER 31,2011 -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On 12/27/2011 12:29 PM, McKown, John wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. USER=LONGUSER NAME=LONG USERID OWNER=SYS1 CREATED=11.364 DEFAULT-GROUP=DEV PASSDATE=00.000 PASS-INTERVAL=180 PHRASEDATE=N/A ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE LAST-ACCESS=UNKNOWN CLASS AUTHORIZATIONS=NONE NO-INSTALLATION-DATA NO-MODEL-NAME LOGON ALLOWED (DAYS) (TIME) - ANYDAY ANYTIME GROUP=DEV AUTH=USE CONNECT-OWNER=SYS1 CONNECT-DATE=11.364 CONNECTS=00 UACC=NONE LAST-CONNECT=UNKNOWN CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE SECURITY-LEVEL=NONE SPECIFIED CATEGORY-AUTHORIZATION NONE SPECIFIED SECURITY-LABEL=NONE SPECIFIED TSO INFORMATION --- ACCTNUM= 1 HOLDCLASS= T JOBCLASS= A MSGCLASS= T PROC= TSOLOGON SIZE= MAXSIZE= SYSOUTCLASS= T USERDATA= -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
W dniu 2011-12-30 22:12, Edward Jaffe pisze: On 12/27/2011 12:29 PM, McKown, John wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. USER=LONGUSER NAME=LONG USERID OWNER=SYS1 CREATED=11.364 [...] TSO INFORMATION [...] Did you try to logon to TSO with that user? ;-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
R.S. wrote: W dniu 2011-12-30 22:12, Edward Jaffe pisze: On 12/27/2011 12:29 PM, McKown, John wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. USER=LONGUSER NAME=LONG USERID OWNER=SYS1 CREATED=11.364 [...] TSO INFORMATION [...] Did you try to logon to TSO with that user? ;-) Did you try to NOTIFY= that user? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Fri, 30 Dec 2011 16:41:21 -0500, Bob Rutledge wrote: R.S. wrote: W dniu 2011-12-30 22:12, Edward Jaffe pisze: On 12/27/2011 12:29 PM, McKown, John wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. USER=LONGUSER NAME=LONG USERID OWNER=SYS1 CREATED=11.364 [...] TSO INFORMATION [...] Did you try to logon to TSO with that user? ;-) Did you try to NOTIFY= that user? Good question. How would he get the notification? But did you try: o ftp MVS user LONGUSER password quote site FILE=JES put ...? o //STEP EXEC PGM=IKJEFT01 with that owner? (possibly in the job submitted via FTP) - Invoke ISPF LM services under that TMP? o ssh LONGUSER@MVS then, in Rexx, address TSO time -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
EJ, you have successfully answered an alternate version of the question Can a swimmer dive into deep water with 100 pounds of concrete strapped to his waist? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Friday, December 30, 2011 3:13 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Eight-character TSO Userid Support On 12/27/2011 12:29 PM, McKown, John wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. USER=LONGUSER NAME=LONG USERID OWNER=SYS1 CREATED=11.364 DEFAULT-GROUP=DEV PASSDATE=00.000 PASS-INTERVAL=180 PHRASEDATE=N/A ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE LAST-ACCESS=UNKNOWN CLASS AUTHORIZATIONS=NONE NO-INSTALLATION-DATA NO-MODEL-NAME LOGON ALLOWED (DAYS) (TIME) - ANYDAY ANYTIME GROUP=DEV AUTH=USE CONNECT-OWNER=SYS1 CONNECT-DATE=11.364 CONNECTS=00 UACC=NONE LAST-CONNECT=UNKNOWN CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE SECURITY-LEVEL=NONE SPECIFIED CATEGORY-AUTHORIZATION NONE SPECIFIED SECURITY-LABEL=NONE SPECIFIED TSO INFORMATION --- ACCTNUM= 1 HOLDCLASS= T JOBCLASS= A MSGCLASS= T PROC= TSOLOGON SIZE= MAXSIZE= SYSOUTCLASS= T USERDATA= -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
Paul Gilmartin wrote: On Fri, 30 Dec 2011 16:41:21 -0500, Bob Rutledge wrote: R.S. wrote: W dniu 2011-12-30 22:12, Edward Jaffe pisze: On 12/27/2011 12:29 PM, McKown, John wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. USER=LONGUSER NAME=LONG USERID OWNER=SYS1 CREATED=11.364 [...] TSO INFORMATION [...] Did you try to logon to TSO with that user? ;-) Did you try to NOTIFY= that user? Good question. How would he get the notification? But did you try: o ftp MVS user LONGUSER password quote site FILE=JES put ...? o //STEP EXEC PGM=IKJEFT01 with that owner? (possibly in the job submitted via FTP) - Invoke ISPF LM services under that TMP? o ssh LONGUSER@MVS then, in Rexx, address TSO time He won't get the notification because the notifier suffers an immediate IEF452I / IKJ142I. Don't you just love JCL? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
W dniu 2011-12-28 01:16, Paul Gilmartin pisze: On Tue, 27 Dec 2011 23:36:48 +0100, R.S. wrote: SUBMIT adds a character only if the job text does not contain JOB statement. IMHO submitting jobs without JOB statement is quick and DIRTY method. Very dirty. It can be easily changed to allow 8-char userids (add 1 charecter OR change eight character with random one). Of course, requiring that job names begin with the user ID is the only way to almost guarantee that job names are unique. Of course it's not. One can imagine other naming conventions. But even nowadays is there anything to prevent my submitting a job not with the TSO SUBMIT command (e.g. via FTP or by writing directly to INTRDR) that has your user ID as a prefix? Fortunately there is JESJOBS class which protects jobnames. You can easily set up the rule everything is allowed with exception to reserverd names. No need to prefix jobnames with userid. Is there anything except the good conscience of the admin to prevent creating two user IDs where the second is the first with a single character appended? Naming convention, you can call it good conscience ;-) Last, but not least: does anyone remember that userid can begin with numeric? A user name 1234567 is legal one. Obviously TSO segment for such userid is still big problem. Simply because of DSN prefixing, or are there other concerns? Yes. Some irony missed. ;-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
Hi, As far as I remember 8 char TSO userids are available when MVS is used with VM/XMAS under an augmented universe but only if you use the Undocumented Feature Option and the System Transition Application Real Generic Access Tool Environment. Otherwise I think the chance for metric to be used in the USA are better. The manual for intellectual self defense tells that neither the ability of using arbitrary length ids elsewhere nor seeing anything else that doesn't tell anything positive doesn't make a working feature a bad one. I'd rather see an IPL being faster, etc. usual seasonal greetings :-) Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Wed, 28 Dec 2011 10:42:16 +0100, Peter Sylvester wrote: I'd rather see an IPL being faster, etc. But re-read the OP. They is contending with Company Policy. http://www.thealders.net/humour/work/wk49.html -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Tue, 27 Dec 2011 23:36:48 +0100, R.Skorupka wrote: SUBMIT adds a character only if the job text does not contain JOB statement. IMHO submitting jobs without JOB statement is quick and DIRTY method. Very dirty. It can be easily changed to allow 8-char userids (add 1 charecter OR change eight character with random one). SUBMIT also adds a character if a JOB statement is present and the jobname is the userid. It will do so multiple times if there is more than one such JOB statement in the dataset being submitted, with a separate prompt for each job if prompting is used. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Tue, 27 Dec 2011 14:29:12 -0600, McKown, John john.mck...@healthmarkets.com wrote: A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. So they cannot be used to logon to TSO. If you try, you get a message of some sort from the TSO logon process. They can be used for batch jobs, UNIX shell accounts, ftp accounts, CICS logons, and probably others (like DB2 and IMS, but I don't know). Actually, a user with an 8-character user ID should be able to have a TSO segment, John. I'm not aware of anything that would prevent that, unless possibly it's something related to creation of the segment trying to add the user to SYS1.BRODCAST. If you've configured TSO/E to use user brodcast data sets even that should not be a problem. But you're right, they would not be able to logon to TSO. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
-Original Message- snip I can also live without OUTPUT. SDSF is better. What's ISPF 3.8? I think we're using a newer release than 3.8. ISPF option 3.8 is the OUTLIST UTILITY. It is an ISPF interface to the old FIB (Foreground Initiated Background) commands of CANCEL, OUTPUT, and STATUS. Probably the least used function in ISPF. On Tue, 27 Dec 2011 02:21:46 -0600, John McKown wrote: Everybody else where I work uses only SDSF. I'm weird grin. I like to use a UNIX shell a bit. And I use Dovetailed Technologies' fromdsn command to copy SPOOL output to a UNIX file. I use the tsocmd command to purge the job output (CANCEL ... PURGE). I'm thinking of trying to write an rmjes command just to have a UNIXy way to purge output. And because using TSO commands from the UNIX shell just irritates me. Do you likewise shun the Rexx interface to SDSF? -- gil Not really. I do many things for my own amusement when I can. Also, if I write an HLASM rmjes command, it will be more CPU efficient than using the REXX API for SDSF. Most don't care about this. My shop does. Of course, this is why the majority of my code writing and testing is done on Sundays. There is nothing else going on. And we have already maxed the MSU usage for the month, so my messing around doesn't matter, cost wise. Not that anybody here is going to use this, other than perhaps myself. Right now, I'm working on an HLASM lsenq command to display ENQ information. It is based on what the QUERYENQ program does for REXX. But it will be using the ISGQUERY interface instead of GQSCAN. Writing UNIX code in HLASM is more difficult, for me, than batch or TSO. Likely due to my ignorance. No C compiler here. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * 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(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Tue, 27 Dec 2011 07:49:31 -0500, Peter Relson wrote: What PARMLIB member is it that allows 8 characters between periods? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1 As Paul Gilmartin posted, this is a reference to: MODIFY CATALOG,DISABLE(DSNCHECK) There's precious little further documentation I can find. Is all syntax checking removed? Is even the HLQ allowed to exceed 8 characters? Some people suspect that this was an unintended consequence of removing all syntax checking when CVOLs were supplanted. After the product was in the field, some customers complained that programmers were cataloging DSNs that couldn't readily be manipulated with customary utilities. IBM discovered or at least suspected that other customers were actively exploiting the feature and had little choice but to provide an option. I'll admit that I didn't even know that this option existed. I know of many places that validate data set names that have no knowledge of the state of this option. You could likely start the list with the JCL R/C/I. What if JCL were DSNCHECK-savvy but the submitting and executing systems had different states of this option? You know me; I'd insist that lacking such knowledge, JES should presume the least restrictive setting. On Tue, 27 Dec 2011 00:54:58 -0500, Robert A. Rosenberg wrote: Likewise, in days of yore, but no longer, one DSN was not allowed to be a prefix of another, such as: GUBBINS.WOMBATversus GUBBINS.WOMBAT.FUBAR This was due to CVOL Support. Each level was a set of chained records and WOMBAT as a File name conflicted with it being a record containing a pointer to another level. Much analogous to the UNIX behavior where a name may not refer to both a directory and a basefile. On Tue, 27 Dec 2011 01:08:04 -0500, Robert A. Rosenberg wrote: The problem with allowing TSO to use 8 Character USERIDs is that it makes some TSO commands fail. Jobnames are 8 characters max. Submit (at least ISPF Automatic Submit) adds a one character suffix to the UserID and thus breaks if the UserID is 8 Characters (since that I can live without SUBMIT. It's easy enough to write directly to INTRDR with an Edit macro. And I submit most of my jobs with FTP. Even when I use ISPF SUBMIT, somehow my jobs do not come out as UserID+1. Something in my profile for which I'm grateful. I have better use for the scant 8 characters in the JOBNAME than telling me my UserID that I already know. ... Also OUTPUT would result in an invalid length 9 character JOBNAME). Also OUTPUT (used by ISPF 3.8) validates that the JOBNAME is UserID+1_Character and thus would not be able to handle 8 character UserIDs. I can also live without OUTPUT. SDSF is better. What's ISPF 3.8? I think we're using a newer release than 3.8. On Tue, 27 Dec 2011 02:21:46 -0600, John McKown wrote: Everybody else where I work uses only SDSF. I'm weird grin. I like to use a UNIX shell a bit. And I use Dovetailed Technologies' fromdsn command to copy SPOOL output to a UNIX file. I use the tsocmd command to purge the job output (CANCEL ... PURGE). I'm thinking of trying to write an rmjes command just to have a UNIXy way to purge output. And because using TSO commands from the UNIX shell just irritates me. Do you likewise shun the Rexx interface to SDSF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support:
On Tue, 2011-12-27 at 01:08 -0500, Robert A. Rosenberg wrote: At 10:21 -0800 on 12/26/2011, Edward Jaffe wrote about Re: Eight-character TSO Userid Support:: Application environments are responsible for supporting whatever the current architected userid length is. It has been asserted that TSO is the only z/OS application environment in 2011 (soon 2012) that can't handle that fundamental requirement. I'm trying to discover if that's a true statement. None of the responses I've received thus-far have offered anything to disprove that assertion. If true, fixing TSO will provide *complete* eight-character userid support for z/OS. The problem with allowing TSO to use 8 Character USERIDs is that it makes some TSO commands fail. Jobnames are 8 characters max. Submit (at least ISPF Automatic Submit) adds a one character suffix to the UserID and thus breaks if the UserID is 8 Characters (since that would result in an invalid length 9 character JOBNAME). Also OUTPUT (used by ISPF 3.8) validates that the JOBNAME is UserID+1_Character and thus would not be able to handle 8 character UserIDs. I would think that the TSO SUBMIT could be gotten around rather easily, for IBM. But due to OCO might be a bit difficult for the average shop. Especially if they are like where I work. We don't do exits very much any more. If it is not customizable via PARMLIB or an options type module, then it cannot be done at all. We do use the IKJEFF53 exit to allow users to do OUTPUT / STATUS / CANCEL of jobs which do not conform to the userid+1 job name restriction. Not that anybody in our shop ever uses those commands, other than myself on rare occasion. We secure jobs using SAF/RACF with JESJOBS and JESSPOOL profiles. This exit would likely go away if anybody really knew that it existed. Everybody else where I work uses only SDSF. I'm weird grin. I like to use a UNIX shell a bit. And I use Dovetailed Technologies' fromdsn command to copy SPOOL output to a UNIX file. I use the tsocmd command to purge the job output (CANCEL ... PURGE). I'm thinking of trying to write an rmjes command just to have a UNIXy way to purge output. And because using TSO commands from the UNIX shell just irritates me. -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
What PARMLIB member is it that allows 8 characters between periods? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1 As Paul Gilmartin posted, this is a reference to: MODIFY CATALOG,DISABLE(DSNCHECK) FWIW, I wouldn't bet that most z/OS componentry pays attention to this. It might be entertaining to try if you can make sure not to pollute your existing catalogs The support says only that it will allow you to create data sets (it does not actually say that you can necessarily use them wherever you'd want to use them). And it even warns you that you may not be able to remove them from the catalog.. I'll admit that I didn't even know that this option existed. I know of many places that validate data set names that have no knowledge of the state of this option. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
I'd be curious to know how to use this. I just tried on my sandbox system, and didn't get the expected results. With or without the catalog command I can create non-standard Dataset names using quotes, but then SMS complains, and it doesn't get cataloged. Allocate it on non-sms DASD, and I still cannot open it. The following 1) IKJ56231I FILE ISP09537 NOT ALLOCATED, SYSTEM OR INSTALLATION ERROR+ 2) IKJ56231I TEXT UNIT X'0002' CONTAINS INVALID PARAMETER _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, December 27, 2011 9:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Eight-character TSO Userid Support On Tue, 27 Dec 2011 07:49:31 -0500, Peter Relson wrote: What PARMLIB member is it that allows 8 characters between periods? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6 .5.1 As Paul Gilmartin posted, this is a reference to: MODIFY CATALOG,DISABLE(DSNCHECK) There's precious little further documentation I can find. Is all syntax checking removed? Is even the HLQ allowed to exceed 8 characters? Some people suspect that this was an unintended consequence of removing all syntax checking when CVOLs were supplanted. After the product was in the field, some customers complained that programmers were cataloging DSNs that couldn't readily be manipulated with customary utilities. IBM discovered or at least suspected that other customers were actively exploiting the feature and had little choice but to provide an option. I'll admit that I didn't even know that this option existed. I know of many places that validate data set names that have no knowledge of the state of this option. You could likely start the list with the JCL R/C/I. What if JCL were DSNCHECK-savvy but the submitting and executing systems had different states of this option? You know me; I'd insist that lacking such knowledge, JES should presume the least restrictive setting. On Tue, 27 Dec 2011 00:54:58 -0500, Robert A. Rosenberg wrote: Likewise, in days of yore, but no longer, one DSN was not allowed to be a prefix of another, such as: GUBBINS.WOMBATversus GUBBINS.WOMBAT.FUBAR This was due to CVOL Support. Each level was a set of chained records and WOMBAT as a File name conflicted with it being a record containing a pointer to another level. Much analogous to the UNIX behavior where a name may not refer to both a directory and a basefile. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Tue, 27 Dec 2011 08:18:44 -0600, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 27 Dec 2011 07:49:31 -0500, Peter Relson wrote: What PARMLIB member is it that allows 8 characters between periods? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1 As Paul Gilmartin posted, this is a reference to: MODIFY CATALOG,DISABLE(DSNCHECK) There's precious little further documentation I can find. Is all syntax checking removed? Is even the HLQ allowed to exceed 8 characters? As far as I can tell from looking at the code, yes, all syntax checking is removed. With the option disabled the routine that is preparing to write the new catalog entry bypasses calling the subroutine that would perform the syntax check (overall length, character content, node length, etc.). Technically that should allow any name to be cataloged. Of course, I can't tell what other checking might precede that routine as I don't know the catalog code very well. Of course, it's always been possible to have uncataloged names that violated most of the rules, but this seems to make it possible to catalog those names, too. I have no idea what would happen if the name exceeded 44 characters. Nor what would happen if the first node exceeded 8 characters (though I might guess that it could work, as long as the user had authority to update the master catalog). And, of course, if any security checking occurs you'd find that RACF is one of those components that has no idea about this option, and so would apply its normal rules, but things might work OK if either SETROPTS PROTECTALL(NOFAIL or WARNING) is in effect, or if one has appropriate RACF profiles defined. (Appropriate profiles: RACF will normally require that each qualifier (node) of the name have a length = 8, but a * that ends the profile name (non-EGN), or a ** that ends the profile name (EGN), will handle qualifiers longer than 8. Still, in the absence of a naming convention table RACF will expect the first qualifier to be = 8 characters, and to match a user ID or group name.) But remember that these considerations would also apply to anyone trying to create uncataloged data sets, so it's not really related to this catalog option. Some people suspect that this was an unintended consequence of removing all syntax checking when CVOLs were supplanted. After the product was in the field, some customers complained that programmers were cataloging DSNs that couldn't readily be manipulated with customary utilities. IBM discovered or at least suspected that other customers were actively exploiting the feature and had little choice but to provide an option. As far as I can see, the option has existed since 2000 or 2002, though I get a bit confused as I look at the source: it appears that the option was created in 2000 but that the code to bypass the syntax checking was added in 2002, though it all seems associated with FMID HDZ11G0. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Mon, 26 Dec 2011 09:00:56 -0600, Paul Gilmartin paulgboul...@aim.com wrote: There's a PARMLIB option that allows the use of far more than 36 (39?) (40?) and removes the 1-8 character blocking requirement. What option provides that flexibility? -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
In CAPD5F5pYX1tLyY6Nirbfs_1iwYj=nq01cq2fceqwzjqfzrg...@mail.gmail.com, on 12/26/2011 at 10:41 AM, John Gilmore johnwgilmore0...@gmail.com said: that left-to-right index-level repetitions, as in SYS1.SYS1. . . . are interdicted. Since when? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donald Zeunert Sent: Tuesday, December 27, 2011 12:42 PM To: IBM-MAIN@bama.ua.edu 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 . john.mck...@healthmarkets.com . 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
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 john.mck...@healthmarkets.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donald Zeunert Sent: Tuesday, December 27, 2011 12:42 PM To: IBM-MAIN@bama.ua.edu 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 . john.mck...@healthmarkets.com . 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Tue, 27 Dec 2011 10:42:02 -0800, Donald Zeunert wrote: 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. This topic entirely mystifies me. I'm looking at the SDSF STATUS display which shows me 123 of my jobs (I need to clean up). Of these, 110 do _not_ begin with my userid, including one which I just submitted with the SUBMIT primary command from an ISPF VIEW panel. 13 do begin with my user ID, including my TSO session and several that I recall submitting other than from a TSO/ISPF SUBMIT command. I don't know why people entertain this fantasy of a UserID+1 job name rule and use it as a refutation of the possibility of 8-character userids. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, December 27, 2011 2:05 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Eight-character TSO Userid Support On Tue, 27 Dec 2011 10:42:02 -0800, Donald Zeunert wrote: 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. This topic entirely mystifies me. I'm looking at the SDSF STATUS display which shows me 123 of my jobs (I need to clean up). Of these, 110 do _not_ begin with my userid, including one which I just submitted with the SUBMIT primary command from an ISPF VIEW panel. 13 do begin with my user ID, including my TSO session and several that I recall submitting other than from a TSO/ISPF SUBMIT command. I don't know why people entertain this fantasy of a UserID+1 job name rule and use it as a refutation of the possibility of 8-character userids. -- gil A RACF id can be 8 characters. But, in that case, they cannot have a TSO segment. So they cannot be used to logon to TSO. If you try, you get a message of some sort from the TSO logon process. They can be used for batch jobs, UNIX shell accounts, ftp accounts, CICS logons, and probably others (like DB2 and IMS, but I don't know). The userid+1 is a very old restriction which is part of the OUTPUT|CANCEL|STATUS command. But it can be ignored by using TSO exit IKJEFF53. It never applied to SDSF, which uses either the SDSF parms or SAF controls. The TSO submit command, as best as I can tell, only looks at the job name in the JCL being submitted. If the job name is equal to the TSO id, then it either prompts for a unique character to append or appends one itself (depending on the PROFILE PROMPT setting). I submit jobs all the time which don't begin with my RACF id. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
Long ago, when I first stating working as a programmer I worked at a site that did not enforce jobnames to be TSO userid+suffix. I could name the jobs anything I wanted and I used that mostly to keep track of what the test case was. One day, since I could, I named a little test case job COREHOGG. I just thought it was a funny name. The job did not, in fact, use much storage or time. You wouldn't believe the storm of irate phone calls I got during the few minutes the job ran. People assumed that the name was meaningful and how dare I run that during the day shift instead of some weekend in the middle of the night! Needless to say, I did not try any funny names after that. --Roger On Tue, Dec 27, 2011 at 11:42 AM, Donald Zeunert dromega...@yahoo.comwrote: Re: Eight-character TSO Userid Support 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Tue, Dec 27, 2011 at 2:05 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 27 Dec 2011 10:42:02 -0800, Donald Zeunert wrote: 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. This topic entirely mystifies me. I'm looking at the SDSF STATUS display which shows me 123 of my jobs (I need to clean up). Of these, 110 do _not_ begin with my userid, including one which I just submitted with the SUBMIT primary command from an ISPF VIEW panel. 13 do begin with my user ID, including my TSO session and several that I recall submitting other than from a TSO/ISPF SUBMIT command. I don't know why people entertain this fantasy of a UserID+1 job name rule and use it as a refutation of the possibility of 8-character userids. -- gil In TSO ISPF SDSF, you can type SET DISPLAY ON to show your seleciton criteria. You probably have OWNER=userid PREFIX=*. This result is a good bypass to allow 8 character TSO userids. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support:
In p06240804cb1f0f7428fe@[192.168.1.11], on 12/27/2011 at 01:08 AM, Robert A. Rosenberg hal9...@panix.com said: The problem with allowing TSO to use 8 Character USERIDs is that it makes some TSO commands fail. Jobnames are 8 characters max. Submit (at least ISPF Automatic Submit) adds a one character suffix to the UserID and thus breaks if the UserID is 8 Characters SUBMIT uses the job name in the JOB statement if there is one. Also OUTPUT (used by ISPF 3.8) validates that the JOBNAME is UserID+1_Character and thus would not be able to handle 8 character UserIDs. That would be a trivial fix. The hard part would be catching all of the references to prefix and userid in TSO contol blocks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
W dniu 2011-12-27 21:05, Paul Gilmartin pisze: On Tue, 27 Dec 2011 10:42:02 -0800, Donald Zeunert wrote: 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. This topic entirely mystifies me. I'm looking at the SDSF STATUS display which shows me 123 of my jobs (I need to clean up). Of these, 110 do _not_ begin with my userid, including one which I just submitted with the SUBMIT primary command from an ISPF VIEW panel. 13 do begin with my user ID, including my TSO session and several that I recall submitting other than from a TSO/ISPF SUBMIT command. I don't know why people entertain this fantasy of a UserID+1 job name rule and use it as a refutation of the possibility of 8-character userids. SUBMIT adds a character only if the job text does not contain JOB statement. IMHO submitting jobs without JOB statement is quick and DIRTY method. Very dirty. It can be easily changed to allow 8-char userids (add 1 charecter OR change eight character with random one). Last, but not least: does anyone remember that userid can begin with numeric? A user name 1234567 is legal one. Obviously TSO segment for such userid is still big problem. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Tue, 27 Dec 2011 23:36:48 +0100, R.S. wrote: SUBMIT adds a character only if the job text does not contain JOB statement. IMHO submitting jobs without JOB statement is quick and DIRTY method. Very dirty. It can be easily changed to allow 8-char userids (add 1 charecter OR change eight character with random one). Of course, requiring that job names begin with the user ID is the only way to almost guarantee that job names are unique. But even nowadays is there anything to prevent my submitting a job not with the TSO SUBMIT command (e.g. via FTP or by writing directly to INTRDR) that has your user ID as a prefix? Is there anything except the good conscience of the admin to prevent creating two user IDs where the second is the first with a single character appended? Last, but not least: does anyone remember that userid can begin with numeric? A user name 1234567 is legal one. Obviously TSO segment for such userid is still big problem. Simply because of DSN prefixing, or are there other concerns? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On 12/27/2011 8:28 AM, McKown, John wrote: -Original Message- [snip] No C compiler here. John, You've mentioned this frequently. I got to wondering if you can still call the C functions from an LE-enabled Assembler program? Should work, but I'm not sure if there are some cases where it doesn't. -- John McKown Systems Engineer IV IT -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * Special promotion: 15% off on all DB2 training classes scheduled by September 1, taught by year end 2011 * Check out our entire DB2 curriculum at: http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Sun, 2011-12-25 at 23:17 -0500, Robert A. Rosenberg wrote: At 19:20 -0600 on 12/24/2011, Paul Gilmartin wrote about Re: Eight-character TSO Userid Support: Hmmm. How many upper-case alphanumeric characters would be needed to provide unique identifiers for all the files an enterprise would ever need? By that metric, 44(8) is more than sufficient. A dataset name is up to 44 characters long but that is based on a set of 36 characters (26 letters and 10 numbers) CURRENTLY broken up into 1-8 character blocks separated by periods. The 8 character blocks are composed, if I remember correctly of 1 Alpha (A-Z) followed by 0-7 Alpha (A-Z) and Numeric (0-9) characters. There may also be some special characters in addition to the 36 (I forget). Each node is 1 to 8 characters. First character is alphabetic or a national character, of which there are three: @#$ in U.S. The other seven characters may be any of those plus the digits 0 through 9 and a dash (-). The dash threw me, when I first saw it. I don't know when that became legal in a DSN. For GDG Datasets, the limit is 39(8) since the last 9 are required for the .GVyy suffix to the GDG File Base Name. What do you mean by 44(8) anyway? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Mon, 26 Dec 2011 08:00:17 -0600, John McKown wrote: On Sun, 2011-12-25 at 23:17 -0500, Robert A. Rosenberg wrote: At 19:20 -0600 on 12/24/2011, Paul Gilmartin wrote about Re: Eight-character TSO Userid Support: Hmmm. How many upper-case alphanumeric characters would be needed to provide unique identifiers for all the files an enterprise would ever need? By that metric, 44(8) is more than sufficient. A dataset name is up to 44 characters long but that is based on a set of 36 characters (26 letters and 10 numbers) CURRENTLY broken up into 1-8 character blocks separated by periods. The 8 character blocks are composed, if I remember correctly of 1 Alpha (A-Z) followed by 0-7 Alpha (A-Z) and Numeric (0-9) characters. There may also be some special characters in addition to the 36 (I forget). There's a PARMLIB option that allows the use of far more than 36 (39?) (40?) and removes the 1-8 character blocking requirement. Each node is 1 to 8 characters. First character is alphabetic or a national character, of which there are three: @#$ in U.S. The other seven characters may be any of those plus the digits 0 through 9 and a dash (-). The dash threw me, when I first saw it. I don't know when that became legal in a DSN. And it's bizarre. When last I tried it, dash was allowed in the DSN= parameter, but not in the DCB= parameter of the DD statement. Go figger. Conway's law? Has IBM any good reason not to make this specification uniform? It shouldn't take a dammed SHARE requirement. I hate JCL! For GDG Datasets, the limit is 39(8) since the last 9 are required for the .GVyy suffix to the GDG File Base Name. What do you mean by 44(8) anyway? By analogy with the Windows FAT file system limit, often called 8.3. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
The combinatorial problem---How many unique, licit DSNAME values are there?--is easy to solve; one can even get the right answer if one remembers that x'7c', x'5b', x'7b'---They are '@', '#', '$' in the United States---are syntactic majuscules and that left-to-right index-level repetitions, as in SYS1.SYS1. . . . are interdicted. The answers to such questions are, however, irrelevant. DSNs like ZZ9ZPFF5.SH70RDLU.Y22023A4. . . . are as a practical matter unusable in many contexts, as are those that contain embedded instances of obscenities in locally known languages, contextually inappropriate religious terminology, and the like. (SYS1.AMGOT would be offensive to Turkish readers; and an Italian-speaking CIO even objected to the index level ADREM, probably because he thought he was being baited.) Intelligibility requirements and assorted propriety constraints in fact make the usable names a small subset of the name space defined by the syntactic rules, at least when there are people in the loop. (There is a very limited role for otherwise 'barbarous' or offensive DSNs when they are generated for exclusively internal use. People unfortunately find out about them, and they must then be looked for and screened out.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Mon, 26 Dec 2011 10:41:00 -0500, John Gilmore wrote: The combinatorial problem---How many unique, licit DSNAME values are there?--is easy to solve; one can even get the right answer if one Thanks for expounding my perhaps-overly-subtle rhetoric. remembers that x'7c', x'5b', x'7b'---They are '@', '#', '$' in the United States---are syntactic majuscules and that left-to-right index-level repetitions, as in SYS1.SYS1. . . . are interdicted. Are you perhaps recalling a superannuated restriction. As an experiment, I readily created (though with NFS, not JCL nor TSO) 'SYSUID..SYSUID', then viewed it and deleted it with DSLIST. Likewise, in days of yore, but no longer, one DSN was not allowed to be a prefix of another, such as: GUBBINS.WOMBATversus GUBBINS.WOMBAT.FUBAR ..., as are those that contain embedded instances of obscenities in locally known languages, contextually inappropriate religious terminology, and the like. (SYS1.AMGOT would be offensive to Turkish readers; and an (Does FUBAR, as I used above, rise to that level. Ex-military personnel would be most likely to know the reference, and least likely to care. You can't please everybody. If COTFSM were to take exception to MARINARA would we be required to oblige them?) Italian-speaking CIO even objected to the index level ADREM, probably because he thought he was being baited.) ??? Google doesn't help me with that one, Collateral to the initial topic, some installations require password complexity forbidden by z/OS with the objective of portability among the Babel of EBCDIC (need I say it?) code pages. And VM creates problems with passwords containing '@', '#', '', perhaps others. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support:
On 12/24/2011 6:45 AM, John Gilmore wrote: Considerable work will have to be done to eliminate the seven-character TSO userid maximum, and it would be a work wasted if an already obsolescent eight-character maximum replaced it. Userid architecture is the responsibility of the operating system's security system that creates, deletes, maintains and processes them. The current z/OS standard is eight characters as implemented by SAF (RACF, ACF2, TSS, etc). Application environments are responsible for supporting whatever the current architected userid length is. It has been asserted that TSO is the only z/OS application environment in 2011 (soon 2012) that can't handle that fundamental requirement. I'm trying to discover if that's a true statement. None of the responses I've received thus-far have offered anything to disprove that assertion. If true, fixing TSO will provide *complete* eight-character userid support for z/OS. I agree 100% that, when TSO fixes this problem, the developers should design things to allow for longer values in the future (and I suspect they will). But, until such time that SAF actually architects longer userids, that point is moot. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
What PARMLIB member is it that allows 8 characters between periods? I just can't seem to find it. On Mon, 2011-12-26 at 09:00 -0600, Paul Gilmartin wrote: On Mon, 26 Dec 2011 08:00:17 -0600, John McKown wrote: snip There's a PARMLIB option that allows the use of far more than 36 (39?) (40?) and removes the 1-8 character blocking requirement. snip -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
Edward Jaffe wrote: begin snippet It has been asserted that TSO is the only z/OS application environment in 2011 (soon 2012) that can't handle that fundamental requirement. I'm trying to discover if that's a true statement. /end snippet I know of no other, and no one has posted another example here. I strongly suspect, therefore, that there is none. Viewed more generally, however, such propositions are problematic, as I am sure EJ knows. They are variants of universal negatives, e.g., o There are no black swans o All men are mortal that allow of a single exception, e.g., Stygius here is a black swan, but there are no others. They are easy to refute by the production of a single counter-example but impossible to establish in general. In this case, qualified slightly to make it o TSO is the only important z/OS MVS subsystem . . . a strong Bayesian argument that it is true is available. I should bet that it is true, particularly since the availability of the weasel word 'important' would provide me with a way to deal with any inconvenient counter-example that was produced later. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Mon, 26 Dec 2011 16:04:01 -0600, John McKown wrote: What PARMLIB member is it that allows 8 characters between periods? I just can't seem to find it. On Mon, 2011-12-26 at 09:00 -0600, Paul Gilmartin wrote: On Mon, 26 Dec 2011 08:00:17 -0600, John McKown wrote: snip There's a PARMLIB option that allows the use of far more than 36 (39?) (40?) and removes the 1-8 character blocking requirement. I know it's been discussed here; I may misremember the details. Before I posted, I searched publibz; the closest I found was a peripheral mention in: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1 RCF submitted suggesting cross-reference to ??? publication or section. It might have been better just to suggest naming the PARMLIB field. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Mon, 26 Dec 2011 16:04:01 -0600, John McKown wrote: What PARMLIB member is it that allows 8 characters between periods? I just can't seem to find it. (more) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d4a0/1.1.9 When you invoke Dynamic Allocation services or directly invoke SVC 26, it is possible to create data set names that are not valid. When the CATALOG routine is called to add the data set to a catalog, there is no way to determine whether the original name was in JCL or whether quotation marks delimit the name. The catalog component validates the syntax of a data set name and fails the request if the syntax is not valid, unless the syntax-checking option for data set names is off. See the description of the MODIFY CATALOG command's DSNCHECK parameter in z/OS DFSMS Managing Catalogs. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6 MODIFY CATALOG,ENABLE(DSNCHECK) MODIFY CATALOG,DISABLE(DSNCHECK) The MODIFY CATALOG command allows you to alter a number of attributes that are initialized at IPL time. Many of these attributes are initialized by the SYSCATxx member of SYS1.NUCLEUS. Closer, but no Holy Grail. Perhaps it's not in PARMLIB. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
Got it. Thanks! Not at all what I was thinking it might be. On Mon, 2011-12-26 at 17:13 -0600, Paul Gilmartin wrote: On Mon, 26 Dec 2011 16:04:01 -0600, John McKown wrote: What PARMLIB member is it that allows 8 characters between periods? I just can't seem to find it. On Mon, 2011-12-26 at 09:00 -0600, Paul Gilmartin wrote: On Mon, 26 Dec 2011 08:00:17 -0600, John McKown wrote: snip There's a PARMLIB option that allows the use of far more than 36 (39?) (40?) and removes the 1-8 character blocking requirement. I know it's been discussed here; I may misremember the details. Before I posted, I searched publibz; the closest I found was a peripheral mention in: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1 RCF submitted suggesting cross-reference to ??? publication or section. It might have been better just to suggest naming the PARMLIB field. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support:
At 10:21 -0800 on 12/26/2011, Edward Jaffe wrote about Re: Eight-character TSO Userid Support:: Application environments are responsible for supporting whatever the current architected userid length is. It has been asserted that TSO is the only z/OS application environment in 2011 (soon 2012) that can't handle that fundamental requirement. I'm trying to discover if that's a true statement. None of the responses I've received thus-far have offered anything to disprove that assertion. If true, fixing TSO will provide *complete* eight-character userid support for z/OS. The problem with allowing TSO to use 8 Character USERIDs is that it makes some TSO commands fail. Jobnames are 8 characters max. Submit (at least ISPF Automatic Submit) adds a one character suffix to the UserID and thus breaks if the UserID is 8 Characters (since that would result in an invalid length 9 character JOBNAME). Also OUTPUT (used by ISPF 3.8) validates that the JOBNAME is UserID+1_Character and thus would not be able to handle 8 character UserIDs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
At 12:15 -0600 on 12/26/2011, Paul Gilmartin wrote about Re: Eight-character TSO Userid Support: Likewise, in days of yore, but no longer, one DSN was not allowed to be a prefix of another, such as: GUBBINS.WOMBATversus GUBBINS.WOMBAT.FUBAR This was due to CVOL Support. Each level was a set of chained records and WOMBAT as a File name conflicted with it being a record containing a pointer to another level. If you had GUBBINS.WOMBAT.FUBAR and GUBBINS.WOMBAT.WOMBAT.FUBAR that was allowed. The GUBBINS Index record would point to chained records which were the 2nd level of indexes (one of which was WOMBAT). That WOMBAT Index record would point to a 3rd level of indexes (all chained from GUBBINS.WOMBAT). One FUBAR File record would be pointed to by the WOMBAT File record that was pointed to by GUBBINS.WOMBAT while another would be pointed to by GUBBINS.WOMBAT. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
At 19:20 -0600 on 12/24/2011, Paul Gilmartin wrote about Re: Eight-character TSO Userid Support: Hmmm. How many upper-case alphanumeric characters would be needed to provide unique identifiers for all the files an enterprise would ever need? By that metric, 44(8) is more than sufficient. A dataset name is up to 44 characters long but that is based on a set of 36 characters (26 letters and 10 numbers) CURRENTLY broken up into 1-8 character blocks separated by periods. The 8 character blocks are composed, if I remember correctly of 1 Alpha (A-Z) followed by 0-7 Alpha (A-Z) and Numeric (0-9) characters. There may also be some special characters in addition to the 36 (I forget). For GDG Datasets, the limit is 39(8) since the last 9 are required for the .GVyy suffix to the GDG File Base Name. What do you mean by 44(8) anyway? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support:
Edward Jaffe wrote begin snippet Recently, the need for eight-character TSO userids made it into the list of the highest ranked MVS SHARE requirements. Many installations, driven by their business units, are attempting to standardize on a single, eight-character, cross-platform userid. These attempts are being hampered by the arcane seven-character TSO userid restriction introduced in the 1970s. /end snippet This is clearly desirable, but I am not sure that it is enough. Historically, such limitations are almost always traceable to the use of suffixing schemes. Old-style IBM PL/I, for example, limited the lengths of external-procedure names to seven characters in order to make the eighth, rightmost character available for single-character suffixes that identified each of the multiple CSECTs that the compiler generated for that procedure. Or again, I was pleased to discover when I first began to use Stratus VOS that its filenames could be 32 characters in length, but this maximum turned out to be illusory. VOS had the habit of naming backup files using the suffixing scheme backed-up filename.bkup so that the 32-character maximum turned out, as a practical matter, to be a 27-character one. Examples of this sort could be multiplied ad infinitum et nauseam. I have concluded that the only way around such infelicities is to make external-name size limitations much larger than life, to chose, say, the value 2^15 - 1 = 32767 characters for them and to make this value a design point even though it is not yet globally usable. Considerable work will have to be done to eliminate the seven-character TSO userid maximum, and it would be a work wasted if an already obsolescent eight-character maximum replaced it. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support:
On Sat, 24 Dec 2011 09:45:12 -0500, John Gilmore wrote: Edward Jaffe wrote begin snippet Recently, the need for eight-character TSO userids made it into the list of the highest ranked MVS SHARE requirements. Many installations, driven by their business units, are attempting to standardize on a single, eight-character, cross-platform userid. These attempts are being hampered by the arcane seven-character TSO userid restriction introduced in the 1970s. /end snippet Examples of this sort could be multiplied ad infinitum et nauseam. I have concluded that the only way around such infelicities is to make external-name size limitations much larger than life, to chose, say, the value 2^15 - 1 = 32767 characters for them and to make this value a design point even though it is not yet globally usable. Considerable work will have to be done to eliminate the seven-character TSO userid maximum, and it would be a work wasted if an already obsolescent eight-character maximum replaced it. Yes. Particularly, TSO userids should be coded so the length is limited only by the underlying OS, so that if MVS ever adopts more than 8, TSO will immediately support that greater number with no recoding. (or at most the minimal code change of redefining a single EQU used globally). Likewise, the TSO DSN prefix should be made larger than life so it could immediately support up to 42 characters for legacy data sets, and more if the underlying OS restriction is ever relaxed, and immediately UNIX directory path. Unix System Services already supports the USERIDALIASTABLE: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb2b0/3.7.4.3 Would extending this facility to support TSO logins, and adding a reverse lookup function provide short term relief of the SHARE requirement. (One of the examplesin the cited section contains an alias longer than 8 characters.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
In 4ef583a2.1080...@phoenixsoftware.com, on 12/23/2011 at 11:47 PM, Edward Jaffe edja...@phoenixsoftware.com said: I am curious: is TSO the only hold-out? For 7 character userids, probably. However, there are two related issues that are global: 1. The current limit of userids to 8 characters is equally obsolescent. 2. The limitation of DSN components no longer makes sense, now that IBM has put a stake through the heart of CVOL's. I agree with Paul that the TSO PROFILE PREFIX should be expanded to 42 characters. Due to control block layouts, expand it or the userid to 8 characters would be as much work as expanding them to a larger size. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Sat, 24 Dec 2011 17:25:29 -0500, Shmuel Metz (Seymour J.) wrote: 1. The current limit of userids to 8 characters is equally obsolescent. 2. The limitation of DSN components no longer makes sense, now that IBM has put a stake through the heart of CVOL's. I understand from discussions in these fora that when CVOLs were supplanted, the limit was consequentially removed. Some people can't tolerate liberty. Customers demanded the limit be reinstated. IBM made it a configuration option, with the default being the less restrictive. Customers demanded that the default be restrictive. IBM acceded. Even worse, it was done in such a manner that if the customer reinstated the restriction, it was not possible to uncatalog or rename data sets created in the interim with names exploiting the less restrictive convention. Go figger. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On 24 Dec 2011 14:44:22 -0800, in bit.listserv.ibm-main you wrote: In 4ef583a2.1080...@phoenixsoftware.com, on 12/23/2011 at 11:47 PM, Edward Jaffe edja...@phoenixsoftware.com said: I am curious: is TSO the only hold-out? For 7 character userids, probably. However, there are two related issues that are global: 1. The current limit of userids to 8 characters is equally obsolescent. 2. The limitation of DSN components no longer makes sense, now that IBM has put a stake through the heart of CVOL's. I agree with Paul that the TSO PROFILE PREFIX should be expanded to 42 characters. Due to control block layouts, expand it or the userid to 8 characters would be as much work as expanding them to a larger size. While I agree that the control block (and SMF record) limitations on Jobname, proc step name and step name will be expensive to overcome, we need to come up with a case for it being worth doing. The name limitations don't seem to be present in the Unix/Linux and Windows environments and both may use Unicode for at least some of the names. File names also may need to be reviewed. The fun will be the transition. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
Yeah, I see the case for 8-character consistency since TSO seems to be the weirdo here, but I'm hard-pressed (much as I'd like to see it) to find a case for changing the other areas. It ain't broke... On Sat, Dec 24, 2011 at 7:11 PM, Clark Morris cfmpub...@ns.sympatico.ca wrote: While I agree that the control block (and SMF record) limitations on Jobname, proc step name and step name will be expensive to overcome, we need to come up with a case for it being worth doing. The name limitations don't seem to be present in the Unix/Linux and Windows environments and both may use Unicode for at least some of the names. File names also may need to be reviewed. The fun will be the transition. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
On Sat, 24 Dec 2011 19:19:34 -0500, zMan wrote: Yeah, I see the case for 8-character consistency since TSO seems to be the weirdo here, but I'm hard-pressed (much as I'd like to see it) to find a case for changing the other areas. It ain't broke... Hmmm. How many upper-case alphanumeric characters would be needed to provide unique identifiers for all the files an enterprise would ever need? By that metric, 44(8) is more than sufficient. But users will complain that they can readily move their data among Linux, Windows, Solaris, OS X; for z/OS they must perform excruciating name transformations. Such complaints will rise at least to audibility in the airline magazines which, like it or not, are a consideration in management decisions. But z/OS Unix System Services provides an escape from the name constraints. IBM should devote effort to elevating z/OS USS to enterprise strength and not let it remain a marketing gimmick. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
