Rob and Jim,

All good points.

1) Not sure if default wait time is a variable with SWA.
2) BRMS save uses fast positioning, takes append out of the equation.
First seq of control group 20 *SAVSECDTA completed within 3 minutes for both.
3) Sync ID - *none for both 40 *ALLUSR *SYSBAS FFFFFFF *ERR *YES QSYSOPR *NONE
4) I found two other differences.
a) nightly save job ENDTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN), while weekly does not.
b) nightly and weekly are run by different users.
5) Comparing the joblogs from both nights, I noticed that the longer save is only seconds longer for each of the 410 libraries saved, gradually gets longer.

What is the best tool to use for checking/comparing saves, not only times, but amount saved?

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, August 27, 2015 11:09 AM
To: Midrange Systems Technical Discussion
Subject: Re: BRMS nightly save time differences

Object locks. Change the job default wait time down to a ridiculously small interval.
But I did notice that your "different" save is on a Tuesday night.

You could look at the actual joblogs from two different nights to see at what step the gap started widening. You may see messages like:
Save-while-active checkpoint processing for library QMGTC complete.
Cannot use MGTCOL Q01523700 in QMGTC2.
Save-while-active checkpoint processing for library QMGTC2 complete.
1135 objects saved from MPLUS. 2 not saved.
212 objects saved from QUSRDIRDB. 1 not saved.
280 libraries saved, 3 partially saved, 0 not saved.
Starting save of list *LINK to devices TAPKVL01.
Message queue LINK not found.
Object in use. Object is
/QIBM/UserData/OS/AdminInst/admin1/wlp/usr/servers/admin1/logs/console.l
og.
Cannot open object
/QIBM/UserData/OS/AdminInst/admin1/wlp/usr/servers/admin1/logs/console.l
og.
Object in use. Object is
/QIBM/UserData/OS/AdminInst/admin1/wlp/usr/servers/admin1/logs/messages.
log.

...
"Save while active" my sweet Aunt.

Especially since you have the "completed with errors." message.

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: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 08/27/2015 10:47 AM
Subject: BRMS nightly save time differences
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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.

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/







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