Answers in-line.
If stopping the application is out of the question you are in kind of a tricky spot, though making things wait longer for a lock might help. My own experience on waits is that they only ever get longer and eventually exceed what's been allocated anyway.
Some questions:
- is the SWA across all the libraries, i.e. do you have everything in one gigantic checkpoint ?
one giant check point - BRMS *ALLUSR
- How long does it typically take to get a checkpoint ?
Checkpoint reached in 2 1/2 minutes for this library.
- What does "I know data areas are excluded from SWA." mean - do you exclude data areas from your save, or something else ?
BRMS SWA has no impact with data areas because of the data area locking rules. see note 6
An internal lock is also held that prevents changes to the object during save-while-active checkpoint processing.
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzaiu/rzaiurzaiu319.htm
- Would it be possible to save the library containing the problem data area (if it's only one) individually to shorten the checkpoint time ? i.e.
too many other dependencies and changes if save was changed.
do two SWA's
Possible solutions.
1) Put a loop on the code where the data area is read in. We've done this before in other applications.
2) Let the error occur, create a Halcyon monitor for the RNQ0431, auto answering with a 'G', however results could be unpredictable.
3) Covert the data area to a PF, (PF do not have the note 6 locking rule issue)
4) Implement an HA solution, then save on HA LPAR.
Paul
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Evan Harris
Sent: Tuesday, September 08, 2020 4:12 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: BRMS SWA creates object lock causing application to fail with CPF1063 followed by RNQ0431
Hi Paul
If stopping the application is out of the question you are in kind of a tricky spot, though making things wait longer for a lock might help. My own experience on waits is that they only ever get longer and eventually exceed what's been allocated anyway.
Some questions:
- is the SWA across all the libraries, i.e. do you have everything in one gigantic checkpoint ?
one giant check point - BRMS *ALLUSR
- How long does it typically take to get a checkpoint ?
- What does "I know data areas are excluded from SWA." mean - do you exclude data areas from your save, or something else ?
- Would it be possible to save the library containingg the problem data area (if it's only one) individually to shorten the checkpoint time ? i.e.
do two SWA's
Possible solutions.
1) Put a loop on the code where the data area is read in. We've done this before in other applications.
2) Let the error occur, create a Halcyon monitor for the RNQ0431, auto answering with a 'G', however results could be unpredictable.
3) Covert the data area to a PF, (PF do not have the note 6 locking rule issue)
4) Implement and HA solution, then save on HA LPAR.
On Wed, Sep 9, 2020 at 1:56 AM Steinmetz, Paul via MIDRANGE-L < midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
During our nightly BRMS full SWA, one of our applications experienced
CPF1063 - Cannot allocate data area JRNPGM01 in library BRCPGMS
followed by a RNQ0431 - Data area *LIBL/JRNPGM01 was allocated to
another process (C G D F).
BRMS was in the process of doing its check point processing for this
library, BRCPGMS. The check point processing only lasts for a few minutes.
The application needed to update the data area, but it was locked by
the save, the application went into MSGW.
I know data areas are excluded from SWA.
I can create a monitor that would automatically answer the RNQ0431
with a G, which would allow the application to continue without going into a MSGW.
Any recommendations from the group on handling locks caused by BRMS
causing applications to fail.
Stopping the application is not an option.
Excluding the object from the save is not an option.
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 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@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
midrange.com
