6

Near 21-22 years ago I worked in a COBOL-based shop. This business had one LOB application written in RM/COBOL-85, and deployed it to multiple customers with different network types (Xenix with dumb terminals, Windows NT Server to Windows 98 clients, Netware server to DOS clients).

One thing that amazed me about this application is that it supported DB row-level locking. The database where just one ISAM and one index file per table, all stored in a network share, mapped in the client computers as a networked drive (except in Xenix, but this is another history).

There where no "database server", the client applications open directly the .DAT (ISAM file) and .IDX (index file) to read and store the data. And, I don't know, but if two clients tried to open the same register, the second one get a "This row/register is locked".

If I remember well, this kind of locking was an standard RM/COBOL-85 feature (or just a COBOL-85 feature?).

How can the COBOL runtime know that other users blocked a row? There was any kind of flag in the .DAT file? Where the clients talking between them, using the network?

2
  • 3
    We had the same with dBase/Clipper/FoxPro, on DOS, over Netware, in the first half of the nineties. I was actually amazed that a system like Oracle apparently did not support that (that was then in the second half of the nineties).
    – chthon
    Oct 19, 2022 at 17:35
  • 3
    I think that record-level locking was actually a feature of COBOL ISAM almost back to the original IBM implementation. Oct 19, 2022 at 18:41

1 Answer 1

4

I'm going to start by saying this was a long time ago, so my memory may fail me. And I did not use RM/COBOL, but I programmed for nearly 20 years starting in the mid 80's, migrating COBOL code from Data General ICOBOL to Unix systems which used Austec ACE Cobol (no longer in existence as far as I know) and then later we switched to one of the first versions of Acucobol, now owned by Micro Focus. Again on Unix, but then later we ported to DOS and Windows, which was a piece of cake because Acucobol did all the work with their runtime.

(We did later put a GUI on the software, using Acucobol, and that was a lot of work.)

Anyway Austec COBOL and Acucobol, like RM/Cobol, used ISAM files. Each Cobol file had a data file and an index file. No database server. These really weren't "databases", they were individual plain flat files with binary data structures inside them, and any relationship between them was in code and logic only.

As an aside, the data file, at least early on, simply contained fixed length Cobol records with a delete flag at the beginning of each record. You could read the data file sequentially if you had the layout (the "FD") of the Cobol record. Using the "FD", you could figure out the offset of each record, and where each field was. In the early days, I often had to write code to read the data file (with Cobol code) and write it back out to a new indexed file if the index file became corrupted or someone deleted a massive number of records from the data file, to recover the space. It was just a loop to READ the data file, MOVE the 01 level of the FD to the new indexed file FD and write the record.

In Windows, when the files were stored on a network server, you were either using a variant of Microsoft LAN Manager or Novell Netware.

MS LAN Manager implemented the SMB (Server Message Block) protocol. This was basically the equivalent of a "database server" on the system serving up the files. It maintained the locks.

This was all abstracted through system calls - the runtime made system calls to open a file, read a file, write a file, lock part of a file - and the OS determined whether or not it could do that on the "C" drive locally for instance, or if it had to send over some commands to a network server. That's the SMB protocol. It was invisible, for the most part.

That's why you can map a F: drive to a network server and still use DIR or COPY from a DOS prompt the same as a C: drive.

You can read about the SMB Protocol (which later evolved into the CIFS protocol) here:

https://learn.microsoft.com/en-us/windows/win32/fileio/microsoft-smb-protocol-and-cifs-protocol-overview

You can also learn some interesting things by looking at Samba, which is an open source SMB Server for Unix systems. This was originally written by reverse engineering the SMB protocol, which wasn't documented publicly, using a packet sniffer. The docs provide some insights, as might the source code.

https://www.samba.org/samba/docs/old/Samba3-HOWTO/locking.html

4
  • So you are saying that operating system locks were used, as opposed to the runtime setting and unsetting flags in the file itself? Oct 20, 2022 at 6:48
  • 1
    "These really weren't databases" - they really were. An organized collection of data stored and accessed electronically. They weren't server\client based.
    – Alan B
    Oct 20, 2022 at 8:17
  • @ThorbjørnRavnAndersen Correct, Acucobol uses operating system locks.
    – mannaggia
    Oct 20, 2022 at 13:12
  • @AlanB Of course, that is correct. I was alluding to there being something external to the code where the data files could be managed or queried. Later on Acucobol did have a product "AcuServer" that was a server for Cobol files - essentially it replaced the function of the SMB protocol or NFS (Unix) and served up Cobol files via the network using its own semantics and protocol which the Cobol runtime understood.
    – mannaggia
    Oct 20, 2022 at 13:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .