Gil, That's the second time you mention seeking in this thread.
In reality most emulated tracks, in fact CYLS, are located on a single physical track of the underlying FBA disk drive, and part of a stripe across several spindles. In HDS case, sequential pre-fetch reads a whole stripe into cache, which can be 24, 32, 42 or 48 tracks depending on the RAID scheme you are using. Intra file seeking due to differences in BLKSIZE would be an insignificant impact in DASD arrays nowadays. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Gilmartin > Sent: Thursday, 16 February 2006 5:27 AM > To: [email protected] > Subject: Re: DASD allocation guidelines > > In a recent note, Barry Schwarz said: > > > Date: Wed, 15 Feb 2006 12:15:39 -0800 > > > > If you really want to maximize the FB blocksize (in the hopes of > improving perfor > > mance without regard to impact on size), then specify the blocksize in > the JCL DD > > statement or DCB macro with a value computed as (32767/LRECL)*LRECL > using intege > > r arithmetic. > > > Won't that give BLKSIZE=28000, resulting in only one block/track. > Is it fair to assume that SSCH is expensive and seek is cheap? > > -- gil > -- > StorageTek > INFORMATION made POWERFUL > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
