Brian Wade's CP Monitor Collector

On this web page I give away and document a small package that helps with the task of collecting raw CP Monitor data (aka "MONWRITE data").

This collector offers several features beyond what the standard MONWRITE virtual machine can do, including:

• Collecting for only a certain amount of time, then stopping;
• Starting a new monitor file every N minutes;
• Subordinating itself to another virtual machine, such as PERFSVM, that is determining the settings for CP Monitor;
• Cleaning off the collection disk periodically, keeping only the N most recent files.

As shipped here, this collector is configured to:

• Put itself in charge of the settings of CP Monitor, and
• Use CP Monitor settings appropriate for diagnosing systems in duress, and
• Run endlessly, and
• Start a new raw monitor file every 60 minutes, and
• Keep only the 24 most recent raw monitor files.

These settings provide a means to keep the last day's worth of raw monitor data handy, in easily-handled hour-size chunks.

You can change the configuration by customizing the collector. More description is found below.

This web page tells how to set up and use my monitor data collector.

New Installation

1. Create a virtual machine to collect monitor data. In this sheet of instructions, I call said machine LINMON. This virtual machine will collect the monitor data and log it out to disk. Here is a sample CP directory entry you can use as a starting point. USER LINMON PASSWORD 64M 256M EG IPL CMS PARM AUTOCR MACH XC OPTION QUICKDSP IUCV *MONITOR MSGLIMIT 255 NAMESAVE MONDCSS SHARE ABSOLUTE 3% SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A CONSOLE 009 3215 T LINK MAINT 190 190 RR LINK MAINT 19D 19D RR LINK MAINT 19E 19E RR MDISK 191 3390 0303 0010 BKWLNX MR ALL ALL ALL MDISK 291 3390 0363 2500 BKWLNX MR ALL ALL ALL

   The important features in this directory are:

   • The EG privilege classes,
   • The PARM AUTOCR clause on the IPL card,
   • The OPTION QUICKDSP card,
   • The IUCV *MONITOR card,
   • The NAMESAVE MONDCSS card,
   • The SHARE ABSOLUTE card,
   • The 191 minidisk, and
   • The 291 minidisk.

   Of course, you will have to change the definitions of the 191 and 291 minidisks to ones appropriate for your system. Keep the 191 at 10 cylinders. Create the 291 minidisk as large as you can get away with on your system. It is the disk to which LINMON will log out the collected monitor data.

   Note: If you are fan of the CMS Shared File System, you could put LINMON's A-disk in SFS and create a subdirectory to replace the 291 disk. Make sure you set LINMON's filespace limit high enough to handle the amount of monitor data you will be collecting. You will have to customize PROFILE EXEC to access your collection directory at filemode B instead of accessing device 291. I run this package from SFS on my systems and it works great!

2. Log on to LINMON. CMS FORMAT the 191 and 291 disks. Log off of LINMON.

3. Download VMARC MODULE from here. Save the downloaded file to your PC in binary, and then upload it to LINMON 191 in binary (FTP, perhaps).

4. Download VMARC HELPCMS from here. Save the downloaded file to your PC in binary, and then upload it to LINMON 191 in binary (FTP, perhaps).

5. Download LINMON VMARC from here. Save the downloaded file to your PC in binary, and then upload it to LINMON 191 in binary (FTP, perhaps).

6. Log on to LINMON.

7. Issue these CMS commands:
   PIPE < VMARC MODULE A | deblock cms | > VMARC MODULE A PIPE < VMARC HELPCMS A | deblock cms | > VMARC HELPCMS A PIPE < LINMON VMARC A | fblock 80 00 | > LINMON VMARC A F 80

