SAVLIB(*LIB) means each library is only concurrent to itself, true. There is a STRSAVSYNC which is supposed to help with that.
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaiu/rzaiusavewhileactivesynch.htm
But "ragged" is a whole different thing. With "ragged" not even the objects within a single library is concurrent.
You cannot get a guaranteed concurrent save with SWA without disruption.
Ok, here is a clarification. SAVACT(*SYSDFN) is the "ragged" SWA. This is what we used to use. No checkpoint processing is used. No disruption to business activities.
SAVACT(*LIB) means that only at the library level are the objects in sync. This can be alleviated with STRSAVSYNC. You will have disruption.
SAVACT(*ALL) means that all the objects in all the libraries will reach checkpoint together. While waiting for checkpoint you will have disruption.
Why would you use SAVACT(*LIB) with STRSAVSYNC instead of SAVACT(*ALL)? If you wanted to run multiple saves at the same time. Perhaps to different media libraries or drives within a single media library.
Performance considerations for save-while-active
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaiu/rzaiurzaiu334.htm
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Justin Taylor
Sent: Thursday, April 25, 2019 2:43 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Save while active gotchas: RTVTCPINF times
By "ragged", you mean each library is concurrent to itself, but different libraries might have a different point-in-time snapshot. Is that correct? That wouldn't be a big problem for us.
SAVACT(*LIB) shouldn't extend backup time, right? Assuming no locks SAVACT(*NO) and SAVACT(*LIB) will perform the same, correct?
Thanks
-----Original Message-----
From: Rob Berendt [mailto:rob@xxxxxxxxx]
Sent: Thursday, April 25, 2019 12:52 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Save while active gotchas: RTVTCPINF times
One needs to understand the complexity of save while active, and the documented way of how you are supposed to do it.
There is "save while active" and there is "ragged save while active".
Ideally one should cease all activities against the data until a checkpoint message is received at the appropriate message queue. Then a program, which waits on that message queue, is supposed to start operations back up and allow people in.
Not to get the absolutists mad at me but it's sort of like a point in time flash copy.
If you fail to do it this way you face real risks of data not being at a "point in time" on your save media. For example if I update OrderLine and that transaction is supposed to also update OrderHeader, ItemMaster, CustomerMaster, etc, there is a risk of them not being at the same point with a save while active.
Before we started doing our saves from our HA machine we were using a ragged save while active. My boss said there will be no ceasing of operations on a nightly basis. We were to take the risks. Keep in mind that at that time we also did no journaling.
Main gotcha on SAVACT(*LIB) vs SAVACT(*SYSDFN): If you have interschema dependencies you are then doing a ragged save while active. For example, if a transaction is supposed to update ERPSchema.OrderLine and at the same time update AccountingSchema.GLTransaction SAVACT(*LIB) will not get a point in time capture between the two. Especially if you do not quiesce operations.
But, in general, if you are going to do a ragged save while active and forego ceasing operations until the checkpoint message is received do you care? It's only data and it's expendable.
--
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
