User profile % full - beware MCH2804 !

Just a heads up for anyone anticipating an increase in new objects,
especially owned by group profiles.

Last week we ran several hundred batch jobs which ran under a group profile
& created files, a lot of files.

In several of the batch jobs, the group profile exceeded -

- not the storage limit (Which was *NOMAX)
- not the system storage limit

but the number of Entries allowed per profile, due to the sheer volume of
files being duplicated.
We did a bit of juggling & transferring ownership for the new objects &
thought all was OK.

The next evening we brought our system down for a scheduled IPL.
It didn't come back up for 48 hours and we had to put our DR site on alert.

During this time, the problem was escalated to Rochester who were straight
onto it; gave us terrific support;
and recommended that if MCH2804 is encountered in batch jobs, it is an
indication that the profile entry count is dangerously high.

We are now running a daily review on profiles that are maxed out, using
PRTPRFINT SELECT(*PCTFULL)  PCTFULL(20)
to obtain a listing. This takes a minute to run and is well worth putting
in place !

We can then CHGOBJOWN for objects to another empty profile to alleviate
this, specifying CUROWNAUT(*REVOKE).

Apparently, ignoring the MCH2804 errors leads to creation of a new DB
recovery object for each.
(We are at V4R5M0. )
Yes, there's an APAR; title of OSP-IPL-SRCB90037FF-MSGMCH3601-T/QDBRCIPS
X/0021

But it looks a lot better to monitor for this in advance.
It was a h@ll of a week !

Fiona
fiona.fitzgerald@notes.royalsun.com