Invalid PDS member names

[Bob Stark]

I received an XMIT format PDS from a client. When I restored it, it had a
number of invalid member names (at the bottom in the ISPF listing). I can
edit these, they appear to be backup copies of members.

The members show up in ISPF member lists, if I write a program to list the
directory (using the ISPF LMMLIST service), and if I do a TSO LISTDS 'dsn'
MEMBERS

The invalid member names all start with x'FFE8'

Any idea what tool might have created these members? Is this what PDSMAN
backup members look like, or members restored via StarTool or the PDS command?

I copied the PDS to a PDS/E, and only the valid members copied over.

Regards,

Bob Stark

[Styles, Andy , TME - Service Support]

They could well be Endevor backout members; Endevor uses 'invalid' member names for backout purposes, and simply a rename when a backout is invoked.


Andy Styles
Endevor Technical Specialist | zSCM (Software Configuration Management)

Lloyds TSB Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales, number 2065. Telephone: 020 7626 1500.
Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 327000. Telephone: 0870 600 5000

Lloyds TSB Scotland plc. Registered Office: Henry Duncan House, 120 George Street, Edinburgh EH2 4LH. Registered in Scotland, number 95237. Telephone: 0131 225 4555.
Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales, number 2299428. Telephone: 01452 372372.

Lloyds TSB Bank plc, Lloyds TSB Scotland plc, Bank of Scotland plc and Cheltenham & Gloucester plc are authorised and regulated by the Financial Services Authority.
Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds TSB Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 218813. Telephone: 0870 600 5000

Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 95000. Telephone: 0131 225 4555

This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments.

Telephone calls may be monitored or recorded.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[John P Kalinich]

The PDS command could restore to a hex member name pattern, but I don't
know why anyone would want to do this. I usually use XXXX as the member
name fragment when running a repeating RESTORE with PDS.

Did the client have CA-Endevor? That product does all kinds of weird
things with directory entries.

Regards,
John K






Invalid PDS member names

Bob Stark
to:
ISPF-L
09/12/2011 09:11 AM


Sent by:
ISPF discussion list <ISP...@listserv.nd.edu>
Please respond to ISPF discussion list

[Paul Gilmartin]

On Sep 12, 2011, at 08:37, Styles, Andy (TME - Service Support) wrote:

> They could well be Endevor backout members; Endevor uses 'invalid' member names for backout purposes, and simply a rename when a backout is invoked.
>

No immediate help to the OP, but:

Stories such as this, all too common, reinforce my belief that

o The primary OS (e.g. z/OS) should clearly document its naming
rules.

o Those rules should be enforced at a low level in the OS (e.g.
SVC), not by APIs such as JCL, TSO, ISPF, language runtime
systems, etc. In fact, those APIs should not enforce constraints
external to the primary OS.

This would protect customers from rogue vendors who use "invalid"
or unconventional names for internal purposes in hope of avoiding
conflicts with names used by customers or vendor peers, and free
the primary vendor to make technical enhancements with less
concern for compatibility with existing art.

I recall similar incidents when Binder appeared and began
enforcing rules on ESD names which had been stated opaquely
if at all, and never enforced by Linkage Editor.

o A portion of the name space should be reserved for use by
implementations (as "C" does with names beginning with
"__"). Ideally, if the name space were realistically large,
ISVs should be encouraged to use identifiers embedding a
registered trademark or domain name.

> -----Original Message-----
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of Bob Stark
> Sent: 12 September 2011 15:00
>

> I received an XMIT format PDS from a client. When I restored it, it had a
> number of invalid member names (at the bottom in the ISPF listing). I can
> edit these, they appear to be backup copies of members.
>

> I copied the PDS to a PDS/E, and only the valid members copied over.

-- gil

[Lizette Koehler]

>
>I received an XMIT format PDS from a client. When I restored it, it had a
>number of invalid member names (at the bottom in the ISPF listing). I can
>edit these, they appear to be backup copies of members.
>

>The members show up in ISPF member lists, if I write a program to list the
>directory (using the ISPF LMMLIST service), and if I do a TSO LISTDS 'dsn'
>MEMBERS
>
>The invalid member names all start with x'FFE8'

Those are from PDSMAN Version process.

CA-PDSMAN when creating backup copies of MEMBERS uses a x'FFE8' member name to put them at the back.

Lizette

[Binyamin Dissen]

On Mon, 12 Sep 2011 09:58:39 -0600 Paul Gilmartin <PaulGB...@AIM.COM>
wrote:

:>On Sep 12, 2011, at 08:37, Styles, Andy (TME - Service Support) wrote:

:>> They could well be Endevor backout members; Endevor uses 'invalid' member names for backout purposes, and simply a rename when a backout is invoked.

