home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1847 < prev    next >
Encoding:
Text File  |  1992-07-31  |  1.4 KB  |  32 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!CLEMSON.BITNET!CAREY
  3. Message-ID: <IBM-MAIN%92073108125614@UA1VM.UA.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Fri, 31 Jul 1992 09:12:00 EDT
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Jim Blalock <CAREY@CLEMSON.BITNET>
  8. Subject:      Re: IFASMFDP question
  9. Lines: 21
  10.  
  11. On Fri, 31 Jul 1992 07:16:59 EDT Mott Given <ntm1169@DSACG3.DSAC.DLA.MIL> said:
  12. >             ...              Is it posssible that the IFASMFDP program
  13. > reformatted some of the SMF records, or it is more likely that there is
  14. > something wrong with the way that the other site is collecting their SMF
  15. > records?
  16.  
  17. I'd suspect different levels of IFASMFDP.  I'd try copying the records
  18. with a different utility that wouldn't monkey with the data, like
  19. IEBGENER or maybe SAS, and see if the problem persists.  (I think that
  20. GENER does spanned records right; I usually use SAS.)  If you have to
  21. select particular types and if you have SAS, I'd do it this way:
  22.  
  23.   //SMFSELEC EXEC SAS
  24.   //SMFIN DD DSN=<smf.input.dataset>,DISP=SHR,BUFNO=50
  25.   //SMFOUT DD DSN=<selected.smf.records>,DISP=(,CATLG), etc etc
  26.   //SYSIN DD *
  27.     data _null_; infile smfin;
  28.     input @2 type pib1. @;
  29.     file smfout recfm=vbs lrecl=32756 blksize=32760; /* assumes tape */
  30.     if type = <type 1> | type = <type 2> | type = <type 3> | etc etc ;
  31.     put _infile_;
  32.