RE: BRMS SWA creates object lock causing application to fail with CPF1063 followed by RNQ0431 -- MIDRANGE-L

One object, first time we've experienced this error since implementing the app with the data area, Oct 2017.
The data area is holding a copy of a before image journal entry.

Paul

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Evan Harris
Sent: Tuesday, September 08, 2020 5:32 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

Is it just the one object consistently, or more than one on an intermittent basis. How often (and how many) would kind of dictate the approach in my view.

Best practise is to shut the application down, or at least temporarily quiesce it, but you've stated that's not possible, so that's out.

How does the contents of the data area affect the application data if it is saved separately or not saved - does it create a data consistency issue if you restore without that data area, or with the data area saved at a different time ? I suppose in a roundabout way I am saying what is in that data area and how is it used.

Is the data area journaled - would that help at all ?

I've no struck the locking issues you mentioned as my approach is to shut the application down while the checkpoint is reached. If the applications cant be shut down then generally I would move to a HA product and save the replicated data, though that can also have it's own issues in terms of recovering the application at a consistent point.

I am curious about when you restore the saved library - does the application run some kind of internal consistency process to get everything in line ?

On Wed, Sep 9, 2020 at 9:09 AM Steinmetz, Paul via MIDRANGE-L < midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

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/rzaiurz
aiu319.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

--

Regards
Evan Harris
--
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
--
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