How to tell Which CA-Ramis Locks are in Effect using GQSCAN in the VM Environment

Document ID : KB000056160
Last Modified Date : 14/02/2018
Show Technical Document Details

CA-Ramis uses a lock mechanism for any write activity to a concurrent CA-Ramis database to ensure database integrity. CA-Ramis database write activities include:

  • Data Maintenance Facility (DMF) command MAINTAIN
  • Records Management commands:
    REVISE, INCLUDE, INPUT, UPDATE, DELETE, CHANGE
    ALTER, ERASE, ERASE*, SCAN
  • Virtual pointer resolution in CA-Ramis reporting
CA-Ramis provides exclusive access and shared access to the CA-Ramis database. DMF concurrency provides the means for multiple users to simultaneously access and update CA-Ramis files in both interactive and batch environments.

Exclusive Access. With exclusive access, the CA-Ramis database is locked for the duration of the activity. No other CA-Ramis activity can modify the database during that time. All write activities acquire exclusive access except for DMF requests which specify shared access.

Shared Access. With shared access, the CA-Ramis database is locked for the duration of one or more specific actions within a DMF activity. Other DMF actions against the database are queued while the lock is in effect, and are subsequently executed in sequence. Shared access through DMF is controlled through a special lock mechanism.

Reporting Activities. The CA-Ramis reporter (commands TABLE, RELATE, etc) does not utilize the lock mechanism and is therefore effectively multi-threaded and multi-tasked with the DMF activities. This means that reporting does not impact the performance of DMF, and DMF does not impact the performance of reporting. If virtual fields are active in the report and write access to the database is permitted, the reporter may attempt to resolve virtual pointers. To assure that no write activity is attempted during virtual pointer resolution, all users reporting from a concurrently updated database should set the VLINK parameter to OFF (see the CA-Ramis publication, Utilities).


What Locks are in Effect

CA-Ramis provides a facility to determine which CA-Ramis locks are in effect and the details pertaining to the locks. This facility can be used to help resolve any problems associated with the unintentional exclusive use of a CA-Ramis database or improper use of locking in an application using DMF (MAINTAIN).

In the VM environment, the CA-Ramis RAMSYNC module is the synchronization program which controls access to CA-Ramis databases with a file mode that ends with the number 6 (for example, RAMDATA DATA B6) on multi-write (MW) accessed CMS minidisks. (The file mode number of 6 causes CMS to update in place rather than shadow update).

RAMSYNC provides the GQSCAN facility via the CP SMSG command.

The GQSCAN facility can be run from any CMS userid with authority to issue #CP SMSG commands. The syntax for invoking GQSCAN is:
#CP SMSG syncid GQSCAN

where syncid is the CMS userid running the RAMSYNC synchronization program (The installation default userid is RAMSYNC).
When this command is issued, the RAMSYNC module prepares a snapshot report of the current status of all users accessing the CA-Ramis concurrent databases. This report, a print file named RAMSYNC QUERY, is sent to the CMS reader of the userid which issued the SMSG command.

If the syncid (RAMSYNC) userid is not running, this message will be displayed:
HCPMSG045E syncid not logged on
If no CA-Ramis users are accessing concurrent CA-Ramis databases, the following messages will be displayed:
hh:mm:ss * MSG FROM syncid: Command accepted.
hh:mm:ss * MSG FROM syncid: No active resources
If the syncid is up (running disconnected) and there are one or more active CA-Ramis users accessing concurrent CA-Ramis databases, the following is displayed and the RAMSYNC QUERY report is sent to the issuer's reader:
hh:mm:ss * MSG FROM syncid: Command accepted.
RDR FILE n SENT FROM syncid PRT WAS n RECS n CPY n A NOHOLD NOKEEP


RAMSYNC QUERY Report

The first line of the RAMSYNC QUERY report shows the date and time when the report was prepared (when the snapshot was taken):
Date is yyddd        Time is hhmmss
The RAMSYNC QUERY report will also show each userid and resource:
Resource is {Resource} named Filename Filetype Mdisklabel
User Userid is {Shared or Exclusive}{Owner or Waiter}
Resource value may be: OP, DB, or IO:
OP indicates that the user has the database in an open lock (a "USE" for the concurrent database has been issued).

