****************NEWSLETTER ELEVEN***************************************
             MXG NEWSLETTER NUMBER ELEVEN DECBMBER 15, 1987             
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
 This newletter accompanies the production shipment of MXG Version 5.5. 
The  MXG  Newsletter is available only to supported customers of Merrill
Consultants.  An "MXG Newsletter" binder, similar to the binder for  the
MXG  Supplement,  will  be  sent to your site early in 1988 to hold your
site's newsletters.                                                     
  We thought that 100 pages of MXG Newsletters would fit with the 500   
  planned pages of the Supplement in its binder. The Supplement's 630   
  actual pages absorbed our planned excess capacity!                    
I.  MXG SOFTWARE VERSION 5.5                                     page  2
II. 1988 ANNOUNCEMENTS                                           page  3
III.TECHNICAL NOTES                                                     
    1. HOT PTFs: MVS                                             page  4
    2. HOT PTFs: VM                                                     
    3. Technical Notes, MVS                                      page  5
       a. Counting allocated tape drives.                               
       b. I/O Counts in TYPE70 and TYPE78IO.                            
       c. SMF TYPE64 (VSAM I/O) counts.                                 
       d. CPU and I/O measurements when writing tapes.                  
       e. More EXCPs in 30's than in 4's and 34's.                      
       f. More CPUTCBTM in SMF than in RMF for a step.                  
       g. MVS 2.1.7 page data set allocation size.                      
       h. Use STEP data for job ABEND analysis.                         
    4. Technical Notes, VM                                       page  8
    5. Technical Notes, SAS                                      page  9
       a. Eliminating tape mounts for SAS tape data libraries.          
       b. SAS ZAPs which you should install.                            
I. MXG VERSION 5                                                        
   This  newsletter  accompanies  the  shipment  of MXG Version 5.5, the
   Production MXG Version 5, which contains the  following enhancements:
  1. MVS 2.2 support.                                                   
     - New type 36 ICF Export/Import SMF record.                        
     - New type 41 Data-In-Virtual SMF record.                          
     - Changes in existing SMF/RMF records.                             
  2. VM/SP Release 5 support.                                           
  3. SAR Accounting record support.                                     
  4. SAR Type 6 record support.                                         
  5. DASD storage measurement system (dynamically read all VTOCs).      
  6. IDMS 10.1 Performance Monitor record (new data sets) support.      
  7. ACF2 user SMF record support.                                      
  8. DB2PM validation and reports.                                      
  9. IMS log processing re-designed and supported for IMS 2.1.          
 10. STOPX37 user SMF record support.                                   
 11. RMF Cache Reporter validation and enhancement.                     
 12. CICS 1.7 cleanups, enhancements, and more decoding.                
 13. DFSORT Release 9 support.                                          
 14. VM/Monitor summarization.                                          
 15. Vector Processor measurement.                                      
 16. TYPE64X data set for VSAM extents.                                 
 17. SYSLOG JES3 processing and JES2 SYSLOG example.                    
 18. EDP Auditor Reports from RACF type 80 data.                        
 19. Eight CPU engine (3090-800?) C.E.C. Support.                       
 20. Online Business Systems WYLBUR Accounting SMF record support.      
 21. TSO/MON Version 5.1 support.                                       
 22. Extended Storage measurement enhanced.                             
 23. 3480 tape drive error counting in TYPE21 added.                    
 24. Separate counts of 3420 and 3480 tape drives in type 30 and PDB.   
 25. VSAM VVR Type 60 record decoded.                                   
 26. NETVIEW modifications to NLDM record supported.                    
 27. RMDS support.                                                      
 28. SYNCSORT user SMF record support.                                  
 29. CINCOM SUPRA log record support.                                   
 30. VM Account LOGOFF record support.                                  
 31. ROSCOE 5.5 SMF Account record support.                             
 32. IMF 2.3 support for DDNAME level I/O counting.                     
 33. NETSPY support.                                                    
 34. OMEGAMON EPILOG 1000 support.                                      
 35. Externalized BUILDPDB macro definitions in IMACPDB.                
 36. HOGAN FPS transaction function code data support.                  
 37. CICS 1.7 EXCLUDE option "support".                                 
 38. IDMS Performance monitor from IDMS journal file supported.         
 39. Landmark's SPECIAL 78 zap (adds CICS 1.7 MRO fields) support.      
 40. Naming conventions established for MXG's use of "New style" macros.
 41. Elimination of excess tape mounts for monthly and weekly jobs.     
   Four MXG Version 5 pre-releases, in  July,  August,  October  and    
   November,  were tested by more than 150 sites; their feedback was    
   invaluable in the quality assurance of the production release.       
 1. The aggregation interval of RMFINTRV data set was relocated in the  
    new member IMACRMFI, instead of being defined inline.               
 2. VM/Monitor users must read Change 5.133. The meaning of VMONDEV data
    set variable CNTVIOCT was altered. A new macro, _INTRVL, defined  in
    IMACVMON, sets the expected record interval of your VM/Monitor.  The
    MXG default of one minute is now used to detect user logon events.  
 3. BUILDPDB/3 users who wish to tailor the PDB data sets will no longer
    have to make internal changes; all PDB macros which control the PDB 
    data sets were externalized into member IMACPDB.                    
