Rob,
I found this when working with IBM on another issue where my DUPMEDBRM for month end failed, 2 out of the last 3 months.
Coincidently, month end saves from two LPARs both ended within the same minute.
Thus both DUPMEDBRM were trying to start with in the same minute.
For the DUPMEDBRM that failed, BRMS did not wait long enough for the destination volume to be loaded, thus failure occurred.
IBM suggested I put a delay in, to increase the 30 seconds.
When researching, If I was using IBM default of 120, probably would not have had the failure.
Conclusion.
1) QBATCH was changed decades ago, probably for the reasons you mentioned, and more.
2) What is your QBATCH default wait time set to?
3) Since my DUPMEDBRMs run in their own jobq, jobd, BRMSD, I could create a class only for the DUPMEDBRM jobs.
I use auto dup, so I don't have the normal control over these jobs as I would a normal job.
Otherwise, I could code a CHGJOB DFTWAIT(120).
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, April 07, 2015 10:33 AM
To: Midrange Systems Technical Discussion
Subject: Re: Class - Default wait time in seconds for batch jobs
In general 30 seconds should be plenty enough time. Actually 5-10 seconds should be plenty of time. Most items that are locked over 10 seconds will be locked for a longer stretch of time.
A backup can stretch out for hours longer if this is not used correctly.
For example, if you try that ridiculous save-while-active and you put a 2 minute wait time there could be 200 stream files with a lock that save-while-active can't even get around. 200 times 2 minutes is 6.75 hours, while 200 times 10 seconds is only slightly over a half of an hour.
I think you'd be better served by trying to determine why BRMS is taking so long.
- Are you running too many backups at the same time thus causing tape drive contention?
- Are you using autoclean and it's trying to clean during backup?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/07/2015 10:20 AM
Subject: Class - Default wait time in seconds for batch jobs
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
I recently was verifying my class entries for my various subsystems.
We don't start QINTER or QBATCH, we have custom for both.
All my interactive subsystems use either QINTER class or a copy of QINTER,
Default wait time set to 30.
However, in all our batch subsystems, I'm seeing a class with Default wait
time of 30, normally batch is 120.
Decades ago, I'm not sure if this was an oversight, or if someone
determined that Default wait time for batch should be 30 instead of 120.
I recently had a BRMS batch job fail, failure was a timing issue, probably
would not have failed if was set to 120.
Any thoughts from the group on what batch default wait time should be?
Default wait time
Shows the maximum wait time (in seconds) that a thread in the job
waits for a system instruction, such as the lock machine interface
(MI) instruction, to acquire a resource. This default wait time is
used when a wait time is not otherwise specified for a given
situation. Normally, this would be the amount of time the system
user would be willing to wait for the system before the request is
ended.
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/
midrange.com
