Re: Re: SAVLIBBRM and the SAVACTWAIT parameter -- MIDRANGE-L

Evan,
Thanks for your response.
I have looked at the use of MONSWABRM, but decided not to go that route. The 
problem there lies in the limit in the SAVLIB command to 300 libraries. This 
means that when you're running an ASP save (i.e. ASP01) where that ASP has in 
excess of 300 libraries (say for example, 500 libs), BRMS actually cuts the 
save into more than one section. So in my example, the first 300 libs get saved 
on one command, the MONSWABRM command kicks in and then the next 200 libs get 
saved on a second command.
Anyway, I digress. The main issue I had was with the reduction of the SWA wait 
time. I played around with this more yesterday and found the key was in the 
SAVCHGOBJ command default parameters. I changed the SAVCHGOBJ SAVACTWAIT 
default parameter to 10 and when I ran the SAVLIBBRM command again, it only 
waited 10 seconds for each locked object. The command I used for changing the 
default parameter to 10 was:
CHGCMDDFT CMD(SAVCHGOBJ) NEWDFT('SAVACTWAIT(10)')
I take your point about 120 seconds not being an issue. The reason I'm trying 
to reduce is because potentially I could have 100+ locks during the backup. 
This would equate to 200 minutes worth of delays, prolonging the save to the 
extent that it will overlap into the online day.... meaning more locks, more 
delays and a very long backup! Of course by reducing the delay, we're likely to 
increase the number of non saved objects, but that's a hit the developers are 
prepared to take.
Thanks again for your help.
John

========================================
Message date : Jul 14 2004, 09:11 PM
>From : "Evan Harris" 
To : "Midrange Systems Technical Discussion" 
Copy to : 
Subject : Re: SAVLIBBRM and the SAVACTWAIT parameter
Hi John

I'm not sure whether this will help you much; I had a similar problem with 
BRMS but I actually wanted to make it wait longer than 120 seconds. 
Personally I wouldn't see a 2 minute wait as an issue :)

In my case I used the SAVWACTMSGQ parameter on the SAVLIBBRM command, 
specifying a message queue monitored by a MONSWABRM command. This was set 
via an *EXIT as the previous entry in the BRMS control group and restarted 
processing when the save while active checkpoint was reached; this actually 
worked better for my purposes than trying to establish a time limit or delay.

I couldn't find anywhere to set or influence the time when I was trying to 
do what you want to do but that's not to say it doesn't exist !

Hope this helps

Regards
Evan Harris

>I'm currently reviewing a backup policy with a view to introducing weekly 
>cumulative SWA backups using BRMS on a development iSeries (on V5R2M0).
>To cater for the cumulative aspect, it will be necessary for me to specify 
>the reference date/time. Consequently, the save cannot be started using 
>STRBKUBRM (as now) and instead the SAVLIBBRM command will have to be used. 
>SAVLIBBRM has the REFDATE/REFTIME parameters that I require.
>The problem is that there appears to be no SAVACTWAIT parameter on 
>SAVLIBBRM. SAVACTWAIT is available on SAVLIB, allowing the wait for locked 
>objects to be reduced from 120 seconds to something shorter. Does anyone 
>know how I can reduce the 120 second SWA wait in SAVLIBBRM.... or is there 
>another way to use BRMS to perform cumulative backups using SWA and a 
>reference date/time?
>John.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

-- 

Whatever you Wanadoo:
http://www.wanadoo.co.uk/time/

This email has been checked for most known viruses - find out more at: 
http://www.wanadoo.co.uk/help/id/7098.htm