The 'S' in FBS does not stand for SPANNED. It stands for STANDARD meaning all the blocks are a standard size.
There are a few cautions to using FBS files. Do not MOD data to a FBS file. A short block in an FBS file is a EOF condition. This means that if you luck out and fill the last buffer of a file, you can MOD to it, but 99 44/100 percent of the time it doesn't work and a program that goes to read the file doesn't see the added records in the file. I can't recommend using FBS in the general case at all. If you need random access to data, you are probably better off using a VSAM KSDS file. FBS can be useful in very specialized cases, but in general, avoid it. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Crayford Sent: Wednesday, June 05, 2013 8:19 AM To: [email protected] Subject: Re: I/O Optimization >> BTW, is the reason FBS is fast for seeks because it makes it easier >> to calculate the track position for a POINT? I've never seen FBS used before. > I don't know what IBM uses under the covers, but it's probably the > same thing that SAS/C did. Calculate the CCHHR from the byte offset > and use EXCP to read the block directly. No need to use POINT. FBS is > guaranteed not to have any short blocks, so the calculation is trivial. > Where does "spanned" come into play? Why does that make the difference? >> On 5/06/2013 1:24 PM, Bernd Oppolzer wrote: >>> Yes, I guess, that the freads on ZFS will be faster, but: >>> >>> - the customer wants the files to be classical z/OS data sets, and >>> >>> - because of the cache (least recently used algoritm), the I/O >>> delays are of no real concern any more - the elapsed time is much >>> better than in the DB2 case, anyway. >>> >>> But: we observed that RECFM=FBS is needed; otherwise the fseek calls >>> are very slow (the tables have indexes which are B*-tree structures >>> and operate based on record numbers, so an efficient fseek call is >>> needed). >>> >>> Kind regards >>> >>> Bernd >>> >>> >>> >>> Am 05.06.2013 04:01, schrieb David Crayford: >>>> Did you try using a ZFS file system? On my system >>>> freads()/fwrites() to a unix file are significantly faster than QSAM/BSAM. >>>> >>>> On 5/06/2013 9:33 AM, Bernd Oppolzer wrote: >>>>> Two weeks ago, I told you about tests with our table system, which >>>>> holds read-only data for our insurance math package. >>>>> >>>>> The data was stored in DB2 tables until now, and we tried to get >>>>> better CPU usage etc. by moving the data to our file based table >>>>> system, which we have in the Windows and Unix environments. >>>>> >>>>> First tests showed a reduction in CPU time, but an increased >>>>> elapsed time, due to I/O waits during fseek / fread calls. See >>>>> below. >>>>> >>>>> Now we examined this more deeply, and, as it turned out, the main >>>>> storage cache simply didn't work due to configuration errors. This >>>>> was the reason for the many file I/Os that occured and for the >>>>> massive I/O waits. >>>>> >>>>> We fixed this, and we set the cache size to 9 MB (the table sizes >>>>> are some hundred MB). Furthermore, the file attribute have to be >>>>> RECFM = FBS, to support the fseek operations in an optimal way. >>>>> >>>>> Doing this, we got the following results: >>>>> >>>>> CPU time and elapsed time is reduced to about 50 % of the original >>>>> value; and that is not only the time for the table access, but for >>>>> the whole computation !! >>>>> >>>>> That means, that the reduction in table access times must me still >>>>> much higher. >>>>> >>>>> This can be explained by the following things: >>>>> >>>>> a) because the table system and the cache is in the same address >>>>> space as the application, we have no address space switching >>>>> traffic, as we have with the DB2 solution >>>>> >>>>> b) DB2 is used by other requesters, too >>>>> >>>>> c) because the tables are read-only, the table system does nothing >>>>> with respect to transaction control etc, no locking and logging, >>>>> which makes it faster than DB2 >>>>> >>>>> Of course, the drawback is: >>>>> >>>>> you have to spend 9 MB cache storage more in every region where >>>>> the application runs. But that's so little, that overall system >>>>> control has no problem with it. >>>>> >>>>> We do a mass test tomorrow to check out the behaviour of the >>>>> system, if there are many computations in a large number of >>>>> parallel jobs. If the results are the same, we will migrate the >>>>> system to the file based solution in the near future. >>>>> >>>>> Kind regards >>>>> >>>>> Bernd ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
