COPYRIGHT (C) 1984-2018 MERRILL CONSULTANTS DALLAS TEXAS USA

MXG NEWSLETTER FIFTY-SEVEN

***********************NEWSLETTER FIFTY-SEVEN***************************
                                                                        
                                                                        
                                                                        
                                                                        
          MXG NEWSLETTER NUMBER FIFTY-SEVEN, JANUARY, 18, 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.                       
                                                                        
     COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA       
                                                                        
I.  The 2011 Annual Version MXG 28.28 is dated Jan 18, 2011.            
                                                                        
    All sites were EMAILED the ftp download instructions on Jan 18, 2011
    The availability announcement was posted to MXG-L.                  
    IF your email address is in our database AND your license is paid.  
    Otherwise, you can always use this form                             
         http://www.mxg.com/Software_Download_Request                   
    to request the ftp download instructions for the current version.   
                                                                        
 1. The current version is MXG 28.28, dated Jan 18, 2011.               
                                                                        
    See CHANGES member of MXG Source, or http://www.mxg.com/changes.    
                                                                        
II.  MXG Technical Notes                                                
                                                                        
 2.  Removal of duplicate (SMF) records on z/OS - new ANALDUPE member.  
                                                                        
     500,000 SMF Records Processed                                      
                                                                        
     Several techniques for removal of duplicate SMF records on z/OS    
     are provided in the new ANALDUPE member.  Two approaches are both  
     sort-based but are limited by requirements for MASSIVE amounts of  
     disk space or tape drives and require more CPU time than the two   
     elegant solutions created by MP Welch, who imagined a solution and 
     discovered that the SAS V9 MD5 (digital signature) function could  
     be used to create a unique Hash Value for each record, and the Hash
     Values are then sorted (instead of the full record), to MASSIVELY  
     reduce the disk and CPU requirements.  A one-pass solution using   
     a hash table works fine, but could rapidly exhaust virtual storage,
     so the recommended solution creates the MD5 Hash Value, but then   
     uses a second step (freeing temp space of the first step) and a SAS
     Format for the look up table to remove duplicates.                 
                                                                        
            SORT ONE       SORT TWO       SORT THREE         SORT FOUR  
            DISK BASED     TAPE BASED     MD5 HASH FUNCTION  MD5 HASH   
            29 SORTWRK     7 TAPE DRIVES  HASH TABLE         SAS FORMAT 
            1000 CYL       REQUIRED       ONE PASS           TWO STEP   
                                                                        
     CPU     41.40  SEC     49.80  SEC     16.2   SEC        16.2  SEC  
     SRB      3.60  SEC      6.60  SEC      0.6   SEC         1.2  SEC  
     EXT     31,780 K       31,776 K       43,848 K          50,284 K   
     SYS     11,860 K       11,864 K       11,884 K          12,060 K   
     EXCP   484,000        463,000         84,000           126,000     
     CONN    27.052 SEC     20.40  SEC     15.00  SEC        18.00  SEC 
     CLOCK  648.00  SEC   1380.00  SEC     18.00  SEC        42.00  SEC 
                                                                        
     Clearly it's much more efficient to hash a record and operate on a 
     shorter value than operating on the full record itself. In this    
     case, it works particularly well because there is no expectation   
     nor requirement to reorder the records.  The Hash table filled 2GB 
     of memory at 3.5 million unique records. But the two pass hash will
     handle hundreds of millions of records in most shops.              
                                                                        
                                                                        
 1.  Processing Compressed CICS data on z/OS and on Windows.            
                                                                        
     An SMF file of 125,712 ID=110 records that created 267,899 CICSTRAN
     transactions was 212 MB when IBM Compression was enabled, and was  
     970 MB when uncompressed by the IBM utility DFH$MOLS.  The example 
     JCL for CICS decompression is in new DFH$MOLS member in MXG 28.06. 
                                                                        
    -On z/OS, three alternatives exist to process compressed CICS data: 
                                                                        
     a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
     b. Use EXITCICS (SAS Infile Exit) to read COMPRESSED WITH EXIT.    
     c. Use MXG's internal SAS code to read COMPRESSED WITH INTERNAL.   
                                                                        
       Average 7 runs:    Elapsed    TCB    SRB   EXCP  Connect  Size   
                           (min)    (min)  (min)         (sec)          
                                                                        
      a. DFH$MOLS            .8      .07    .00   53158   11.2  212/970 
         UNCOMPRESSED       2.0      .62    .01   47934   11.3   970 MB 
             total          2.8      .69    .01  101092   22.5          
                                                                        
      b. COMP WITH EXIT     2.3      .70    .00   14549    5.7   212 MB 
                                                                        
      c. INTERNAL SAS      22.4     9.88    .00   14554    5.7   212 MB 
                                                                        
      As previously reported, the INTERNAL SAS algorithm on z/OS is VERY
      CPU intensive (and it takes a long time, too!).  DFH$MOLS and read
      UNCOMPRESSED is only slightly slower than reading COMPRESSED+EXIT,
      but the uncompressed file needs nearly 5 times the disk space for 
      the (temporary) uncompressed file, and I/O activity with DFH$MOLS 
      (read compressed, write uncompressed, then read uncompressed) took
      six times the EXCPs and four times the IOTM (Connect Time), so the
      reading of the compressed file with the EXITCICS exit is best.    
                                                                        
      Note that executing on z/OS with the ftp access method to read    
      data from a different z/OS system CAN NOT use the EXITCICS code.  
      The INFILE exit and the ftp access method are mutually exclusive. 
                                                                        
    -Executing SAS on Windows/ASCII platforms (which includes using the 
     SAS ftp access method), SAS Infile Exits do not exist (and, if they
     existed, the ASM code in EXITCICS couldn't execute on ASCII), so if
     the SMF data file is downloaded and then processed, there are only 
     two ways to process compressed CICS data:                          
                                                                        
                                                                        
     ORIGINAL EXAMPLE - SEE REVISED EXAMPLE IN NEWSLETTER SIXTY-ONE.    
                                                                        
     a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
     c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.    
                                                                        
                         Elapsed     User   SYS    Size                 
      a. DFH$MOLS            .4      .07    .00   212/970               
         ftp download       2.0      .04    .00    970 MB               
         UNCOMPRESSED        .4      .23    .05    970 MB               
           total            2.8      .34    .05                         
                                                                        
      c. ftp download       0.5      .01    .00    212 MB               
         INTERNAL SAS       3.8     2.71    .05    212 MB               
           total            4.3     2.75    .05                         
                                                                        
    The internal algorithm on Windows is only ten times as CPU intensive
    reading the compressed file, compared to reading uncompressed, but  
    a lot more disk space is needed for the uncompressed file.          
                                                                        
    Unfortunately, at this test site, we were not able to use the SAS   
    ftp access method on ASCII to read the uncompressed and compressed  
    files directly from z/OS, without download, for that comparison, but
    prior tests using the access method to directly read z/OS files have
    always been cheaper and faster than reading the downloaded files, so
    I would expect that if you can tolerate the temporary disk space on 
    z/OS for the uncompressed file, using DFH$MOLS first would be best. 
                                                                        
                                                                        
                                                                        
III. MVS, a/k/a z/OS, Technical Notes.                                  
                                                                        
19. APAR OA34480 for z/OS 1.12 RMF III, ERB944I REPORT IS NOT AVAILABLE 
    REASON CODE 2, due to an incorrect check for "zFS inactive or       
    shutting down.                                                      
                                                                        
18. APAR OA34375 provides new function SMARTENDPOINT for IFASMFDL for   
    SMF Dumping from Logstreams, and a new keyword SMARTEPOVER so that  
    the amount of time that is added to the end date/time to calculate  
    the smart end point can be controlled by the user.                  
    The SMF Manual is updated with these descriptions:                  
                                                                        
     SMARTENDPOINT      Specifies that processing of input records in   
                        the logstream should discontinue once it has    
                        been determined that records for all known SIDS 
                        contain a date and time that is past the        
                        IFASMFDL specified date and time plus the       
                        specified SMARTEPOVER value.                    
                                                                        
                        The default behavior is that IFASMFDL continues 
                        to read records all the way to the end of the   
                        logstream.                                      
                                                                        
                        This keyword only applies to the DUMP option.   
                                                                        
    SMARTEPOVER(hhmm)  Specifies the amount of time that is added to the
                       end date and time to determine the SMARTENDPOINT 
                       time.                                            
                                                                        
                       The value specified by hhmm can range from zero  
                       (0000) to two hours (0200). The value to specify 
                       can be determined by taking the following        
                       considerations into account:                     
                                                                        
                       - If no SIDs are being specified then this value 
                         should be set to double the maximum MAXDORM    
                         value of any image recording into the          
                         logstream. This allows for the best results    
                         from SID auto-detection.                       
                                                                        
                       - If all SIDs are being specified then this value
                         can be minimized down to zero.                 
                                                                        
                       - If only a single SID is being recorded into    
                         this logstream (for example in a DASD-only     
                         logstream) then this value can be minimized    
                         down to zero.                                  
                                                                        
                       The default for this value is two hours (0200).  
                                                                        
                       This keyword only applies when SMARTENDPOINT is  
                       specified.                                       
                                                                        
                                                                        
17.  z/OS 1.10 new parameter USEZOSV1R9RULES VSM has no impact on MXG.  
     It is a new optional control of allocation of GETMAINs, which MXG  
     never issues; that is SAS's job, and the default in DIAG is (YES)  
     which means no change from prior allocation scheme.                
                                                                        
16.  APAR PM16750 reports invalid BLKSIZE for SMF 42 subtype 6 after    
     using the IBM File Manager (FMNQSAM) DSU function with a procedure 
     containing REXX CHG_OUT function.                                  
                                                                        
15.  APAR OA34190 reports incorrect capacity data in SMF 30/89/90-34    
     when a dynamic processor speed change occurs.                      
                                                                        
14.  APAR OW47653 lists a number of errors in RMF Post Processor Reports
                                                                        
13.  APAR OA29314 makes no changes, but documents all of the things that
     DO NOT happen with regard to wlm weight management and group       
     capacity, especially the (BAD) design that:                        
        Group capacity will function together with IRD weight management
        as long as the partitions in the group are not subject to       
        capping. No weight moves will take place for partitions as long 
        as the group is being capped.                                   
                                                                        
12.  APAR OA32067 corrects SMF 42 Subtype 16 with SMF2ADG2=14880, which 
     was greater than the LRECL of the SMF record.  The text of the APAR
     is interesting reading!                                            
                                                                        
11.  Duplicate JESNR for OMVS "jobs" in SMF 30 subtype 1,2,3,4 and 5.   
                                                                        
     MXG has always used SMF 30 variables READTIME JOB JESNR to identify
     all of the records created by a "job", and JESNR was incremented   
     each time a new "job" was read in.  Now, OMVS/USS processes can    
     reuse WLM initiators, which retain their JESNR, so the SMF records 
     for different OMVS jobs will have the same duplicated JESNR.       
                                                                        
     These OMVS jobs creates subtype 1/3/4/5 records.  By using READTIME
     along with JOB and JESNR, these job's SMF records can be grouped to
     identify each job, but only accidentally because the closest values
     of READTIMEs for these duplicate JESNR jobs are 0.09 seconds, and  
     READTIME's resolution is 0.01 seconds.  At some point, OMVS jobs   
     will have identical READTIME and JESNR for different jobs, and we  
     will not be able to identify which SMF records belong to which job.
                                                                        
     For the interval, step terminate, and job terminate SMF 30 records,
     the OMVS Segment has exactly what we need, the OMVS Process ID,    
     to identify each OMVS "job"'s unique set of SMF data, but the SMF  
     30 subtype 1 job initiate record does not have an OMVS/USS Segment.
     If IBM could add that segment to the job initiate record, or even  
     just the PID and perhaps PPID fields, then we would have the data  
     to satisfy our billing/chargeback/auditors that we can correctly   
     identify the resources and identity of each JOB in z/OS, a feature 
     that is unique to the z/OS platform!                               
                                                                        
     But whether IBM does or does not add that identification data to   
     the SMF 30 subtype 1 records for OMVS tasks, I should be able to   
     solve the IBM exposure in MXG code, by adding the PID and PPID to  
     READTIME JOB JESNR to group the subtype 2/3/4/5 data, and I should 
     be able to detect and protect that unlikely instance in the        
     BUILDPDB logic when identical Subtype 1 records were created.      
                                                                        
                                                                        
                                                                        
     From IBM USS/OMVS support's explanation:                           
                                                                        
      When a USS application issues a fork or spawn request (and a new  
      address space for the request is required), USS will go to pool of
      WLM initiator address spaces to satisfy the fork/spawn request.   
      This is done to cut down on the overhead of address space         
      creation.                                                         
      When a fork/spawn is called, the new process will run in the WLM  
      initiator address space if one is available in the WLM init pool. 
      If no idle WLM inits are available then a new one is created to   
      satisfy the request.                                              
      When the requesting process terminates, the WLM init is returned  
      to the pool of WLM inits. There it will wait for a new fork/spawn 
      request. If 30 continuous minutes pass and the init is not used   
      again, it is ended.  But on a system that with significant USS    
      activity, it is more likely that it be re-used before the 30      
      (continuous) minutes elapses.                                     
                                                                        
      When a WLM init is re-used, the only thing it retains from the    
      previous job is its JOBID.                                        
                                                                        
      The following statements apply to WLM inits and USS:              
      - The WLM initiator will keep its JES jobid for its entire        
        lifespan (whether it is unused or in use).                      
      - The JOBNAME associated with a WLM initiator will change when it 
        is 'in use'.  When it is idle it will have a JOBNAME of BPXAS   
      - WLM initiators are eligible to be re-used when ANY process      
        issues a fork/spawn call.                                       
                                                                        
      When a new address space is created as part of a fork/spawn call, 
      USS will typically add a numeric suffix to differentiate the      
      parent process from the child process. It only does this IF the   
      parent process has a jobname of 7 characters or less.  With a     
      jobname of 8 characters, USS will not add a numeric suffix to the 
      jobname.                                                          
                                                                        
      With OMVS processes, each process has a Process ID (PID) and when 
      a child process is created, the PID of the Parent is recorded as  
      the PPID. You can use this Parent PID (PPID) to find the parent   
      that started this process.                                        
         A PPID of 1 is special as that is BPXOINIT. That means the     
         original parent has ended and the child is now an orphan.      
         The PPID is set to 1 which is BPXOINIT in this case.           
         The command D OMVS,A=ALL displays the PID and PPID for each    
         OMVS process so you can see how to chain back thru the PPID to 
         the parent process and if it has a PPID then back to that      
         parent and so on.                                              
                                                                        
                                                                        
     From IBM USS/OMVS support's explanation:                           
                                                                        
      When a USS application issues a fork or spawn request (and a new  
      address space for the request is required), USS will go to pool of
      WLM initiator address spaces to satisfy the fork/spawn request.   
      This is done to cut down on the overhead of address space         
      creation.                                                         
      When a fork/spawn is called, the new process will run in the WLM  
      initiator address space if one is available in the WLM init pool. 
      If no idle WLM inits are available then a new one is created to   
      satisfy the request.                                              
      When the requesting process terminates, the WLM init is returned  
      to the pool of WLM inits. There it will wait for a new fork/spawn 
      request. If 30 continuous minutes pass and the init is not used   
      again, it is ended.  But on a system that with significant USS    
      activity, it is more likely that it be re-used before the 30      
      (continuous) minutes elapses.                                     
                                                                        
      When a WLM init is re-used, the only thing it retains from the    
      previous job is its JOBID.                                        
                                                                        
      The following statements apply to WLM inits and USS:              
      - The WLM initiator will keep its JES jobid for its entire        
        lifespan (whether it is unused or in use).                      
      - The JOBNAME associated with a WLM initiator will change when it 
        is 'in use'.  When it is idle it will have a JOBNAME of BPXAS   
      - WLM initiators are eligible to be re-used when ANY process      
        issues a fork/spawn call.                                       
                                                                        
      When a new address space is created as part of a fork/spawn call, 
      USS will typically add a numeric suffix to differentiate the      
      parent process from the child process. It only does this IF the   
      parent process has a jobname of 7 characters or less.  With a     
      jobname of 8 characters, USS will not add a numeric suffix to the 
      jobname.                                                          
                                                                        
      With OMVS processes, each process has a Process ID (PID) and when 
      a child process is created, the PID of the Parent is recorded as  
      the PPID. You can use this Parent PID (PPID) to find the parent   
      that started this process.                                        
         A PPID of 1 is special as that is BPXOINIT. That means the     
         original parent has ended and the child is now an orphan.      
         The PPID is set to 1 which is BPXOINIT in this case.           
         The command D OMVS,A=ALL displays the PID and PPID for each    
         OMVS process so you can see how to chain back thru the PPID to 
         the parent process and if it has a PPID then back to that      
         parent and so on.                                              
                                                                        
                                                                        
10.  Impact of NO REGION versus REGION on JOB and STEP JCL statements.  
     (MXG Version 32.32, Jan 2015: BUILDPDB REGION=140M, 31.31 was 130M)
                                                                        
      REGION         REGION    REGREQST in TYPE30_4                     
      on JOB         on STEP    that the step                           
      "CARD"  step   "CARD"     received                                
                                                                        
       none  step 1   none       64M <- IEFUSI site limit no REGION     
       none  step 1   150M      150M                                    
        0M   step 1   none       10M <- IEFUSI site limit for 0M        
       150M  step 1   none      150M                                    
       150M  step 1   400M      150M                                    
                                                                        
       none  step 1    10M       10M                                    
       none  step 2   150M      150M                                    
       none  step 3   400M      400M                                    
       none  step 4    40M       40M                                    
       none  step 5    64M       64M                                    
                                                                        
                                                                        
 9.  APAR OA34261 corrects error in RMCTADJN (MXG R723NADJ) when running
     at reduced speed, (e.g., due to Power Save Mode).  In control block
     IRARMCT, module IRAEVSSI may return incorrect values due to        
     rounding problems when the machine is running at reduced speed.    
        Instead of computing RMCTADJN from RMCTADJC proportionally to   
        the ratio of actual and nominal CPU capability, module IRAEVSSI 
        has been changed to calculate RMCTADJN similar to RMCTADJC by   
        applying the MP factors to the nominal CPU capability.  D/T2817 
                                                                        
 8.  APAR OA34576 documents that false contention values may differ     
     between SMF 74, SMF 42, and the D SMS,CFLS command results.        
        False Contention is recorded by XCF when it detects multiple    
        values hashing to same entry in a coupling facility lock        
        structure.  When this is detected a counter is incremented      
        internally, and passed to RMF(SMF 74) via macro call.  The      
        requestor of the lock will be notified of false contention via  
        the completion exit once the request has been satisfied.  False 
        contention can occur on IXLLOCK, IXLALTER, or IXLRELEASE calls. 
        When a request hits contention, it becomes globally managed by  
        XCF.  If it was incorrectly in contention and the global manager
        runs the request it is marked in False Contention.  Thus even   
        release requests can incur false contention counts.             
        But, in SMSVSAM's (SMF 42 and the D SMS command), only lock or  
        alter requests have their values recorded for false contention, 
        while Release requests are ignored.                             
        SMF 74s may have higher false contention counts than SMF 42.    
     LOCAL FIX:                                                         
        Use RMF and SMF 74's to keep track of false contention values.  
        False contention can occur during release request.              
        Currently, SMF42 only records lock and alter requests.          
        Due to skipping the release requests, SMF74 false contention    
        values are higher than the SMF42 records.                       
                                                                        
 7.   APAR OA33682 addresses Page Fixing Storage issues between 16M-2G. 
                                                                        
                                                                        
 6.   APAR OA33527 reports Logical OUT and READY count in RMF 70s can be
      wrong in z/OS 1.11.                                               
                                                                        
 5.   APAR OA31895 corrects an error in RMF 73 records (although the    
      text only mentions corrections to the RMF IOQ Report) that when   
      Channel Paths are added dynamically, they are not recorded.       
                                                                        
 4.   APAR OA30563 and z/OS 1.12 added the MAXEVENTINTRECS parameter in 
      SMFPRM to determine if type 30 and type 89 interval records will  
      be generated when the processor capacity is changed.  This could  
      be important for billing issues, since the CPU times recorded are 
      potentially impacted by a capacity change.  The default value of  
      MAXEVENTINTRECS is zero, so no event driven interval records are  
      created when capacity is changed.  If non-zero, the value limits  
      the maximum number of event driven interval records allowed during
      a regular scheduled interval. The capacity changes are recorded in
      SMF70CCR and can be due to POWERSAVE or CYCLESTEERING or EXTERNAL.
                                                                        
 3.   APAR OA34007 reports SMF30 TIME_ON_ZIIP can be negative in subtype
      3 records; this caused LARGE values in CPUZIPTM.                  
                                                                        
 2.   APAR OA33712 reports SMF64DAU and SMF64RLM were swapped, but now  
      are correct.  OA33712 is an AE fix completion for OA33315.        
                                                                        
 1.   APAR OA33841 corrects SMF 14/15 error; CLOSTIME/SMF30OPD was set  
      incorrectly to zero time if OPENTIME/SMF30OPE was midnight, i.e.  
      exactly zero time.                                                
                                                                        
IV.   DB2 Technical Notes.                                              
                                                                        
 2. How do you find out who deleted/dropped a DB2 database/table.       
                                                                        
    If you had the DDL Audit Trace enabled it is easy.                  
         %ANALDB2F(PMACC01=NO,PMACC02=NO,PMSTA01=NO,                    
                   PMAUD02=YES,AUDIT=DDL);                              
    will print those events.                                            
                                                                        
    But even if trace is not enabled, it still can be done:             
    Looking at the TYPE6156 records, selecting the zOS dataset name:    
                                                                        
      PROC PRINT DATA=TYPE6156 (WHERE=(ENTRNAME='whatever.yours'));     
      VARIABLES SMFTIME JOB ENTRNAME ACTION;                            
                                                                        
    you can find the time when the zOS datasets were deleted, but they  
    will show the job name of the DB2*DBM1 address space as the user.   
    Then looking at DB2ACCT records in the same time period with        
    QXDRPDB OR QXDRPTA OR QXDRPIC GT 0:                                 
                                                                        
      PROC PRINT DATA=DB2ACCT.DB2ACCT  (where=                          
      (   (qxdrpdb gt 0 or qxdrpta gt 0 or qxdrpic gt 0)                
                          and                                           
         ('18NOV2010:12:30:45.99'DT LE QWHSSTCK LE                      
          '18NOV2010:12:40:55.11'DT)  ));                               
      VARIABLES QWHCAID QWACBSC QWACESC QXDRPDB QXDRPTA QXDRPIX;        
                                                                        
    will show the RACFUSER that did the dirty deed in QWHCAID;          
                                                                        
 1. APAR PM17542.  DD Segments NOT WRITTEN as part of DB2 Performance   
    Improvements in z/OS 1.12.                                          
       DB2 exploits z/OS 1.12 new allocation functions to improve the   
       performance of allocation, deallocation, open, and close of the  
       data sets in DB2 page sets.  It will improve the performance when
       opening a large number of data sets concurrently, and shutdown   
       time, especially for DB2 users with high DSMAX.  Significant     
       reduction in elapsed time has been observed by DB2 and z/OS      
       performance test.  Allocation will manage DB2 data set ENQs in   
       memory, and SUPPRESS CERTAIN DB2 DD-LEVEL ACCOUNTING IN THE SMF  
       records to save significant overhead.                            
          ATTENTION to DB2 DBA and system programmers:                  
          To make the APAR effective:                                   
           - Update the ALLOCxx parmlib member to set                   
                SYSTEM MEMDSENQMGMT(ENABLE).                            
           - or issue command SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE.      
          Updating the ALLOCxx parmlib is strongly recommended as it    
          remains effective across IPLs.  If the SETALLOC command is    
          used to enable SYSTEM MEMDSENQMGMT, a DB2 restart is required 
          to make the change effective.                                 
       "Suppress CERTAIN DB2 DD-LEVEL ACCOUNTING" means that DB2 with   
       this APAR sets the new S99DASUP bit, described in MVS Programming
       Authorized Assembler Services Guide:                             
          S99DASUP    Used by authorized programs to suppress the       
          DD-level accounting. Setting this bit can affect the SMF      
          data created for the following:                               
             The EXCP section of SMF Record Type 30.                    
             SMF Record Type 40.                                        
             SMF Record Type 14 for the fields SMF14NTR and SMF14NER.   
          This bit is only recommended for programs allocating VSAM data
          sets with generated DD names, or when the exploiting program  
          has established that the usefulness of the SMF data is less   
          than the benefit to system performance.  Because the data is  
          used by an installation and suppressed by the exploiting      
          program, an external switch controlling the program's use of  
          this bit is strongly recommended.                             
       But the Services Guide is unclear (are ALL DD Segments suppressed
       or is S99DASUP set for individual DD's), but Bob Rogers' SHARE   
       presentation added information:                                  
         Suppress DD accounting (in SMF 30 records)                     
           Suppresses creation of SMF Type 30 EXCP section data on      
              a per-DD basis                                            
           Reduces CPU in Allocation and Unallocation processes         
           Requested by program with S99DASUP flag on DynAlloc          
       S99DASUP is set ONLY for Selected Dynamically Allocated DD's.    
       But, thanks to Merrill Consultant's IBM "TLC" Technical liaison  
       Consultant in Poughkeepsie, who contacted the author of the APAR,
       she has confirmed that the APAR suppresses all Database Dataset  
       Dynamic Allocation Requests in the DBM1 Address Space, so when   
       enabled, SMF 30 records for DBM1 will not contain DD segments    
       for those allocations.                                           
                                                                        
V.   IMS Technical Notes.                                               
                                                                        
 1.                                                                     
                                                                        
                                                                        
VI.  SAS Technical Notes.                                               
                                                                        
 2. Using SAS Enterprise Guide 4.2 or earlier with ANALDB2R, the        
    standard SAS report can fail to open when there exist unprintable   
    characters in DB2 data.  You may see some of the report if you      
    invoke HTML output, but in that HTML report you may see reams of    
    blank pages.  SAS Support said that EG 4.22 had added new data      
    cleansing functionality that would resolve the errors, adding:      
    To use this functionality, you must first bring the data down to    
    your PC, then use the "file > import" menu option in EG. After      
    importing the data, run your code against the newly imported data.  
    See also SAS Note http://support.sas.com/kb/32/133.html.            
    There are DB2 variables with mixed valid EBCDIC and HEX values.     
       Wherever possible, MXG changes '00'x in EBCDIC text fields to a  
       blank, because IBM initialized text fields with '00'x.  Or, MXG  
       formats all-hex variables with $HEX format so they are printable.
       But mixed fields can start with a useful EBCDIC text (netname)   
       followed by a TODSTAMP in hex aren't formatted $HEX because that 
       would make the useful EBCDIC name unreadable (except to certain  
       hex'd sysprogs!).                                                
    See member UTILNPRT in MXG 28.08 to identify all variables in all   
    SAS datasets that have non-printable character values.              
                                                                        
 1. z/OS SAS Version 9 USER ABEND U0998-16D is actually ABEND 16D RC 8  
    and only occurred on a system where the SAS write-SMF-record exit   
    was installed, but the SAS Load Library module was not copied over  
    when a SYSRES was cloned.                                           
                                                                        
                                                                        
VI.A.  WPS Technical Notes.                                             
                                                                        
 1. X                                                                   
                                                                        
VII. CICS Technical Notes.                                              
                                                                        
 1.                                                                     
                                                                        
VIII. Windows NT Technical Notes.                                       
                                                                        
 1. Using MicroSoft Security Essential, MSE, causes various errors when 
    the MXG QA job is run, never at the same place in the job:          
                                                                        
    ERROR: User does not have appropriate authorization level for       
           library WORK.                                                
           Followed, sometimes, with a second error:                    
           FATAL: Code generation error detected during BY compare      
           generation.                                                  
    ERROR: File Deletion Failed For MXGSUM1  (after prior successes).   
    ERROR: An I/O error has occurred on file WORK._tf6737.UTILITY.      
    ERROR: An I/O error has occurred on file WORK.OPTVAR.DATA.          
    ERROR: Rename of temporary member for WORK.OPTVAR.DATA failed.      
    ERROR: Rename of temporary member for WORK.TMVSCH.DATA failed.      
                                                                        
    Only by disabling MSE Settings to:                                  
      -exclude the SAS.EXE process                                      
      -exclude files *.sas7bdat and to                                  
      -exclude the d:\qa\ directory, where all output was written, AND  
      -exclude the d:\sastemp\ "WORK" directory.                        
    were both errors were eliminated.                                   
                                                                        
    However, that "does not have appropriate authorization level" error 
    can also occur, especially with Windows 7, without MSE, when your   
    program is attempting to write to the root directory or to the      
    Program Files directory, especially when not executing your program 
    "as administrator".                                                 
                                                                        
    This issue had been open with SAS Institute and Microsoft support   
    since February, 2010; finally, in October, a new MicroSoft "Senior  
    Escalation Engineer" attempted resolution, providing instructions   
    to install several MicroSoft diagnostics tools that either failed to
    initialize or failed to capture the event data, including runs with 
    TTTracer that generated over 85 GigaBytes of trace (how do you send 
    a file that big??) that still did not capture anything of use to MS.
    Then, out of the blue, in November, 2010, fourteen updates were auto
    installed by MicroSoft autoupdate, and the error went away.  The MS 
    escalation engineer was unable to identify which update corrected.  
                                                                        
    Moral: Disable MSE for SAS.                                         
                                                                        
    Update: May, 2011.                                                  
    RUN SAS AS ADMINISTRATOR.                                           
    Starting with SP1 for Windows 7, writing to any sub-directory under 
    c:\PROGRAM FILES is restricted, with NOT AUTHORIZED error messages, 
    unless SAS is RUN AS ADMINISTRATOR.  This is where the default SAS  
    root directory is located, which is where xxx.log and xxx.lst files 
    are created by default.                                             
    A Windows 7 system that does NOT have SP1 and its recent updates    
    does not restrict saving/writing into the SAS root directory here.  
                                                                        
    Update: May, 2011.                                                  
    Disable Microsoft Security Essentials, again.                       
    After autoinstall of SP1 for Windows 7, the above MSE error has     
    reoccurred, and in some cases, even using the above settings was    
    not sufficient; MSE real-time monitoring had to be turned off for   
    the full MXG QA job to complete.  These errors occur at different   
    times and places in the 33 minute QA job, and always involves a     
    file in the WORK library that is being written to, or is being      
    deleted (MXGSUM1) or is being renamed (OPTVAR), in the QA run with  
    zero observations.                                                  
                                                                        
    These errors with MSE and authorization are on 64 bit Windows 7     
    Ultimate on 64 bit hardware with 64 bit SAS, on two separate        
    machines; on two more machines that do NOT have SP1, these errors   
    do NOT occur.                                                       
                                                                        
IX.  z/VM Technical Notes.                                              
                                                                        
 1.                                                                     
                                                                        
X.    Email notes.                                                      
                                                                        
 1.  X                                                                  
                                                                        
                                                                        
                                                                        
XI.   Incompatibilities and Installation of MXG vv.yy.                  
                                                                        
 1. Incompatibilities introduced in MXG 28.28 (since MXG 27.27):        
    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 http://www.MXG.com            
 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 28.28:
                                                                        
  Dataset/                                                              
  Member   Change    Description                                        
                                                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage www.mxg.com.                                          
                                                                        
Inverse chronological list of all Changes:                              
                                                                        
Changes 28.yyy thru 28.001 are contained in member CHANGES.