***********************NEWSLETTER FIFTY-EIGHT***************************
          MXG NEWSLETTER NUMBER FIFTY-EIGHT, Oct  1, 2011.              
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                              
I.    MXG Software Version.                                             
II.   MXG Technical Notes                                               
III.  MVS, aka z/OS, Technical Notes                                    
IV.   DB2 Technical Notes.                                              
V.    IMS Technical Notes.                                              
VI.   SAS Technical Notes.                                              
VI.A. WPS Technical Notes.                                              
VII.  CICS Technical Notes.                                             
VIII. Windows NT Technical Notes.                                       
IX.   z/VM Technical Notes.                                             
X.    Email notes.                                                      
XI.   Incompatibilities and Installation of MXG.                        
         See member CHANGES and member INSTALL.                         
XII.  Online Documentation of MXG Software.                             
         See member DOCUMENT.                                           
XIII. Changes Log                                                       
     Alphabetical list of important changes                             
     Highlights of Changes  - See Member CHANGES.                       
I.  The 2011 Annual Version MXG 28.28 was dated Jan 18, 2011, but it was
    replaced by MXG 29.01 dated Feb  4, 2011.                           
    You can always use this form                                                           
    to request the ftp download instructions for the current version.   
 1. The current version is MXG 29.06, dated Sep  8, 2011.               
    See CHANGES member of MXG Source, or    
II.  MXG Technical Notes                                                
 1. Daily BUILDPDB on 8GB 64-bit Intel Duocore E7500 2.93 Ghz,          
    Windows Seven Professional 64-bit,                                  
    SAS V9.2 64-bit.                                                    
    SMF read:   19,803,835,294 Bytes  @7345KByte/Sec 9,819,991 records  
    MXG BUILDPDB "Big data" step:                                       
       1:08:00 elapsed  13:50 total CPU (12:42 User, 1:08 System)       
    Total daily run including some reports                              
       1:27:00 elapsed  22:08 total CPU (20:21 User, 1:47 System)       
    Output PDBs:                                                        
     CICSTRAN CICSTRAN   4,677,295 obs   3.00 Gigabytes                 
     PDB                                 3.35 Gigabytes                 
              DB2ACCT      867,135       1.30 Gigabytes                 
              DB2ACCTP   1,267,153       0.60 Gigabytes                 
              TYPE42DS   2,057,402       0.50 Gigabytes                 
              SMFINTRV     275,725       0.20 Gigabytes                 
              STEPS        260,484       0.20 Gigabytes                 
               Rest of PDB               0.55 Gigabytes                 
III. MVS, a/k/a z/OS, Technical Notes.                                  
14.  CA TSO/MON V6.2 CAUSES MXG JOBS TO FAIL ON z/OS 1.12.              
     MXG jobs that ran fine on z/OS 1.10 failed when run on z/OS 1.12   
     because TSO/MON corrupts the floating point instructions.          
     Errors in three separate jobs processing different SMF records:    
     - INVALID DATA FOR SMFTIME IN LINE 85041 3-10.                     
     - ***ERROR. INVALID DB2 PRODUCT HEADER ID=101 QWHSLEN=50370        
     - INVALID ARGUMENT TO FUNCTION DATEJUL                             
     There is no clue in any of these errors that TSO/MON is involved.  
     These two APARs for TSO/MON are required to correct:.              
     TSO/MON HIPER APAR RO34278 (8/25/2011, was test APAR T5QV357 8/11) 
     documents that "Applications using Floating Point registers will   
     experience a series of data exceptions followed by an S059 abend.  
     SAS applications using 2 dimensional arrays may run into           
     subscripting problems Customers experiencing these problems were   
     migrating to z/OS 1.12."                                           
     TSO/MON APAR R029589 (Apr 27, 2011), corrects PTF R022614 states:  
     "When moving to the z/OS 1.12 operating system, you will experience
     various abends in the TSO user address spaces, as well as other    
     applications.  This can sometimes be observed during the data      
     recording phase or when TSO users are logging on or off, and when  
     batch TSO jobs start. The problem is exacerbated when system       
     control blocks are overlaid, which causes the system to become     
     Both of these CA APARs are HIPER - which means that if your TSO/MON
     "guru" has signed up for alerts, he/she will have been notified by 
     CA of the critical need for these corrections.                     
     SAS Problem Note 44042 also documents this TSO/MON error.          
