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