2009 Master the Mainframe Contest!

The 2009 contest is just around the corner. If you are a high school or college kid and want to participate (no experience necessary, I promise!), click here.

Notes on How to Create a RACF Database

First, here is a quick list of some of the RACF utilities and what they do:

IRRMIN00 RACF database initialization utility
IRRUT400 RACF database split/merge/extend utility
IRRDBU00 RACF database unload utility
IRRUT200 RACF database verification utility
IRRUT100 RACF cross-reference utility
IRRRID00 RACF remove ID utility
IRRADU00 RACF SMF data unload utility

To create a new RACF database, you're going to use IRRMIN00. Just whip up some JCL (check out 'z/OS Security Server RACF System Programmer's Guide' if nobody in your shop has some canned JCL you can cut and paste) and the utility will create a fresh database for you to use. Note that you have to reIPL before you can use this new database, as it is completely empty. At IPL time, a user entry for IBMUSER will be added so you can log in and start populating your new database.

After you've done this, there are two commands you probably want to issue against your new database. They are:

SETR GENERIC(DATASET)

and

SETR EGN

The first activates generic profile checking (see this post for a bit more on RACF profiles) and the second activates Enhanced Generic Naming. "When you activate this option, RACF allows you to specify the generic character ** (in addition to the generic characters * and %) when you define data set profile names and entries in the global access checking table. " (Security Server RACF Command Language Reference).

Some Random Goodies

I've picked up a few tricks I thought I'd share:

1) In a previous post I talk about sending messages and data sets to other users. The command requires you to know the node name of the system the recipient is on. You can find out what the node name is by going into SDSF and typing NODE on the command line.

2) From within SDSF, after you've run a job and you are reading the results, if you want to edit and or reissue the same JCL, you can do so from within SDSF. When you are looking at the job output, type SJ at the command field to access your job. From there you can edit and resubmit. Here are a few screen shots of what to put where:





3) Recalling migrated data sets can be a pain in the arse, especially when you need several of them to perform a particular task. If you want to recall a bunch of stuff at once, you can do so from within the ISPF data set listing (option 3.4) by typing HRECALL on the command field then = at every subsequent data set you want recalled. The equals sign tells ISPF that you want to repeat the previous command you've entered. Here's another screen shot that illustrates what I'm talking about.

Quick and Dirty Guide to Adding Users and Groups to the RACF Database

On occasion you may have the need to give a new user access to your system. As with anything else on the mainframe, there are about a million options but thankfully you really only need to concern yourself with a few of them. The first thing you need to understand is the concept of groups. RACF groups are a collection of users, grouped together to allow the system programmer (that's you!) an easy way to manage access lists. In other words, if you have 50 users that require access to a data set, rather than grant them access individually, you can put them in a group and give the group access to the data set. Cool, huh?

When creating a group, there are two attributes that you need to think about. They are

1) who the group owner is (can be another group)

2) whether or not this is a Unix System Services group (if it is, you may need to specify a GID)

It should be noted that it is not required that a group is created when a new user is added to the RACF database. Use the ADDGROUP command to add a RACF group. Here are a few examples from the RACF Security Administrator's Guide (ch 3, pg 59)

For example, to create a group for Department A called DEPTA whose owner and superior group is to be a group called ALLDEPT, enter:

ADDGROUP DEPTA OWNER(ALLDEPT) SUPGROUP(ALLDEPT)

To then connect users to that group, use the CONNECT command. For example, to connect department members SUE, LIZ, and GENE to the DEPTA group and also give LIZ and SUE authority to add new users to the group, enter:

CONNECT (SUE LIZ) GROUP(DEPTA) OWNER(DEPTA) AUTHORITY(CONNECT)

CONNECT GENE GROUP(DEPTA) OWNER(DEPTA)

If the group is to own group data sets create a top generic profile for the group data sets in the DATASET class. For example:

ADDSD ’DEPTA.**’ UACC(NONE)

If the group requires access to RACF-protected resources, give the group the required access using the PERMIT command. For example:

PERMIT ’RACF.PROTECT.DATA’ ID(DEPTA) ACCESS(READ)

If the group requires access to z/OS UNIX resources, alter the profile to include an OMVS segment with an z/OS UNIX group identifier (GID). For example:

ALTGROUP DEPTA OMVS(GID(100))

