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).

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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.