Skip to main content

IBM Systems  >   z Systems  >   z/VM  >  

Description of HOMUNC

Download count: 30 this month, 30 altogether.

Downloads for HOMUNC:
VMARC archive: v-52K

HOMUNC is a platform for experimenting with giving VM a form of self-awareness. The general idea is that the operating system brings up a 2nd-level system that is a model of the 1st-level system. Anything that might change the 1st-level system can be tried out first on the 2nd-level system and evaluated. The evaluation then guides the decision on whether to implement the change 1st-level. This is analogous to a person reflecting upon how some action they contemplate might affect them.

What this tool provides is the automation to bring up a 2nd-level system based on the current configuration of the 1st-level system, a means of keeping the 2nd-level system matching the 1st-level system as things change, and a way to make changes to the 2nd-level system and check on the results. Properly set up, the 2nd-level system comes up automatically and stays synchronized with the 1st-level system. Minimal permanent minidisk storage is required, but the model uses a substantial amount of VDISK space on the 1st-level system. Privilege classes given to the included UserIDs are restricted to the minimum necessary. But the expected use of this as a tool is to defend the 1st-level system from nasty effects of harmful commands, so it is expected that the person installing the tool will have system administrator privileges 1st-level. And any user, if not the same person, will be something akin to system operator. For example, one use of the tool has been to protect against SHUTDOWN REIPL with a bad CPLOAD. This is done by intercepting the SHUTDOWN command, issuing it on the 2nd-level system, and waiting to see what happens before allowing the command to be issued 1st-level.

This package includes the following files.

  • H1STDIR ENTRIES -- Sample directory entries for 1st-level UserIDs
  • USERDIR PROTO -- Prototype directory for 2nd-level system
  • SYSCFG PROTO -- Prototype SYSTEM CONFIG for 2nd-level system
  • SELFIE EXEC -- Program that sets up and starts 2nd-level system
  • INDLOOP EXEC -- Program run by HOMUNCD to pass initialization information (CPLOAD, SYSTEM CONFIG) to HOMUNC and then supply updates
  • UPDLOOP EXEC -- Program run by HOMUNCUP on the 2nd-level system to do the bidding of 1st-level users HOMUNCB and HOMUNCD
  • HTHINK EXEC -- Program run by HOMUNCB to relay requests to HOMUNCUP 2nd-level. The requests come via REQHOMNC EXEC.
  • HTHINK2 EXEC -- Program run by HOMUNCU2 on the 2nd-level system to react to requests like HOMUNCUP, but faster via REQHOMN2 EXEC
  • REQHOMNC EXEC -- Program allowing 1st-level user to send requests to the 2nd-level system
  • REQHOMN2 EXEC -- Same function as REQHOMNC EXEC, but much faster. Requires ISFC (or TSAF) connection between 1st- and 2nd-level.
  • $SERVER$ NAMES -- File to route incoming requests for HOMUNCB and/or HOMUNCU2 to correct private server program
  • FAKELOAD EXEC -- Prototype utility to give fake UserIDs a load to match their namesake's 1st-level behavior

As implemented, user HOMUNCUP uses the CP1STLVL tool to issue QUERY VARIABLE on the level below (see within UPDLOOP EXEC). So you will also need to download that package.

Description of Roles and Controls
To initiate the model, autolog 1st-level UserID HOMUNC. This will result in HOMUNCD also being autologged if it is not already running, as HOMUNC runs SELFIE EXEC to build and bring up the 2nd-level system. HOMUNCD supplies SELFIE EXEC with information so that it will know how to immitate the 1st-level system with the 2nd-level system. For example, SELFIE needs to know the names of the 1st-level SYSTEM CONFIG and CPLOAD. In addition to supplying initialization information, HOMUNCD periodically checks who is logged on 1st-level and relays this information.

After the 2nd-level system comes up, OPERATOR starts HOMUNCUP, whose function is to keep the model up to date by acting on updates sent by HOMUNCD. HOMUNCUP can also act on requests from HOMUNCB on the 1st-level system; such requests would be expected to be such things as health queries and commands we want to experiment with before invoking them 1st-level. You can send such requests via HOMUNCB by using REQHOMNC EXEC. REQHOMNC EXEC uses CPIC to communicate with HOMUNCB.