13. IBM APAR OA24074, documented in MXG Newsletter FIFTY-TWO, changed   
    the RMF Report calculation of Percent MVS Busy, by subtracting the  
    Hiperdispatch Parked Time SMF70PAT, and MXG's PCTMVSBY was revised  
    to match IBM since the Parked Time is NOT a part of capacity.       
    But, that APAR did NOT document that IBM chose NOT to also revise   
    their calculation of LPAR Busy (PCTCPUBY), but MXG has always       
    correctly calculated PCTCPUBY and PCTMVSBY by NOT including the     
    parked time in the denominator of capacity.  IBM's choice was just  
    recently restated in a PMR which stated:                            
      With hiperdispatch, RMF changed the way it calculates the MVS busy
      to not take into account parked engines.  This is described in the
      text of APAR OA24074 with an example there of how parked engines  
      can affect the MVS BUSY calculation.  However LPAR BUSY does not  
      consider whether engines are parked.  This can throw people off,  
      especially if there are a large # of engines.  It is one reason   
      that you will still want to define some reasonable number of      
      logical engines for your LPAR, not necessarily the max possible.  
      For example, if you had 32 physical engines on the box,  and an   
      LPAR that only ever used a weight equivalent of 4 engines, then   
      you might define 8 engines to the LPAR (some number larger than 4 
      for a buffer), and let hiperdispatch park some of them.  But you  
      might not want to define all 32 to that LPAR.  Even though        
      hiperdispatch would park most of them, the reporting which        
      includes the parked engines can confuse people if they are not    
      expecting it.                                                     
    In other words, IBM RMF REPORTS ARE WRONG and do not match the      
    more-correct MXG calculations of both PCTCPUBY and NRCPUS, both     
    of which take into account the parked time as "not available".      
12. APAR OA36831 corrects negative (or very large) values in SMF 74     
    fields SMF74SSC, SMF74MEC, SMF74CNN, SMF74PEN and SMF74ATV, in an   
    interval with Hyperswap activity.                                   
11. APAR OA35175 new SMFPRMxx SMF parameter DSPSIZMAX for SMF Logstreams
    allows you to specify the maximum amount of storage that each SMF   
    logstream data space will consume.  This parameter applies to any   
    logstreams specified with the LSNAME or DEFAULTLSNAME keyword which 
    does not have this keyword specified as a suboption.  This option   
    can not be changed when SMF is active.  If it is attempted to be    
    changed message IFA760I will be issued. The default is 2 GigaBytes. 
    See MXG Change 29.177 and APAR OA35175 which add data to SMF 23.    
