×
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 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.
As an Amazon Associate we earn from qualifying purchases.