The IMS Database Recovery Control (DBRC) recovery control (RECON) datasets contain critical information for IMS database recovery. For this reason the RECON datasets should be secured from general access to prevent accidental or malicious destruction of IMS database recovery information.
IMS uses the SAF interface to provide resource security. This paper will use RACF as the sample SAF provider but any SAF product may be substituted.
To secure the RECONs an understanding of how the RECONs are used and protected is required. The RECON datasets are VSAM clusters which can be protected in the RACF DATASET class.
Jobs or tasks that result in updates to the RECON information will need CONTROL access to the datasets. All other jobs or tasks that only view the RECON data will require READ access to the datasets.
It should be noted that the database access intent (i.e. read , insert, delete, etc.) of the job or task is not significant in determining the access level to the RECON datasets, although it is typical that a job that updates an IMS database will also affect the recoverability of the IMS database and therefore will result in updates to the RECONs.
Any job that will cause a change in the recovery information of a recoverable IMS database will need CONTROL access to the RECONs.
Because the RECONs are accessed by both online IMS regions (i.e. TM or DBCTL) and batch jobs, consideration needs to be given to the different requirements that exist in the different environments.
IMS Online:
For IMS online processing, the RECON access is performed by the DBRC region. In this case the DBRC region should be assigned a userid, preferrably using the RACF STARTED class, but it may also be done using the RACF started task table (ICHRIN03) or using the USER= and PASSWORD= values on the DBRC job/task JCL.
The userid assigned to the DBRC region can then be granted CONTROL access to the RECON datasets.
Following is an example of the statements used to create and enable RECON dataset protection using RACF in the IMS online environment.
Note: The statements are numbered only for ease of identification in the explanation that follows the sample.
1.SETR CLASSACT(DATASET)
2.SETR GLOBAL(DATASET)
3.SETR GENERIC(DATASET)
4.SETR CLASSACT(STARTED)
5.SETR GLOBAL(STARTED)
6.SETR GENERIC(STARTED)
7.SETR RACLIST(STARTED)
8.AG IMSTEST
9.AU DBRLCTAW DFLTGRP(IMSTEST)
10.RDEF STARTED DBRLCTAW.* STDATA( USER(DBRLCTAW) GROUP(IMSTEST)
11. PRIVILEGED(NO) TRACE(NO) TRUSTED(NO) )
12.ADDSD 'IMSTESTL.IMS.RECON*' UACC(NONE)
13.ADDSD 'IMSTESTL.IMS.RECON2' UACC(NONE)
14.ADDSD 'IMSTESTL.IMS.RECON3' GENERIC UACC(NONE)
15.PE 'IMSTESTL.IMS.RECON*' ID(IMSTEST) ACCESS(CONTROL)
16.PE 'IMSTESTL.IMS.RECON2' ID(IMSTEST) ACCESS(CONTROL)
17.PE 'IMSTESTL.IMS.RECON3' ID(IMSTEST) ACCESS(CONTROL)
18.SETR GLOBAL(STARTED) REFRESH
19.SETR GENERIC(STARTED) REFRESH
20.SETR RACLIST(STARTED) REFRESH
21.SETR GLOBAL(DATASET) REFRESH
22.SETR GENERIC(DATASET) REFRESH
Statements 1 through 8 activate the DATASET and STARTED classes and then enable global and generic profiles for the classes.
Statement 8 creates a RACF group by the name of IMSTEST.
Statement 9 creates a normal RACF userid of DBRLCTAW and assigns a default group of IMSTEST. This userid is being created for the DBRC region.
Statement 10 creates a STARTED class profile which will assign the DBRC userid to the DBRCLCTAW procedure. This statement assumes the PDS member name of the proc being started is 'DBRLCTAW'. This statement assigns userid DBRLCTAW (which has already been created) to the started procedure. Refer to IBM Secureway Security Server (RACF) for furhter information on the STARTED class profiles.
Statement 11 is a continuation of statement 10 and ensures no special attributes are assigned to the DBRC userid.
Statements 12 through 14 create profiles for the RECON datasets. Only statement 13 is needed and offers the most flexible protection, but statements 13 and 14 were included only as a sample of discrete RECON profiles. If IMSTESTL.IMS.RECON2 is ever scratched/deleted, the profile in statement 13 will also be deleted. However, the genric profile created by statement 12 will not be deleted so the RECONs will always have a profile in place. Statement 14 is an example of creating a fully qualified generic profile such that the profile will remain even if the dataset is deleted. In this manner when the dataset is redefined it will already be protected.
Statements 15 through 17 give the IMSTEST group CONTROL access to the RECONs. If other users need CONTROL access to the RECONs then they need only be connected to the IMSTEST group rather than explicitly granting the users access to the RECONs. Note that only statement 15 is needed but statements 16 and 17 were added to show how the discrete profiles are used.
Statements 18 through 22 cause RACF to refresh the in storage profiles to include the new profiles created in the STARTED and DATASET classes.
IMS Batch Processing:
IMS database batch processing should use DBRC as an operational requirement. This is accomplished by specifying DBRC=FORCE on the IMSCTRL macro for the IMS system generation.
Because IMS batch jobs can be submitted by many different users, the DBRC userid created for the DBRC online region may not be used. The DBRC userid will be used if it is correctly assigned through the use of the RACF STARTED class by coding entries for specific job names in the STATED class and associating those entries with the DBRC userid. However, the STARTED class is used only in the case where the batch jobs are started with the MVS START command.
Jobs submitted to a JES reader will not invoke a call to the STARTED class so they may not be assigned a userid allowing the appropriate access to the RECON datasets. In this case all users authorized to run IMS database batch jobs should be identified and connected to a group that has CONTROL access to the RECON datasets.
This area of security can be enhanced by disallowing general access to the job libraries using the DATASET class and forcing the jobs to be started with the START command. This, however, can cause undue inconvenience when updating the batch jobs as only a limited number of users will be allowed to alter the jobs.
A better option is to use the PROGRAM class to prevent unauthorized access to the IMS main program, DFSRRC00. By doing so, no unauthorized users will be allowed to execute IMS batch jobs. The same approach can be used to prevent unauthorized users from executing the main DBRC program, DSPURX00.
23.SETR WHEN(PROGRAM)
24.AU IMSLCTAW DFLTGRP(IMSTEST)
25.RDEF STARTED IMSLCTAW.* STDATA( USER(IMSLCTAW) GROUP(IMSTEST) 26. PRIVILEGED(NO) TRACE(NO) TRUSTED(NO) )
27.RDEF PROGRAM DFS* 28. ADDMEM('IMSBLD.I71STS27.CRESLIB'/IMSBD2/PADCHK) UACC(NONE) 29.RDEF PROGRAM DSP* 30. ADDMEM('IMSBLD.I71STS27.CRESLIB'/IMSBD2/PADCHK) UACC(NONE)
31.RDEF PROGRAM DSP* 32. ADDMEM('IMSBLD.I71STS27.CRESLIB'/IMSBD2/PADCHK) UACC(NONE)
33.PE DFS* CLASS(PROGRAM) ID(IMSTEST) ACCESS(READ)
34.PE DSP* CLASS(PROGRAM) ID(IMSTEST) ACCESS(READ)
35.PE REC* CLASS(PROGRAM) ID(IMSTEST) ACCESS(READ)
36.SETR GLOBAL(STARTED) REFRESH
37.SETR RACLIST(STARTED) REFRESH
38.SETR GLOBAL(DATASET) REFRESH
39.SETR GENERIC(DATASET) REFRESH
40.SETR WHEN(PROGRAM) REFRESH
The statements above are included to the preceeding 22 statements to expand the RECON protection to the IMS batch environment.
Statement 23 enables the PROGRAM class checking.
Statement 24 creates a userid that can be assigned to an IMS control region or an IMS batch job.
Statements 25 and 26 add an entry in the STARTED class to assign the IMS userid to jobs that fit the profile model.
Statements 27 and 28 create a PROGRAM class profile for the IMS programs with prefix 'DFS'.
Statements 29 and 30 create a PROGRAM class profile for the DBRC programs with prefix 'DSP'.
Statements 31 and 32 create a PROGRAM class profile for dynamically allocated RECONs with prefix 'REC'.
Note that the PROGRAM class entries protect load modules in a specific dataset ('IMSBLD.I71STS27.CRESLIB') on a specific volume (IMSBD2).
Statements 33, 34, and 35 allow all members of group IMSTEST to run the IMS and DBRC programs and to access the RECONs.
Statements 36 through 40 cause RACF to refresh the in storage profiles.
The PROGRAM class can be further utilized to allow access to the RECONs only when the access is made from an authorized program scheduled by an authorized user.
41.PE 'IMSTESTL.IMS.RECON*' ID(IMSTEST) ACCESS(CONTROL) 42. WHEN(PROGRAM(DFSMVRC0,DSPURX00,DFSUARC0))
If statements 15 through 17 are deleted from the initial example, statements 41 and 42 can be used to allow members of the IMSTEST group to access the RECONs only when the access is through the PROGRAM class using the IMS and DBRC programs residing on the named volumes (on statements 28 and 30).
The examples in this document are functional but are not intended to represent the full profile set that should be used to protect the RECON datasets. Consideration must be given to special users that may need READ, ALTER or CONTROL access on an individual basis. Also, this document does not provide examples of all possible solutions to protecting the RECON datasets, rather, it offers a sample of some of the RACF options available in the IMS DBRC environment. User access requirements to the IMS RESLIB dataset(s) should also be considered before establishing program control of the IMS RESLIB.
23October2001
Mike Gonzales
IBM Silicon Valley Laboratory