10. APAR OA36761 reports correction to variables SM42GRW and SMA2GRW in 
    SMF 42 subtype 16 records (TYPE42D1,TYPE42D3 MXG datasets).         
 9. Tabulation of IBM Created SMF Records that contain JOB name, with   
    list of other accounting fields that are needed or present; Cheryl  
    Watson proposed a series of SHARE requirements for each owner of    
    SMF records that are used for accounting and cost recovery to add   
    the z/OS ACCOUNT fields.  I reviewed and suggested that SYSPLEX is  
    now needed for accounting, since you can have multiple instances of 
    the same SYSTEM name in a CEC, and that JCTJOBID has always been    
    required to fully match JOB-level accounting information, because   
    JOB and READTIME are not necessarily unique.  This table shows all  
    of the IBM-created SMF records that contain JOB name, with their    
    status with regard to the other requested fields, for Cheryl to     
    rank for importance and submit to SHARE:                            
        6        YES     YES      YES       NEED    NEED                
       10        YES     YES      NEED      NEED    NEED                
       14/15     YES     YES      NEED      NEED    NEED                
       16        YES     YES      NEED      NEED    NEED                
       17/18     YES     YES      NEED      NEED    NEED                
       21        NEED    NEED     NEED      NEED    NEED                
       24        YES     YES      NEED      NEED    NEED                
       25        YES     YES      NEED      NEED    NEED                
       26        YES     YES      YES       YES     NEED                
       30        YES     YES      YES       YES     YES                 
       32        YES     YES      YES       NEED    YES                 
       32        YES     YES      NEED      NEED    YES                 
       36        YES     YES      NEED      NEED    NEED                
       40        YES     YES      NEED      NEED    NEED                
       41        YES     NEED     NEED      NEED    NEED                
       42        YES     YES      YES       NEED    NEED                
       57        YES     NEED     YES       NEED    NEED                
       59        YES     NEED     YES       YES     NEED                
       60        YES     YES      NEED      NEED    NEED                
       61/65/66  YES     YES      NEED      NEED    NEED                
       62/64     YES     YES      NEED      NEED    NEED                
       79        YES     NEED     NEED      NEED    YES                 
       80        YES     YES      NEED      NEED    NEED                
       83        YES     YES      NEED      NEED    NEED                
       84        YES     NEED     YES       NEED    NEED                
       85        YES     NEED     NEED      NEED    NEED                
       90        YES     NEED     YES       NEED    NEED                
       91        YES     YES      YES       NEED    NEED                
       92        YES     YES      NEED      NEED    NEED                
       99        YES     NEED     NEED      NEED    NEED                
      103        YES     NEED     NEED      NEED    NEED                
      110        YES     YES      NEED      NEED    NEED                
      111        YES     NEED     NEED      NEED    NEED                
      112        YES     NEED     NEED      NEED    NEED                
      113        YES     YES      NEED      NEED    NEED                
      114        YES     NEED     NEED      NEED    YES                 
      119        YES     YES      NEED      NEED    YES                 
      120        YES     NEED     YES       NEED    YES                 
      122        YES     NEED     YES       NEED    NEED                
      123        YES     NEED     NEED      NEED    NEED                
 8.  DSNTYPE=LARGE or Extended Format support in SAS V9.2:              
     All the DSNTYPE=LARGE does is allow more than 64k tracks per volume
     to be allocated.  The support could not be put in place till z/OS  
     1.7 when EXCP had the ability to address beyond the 64k track limit
     through the TTR, but DSNTYPE=LARGE can be used; see SAS Note 17038.
     Extended Format, Striped, Hardware Compressed z/OS datasets have   
     always been useable, but ONLY for "single dataset data libraries in
     sequential format", i.e., your CICSTRAN.CICSTRAN dataset can be    
     hardware compressed if written to an EF dataset, but you can't     
     really write multiple SAS datasets to that sequential data library,
     since it must be tape format, i.e., with NO directory, so you would
     have to read the entire first dataset to get to or to start writing
     a second dataset to that library.  SAS also refers to these        
     datasets as "sequential access bound libraries (tape format) on    
     disk", and SAS Note 17038 specifically states that DSNTYPE=LARGE   
     can NOT be used for those datasets.                                
     SAS does not have extended format for a SAS bound library on disk  
     because it is not supported by EXCP which is the access method     
     service used for SAS I/O for the bound library.  The tape engine   
     can be used (and stored on DISK) because this is using BSAM as the 
     access method.  SAS thinks that IBM does not intend to extend the  
     support to EXCP either, but IBM also said that before DSNTYPE=LARGE
     support existed, but that was then delivered in z/OS 1.7.          
 7.  APAR OA35989 corrects a HiperDispatch problem when processors are  
     not unparked.  On a large test system that was idle, except for a  
     small test partition that is running with HiperDispatch=YES, low   
     polarized processors may not be unparked, even though there is     
     sufficient demand on the small partition and there is a large      
     amount of free capacity on the CEC.                                
       In module IRABAADJ the free CEC capacity in variable             
       VCM_CecCapFree is checked against a limit. The variable is of    
       type Fixed(31) and is multiplied by 256 for the compare.  If the 
       amount of free CEC capacity is very large, an overflow may occur 
       due to this multiplication.  As a result, a very large free CEC  
       capacity value may not be recognized and a vertical low processor
       will not be unparked.                                            
 6.  In Nov 2010, APAR OA25831 was installed, PTF UA56641 for z/OS 1.10.
     After the IPL of each LPAR, the total frames (SMF71TFC + SMF71FIN) 
     was 261 frames less than the total storage assigned to the         
     partition.  Eventually IBM created APARs to correct the problems,  
     APAR OA35901 only for z/OS V1.10 (fixed in base of z/OS  V1.12)    
     APAR OA35898.  The fix for APAR OA35901 is in the base of z/OS     
     V1.12 and the ++APAR fixtest for OA35898 restores the correct total
     frame count.  Most users will probably never notice the error since
     the total number of frames was so small.  SMF71TFC is PVTPOOL and  
     SMF71FIN is PVTFPFN in MXG TYPE71 dataset.                         
 5.  APAR OA33307 is needed for z/OS 1.11; it corrects high CPU time in 
     MASTER address space and increased paging.                         
 4.  APAR PM35809 corrects Average CPU Time in SMF 120 subtype 6 and 8  
     interval records, variables SM120WJ4 and SM120JMQ, which w         
     accurate because integer arithmetic was losing the remainder.      
 3.  There no SMF 30 interval records for the BPXAS address space.      
     From a posting to IBM-Main in 2011, an IBM answer, from a prior PMR
        Since address space BPXAS creates the spawn or forked address   
        space, it will not write any SMF interval records.  The interval
        record will be generated in the name of the forked or spawned   
        address space during the processing of that job.   BPXAS is like
        the initiator with no job running in it at that time.           
 2.  IBM 'Driver 79' maintenance has affected SMF70CSF (Central Storage)
     with zero values for all LPARs on the physical 2097 CEC, while the 
     values on the new z196 LPARs appear to be correct.  IBM's response 
     was  "open a hardware record indicating SMF70CSF is zero and you   
     will need hardware MCL N24404.008 in Bundle 37.  The hardware      
     record is the delivery method for the fix."                        
 1. APAR OA31856 reports TYPE42DS Read Disconnect Time and Read count   
    (S42DSRDD/S42DSRDT) were invalid if an EXCP Channel Program was     
    built using a Locate Record Extended, because any writes were       
    considered to be reads.                                             
