Re: BRMS nightly save time differences

On 27-Aug-2015 08:46 -0600, Steinmetz, Paul wrote:

On our Production LPAR, every night at 22:00, I run a full BRMS save
SWA.

Cause . . . : Command to execute is: STRBKUBRM CTLGRP(SAVFULL05)
SBMJOB(*NO) APPEND(*YES) ACTIVITY(*CTLGRPATR) RETENTION(*DAYS 45).

BRM16A1 Diagnostic 40 08/27/15 00:22:55.539417 Q1AC0SLIB QBRM *STMT Q1ARBK QBRM *STMT
Message . . . . : Backup *ALLUSR, type *FULL completed with errors.
for sequence 57372,

Once a week, same time, we run a different job using the same control
group with different retention overrides and move policies.

Cause . . . : Command to execute is: STRBKUBRM CTLGRP(SAVFULL05)
SBMJOB(*NO) APPEND(*YES) ACTIVITY(*CTLGRPATR) RETENTION(*DAYS 396)
MOVPCY(CYCBRC396).

BRM16A1 Diagnostic 40 08/25/15 00:10:34.356003 Q1AC0SLIB QBRM *STMT Q1ARBK QBRM *STMT
Message . . . . : Backup *ALLUSR, type *FULL completed with errors.
sequence 18100

The once a week *ALLUSR part of the save is consistently 10 to 15
minutes faster than the daily save.
During the backup window, no batch jobs, only a handful of
interactive users.

Why would a retention override result in a performance improvement
during the *ALLUSR? *ALLDLO and *LINK times are the same.
We do append, sequence numbers are higher for the nightly save
compared to the weekly save.

The speculation that the RETENTION() specification is related almost surely would be disproved by testing with the same specification as the other request. Conspicuously, no mention was made of the Move Policy (MOVPCY) change visible between the two requests. The seek-time to sequentially locate the larger sequence number [as seen on the prior day] and the differences for "with errors" [presumably being allocation errors] alluded in other replies are both much more and very likely to be an origin for the difference in time-taken than the retention specification. However there are also nuances like faulting vs paging that can be [even wildly] different according to prior activity earlier that night; faulting statistics could be compared spanning the request between the once-a-week and the others.