Re: AJS lock issue caused by 8=Change command list

On 05-Nov 11:28 , Steinmetz, Paul wrote:

I checked the AJS command list file,
QUSRIJS/QAIJS1CM, WAITRCD set to 60.
All the AJS files are set to 60.
Maximum record wait time . . . . . . . . . : WAITRCD 60

I then checked the QIJSSCD monitor job for overrides.

The output <mostly snipped from quoted text below> seems to show a large number of the Advanced Job Scheduler files with the OVRDBF explicitly effecting WAITRCD(600) so they *really want to wait* that long for those files... but for what reason, is anybody's guess. And having implemented that via overrides vs simply using that parameter as obtained from the file, that makes any attempt to influence\override their implementation very difficult :-( IMO, a poor design [or implementation decision, versus having simply changed the files].

The command list file was not listed, probably one of the others is
causing the lock.

Or I suppose if there are ten commands in the scheduled entry, and all of those command-as-row are locked, and they keep trying to get the next record with each timing out as 60 seconds, or similarly trying ten times for just one locked record, that would add up to 10 minutes :-)

The joblog might show the details [the lock exception and thus the file name], even if only logged for a moment before the processing deletes the exception as part of its recovery. But that long wait also allows significant amount of time to DSPJOB OPTION(*JOBLCK) to review for record locks in the WAIT status. DSPRCDLCK QUSRIJS/QAIJS1CM could be performed to see that the opt-8 requester is the holder, and the output would also show if other job(s) have status WAIT; if so, then the program stack [and cmtctl info; of the job doing opt-8 too] of the other job can be reviewed to see what it is doing. Such a review can help infer more about the apparent design [intention].

Hmm... I recall there is another feature that was handy for record locks, but I can not recall what it was... OK, never mind... I looked, and found the Check Record Locks (CHKRCDLCK) command. That is not helpful here.

Waiting for update from IBM.
AJS is an IBM product, but development is 3rd party.

Ugh! I am all too familiar with that particular situation :-( Sure does delay any feedback.

Opt File Level Type Keyword Specifications
QAIJSWFS 5 DB TOFILE(QUSRIJS/QAIJSWFS) WAITRCD(600)
<<SNIPped many others>>
QAIJSMST 5 DB TOFILE(QUSRIJS/QAIJSMST) WAITRCD(600)

Given the feature has probably been functioning the same probably since its inception, unless others have reported a similar concern, I would guess the answer might end up being along the lines of the helpful-doctor reply.... "Best you _don't do that_ if it hurts" :-)

Regards, Chuck

CRPence on Tuesday, November 05, 2013 1:45 PM wrote:

<<SNIP>>

I do not know what 8=Command List does, but it seems to me that
another possible approach is to determine if it even makes sense
that the opt-8 action should hold the record lock(s) "until the
8=command list is exited." Of course the actual
design\implementation dictates what occurs, but a logical inference
from a reviewer perspective is worthwhile to consider\suggest...
just as much as suggesting a shorter wait time.

As for the timeout, what is the _Maximum record wait time_
(WAITRCD) setting on the file? Apparently WAITRCD(600); per DSPFD
results? If so, that implies the effect is likely customizable
without any code or definitional changes to the feature; i.e.
effect CHGPF [or CHGLF] WAITRCD(1) to specify your own desired
effect.