II. 1988 EXPECTATIONS                                                   
 IBM  announced  plans for operating system changes next year which will
 likely require changes to MXG software.  IBM dates given below are  the
 availabilty  date  in  the IBM announcement.  We always hope to provide
 MXG support by availability date, if we can get both documentation  and
 test  data in time.  We will likely repeat the strategy of the past two
 years:  a spring newsletter to announce when  the  pre-release  of  the
 next  MXG version is available, and a production MXG version shipped to
 all customers in the fall.                                             
 a. March, 1988. Expected availability of VM/XA SP1, with a complete    
    new set of monitor records, new format, and zero compatibility with 
    current VM/SP VM/Monitor data.  IBM says there will be no VM MAP for
    this new VM/XA monitor, but MXG will be there.                      
 b. May, 1988. PTF to MVS 2.2 which adds VIO activity fields to TYPE71  
    data (this PTF permits VIO to be directed to Extended Storatge).    
 c. Unknown. PTF to add JOB and READTIME which IBM  left out of the new 
    MVS 2.2 Type 41 (Data In Virtual) SMF record.                       
 d. December, 1988. Expected availability of VM/SP Release 6, with many 
    new data elements added to existing VM/SP VM/Monitor. This release  
    includes the new VM Shared File System, which creates new data.     
 e. Unknown. We expect to enhance MXG to support the PDL data written by
    the FACOM OSIV/F4 MSP operating system.                             
 f. Unknown. Other rumored impacting events may be CICS 2.1, a new DB2  
    release, and DOS/VSE Power record changes.                          
III. TECHNICAL NOTES                                                    
 Note:   The PTF or APAR numbers were provided by some system programmer
 who has actually installed this fix, but sometimes the number  will  no
 longer  be valid;  IBM supersedes and replaces PTFs, and one APAR often
 has several PTFs for the same logical problem.   Use  this  information
 only to search INFO/MVS for more information and exact status.         
1. HOT PTFs: MVS:                                                       
 MVS  2.1.7  PTFs  OZ44728  and OZ92196 appear to finally solve the long
 outstanding constraint that the SMF interval (for type 30s and 32s) had
 to  be greater than JWT.  These PTFs apparently are already in MVS 2.2,
 and the documentation still recommends that the  Interval  duration  be
 greater than JWT, but experimental system programers have reported that
 that recommendation is no longer a requirement.  Don't take my word  on
 this, but I think it's probably true.                                  
 A  new  PTF  (only for MVS 2.2 and later) finally allows you to specify
 BLKSIZE of the SMF data.  Requested through SHARE in the CME project in
 1973,  it has finally been acknowledged in APAR OY07209 and implemented
 in PTF UY12002.                                                        
 MVS 2.1.3 and 2.1.7 do not write type 7 records when SMF  recording  is
 lost!  Fix is PTF UY12608.                                             
 For 3090-400s, 300s, and 600s with 128MB real memory, there are lots of
 performance problems if you do not install  OY01085.   Your  CE  should
 have caught this one for you.  MXG NL TEN misprinted this PTF number.  