8. Issue this CMS command: VMARC UNPK LINMON VMARC A = = A ( OLDDATE REPLACE

9. Issue these CMS commands: COPYFILE PROFILE $EXEC A PROFILE EXEC A ( OLDDATE REPLACE COPYFILE MSDONE $EXEC A MSDONE EXEC A ( OLDDATE REPLACE COPYFILE MONSETUP $OPT A MONSETUP OPTIONS A ( OLDDATE REPLACE COPYFILE MONSETUP $CMD A MONSETUP COMMANDS A ( OLDDATE REPLACE

10. Using XEDIT, create on LINMON 291 a file called MONDATA $MARKER. It doesn't matter what's in the file.

At this point the new installation is complete.

Note: the MONWRITE MODULE distributed with this package is a replacement for the standard MONWRITE.

Refresh Installation

1. Download LINMON VMARC from here. Save the downloaded file to your PC in binary, and then upload it to LINMON 191 in binary (FTP, perhaps).

2. Issue this CMS command: PIPE < LINMON VMARC A | fblock 80 00 | > LINMON VMARC A F 80

3. Issue this CMS command: VMARC UNPK LINMON VMARC A = = A ( OLDDATE REPLACE

4. If there is no file called MONSETUP COMMANDS on LINMON 191, issue this CMS command: COPYFILE MONSETUP $CMD A MONSETUP COMMANDS A ( OLDDATE REPLACE

At this point the refresh installation is complete.

A refresh installation does not write over your files PROFILE EXEC, MSDONE EXEC, MONSETUP OPTIONS, or MONSETUP COMMANDS. We recognize you might have customized those.

Customizing The Installation

There are some files you might want to customize after you do a new installation. These are PROFILE EXEC, MSDONE EXEC, MONSETUP OPTIONS, and MONSETUP COMMANDS. See below.

Customizing PROFILE EXEC

You might want to customize PROFILE EXEC to link and access local tools disks, or whatever.

Customizing MSDONE EXEC

My package drives MSDONE EXEC when it is completely done collecting data. If you want to put some postprocessing in here, go ahead.

Customizing MONSETUP OPTIONS

The prologue of file MONSETUP $OPT describes what all the various keywords in file MONSETUP OPTIONS do. Here are some examples.

• To let LINMON be in charge of the settings of CP Monitor, and to let LINMON pick the name of the monitor data file, and to let LINMON keep collecting in one single file until someone types MONWSTOP on its console, and to put MONDCSS at 1A00-21FF, use:

  DCSSRANGE 1A00-21FF
  

• To let some other virtual machine be in charge of the settings of CP Monitor, and to collect CP Monitor data for only one hour and then stop collecting, use:

  SUBORDINATE
  COLLECTFOR 60
  

• To let some other virtual machine be in charge of the settings CP Monitor, and to run the collector constantly, and to collect raw monitor data in one-hour chunks, and to keep only the last 24 raw monitor files collected, use:

  SUBORDINATE
  COLLECTFOR 0
  NEWFILE 60
  KEEP 24
  

• To let LINMON be in charge of the settings of CP Monitor, and to put the MONDCSS segment at 1A00-21FF, and to run the collector constantly, and to collect raw monitor data in one-hour chunks, and to keep only the last 24 raw monitor files collected, use:

  DCSSRANGE 1A00-21FF
  COLLECTFOR 0
  NEWFILE 60
  KEEP 24
  

Customizing MONSETUP COMMANDS

This file contains the CP MONITOR commands that the collector will issue when it starts CP Monitor, if in fact it is in charge of CP Monitor (that is, if you did not specify SUBORDINATE in the MONSETUP OPTIONS file).

My package ships with these settings for CP Monitor:

These settings are good for a system running with a 2048-page MONDCSS.

If you want to change the commands in this file, you should probably go read the help for CP Monitor first and get familiar with how CP Monitor works.

Starting Monitor Data Collection

To start the monitor, either:

• CP FORCE LINMON and then CP XAUTOLOG LINMON, or
• Log on to LINMON, get a "Ready;" prompt, and then press PF1 and hit ENTER.

The first couple of times you try this, you might consider using the second method, just to make sure that you see the console messages that indicate data collection has started.

Stopping Monitor Data Collection

To stop the monitor, either:

• CP FORCE LINMON, or
• Log on to LINMON and type this: MONWSTOP

Where the Data Lands

The data ends up on LINMON 291 in one or more CMS files. These files are suitable for input to the VM Performance Toolkit.

Here is a screen shot of FILELIST, showing an example of what you might see on the LINMON 291 minidisk. The raw monitor files are the ones of F 4096 format.

To calculate how big a raw monitor file is, divide the "Records" column by 256. The quotient is the file's size in MB.

How to Send Us Raw Monitor Data

Probably the best way for you to send us raw monitor data is to pack it into a VMARC archive file and then use FTP to push the archive file to our receiving server testcase.boulder.ibm.com.

Do not COPYFILE ( PACK the raw monitor files before packaging them with VMARC, and do not COPYFILE ( PACK the archive file after you build it.

VMARC is a file compression utility that crams a bunch of CMS files into one single CMS file, data-compressed. This is similar to the idea behind ".zip" files in the PC world.

I recommend you package your data with VMARC even if you are sending us only one file. Raw monitor data compresses well, so your FTP operation won't take so long. Also, using VMARC to package the file helps protect it against corruption.

The syntax for your VMARC command(s) would be this:

VMARC PACK infn inft infm outfn outft outfm ( options

where:

• infn inft infm is your input file, e.g, D052107 T083242 A
• outfn outft outfm is the archive file you are building, e.g., MONDATA VMARC A
• options are the options for the command:
  • Use ( REPLACE for the first file. This creates the archive.
  • Use ( APPEND for the rest of the files. This appends to the archive.

Here's an example of how to put three raw monitor files into one VMARC archive file. Notice for the first command, we use REPLACE to create a new archive. For the next two commands, we use APPEND to append to the archive we created.

Then FTP the archive file in binary to testcase.boulder.ibm.com. Put your file into the directory /toibm/vm/. If your data is associated with a PMR, name the file according to your PMR number, for example, 12345.678.000.mondata.vmarc or some such. For more information about using testcase, visit the testcase page.

Do not use any of the VM-ish FTP options, such as SITE FIXREC, LOCSITE FIXREC, or QUOTE SITE FIXREC, when moving the VMARC archive file. Just FTP it in binary.

Interaction with z/VM Performance Toolkit

If you are already running z/VM Performance Toolkit (Perfkit), then you already have a MONDCSS segment on your system. My collector will never attempt to recreate MONDCSS, no matter what.

However, be aware that the Perfkit user ID PERFSVM does contain some CP MONITOR commands in its PROFILE EXEC. If you did not subordinate my collector, PERFSVM and LINMON will both be tinkering with the settings with CP Monitor, and the last user ID to initialize will win. This won't generally cause a functional problem, but it will affect what kinds of raw data you end up with in your MONWRITE files.

If in doubt, you can always log on to a privileged user ID such as MAINT, issue QUERY MONITOR, see what the settings are, and issue CP MONITOR commands by hand to change Monitor's configuration. Neither LINMON nor PERFSVM will mind if you do this. Be aware, though, that if you restart PERFSVM or LINMON after having done this, the CP Monitor settings will change.

Getting Help

If you need help, contact me.

This web page might also be helpful.