:>No immediate help to the OP, but:

:>Stories such as this, all too common, reinforce my belief that

:>o The primary OS (e.g. z/OS) should clearly document its naming
:> rules.

:>o Those rules should be enforced at a low level in the OS (e.g.
:> SVC), not by APIs such as JCL, TSO, ISPF, language runtime
:> systems, etc. In fact, those APIs should not enforce constraints
:> external to the primary OS.

:> This would protect customers from rogue vendors who use "invalid"
:> or unconventional names for internal purposes in hope of avoiding
:> conflicts with names used by customers or vendor peers, and free
:> the primary vendor to make technical enhancements with less
:> concern for compatibility with existing art.

Rouge vendors, such as IBM with SMP?

"nuff said.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[adrianstern]

Personally I applaud the practice - it's very handy although my back-
up macro uses member names starting with a $ which unfortuantely puts
them at the beginning - but this is an incentive to deal with them -
mind you I always have my pds.es sorted by date changed!
In VM we used to use member names in lower-case - never tried that in
TSO - but I'm going to great idea, thanks

[Schwarz, Barry A]

Using the 3.4 member list option, you should be able to rename the members in question to something more to your liking.

The STOW service, which actually adds, deletes, and renames members, accepts unprintable characters as well as imbedded blanks in member names for a PDS. Some other functions, such as JCL, are not quite so tolerant.

> -----Original Message-----
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of
> Bob Stark

> Sent: Monday, September 12, 2011 7:00 AM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Invalid PDS member names
>

[Bob Stark]

Aha, CA-PDSMAN. Thanks, Lizette, that's what I wanted to know!

[Paul Gilmartin]

On Sep 12, 2011, at 12:32, Binyamin Dissen wrote:
>
> :> This would protect customers from rogue vendors who use "invalid"
> :> or unconventional names for internal purposes in hope of avoiding
> :> conflicts with names used by customers or vendor peers, and free
> :> the primary vendor to make technical enhancements with less
> :> concern for compatibility with existing art.
>
> Rouge vendors, such as IBM with SMP?
>
> "nuff said.
>

Yup. Given that there was no clear documentation about
what might be a valid PDS member name, customers are apt
to observe what IBM products do, and assume that if SMP
does it, it's OK.

BTW, many years ago, I discovered that ISPF LM* utilities
would generally let me create a member name containing a
hyphen, but LMMSTATS called the name invalid when I tried
to update its statistics. Is this still the case? Why?
Conway's law, again, I suppose.

-- gil

[Steve Coalbran]

I think you can stick what you like in the membername (<=8 bytes) with an assembler STOW.
Try the '-'s in an LM service and see if it works !?
it sounds unlikely that the 'loophole' hadn't already been closed buy ya never know?
I'm sure the boys in Perth monitor this forum and react anyhow ?
/Steve

> Date: Tue, 13 Sep 2011 08:05:51 -0600
> From: PaulGB...@AIM.COM
> Subject: Re: Invalid PDS member names
> To: ISP...@LISTSERV.ND.EDU

[Paul Gilmartin]

On Sep 14, 2011, at 02:22, Steve Coalbran wrote:

> I think you can stick what you like in the membername (<=8 bytes) with an assembler STOW.

8x'FF' has always been reserved to indicate the end of the directory.
And, as this thread began, there are stricter rules for PDSE than
for PDS. I can't find them documented in "Using Data Sets".

> Try the '-'s in an LM service and see if it works !?

Which LM service? They're not necessarily consistent.

> it sounds unlikely that the 'loophole' hadn't already been closed buy ya never know?
> I'm sure the boys in Perth monitor this forum and react anyhow ?
>

What "loophole"? The term implies a technique for circumventing
rules, but the rules were never stated.

-- gil

[Bob Rutledge]

Paul Gilmartin wrote:
> On Sep 14, 2011, at 02:22, Steve Coalbran wrote:
>
>> I think you can stick what you like in the membername (<=8 bytes) with an assembler STOW.
>
> 8x'FF' has always been reserved to indicate the end of the directory.
> And, as this thread began, there are stricter rules for PDSE than
> for PDS. I can't find them documented in "Using Data Sets".

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.6.1.1?SHELF=EZ2ZBK0K&DT=20100628133137

and

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.7.4.1.1?SHELF=EZ2ZBK0K&DT=20100628133137

>> Try the '-'s in an LM service and see if it works !?
>
> Which LM service? They're not necessarily consistent.
>
>> it sounds unlikely that the 'loophole' hadn't already been closed buy ya never know?
>> I'm sure the boys in Perth monitor this forum and react anyhow ?
>>
> What "loophole"? The term implies a technique for circumventing
> rules, but the rules were never stated.

Bob

[Paul Gilmartin]

