On Wed, 2 Jan 2008 21:06:54 -0500, Shmuel Metz (Seymour J.) wrote:
>
>Off the top of my head, I'd say that it's broken as designed. Another case
>of IBM's MVS, OMVS and Unix people not talking to each other, assuming
>that you have verified the difference in behavior.
>
Do you consider the following IEBGENER step to verify the difference
in behavior:
//STEP EXEC PGM=IEBGENER
//SYSUT1 DD *
This is the first instream catenand.
// DD PATH='/./dev/null'
// DD *
This instream catenand follows PATH='/./dev/null'..
// DD PATH='/dev/null'
// DD *
This instream catenand follows PATH='/dev/null'..
//SYSUT2 DD SYSOUT=(,)
... which writes to SYSUT2:
SDSF OUTPUT DISPLAY NULLPATH JOB02427 DSID 105 LINE 0 COLUMNS 02- 97
COMMAND INPUT ===> SCROLL ===> PAGE
********************************* TOP OF DATA
*************************************************
This is the first instream catenand.
This instream catenand follows PATH='/./dev/null'..
******************************** BOTTOM OF DATA
***********************************************
... ? Note that the line after /./dev/null is displayed, but the line
after /dev/null is not because according to JCL rules catenands following
DD DUMMY are not processed.
>The look and feel of JCL was that there was only *one* special dsname.
>handling PATH='/dev/null' differently from other Unix file names with the
>same definition is *not* what an old time JCL user would expect. OTOH, if
>the are treated the same, there's nothing wrong with the documentation
>pointing out the canonical name.
-- 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
