On Thu, 19 Sep 2013 19:48:54 -0400, Gerhard Postpischil wrote:
>
>At a minimum, DSN=NULLFILE, unlike a plain DD DUMMY, can be used to
>carry more JFCB information to a program (volsers, DCBs, etc.). I use
>this when a program may allocate a file dynamically, and the DSORG and
>size are determined during execution.
> 
Here, I'll disagree, emphatically.  A similar argument was presented
here, a few years ago.  But the JCL reference insists that DUMMY
and DSN=NULLFILE are entirely equivalent.  The pedant arguing the
other side did not deign to supply a code example where different
behavior is manifest.  I tried on my own to generate such an example;
I was unable to do so, even trying such convoluted techniques as
overrides.  (I didn't try VOLSER.)

But I'll welcome a refutation, with accompanying test cases.

(An old-timer colleague refused to use DUMMY or NULLFILE, preferring
(empty) temporary data sets as he harbored unpleasant remembrance
of things past, when allocation issued ENQ SYSDSN NULLFILE.  This
seems to have been a bug, long since fixed.)

>And depending on your definition, an EOF is a record (it may have a
>non-zero key length, thus carry information).
>
I believe that if the data exactly fill an allocated extent, no EOF is
written, nor is a secondary extent created to hold it.  In that case,
EODAD will be entered when READ encounters the end of the last
extent allocated.  But a crude experiment seems to show that
CLOSE will not tolerate an EOF at the end of a full directory in lieu
of the high-value entry.

>> I have occasionally created empty PDSes (usually temporary) to use
>> in overriding concatenations.  If there are no members, it's silly to require
>> that there be directory blocks.
> 
I withdrew that assertion when I thought of the high-value entry.

>A number of programs, including IEBCOPY, will refuse to operate unless
>they find a high-value entry.
>
Good for them.  Allocation should likewise fail if it can't create the
high-value entry.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to