Re: When does Save While Active (SWA) (with BRMS) checking pointing begin?

Charles:

My first point was to make it easier to find the messages, in a message queue called BACKUP. You can find all the message in QHST or the BRMS logs for that matter, it is just easier with a dedicated message queue.

It is the retain object detail, and yes I agree that it does not seem to fly with the intent of the *SYNCDFN, but the way I have seen the behavior of BRMS it holds the locks for some reason. You are not the first to have found this out with non-database objects. I have even seen it hold databases long after I would have thought the lock would be released, the problem in each case as the number of objects that are included in the synchronization gets larger the longer the lock is held. OK up to a point but SWA does not seem to release the lock when you would expect it to. The way I get around that problem is to create back up lists and process each list (specifying libraries in them) and group the libraries according to the sync needs. Keep the list of objects as low as possible.

I know that does not square with how we would surmise is should work but that has been the behavior for at least three versions of the OS.

I have not successfully been able to explain that phenomenon.

*OBJ is what you want, I confused that parm with another when I was writing the post. Only object detail is kept, not member level which is not as useful as it could be unless you are referring to source files.

Jim Oberholtzer
CEO/Chief Technical Architect
Agile Technology Architects, LLC


On 5/26/2010 3:57 PM, Charles Wilt wrote:

*This message was transferred with a trial version of CommuniGate(r) Pro*
On Wed, May 26, 2010 at 4:04 PM, Jim Oberholtzer<midrangel@xxxxxxxxxx> wrote:

Charles:

The best way to know that is to use a message queue for backups only. I
always use "BACKUP" and I put it in QUSRSYS. On the control group
specify BACKUP and all the checkpoint messages will go there for that
line in the control group. I always use the same message queue on every
line in the control group. Now all the checkpoint messages will be sent
there and it's easier to figure out. Lacking that I'll bet the
messages are in message queue HLTHPRDFIL.

Not sure what your point is here. I've got all the checkpoint
messages and included them in the original post.

Granted I pulled them from QHST, as the BRMS control group is
configured to send the messages to QSYSOPR, but I did double check
that the messages matched in both places. I realize that's not the
best queue to use, but I unfortunately didn't set it up and am
unlikely to get the messages sent to a dedicated queue.

Since you are using the *OBJ parm in the control group I suspect the
checkpoint is being held until the entire control group finishes thus
causing your problem. The check point is reached across all the objects
in the control group line before the save actually commences, so in the
case below I suspect it is about 23:01 or so and is not getting released
until the control group finishes. I don't know why this behavior
happens but I have seen it before.

What *OBJ in the control group are you referring too? The "Retain
Object Detail" attribute?

Still I'm not following what you are saying. The control group doesn't
finish being saved till 03:10. The first checkpoint message is
received at 23:01 the last at 3:10. Unless you are saying the system
is holding the checkpointing in-progress lock till it has checkpointed
everything. But that doesn't seem to square with the definition of
*SYNCDFN.

*LIB will go a long way to helping out your issue, and all you will
loose is some detail in the BRMS database.

What detail would we lose?

Thanks!
Charles Wilt