Re: SAVSYS running over an hour

rob@xxxxxxxxx wrote:

It was a full RCLSTG in restricted state. How could I tell if
that was a conflict?
12/09/09 06:44:47.550855 QRCLAIM QSYS
Message . . . . : RCLSTG processing complete.
12/09/09 06:44:47.597399 QCADRV QSYS 03B8 Message . . . . : 29000 - SAVSYS DEV(TAPMLB04) ENDOPT(*LEAVE)

Insert a WRKACTJOB /* JOB(*SYS) */ OUTPUT(*PRINT) after the reclaim and before the SAVSYS, to show what was actively processing when the save system request started. I used to actually change the SysRqs-3 to present the WRKJOB during restricted state operations so I could issue WRKACTJOB anytime I was curious about activity. Although the asynchronous processing of *DBXREF information for a full reclaim is likely to be limited, there are situations by chance alone that can have the synchronous portion at the tail-end; the closer to the end of processing for the sync portion increases the potential overlap of the async portion and the next [in this case SAVSYS] request. This can be prevented by using RCLSTG OMIT(*DBXREF) before the SAVSYS, and then issuing RCLSTG SELECT(*DBXREF) after the SAVSYS. The overlap will be during whatever follows, e.g. startup of the system and user activity, which could be even more negative. The OMIT(*DBXREF) is actually the best option, if there is any chance the full reclaim might need to be interrupted; i.e. RCLSTG SELECT(*DBXREF) will be effectively *required* any time a RCLSTG which included the *DBXREF was interrupted.

You may have something there with the PRTPRFINT command. I remember IBM used that to point out that supplemental groups were
a real hog in jumping a SAVSYS from 4 minutes to 44 minutes on a
different system. How do I analyze that output? What should I
look for?

<<SNIP PRTPRFINT by user showing all zeroes>>

Alternative run
Select by . . . . . . . . . . : *PCTFULL
Percentage full . . . . . . . : 99.90
Percent of
Percent of Private Percent of Percent of
User Percent Owned Object Authority Authorized Primary Group
Profile Full Entries Entries User Entries Entries
(There are no user profiles to list)
* * * * * E N D O F L I S T I N G * * * * *

I think *PCTFULL of greater than .5% would be a good start. While the value 99.5% is good to find conditions of "nearly full", that is not directly useful for investigating possible impacts to the save security data, for which any _large number_ of authority entries will add time. IMO any profiles that are greater than 1% are probably of interest to at least review for why there are so many authority entries, as possibly new entries for which the additional time is required to save that data [saved for use by RSTAUT].


FWiW:

Although the system is in "restricted state", all "system jobs" will continue to run. The database cross reference server jobs could still be processing some *DBXREF information, some object decompression could be active as Jack noted [e.g. IPL after an install], conversions may be active, and communication activity will continue [in part, if any lines were left active]. Any database conversions [and so too should other conversions], and I think also decompression, are supposed to pause during restricted state. Those processes may pause only when the "save system" indication is also on, specifically to prevent impacting save activity performed in restricted state while allowing progression on their intent during non-save restricted-state [lack of] activity.

Regards, Chuck