Re: allowed characters in member name

[Seymour J Metz]

It is common for IBM manuals for one component to give incorrect rules for 
another component instead of referring the reader to the relevant 
documentation. This is especially common when describing REXX or JCL 
requirements for using that component.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, January 8, 2024 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Mon, 8 Jan 2024 11:00:38 -, 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='' 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

DIRF.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, January 8, 2024 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

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 -, 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='' 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Thompson]

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 -, 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='' 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.




--
Regards, Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Mon, 8 Jan 2024 11:00:38 -, 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='' 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.


-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

I don't know of any difference in expressive power and, no, you can't use it 
with a path.

ObVir I don't find Q and QQ to be mnemonic. YMMV.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:

>Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
>subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that 
>LIKE= was part of that.
>
Did LIKE add any expressive power that DCB lacks?

I believe neither DCB nor LIKE can be used in nor refer to DD PATH=

The alternative might be to use JCL symbols for common attribute strings.

Combining brevity and mnemonic value:
Q = "'"
QQ = '"'

Don't forget to mention them in PROCEDURE EXPOSE.
SIGNAL ON NOVALUE would remind you, if you chose to use it.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

L?

I would expect 8X'FF' to work for PDSE, but what happens with PDS?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 7:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Actually STOW 8XL’FF’

Will work

Sent from my iPhone

No one said I could type with one thumb

> On Jan 7, 2024, at 18:34, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:
>
>> Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
>> subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe 
>> that LIKE= was part of that.
>>
> Did LIKE add any expressive power that DCB lacks?
>
> I believe neither DCB nor LIKE can be used in nor refer to DD PATH=
>
> The alternative might be to use JCL symbols for common attribute strings.
>
> Combining brevity and mnemonic value:
>Q = "'"
>QQ = '"'
>
> Don't forget to mention them in PROCEDURE EXPOSE.
> SIGNAL ON NOVALUE would remind you, if you chose to use it.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

I believe that GDG model DSCBs are still a thing for non-SMS volumes.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Sunday, January 7, 2024 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Going back to hazy memories...

GDGs needed the DSN specified, and the DCB info DCB=(dsn,) so
that the allocation routines would correctly set the DSCB info
for the data set by getting the LRECL, RECFM, etc. so that
allocation would have all that. I'm not sure that DFP V3 fixed
this, or SMS or what. But I remember having to remember to do
these things back in the day, for SMF tapes and the like, when
doing the initial allocation for a GDG generation data set (GDS)
(+1, etc.).

Steve Thompson

On 1/7/2024 5:15 PM, Paul Gilmartin wrote:
> On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:
>
>> DCB for the subparameters as been depreciated and, in my opinion, bad form 
>> for most of the 40 years I worked on mainframes. The DCB=modeldscb form used 
>> for new GDS allocations hasn't been needed since SMS came along. Early 90s'?
>> I may recall wrong, but I think LIKE was new with SMS.
>>
> Formerly needed; now deprecated.  Why was it ever needed?  I suspect the 
> change
> was less to accommodate SMS than UNIX files, which support attributes but no 
> DCB.
>
> Answering my earlier question (IRTFM):
> <https://www.ibm.com/docs/en/zos/3.1.0?topic=parameter-examples-like>
>  Example 2
>  //SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
>  //  LRECL=1024
>  In the example, the data set attributes used for MYDS7.PGM are obtained 
> from
>  the cataloged model data set MYDSCAT.PGM. Also, the logical record 
> length of
>  1024 overrides the logical record length obtained from the model data 
> set.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Radoslaw Skorupka]

W dniu 08.01.2024 o 05:01, Paul Gilmartin pisze:

On Mon, 8 Jan 2024 03:42:05 +, Gibney, Dave wrote:


Before LIKE, you needed IDCAMS to create VSAM files, after LIKE you could do 
this with just JCL


Ah.  So for PS or PO it has no advantage over DCB=dsname.  Perhaps for SPACE?


A lot of advantages including DSNTYPE (LARGE, EXTPREF - previously not 
available in JCL, only DC), PDSE compression, encryption, VSAM EA, etc.

Last, but not least: it is CONVENIENT.
I it just convenient to create new dataset "same as A.B.C".

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Radoslaw Skorupka]

W dniu 07.01.2024 o 21:55, Paul Gilmartin pisze:

On Sun, 7 Jan 2024 21:04:48 +0100, Radoslaw Skorupka wrote:

...
I have to admit: I almost never used DCB keyword in JCL and (AFAIR)
absolutely never DCB=HLQ.DATASET.NAME.
When teaching JCL I explain it, but also advice to not using that.
BTW: LIKE=HLQ.FOO-BAR works like a charm.


in :
 [ DCB= ( {dsname   }[,subparameter]...) ]

Is it possible likewise to override selected subparameters
of LIKE?  Was it so even before the subparameters were allowed
as separare parameters?  (Old habits diehard.)


Yes, yes, and yes.
I always use (and teach) that technique - LIKE says "I want the same, 
BUT..." and you provide the differences.
Of course it is IMHO unacceptable to *partially* support legal DS names 
in JCL - I mean DCB not accepting HLQ.FOO-BAR.



--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Lennie Dymoke-Bradshaw]

I believe these came in with the re-write of the JCL Converter and/or 
Interpreter which occurred with MVS 4.2 (working purely from memory!)

Lennie Dymoke-Bradshaw
https: //rsclweb.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 07 January 2024 23:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that 
LIKE= was part of that.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:

