Rob,
These are library objects, not IFS objects.
I could adjust these BRMS settings below.
Save active wait time:
Object locks . . . . . . . . . . . . 120 0-99999, *NOMAX
Pending record changes . . . . . . . 120 0-99999, *NOCMTBDY, *NOMAX
Other pending changes . . . . . . . . 120 0-99999, *NOMAX
IFS objects have no wait time.
If an application has the IFS object locked, it is immediately skipped, no retry available.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Thursday, April 25, 2019 8:23 AM
To: Midrange Systems Technical Discussion
Subject: RE: RTVTCPINF times
There's also this thing called
CHGJOB DFTWAIT(10)
Really, what, in your backup, is going to free up given between 10 and 120 seconds that wasn't going to free up in 10 seconds or less?
But if it's always locked using QLNKOMT for IFS objects is a good idea.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Steinmetz, Paul via MIDRANGE-L
Sent: Wednesday, April 24, 2019 10:33 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>
Subject: RE: RTVTCPINF times
Justin,
We use BRMS, SWA, both production and r&d.
The only services we stop is HTTP *ADMIN and IBM CDC replication.
A few GUI omits, and some IFS folders set not to save.
RTVTCPINF only takes a few seconds on either lpar.
By default, any library object, if locked, (SWA can't handle all object types), will add 2 minutes.
IBM CDC replication had 30 locked objects, added 60 minutes to save, decided to end that service.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Justin Taylor
Sent: Wednesday, April 24, 2019 10:38 AM
To: Midrange Systems Technical Discussion
Subject: RE: RTVTCPINF times
I doubt the decision was made specifically to save performance data. Most likely, it happened to be saved and caused locking issues. The "easiest" fix was to end performance collection.
This is an situation where it would be beneficial. Since moving from POWER7 to POWER9, our backup times have varied wildly and inexplicably (Monday was 40 minutes, while Tuesday was only 25). I'll see if I can get permission to not end performance collection.
Thanks
-----Original Message-----
From: Jim Oberholtzer [mailto:midrangel@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, April 24, 2019 8:13 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: RTVTCPINF times
Why back up the performance data as part of the normal backups at all? Exclude the *MGTCOL object from the save. What if the performance data is needed to diagnose a problem with the save or other functions running at that time?
Then, later when it's more convenient back up the performance data if you want to. Once a week is plenty.
Performance data is not critical data for a DR or data recovery. It's only value at that point is to assist IBM with forensics if that's needed.
Save it for comparative analysis when doing upgrades hardware or software. Save it for use when you do updates to OEM or internal applications, but it should not be part of the recovery backups if it is disruptive at all.
Jim Oberholtzer
Agile Technology Architects
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
