"Standard" for FBS, not "spanned".
Spanned is for VBS.
=
> Date: Wed, 5 Jun 2013 21:19:09 +0800
> From: dcrayf...@gmail.com
> Subject: Re: I/O Optimization
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> >> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