>DCB for the subparameters as been depreciated and, in my opinion, bad form for 
>most of the 40 years I worked on mainframes. The DCB=modeldscb form used for 
>new GDS allocations hasn't been needed since SMS came along. Early 90s'?
>I may recall wrong, but I think LIKE was new with SMS.
>
Formerly needed; now deprecated.  Why was it ever needed?  I suspect the change 
was less to accommodate SMS than UNIX files, which support attributes but no 
DCB.

Answering my earlier question (IRTFM):
<https://www.ibm.com/docs/en/zos/3.1.0?topic=parameter-examples-like>
Example 2
//SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
//  LRECL=1024
In the example, the data set attributes used for MYDS7.PGM are obtained from
the cataloged model data set MYDSCAT.PGM. Also, the logical record length of
1024 overrides the logical record length obtained from the model data set.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Lennie Dymoke-Bradshaw]

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

Note particularly,

"The system does not check data set names enclosed in apostrophes for valid 
characters. When SMS is
not installed or active incorrect characters or length result in data set 
allocation, but the data set is not
cataloged. When SMS is active, it will fail the job for incorrect characters or 
length."

However, I think it is not possible to do this with a member name. Happy to 
learn more though, if someone knows better.

Lennie Dymoke-Bradshaw
https: //rsclweb.com
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Leonard D Woren
Sent: 08 January 2024 06:29
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

I don't think anyone has mentioned that X'C0' (left brace in the U.S.) is valid 
in a member name.  I didn't test to see whether it's allowed in the first 
position; probably not.

X'C0' is also valid in a dsname on a non-SMS volume, but it's now broken in 
that you can't catalog it any more.  Get "NOT CATLGD 9". 
Again, I didn't try it in the first position which almost certainly is not 
allowed.


Regarding the limit of 8 characters between periods in a dsname, that was a 
requirement in OS CVOL days.  Seems to me that that validity test can and 
should be removed now that CVOLs are long long dead dead.  I could see 
requiring any levels in an MLA alias restricted to
8 characters.  Why is left as an exercise to the reader.


/Leonard




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Leonard D Woren]

I don't think anyone has mentioned that X'C0' (left brace in the U.S.) 
is valid in a member name.  I didn't test to see whether it's allowed 
in the first position; probably not.


X'C0' is also valid in a dsname on a non-SMS volume, but it's now 
broken in that you can't catalog it any more.  Get "NOT CATLGD 9". 
Again, I didn't try it in the first position which almost certainly is 
not allowed.



Regarding the limit of 8 characters between periods in a dsname, that 
was a requirement in OS CVOL days.  Seems to me that that validity 
test can and should be removed now that CVOLs are long long dead 
dead.  I could see requiring any levels in an MLA alias restricted to 
8 characters.  Why is left as an exercise to the reader.



/Leonard




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Mike Schwab]

High values indicates end of directory.

On Sun, Jan 7, 2024 at 6:30 PM Phil Smith III  wrote:

> Paul Gilmartin wrote:
> >STOW 'Abc Xyz!'probably works.
> >STOW 8X'FF'   probably doesn't or produces unexpected results.
>
> Ah.this is in reference to the original question, sorta, not to my "Why?"
> question. Thanks.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Mon, 8 Jan 2024 03:42:05 +, Gibney, Dave wrote:

>Before LIKE, you needed IDCAMS to create VSAM files, after LIKE you could do 
>this with just JCL
>
Ah.  So for PS or PO it has no advantage over DCB=dsname.  Perhaps for SPACE?

-- 
Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Gibney, Dave]

Before LIKE, you needed IDCAMS to create VSAM files, after LIKE you could do 
this with just JCL

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Sunday, January 7, 2024 4:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: allowed characters in member name
> 
> [EXTERNAL EMAIL]
> 
> On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:
> 
> >Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to
> subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that
> LIKE= was part of that.
> >
> Did LIKE add any expressive power that DCB lacks?
> 
> I believe neither DCB nor LIKE can be used in nor refer to DD PATH=
> 
> The alternative might be to use JCL symbols for common attribute strings.
> 
> Combining brevity and mnemonic value:
> Q = "'"
> QQ = '"'
> 
> Don't forget to mention them in PROCEDURE EXPOSE.
> SIGNAL ON NOVALUE would remind you, if you chose to use it.
> 
> --
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Thompson]

Going back to hazy memories...

GDGs needed the DSN specified, and the DCB info DCB=(dsn,) so 
that the allocation routines would correctly set the DSCB info 
for the data set by getting the LRECL, RECFM, etc. so that 
allocation would have all that. I'm not sure that DFP V3 fixed 
this, or SMS or what. But I remember having to remember to do 
these things back in the day, for SMF tapes and the like, when 
doing the initial allocation for a GDG generation data set (GDS) 
(+1, etc.).


Steve Thompson

On 1/7/2024 5:15 PM, Paul Gilmartin wrote:

On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:


DCB for the subparameters as been depreciated and, in my opinion, bad form for 
most of the 40 years I worked on mainframes. The DCB=modeldscb form used for 
new GDS allocations hasn't been needed since SMS came along. Early 90s'?
I may recall wrong, but I think LIKE was new with SMS.


Formerly needed; now deprecated.  Why was it ever needed?  I suspect the change
was less to accommodate SMS than UNIX files, which support attributes but no 
DCB.

Answering my earlier question (IRTFM):

 Example 2
 //SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
 //  LRECL=1024
 In the example, the data set attributes used for MYDS7.PGM are obtained 
from
 the cataloged model data set MYDSCAT.PGM. Also, the logical record length 
of
 1024 overrides the logical record length obtained from the model data set.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Beaver]

