My inherited customer's original programmer used the ISAM-A locking mechanism which I am not familiar with and can't find a remedy in the documentation.
I am getting a FILE IN USE @ 2240 in a program. So I know the filename. But I have no idea where or when it was locked.
Its not an ISAM file but just a file called CASH.DAT and is used in a dozen programs opened as RANDOM or RANDOM'FORCED with READ #6 and WRITEL #6.

Is there a method by which I could universally unlock the file?
Is there a way I can find out what records (or other files) are locked?
What do I use to unlock the file and record if I can find out the record #?

The locking mechanism you're describing is not ISAM-A but LOKSER. When enabled (typically in the miame.ini), files open RANDOM are locked for exclusive use, while those opened RANDOM'FORCED are shared. The error FILE IN USE (37) occurs when one user has a file open opened exclusive and another tries to open it, or when you try to open a file exclusive and one or more other users already have it open for shared access.

For files open RANDOM'FORCED, record level locks are placed by using READL instead of READ. (WRITE unlocks a record previously locked with READL, and WRITEL is used to lock/write/unlock a record that was not previously read, i.e. when adding new records to a file.)

Under A-Shell, LOKSER is implemented via the native operating system file locking system. Unfortunately, unlike the case with XLOCK and FLOCK locks (which are entirely controlled by A-Shell), system locks are not that easy to monitor or remove. In the Linux environment, you can use LOKUTL (which wraps around the not-quite-universal lslk Linux shell command) to get a list of locks, but I'm not aware of any standard Windows equivalent. However, the Windows Computer Management utility does provide a view of Open Files. And most Window Server editions will also allow you to terminate sessions. But that's a pretty blunt instrument for management multi-user conflicts like this.

CASH.DAT is most like the cash receipts file, and it would be typical of AlphaACCOUNTING to require exclusive use, i.e. only one person entering cash receipts at a time. So you are convinced that some rogue user has the CASH.DAT file open and you want to force it to be closed, your best bet is probably to us SYSTAT to identify which programs/users are running, and based on that (and knowledge of the application, which in your case might be tricky to acquire), figure out which user to either call on the phone, or if necessary, to terminate using the KILL command. Note that any locks owned by a process will be freed by the OS when the process terminates.

This won't help after the fact, but if you want to get an understanding of which files are opened by which programs, you might want to add the TRACE=FOPENS option to the miame.ini (or use SET TRACE FOPENS ON at the dot, which will log all file opens and closes to the ashlog.

Another tip, which is probably too extreme to be practical, but good to know, is that if you disable LOKSER, then there won't be any such file locking. So if you're having problems with file locking even in single-mode, that might suggest that the application wasn't actually written to use LOKSER, in which case disabling might make sense. But in that case you're asking for trouble if multiple users access it at the same time, unless you become convinced that the app is actually using XLOCK or FLOCK instead. (You can use the XCALL TRACE, or QUTL, to monitor XLOCK/FLOCK operations, and there is also a RW TRACE which will show you whether the app is use READL/WRITEL or simply READ and WRITE, and thus whether it is build around the LOKSER framework or not.)

I never used LOKSER because we started with XLOCK and had no reason to redo all of the code we had already written. But now I understand it a little.
Here is what I found in the program generating the file in use error. I don't know why it never had this error on the alpha.

02580 OPEN #6, DEVICES(6)+":CASH.DAT", RANDOM, RECSIZ6, FILE6
02590 OPEN #13, DEVICES(6)+":CASH.DAT", RANDOM, RECSIZ13, FILE13

Every other program opened these files RANDOM'FORCED and used READ & WRITEL so that is what I changed it to do in this program.

Questions:
I can' see anywhere on the old Alpha where LOKSER was turned on. Maybe it is just ON and if you don't use it it doesn't matter. Does anyone know where to look?
Does it seem right to use READ (not READL) and WRITEL?

It sounds like you found some source code?

Obviously there had to be a way to avoid using LOKSER, else most pre-LOKSER code would have reverted to only working in single-user mode, and code like the above (opening the same file under two different channels) would have been impossible. But after searching both my set of AMOS docs and the deep recesses of my matière grise I was unable to come up with anything definitive. My best guess though is that it depended on the version of RUN you were using, i.e. RUN (1.4) or RUNP enabled it, while ORUN (1.3) didn't.

As you suggest, one workaround for programs that were written to use some other locking mechanism (e.g. XLOCK or FLOCK) but were later forced to run with LOKSER enabled, is to change all of the RANDOM opens to RANDOM'FORCED, and all of the WRITE statement to WRITEL. (Presumably there wouldn't be any READL's needing to be changed in such pre-LOKSER programs.) That should "work" in the sense of not running afoul of LOKSER rules, but it undermines any multi-user protection that LOKSER was designed to provide. Which is to say that such programs would not be safe to run in a multi-user environment without modifications to add some other kind of locking. Whether it makes sense, or would be easier for you to implement XLOCK-style vs LOKSER-style locking while editing those program is an open question.

Note that in most environments, the vast majority of the programs in an accounting suite like AlphaACCOUNTING are intended to run in single user mode anyway. (Anything involving batches, e.g. cash receipts, payables, journal entries, etc. would definitely be hard to manage with multiple users working on them simultaneously. Likewise with financial reporting, which is usually handled by a single bookkeeper / accountant.) So my guess is that there are only a few programs in the suite that really need much attention. (Customer maintenance might be an example.)

The fact that there are any READL statements in the code suggests that it was already designed to work with LOKSER, which would argue that it would be less work to just stick with that method, rather than convert it to XLOCK. The only conflicting evidence is the example with the same file being opened twice. That seems like an anomaly (definitely not something that you would find in "standard" AlphaACCOUNTING). Now that the memory circuits are getting warmed up, I vaguely recall that LOKSER under AMOS may not have prevented a single user from locking herself out of a file, so that may have been perfectly legal under AMOS, even with LOKSER. Which would explain how that program was able to run under AMOS with LOKSER. Unfortunately, since the LOKSER implementation under A-Shell relies on the native operating system, we are somewhat at the mercy of the fact that neither Windows nor Linux provide a free pass for locking conflicts created by a single user, i.e. there is nothing stopping you from locking yourself out of a file or record.

If that is accurate, then the simplest fix is probably to do more or less what you suggested, i.e. convert RANDOM to RANDOM'FORCED (for just that file), and then establish an exclusive lock on the file (to prevent other users/programs from accessing it) by some other method, perhaps XLOCK. (CASH.DAT is probably not used in may programs, so adding a few lines of XLOCK code to each of them to limit only one to accessing that file might be easy enough.)

Hi Joe, I'm not sure if this will help, but I have a copy of the AMOS File Locking User's Manual from 1998. Here's a Dropbox link to it:

AMOS File Locking User's Manual

If the link doesn't work, I will email it to you.

Yes that was useful. LOKSER was automatically active on AMOS so it is appropriate to use LOKSER=ON in this Ashell environment. I fixed the one program that had the bug and there haven't been any others reported so I think we are good to go.

You don't happen to have an Alpha-Lan manual? I would love to know how it works with printers. I haven't figured that out yet.

Give me a call and we can catch up. 215-237-2602

The AlphaLAN manual is built into its Help menu. Select Help, then Index or Contents.