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

Chuck,

Good idea.
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 command list file not listed, probably one of the others is causing the lock..
Waiting for update from IBM.
AJS is an IBM product, but development is 3rd party.

Opt File Level Type Keyword Specifications
QAIJSWFS 5 DB TOFILE(QUSRIJS/QAIJSWFS) WAITRCD(600)
QAIJS2WF 5 DB TOFILE(QUSRIJS/QAIJS2WF) WAITRCD(600)
QAIJS1WP 5 DB TOFILE(QUSRIJS/QAIJS1WP) WAITRCD(600)
QAIJSWPC 5 DB TOFILE(QUSRIJS/QAIJSWPC) WAITRCD(600)
QAIJS2MJ 5 DB TOFILE(QUSRIJS/QAIJS2MJ) WAITRCD(600)
QAIJS1MJ 5 DB TOFILE(QUSRIJS/QAIJS1MJ) WAITRCD(600)
QAIJS1RC 5 DB TOFILE(QUSRIJS/QAIJS1RC) WAITRCD(600)
QAIJSRCP 5 DB TOFILE(QUSRIJS/QAIJSRCP) WAITRCD(600)
QAIJS1ES 5 DB TOFILE(QUSRIJS/QAIJS1ES) WAITRCD(600)
QAIJSESC 5 DB TOFILE(QUSRIJS/QAIJSESC) WAITRCD(600)
QAIJSME 5 DB TOFILE(QUSRIJS/QAIJSME) WAITRCD(600)
QAIJS3MG 5 DB TOFILE(QUSRIJS/QAIJS3MG) WAITRCD(600)
QAIJSSCD 5 DB TOFILE(QUSRIJS/QAIJSSCD) WAITRCD(600)
QAIJS1LB 5 DB TOFILE(QUSRIJS/QAIJS1LB) WAITRCD(600)
QAIJS1PR 5 DB TOFILE(QUSRIJS/QAIJS1PR) WAITRCD(600)
QAIJS1PC 5 DB TOFILE(QUSRIJS/QAIJS1PC) WAITRCD(600)
QAIJSSD 5 DB TOFILE(QUSRIJS/QAIJSSD) WAITRCD(600)
QAIJSSC 5 DB TOFILE(QUSRIJS/QAIJSSC) WAITRCD(600)
QAIJS4HS 5 DB TOFILE(QUSRIJS/QAIJS4HS) WAITRCD(600)
QAIJSHST 5 DB TOFILE(QUSRIJS/QAIJSHST) WAITRCD(600)
QAIJSOD 5 DB TOFILE(QUSRIJS/QAIJSOD) WAITRCD(600)
QAIJSAD 5 DB TOFILE(QUSRIJS/QAIJSAD) WAITRCD(600)
QAIJSPCR 5 DB TOFILE(QUSRIJS/QAIJSPCR) WAITRCD(600)
QAIJS7MS 5 DB TOFILE(QUSRIJS/QAIJS7MS) WAITRCD(600)
QAIJS6MS 5 DB TOFILE(QUSRIJS/QAIJS6MS) WAITRCD(600)
QAIJS4MS 5 DB TOFILE(QUSRIJS/QAIJS4MS) WAITRCD(600)
QAIJS2MS 5 DB TOFILE(QUSRIJS/QAIJS2MS) WAITRCD(600)
QAIJS1MS 5 DB TOFILE(QUSRIJS/QAIJS1MS) WAITRCD(600)
QAIJSMST 5 DB TOFILE(QUSRIJS/QAIJSMST) WAITRCD(600)


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, November 05, 2013 1:45 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: AJS lock issue caused by 8=Change command list

On 05-Nov 08:43 , Steinmetz, Paul wrote:

Ran into an issue with AJS record locking.
If in a job's 8=Change command list, that job will not be submitted
due to the record being locked by the interactive user, AJS monitor
job, QIJSSCD goes into a *LCKW status for 10 minutes.
During this 10 minute window, any other scheduled AJS jobs that should
have run are not submitted because the QIJSSCD job is in a *LCKW
status.
After 10 minutes, IJS6009 is posted, and the scheduled jobs from above
are submitted.
The QIJSSCD job then goes into a 2nd 10 minute *LCKW, trying for the
locked job.
This will continue until the 8=command list is exited.

These 10 minute delays caused other AJS production jobs to be run
later than scheduled, causing production issues. IBM development is
checking to see if this 10 minute lock could be changed.
I'm suggesting changing the 10 minutes to 1 second.

Any thoughts from the group?

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.