Actually STOW 8XL’FF’

Will work 

Sent from my iPhone

No one said I could type with one thumb 

> On Jan 7, 2024, at 18:34, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:
> 
>> Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
>> subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe 
>> that LIKE= was part of that.
>> 
> Did LIKE add any expressive power that DCB lacks?
> 
> I believe neither DCB nor LIKE can be used in nor refer to DD PATH=
> 
> The alternative might be to use JCL symbols for common attribute strings.
> 
> Combining brevity and mnemonic value:
>Q = "'"
>QQ = '"'
> 
> Don't forget to mention them in PROCEDURE EXPOSE.
> SIGNAL ON NOVALUE would remind you, if you chose to use it.
> 
> --
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sun, 7 Jan 2024 19:29:46 -0500, Phil Smith III wrote:

>Paul Gilmartin wrote:
>>STOW 'Abc Xyz!'probably works.
>>STOW 8X'FF'   probably doesn't or produces unexpected results.
>
>Ah.this is in reference to the original question, sorta, not to my "Why?" 
>question. Thanks.
>
As always, no one supplied an RFE with a sufficient use case.

And if they answer Shmuel's FAMS question they have to kill him.
It's absurd that so useful a facility remains a trade secret.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:

>Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
>subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that 
>LIKE= was part of that.
>
Did LIKE add any expressive power that DCB lacks?

I believe neither DCB nor LIKE can be used in nor refer to DD PATH=

The alternative might be to use JCL symbols for common attribute strings.

Combining brevity and mnemonic value:
Q = "'"
QQ = '"'

Don't forget to mention them in PROCEDURE EXPOSE.
SIGNAL ON NOVALUE would remind you, if you chose to use it.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Phil Smith III]

Paul Gilmartin wrote:
>STOW 'Abc Xyz!'probably works.
>STOW 8X'FF'   probably doesn't or produces unexpected results.

Ah.this is in reference to the original question, sorta, not to my "Why?" 
question. Thanks.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

Is there a FAMS equivalent to STOW? Does member 8'X'FF' work wit PDSE?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Sun, 7 Jan 2024 18:16:32 -0500, Phil Smith III  wrote:

>
>And Steve Beaver added:
>>The simplest path on this discussion is to try it in batch or ispf. The only 
>>other way is in HLASM with the STOW macro
>
>Try what? Unclear what you're suggesting?
>
STOW 'Abc Xyz!'probably works.
STOW 8X'FF'   probably doesn't or produces unexpected results.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sun, 7 Jan 2024 18:16:32 -0500, Phil Smith III  wrote:

>
>And Steve Beaver added:
>>The simplest path on this discussion is to try it in batch or ispf. The only 
>>other way is in HLASM with the STOW macro
>
>Try what? Unclear what you're suggesting?
>
STOW 'Abc Xyz!'probably works.
STOW 8X'FF'   probably doesn't or produces unexpected results.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that 
LIKE= was part of that.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:

>DCB for the subparameters as been depreciated and, in my opinion, bad form for 
>most of the 40 years I worked on mainframes. The DCB=modeldscb form used for 
>new GDS allocations hasn't been needed since SMS came along. Early 90s'?
>I may recall wrong, but I think LIKE was new with SMS.
>
Formerly needed; now deprecated.  Why was it ever needed?  I suspect the change
was less to accommodate SMS than UNIX files, which support attributes but no 
DCB.

Answering my earlier question (IRTFM):
<https://www.ibm.com/docs/en/zos/3.1.0?topic=parameter-examples-like>
Example 2
//SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
//  LRECL=1024
In the example, the data set attributes used for MYDS7.PGM are obtained from
the cataloged model data set MYDSCAT.PGM. Also, the logical record length of
1024 overrides the logical record length obtained from the model data set.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Phil Smith III]

Radoslaw Skorupka wrote:
>The "8 characters rule" is widely used in z/OS and mainframe world.
>Why?

Presumably because a doubleword is a nice, discrete size of data-big enough to 
be useful, small enough to manipulate with things like two (now one) register?

And Steve Beaver added:
>The simplest path on this discussion is to try it in batch or ispf. The only 
>other way is in HLASM with the STOW macro

Try what? Unclear what you're suggesting?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Wayne Bickerdike]

DCB was often used in referbacks, eg DCB=(*.STEP1.MASTER), I'm sure most
modernspeak prefers LIKE. Blame the Beatles.

Yanno what I mean like?

On Mon, Jan 8, 2024 at 9:15 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:
>
> >DCB for the subparameters as been depreciated and, in my opinion, bad
> form for most of the 40 years I worked on mainframes. The DCB=modeldscb
> form used for new GDS allocations hasn't been needed since SMS came along.
> Early 90s'?
> >I may recall wrong, but I think LIKE was new with SMS.
> >
> Formerly needed; now deprecated.  Why was it ever needed?  I suspect the
> change
> was less to accommodate SMS than UNIX files, which support attributes but
> no DCB.
>
> Answering my earlier question (IRTFM):
> 
> Example 2
> //SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
> //  LRECL=1024
> In the example, the data set attributes used for MYDS7.PGM are
> obtained from
> the cataloged model data set MYDSCAT.PGM. Also, the logical record
> length of
> 1024 overrides the logical record length obtained from the model data
> set.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:

>DCB for the subparameters as been depreciated and, in my opinion, bad form for 
>most of the 40 years I worked on mainframes. The DCB=modeldscb form used for 
>new GDS allocations hasn't been needed since SMS came along. Early 90s'? 
>I may recall wrong, but I think LIKE was new with SMS.
>
Formerly needed; now deprecated.  Why was it ever needed?  I suspect the change
was less to accommodate SMS than UNIX files, which support attributes but no 
DCB.

