Re: Wait time on a *DTAARA...

On 11-Nov-2011 12:24 , Robert Rogerson wrote:

Last night we had a lock problem due to the backup locking a data
area. I've added code to handle this but during testing I noticed the
message <<reformatted from apparent print screen format:>>
MCH5802 "Lock operation for object UT1505A not satisfied.
Cause . . . . . : The lock operation was not satisfied for object
UT1505A in the specified time interval of 30 seconds. The lock holder
type is 1. The lock holder name is RROGA RROGERSON 149505.
The lock holder thread identifier is X'000000000000010B'. The lock
holder type has the following meaning:
0 - The lock holder is a Licensed Internal Code (LIC) task. The lock
holder name and thread identifier do not apply.
1 - The lock holder is a job.
2 - The lock holder is a transaction control structure. The lock
holder name and thread identifier do not apply.

Can someone tell me where the specified time interval of 30 seconds
comes from?

That really depends on what was the failing operation. But...

The replacement value "30" comes from the "Wait time-out value for instruction" Lock Object (LOCK) which requests to obtain "locks for system objects identified by system pointers in the space identified by operand 1 are allocated to the requesting thread or its containing process or a transaction control structure."
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatk/LOCK.htm

So the job requesting, but not getting the lock, had either explicitly specified a "Wait timeout value" of 30 seconds, or perhaps specified a "special value" which indicates that Resource Management should redirect to the /default wait time/ for the process [or thread; if that value can be different]. Although the "Standard Time Format" seems not to include an example of that special value, nor in text giving "additional information on the format of the wait time-out value for" instructions which support a waittime, I believe a char(8) of all binary zeroes effects that redirect to the default process wait time; i.e. to the DFTWAIT() value as others have noted in prior replies. I believe that to be the case, because I do not recall ever having to extract the job default wait value and then place that into the LOCK template.

So that additional information is relevant, beyond a more generic reply suggesting "from DFTWAIT()", because that means whatever feature requested the lock may provide a means for the user to specify\override the request lock-wait-time. For lack of full message details and\or a description of what was invoked to cause the lock to be requested, I could only guess if there was a means to provide a different wait time value to the unknown\failing feature, than the value which was probably defaulted to the Default Wait.

Regards, Chuck