"Queue blocks" (which are actually records in a shared file called qflock.sys) are used primarily by FLOCK.SBR and XLOCK.SBR, and some developer-specific variations of them, as a scheme of keeping track of, or controlling access to, shared resources (e.g. record and file locks). If you are running out of them, either the qflock.sys file is too small, or your application is not freeing up the queue blocks that it uses.

The size and location of the file is defined by the QUEUE statement in the miame.ini. The file is automatically created when the first A-Shell user starts up, and automatically deleted when the last user logs out. That system can be foiled by "phantom" jobs that never log out. If such is the case, and particularly if one of those phantom jobs has allocated queue blocks and never released them, you need to either remove the phantom jobs, manually clear the locks from the qflock.sys, or get all the real users out and then erase both qflock.sys and jobtbl.sys (which will be in the same directory).

Comments and debugging suggestions:

• ABOUT will show you which miame.ini file you are using.

• VUE %MIAMEFILE% will allow you see and edit the current miame.ini file (to determine where the qflock.sys file is, and possibly to increase its size). Note however, that any changes to the QUEUE statement will not take effect until all users have exited and the existing qflock.sys is deleted.

• QUTL has options to display the queue block usage, both in the form of summary totals, and in detailed lists of the locks by type and by user. It also has an option to "zap" a user (remove the user from the system and release the locks held by it). This is one way to get rid of "phantom" jobs.

• SYSTAT/W will display how long each job has been logged in. This is useful for identifying jobs that have been abandoned (i.e. anything over 24 hours might be suspect, at least for a normal, non-background job).

• See XLOCK.SBR and FLOCK.SBR and ABOUT.LIT, SYSTAT.LIT, and QUTL.LIT.

• If you suspect that an application is not freeing the locks that it requests, one way to study it would be to activate the XCALL trace (with SET TRACE XCALL ON or by opening the debug message window and using the properties dialog). This will trace all of the XCALL statements, which would allow you to see just what an application is actually doing in terms of requesting and releasing locks.