Objective: Compare using COMPAREOPT

In IBM Security zSecure release 1.12 a new CARLa feature named “compare options” or CARLa keyword “COMPAREOPT” is introduced. You can use this “COMPAREOPT” function for comparing records from multiple information sources. The information sources can be CKFREEZE data sets, Unload data sets, or RACF databases. This compare function is used for comparing records. This function can identify and show changes or differences in the selected fields. Like the summary shown in the previous exercise, the input for comparing is two RACF or CKFREEZE data sets. These input sources are generated at a different point in time or are taken on different systems.

The goal is to compare specific fields from matching records. Specifying what exactly you want to compare is done by defining a “COMPAREOPT” statement. Here is an example of a “COMPAREOPT” statement.

The following keywords must be defined in your “COMPAREOPT” specification:

The results of the comparison can be specified in output fields that are based on the COMPARE_RESULT and COMPARE_CHANGES formats.

The COMPARE_RESULT format contains only one column. It shows the type of result that is found during the comparison process. This variable supports the same values as explained for the SHOW= specification.

The COMPARE_CHANGES format is supported with a list of predefined layout formats. The default layout format is named “CMPCHG4”. This format contains 4 columns: fieldname, change direction (“+” or “-“), base value, and changed value.

There is a wide range of other available layout formats for the COMPARE_CHANGES format. Please refer to the IBM Security zSecure Admin and Audit User Reference manual, in chapter 12 CARLa Command Language, for more details.

Here is an example of a CARLa program that uses the “COMPAREOPT” function:

Notes regarding the CARLa code. In this example, the system-wide SPECIAL, OPERATIONS, and AUDITOR attributes are compared for user IDs. The input to this program is the current active RACF database and an unload data set of the same RACF database taken some time ago. The “COMPAREOPT” statement specifies the following information:

In the NEWLIST statement, the “COMPAREOPT” specification is referred to by the assigned name “priv_changes”. In addition, the report title and empty specification are specified. The DEFINE statements introduce the variables based on the formats COMPARE_RESULT and COMPARE_CHANGES to include in the report. You can specify the appropriate output formats, column headers, and column length as output modifiers. The SELECT statement selects the base segment of user profiles in both complexes. The SORTLIST statement specifies the columns to include in the final report.

Sample output:

From this report, you can derive what changes occurred over time regarding the system-wide SPECIAL, OPERATIONS, and AUDITOR attributes.If during your first attempt the report shows that no changes occurred, please change some system-wide attribute assignments in the live RACF database. Running this program again must now reflect the system-wide attribute changes that you made.

Before you continue, please put back or remove the attributes that you deleted or added to provoke getting some output from this report!

Another example where “COMPAREOPT” might be convenient to use is when you want to report changes that occurred over time to your RACF SETROPTS settings. Most RACF shops refresh their CKFREEZE data sets for each system that they administer on a daily basis. This CARLa program compares the active SETROPTS settings against the settings as stored in the most recent CKFREEZE data set.

Below is an example of what the output might look like:

This report shows the SETROPTS changes on the local ED02 system after the last refresh of the CKFREEZE data set. The first column indicates which SETROPTS setting is changed. The column “Yesterday” reports the original setting from yesterday, and column “Today” shows the current setting.

Note: possibly after running this CARLa program, you might see duplicate settings that are reported. This situation is most likely caused by the fact that in “Setup Files” (option SE.1) you have an additional CKFREEZE data set allocated. Unselecting that CKFREEZE data set must remove the duplicate changed SETROPTS settings that are reported.

Theoretically, you can allocate CKFREEZE data sets for all the environments that you are responsible for managing. These environments can be, for example, DEVELOPMENT, TEST, ACCEPTATION, and PRODUCTION. By using a generation data set (GDG) for the daily CKFREEZE refresh job, you can compare the last two versions of each environment you manage. This example implies that you use a specific naming convention for your CKFREEZE data sets. In addition, this example assumes that these GDGs can be accessed from the system where you run the compare SETROPTS program. In that case, your alloc statements might look as follows:

The generated report shows one page for each of the pertinent systems that show the SETROPTS setting changes that occurred compared to yesterday. Using a similar approach, you can build many more jobs that compare whether particular settings changed over time. For example, class settings from the class descriptor table, program settings from the program properties table, or the list of APF-authorized libraries. But there are many more things that you can monitor by using this “COMPAREOPT” function.

The final example in this section of the CARLa lab guide shows how to use the “COMPAREOPT” function in a different fashion. This example reports the differences in existing data set profiles in the active RACF data base and an unload data set of two different system environments. In this example, the DEMO (demonstration) and EDUC (education) systems compare the profiles defined in the data set class. This report is a convenient overview when you expect the existing resource profiles to be more or less the same. This report shows only data set profiles that exist in one of the pertinent environments.

The output might look like this screen capture:

The above report shows that on the DEMO system there exist 8 data set profiles that do not exist on the EDUC system. In addition, it shows that there are 81 data set profiles that exist only on the EDUC system.

Note that the SORTLIST statement contains column “class”. This column is not useful if you run this comparison only for the data set class. However, changing the SELECT statement to: “select class=(dataset,general) complex=(EDUC,DEMO)”, includes all resource profiles in this comparison. In that case, showing the class column in the report is probably a good suggestion.

Exercise:

Run the following CARLa compare function. Verify whether there are any changes to the revoke attribute, owner, or default group of the existing user IDs stored in an unload data set. For this comparison, you must use the following input sources:

To report the changes, use the CMPCHG output format. This output format includes the three columns: field name, original value, and the new value of identified changes.

 

 

View Suggested samples and answers

 

Continue with the Baseline reports

 

© Copyright IBM Corp. 2012, 2020

IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.