The AMOS version of XLOCK.SBR has a bug in which an attempt to get a wildcard lock (e.g. X,0) will appear to succeed (i.e. return MODE 0) even when you already have a conflicting lock (X,Y). One could argue whether a lock previously set by the same user should be considered a conflict or not, but it is hard to justify returning a status of success when the wildcard lock was, in fact, not set due to the conflict. Yet, in the rarified world of programming, there are those that consider this a feature rather than a bug. For those, we have the AXLOCK option, which causes A-Shell to copy the AMOS bug. For all others, the default behavior is to return an error status (MODE set to your own job number) to indicate that there was a conflicting lock, set by yourself, and that the wildcard lock request was not set. Note that there is a similar issue relating to how to handle a request to obtain a lock that you already have, for which the MXLOCK switch was created.