Page 1 of 1

"Invalid" member names

PostPosted: Thu Apr 29, 2010 3:04 pm
by Mirco
Hello all.

I have a question regarding member naming rules. This official manual says:
PDS member naming rules
* 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 doesn't allow me to create a member with a name containing '-', '^', '&' or the like or rename a member to such name. BUT if I use some custom-written program that does not check the name, I can create such members without any problems, then list them with ISPF, view, edit etc. as if everything was OK.

The question is: can I assume that those "invalid" names will normally work and the naming rules are just recommendations, or should I try to avoid them and carefully validate every name in my programs to prevent them from being created?

Thanks.

Re: "Invalid" member names

PostPosted: Thu Apr 29, 2010 4:52 pm
by Robert Sample
I would be very cautious about allowing anything not allowed by the official rules -- IBM usually has very solid reasons for such rules. I don't know of anything that wouldn't work, but 2 AM would be a bad time to find out that your back ups are not copying these member when your restore fails. The point is, there's likely something that doesn't work with invalid member names and without knowing what that is do you really want to take chances with them?

Re: "Invalid" member names

PostPosted: Fri Apr 30, 2010 3:08 am
by dick scherrer
Hello,

should I try to avoid them and carefully validate every name in my programs to prevent them from being created?
Yes, you should make sure that nothing invalid is attempted. Many times in the past documented rules that are not in force become "real" and suddenly many things "go thud".

Just because some documented rule is not currently enforced when you run something invalid is no guarantee that it will currently work for all cases or that it will not be enforced by a fix (apar) let alone an upgrade to the system.

And when the enforcement is discovered it is quite likely that there will some other major problem that needs resolution. . .