On Mon, 8 Jan 2024 11:00:38 -0000, Lennie Dymoke-Bradshaw wrote:
>Using quotes around the DSNAME will allow any combination of Hex chars for a
>Dsname I think (possibly excluding 44X'04' which represents the VTOC). However
>these are not supported for SMS datasets, nor can they be catalogued, nor can
>they be protected by RACF.
>https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-dsname-parameter
>
Where I read such as:
- The system ignores blank characters at the end of a data set name.
Wouldn't it be better to say, "data set names shorter than 44 ccharacters
are padded with blanks to 44"?
- Double ampersands to identify a temporary data set name. Note that
if you use apostrophes, DSNAME='&&AB' and DSNAME='&AB' refer
to the same data set.
That doesn't belong here. It's described better in "Determining Equivalent
JCL". It's incorrect here because it depends on the symbol AB being
undefined.
"Determining Equivalent JCL" states that double ampersands not enclsed
in apostrophes are reduced to single. Does this suggest that within
apostrophes they are nor so reduced?
I once tried a DSN enclosed in apostrophes ("unqualified") beginning with
a period. It failed with a syntax error. I have never found this restriction
documented.
The data set name should not contain the 44 special characters (X'04')
created by hexadecimal editing or any operation that converts the
value of characters to X'04'.
The "created by ... converts" clause is improperly restrictive. It doesn't
matter how they got there, "converted" or otherwise.
And no one has mentioned DISABLE(DSNCHECK) before now.
<https://www.ibm.com/docs/en/zos/3.1.0?topic=functions-enabling-disabling-data-set-name-validity-checking>
--
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