Answering my earlier question (IRTFM):

Example 2
//SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
//  LRECL=1024
In the example, the data set attributes used for MYDS7.PGM are obtained from
the cataloged model data set MYDSCAT.PGM. Also, the logical record length of
1024 overrides the logical record length obtained from the model data set.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Gibney, Dave]

DCB for the subparameters as been depreciated and, in my opinion, bad form for 
most of the 40 years I worked on mainframes. The DCB=modeldscb form used for 
new GDS allocations hasn't been needed since SMS came along. Early 90s'? 
I may recall wrong, but I think LIKE was new with SMS.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Sunday, January 7, 2024 12:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: allowed characters in member name
> 
> [EXTERNAL EMAIL]
> 
> On Sun, 7 Jan 2024 21:04:48 +0100, Radoslaw Skorupka wrote:
> >...
> >I have to admit: I almost never used DCB keyword in JCL and (AFAIR)
> >absolutely never DCB=HLQ.DATASET.NAME.
> >When teaching JCL I explain it, but also advice to not using that.
> >BTW: LIKE=HLQ.FOO-BAR works like a charm.
> >
> in
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> defense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%
> 2Fzos%2F3.1.0%3Ftopic%3Ddp-syntax-
> 2__%3B!!JmPEgBY0HMszNaDT!t9cNADlF8YggV3ftQnDqq6_pEAAjAFaVbaK2k
> fJgOesh1r7d9dqid5L-
> WIIW1zb5mpfhGtk7tLl2BCULYpCb41cuw0K2G4c3%24=05%7C02%7C
> GIBNEY%40WSU.EDU%7C67f73d32256d4c107e3608dc0fc30cd4%7Cb52be
> 471f7f147b4a8790c799bb53db5%7C0%7C0%7C638402577608244597%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=5avD4PTklj
> wHUQOVSoHwar90iho8VQVuCtgOLxfh5gM%3D=0 >:
> [ DCB= ( {dsname   }[,subparameter]...) ]
> 
> Is it possible likewise to override selected subparameters of LIKE?  Was it so
> even before the subparameters were allowed as separare parameters?  (Old
> habits diehard.)
> 
> --
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sun, 7 Jan 2024 21:04:48 +0100, Radoslaw Skorupka wrote:
>...
>I have to admit: I almost never used DCB keyword in JCL and (AFAIR)
>absolutely never DCB=HLQ.DATASET.NAME.
>When teaching JCL I explain it, but also advice to not using that.
>BTW: LIKE=HLQ.FOO-BAR works like a charm.
>
in :
[ DCB= ( {dsname   }[,subparameter]...) ]

Is it possible likewise to override selected subparameters
of LIKE?  Was it so even before the subparameters were allowed
as separare parameters?  (Old habits diehard.)

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sun, 7 Jan 2024 13:59:09 -0600, Steve Beaver wrote:

>The simplest path on this discussion is to try it in batch or ispf. The only 
>other way is in HLASM with the STOW macro
> 
I've tried it with STOW.  It likes any 8 bytes: lower case, embedded spaces, 
NULs, etc.
And I consider it improper for middleware (TSO, JCL, ...) to impose syntactic 
restrictipns
beyond those enforced by the primitives.  Apostrophes should be your friend.


>> On Jan 7, 2024, at 13:55, Radoslaw Skorupka wrote:
>> 
>> W dniu 07.01.2024 o 19:02, Phil Smith III pisze:
>>> Paul Gilmartin wrote, in part, in answer to "Why can't a data set name 
>>> element start with a digit":
 Left-to-right lexical analyzer that treats anything beginning with a digit
 as a number.
>>> I'm willing to believe this, but am unclear on why whatever is parsing a 
>>> DSN would care whether it's a number or not. E.g.:
>>> //SYSINDD   DISP=SHR,DSN=1.2.3
>>> 
>>> Why would it care that it's a digit? The start of a non-initial DSN element 
>>> is the thing after a period, so it doesn't matter there.
>>> 
The period is not part of the DSN element.  Its a separator.

Perhaps my imaginary lexical analyzer returns numbers in fixed-point format;
other things as strings.

Why is LRECL=080 acceptable but BUFNO=080 a syntax error?

>>> My guess is something planned/considered that never happened, or just a 
>>> mistake late on a Sunday afternoon in 1962.
>> 
Storage was expensive then.

>> The "8 characters rule" is widely used in z/OS and mainframe world.
>> Why?
>> I heard an explanation for that. However it was approx. 25 years ago I did 
>> not fully understand it. Since at the time the rule was enough for me, I 
>> didn't ask. It was something related to assembler, as far as I remember.
>> 
Storage was expensive then.

A UNIX historian recalls an era when directory entries were 16 bytes:
file names were limited to 14 and I-numbers to 65535.

UNIX got better; MVS didn't.  It's the curse of Assembler compatibility
with inadequate parameterization in copybooks.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Radoslaw Skorupka]

W dniu 06.01.2024 o 23:59, Paul Gilmartin pisze:

On Sat, 6 Jan 2024 23:14:28 +0100, Radoslaw Skorupka wrote:

...
For dataset names the addition is "-". This character can be used in
dataset names with no tricks like name in apostrophes, uncataloged ones,
etc.


But not, in my experience, in a reference to define DCB subparameters such as:
 DCB=HLQ.FOO-BAR* Syntax error!