On Sep 14, 2011, at 10:11, Bob Rutledge wrote:

> Paul Gilmartin wrote:
>> On Sep 14, 2011, at 02:22, Steve Coalbran wrote:
>>> I think you can stick what you like in the membername (<=8 bytes) with an assembler STOW.
>> 8x'FF' has always been reserved to indicate the end of the directory.
>> And, as this thread began, there are stricter rules for PDSE than
>> for PDS. I can't find them documented in "Using Data Sets".
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.6.1.1?SHELF=EZ2ZBK0K&DT=20100628133137
>
> and
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.7.4.1.1?SHELF=EZ2ZBK0K&DT=20100628133137
>

Thanks. It's pretty well hidden. And that restriction appears
to apply alike to PDS and PDSE.

Note: If the member name specified in JFCBELNM begins with '+' (X'4E'),
'-' (X'60'), or X'Fx', the system does not issue the STOW macro. CLOSE
will interpret '+' (X'4E'), '-' (X'60'), or X'Fx' in JFCBELNM as an
indication that the data set is a generation data set (GDS) of a
generation data group (GDG).

Hmmm.... "X'Fx'" ... does that mean that X'FA', which is not the code
point of a decimal digit is prohibited?

This would seem to render the earlier prohibition of 8x'FF' redundant,
since that's a special case of "begins with ... X'Fx'".

And this is stated as applying to the content of JFCBELNM at the time
of CLOSE. Do the same rules apply to member names created by STOW?

-- gil

[Pedro Vera]

note: I do not speak for IBM.

> ... but the [ISPF naming] rules were never stated.

See the section 'Member name conventions' in "ISPF User's Guide Vol I".

That section describes the rules for naming members, but has this
disclaimer: "Members created through ISPF must follow this naming
convention..."
Paul's observation that various z/OS components might support different
conventions is probably true.

Since ISPF is pervasive, my suggestion is to stick with ISPF naming
conventions.


Pedro Vera
DB2 Admin Tool
http://www-01.ibm.com/software/data/db2imstools/db2tools/db2admin/

[Paul Gilmartin]

On Sep 14, 2011, at 10:33, Pedro Vera wrote:
>
> Paul's observation that various z/OS components might support different
> conventions is probably true.
>
> Since ISPF is pervasive, my suggestion is to stick with ISPF naming
> conventions.
>

So ISPF feels it's the 800-pound gorilla, entitled to impose rules
on the rest of z/OS?

I'd prefer to see ISPF be eclectic and deal with anything acceptable
elsewhere in z/OS.

-- gil

[Greg Price]

AFAIK, there is nothing to prevent a PDS member having a name
with a bit pattern corresponding to 8 EBCDIC blanks.

Also AFAIK, when issuing ISPF service calls that specify data set
and member names, ISPF decides if the data set is sequential
or a member of a partitioned data set by whether the member
name is blank or not.

This means that the DSORG need not be supplied as a separate
variable, which probably saves everyone a bit of overhead, but
comes at the "cost" of hiding underlying z/OS detail.

Surely this "hiding" facilitates enhanced usability and productivity?
I think I see your point, but would you change this aspect?

[War story from the 1980s: Fujitsu's SPF look-alike called PFD
at a certain maint level got screen errors when showing the
member list of PDSes with unprintable member names, such
as the SMPCDS etc.

Solution by PTF: translate the member names to only have
printable characters suitable for 3270-type display.

Result: members with such code points in their name could
not be browsed because this "sanitized" copy of the member
name was (so we can deduce) passed to the BLDL or FIND
to locate the member.

Ha! Laugh? I nearly started.]

Cheers,
Greg

[Greg Price]

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.6.1.1?
SHELF=EZ2ZBK0K&DT=20100628133137
says:
---start-of-quote---
Process the member with an OPEN TYPE=J macro, a series of PUT or WRITE macros, and the CLOSE
macro. The system issues a STOW macro when the data set is closed.

Note: If the member name specified in JFCBELNM begins with '+' (X'4E'), '-' (X'60'), or X'Fx', the
system does not issue the STOW macro. CLOSE will interpret '+' (X'4E'), '-' (X'60'), or X'Fx' in JFCBELNM
as an indication that the data set is a generation data set (GDS) of a generation data group (GDG).

---end-of-quote---

Does this mean it tries to interpret the meaning based on the
character string that makes up the member name?

Surely if the JFCB is supplied then the logic trying to interpret this
control block would look at the JFCPDS and JFCGDG flags in
preference to a contextual interpretation of the 8-byte field
which might have any (subject to conclusions reached so far)
bit pattern?

Maybe it only employs this logic if neither flag is set?
If so, couldn't really argue with that, I suppose.

Cheers,
Greg