That any one particular database file might have exhibited
difficulties in SAVxxx when it reached 8K members, would not have
been a valid indication that any other database files would have the
same issue when they also reached the same number of members. Even
if two or three files exhibited that effect [presumably the error
message CPF375E symptom msgCPF375E], any conclusion that there was
some upper limit other than the documented 32K database *FILE
MAXMBRS(*NOMAX) limit, would have been apocryphal. The similarity
in effect would have been coincidental or have arisen only from the
similarity of the attributes of the members themselves; attributes
may be file-level attributes, such as key fields. The message does
not name any specific number of members, not simply to avoid
updating the text with removal of a limit, but because the save
limits are not only by number. For a database file, a limit in
storage size of 16MB for the "descriptions" of the *FILE and its
members is the limit that is enforced.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzamp/rzampsaverst.htm
"When you perform a save operation, the system creates a list of the
objects and their descriptions that it saves. The system saves this
list with the objects for use when it displays the save media or
restores the objects. The list is an internal object that is not
accessible to user programs.
The system requires that all description data saved for a file must
be contained in the same 16 MB internal object. This data includes
information about the file, its formats, and its members. For
database physical files with dependent logical files, the data also
includes information about the logical files, if access paths are
saved. If your save operation fails because the description data for
a file has exceeded the size of a 16 MB internal object, you need to
divide the members of the file among multiple files and save these
files. Because the system might try to put the description data for
more than one file in the same 16 MB internal object, you might need
to use separate save commands to save these files."
So although such load\dump descriptor limits as imposed on the
database save feature by the SAVxxx features may have been manifest
as an error [like CPF375E] that alluded to some limit being exceeded
[and thus why a database *FILE was not saved], the origin for the
"not saved" condition was not directly the number of members, merely
influenced by the number of members. A source file with 32K members
added, would on every release, be saved successfully within the LD
descriptor limits, as verified by a /limits test/ that was
performed. Such a save would succeed whenever the attributes of the
file members did not cause the internal 16MB limit to be exceeded,
or IIRC, also that the ordered objects within the descriptor did not
happen to place that *FILE as the last object. Thus in a specific
scenario [unique to a specific system environment], a *FILE that
could not be saved might have had as few as one member. In other
scenarios a *FILE that could not be saved might have had 2K, 10K,
20K, or any number of members up to the MAXMBR limit. So the
particulars of the *MEM objects, the *FILE object, and the other
objects & relations saved on the same SAVxxx request could prevent
the *FILE being saved, but the specific number of members required
to see a problem was always indeterminate.
So again, there has never been any hard\specific number-limit for
members of a database file for save; I know of this quite well,
having worked on the database team. As such, no specific number of
members as an upper limit could ever be used to appropriately define
generally at what point a database file would no longer be able to
be saved on SAVxxx requests.
Regards, Chuck
Wintermute, Sharon wrote:
There was a limit on the # of members you could save at one time
with SAVLIB. I have hit it at multiple shops. I may not remember
the # correctly, (ie 8000) but I do know it existed at one time.
That was one reason several shops started putting source into
multiple files and separating source from production objects.
This may no longer exist, but it did at one point.
For some shops, having multiple source files may simply be a
carry-over from this restriction.
CRPence on Friday, May 07, 2010 10:38 AM wrote:
Wintermute, Sharon wrote:
One of the reasons (way back when) was the 8000 member limit
on saving of files. I don't know if that still exists. I have
seen applications that exceed that. (Working on 2 of them
now).
hr wrote:
I know this is not directly the subject, but I have always
wondered why people has different source files for
different source types <<SNIP>>
If "saving of files" means SAVOBJ or SAVLIB, neither has ever
had a hard-limit like 8000; I doubt also for SAV. The database
supports up to 32766 [and remains functional for most requests,
even up to the documented limit of 32767] members in a database
file; the database save feature [which implements SAVxxx]
included.
There are dozens of reasons that one could justify self-imposed
limits on the number of members, mostly performance-related;
or perhaps to avoid exceeding some application-imposed limits.
midrange.com