The next thing you need to dig is the concept of profiles. RACF is made up of profiles, and profiles are composed of segments. The base segment is composed of RACF specific stuff. Products also have segments in the profile. When you define a user to the RACF database, you also can define segments of that profile that specify what kind of access that user has to various products that are installed on the system. For example, when you define a new user to RACF, you may also want to define a TSO segment so TSO knows to use RACF (as opposed to its own UADS (User Attribute Dataset) dataset) to authenticate said user at login time. Use the ADDUSER command to add a user. Here are some things to remember when adding a new user:

1) Unless you specify a default password, the password for the new user will be the name of the group to which you add the user make sure you use a valid logon proc (IKJACCNT and ISPFPROC are good basic ones to start with)

2) You can apply the attributes SPECIAL, OPERATIONS, and AUDIT to a new user to give them access to protected system resources.
- SPECIAL does not automatically give the user access to data, but does give him/her the ability to grant him/herself permission to said data. Another way to look at the SPECIAL user is someone who has the ability to execute protected system commands.
- OPERATIONS has access to data, but not to protected system commands
- AUDIT gives the user the ability to view logs, and specify logging options

Here's more of the ADDUSER command, again from RACF Security Administrator's Guide (ch3 pg 92)

To create the user profile, you can use any of the following methods:

1) Issuing the ADDUSER command.
2) Enrolling the user through the TSO/E Information Center Facility (ICF) panels.

Here is an example of using the ADDUSER command to create a user profile. Suppose you want to create a user profile for user Steve H., a member of Department A. You want to assign the following values: STEVEH for the user ID DEPTA for the default connect group DEPTA for the owner of the STEVEH user profile R3I5VQX for the initial password Steve H. for the user’s name Steve H. does not require any of the user profile segments except TSO. The TSO segment values that you want to set to start with are 123456 for the account number and PROC01 for the logon procedure. To create a user profile with these values, enter:

ADDUSER STEVEH DFLTGRP(DEPTA) OWNER(DEPTA) NAME(’Steve H.’) PASSWORD(R315VQX) TSO(ACCTNUM(123456) PROC(PROC01))

You then want to create a top generic profile for the user in the DATASET class using the ADDSD command. For example, if the user’s user ID is STEVEH, enter:

ADDSD ’STEVEH.**’ UACC(NONE)

Well, that's about it. Note that you can use generic RACF profiles to protect more than one resource. This can be done with the use of the '*' wildcard (also known as the splat). Generic profiles saves you the trouble of having to create a unique profile for every little thing on the system. Last but not least, if you want RACF to protect all non-defined system resources, issue the command:

SETROPS PROTECTALL(FAIL)

What Does ABEND 414-04 Mean?

Ran into this one recently and I thought I'd share. Essentially, a volume can be set to READ ONLY. This is something outside the scope of any security product that might be running on the system, meaning you may have RACF permissions to a data set, but if the volume on which that data set resides is READ ONLY, you'll get the 414 abend. The solution is to get your system programmer to un-read only the volume so you can write to it.

RANDOM APF AUTH GOODNESS

From the console (or from SDSF), use this command to display a list of data sets that are currently APF authorized:

D PROG,APF

From the console (or from SDSF), to dynamically APF authorize a data set:

SETPROG APF,ADD,DSNAME=dsname,VOLUME=volser

Note that if you are using the TSO 'CALL' command to execute your compiled programs, you'll get an error if the program you're attempting to execute is APF authorized. To rectify this, you need to either execute the program via JCL, or add the module to TSO Parmlib member IKSTSOxx and re IPL.

How to set AC=1 when using ISPF foreground processing

When you are writing APF authorized code (see this post for more details on what APF is), you may want to link-edit the module using the handy-dandy ISPF panels (option 4.7). Unfortunately, the pubs are not as clear as they could be as to the syntax of how to set the AC = 1 option when using the panels. Well, here's a screen shot of what you need to put there and what it looks like.

APF AUTHORIZED, SUPERVISOR STATE, AND KEY 0

Understanding how the mainframe manages authorized and non-authorized code is crucial for anyone performing system-level tasks. The concepts are simple, but understanding how they relate to one another can get dicey. This post is geared towards someone who needs to write authorized mainframe code.

The system considers a task authorized when the executing program has the following characteristics:

• It runs in supervisor state (bit 15 of the program status word (PSW) is zero).

