Now we have all wished that a software product worked differently, be it in terms of defaults chosen by it, or missing features, or the way information is presented.

And so it is with RACF. Make no mistake, RACF is a great product, and I like it a lot. But I have often wondered - would it not be nice if it worked just a little differently? Or would it not be better if it interpreted a certain aspect another way thereby removing ambiguity? We all have our wish lists, and the following is mine.

IBM Listens to Customer Suggestions

We must not assume these suggestions fall on deaf ears. IBM does listen. Over the years several enhancements have been implemented in RACF, presumably put forth by customers.  

As an example, I remember not long ago, under older versions of RACF, this is what would happen when one tried to add, by mistake, a RACF group that already existed.

The command entered was -  

ADDGROUP TST234 SUPGROUP(SUPGP1)

The following error message was displayed -   

TST234 - Invalid Group Name

The message gave no indication as to what was invalid about TST234. Was it some sort of naming standard for RACF groups? Or was it the fact there were numbers in the group name? Maybe the length of the group name was not right?

We could never tell. It was confusing to beginners, and irritating to experienced folk, even though the latter likely would have guessed from experience that what RACF was trying to say was that this group name (TST234) already existed in RACF, stupid!

It was so confusing, that it was on my wish list of RACF improvements at the time!

That was then. Now, under newer versions of RACF, the same command under the same circumstances issues the following error message -

ICH51002I Name to be added to RACF data set already exists

ICH00006I TST234 Not added 

This makes perfect sense. Whoever it was that suggested this improvement must have felt good for making a small difference in the RACF world.

With this in mind, here are some improvements I wish RACF could provide in the future (even though this may not be the right time to make wishes, Christmas having already passed).  

Most of these improvements have to do with the RACF SETROPTS, the global options that control the behavior of RACF at an installation.

The Name SETROPTS  

First, I wish the name SETROPTS (derived from, I suppose, SET Racf OPTionS) was changed to something more meaningful. These are global options, so why not call them as such? I know most of my colleagues (and even IBM manuals) refer to these as SETROPTS.

If SETROPTS were called RACF Global Options it would be simpler, and there would be no confusion as to what they represent or what role they play in RACF.

In most products such settings are called by their correct function. Even at IBM, on the AS400 platform, the global Operating System settings are called system values, leaving no doubt as to what they denote.

SETROPTS Format

It is not just the name SETROPTS I have trouble with. I have an even bigger wish for enhancements in this area. This has to do with how these important global settings are presented when one lists them using the command SETROPTS LIST. The resulting display is not formatted properly, to say the least.     

Here is how I think improvements can be made in this area. The display of all RACF active classes, audit classes and generic profile classes should be in alphabetical order, and in a tabular format. Since these are often big lists, you should not have to suffer through reading all the entries in the list before finding the class you want.    

This is how I would like to see the RACF classes displayed:

 

CLASS-NAME           ACTIVE          AUDITED       GENERIC PROFILE   etc..

 

CICSPTRN     YES                 YES                 YES

DATASET       YES                 NO                  YES

 

Etc.

Etc.

Secondly, password rules, and all the remaining controls should be presented in a similar tabular format, so they are easy to read.

RACF Audit Class Defaults

By default, all RACF classes in the active class list should also be in the audit class list.

I don't understand why IBM has not adopted this practice. True, IBM always believes in giving the customer all the choices, but the downside here is that at most installations there are active classes not being audited, and it is not by design - rather, it is an oversight on the part of the customer. The first sign of trouble is often when an auditor notices this discrepancy.

I have not come across a single customer who has knowingly left out an active RACF class from the audit class list.

The only time I can see someone wanting to do it is when the class in question is not important, and it is going to be generating a lot of potentially useless SMF records. Well, in those rare cases, let the customer manually remove the class from the audit list!

Why not default to something that is more appropriate, and if someone wants it any different, then let them change the defaults?

Highlight Important SETRPOTS Settings

One important SETROPTS setting that comes to mind is the one that deals with the PROTECT-ALL feature. This option determines whether (and how) all the installation's data will be protected by RACF.  

Most installations would want their data fully protected, so the option they want to see in SETROPTS is -

PROTECT-ALL( FAILURES) IS IN EFFECT

If this important setting is not in place, this fact should be highlighted, preferably with a warning.

Currently, when one lists the SETROPTS they may see somewhere in a big, un-formatted list, the wording -

PROTECT-ALL IS NOT IN EFFECT

This does not notify the customer that something is very wrong with the RACF setup.

But if this message were prefixed with a warning, it would draw immediate attention, especially to senior management. For example -

WARNING - INSTALLATION DATA AT RISK

PROTECT-ALL IS NOT IN EFFECT

RACF Access Lists       

Here my pet-peeve is that the entities below the userid column of the access list are not always userids - they could be RACF group names. Yet the column heading (see ID: below) implies that these are userids only.   

Here is a sample:

ID:                   ACCESS:

---------           -----------

ABC123          READ

GGG999          ALTER

In this example either of the entities ABC123 or GGG999 could be groups instead of userids. But it is not clear looking at this.   

Now an experienced person knows this fact, and always takes it for granted that there can be userids and groups under this heading. But I am sure a beginner would take this literally, and think that entities under this heading are always userids.

A simple solution would be to differentiate between the two, for example by indicating in a third column what this is.

Not only will this remove any ambiguity, but there will be the added benefit of telling the reader if the entity is a group or userid. Knowing this at a glance helps, for example in implementing role-based security, where the goal is to mostly have groups in access lists, and not individual userids.     

So the above would look something like this if my wish were granted -   

 

ID:                   ENTITY:          ACCESS:

---------           -----------        -----------

ABC123          USERID          READ

GGG999          GROUP           ALTER

Summary

In fairness to RACF, all products have their deficiencies. And it is hard to correct these, because a product like RACF is used by thousands of persons worldwide, and changing anything, even a little bit, can negatively impact someone.

So I don't expect IBM to move quickly on these. But this is something for them to consider in future releases, certainly. 

Dinesh Dattani is a Mainframe Security Consultant in Toronto, Canada. He welcomes feedback on this column. He can be reached at dinesh123 [at] rogers [dot] com.

Forward this page to a friend

Your Email: *

Your Name: *

Send To: *

Enter multiple addresses on separate lines or separate them with commas.

Message Subject: (Your Name) has forwarded a page to you from NaSPA.com

Message Body: (Your Name) thought you would like to see this page from the NaSPA web site.

Your Personal Message: *

Your vote:

1

2

3

4

5

No votes yet