Why the use of data set names enclosed with apostrophes, that are
not TSO oriented?
Back in the days when I was doing DOS to MVS migrations, to
access certain DOS data sets, you needed this because they could
contain names like this:
'PAYROLL STR 12MAY75' for either a Tape label or disk DSN. (where
STR was the ID of the company you were doing payroll for -- In
various service bureaus I've worked in).
DOS did not enforce the same restrictions as OS did (or MVS) for
"File names" (DDNAME for OS) UNTIL VSAM (IIRC). VSAM in DOS, as I
remember it, did enforce the same naming restrictions. BUT!!!
SHARE options were different because VSAM was at the "domain"
(O/S) level, for DOS where it is at the address space level for OS.
I mention this because there were migrations from DOS to
OS{MVS|z/OS) for CICS that did not take this into account and so
used multiple FILE names (DDN in MVS terms) and so cause
performance issues under MVS-OS390-z/OS if that file is not
accessed using a single DDNAME. --- I was just dealing with
such a situation with a client where the applications group
managment did not want to hear it -- because they didn't want to
make the changes that needed to be done. So IAM was brought in
which addressed those problems!!
Long ugly story. But thought there might be a few that would need
this deeper knowledge.
Also, back in the day (don't know if this is true to day with
zVSE) there was a "dirty" bit set in the VTOC (DIRM if I remember
correctly) that caused MVS to see that it may not have space
extents correct (forgot the name of the DSCB) and so would re-org
the VTOC and maybe the volume (holding a RESERVE) every time DOS
would write to such a shared volume where it would set the VTOC
dirty bit on.
Depending on what was on that volume, that RESERVE could and did
affect the DOS and MVS sides.
Some of the things we run into today were caused by some
decisions made years ago.
But as was noted, those names could be cataloged at one time in
"MVS".
Steve Thompson
On 1/8/2024 10:10 AM, Paul Gilmartin wrote:
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>
--
Regards, Steve Thompson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
