By default, Sybase doesn't support the type of record and table locking that COBOL expects. For this reason, the Acu4GL for Sybase interface implements its own locking method. This is accomplished with the addition of two tables to a database. You choose which database will hold these tables during installation of the Acu4GL for Sybase interface.
Before using the locking tables, you need to execute the included syb_inst.sql script. See the installation instructions you used from this on-line document for the exact procedure. They can be located in the table of contents. If you don't perform this step, the first time you try to execute a COBOL program that opens a Sybase table, you will receive error 9D,11, "ACUCOBOL Lock Table Incorrect".
The first locking table is called AcuLocks; it holds the record locks. The columns in this table are the Table ID, the Process ID of the process holding the lock, and the primary key of the record that is locked. There is a unique index on the Table ID and Key Value, so that inserts into this table are automatically rejected if another user holds a lock on the row in question. This also gives the Database Administrator the information needed to determine who has locks set, and whether the user in question still has a connection to the server. There is a column in the AcuLocks table, which is DBID, the ID of the database. This allows a single lock table to handle locks for all tables on a single server. This column is included in the unique index.
The second locking table is called AcuOpenTables; it holds information about open tables. There is also column in the AcuOpenTables table, DBID, which has been added for the same reason as noted above. The seven columns in this table are:
1) the Table ID,
2) the process ID (PID) of the process that has the table open,
3) the Open Mode (Input, Output, I/O or Extend),
4) whether Multiple records can be locked,
5) whether the file can be open for I/O by any other users,
6) whether the file can be open at all by any other users, and
7) whether Mass Update was specified in the open.
There are no indices on this table, but there is a trigger, which will automatically reject opens that are not allowed based on other users' open modes.
By using these lock tables, the Acu4GL for Sybase interface is able to support all the types of locking ordinarily supported by ACUCOBOL-GT. No special runtime configuration variables are required.
This method of locking is all that is needed if no applications other than COBOL programs are going to be using the Acu4GL for Sybase interface. But if your site has other applications that access the Sybase databases, then you need to use a method of locking that is inherent to Sybase.
The only method of locking that Sybase supports internally is the result of time stamping and the use of BROWSE MODE (see the discussion of BROWSE MODE in the Sybase Commands Reference Manual). If a table has a time stamp column, the Acu4GL for Sybase interface will use browse mode. This will allow the server to detect whether another application has modified a record while an ACUCOBOL-GT application has had it locked.