Is there any plausible reason for that restriction

I hate JCL!


I have to admit: I almost never used DCB keyword in JCL and (AFAIR) 
absolutely never DCB=HLQ.DATASET.NAME.

When teaching JCL I explain it, but also advice to not using that.
BTW: LIKE=HLQ.FOO-BAR works like a charm.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Beaver]

The simplest path on this discussion is to try it in batch or ispf. The only 
other way is in HLASM with the STOW macro


Sent from my iPhone

No one said I could type with one thumb 

> On Jan 7, 2024, at 13:55, Radoslaw Skorupka 
> <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
> 
> W dniu 07.01.2024 o 19:02, Phil Smith III pisze:
>> Paul Gilmartin wrote, in part, in answer to "Why can't a data set name 
>> element start with a digit":
>>> Left-to-right lexical analyzer that treats anything beginning with a digit
>>> as a number.
>> I'm willing to believe this, but am unclear on why whatever is parsing a DSN 
>> would care whether it's a number or not. E.g.:
>> //SYSINDD   DISP=SHR,DSN=1.2.3
>> 
>> Why would it care that it's a digit? The start of a non-initial DSN element 
>> is the thing after a period, so it doesn't matter there.
>> 
>>  
>> My guess is something planned/considered that never happened, or just a 
>> mistake late on a Sunday afternoon in 1962.
> 
> The "8 characters rule" is widely used in z/OS and mainframe world.
> Why?
> I heard an explanation for that. However it was approx. 25 years ago I did 
> not fully understand it. Since at the time the rule was enough for me, I 
> didn't ask. It was something related to assembler, as far as I remember.
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Radoslaw Skorupka]

W dniu 07.01.2024 o 19:02, Phil Smith III pisze:

Paul Gilmartin wrote, in part, in answer to "Why can't a data set name element start 
with a digit":

Left-to-right lexical analyzer that treats anything beginning with a digit
as a number.

I'm willing to believe this, but am unclear on why whatever is parsing a DSN 
would care whether it's a number or not. E.g.:
//SYSINDD   DISP=SHR,DSN=1.2.3

Why would it care that it's a digit? The start of a non-initial DSN element is 
the thing after a period, so it doesn't matter there.

  


My guess is something planned/considered that never happened, or just a mistake 
late on a Sunday afternoon in 1962.


The "8 characters rule" is widely used in z/OS and mainframe world.
Why?
I heard an explanation for that. However it was approx. 25 years ago I 
did not fully understand it. Since at the time the rule was enough for 
me, I didn't ask. It was something related to assembler, as far as I 
remember.



--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Radoslaw Skorupka]

No, it is not catalog issue, including multilevel alias. I just created 
alias named HLQ.A-L1
However first qualifier is special one because of RACF. You cannot 
create RACF profile without creating group or user for HLQ. And both 
GROUP and USER names cannot contain "-".
Of course one may consider uprotected datasets, but IMHO it has no 
practical usage.




--
Radoslaw Skorupka
Lodz, Poland




W dniu 07.01.2024 o 18:15, Michael Oujesky pisze:

And for multi-level aliases also?

Michael

At 07:15 PM 1/6/2024, Steve Thompson wrote:

Content-Transfer-Encoding: 7bit

Would that be because of a Catalog issue? As in an Alias can't 
contain "-"?


Steve Thompson

On 1/6/2024 6:18 PM, Ed Jaffe wrote:

On 1/6/2024 2:14 PM, Radoslaw Skorupka wrote:
For dataset names the addition is "-". This character can be used 
in dataset names with no tricks like name in apostrophes, 
uncataloged ones, etc.


We tried using this for our PHX-BDT product. It worked great in the 
second qualifier (e.g., SYS2.PHX-BDT.SJBDMAC), but not in the first.


Since we prefer to deliver product data sets with the product name 
as the first qualifier, we settled on using PHXBDT instead...




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Phil Smith III]

Paul Gilmartin wrote, in part, in answer to "Why can't a data set name element 
start with a digit":
>Left-to-right lexical analyzer that treats anything beginning with a digit
>as a number.

I'm willing to believe this, but am unclear on why whatever is parsing a DSN 
would care whether it's a number or not. E.g.:
//SYSINDD   DISP=SHR,DSN=1.2.3

Why would it care that it's a digit? The start of a non-initial DSN element is 
the thing after a period, so it doesn't matter there.

 

My guess is something planned/considered that never happened, or just a mistake 
late on a Sunday afternoon in 1962.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Michael Oujesky]

And for multi-level aliases also?

Michael

At 07:15 PM 1/6/2024, Steve Thompson wrote:

Content-Transfer-Encoding: 7bit

Would that be because of a Catalog issue? As in an Alias can't contain "-"?

Steve Thompson

On 1/6/2024 6:18 PM, Ed Jaffe wrote:

On 1/6/2024 2:14 PM, Radoslaw Skorupka wrote:
For dataset names the addition is "-". This character can be used 
in dataset names with no tricks like name in apostrophes, 
uncataloged ones, etc.


We tried using this for our PHX-BDT product. It worked great in the 
second qualifier (e.g., SYS2.PHX-BDT.SJBDMAC), but not in the first.


Since we prefer to deliver product data sets with the product name 
as the first qualifier, we settled on using PHXBDT instead...


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

GDS?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Saturday, January 6, 2024 9:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Has anyone ever understood why data set/member names cannot start with 
numerics? Just curious, as it seems like an odd restriction.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sat, 6 Jan 2024 21:11:23 -0500, Phil Smith III wrote:

