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.