QUEUE=<Blocks>,MEM: | DISK:<Filespec>

UNIX Example:                QUEUE=100,MEM:C:\VM\MIAME\QFLOCK.SYS

Windows (or UNIX) Example:   QUEUE=100,DISK:C:\VM\MIAME\QFLOCK.SYS

A-Shell, like AMOS, uses a pool of "queue blocks" to keep track of locks and other shared system resources. While AMOS uses the queue for a variety of operating system functions, including LOKSER, A-Shell uses it primarily just for maintaining locks placed by XLOCK, FLOCK, and similar custom locking subroutines. (LOKSER-style locks are handled directly by the native operating system.) Thus, the required number of queue blocks is simply the maximum number of concurrent XLOCK and FLOCK (or similar) locks. Specifying an unnecessarily large queue file will have a minor impact on performance.

The queue may reside either in memory (MEM:) or on disk (DISK:), though as of A-Shell 4.8, memory based queues are only supported under the UNIX versions of A-Shell. (A-Shell 4.9 adds the capability for A-Shell/Windows.) Memory queues are quite a bit faster, but this is not significant unless your application makes a large number of XLOCK or FLOCK calls.

Whether QFLOCK is disk-based or memory-based, a complete pathname (including filename) must be given. The name is usually qflock.sys, and it must reside in a directory accessible by all users, typically the same directory where the shared miame.ini file is located. Memory based queues are implemented under A-Shell/UNIX as memory-mapped files, so even though all accesses are performed in memory, the file will appear in the directory. (In addition, a small control file named qflock.lck will be created in the same directory.)

Notes

The QUTL.LIT utility may be used to display the contents of the queue, as well as to manually remove locks placed by another user.

The queue file is created automatically by the first user to launch A-Shell, and deleted automatically by the last user to exit (provided there are no locks currently in use). On a normal exit, A-Shell will purge the queue of all locks owned by the current user, but if a job or user should crash out of A-Shell for whatever reason, locks may be left in the queue. (Use QUTL.LIT to manually remove such locks.) Should the queue file become corrupted, it can always be removed manually (provided it is not currently in use) since the next user will recreate it.

Prior to Build 4.6, the QFLOCK.SYS file also held two records for each job which functioned like the job table records under AMOS. As of Build 4.6, this information is now kept in a separate file called jobtbl.sys.

The jobtbl.sys file is also created and deleted automatically alongside qflock.sys. (See MAXJOBS.) If, for some reason you have to manually delete one of them, it is best to delete them both.

Warning: Although these files will be recreated automatically, they should not be removed while there are active users! Removing a disk based (DISK:) qflock.sys will cause all locks for any current users to disappear. Removing a disk based jobtbl.sys file will cause existing users to abort with a "jobtbl/queue zapped" error the next time they execute a command or perform any function that updates the job accounting information. Removing memory based (MEM:) versions of these files (by deleting them from the disk directory) will not appear to affect currently running users, since they will continue to use the copy in memory. However, the next user to launch A-Shell will create new copies of these files in memory, leading to a situation where there are two (or even more) "pools" of users that don't know about each other. Locks placed in one "pool" will not be visible in the other, which could lead to file corruption due to locking failure. So if there are any users currently running A-Shell (even if they appear to be "dead") it is preferable to manually remove the users (either with the QUTL.LIT "ZAP" function or via the operating system) before deleting the jobtbl and qflock files.

The maximum number of queue blocks is 65,535.