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.
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.
//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
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.
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.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
Paul Gilmartin
<[EMAIL PROTECTED]
TEK.COM> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: Curiousity question: the
processing of DD DUMMY.
01/02/2008 02:43
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
On Wed, 2 Jan 2008 14:20:04 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>I'll retract "grievous".
>
>But see below.
>
Thanks for seeing past my bombast.
>>If the argument of PATH is anything other than '/dev/null'
>>(or '//dev/null'), the file is allocated as a UNIX file and can be
>>processed as a UNIX file. If it is '/dev/null' it as allocated as
>>DUMMY,
>
>If true, I'd have to agree with egregious; neither the C/I not allocation
>should have special processing for any path name.
>
One might make the same argument about DSNAMEs -- either way.
NULLFILE could have been catalogued on an imaginary UNIT and
the special processing deferred to the access method, even as
/dev/null has a real directory entry as a character special
device, and Unix's special processing of /dev/null is left to
the driver for that device.
>>It's worth a chapter in the JCL RM.
>
>If there actually is such a problem and IBM doesn't correct it, then I'd
>say that it should be documented in both the JCL RM and the JCL UG.
>
It's not a "problem", but a feecher:
12.42.6 "z/OS V1R7.0 MVS JCL Reference"
12.42.6 Dummy HFS Files
The following DD statements define a dummy
HFS file. The statements are equivalent; for DUMMY3, the extra slashes
(/) are compressed to single slashes.
//DUMMY1 DD PATH='/dev/null'
//DUMMY2 DD DUMMY,PATH=/ANYNAME
//DUMMY3 DD PATH='//dev///null'
>>What benefit of this distinct treatment of /dev/null justifies the
>>resource spent on its implementation?
>
I still wonder.
>I'm not convinced that there is such a treatment, but if you're not
>misinterpreting things then it would definitely violate Unix[2] semantics.
>
>[2] You might argue that JCL is outside the scope of Unix, but I doubt
> that the Unix community would buy that.
>
I suppose that Unix community would expect the look and feel of
Unix, even as the JCL community would expect the look and feel
of JCL.
-- 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