DB indicates that the user has the database in a write activity (in a MAINTAIN, REVISE or other write activity).

IO indicates that the user in a locked IO activity in anticipation or in process of a write. IO locks are always exclusive.
Filename Filetypeis the CMS database filename and filetype.
Mdisklabel is the CMS minidisk label.
Userid is the CMS userid accessing the database.
Shared or Exclusive is the access acquired by that userid.
Owner or Waiter is the access status of that locked resource.

Examples of RAMSYNC QUERY Reports:

Shared Open Lock

The following entry would be created in response to #CP SMSG RAMSYNC GQSCAN when only one user (USERID1) has access to one database named RAMDATA DATA on a CMS minidisk labeled RAMDISK (resource is OP with Shared Owner) and is NOT in a write activity (no DB resource):


Date is 01149 Time is 114333
Resource is OP named RAMDATA DATA RAMDISK
User USERID1 is Shared Owner

Shared DMF Concurrent Activity

The following entry would be created in response to #CP SMSG RAMSYNC GQSCAN when only one user (USERID1) has access to one database named RAMDATA DATA on a CMS minidisk labeled RAMDISK (resource is OP with Shared Owner) and is in a shared write activity (resource is DB with Shared Owner). In this example, the user was in a MAINTAIN activity specifying ACCESS SHARED:

Date is 01149 Time is 114637
Resource is OP named RAMDATA DATA RAMDISK
User USERID1 is Shared Owner
Resource is DB named RAMDATA DATA RAMDISK
User USERID1 is Shared Owner

Exclusive IO Lock Against the Database in Shared DMF Concurrent Activity

The following entry would be created in response to #CP SMSG RAMSYNC GQSCAN when two users (USERID1 and USERID2) have access to one database RAMDATA DATA on a CMS minidisk labeled RAMDISK. Both have opened the database successfully (resource OP with Shared Owner). Both users are in a DMF concurrent write activity (resource DB with Shared Owner). USERID1 has an exclusive IO lock on the database (resource IO with Exclusive Owner) while USERID2 is waiting for the lock (resource IO with Exclusive Waiter). USERID2 will remain in an exclusive wait state until USERID1 releases the lock.

Date is 01149 Time is 154248
Resource is OP named RAMDATA DATA RAMDISK
User USERID1 is Shared Owner
User USERID2 is Shared Owner
Resource is DB named RAMDATA DATA RAMDISK
User USERID1 is Shared Owner
User USERID2 is Shared Owner
Resource is IO named RAMDATA DATA RAMDISK
User USERID1 is Exclusive Owner
User USERID2 is Exclusive Waiter


This scenario highlights an application problem. In this example, the USERID1 write activity was an interactive MAINTAIN using the "SAVE AFTER 2 TRANSACTIONS" option. USERID1 has only completed one transaction so the lock will not be freed until USERID1 completes the second transaction. "SAVE AFTER n TRANSACTIONS" is not appropriate for online, interactive activities. Nor is its use appropriate for batch activities when online users may be writing to the same database. When shared access is being used, "SAVE AFTER 1" (the default) is always recommended. As seen by this example, SAVE values greater than 1 will cause other concurrent users to "hang" while they wait for the user with the exclusive lock to complete the specified number of transactions.

Read More About It

For more information on the CA-Ramis DMF facility (MAINTAIN) and concurrent database access, please refer to the CA-Ramis publication, Data Maintenance Facility. For more information on the CA-Ramis reporter, refer to the publication, CA-Ramis Syntax Based Reporting. For more information on the RAMSYNC CMS id, refer to the publication, CA-Ramis VM Installation Guide. For more information on the VLINK parameter and virtual pointer resolution, see the CA-Ramis publication, Utilities.

Contribute Your Ideas

If you have a tried and true technique that you would like to share with the CA-Ramis community as a published article, please contact Computer Associates Support.