2.HOT PTFs: VM:                                                         
 Concatenated MACLIBs on different mini-disks will fail;  only the first
 MACLIB in the concatenation will  be  searched  until  PTF  VM24283  is
 installed.   As long as the MACLIBs are on the same mini-disk, there is
 no problem with concatenation (as suggested for the  MXG  SOURCLIB  and
 USERID SOURCLIB libraries).                                            
3.TECHNICAL NOTES, MVS:                                                 
 a. Counting allocated tape drives.                                     
 The following is a revision of a note originally in MXG Newsletter TEN:
 Counting of tape drives  (TYPE30_4  or  PDB.STEPS  variables  TAPEDRVS,
 TAPE3420  and/or  TAPE3480)  is  affected  if  the job step dynamically
 allocates tape drives.  For example, DB2MSTR  dynamically  allocates  a
 drive  every  time  the recovery data is backed up.  If each allocation
 happens to get a different tape drive,  the  step  record  for  DB2MSTR
 would  contain a different DEVNR (old UCB address) for each tape, which
 MXG would count as a large number of tape  drives.   Only  a  few  jobs
 actually  use  dynamic allocation (thank goodness), but they tend to be
 long running DBMS, which wreak havoc  on  the  number  of  tape  drives
 perceived  by ANALTAPE to be in use.  You must use the type 40 (Dynamic
 Allocation) record to find those jobs that  dynamically  allocate  tape
 drives, and exclude their step records before processing STEPS with the
 MXG ANALTAPE program.  Otherwise, it will appear the job step  had  all
 those tapes for the entire time the step executed.                     
    You can use the MXG Exit Facility to add type 40 processing, and  in
    the exit (EXTY40) and use:                                          
        IF DEVICE='3420' or DEVICE='3480' THEN OUTPUT TYPE40;           
    to only create observations for tape devices.                       
       VMAC40 reads in a 40 and calls VMACEXC1, which decodes  DEVCLASS,
       DEVTYPE,  and  DEVNR  for  each UCB segment.  VMACEXC1 then calls
       VMACUCB to decode DEVCLASS and DEVTYPE (hex) into DEVICE  (char);
       the value '3420' or '3480' is set for tape devices.              
    Since  SMF  offers  no option to create type 40's just for tape, you
    still have to create all type 40 records, but this use of the EXTY40
    exit allows you to keep only tape observations in TYPE40.           
 b. I/O Counts in TYPE70 and TYPE78IO.                                  
 The MXG Supplement noted that the I/O Interrupt Counts in  TYPE70  were
 observed  to be greater than the 3090 IOP I/O Activity in TYPE78IO.  It
 was pointed out that IBM notes (in LY17-5500) that  both  TYPE78IO  and
 TYPE70   count   SSCH   (i.e.   SIOs)  and  RESUMES,  but  that  TYPE70
 additionally  counts  PCIs,  Device  End  following  Channel  End,  and
 Unsolicited Interrupts.  The difference has been seen as 12-14% more in
 TYPE70.  Is this a useful indicator of anything?                       
 c. SMF TYPE64 (VSAM I/O) counts.                                       
 VSAM counts (EXCPs, SPLITS, etc.) in type 64 records are wrong  if  the
 VSAM  file  is concurrently opened.  These counts are the "change since
 open".  Four jobs which concurrently opened the same VSAM file and then
 read  9000  blocks, showed 9000, 18000, 27000, and 36000 EXCPs in their
 type 64 records.  The type 30 SMF record EXCP counts are correct.   The
 type  64  record  has  always  been this way;  only recently did a user
 investigate the data.  MXG will be  enhanced  to  de-accumulate  TYPE64
 data,  as ANALDSET does to de-accumulate TYPE1415 data.  You could find
 a CASPLIT count in a type 64, but the actual split may have been caused
 by a separate job.  You must sort all accesses to the same VSAM file by
 open time and examine the end time for potential  overlap  and  perform
 you own de-accumulation.                                               
 d. CPU and I/O measurements when writing tapes.                        
 In  creating  tape  copies of MXG Version 4.4, we used SYNCSORT's free,
 fast BETRGENR replacement for  IEBGENER.   Since  BETRGENR  copies  one
 cylinder  at a time, the 833 blocks of 6160 bytes each required only 11
 Start IO's, each SIO transferred 550KB of data in .44 seconds (you  can
 hear  the  voice  coil  humm  that long), but there was then a delay of
 about .6 seconds for the next SIO to commence (again, heard at the tape
 drive).   As  a result, while the channel capacity is 1.25 MB/sec, even
 with the transfer of 550KB per SIO, the effective channel capacity  was
 only  550KB/sec,  or  only  44% of IBMs stated capacity.  This was in a
 dedicated processor with no other work in progress.                    
 Furthermore, this was for a single copy of the MXG library.  The actual
 data transfer took 11 seconds for the 11 SIOs, but the physical loading
 of the tape, the swap in to reply (tapes are NL) and the rewind and the
 unload  time total just about one minute elapsed time.  Because we were
 waiting on the computer (THE definition of bad response)  we  allocated
 more  tape drives and found that with two tape apes (us), and four tape
 drives, we could create 100 tapes per hour.  Increasing the tape  drive
 count  to  six  drives  increased our production to 163 tapes per hour.
 Note at this rate of 163 5.5MB tapes written per hour, the tape channel
 was  still  only  utilized at 250KB per second, or only 20% of the peak
 transfer capacity.  The peak-to-sustainable rate here was 5 to 1.      
 This should point up the fallacy of using the peak  transfer  rate  (or
 any peak rate) as a measure of capacity, without determining the actual
 sustainable transfer rate.  IEEE Computer magazine recently had a  good
 discussion  with  regard  to  the ratio between peak mega-flop rate and
 achievable mega-flop rate on super computers, reporting typical  ratios
 also in the 5 to 20 range.                                             
 Each job executes 255 copy steps.  All steps except the first  recorded
 .40  or  .41 TCB seconds and .03 SRB seconds on a 3090-200.  With 5.5MB
 of data per step, this 13 MIPS (speed) processor is moving data at 13.4
 MB per second.  This is quite close to the one byte per one instruction
 rate first noted on page 842 of the MXG book!                          
 The first step of each job, however, required 1.06 TCB seconds and  .06
 SRB  seconds, or 1.12 total CPU seconds apparently because the CPU time
 for operator response to allocation recovery is captured in  the  step.
 Each job enters allocation recovery because its specific UCB address is
 offline at job initiation.  The IEF244I - "Unable to allocate"  message
 set  up  the  IEF238D  -  "Reply  Device  Name  or Cancel" WTOR and the
 R,99,181 reply apparently records .68 CPU seconds in the step record.  
 (The job which specifies VOLSER=MXG181 allocates UCB 181.  NL tapes are
 built so only one mount is needed, but require a reply to  confirm  the
 VOLSER.   With the UCB in VOLSER, the reply is fast and accurate.)     
 e. More EXCPs in 30's than in 4's and 34's.                            
 Several  sites have noticed approximately 10% more EXCPs are counted in
 the type 30 subtype 4 (TYPE30_4 data set) record than the EXCPs in  the
 step  type  4  (or type 34) for the same step.  The type 30 is correct,
 and the additional count in type 30 is due to the EXCP count to dynamic
 allocations, which are captured in 30s but never were captured in the 4
 or 34 records.  As described on page 628 of the MXG book, if  you  used
 4s  or  34s, you had to use the 40s also.  This is only one more reason
 why the type 30 SMF record has (since 1978) always and  all  ways  been
 better  than the type 4/34 records.  It's even worse for the 4s and 34s
 now.  In MVS 2.2, IBM turns on a new flag bit in 4s and 34s to tell you
 that  the  EXCP  data on this step is incomplete in the 4/34 record and
 you must use the type 30 for this step.  (This  happens  for  any  step
 with  more  than  1651  DD  cards).   STOP  USING 4's and 34's!  (MXG's
 BUILDPDB has always used only type 30s.)                               
 f. More CPUTCBTM in SMF than in RMF for a step.                        
 Step termination data shows that the SMF CPU TCB time in the  SMF  type
 30  can  be  slightly  greater than the RMF CPU TCB time in RMF service
 units in both the SMF type 30 and the RMF type 72 record for that step.
 The  step  recorded  8.13 CPUTCBTM seconds in TYPE30_4, but CPUUNITS in
 the step record (converted to CPU seconds) showed  only  8.08  seconds.
 This  step  executed  in  a  unique  performance  group, and the TYPE72
 CPUTCBTM was also 8.08 seconds for  the  interval  in  which  the  step
 executed.   This  is  not  statistically significant, but an IBM expert
 suggests  this  occurs  because  RMF  gets  it  service   unit   values
 (CPUUNITS,SRBUNITS) from the job data during step termination.  This is
 why the CPUUNITS in the type  72  data  matched.   However,  after  the
 service  units have been passed to RMF, the job is still in termination
 and the SMF clock is still accumulating true CPU  time  for  the  step.
 The  extra  CPU  time recorded in the SMF step record may be due to SMB
 processing (putting those termination messages on your SYSLOG  listing)
 or  it  could  be  installation code executing in SMF exits (perhaps to
 print the job costs on the "banner page" in SMF exit IEFU83 or IEFU84).
 At  this  site, there appears to be a fixed cost of .05 TCB seconds per
 step termination which is not recorded  in  the  TYPE72  CPUTCBTM,  but
 which  is  recorded  in  the  TYPE30  CPUTCBTM.   Even  at  1000  steps
 terminating each hour, this would be only  50  additional  TCB  seconds
 for each 3600 seconds, or only about one percent.                      
 g. MVS 2.1.7 page data set allocation size.                            
 The  Contiguous  Slot  Allocation  algorithm, the very efficient way of
 transferring up to 30 page frames contiguously with one  SIO  and  with
 minimal arm movement, was introduced for page data set I/O with MVS/370
 SP 1.3 in the late 70's.  Recently, several authors have concluded that
 the  algorithm will perform well only if the maximum number of slots in
 use is less than 25% of the slots allocated.  When the page data set is
 full,  the  algorithm  can  not  perform  well, because it can not find
 contiguous free slots.  This greatly increases the search  time,  which
 can  negate  the  positive  performance  of the algorithm.  For MVS/370
 VSCR, IBM had recommended minimizing the number of slots  allocated  to
 relieve  MVS/370  VSCR  because  a small amount of CSA is used for each
 slot allocated.  With only 50K-60K virtual storage saved,  real  paging
 is  likely  a  more  serious  problem,  and thus a larger page data set
 allocation may still be advised.  In early MVS/XA there also was a real
 problem  with  large  page  data sets causing excessive seek times, but
 that design error was fixed in MVS 2.1.2.  You can use the MAXUSED  and
 SLOTS variables in TYPE75 to see if you might have a problem, and could
 plot the percent used versus the service time  (AVGRSPMS  from  TYPE74)
 for each paging volume to confirm its real impact.  It is clear that an
 insufficient number of allocated slots will degrade the contiguous slot
 algorithm;   the  exact  percentage  at  which  you encounter increased
 service time may not be 25%, and you should construct your own data for
 h. Use STEP data for job ABEND analysis.                               
 Analysis  of  "Job" abends really must be done from the PDB.STEPS (from
 TYPE30_4  step  termination),  rather  than  from  the  PDB.JOBS  (from
 TYPE30_5  job termination).  The CONDCODE and ABEND variables (Page 578
 in the MXG Book, page 266 in the MXG Supplement) describe the value and
 the  type  of  termination.   ABEND  values  of SYSTEM or USER indicate
 abends and CONDCODE identifies the abend code, such as  SYSTEM  322  or
 USER  999.  An ABEND value of RETURN indicates that CONDCODE contains a
 return code value.  While both variables exist  in  both  PDB.JOBS  and
 PDB.STEPS,  the  ABEND  value  in  PDB.JOBS is from the job termination
 record, and can show an ABEND of SYSTEM for the job with a CONDCODE  of
 zero  if  the  step which ABENDed was not the last step!  The PDB.STEPS
 data is thus not only more accurate, but since many abends  result  are
 due  to  defective programs rather than defective jobs, using the STEPS
 data allows you not only to identify which JOB  abended,  but  also  to
 identify  the  name of the PROGRAM which abended.  You may even be able
 to  recognize  (by  your  program  naming  convention)  which  of  your
 development groups wrote the frequently-abending programs!).  PDB.STEPS
 data also identifies which step actually abended first when  there  are
 multiple abends (and when there are COND=EVEN and COND=ONLY steps).    
