Re: Different methods to control runaway file builds

[Jim Franz <franz9000@xxxxxxxxx>]

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

o  The user profile that creates a journal receiver is assigned the
   required storage as the receiver size grows. If new receivers are
   created using JRNRCV(*GEN), the storage continues to be assigned to
   the user profile that owns the active journal receiver. If a very
   active journal receiver is owned, specify MAXSTG(*NOMAX).

o  User profiles that transfer created objects to their group profile
   must have adequate storage in the user profiles to contain created
   objects before the objects are transferred to the group profile.

o  The owner of the library is assigned the storage for the
    descriptions of objects which are stored in a library, even when the
    objects are owned by another user profile. Examples of such objects
    are text and program references.

Jim

On Thu, Sep 17, 2015 at 10:17 AM, <rob@xxxxxxxxx> wrote:

> Max storage by user is not a bad idea.  "IF" they are the owner and not
> the users associated group profile.  I actually query user profiles on a
> periodic basic for those with a set maximum storage and how much space
> they are using.
>
> This is a valid SQL statement on newer versions of the OS:
>
> SELECT AUTHORIZATION_NAME, MAXIMUM_ALLOWED_STORAGE, STORAGE_USED
> FROM qsys2.user_info
> where maximum_allowed_storage>0
> order by (Maximum_allowed_storage - storage_used)
>
> Keep on eye on this.  If it's getting close and it's not the runaway query
> but rather the month end that fills this up the results might not be
> desired.
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   Jim Franz <franz9000@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   09/17/2015 09:20 AM
> Subject:        Different methods to control runaway file builds
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> Looking for a "best practice" plan
>
> About 50 (out of thousands) of our users can create queries (Query/400) to
> generate outfiles for upload. Other processes (RPGLE or SQLRPGLE) often
> generate export files to either libraries or ifs.
> Currently no QQRYTIMLMT.
> Last night a query/400 outfile reached 180 Gb before process halted
> (overflowed an ASP).
> We can set max storage by user, or a general max storage for all end
> users.
> QQRYTIMLMT an option but wondering if the odd join in a Query/400 that
> caused this issue would be able to estimate the time. OPS killed the job
> after 2 hours.
>
> So... QQRYTIMLMT could help in query and sql, but that does not fix the
> RPGLE possibility.
>
> A disk monitor is possible, or a job monitor (more complicated).
> Am leaning towards the max storage by user.
> Ideas?
>
> Jim Franz
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.