home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1786 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.5 KB  |  50 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!MCMAIL.CIS.MCMASTER.CA!DFRASER
  3. X-Envelope-to: IBM-MAIN@RICEVM1.BITNET
  4. Message-ID: <Pine.2.4.9207231400.B12273@mcmail>
  5. Newsgroups: bit.listserv.ibm-main
  6. Date:         Thu, 23 Jul 1992 14:18:05 -0400
  7. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  8. From:         Doug Fraser <dfraser@MCMAIL.CIS.MCMASTER.CA>
  9. Subject:      Re: 3390 blksize calculation
  10. In-Reply-To:  <199207231536.AA08846@mcmail.cis.mcmaster.ca>
  11. Lines: 37
  12.  
  13. On Thu, 23 Jul 1992, Jerry Bryan wrote:
  14.  
  15. > In article <IBM-MAIN%92072210340646@RICEVM1.RICE.EDU>, Zoltan Forray
  16. > <SSTSZXF@VCUVM1.BITNET> says:
  17. >
  18. > >For 3380 type disks, a half-track block (23400) is usually optimal for most
  19. > >things like load libraries. If you used anything much larger, you would waste
  20. > >a large amount of space on each track.
  21. >
  22. > Reasonable people can disagree about this, but I would have said that
  23. > half-track is best for most things *except* load libraries, where
  24. > 32K blocking is best.  Load libraries are RECFM=U, which means that
  25. > the blocks are variable length.  Many blocks are small to medium,
  26. > no matter what the block size is.  A block which *can* fit on the
  27. > remainder of the track *will* be placed on the remainder of the
  28. > track and vice versa.  Here are some examples.  1) First block is
  29. > small, second block is half-track (fits), third block is half-track
  30. > (doesn't fit, space wasted).   2) First block is small, second block
  31. > is 32K (fits), third block is small (fits).  3)  First block is
  32. > 32K, second block is small (fits), third block is 32K (doesn't
  33. > fit).  Construct the example of your choice to prove whatever you
  34. > want to prove.  My personal humble opinion is that 32K is fine,
  35. > maybe even best, for load modules, because so many of the blocks
  36. > are small.  Why not get the advantage of the occasional 32K block?
  37.  
  38. We run mvs 2.2.x now.  I believe that this was true for mvs 2.1.7 as well.
  39. I did some experiments on this.  Our policy now is 32k load libraries for
  40. everything new.  My experiments involved actually looking at the lengths
  41. of the blocks of the load modules on the disk.
  42.  
  43. IEBCOPY now has a copymod statement which will copy and reblock load
  44. modules.  You may have to be careful about concatenation of libraries.  I
  45. don't remember.
  46.  
  47. I recommend half track blocks for other (sequential) datasets, allocating
  48. in blocks, and rounding to cylinder boundaries if the dataset is over 1 or
  49. 2 cylinders in size.
  50.