>Has anyone ever understood why data set/member names cannot start with 
>numerics? Just curious, as it seems like an odd restriction.
> 
Left-to-right lexical analyzer that treats anything beginning with a digit
as a number.

Does the same apply to every level in a DSN?

(In the day, storage was too expensive for a fancy parser)

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Phil Smith III]

Has anyone ever understood why data set/member names cannot start with 
numerics? Just curious, as it seems like an odd restriction.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Thompson]

Would that be because of a Catalog issue? As in an Alias can't 
contain "-"?


Steve Thompson

On 1/6/2024 6:18 PM, Ed Jaffe wrote:

On 1/6/2024 2:14 PM, Radoslaw Skorupka wrote:
For dataset names the addition is "-". This character can be 
used in dataset names with no tricks like name in apostrophes, 
uncataloged ones, etc.


We tried using this for our PHX-BDT product. It worked great in 
the second qualifier (e.g., SYS2.PHX-BDT.SJBDMAC), but not in 
the first.


Since we prefer to deliver product data sets with the product 
name as the first qualifier, we settled on using PHXBDT instead...




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sat, 6 Jan 2024 18:14:54 -0500, Tony Thigpen wrote:

>The restriction in the DCB is due to Assembler restrictions on use of '-'.
>
Explain in more detail how DCB=HLQ.FOO-BAR runs afoul of
"Assembler restrictions on use of '-'", please.

Does the JCL converter invoke Assembler to process DD statements?

Is it in the generation of SVC 99 TUs?

Is it in the expansion of the DCB macro?

How does "DSN=HLQ.FOO-BAR" evade the restriction?


>Paul Gilmartin wrote on 1/6/24 5:59 PM:
>> On Sat, 6 Jan 2024 23:14:28 +0100, Radoslaw Skorupka wrote:
>>> ...
>>> For dataset names the addition is "-". This character can be used in
>>> dataset names with no tricks like name in apostrophes, uncataloged ones,
>>> etc.
>>>
>> But not, in my experience, in a reference to define DCB subparameters such 
>> as:
>>  DCB=HLQ.FOO-BAR* Syntax error!
>> 
>>
>> Is there any plausible reason for that restriction
>>
>> I hate JCL!

-- 
Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Ed Jaffe]

On 1/6/2024 2:14 PM, Radoslaw Skorupka wrote:
For dataset names the addition is "-". This character can be used in 
dataset names with no tricks like name in apostrophes, uncataloged 
ones, etc.


We tried using this for our PHX-BDT product. It worked great in the 
second qualifier (e.g., SYS2.PHX-BDT.SJBDMAC), but not in the first.


Since we prefer to deliver product data sets with the product name as 
the first qualifier, we settled on using PHXBDT instead...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Tony Thigpen]

The restriction in the DCB is due to Assembler restrictions on use of '-'.

Tony Thigpen

Paul Gilmartin wrote on 1/6/24 5:59 PM:

On Sat, 6 Jan 2024 23:14:28 +0100, Radoslaw Skorupka wrote:

...
For dataset names the addition is "-". This character can be used in
dataset names with no tricks like name in apostrophes, uncataloged ones,
etc.


But not, in my experience, in a reference to define DCB subparameters such as:
 DCB=HLQ.FOO-BAR* Syntax error!


Is there any plausible reason for that restriction

I hate JCL!

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Sat, 6 Jan 2024 23:14:28 +0100, Radoslaw Skorupka wrote:
>...
>For dataset names the addition is "-". This character can be used in
>dataset names with no tricks like name in apostrophes, uncataloged ones,
>etc.
>
But not, in my experience, in a reference to define DCB subparameters such as:
DCB=HLQ.FOO-BAR* Syntax error!


Is there any plausible reason for that restriction

I hate JCL!

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Radoslaw Skorupka]

You can see such member names in SMP dataset and CA PDSMAN managed 
datasets.

However this is NOT what I'm talking about.
I mean "regular" member names used in JCL and/or in ISPF dialogs.

BTW: it is NOT "regular character set" understood as A-Z, 0-9, #$@ with 
no numeric on first position. It is a little more. And that's what I'm 
asking about.
For dataset names the addition is "-". This character can be used in 
dataset names with no tricks like name in apostrophes, uncataloged ones, 
etc.


--
Radoslaw Skorupka
Lodz, Poland




W dniu 05.01.2024 o 21:06, Steve Beaver pisze:

The last time I saw PDS Member names that were not A-Z 0-9 was in Endevor.

Those were/are the prior Member name backup until the package was committed


Steve


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, January 5, 2024 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Fri, 5 Jan 2024 18:33:40 +, Sri h Kolusu wrote:


What characters are allowed in JCL when specifying member name?

Radoslaw,
In general, PDS member naming rules are ( assuming code page 037)

•   A member name cannot be longer than eight characters.
•   The first member character must be either a letter or one of the 
following three special characters: #, @, $.
•   The remaining seven characters can be letters, numbers, or one of the 
following special characters: #, @, or $.
•   A PDS member name cannot contain a hyphen (-).
•   A PDS member name cannot contain accented characters (à, é, è, and so 
on).


The last two bullets are pleonastic.


ISPF also supports the same.
https://www.ibm.com/docs/en/zos/2.5.0?topic=types-member-name-conventions


I consider it bad design for middleware such as JCL or ISPF to impose
syntactic restrictions not present in the primitives, STOW/BLDL.


Special/national characters may differ based on the code page


Either:
o the supported code points should be specified in the Ref. or,
o the middleware should be aware of the code page and adapt
   to it as ISPF does for regular expr3essions.
   
