CA Ramis VM Environment lock GQSCAN

Products

Ramis Reporter

Issue/Introduction

CA Ramis and CA Ramis Reporter use a lock mechanism for any write activity to a concurrent Ramis database to ensure database integrity. 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 Ramis database. DMF (MAINTAIN) concurrency provides the means for multiple users to simultaneously access and update Ramis files in both interactive and batch environments.

Exclusive Access. With exclusive access, the Ramis database is locked for the duration of the activity. No other 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 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 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).

Environment

Release: 7.4

CA Ramis
CA Ramis Reporter

Resolution

What Locks are in Effect

Ramis provides a facility to determine which 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 Ramis RAMSYNC module is the synchronization program which controls access to 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 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 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 Ramis users accessing concurrent 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 Filetype*	is 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.

Additional Information

The CA Ramis Version 7.4 set of documentation can be found at CA Ramis Bookshelves and PDFs.

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