****************NEWSLETTER THIRTY-SEVEN*********************************
             MXG NEWSLETTER NUMBER THIRTY-SEVEN, October 20, 2000       
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                          Page
I.   MXG Software Version 18.08.                                        
II.   MXG Technical Notes                                               
III.  MVS Technical Notes                                               
IV.   DB2 Technical Notes.                                              
V.    IMS Technical Notes.                                              
VI.   SAS Technical Notes.                                              
VII.  CICS Technical Notes.                                             
VIII. Windows NT Technical Notes.                                       
IX.   Incompatibilities and Installation of MXG 18.08.                  
X.    Online Documentation of MXG Software.                             
XI. Changes Log                                                         
     Alphabetical list of important changes                             
     Highlights of Changes 18.001 thru 18.250 - See Member CHANGES.     
I.   MXG Software Version 18.08 is now available, upon request.         
 1. Major enhancements added in MXG 18.08:                              
II.  MXG Technical Notes                                                
 1.   Converting from JES3 to JES2 (or vice versa) could cause problems 
      in your weekly/monthly jobs or in your regular reporting:         
        -JES2's BUILDPDB creates the PDB.NJEPURGE dataset, which is not 
         created by JES3, while JES3's BUILDPD3 creates the PDB.TYPE25, 
         PDB.DJEPURGE, and PDB.SPIN25 datasets, which are not created by
         JES2.  If those non-created datasets are referenced in reports 
         or WEEK/MONTH build jobs, you must revise those programs when  
         you change JESes.                                              
        -BUILDPDB for JES2 creates variables in PDB.JOBS, PDB.SPIN26,   
         and PDB.SPUNJOBS, from JES2 6 and 26 records, that do not      
         exist in those datasets built by BUILPD3 for JES3 records:     
            SMF26WOC SMF26WSE SUBMUSER SYSTRANS                         
III. MVS Technical Notes.                                               
26.   APAR OW46470 corrects wrong value in TYPE1415 management class and
      data class variables MGMTCLAS and DATACLAS. 19Oct2000.            
      See also OW46606. 03Nov2000.                                      
25.   APAR OW46336 corrects wrong value in TYPE26J2 variable JOBMODE1,  
      set from IBM bit SMF26SJB to indicate "Job ran because of $S J'.  
      IBM never set the bit, so JOBMODE1 was always blank in MXG. 19Oct.
24.   APAR OW43954 corrects a problem with high disconnect time in RMF  
      variable R723CIDT in dataset TYPE72GO, that also affected measures
      of velocity and delays.                                           
23.   APAR OW44517 corrects a problem with high uncaptured CPU time,    
      with capture ratio dropped by 10% (i.e., CPU time was lost in both
      SMF type 30 and RMF type 72 records).  This APAR applies to OS/390
      R2.5 thru R2.10.                                                  
22.   APAR OW45020 recommends you should now specify NOTYPE(69), even   
      though there are no type 69 (VSAM Data Space) records.  An LSPACE 
      macro is issued if TYPE(69) is specified explicitly or implicitly,
      and that LSPACE can cause an IPL or long delay as discussed in the
      APAR text.  Sep 7, 2000.                                          
21.   BMC's CMF type 71 SMF record had incorrect values for CSFRxxxx    
      fields.  Relevant BMC PTF numbers are BPM6617 (introduced error), 
      BPM6791 (fixed to make CMF look like RMF) & BPM7077 & BPM7557.    
      MXG Change 18.199 is also needed for CSFRxxxx TYPE71 variables.   
20.   APAR PN65504 reports SMF type 118 has incorrect timestamps for FTP
      start and stop events if the C-FTP server is used; timestamps for 
      the Pascal FTP server had correct numbers.  The C-FTP server used 
      the time function of the C runtime, which returned the number of  
      seconds since Jan 1, 1980, when it was only the seconds from the  
      midnight that should have been returned.                          
19.   APAR PQ38319 for DFSORT R14 does not impact MXG sorting under SAS,
      but if your site uses DFSORT to sort SMF (or any VBS) records, and
      also uses E15/E35 Sort Exits, this APAR corrects DFSORTS error    
