Chuck,
Thanks for the feedback.
My previous testing has confirmed that SWA does nothing for IFS objects, only lengthens the SAV time. The wait time you refer to only applies to objects in libraries, not IFS objects. IFS objects do not have a wait time with SWA, it is immediate. If the IFS SWA hits a locked object, it simply skips it and moves on.
Thanks
Paul
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, May 20, 2013 11:25 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: BRMS recovery
On 20 May 2013 19:42, Steinmetz, Paul wrote:
Ending QHTTPSVR subsystem rid all IFS locks (most were log files)
except for 2.
Remember, SWA does not help, only makes IFS save run longer.
<<SNIP>>
The save, just like anything else because object\data integrity requires that, can not break an exclusive lock. Only the lock holder can [be asked to] give up their lock; one way that can be done is to use ENDJOB\ENDSBS\ENDfeature if the feature does not offer an alternative means such as an induced /fail-over/ to an alternate system, file system, and\or database. Change the default wait (DFTWAIT) for the job to reduce the wait timeout for the locks that will never be able to be obtained; e.g. if the only concern is the longer time taken by the SWA for when the those jobs are not ended. The longer time is caused by the lock wait (LCKW) status of the SWA job while trying to obtain the lock prior to obtaining its image\snapshot of those objects+data. A non-SWA save request may use an *IMMED timeout for its locking; i.e. if its exclusive lock can not be obtained immediately, then skip the object.?
The Save While Active needs to see an unchanging copy of the object to get a save. So for a job that holds the exclusive lock that is neither dropped and re-obtained periodically [within the window of the wait time period while the lock was requested by the SWA request] nor was ever forced\requested to drop the lock before starting the SWA, that original\static copy of the object can not be obtained for a save.
Such jobs can be ended to break their lock and allow the save to obtain its locks for the moment that the save obtains its static copy, and then those jobs can be restarted. IIRC that can be effected using /checkpoint/ processing; i.e. notification via a message on a message queue which can be in break mode to handle the event.
The SWA needs and keeps its lock only for the instant required to obtain the snapshot, and then the lock by the SWA is released. And then these other jobs can re-obtain their lock and be /active/ changing the object and data. The non-SWA save keeps the lock on the object until some particular grouping of objects\data [its descriptor] is finished being /dumped/ [aka saved] to media.
I am not sure what\if anything about that explanation of SWA has to do with the QLNKOMT being discussed earlier in the thread.... but hopefully it clarifies what SWA can [not] do with regard to these locked objects. And I must admit my recollection\description is from old design\fix recollections [decades ago], not reflective of any more recent enhancements that might have come since.
--
Regards, Chuck
--
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.
midrange.com
