× 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.



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.


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.