This article is intended to provide an overview of the CA Ramis database format and usage, and to provide rules and guidelines for working with database data sets in the z/OS operating system environments.
Release: 7.4
CA Ramis
CA Ramis Reporter
CA Ramis database is a special data set created and maintained in a proprietary format compatible with the host operating system. Each database will contain descriptions of Ramis system files, and may also contain descriptions of user files, user file data and user-written requests and procedures. The data for the user files may be contained in a single database or multiple databases, or it may be stored in an external host system data set.
Ramis databases may be moved or copied using the BACKUP and RELOAD utilities that are provided. The BACKUP utility will create a sequential data set that may then be moved or copied by any other program. However, the database itself must never be moved or copied except by the BACKUP and RELOAD utilities.
A Ramis activity may access as many as 24 databases by means of the USE or USEX utility, which effectively concatenates the databases in the USE or USEX list. Although only the first database in the list may be updated by the Records Management facility, the Data Maintenance Facility (DMF) may update any of the databases in the list. In addition, SBX libraries may be specified via the LIBRARY utility without including the associated database in the USE or USEX list. The following description of the database open process applies to all Ramis databases, regardless of how they are defined and accessed.
Before Ramis opens a database, a check is made to determine whether update access is allowed for that database. If the security system indicates that update access is granted, the database is opened for UPDATE. Otherwise, Ramis will check whether read-only access is allowed for that database. If the security system indicates that read-only access is granted, then Ramis will open the database as READONLY (or INPUT). The security system itself may issue an error or warning message when Advantage CA-Ramis issues the check for update access. If read-only access is subsequently established, there are no further warnings or errors issued for that database during the open process.
When you know that a database is to be used in read-only mode, you can prevent the security system from logging an access exception by specifying the LABEL=(,,,IN) parameter on the database DD statement in your batch JCL. If you are running interactively add an ATTR statement that specifies INPUT and reference that ATTR statement in a USING parameter on the ALLOC statement for the database, or simply add the INPUT parameter to the database ALLOC statement.
Here is what the batch JCL parameter should look like:
...
//USERBASE DD DSN=the.dataset.name,DISP=SHR,LABEL=(,,,IN)
...
For an interactive CLIST, one of the following methods should be used:
...
ATTR READONLY INPUT
ALLOC F(USERBASE) DS('the.dataset.name') SHR REUSE USING(READONLY)
...
or
...
ALLOC F(USERBASE) DS('the.dataset.name') SHR REUSE INPUT
...
You can see this coding in the SAMPJCL member RAMISJCL and the CAICLIB member RAMCLIST, both of which are distributed with the CA Ramis product. Both members include the read-only attribute for the RAMLIBE data set definition.
The RAMLIBE data set is itself a Ramis database, which contains all of the standard requests and procedures distributed as part of the CA Ramis product. It should be handled the same as any other Ramis database, and it should normally be accessed for INPUT only.
The CA Ramis Version 7.4 set of documentation can be found at CA Ramis Bookshelves and PDFs.
For more information about CA Ramis databases, refer to the publications, Datasets, Database Design and Utilities.