Re: Wait time on a *DTAARA...

[CRPence <CRPbottle@xxxxxxxxx>]

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