×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 17-Sep-2015 08:24 -0600, Jim Franz wrote:
an interesting (but understandable) set of restrictions on
max storage by user
o A restore operation assigns the storage to the user doing
the restore, and then transfers the object to the owner.
For a large restore, specify MAXSTG(*NOMAX).
<<SNIP>>
FWiW: Although generally accurate, that statement may be somewhat
deceptive, for the restore of database files; often the /largest/ of
what gets restored. Unless I recall _incorrectly_, I expect that a user
with just a 100KB available storage could easily restore a new database
file both with a size of many GB and with an owner [as defined on the
media] different than the user doing the restore; that owner of course,
necessarily will need to have the necessary storage allowed. That is,
similar to restoring [members or data] into, or adding data to a member
of, a database file owned by another user; i.e. the signed-on user is
not charged for any storage, the owner of the file is charged.
So while that /restriction/ applies to restoring database file
objects [Restore Object (RSTOBJ) or Restore Library (RSTLIB)], my
recollection is that the described issue is mostly _mitigated_ for
database files, for those pieces of the composite-object that typically
take the biggest amounts of storage; those being the data [i.e. the
dataspace (*QDDS)], the keyed access paths [i.e. dataspace index
(*QDDSI)] and the members [i.e. the *MEM objects, often called *MBR;
while usually much smaller, sometimes /many/ in number, so in-aggregate
they may take significant storage]. That is because...
When the Database Restore feature /restores/ a file, the file is
pre-created as empty, much like Create Physical File (CRTPF) without
members, as if MBR(*NONE) were specified, and then the ownership of the
*FILE object is transferred. The dataspace for each member and each
member object are created effectively the same as if by Add Physical
File Member (ADDPFM) into the existing *FILE; i.e. as an /empty/ member.
Given that file would already have been assigned the owner and
authorities, the owner of the member [and dataspace] becomes the owner
of the file, *upon creation*, instead of being created first as owned by
the user doing the restore and then having the ownership transferred in
a second step. And only after all of that object-creation [and the
original ownership assignment before adding any members] transpires,
does the actual data ever get /loaded/ and /charged-as/ storage against
the object-owner.
midrange.com