<https://www.ibm.com/docs/en/zos/3.1.0?topic=string-regular-expressions-string1>

I hate EBCDIC!



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Mike Schwab]

DSN with quotes is not edited at all, and is not cataloged.

On Sat, Jan 6, 2024 at 2:49 PM Jon Perryman  wrote:

> On Fri, 5 Jan 2024 20:40:00 +, Nash, Jonathan S. <
> jonathan.s.n...@ssa.gov> wrote:
>
> >We have a PDSE with member names starting with a
> >left paren which were created with some old software.
>
> Did IBM fix this with JCL DSN= using quoted dataset and member name? My
> guess is no. DSN and member name validation can be different for every
> interface. For instance, JCL DSN validation is different when the DSN= is
> quoted. I've used superzap more than once because someone quoted a DSN with
> lower case letters. I'm guessing that including blanks, special characters
> and omitting periods is acceptable for quoted datasets.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Jon Perryman]

On Fri, 5 Jan 2024 20:40:00 +, Nash, Jonathan S.  
wrote:

>We have a PDSE with member names starting with a
>left paren which were created with some old software.

Did IBM fix this with JCL DSN= using quoted dataset and member name? My guess 
is no. DSN and member name validation can be different for every interface. For 
instance, JCL DSN validation is different when the DSN= is quoted. I've used 
superzap more than once because someone quoted a DSN with lower case letters. 
I'm guessing that including blanks, special characters and omitting periods is 
acceptable for quoted datasets.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Thompson]

Sounds like something NETVIEW might do. I also forgot to mention 
it does STOW, and so with that interface you can ignore the 
member name rules of JCL.


Steve Thompson

On 1/5/2024 3:40 PM, Nash, Jonathan S. wrote:

We have a PDSE with member names starting with a
left paren which were created with some old software.
I am unable to create such members in ISPF edit or to
copy them with IEBCOPY.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Friday, January 05, 2024 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: allowed characters in member name

Radoslaw,
 From memory, this is simply the ALPHANUMNAT set. Alphabetic chars (upper 
case), Numerics and the national chars (#$@). First char may not be numeric.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 05 January 2024 17:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: allowed characters in member name

(This is somehow Friday question, but at least on topic. :-)  )


What characters are allowed in JCL when specifying member name?
I mean constructs like the following:
//ANY DD DSN=HLQ.DATASET(MEMBER)

Note, it is not about PDS/PDSE itself and I have seen SMPSCDS member names (as 
well as PDSMAN generated), but I mean JCL-acceptable names, which are also 
supported by ISPF (I think so).

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Nash, Jonathan S.]

We have a PDSE with member names starting with a
left paren which were created with some old software.
I am unable to create such members in ISPF edit or to
copy them with IEBCOPY. 


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Friday, January 05, 2024 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: allowed characters in member name

Radoslaw,
From memory, this is simply the ALPHANUMNAT set. Alphabetic chars (upper case), 
Numerics and the national chars (#$@). First char may not be numeric.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 05 January 2024 17:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: allowed characters in member name

(This is somehow Friday question, but at least on topic. :-)  )


What characters are allowed in JCL when specifying member name?
I mean constructs like the following:
//ANY DD DSN=HLQ.DATASET(MEMBER)

Note, it is not about PDS/PDSE itself and I have seen SMPSCDS member names (as 
well as PDSMAN generated), but I mean JCL-acceptable names, which are also 
supported by ISPF (I think so).

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Thompson]

Along those lines, does NETVIEW still use "hex" values in member 
names? I wondered how that would work if it (NETVIEW) was pointed 
to a PDSE. If I remember correctly it was using SVC 99 for some 
of this.


Steve Thompson

On 1/5/2024 3:08 PM, Seymour J Metz wrote:

What about JES2 member names starting with $?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Steve 
Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 5, 2024 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

The last time I saw PDS Member names that were not A-Z 0-9 was in Endevor.

Those were/are the prior Member name backup until the package was committed


Steve


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, January 5, 2024 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Fri, 5 Jan 2024 18:33:40 +, Sri h Kolusu wrote:


What characters are allowed in JCL when specifying member name?

Radoslaw,
In general, PDS member naming rules are ( assuming code page 037)

•   A member name cannot be longer than eight characters.
•   The first member character must be either a letter or one of the 
following three special characters: #, @, $.
•   The remaining seven characters can be letters, numbers, or one of the 
following special characters: #, @, or $.
•   A PDS member name cannot contain a hyphen (-).
•   A PDS member name cannot contain accented characters (à, é, è, and so 
on).


The last two bullets are pleonastic.


ISPF also supports the same.
https://www.ibm.com/docs/en/zos/2.5.0?topic=types-member-name-conventions


I consider it bad design for middleware such as JCL or ISPF to impose
syntactic restrictions not present in the primitives, STOW/BLDL.


Special/national characters may differ based on the code page


Either:
o the supported code points should be specified in the Ref. or,
o the middleware should be aware of the code page and adapt
   to it as ISPF does for regular expr3essions.
   
<https://www.ibm.com/docs/en/zos/3.1.0?topic=string-regular-expressions-string1>

I hate EBCDIC!

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Seymour J Metz]

What about JES2 member names starting with $?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 5, 2024 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

The last time I saw PDS Member names that were not A-Z 0-9 was in Endevor.

Those were/are the prior Member name backup until the package was committed


Steve


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, January 5, 2024 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Fri, 5 Jan 2024 18:33:40 +, Sri h Kolusu wrote:

