Re: BRMS SWA creates object lock causing application to fail with CPF1063 followed by RNQ0431

If I read your message correctly, you would create a monitor which effectively tells the program not to update the data area? That does not sound sensible to me. Isn't replying G to an RPG message somewhat unpredictable?

Probably you should change. the application to wait longer to get a lock on the data area. Possibly with and ALCOBJ/update-dtaarea/DLCOBJ sequence. If the update is done only once, or infrequently per program execution, then it shouldn't impact performance.

Seems like this came up before with BRMS, but I found no responses:
https://archive.midrange.com/midrange-l/201010/msg00822.html

Another thread with a looping solution here:
https://archive.midrange.com/rpg400-l/200505/msg00082.html

Sam



On 9/8/2020 9:56 AM, Steinmetz, Paul via MIDRANGE-L 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/