18.   APAR OW45192. RMF 72 records have very large values in CPU time,  
      elapsed time, and in CPUUNITS fields ('7FFFFFFF'x > 2*10**9 ), but
      only in records from Performance Groups or Service Classes in     
      which enclaves are running.  PTFs for APAR OW40548 (which raised  
      the previous limit of 5,000 enclaves per system to over 32,000)   
      introduced the error, but only for OS/390 R2.6, R2.7, and R2.8    
      (the R2.9 PTF for APAR OW40548 was not in error).                 
      The bad data was first seen in records from the DDF (Distributed  
      DB2), because DDF is the most common user of enclaves, but other  
      enclave users include CPU Parallelism in DB2, IBM's Web Server (in
      Scalable mode), and the MQ Series WorkFlow products.              
      These bad values cause Negative Uncaptured CPU time error messages
      on the SAS log during creation of MXG dataset RMFINTRV, and trash 
      the TYPE72/TYPE72GO and PDB.RMFINTRV datasets.                    
      Until IBM has a PTF for APAR OW45192, you must delete these bad   
      observations, in the MXG exit member EXTY72 or EXTY72GO.  Look at 
      your TYPE72/TYPE72GO data to see if CPUUNITS can be used to detect
      and if so, then delete the bad observations using:                
        IF CPUUNITS GE 2E09 THEN DELETE;                                
      in the exit member.  Or you could use the PERFGRP number or the   
      SRVCLASS name to delete the DDF (or any other) observations with  
      the bad data values.   26Jun2000.                                 
      Sep 21, 2000:  PTFs exist for APAR OW45192 and did correct that   
      error at one site.                                                
17.   APAR OW41270, OS/390 R2.8 caused creeping ECSA problem that was   
      resolved by OW43069.                                              
16.   APAR OW39924, OS/390 R2.8 and R2.9, macro STCKCONV bad. 17May2000.
      There is a blank line in the IBM STCKCONV macro, and it causes the
      Assembly of ASMTAPES to fail under OS/390 R2.8 and R2.9.  The APAR
      identifies the blank line to be removed (or the High Level ASM    
      be used, as the blank line does not trip it up!).                 
15.   APAR OW40458 corrects large values in TYPE72GO Period 2. 27Apr00. 
      If you are in Goal Mode and specify multiple periods for the      
      service class that CICS or IMS regions are running in, and you    
      are also classifying the transactions, negative/large/invalid     
      values for many variables in period 2 and later periods are       
      created, because when an address space stops being a server,      
      it is moved back to period 1 without updating the workload        
      reporting numbers for the period it had been running in.  While   
      the APAR fixes the IBM error, the site with the problems real     
      culprit was the accidental misclassification of a test CICS       
      region into a service class with multiple periods.                
        This caused large negative PCTOVHD and CAPTURAT over 100% in the
        PDB.RMFINTRV; CPUTCBTM was greater than CPUACTTM also.          
14.   APAR OW43817 corrects SMF type 85 CICS TRAN ID blank.  26Apr2000. 
      OAM SMF 85 R85PTRXN was not filled in for customers using the     
      Default Security Checking Bypass, because the Authorization Check,
      and the Gathering of Userid, Trans ID were both being bypassed.   
13.   APAR OW43581 corrects SMF type 17 fields. Apr 26, 2000            
      Installing APAR OW41664 corrupts SMF type 17 fields JOB, READTIME,
      and LOCLINFO, and the DSNAME has 'SYS' in Columns 1-3.  New APAR  
      OW43581 corrects the problem created when the strengthening of    
      DADSM's name checking by OW41664 destroyed the register used to   
      build the type 17 SMF record (Data Set SCRATCH).                  
12.   APAR OW43846 (FIN=Fixed In Next). Apr 17, 2000.  Incorrect values 
      in type 14/15 SMF records for striped extended format sequential  
      data sets.  The first stripes number of tracks is not included in 
      SMF15NTU if the OPEN was for output with partial release, and both
      SMF14NTU and SMF15NTU are too large by one track for each stripe. 
11.   Multi-volume tape data library last vol not read. April 16, 2000. 
      IBM APAR OW31263 (1997) for message IEC999I IFG0551H,jjj,prog.... 
      The 35th volume of a 35 volume CICSTRAN-on-tape was not read after
      being created; the job stopped after the 34th volume.  The SAS log
      reported only that an error had occurred "OUTSIDE THE SAS SYSTEM".
