Skip to main content

IBM Systems  >   z Systems  >   z/VM  >  

Description of RENSSI

Download count: 10 this month, 1341 altogether.

Downloads for RENSSI:
VMARC archive: v-25K

This tool renames a member system of a Single System Image (SSI). It consists of two REXX EXECs. You run RENSSI1 EXEC on the member to be renamed, then, after shutting down the member to be renamed, run RENSSI2 EXEC on some other SSI member. Before running the EXECs, you may need to modify a few lines near the beginning to provide minidisk passwords, the name of your SYSTEM CONFIG file, etc.

That's pretty much all there is to it. The whole process takes about 5 minutes, not counting the time it takes to shut down the system being renamed and the time to bring it back up again after running RENSSI2. However, this is major surgery on your SSI. The EXECs modify lots of crucial files and labels, and there is plenty that could go wrong. There is a small amount of configuration of the EXECs that you will need to do before running them, so that the EXECs are able to link the necessary disks and target the correct files. You may have to make more extensive changes of the EXECs if your setup is substantially changed from a standard install. Therefore, it is important to review the EXECs before running them, and alter them as appropriate.

To make review of the EXECs easier, I begin every new functional section with a comment including three consecutive asterisks. For example

                                                                           
  /*** Change the ownership info on every DASD except SPOOL */                  
This gives you an easy way to see all the things the EXECs try to attend to. There may be things that do not apply to your setup, which you can probably ignore, but what you are really looking for are things that are missing. For example, RENSSI2 EXEC handles the case that the user directory is stored in a USER DIRECTory file, and the case where it is controlled by the directory maintenance product DIRMAINT. But if you use some other directory maintenance product, you will need to add that to the program or otherwise allow for it. Likewise note that there is no provision for RACF or any other external security manager.

A little set up is required. There are a few lines of LINK statements which you may need to modify, filling in the correct LINK passwords if you are not making use of the LNKNOPAS DIRECTory OPTION. You will need to supply the correct name of SYSTEM CONFIG and USER DIRECT if you have changed the names from the install default. You should also SET PRODUCT DISABLE for DIRMAINT if you are not using DIRMAINT, and you must ensure that the user on which you invoke RENSSI1 and RENSSI2 has the required privileges. Specific directions are included in comments at the beginning of the two EXECs.

There are no steps taken by either EXEC that cannot be invoked manually. Indeed, one way to use this tool is as a step-by-step guide rather than invoking the EXECs at all. There are a lot of steps, though, and most provide opportunity for typos and other human error. So the EXECs, although scary, may nevertheless be the safer route. This tool is expected to be used only by system administrators or others with substantial understanding of the system environment. Not all of the things the EXECs try to modify may be familiar to you, but if most of them are unfamiliar you are probably in over your head.

Some functional notes:

  • In updating files, the EXECs mostly just replace the old name of the member system with the new name. This works fine if the character string forming the old name is unique. But if that character string appears in the file with meaning other than member system name, it will still get replaced with the new name, and you will be unhappy with the result. If, for example, you chose single letter names for your SSI members, the EXECs will make hash of your files. If you are starting with reasonably complex names such as SYS1A, you should be ok.
  • Unless you have a very clean system, you are likely to see CP error message HCP002E, as RENSSI2 EXEC tries to deal with nonexistent DASD that it sees referred to in SYSTEM CONFIG. While you should not completely ignore these messages, they are not necessarily bad news.
  • You will also see many other messages, both from the EXECs and from CP, the latter reporting things like users getting FORCEd, minidisks being LINKed and DETached, etc. I have left the CP responses exposed so that, if something goes wrong, it is easier to figure out what happened. Unless the EXECs report an error, it is probably safe to ignore the CP messages. Take note of any messages from the EXECs that report "doing nothing". Generally these "doing nothing" messages are expected, but you should confirm that something you intended to happen is not being skipped over. In that case you will need to manually do whatever was unintentionally skipped over.
  • If RENSSI2 tries to issue DIRECTXA and fails (this is with no DIRMAINT active), it will warn you. In that case, you will need to fix whatever the problem is and issue the DIRECTXA properly. Failure to do that will result in a system that IPLs but has no UserIDs.
  • Before running either EXEC, make sure to spool your console ("SPOOL CONS START") so that you have a record of the messages produced. If anything goes wrong, this record will be helpful in figuring out what happened and how to fix things.
  • There will inevitably be updates required to files this tool does not know about or cannot access -- references in communication configuration files on other systems, for example. The programs have no memory of previous runnings, so although you may be changing the names of multiple members in a single SSI, each change is independent. There is no provision for handling multiple members simultaneously.
  • The programs work equally well on z/VM 6.2.0 or z/VM 6.3.0; the only difference is the UserIDs specified in the configuration lines -- MAINT620 vs. MAINT630 and 6VMDIR20 vs. 6VMDIR30.

The essential files in this package are

  • RENSSI1 EXEC -- Program to run on member to be renamed
  • RENSSI2 EXEC -- Program to be run on another member, after the member to be renamed has been shut down
  • RENSSI DESCRIPT -- This file, a description and user's guide

Some comments about testing: This tool has undergone varied testing in an environment specially created for that purpose. It has also been used successfully with multiple members in a much different, more production-like SSI. But there are many possible SSI environments and I will never have time to test more than a few of them. Most likely your environment was not tested, possibly not even anticipated. Likewise, except by the author Tim Greer, no review has been done.