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.



This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2019 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].