10.   IBM/Tivoli NetView/FTP Apr 6, 2000.  FTP apparently creates SMF   
      records for FTP with ID=0 if you do NOT specify SMFREC=nnn INIT   
      parameter for FTP.  MXG detects a "Bad IPL" record and deletes;   
      a hex dump of the type 0 record shows NFTP as the product name.   
 9.   RMF TYPE74 PAV/SHARK Apr 3, 2000.  APAR OW40885 reports incorrect 
      (high) values for PAV devices director port busy (DPB), control   
      unit busy (CUB) and device busy (DB).                             
 8.   CA Dispatch. April 1, 2000.  CA Dispatch Release 5.1 can produce  
      type 6 SMF records with non Y2K Ready date value in SM6JLDAT (the 
      date part of READTIME); this only seems to occur for Dispatch     
      data sent directly to 'distribution' (as opposed to printing from 
      'online viewing' or 'archiving').  CA has a temporary ptf         
      available under CA Problem Number 1195.                           
 7.   TCP/IP SMF records.  Mar 15, 2000.  APAR PQ36346 reports that the 
      wrong STC name (SMFAPINM) is in the SMF INIT API call records.    
      The INIT record has the started task name of the TCP/IP stack, the
      TERM record is correct and has the started task name of the       
 6.   FTP SMF records.  Mar 15, 2000. APAR PQ36103 reports that an SMF  
      record is not always written when an FTP client user aborts the   
      connection to OS/390 FTP server.  IBM reports "FIN", Fixed in Next
      Release, but notes "problem is easily avoided if the client FTP   
      user avoids aborting the transfer"!                               
 5.   WEBSERVER SMF 103.  Mar 15, 2000.  APAR PQ32435 reports that the  
      incorrect IP stack address is stored in a VIPA environment.       
      The OS/390 Webserver (IHS) writes SMF records TYPE103 subtypes 1  
      and 2 to report configuration and performance data.  The customer 
      has an environment with multiple Webservers using VIPA and Network
      Dispatching via D/T2216 routers.  They found that the IP address  
      of the Webserver, reported in the SMF record, derived from the    
      HTTP Server MIB, variable EntityAddress (and also EntityPort) were
      incorrect. The record always contains the default IP stack's      
      primary IP address.  They also noted that the records do not      
      contain the jobname of the webserver, which would be useful for   
      subsequent analysis.  This APAR is recently opened and no PTF yet.
 4.  OMVS/USS TYPE 30. Mar 15, 2000.  Information APAR II12312:         
     On OS/390 V1R3 and prior, OMVS used APPC/ASCH initiators for       
     address space creation.  From RACF definitions, an OMVS users      
     workaccount and workattribute fields were added to the EXEC card   
     and this information was recorded in SMF Type30 Subtype 2 and 3    
     records, so OMVS Accounting fields are in the SACCTn variables in  
     MXG's TYPE30_V and PDB.SMFINTRV datasets.  With OS/390 V2R4+, OMVS 
     now uses WLM initiators for address space creation.  From RACF     
     definitions, an OMVS users workaccount and workattribute fields are
     added to the JOB card and this information is recorded in SMF      
     Type30 Subtype 1 and 5 records, so the OMVS/USS accounting fields  
     will be in the ACCOUNTn variables in MXG TYPE30_1 and TYPE30_5     
     datasets, and in the PDB.JOBS/PDB.STEPS observations for OMVS jobs.
 3.  DCOLLECT. Mar 8, 2000. APAR OW43104 reports incorrect Device       
     Type on the type 'V' records for RVA and SHARK DASD.  RVA shows    
     9393 instead of 3390 and the SHARK showed as /UNKN/.               
 2.  TYPE92. Mar 3, 2000. According to APAR OW41113, SMF 92 records cut 
     for open/close under UNIX System Services capture the SAF (RACF)   
     userid of the process (server) rather than the actual caller of the
     service (task).  The "process" level OMVS Real UserId and OMVS Real
     GroupId were being recorded instead of the "task" level OMVS Real  
     UserId and GroupId.  As of March 3, 2000, that APAR was only a     
     request; there is no PTF yet that actually records the "task" level
     IDs in SMF type 92 records.                                        
 1.  TPX 4.1. Feb 9, 2000.  TPX 4.1 originally wrote GMT time, and then 
     added GMT offset, so MXG converted times to Local time, but now TPX
     has added a new PARM, "Reserve Option #45=Y", that changes the time
     values in the record to Local time, but sets no flag in the record 
     that the timestamps are now on the local clock, so MXG re-adjusted 
     the time away from local by the GMT offset.  (In my opinion, they  
     should have just zeroed the GMT offset field when the times are    
     local, and MXG would have calculated correctly!).  But instead, you
     must set that parm to N so that the record values are in GMT and   
     the non-zero GMT offset will be used by MXG to correct TPX records.