As provided, the communications between 1st-level (HOMUNCB and HOMUNCD) and 2nd-level (HOMUNCUP) is a slow, clunky arrangement utilizing shared VDISKs and CP environmental variables for signaling. This method was chosen purely because it is guaranteed to be available. Faster and more reliable communication methods are available, e.g. TCPIP and CPIC, but they require extra set up and may not be available. But if you add the HOMUNC 2nd-level system to the ISFC collection which includes the 1st-level system, then you can start HOMUNCU2 on the 2nd-level system and make use of REQHOMN2 EXEC instead of using REQHOMNC EXEC. To bring the 1st- and 2nd-level systems into the same ISFC collection, a real channel to channel (CTC) connection must be set up somewhere between a 1st- and a 2nd-level system. If your 1st-level system is a member of an SSI, CTC link(s) already exist between members of the SSI. There may then be unused CTCs already set up between the members, and one of these can be connected to a 2nd-level system, thus providing an ISFC connection between one member of the SSI and a 2nd-level system on another member. Any 2nd-level system on that other member, e.g. the one on HOMUNC, can be connected to the other 2nd-level system via virtual CTC, thus adding it to the ISFC collection in which the SSI members are. SELFIE EXEC gives HOMUNC's 2nd-level system a unique GATEWAY that REQHOMN2 EXEC knows about, so except for the ISFC set up, this communications method is already available.

Set Up
To install, add the three UserIDs HOMUNC, HOMUNCB, and HOMUNCD to your 1st-level system. Example directory entries are supplied in the file H1STDIR ENTRIES. You may need to change these entries slightly if your system configuration has been modified from a standard install. Specifically, HOMUNC expects the CPLOAD to be on MAINT.CF1 and SYSTEM CONFIG to be on PMAINT.CF0. (It does not necessarily expect them to be so named, however.) Likewise DIRECTXA and CPFMTXA are expected to be on PMAINT.551. The example directory entries are for a 2-member SSI; change to other configurations is just a matter of adding or deleting SUBCONFIGs and is expected to be straightforward. You may also wish to modify the virtual storage size of user HOMUNC -- choose some appropriate fraction (10%? 1%?) of the real storage size of the 1st-level system. Finally, you will need to fill in passwords and the MDISK information for HOMUNC's 191 disk(s). The DASD requirement is 10 cyl 3390. (Yes, that's all -- just some space for the various files included in this package. Everything else is either passed up from 1st-level or on VDISK.)

When you log on to HOMUNC the first time, CMS-format the 191 disk and give it the label HOMUNC. Put all files in this package on the HOMUNC 191 disk, along with the CP1STL TXT* file from CP1STLVL which SELFIE EXEC copies. (It's ok to put on all the CP1STLVL files. But only the one is needed. Since the file is a CP exit and therefore may need to be updated to match your version of VM, I am not specifying the exact name in this document.)

That may be all that you need to do, but you should check to see that the labels for the MDISK statements of USER MAINT in USERDIR PROTO match reality. These are the minidisks such as MAINT CF1 which are LINKed by the 1st-level HOMUNC user -- see H1STDIR ENTRIES. If changes are required, you will need to correct the corresponding USER_VOLUME_LIST entry in SYSCFG PROTO as well. Also verify (Q VDISK USERLIM and Q VDISK SYSLIM) that the 1st-level system will allow HOMUNC to define lots of VDISK space. The amount it will want depends on the 1st-level paging and spooling allocations, but 3000000 BLKs are called for in the directory entry, and then SELFIE EXEC will expect to be able to define more. Remember that you can choose to SET VDISK SYSLIM INFINITE. Probably you don't want to SET VDISK USERLIM INFINITE, but some big number like 50000000 might be appropriate.

If some or all of your 1st-level DASD is SCSI, you will have a little more set up work to do. You will need to correct affected directory entries. Look at those which specify "3390" for the DASD type.

To start HOMUNC, simply XAUTOLOG HOMUNC. HOMUNCD and HOMUNCB will be automatically started as needed. Use REQHOMNC EXEC (or REQHOMN2 EXEC if you have set up an ISFC link) to send commands to the 2nd-level system and to check results. See the EXECs for more detailed instructions. This is where you can begin experimenting with self-awareness. Before implementing a system change 1st-level, use REQHOMNC to implement it 2nd-level and evaluate the result. This results evaluation can be fed back to decide whether to go ahead with the action 1st-level. Programming for automation of this feedback is not included in this package -- clearly a variety of approaches and strategies are possible.
Extensions and Improvements
Like all models, the 2nd-level system will not be a perfect match of the 1st-level system. Experiments on the model will have predictive value only to the extent that the model matches reality in aspects relevant to the experiment. So the expectation is that you, the user of HOMUNC, will adjust and add to the ways that the 2nd-level system mimics 1st-level. As provided, the 2nd-level system starts with a SYSTEM CONFIG largely copied from 1st-level, paging and spool matching 1st-level in number but not size, the same CPLOAD as 1st-level, the same system name, and the same users logged on. Most of the users are the same in name only, though. You can give them a workload, but as provided HOMUNC simply creates idle guests. Creating an analogous workload would clearly be important if you hope to use HOMUNC to feel out performance-related changes. Trying out CP exits can be done with the existing arrangement, but you will have to learn how REQHOMNC provides for this. Some networking changes may be usefully tested, but better modeling of the network environment would give more reliable results.

Tim Greer