• It runs with PSW key 0 to 7 (bits 8 through 11 of the PSW contain a value in the range 0 to 7).

• All previous programs executed in the same task were APF programs.

Here are the three things you need to know about:

APF AUTHORIZED: APF stands for A.uthorized P.rogram F.acility. It allows for the system programmer (for those of you who are new to the field, in mainframe-land a system programmer is like a system-administrator) to identify data sets and programs that are allowed to perform sensitive system functions. There are two components to APF authorization. The first is link-editing a module (program) with the AC 1 option set. By using the AC 1 option, we are making the module eligible to be APF authorized. The second component is to place the module into an APF authorized library. APF-authorized programs must reside in one of the following authorized libraries (data set):

• SYS1.LINKLIB

• SYS1.SVCLIB

• SYS1.LPALIB

• Authorized libraries specified by your installation.

Now that we've got our module properly link-edited and placed in an authorized library, we can move onto PSW key and system state. Normally, the system will run in what's referred to as “problem state”. This means there is a set of instructions that are unavailable. Only when the user is in supervisor state are these privileged instructions available. APF authorized programs are permitted to put the system into supervisor state. THIS IS IMPORTANT ---> APF AUTHORIZED PROGRAMS DO NOT RUN IN SUPERVISOR STATE AUTOMATICALLY! APF AUTHORIZATION ONLY ALLOWS FOR THE SYSTEM TO BE PLACED SUPERVISOR STATE.

So now that we're in supervisor state, there's one more thing we need to think about. Every page of storage (a page is 4 kilobytes) has a key associated with it. Keys 0-7 are considered protected, and 8-15 are considered unprotected. If a page of storage is protected, module attempting to access it must be authorized. The system needs to be in supervisor state in order to change the default PSW key from 8 to one that is authorized.

So, let's review. To create a program that is capable of executing privileged instructions and accessing protected storage, it needs to be APF authorized (link edited with the AC 1 option and placed in an APF authorized library), it needs to use the MODESET macro to place the system in supervisor state, and it needs to use the SPKA instruction to change the PSW key to 0-7 (whatever is appropriate).

Well, that's about it. I hope it helps. Here's a link that provides a bit more info if you need it.

Random TSO Goodness

Lately I've been missing MS-DOS. Not because DOS was amazing, but because I know where things are and how to get things done. The PATH command is a good example. In DOS, you could use the PATH command to help DOS find programs you wanted to run. It created a list of directories to search through before it gave up and said something like BAD COMMAND OR FILENAME. You could put this command inside a file called AUTOEXEC.BAT, which was the name of a program that would get run every time the computer started. This way, you could save time as you didn't have to type out or go to the directory in which the program you wanted to execute resided.

In mainframe land, however, things are a bit more complicated.

In mainframe land, the equivalent of a BAT file (short for BATCH) is something called a CLIST. CLIST stands for Command Listing, and is a lot like a DOS batch file in that it provides a user the means to execute several commands at once. In other words, instead of issuing ten commands separately, you could make a list and all you had to do was type in the name of the list. So how do we save ourselves time like we did on our old DOS system?

There are two commands that you can issue on the mainframe that are roughly equivalent to the DOS PATH command. They are TSOLIB and ALTLIB.

TSOLIB is used for load modules, which are programs that have been compiled and link-edited. We issue this command against load modules to have it added to the STEPLIB data set. STEPLIB is a library that will be at the head of a load module search. So, when we want to run our "hello world!" program we lovingly wrote in C, we add it to the STEPLIB so the mainframe knows where to find it, thus saving us the trouble of pecking out it's location in the file system.

ALTLIB will do basically the same thing, but is used for CLISTs and uncompiled REXX programs. These are scripting languages and thus don't have load modules. By default, the mainframe will look in a dataset called SYSPROC for CLISTs. ALTLIB will add other data sets to that search, thus saving us time.

Now, it's important to remember that, like the PATH command in DOS, these changes all go away the minute you log off (or in the case of DOS, reboot the system). So, we need to find a way to have the system re-implement these changes every time we log in. We need a mainframe equivalent to AUTOEXEC.BAT.

On the logon screen , there is a field labeled COMMAND. From there you can issue any TSO command you want, including a CLIST that contains all your ALTLIB and TSOLIB statements in it.

There ya go. Hope it helps :-)