We are experiencing an issue with one of our customers where an Out Of Queue Blocks message is displayed. This started today and has happened twice. At first, we suspected that something was not getting unlocked (we use XLOCK extensively). The second time it happened, we ran QUTL and chose STATUS. It reported 0 free queue blocks and 0 total queue blocks. I have activated the QOP trace on their system. Is there any other trace I should turn on in addition?

A-Shell Version: 6.5.1672.1 (EL7)

Thanks,
John Andreasen
Diversified Data Solutions

John - if i am not mistaken this can also happen if you are opening lots of files. We have a program that will open a ton of tmp files for a report and we had to increase the queue blocks to accommodate this... i am sure Jack will chime in but i believe every open file uses 500 queue blocks.

I would start with the XLIST option on the QUTL utility menu, which lists all of the individual xlocks. Hopefully that will product an AHA! moment where you suddenly recognize where all the xlocks are coming from. For example, it could be one rogue program, job, or user that is responsible for most of the usage. Or, as Frank suggests, it might just that there has been a steady increase in the number of files opened. (Of course XLOCK does not explicitly identify the resources being locked, but it is common to use the first value for the file channel and the second for the record number.)

It may just be that you need to increase the QUEUE statement value in the MIAME.INI to account for a steady upward creep in usage.

Thank you both. Next time, we'll run XLIST to verify what locks exist. We use the channel / record number scheme, so it should be easy to identify the file that is being locked that is causing the issue.

After working with Jack, we figured out this issue can be reproduced by disconnecting the ATE client as soon as possible once the ATESYC dialog appears from within an ATESYC call. I wanted to post here in case anyone else runs into this.

Running QUTL STATUS after disconnecting reveals the following:
A-Shell Queue system status information is as follows:

Queue version:
Total number of queue blocks: 0
Max recs used (highwater): 0
Total add/delete operations: 0
Total qblock reads: 0
Total qblock writes: 0
FLOCK.SBR locking blocks: 0
FLOCK.SBR inactive blocks: 0
XLOCK.SBR locking blocks: 0
Unknown or corrupt blocks: 0
Number of free queue blocks: 0
Number of job table entries: 3
Press the RETURN key to continue

The affected version of ATESYC is 1.3(119) / 721-735-144-172. Upgrading to 1.3(121) / 420-251-400-077 appears to have solved the issue (at least in my development environment).

I wasn't able to locate an old copy of that version, but like you I'm unable to reproduce the problem with the current 1.3(121) version of ATESYC.SBX, using A-Shell 6.5.1688.5.

Note that 6.5.1688.5 fixes a loophole in which a queue failure (such as out of queue blocks, or other corruption) failed to return an error code in XLOCK.SBR, which may have made the above situation harder to diagnose.

Here's a beta version for testing:

ash-6.5.1688.5-el7-upd.tz
ash65notes.txt