>>> What characters are allowed in JCL when specifying member name?
>
>Radoslaw,
>In general, PDS member naming rules are ( assuming code page 037)
>
>•   A member name cannot be longer than eight characters.
>•   The first member character must be either a letter or one of the 
>following three special characters: #, @, $.
>•   The remaining seven characters can be letters, numbers, or one of the 
>following special characters: #, @, or $.
>•   A PDS member name cannot contain a hyphen (-).
>•   A PDS member name cannot contain accented characters (à, é, è, and so 
>on).
>
The last two bullets are pleonastic.

>ISPF also supports the same.
>https://www.ibm.com/docs/en/zos/2.5.0?topic=types-member-name-conventions
>
I consider it bad design for middleware such as JCL or ISPF to impose
syntactic restrictions not present in the primitives, STOW/BLDL.

>Special/national characters may differ based on the code page
>
Either:
o the supported code points should be specified in the Ref. or,
o the middleware should be aware of the code page and adapt
  to it as ISPF does for regular expr3essions.
  
<https://www.ibm.com/docs/en/zos/3.1.0?topic=string-regular-expressions-string1>

I hate EBCDIC!

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Steve Beaver]

The last time I saw PDS Member names that were not A-Z 0-9 was in Endevor.

Those were/are the prior Member name backup until the package was committed 


Steve 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, January 5, 2024 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Fri, 5 Jan 2024 18:33:40 +, Sri h Kolusu wrote:

>>> What characters are allowed in JCL when specifying member name?
>
>Radoslaw,
>In general, PDS member naming rules are ( assuming code page 037)
>
>•   A member name cannot be longer than eight characters.
>•   The first member character must be either a letter or one of the 
>following three special characters: #, @, $.
>•   The remaining seven characters can be letters, numbers, or one of the 
>following special characters: #, @, or $.
>•   A PDS member name cannot contain a hyphen (-).
>•   A PDS member name cannot contain accented characters (à, é, è, and so 
>on).
>
The last two bullets are pleonastic.

>ISPF also supports the same.
>https://www.ibm.com/docs/en/zos/2.5.0?topic=types-member-name-conventions
>
I consider it bad design for middleware such as JCL or ISPF to impose
syntactic restrictions not present in the primitives, STOW/BLDL.

>Special/national characters may differ based on the code page
> 
Either:
o the supported code points should be specified in the Ref. or,
o the middleware should be aware of the code page and adapt
  to it as ISPF does for regular expr3essions.
  
<https://www.ibm.com/docs/en/zos/3.1.0?topic=string-regular-expressions-string1>

I hate EBCDIC!

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Paul Gilmartin]

On Fri, 5 Jan 2024 18:33:40 +, Sri h Kolusu wrote:

>>> What characters are allowed in JCL when specifying member name?
>
>Radoslaw,
>In general, PDS member naming rules are ( assuming code page 037)
>
>•   A member name cannot be longer than eight characters.
>•   The first member character must be either a letter or one of the 
>following three special characters: #, @, $.
>•   The remaining seven characters can be letters, numbers, or one of the 
>following special characters: #, @, or $.
>•   A PDS member name cannot contain a hyphen (-).
>•   A PDS member name cannot contain accented characters (à, é, è, and so 
>on).
>
The last two bullets are pleonastic.

>ISPF also supports the same.
>https://www.ibm.com/docs/en/zos/2.5.0?topic=types-member-name-conventions
>
I consider it bad design for middleware such as JCL or ISPF to impose
syntactic restrictions not present in the primitives, STOW/BLDL.

>Special/national characters may differ based on the code page
> 
Either:
o the supported code points should be specified in the Ref. or,
o the middleware should be aware of the code page and adapt
  to it as ISPF does for regular expr3essions.
  


I hate EBCDIC!

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Sri h Kolusu]

>> What characters are allowed in JCL when specifying member name?

Radoslaw,

In general, PDS member naming rules are ( assuming code page 037)

•   A member name cannot be longer than eight characters.
•   The first member character must be either a letter or one of the 
following three special characters: #, @, $.
•   The remaining seven characters can be letters, numbers, or one of the 
following special characters: #, @, or $.
•   A PDS member name cannot contain a hyphen (-).
•   A PDS member name cannot contain accented characters (à, é, è, and so 
on).


ISPF also supports the same.

https://www.ibm.com/docs/en/zos/2.5.0?topic=types-member-name-conventions


Special/national characters may differ based on the code page


Thanks,
Kolusu


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: allowed characters in member name

[Lennie Dymoke-Bradshaw]

Radoslaw,
>From memory, this is simply the ALPHANUMNAT set. Alphabetic chars (upper 
>case), Numerics and the national chars (#$@). First char may not be numeric.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 05 January 2024 17:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: allowed characters in member name

(This is somehow Friday question, but at least on topic. :-)  )


What characters are allowed in JCL when specifying member name?
I mean constructs like the following:
//ANY DD DSN=HLQ.DATASET(MEMBER)

Note, it is not about PDS/PDSE itself and I have seen SMPSCDS member names (as 
well as PDSMAN generated), but I mean JCL-acceptable names, which are also 
supported by ISPF (I think so).

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

allowed characters in member name

[Radoslaw Skorupka]

(This is somehow Friday question, but at least on topic. :-)  )


What characters are allowed in JCL when specifying member name?
I mean constructs like the following:
//ANY DD DSN=HLQ.DATASET(MEMBER)

Note, it is not about PDS/PDSE itself and I have seen SMPSCDS member 
names (as well as PDSMAN generated), but I mean JCL-acceptable names, 
which are also supported by ISPF (I think so).


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN