NO? Migrating an ADCD z/OS release:RACF

ADCD, migration 3 Minutes

This post is a very quick post in response to a question about migrating your RACF data to a different system. I will update it when I have more time.

This is one of a series of posts about migrating to a newer level of ADCD.

This covers RACF.

A typical z/OS migration is to take your existing system and upgrade it. With ADCD the operating system is replaced and you have to move to it, taking your data with you.

You need to think about your RACF definitions, and migrates your specific data into the newer RACF database. This will include userid, profiles, permissions and digital certificates.

Some of the changes are good practice and clean up. For example

Instead of a definition CICSTS55.* in class(STARTED), the profile is CICSTS.*.* in class(STARTED). Using the scripts described in this blog you can update your old system before you move to the new system. 

I have put files into a github repository.

Migrating certificates and keyrings

The JCL EXPCERT runs a rexx exec which create commands to export your certificates, imports them (on the new system), and recreates the keyrings (on the new system).

The exec issues the RACDCERT command to list all the keyrings for a userid, and processes that output.

//IBMCERT  JOB 1,MSGCLASS=H 
// EXPORT SYMLIST=(*) 
//ADCDA EXEC PGM=IKJEFT01,REGION=0M 
//SYSPRINT DD SYSOUT=* 
//OUTPUT   DD DISP=SHR,DSN=COLIN.MIG.DATA(EXPCERTD) 
//IMPORT   DD DISP=SHR,DSN=COLIN.MIG.DATA(IMPCERTD) 
//RING     DD DISP=SHR,DSN=COLIN.MIG.DATA(RINGD) 
//SYSEXEC  DD DISP=SHR,DSN=USER.Z24C.CLIST 
//SYSTSPRT DD SYSOUT=* 
//SYSTSIN  DD * 
%LRING COLIN.CERT.EXPORT   START1 PASS4ME4 
/* 
//S2    EXEC PGM=IKJEFT01,REGION=0M 
//SYSPRINT DD SYSOUT=* 
//SYSTSIN  DD DISP=SHR,DSN=COLIN.MIG.DATA(EXPCERTD) 
//SYSTSPRT DD SYSOUT=* 
/*  

The parameters are

  • the exported certificates high level qualifier. It will create data sets like COLIN.CERT.EXPORT.C14 . Once you have imported the certificates you need to delete these data sets.
  • the userid that owns the keyrings
  • the password for the exported certificates

The output data sets are

OUTPUT: this has data like

RACDCERT EXPORT(LABEL('AdcdShrCA')) -
CERTAUTH DSN('COLIN.CERT.EXPORT.C8')-
FORMAT(PKCS12DER) password('&PASSWORD')

IMPORT: This has data like

RACDCERT ADD('COLIN.CERT.EXPORT.C8') CERTAUTH -
TRUST withlabel('AdcdShrCA') PASSWORD('&PASSWORD')

RING: this has data like

RACDCERT ADDRING(RING) ID(START1)
RACDCERT ID(START1) CONNECT(RING(RING) –
  CERTAUTH DEFAULT usage(PERSONAL ) –
  LABEL(‘AdcdShrCA’) )

Migrating userids and profiles

RACF provides a DBSYNC rexx program to take two unloaded RACF databases and generate the RACF command statements to show the differences and help you convert from one to the other. One file will have “define resource XYZ” another file will have “delete resource XYZ”.

In theory you can just run the appropriate files and merge your old definitions into the new database. I have a lot of junk in my old database and wanted to be more selective as to what I copied across, and understand the differences.

I used the DBSYNC job to create the various files. I changed the DCB to DCB=(RECFM=VB,LRECL=600,BLKSIZE=6400)

The output of ALTFILE1 looks like

/*70:339:286*/ "altgroup PKIGRP   omvs( gid(0000990031))" 
/*75:373:315*/ "altuser ADCDA owner(IBMUSER  ) dfltgrp(TEST     ) noadsp n....
  "noseclabel"

I use ISPF View on the data set, so I do not accidentally change the output.

I run the Rexx exec RACFONEL (in user.*.clist). This creates one line in the file for each logical line, and sorts the file alphabetically. For example

altuser ADCDA owner(IBMUSER  ) dfltgrp(TEST     ) noa..... noseclabel

Depending on what I am doing, I select a subset of the records for example, for my userid and use those records.

The Rexx exec RACSPLIT does the following

  • Cosmetic edits to make fields align – for example change ‘ group’ to ‘group’, changes revoke to resume to make it easier to compare records
  • Splits each line so it fits more into columns 1-80. Sometimes the lines are longer because the definition requires a long string.
  • It appends the records into the save file

Example output

altuser ZWESIUSR owner(IBMUSER  ) - 
    dfltgrp(ZWEADMIN ) - 
    noadsp - 
    nospecial - 
    nooperations - 
    nogrpacc - 
    name(zzzzz) - 
    nodata - 
    noseclabel 
altuser ZWESVUSR omvs( uid(0000990016 ) home('/apps/zowe/v10/home/z.....

If I am happy with the output, delete the top records in the file, and save it.

Do the same for the old and new RACF DBSYNC files and then use ISPF edit compare function to show the difference.

Once you know what the difference are you can run the updates for the changes you want to make to your new database.

Unknown's avatar

Published by Colin Paice

I retired from IBM where I worked on MQ on z/OS, and did customer stuff. I retired, and keep my hand in with MQ, by playing with it! I'm now an #IBMChampion from my work trying to make z/OS product more usable.

Published

2 thoughts on “NO? Migrating an ADCD z/OS release:RACF”

  1. Hi Colin. Thanks for the blog. I do have a few questions:

    1) Do you change the LRECL when the OUTxxx1/2 files are created? Is this so RACFONEL can combine the output later in the same dataset?

    2) Do you set DBSYNC’s INDD1 to the old unloaded RACF DB, and INDD2 to the new unloaded DB, or do you just set INDD1 to the old DB & INDD2 to DUMMY, creating all of the commands int OUTxxx1 necessary? (I’m thinking INDD2=newDB would probably better.)

    Thanks again for the tips!

    Like

    Reply

    1. Hi Wendell,

      1)
      I make the LRECL bigger, as some lines when all of the options were assembled into one line, were longer than the provided lrecl. Making the lrecl bigger solved that problem.

      2) Good question. I just defined them at random, then looked at the output files and said ” Ahh this does the add user for my old userid… I’ll use this one. I should do as you suggest

      Colin

      Like

      Reply

Leave a comment