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.WOMBAT versus >> 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