4. TECHNICAL NOTES, VM:                                                 
 There are two ways to hold SPOOL data in VM so that it exists after the
 spool data is read:                                                    
    SPOOL READER HOLD             holds the reader, while               
    CHANGE READER nnn HOLD        holds the file                        
 Hold only the reader, never hold the file, if you want the data to be  
 read. The CMS Diagnose 14 Subtype 1C command which is used to read the 
 monitor data in the spool, skips over held files.                      
5. TECHNICAL NOTES, SAS:                                                
a. Eliminating tape mounts for SAS tape data libraries.                 
 Many users have found that the weekly and monthly PDB jobs (described  
 in Chapter Thirty-Five with examples in MONTHBLD and WEEKBLD) can cause
 lots of tape mounts and rewinds.  Some sites have resorted to the      
 parallel allocation of as many tape drives as there are tape volumes to
 avoid mounts.  This problem is not unique to MXG, but results from the 
 protective instincts of SAS when tape data sets are involved.  As you  
 will see, we now have a sucessful circumvention which minimizes the    
 amount of temporary DASD needed by WEEKBLD and MONTHBLD, and completely
 eliminates the multiple rewinds and mounts for the output library.     
 The Present SAS Design:                                                
 SAS data libraries on tape volumes have no directory of what SAS data  
 sets are where on the tape.                                            
 When a SAS SET statement needs to read a SAS data set from tape data   
 library, SAS rewinds to the beginning of the tape, and searches for the
 desired data set name to be read.                                      
 When a SAS DATA step writes a SAS data set to a tape data library, the 
 tape is first rewound to the beginning of the OS tape dataset, and SAS 
 begins searching for the data set name to be written:                  
   i.e., if currently on vol 4 of a multi-volume tape data library, SAS 
   will rewind and dismount vol 4, mount vol 1, read and dismount it,   
   mount vol 2, read and dismount, etc, until it gets back to where it  
   physically was, and then SAS writes the SAS dataset at the end of the
   existing tape, if no matching SAS dataset was found in the library.  
     If a match is found, SAS starts writing the new data set where     
     the old one was found, ERASING ALL OTHER DATA SETS physically after
     that point on the tape!                                            
 The Source of the Problem:                                             
 The required rewind spins the tapes a lot.  If the SAS data library    
 fits on a single volume, there is not too much of a problem.  But if   
 the output tape library expands to multi-volume, the above problem of  
 mounts, dismounts and rewinds will elongate run times, whenever SAS    
 DATA steps are used to create the tape data library.                   
 Past Circumventions:                                                   
 One solution was to build all of the desired SAS data sets on disk, and
 then use PROC COPY from disk to tape.  The PROC COPY knows it does not 
 need to rewind before each data set.  While this avoids the mount      
 problem, it requires as much temporary DASD space as the size of the   
 entire SAS data library, which is why it was not recommended.          
 The New Solution:                                                      
 Each new SAS data set is first built on temporary DASD in "tape        
 format", and then is copied to the output tape using FILE/INFILE logic,
 exploiting the SAS CLOSE=LEAVE option to hold the output tape in place.
 The temporary DASD data set is then erased, so that the job needs only 
 as much DASD space as the size of the single largest SAS data set to be
 created.  The SAS "tape format" originally was created just by using a 
 DDNAME that started with "TAPE....", but now LIBNAME TAPETEMP V6SEQ;   
 syntax is used to create the Sequential Format, which is required so   
 that the SAS data set can be copied with the FILE/INFILE logic.  The   
 following partial example shows how this is done (see member MONTHBLD  
 for complete implementation):                                          
  //            DSCB=SYS1.MODEL,LABEL=EXPDT=99000                       
  //TAPETEMP DD DSN=&TEMP,UNIT=SYSDA,SPACE=(CYL,(10,10))                
      LIBNAME TAPETEMP V6SEQ;                                           
      DATA TAPETEMP._DSET;                      create _DSET in TAPETEMP
        SET WEEK1._DSET WEEK2._DSET ...   ;     input data sets         
        BY _BYLIST:                             sort order variables    
        IF date selection logic;                selection criteria      
      DATA _NULL_;                              copy _DSET to MONTH     
        INFILE TAPETEMP;                                                
        FILE MONTH MOD CLOSE=LEAVE;                                     
        PUT _INFILE_;                                                   
      DATA _NULL_;                              write EOF to TAPETEMP to
        FILE TAPETEMP;                           "scratch" _DSET        
 These three DATA steps are then repeated for each data set to be built,
 by invoking the _MNTHBLD macro as shown in member MONTHBLD.  Our thanks
 to Susan Marshall, SAS Institute, for  this  circumvention.   The  only
 additional  cost  is  the  extra copying of each output data set.  This
 solution only eliminates mounts for the output SAS  data  library.   If
 the  input  data  sets  are  on multiple volumes, each new data set may
 causes the same rewind and dismount/mount sequence.  These input mounts
 can  only be eliminated (at present) by specifying multiple units where
 necessary, eg., with UNIT=(TAPE,2) for a  two-volume  input  tape  data
    SAS  Institute  is  investigating a new SAS option which might allow
    you to override that "rewind and search" algorithm  for  both  input
    and  output tape data libraries.  Provided the order of building new
    data sets is the same as their order on the  input  data  libraries,
    such an option could completely eliminate the unnecessary mounts and
    unnecessary copy steps.  No commitment has been made by SAS yet.    
 However, early experience with  this  circumvention  is  overwhelmingly
 positive  - fewer tape drives, fewer tape mounts, significant reduction
 in elapsed time, all for a few seconds of  I/O  time!                  
 b. SAS ZAPs which you should install.                                  
  ZAP 516.2525     Corrects (erratic) error condition in PROC PLOT if   
                   data set has zero observations.                      
  ZAP 516.4592     PROC FORMAT can cause a "STOW failure" message on the
                   SAS log (no error condition, no abend) if the PDS to 
                   which the formats are being written does not have    
                   enough directory blocks defined. Some formats will be
                   missing, with no notification. This ZAP tells you.