IV.  DB2 Technical Notes.                                               
 1.  DB2STATS. Mar 29, 2000.  APAR PQ21969 corrects QTSLWDD values; the 
     incorrect (large) value in the type 100 subtype 1 SMF record caused
     negative values for IN USE DATASETS in DB2PM and ANALDB2R reports. 
     DSNB1CST did not decrement the count in QTSLWDD correctly when     
     closing a linear pageset with multiple pieces during deferred close
     request processing, i.e., a problem in serialization if several DB2
     jobs 'declaim' at nearly the same time.  APARS PQ23458 affects the 
     Program name and PQ24406 affects the count of datasets closed due  
     to DSMAX or DDLIMIT being exceeded in error.                       
V.   IMS Technical Notes.                                               
     Sep 12, 2000.  IMS PTF UQ35642 for APAR PQ30803 has no impact.     
     That change to the IMS log record fixes an IBM error, where a bit  
     in field DLRNOSTP is now set when it was not, but MXG does not use 
     nor care about that bit flag.                                      
VI.  SAS Technical Notes.                                               
12. Starting with SAS 8.1, the Sequential Engine names of SASV5SEQ,     
    SASV6SEQ, and SASV7SEQ cannot be used.  However, the engine names   
    of V5SEQ, V6SEQ, V7SEQ, V8SEQ, & VnSEQ are still supported and will 
    be supported in future versions.  Fortunately, I never knew of the  
    SASVnSEQ form, so all MXG notes and references have been for VnSEQ! 
    This note was precipitated because the manual What's New in SAS 8.1,
    page 21, Chapter 7 states that "SEQENGINE= now has a default of TAPE
    and no longer supports values in the form SASVnSEQ".  SAS plans to  
    change the note to document that the VnSEQ form is still valid.     
    Additionally, the default of TAPE will be the VnSEQ engine for the  
    Vn release of SAS, i.e., TAPE=V8SEQ when under SAS V8.  28Sep2000.  
11. If you use SAS V8's default Engine to write to a SAS Data Library   
    that was previously written to by a SAS V6 Engine, and MXG has set  
    the new SAS V8 option SASCHRLN=32000 (done for you by VMXGINIT when 
    under V8, but only if you also set option COMPRESS=YES, for some    
    long text variables in type 102 records), you get ERROR: CHARACTER  
    recognized the output data library was built with V6, so it changed 
    the default Engine from V8 to V6, but the V6 engine doesn't support 
    long-length variables! The only permanent fix is to not do that:    
    change your data libraries to V8-built.  You must allocate new data 
    libraries ("PDBs"), and use PROC COPY to copy from V6 to V8, then   
    delete the old data library, and rename the old back to new.  You   
    cannot use PROC DELETE nor PROC DATASETS to delete all members and  
    re-use the existing data library, because the SAS directory remains 
    in V6-format, and so that data library will always be built with the
    V6-engine.  However, if you still must create SAS V6 data libraries 
    under MXG under SAS V8, you can reset the value of SASCHRLN by using
       %LET SASCHRLN=100;  as your first //SYSIN.           Sep 6, 2000.
