On Wed, 2 Jan 2008 16:56:19 -0800, Skip Robinson wrote: >I've never questioned the path length or development costs to support both >DDNAME and DSNAME options for a null file, i.e. DD DUMMY and DSN=NULLFILE, >but as pointed out earlier in this thread, they are both ancient. The >virtue of having both is the flexibility of choosing whichever one is more >convenient (if either would work) or being able to use the function at all >in a context where only one would work. > I'm a little puzzled. In what context would "DD DUMMY" work where "DSN=NULLFILE" would work differently, or not at all?
>The 'equivalent' examples quoted from the manual differ greatly in coding >JCL statements in a cataloged procedure: DSNAME can be represented as a >symbolic variable but DDNAME cannot. > ITYM the positional parameter DUMMY, not DDNAME. >//UPDATE PROC IN1='APP.TRANSFILE' >//INPUT1 DD DSN=&IN1 > >At execution time, without touching the proc itself, one can run the >program with null input with minimal coding. > >// EXEC UPDATE,IN1=NULLFILE > One could equally well code: //UPDATE PROC KEYWORD='' //INPUT1 DD &KEYWORD.DSN=APP.TRANSFILE And at execution time, without touching the proc itself, run the program with null input with minimal coding: // EXEC UPDATE,KEYWORD='DUMMY,' ... the constructs are highly equivalent in expressive power. >Back in the day when resources were far more expensive than they are today, >being able to test or diagnose or just validate with empty input or output >files was crucial. It still makes sense today. > Agreed. >I'm guessing that the 'unnatural' syntax option for a null path name simply >gives a Unix user the same two choices as in MVS JCL. As a mainframer, I >find the mechanism ingenious, not offensive. > A bad guess. The choices would exist regardless. There is need for the CI, and perhaps JES3 setup, to provide special handling for DSN=NULLFILE. Otherwise, there would be a default DISP=(NEW,DELETE) and the initiator would issue an exclusive ENQ for the name, preventing other users concurrent use of NULLFILE. No such concern applies to PATH='/dev/null', and the filesystem itself implements the character special device. The code and documentation to provide special handling for PATH='/dev/null' is unnecessary; therefore wasteful; therefore I find it offensive. Again, what is the benefit provided by the special treatment? What facility is provided by the allocation's (and perhaps the CI's) treating /dev/null differently from any other pathname? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
