× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

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.

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

Another suggestion is if you have a program that creates the data areas for you, is to exclude them from the back up. If the data is recreateable and the data areas can be created by running a program then your recoverability is covered. Simply run that program as an exit in the recovery control group. Not great but it'll get you past this error. (data queues are in the same boat)

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


On 5/26/2010 1:30 PM, Charles Wilt wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
Hoping a backup/recovery (BRMS?) guru out there can shed a little
light on what's going on here..

--------From the joblog (job name SV_PROD)------------------
23:00:00 STRBKUBRM CTLGRP(SV_PROD)
23:00:29 Starting save of library HLTHPRDFIL
23:00:29 Starting save of library HLTHPRDPGM
23:00:29 Starting save of library PRCPRDFIL
<others snipped>
03:10:24 3519 objects saved from library HLTHPRDFIL
03:10:24 4967 objects saved from library HLTHPRDPGM
03:10:25 506 objects saved from library PRCPRDFIL
<others snipped>


-------From QHST (and SWA msgq )-------------------
23:01:22 Save-while-active checkpoint processing for library HLTHPRDFIL complete
02:27:23 Save-while-active checkpoint processing for library
HLTHPRDPGM complete.
02:28:21 3519 objects saved from library HLTHPRDFIL.
02:29:22 Save-while-active checkpoint processing for library PRCPRDFIL complete.
02:29:25 4967 objects saved from library HLTHPRDPGM.
02:25:52 Save-while-active checkpoint processing for library<snip> complete.
02:35:53 506 objects saved from library PRCPRDFIL.
<others snipped>
03:13:46 BRMS backup job SV_PROD ended on S10316ZM

The libraries in the BRMS group are all defined with SWA = "By
Object". Which as I understand it is the same as *SYSDFN on the
SAVACT parameter of the SAVLIB command. (Yes, I know that *SYSDFN is
a bad idea and I've pointed it out to management)

My question...
When does checkpoint processing begin for the 2nd library in the
group, HLTHPRDPGM?

Looking at the above, I would say that the answer is (basically) after
the objects are in saved 1st library, HLTHPRDFIL.

However, at 02:02 we had an RPG program attempt to use a data area in
HLTHPRDPGM and not be able to because it was locked. The RPG program
in question is the only one that would access the data area, so I can
only assume that the data area was locked because the checking
pointing of HLTHPRDPGM hadn't completed which would lead me to
conclude that checkpoint of all the libraries started at 23:00. But
then why, especially with SWA = *SYSDFN, would checkingpointing not
finish on HLTHPRDPGM till 02:27:23 when most of the objects in it are
*PGM, DSPF, PRTF, and some *DTAARA?

Thanks!
Charles Wilt

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.