On Tue, 11 Nov 2008 19:17:08 +0000, john gilmore wrote:
> 
>//LIB1  DD DSN=A.B.C,DISP=SHR
>//        DD DSN=A.B.C,DISP=SHR
> 
>is licit.  One may, that is, concatenate a library with itself; and the 
>only penalty incurred by doing so is a small amount of sometimes 
>gratuitous overhead.
> 
>That said, why do this?  The answer is that if the first DSN= 
>value is parameterized and given a default value equal to the 
>value of the second, the default value of the first can be 
>overridden if a second library is needed and ignored if not.
> 
>This scheme also generalizes readily to situations in which more 
>than one placeholder is needed.
> 
>About the differences between DSN=NULLFILE and DUMMY I have 
>nothing new to say.  The mob was wrong on that earlier occasion, 
>and it is wrong again now.  It may be, however, that this 
>placeholder example will suggest one of the crucial differences 
>between DUMMY and DSN=NULLFILE to an 'alert reader'.

Perhaps I am not sufficiently "alert".

AFAIK, there is no value for either DUMMY or NULLFILE in the above 
placeholder example.  Perhaps you could enlighten us if you know any. 
Certainly, it would not be useful to override the dsname in the example 
to NULLFILE, as that would cause a S013-64 abend.

As to your previous posts on this subject,
On Tue, 31 May 2005 15:16:36 +0000, john gilmore wrote:
>
>Once written within a procedure neither of the DD statements
>
>//<ddname> DD DUMMY
>
>or
>
>//<ddname> DD DUMMY, . . .
>
>can be altered into one that in fact is functional, permits non-null outputs
>to be written or non-null
>inputs to be read.
>
>On the other hand
>
>//SYSPRINT  DD DSN=NULLFILE,BLKSIZE=0,LRECL=137,RECFM=VBA
>
>can be altered readily by simply supplying a different licit value of DSN=.
>This
>difference was the basis for my statement that DSN=NULLFILE was superior to
>DUMMY when used inside procedures.

This assertion is inconsistent with the documented behavior.  It is 
also just plain wrong, as can easily be confirmed.  A DD DUMMY... 
can be overridden by supplying an overriding DD statement 
containing a DSNAME other than NULLFILE.  The DUMMY parameter 
can also be overridden by a path other than /dev/null, SYSOUT, 
*, DATA or SUBSYS.  Furthermore, any other parameters that 
were specified on the DD DUMMY will be used.  I tested this and 
invite others to do likewise.

Finally, On Fri, 27 May 2005 22:35:28 +0000, john gilmore wrote:
>
>Let me, however, rehearse what I said originally at greater length.  Coding
>DUMMY has the effect that everything following it is ignored, no DCB
>information is retained.

I'm sorry, but you are mistaken on this.  It is not true on 
z/OS 1.9, the release that I tested with.  Indeed, DCB 
subparameters may be required to complete the DCB in order 
to avoid abends.
>
>Coding DSN=NULLFILE,DCB=...  permits NULLFILE to be overridden and the
>retained DCB info to be used.

As does coding DD DUMMY...   DCB and other parameters coded 
with DUMMY are used when DUMMY is overridden.

>About citations of the obvious I grow less and less patient as I age.  There
>are days when I am still prepared to summon up arguments for the oblate
>sphericity of the earth to confute some flat-earther, but there are other
>days when I am not.

We are not "flat-earthers".  We are reasonably intelligent people 
who are willing to learn.  Do you have anything to contribute or 
does it please you to insult us?

You have asserted that DUMMY and NULLFILE are different.  
Thus far, your assertions are unfounded.
>
>The JCL manual snippet quoted by Paul Gilmartin,
>
>>   The system ignores all parameters other than DUMMY or
>>   DSNAME=NULLFILE and DCB. The DCB parameter must be coded if you
>>   would code it for normal I/O operations. ...
>
>
>specifies just exactly the behavior I describe above.  Moreover, it does so
>in language that seems to me to be quite clear enough.  In standard English
>the boolean operator AND takes precedence over the boolean operator OR: 'A
>or B and C' means '(A) or (B and C)'.
>
>Expanded, this snippet thus means
>
>o If you code DUMMY all else is ignored
>
>o If you code DCB=NULLFILE, DCB information will be retained.

Assuming that you are correct about the precedence of AND over 
OR in standard English, what you have stated does indeed seem 
obvious.  I am not aware of this precedence, though.  However, 
it is inconsistent with other statements in the JCL manuals.  
Specifically,in the JCL Reference, section 12.24 "DUMMY Parameter", 
it reads,

"Code the DCB parameter, if needed. If the program does not 
supply all the data control block information, make sure that 
the DCB parameter supplies the missing information."

-- 
Tom Marchant

----------------------------------------------------------------------
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

Reply via email to