Re: SAVRSTOBJ QUESTION

On 03 May 2013 15:03, Peter Dow wrote:

You said "Even possibly effecting more members than the MAXMBRS()
limit for the file, because the restore allows the new member to
restore regardless of the limit, when the outcome is due to its
renaming activity. "

Is that true when MAXMBRS is *NOMAX? Or does an error occur in that
situation?

I should have said "more members than the explicit numeric MAXMBRS()
limit". The *NOMAX special value is a variable [non-specific] limit,
currently established with a hard stop at 32767 due to implementation.
The restore probably still renames the existing member, but then fails
to create the member into which the data will be restored\loaded; likely
with the error message CPF3213 "Members for file &1 more than maximum
allowed.", which would then lead to the /not restored/ messages from
both the database [DB] and the save\restore [SR] features.

I do not recall the effect for SQL TABLE. While I know the illogical
case of zero members can be effected using save\restore, I think maybe
an extra member is prevented at the create member processing too,
probably diagnosed as CPF3207 "Member not added. Errors occurred." with
a prior diagnostic message explaining that an SQL TABLE can have only
one member. Or I suppose it could rename the file instead of the
member, but I do not recall that in the code [which I do recall having
changed once, maybe twice].?

I have never tested the effects of ADDPFCST [or /if/ any other
features] dependent on the MAXMBRS(1) for how they respond to the effect
of a member beyond the maximum when set to have only one, but any such
feature requiring that only one member be present should be testing the
actual number of members beyond just ensuring that its
attribute\restriction is set to allow just one member.