10. Comparing values between MXG PDBs built with V6 versus V8 can show  
    some differences, but only in the 7th-8th significant digit.  The   
    SAS V8 INHERIT parameter of PROC SUMMARY/PROC MEANS apparently now  
    uses the length of the input variable for the internal length use in
    calculations, whereas without it SAS uses an internal length of 8 in
    calculations.  With an input dataset that had length 4 variables,   
    the output values with INHERIT are slightly less than the same PROC 
    MEANS without INHERIT specified.  INHERIT was designed for MXG so   
    that an entire step in VMXGSUM can be avoided.                      
 9. SAS V8 did not RELEASE space from SAS Data Libraries when it was    
    requested.  SAS Technical Note SN-002674 has the fix.  28Jun00.     
 8. PROC APPEND with new versions of MXG/ITSV:  26Jun2000.              
    If you use PROC APPEND to create week-to-date                       
    or month-to-date SAS datasets, new variables added to               
    MXG datasets will not be added to the APPENDed "Base"               
    dataset, and lengths of variables that were changed                 
    in MXG will not be changed in your "Base" dataset.                  
       MXG does not actually use PROC APPEND in its code,               
       because it breaks the sort order of sorted datasets,             
       but now also because it doesn't propagate dataset changes.       
    But if you have inherited a job that uses PROC APPEND to            
    concatenate NEW observations to a BASE dataset:                     
    and if the contents of NEW.DATASET are different, you get           
    a condition code 4 and these warning messages on the SAS log:       
     WARNING: Variable x was not found on BASE file and/or              
     WARNING: Variable y has different lengths on Base and Data files   
             (BASE 4 DATA 8).                                           
    and the output BASE.DATASET will still have only the                
    original variables and their original attributes.                   
    You must replace the "BASE.DATASET" with a dataset with the same    
    a. Somewhere in your jobstream, before the first day of the         
       whatever-to-date you are building, or after the last day         
       of that period, that BASE.DATASET is being re-set to zero        
       observations, instead of being deleted.                          
          If it were being deleted, then the first execution of         
          the PROC APPEND with a null BASE dataset will contain         
          all of the variables in the NEW dataset.                      
       Find where that setting of BASE.DATASET to zero observations     
       is located, and replace it with a PROC DELETE DATA=BASE.DATASET  
       before the first-day-of-period run.                              
          However, BASE.DATASET will contain only those variables in the
          NEW dataset; variables dropped by the new version will not    
          exist in the replacement BASE.DATASET.  If your reports used  
          those now-non-existent variables, they could fail, but because
          of this impact, MXG almost never drops variables!             
    b. Or, with complete safety, you can re-create your BASE.DATASET, as
       it now exists, to contain the union of all variables in both the 
       BASE.DATASET and NEW.DATASET, with all of the observations in the
       BASE.DATASET, adding nothing from NEW, with this program. Execute
       the program for each DATASET in the BASE library that is being   
       PROC APPENDED (after first backing up the BASE library!):        
          /* Create WORK.NEWBASE with zero obs but with all variables*/ 
          OPTIONS OBS=0;                                                
          DATA WORK.NEWBASE;                                            
          SET  NEW.DATASET BASE.DATASET;                                
          /* Reset option obs to max to now actually read observations*/
          OPTIONS OBS=MAX;                                              
          /* Data step will create a new BASE.DATASET; by listing the */
          /* WORK.NEWBASE first, its attributes will be used to set   */
          /* the attributes of variables found in NEWBASE.            */
          DATA BASE.DATASET;                                            
          SET WORK.NEWBASE BASE.DATASET;                                
 7. SAS Version 8/8.1 corrupted multi-volume SAS Data Library. Jun 23.  
    SAS Version 8 & 8.1 will create a corrupted multi-volume SAS Data   
    Library on DASD (but not a problem with multi-volume Tape), if you: 
      - Use a STORCLAS with "Guaranteed Space" attribute enabled when   
        the library dataset was allocated, and                          
      - Have a non-zero Secondary Space Allocation value in the SPACE=  
        parameter when the library dataset was allocated, and           
      - The second volume was actually written to.                      
    There is NO error during creation, but when the data library is read
    you may get USER 0315 ABEND, with this error message on the SAS log:
       Physical I/O error on SAS data library DATA.SET.NAME on          
       volume volser,jobname,stepname,dev-addr,ddname,86-OP             
    or you may just get RC=8 with these messages on the SAS log:        
       Expecting page NNN, got page -1 instead.                         
       Page validation error while reading LIBREF.DATASET.DATA          
       File LIBREF.DATASET.DATA is damaged.                             
       I/O processing did not complete.                                 
    Removing the Secondary Space Value will eliminate this error, and,  
    if you still must use Guaranteed Space (for example, so you can use 
    VOLSER= in your JCL), that is the solution.  However, if the only   
    reason you used a STORCLAS with GS was to satisfy SAS V6, then the  
    permanent solution is to remove the Guaranteed Space attribute from 
    the STORCLASS, or change your JCL to a different STORCLAS that does 
    not have the GS attribute specified.                                
    Under SAS V6, GS was REQUIRED for multi-volume DASD, but GS does not
    use secondary extents, although they were tolerated in your JCL by  
    V6.  Now, under SAS V8, the existence of a secondary value and GS   
    causes the corruption (but only when the second volume is actually  
    opened), but GS is no longer required by V8, and in general, GS     
    should not be used with V8:  with GS and five volumes of 3000 PRI   
    cylinders, you get 15,000 cylinders whether you need it all or not, 
    whereas with SAS V8 and without GS, you allocate only the primary on
    the first volume, until more is needed by today's job!              
    Tests with SAS V8 multi-vol DASD strongly suggest that you SHOULD   
    have a secondary allocation value, once you have removed the GS     
    attribute, as it makes it easier for allocation to find more space  
    when available on each volume.                                      
    How do you know if you have Guaranteed Space?  Look at the STORCLAS 
    of the Data Library (either in the JCL or on the SYSMSG allocation) 
    and go to your Storage Administrator, who can use ISMF to see if the
    GS attribute is specified for that Storage Class.                   
    SAS Institute is currently investigating a fix (at best, probably,  
    to force a failure rather than creating the corrupt dataset), and   
    SAS Technical Support Note 002881 will be posted later this week to 
    track the problem.                                                  
    In summary:  For Multi-Volume Data Libraries under SAS V8:          
      a - If you must use Guaranteed Space, do not have a Secondary.    
      b - Without Guaranteed Space, do have a Secondary allocation.     
 6. SAS V8  PROC COPY IN=WORK OUT=PDB; if the PDB DDNAME points to a V6 
    SAS data library, when copying WORK.REGSTRY (MEMTYPE=ITEMSTOR), with
    NOT BEEN SAVED....  While SAS investigates, adding MEMTYPE=DATA to  
    the PROC COPY is what you really wanted in the first place, and will
    avoid the incompatibility.  Jun 12, 2000.                           
 5. The SAS V8 TAPE Engine cannot be safely used.  May 12, 2000.        
    The SAS V8 TAPE Engine (V7SEQ=V8SEQ) cannot be used with complete   
    safety to create or even to read tape-format datasets.  LABELs of   
    variables in datasets that are created (on tape or disk!) from      
    V8SEQ-format datasets can be trashed (truncated, overlaid, extra    
    blanks) if a SET statement with a (KEEP=) dataset option is used.   
    Bad LABELs can destroy reports, and there is no warning, error      
    message, nor a condition code set.  V8SEQ can also error if you     
    create tape-format on DASD, but at least then, you do get an error! 
    These errors were found too late to be fixed in SAS Version 8.1!    
    July 26, 2000 update: See SAS Note SN-002651.  SAS ZAP Z8002651 now 
    exists for SAS V8.0 and V8.1, and the error is corrected in V8.2.   
    Until then, the circumvention is to tell SAS Version 8 to use the   
    V6SEQ engine instead of the V8SEQ engine (both to create and to read
    tapes) until SAS Institute has a corrected version.                 
    The Trashed LABELs error:                                           
    SAS V8 will create V8SEQ-format datasets on tape, and the LABELs in 
    the tape dataset are fine, but if you then read that tape dataset to
    create a new dataset, the LABELs in that new dataset are trashed if 
    the SET statement also uses the (KEEP=) dataset option:             
      DATA SUBSET; SET CICSTRAN.CICSTRAN (KEEP= A B .. Z);              
    While this case exposes the error, there may be other exposures.    
    MXG uses (KEEP=) to reduce the number of bytes read into memory.  It
    is used in VMXGSUM (invoked by all TRNDxxx members and most ASUMxxxx
    members), and bad labels were found first in TRND70PR.  The (KEEP=) 
    option is also used by ASUMUOW, which has only data steps, was the  
    second instance of bad labels, and helped isolate the problem.      
    The circumvention for Trashed Labels error in SAS V8.0 and V8.1:    
    You should add  SEQENGINE=V6SEQ  in your CONFIG member to make V6SEQ
    your default tape (sequential) engine.  However, you must also scan 
    your tailoring and report source libraries for any instances of     
    "LIBNAME ddname TAPE;" and must change "TAPE" to "V6SEQ", because   
    TAPE in a LIBNAME statement overrides the SEQENGINE option, and TAPE
    defaults to V8SEQ under SAS V8, a default that cannot be changed.   
    SAS V8 should be able to detect that a tape dataset was built with  
    the V6SEQ engine, but it can't.  If you try to read a V6SEQ dataset 
    with V8SEQ engine, the step fails with error message:               
    That's why you should change you CONFIG option to SEQENGINE=V6SEQ.  
    However, you could instead add a LIBNAME statement for each tape DD,
    (in your SYSIN stream) with "LIBNAME ddname V6SEQ;" and not have to 
    update the CONFIG member, but changing the CONFIG member is probably
    the best circumvention.                                             
    Second V8SEQ error, tape-format-on-DASD.                            
    V8SEQ also fails if you try to write a tape-format dataset on DASD, 
    using just the old DDname convention of //TAPExxxx to invoke the    
    tape engine, because that option invokes only the V5SEQ engine, and 
    SAS V8 is no longer backwards compatible, as it can only read V5SEQ 
    libraries; writing to V5SEQ from V8 causes error messages:          
    This is documented in the SAS Companion for MVS, V6, Second Edition,
    Appendix I, page 437, which is also the reference in the V8         
    Companion for MVS.                                                  
    The circumvention is to use   LIBNAME   ddname  V6SEQ ; for any     
    MXG's WEEKBLDT and MONTHBLD members use //TAPETEMP for temporary    
    files to create weekly and monthly PDBs on tape without rewinds, but
    both had "LIBNAME TAPETEMP TAPE;" statements, so that "TAPE" was    
    changed to "V6SEQ" in those two members.                            
    Even if you specify SEQENGINE=V6SEQ in CONFIG, that only applies if 
    the actual device is tape;  to now create a tape format dataset on  
    DASD under SAS V8, you must now also specify:                       
      LIBNAME TAPExxxx V6SEQ;  or  LIBNAME ddname V6SEQ;                
    The text of Change 18.104 has details on the actual MXG changes.    
 4. SAS V8 OPTION FILEEXT=IGNORE default value must be used with MXG.   
    The new options can be used to control the syntax than can be used  
    in SAS programs to reference PDS member names; the FILEEXT=VERIFY   
    should not be used, since MXG syntax works just fine when OS/390    
    "ignores" this option by default.  FILEEXT=VERIFY causes errors:    
 3. SAS V6.09E TS455 or later, VM 1319 and USER ABEND 1319, "No MKLEs"  
    can be corrected by SAS zap number Z609E449, although the problem   
    can also be circumvented simply by a) making sure your MEMSIZE      
    option in MXG's CONFIG member is 64M, and b) making sure your REGION
    parameter is also 64M so that SAS can get its requested MEMSIZE.    
 2. SAS V8 ABEND S01D when HSWORK is used.  Apr 25, 2000.               
    SAS zap number Z8001639 corrects said ABEND with SAS Version 8.     
 1. SAS V8 does not support V5 data libraries. Apr 17, 2000.            
    SAS V8 does not support V5 format data libraries (recognizable by   
    their old RECFM=U,BLKSIZE=32760 DCB), failing when written-to with a
    WRITE ACCESS DENIED error (which otherwise is the result of using   
    DISP=SHR for an output SAS data library).  In this case, it was the 
    MXG //SPIN library in the BUILDPDB logic that was still V5, so to   
    preserve the data and create a V8-format data library, the site     
    first used V6 to PROC COPY from V5 to a V6 library (DISP=NEW), and  
    then used V8 to PROC COPY from the V6 library to the (new and not   
    backwards compatible) V7/V8 SAS data library (DISP=NEW).            
VII. CICS Technical Notes.                                              
 1. APAR PQ41392 corrects wrong TERMID in SMF type 110 records that was 
    written for non-Terminal transactions.  The TERMID name was FHCI.   
VIII. Windows NT Technical Notes.                                       
IX.   Incompatibilities and Installation of MXG 18.04.                  
 1. Incompatibilities introduced in MXG 18.04 (since MXG 17.17):        
  a- No changes in MXG architecture were made between 17.17 and 18.04   
     that introduced incompatibilities.                                 
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL (which also lists common Error/Warning messages a 
    new user might encounter), and sample JCL is in member JCLINSTL.    
X.    Online Documentation of MXG Software.                             
    MXG Documentation is now described in member DOCUMENT.              
XI.   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 17.17 now in MXG 18.04:
  Member   Change    Description                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage                                          
Inverse chronological list of all Changes:                              
Changes 18.264 thru 18.001 are contained in member CHANGES.