IV.   DB2 Technical Notes.                                              
 5. APAR PM17542 enables DB2 Performance Improvements with z/OS 1.12,   
    one of which was to eliminate EXCP/IOTM counting at the DD level in 
    DB2 SMF type 30 records by eliminating the DD segments, losing the  
    EXCPDASD,EXCPTAPE,EXCPTODD counts at the device-type level.         
    However, OA37361 reports that "after PM17542, SMF IO counting at the
    Address Space level are no longer available", which was NOT IBM's   
    intention, so this newer APAR reinstates ASID counts, which are the 
    EXCPTOTL/IOTMTOTL variables in MXG.                                 
       The Media Manager only records SMF IO counts if the caller       
       requested it and a DD token exists.  A data set allocated via    
       dynamic allocation with the S99DASUP bit set on, will not        
       generate a DD token. Any EXCP/IOTM to those dynamic allocation   
       with S99DASUP on will be seen in EXCPTOTL and EXCPNODD but       
       will NOT be counted in EXCPTODD.                                 
 4. APAR PM39194 corrected zero values in QWACBSC and QWHSSTCK in       
    SYSPLEX Query Parallel Rollup SMF 101 DB2ACCT records.              
 3. APAR PM27872 announces sample program DSNTSMFD that decompresses    
    DB2 SMF 100, 101, and 102 compressed records (and DSNTEJDS JCL to   
    ASM/LKED/run).  There is a limit of 512 DB2 Subsystems, because     
    the program reports detail statistics on each subsystem, and the    
    program will fail on the 513rd subsystem, but that limit is set     
    in DB2_ARRAY_MAX in the sample ASM source code.  Of course, this    
    utility is not needed by MXG users on z/OS, since EXITCICS will     
    decompress not only the DB2 100,101,102 but also CICS 110 and 112.  
 2. APAR PM30468 reports that DB2 zIIP usage for DB2 V10 Prefetch and   
    for Deferred Write zIIP direct, is erroneously reported under MSTR, 
    instead of DBM1.                                                    
 1. APAR II07124 discusses problems in DB2 pausing for 1 to 5 minutes   
    while writing SMF records when the (now known to be STUPID default) 
    DDCONS=YES is in use, and recommends DDCONS=NO (See item 3.g in MXG 
    NEWSLETTER SIXTEEN, "No EXCP data for type 30 subtypes 4 and 5...." 
    for MXG's extensive discussion of DDCONS and DETAIL vs NODETAIL     
    But this Information APAR adds this note:                           
    If the DB2 address space is run as a batch job, then the INTERVAL   
    and NODETAIL options will have no effect.  If the DB2 address space 
    is run as a started task (STC) then either the INTERVAL and NODETAIL
    options must be put on the SYSSTC parameter, or the SYSSTC parameter
    must inherit those options from the SYS parameter.                  
V.   IMS Technical Notes.                                               
 1. Text                                                                
VI.  SAS Technical Notes.                                               
 3. If using Enterprise Guide and you choose a device driver for        
    graphics routines you may get a message:                            
       Insufficient authorization to use yadayada                       
    Circumvention according to SAS knowledge base is to make the first  
       ODS LISTING CLOSE;                                               
 2. Some TYPE70 variables cannot be dropped when TYPE70 is created,     
    because they are used internally in the MXG logic in VMAC7072       
    to create the TYPE70PR dataset.  In particular, this error message  
    HAS NEVER BEEN REFERENCED  will occur if you drop those variables.  
    a. You could create WORK.TYPE70 with your tailoring, and then use   
        BY _BTY70;                                                      
       to DROP those variables from your final PDB.TYPE70 dataset.      
    b. However, there is an alternative, for this case, where the MXG   
       code that references these two variables is the statement        
             FROM70PR (IN=FROMPR) ....                                  
       You can specify OPTIONS DKRICOND=NOWARN; to prevent the error    
       message where these variables are dropped from an INPUT.         
    c. To be compete, MXG defaults the OPTIONS DKROCOND=NOWARN; for     
       variables in the OUTPUT with Drop/Keep/Rename, because there are 
       specific cases where variables are in the KEEP= list that may or 
       may not exist. (In CICSTRAN, there are optional segments and     
       their variables are in the KEEP= list, but they only exist if    
       you have tailored their corresponding IMACICxx member to create  
       them, and the DKROCOND=NOWARN value prevents a similar error     
    d. The above case for DKRICOND=NOWARN is the first instance where   
       that has been needed, but I'm not prepared to make it also an    
       MXG default, at least not from this one instance.                
 1. Install of SAS V9.2 for z/OS is rumored to be difficult, but by just
    following the SAS Install Instructions at:                                                       
    we found that the upload and install of the (7.5 GB) z/OS SAS Depot 
    V9.2 SAS/BASE Component (which is all that is required for MXG)     
    took less than two hours for a competent systems programmer, even   
    one who had not done a z/OS SAS install in many years (BUT ONLY if  
    everything needed is already in place!).                            
    What might be needed to be in place prior to the SAS upload? The    
    size of the depot itself will typically vary between 5GB and 17GB   
    depending on the mix of products to be installed.  Given that the   
    SAS Depot will likely be uploaded to a ZFS filesystem (the other    
    option is NFS attached), and with the z/OS restriction of 4GB for   
    the size of a (normal) zFS mount point, you will either need the    
    authority to define a larger zFS mount point, or be able to use an  
    existing zFS mount point(s) large enough for the SAS Installation.  
    Either must be created with the SMS Data Class EXTENDED attribute.  
    In fact, if you take the most straight forward approach you will    
    need two zFS directories of 5GB to 17GB because the SAS Depot stages
    into a second zFS directory (SASHOME) which is used during the      
    actual install to z/OS datasets.                                    
    Once the needed zFS space (with EXTENDED attribute) and commensurate
    z/OS space needed for the target DSNs is available it should be     
    clear sailing.                                                      
    But, one last note, do NOT use that EXTENDED attribute for the Data 
    Class of your SAS Data Libraries on z/OS; it is not supported due   
    to SAS's use of the EXCP access method.                             
VI.A.  WPS Technical Notes.                                             
 1. Text                                                                
VII. CICS Technical Notes.                                              
 1. Text                                                                
VIII. Windows NT Technical Notes.                                       
 1. Text                                                                
IX.  z/VM Technical Notes.                                              
 1. z/VM MONWRITE data from two z/VM LPARs was compared with RMF 70 data
    (SMF70CIN=IFL data for both "IFL LPAR" and "IFL PHYSICAL") for this 
    four shared-IFL system with 23 hours of matching data.              
    RMF only has IFL Utilization for SHARED IFLs WITH WAITCOMPLETE=NO,  
    in TYPE70PR,ASUM70PR,ASUM70LP,ASUMCEC, and ASUMCELP datasets.       
    IFL Utilization is always 100% Busy; for these environments, z/VM   
    MONWRITE (TYPEVMXA) must be used to measure IFL utilization.        
    The RMF "IFL BUSY" time was 87.31 hours (so the IFLs were busy 94.7%
    of those 23 hours).  Those 87.31 hours of IFL BUSY time are 5239    
    minutes, and MONWRITE captured 5182 minutes (98.9%) of that hardware
    busy time.  And of the 57 minutes not captured in MONWRITE, 49      
    minutes were the z/OS IFL Management Time.  Or, MONWRITE captured   
    all but 7 minutes of the 5189 minutes of the "Effective Dispatch    
    Time" recorded by z/OS.                                             
          VMCPU    =  MONWRITE CPU (PFXUTIME+PFXSYSTM)                  
          IFLACTTM =  RMF Partition CPU Dispatch Time, SMF70CIN='IFL'   
                       (both LPAR and PHYSICAL for IFL)                 
                      *****ONLY VALID FOR SHARED IFLs*****              
          DIFF     =  IFLACTTM minus VMCPU                              
          LCPUMGTM =  LCPUPDTM minus LCPUEDTM                           
          LCPUPDTM =  Logical/Physical LPAR Partition Dispatch CPU Time 
          LCPUEDTM =  Logical/Physical LPAR Effective Dispatch CPU Time 
               hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss  hh:mm:ss  hh:mm:ss  
             0  3:45:32  3:48:37  0:03:05  0:02:41   3:48:37   3:45:56  
             1  3:31:17  3:34:15  0:02:58  0:02:37   3:34:15   3:31:38  
             2  3:52:58  3:55:15  0:02:17  0:02:00   3:55:15   3:53:15  
             3  3:57:03  3:58:57  0:01:54  0:01:39   3:58:57   3:57:18  
             4  3:56:34  3:58:25  0:01:51  0:01:36   3:58:25   3:56:49  
             5  3:47:43  3:49:55  0:02:12  0:01:55   3:49:55   3:48:00  
             6  3:38:32  3:41:11  0:02:39  0:02:19   3:41:11   3:38:52  
             7  3:39:53  3:42:27  0:02:35  0:02:15   3:42:27   3:40:12  
             8  3:44:08  3:46:29  0:02:20  0:02:02   3:46:29   3:44:27  
             9  3:45:52  3:48:14  0:02:21  0:02:02   3:48:14   3:46:11  
            10  3:52:52  3:54:56  0:02:04  0:01:48   3:54:56   3:53:08  
            11  3:54:01  3:56:04  0:02:03  0:01:47   3:56:04   3:54:17  
            12  3:48:54  3:51:14  0:02:20  0:02:02   3:51:14   3:49:12  
            13  3:41:47  3:44:20  0:02:32  0:02:13   3:44:20   3:42:07  
            14  3:43:33  3:46:12  0:02:40  0:02:20   3:46:12   3:43:53  
            15  3:33:38  3:36:26  0:02:48  0:02:27   3:36:26   3:33:59  
            16  3:34:50  3:37:50  0:03:00  0:02:37   3:37:50   3:35:13  
            17  3:47:36  3:49:56  0:02:20  0:02:02   3:49:56   3:47:54  
            18  3:48:37  3:50:55  0:02:18  0:02:01   3:50:55   3:48:55  
            19  3:28:17  3:31:28  0:03:11  0:02:48   3:31:28   3:28:40  
            20  3:44:45  3:47:22  0:02:37  0:02:18   3:47:22   3:45:05  
            21  3:47:22  3:50:02  0:02:40  0:02:19   3:50:02   3:47:43  
            22  3:56:37  3:58:38  0:02:02  0:01:46   3:58:38   3:56:53  
               ======== ======== ========= ========  ========  ======== 
               86:22:20 87:19:09  0:56:49  0:49:33  87:19:09  86:29:36  
 2. MONWRITE does not provide synchronized interval records (yet???).   
    The below procedure is only run a IPL time or any situation the     
    requires a recycle.  This procedure holds the Monitor START command 
    until the next hour boundary, with the hour padded with a zero if   
    had only one digit, as the WAKEUP command doesn't support a single  
    digit hour.                                                         
       /* Make the monitor intervals start on the hour   */             
       'CP MONITOR STOP'                                                
       Parse value time('N') with hh ':' mm ':' ss .                    
       hh=hh+1                      /*Wait for the next hour*/          
       If ss=59 then mm=mm+1        /*May need a bit more time*/        
       If mm>60 then do             /*Overflow to the hour*/            
       If hh<10 then hh = '0'hh                                         
       'WAKEUP' hh':00:00'          /*Wait*/                            
       'CP MONITOR START'           /*Start the monitor*/               
X.    Email notes.                                                      
 1. Text                                                                
XI.   Incompatibilities and Installation of MXG vv.yy.                  
 1. Incompatibilities introduced in MXG 29.05 (since MXG 28.28):        
    See CHANGES.                                                        
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL (separate sections for each platform, z/OS, WIN,  
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member 
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.                                        
XII.  Online Documentation of MXG Software.                             
    MXG Documentation is now described in member DOCUMENT.              
XIIV. Changes Log                                                       
--------------------------Changes Log---------------------------------  
 You MUST read each Change description to determine if a Change will    
 impact your site. All changes have been made in this MXG Library.      
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The CHANGES selection on our homepage at            
 is always the most current information on MXG Software status,         
 and is frequently updated.                                             
 Important changes are also posted to the MXG-L ListServer, which is    
 also described by a selection on the homepage.  Please subscribe.      
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different than described in the change text (which might have printed  
 only the critical part of the correction that need be made by users).  
 Scan each source member named in any impacting change for any comments 
 at the beginning of the member for additional documentation, since the 
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.                     
Alphabetical list of important changes after MXG 27.27 now in MXG 29.07:
  Member   Change    Description                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage                                          
Inverse chronological list of all Changes:                              
Changes 29.yyy thru 29.001 are contained in member CHANGES.