From:	MERC::"uunet!VM1.NODAK.EDU!OWNER-ANU-NEWS"  2-MAR-1993 21:29:37.20
To:	Multiple recipients of list ANU-NEWS <ANU-NEWS@VM1.NoDak.EDU>
CC:	
Subj:	ANU News 6.1 beta 6: RMS Performance Patches

A number of messages to this group have requested a "Turbo" skim command
for NEWS, in order to speed up processing.

While a full Turbo-Skim isn't possible, it is possible to use a number
of the RMS performance options to speed up processing of NEWS and, in
particular, the SKIM run.

The following is a description of the effect of the patches and an
important warning about their use:

These patches are controlled by 3 logical names:

        ANU_NEWS_ITEMFILE_BUFFERCOUNT
        ANU_NEWS_GROUPFILE_BUFFERCOUNT
        ANU_NEWS_HISTORYFILE_BUFFERCOUNT

These logicals are translated via normal system routines, so may be
defined in any system, group, job, or process table, or may be defined
differently for different contexts.

If these patches are installed, and those logicals are not defined, NEWS
behaves as before.

If these patches are installed, and the logicals ARE defined, the following
happens to RMS processing of the NEWS.ITEMS, NEWS.GROUPS, and HISTORY.V60
files:
        1) RMS deferred write is turned on - Normally, RMS will write a
        buffer as soon as it is modified. Deferred write delays the writing
        of the buffer until RMS needs to reuse the buffer space.
        2) The file is opened with "cathedral windows", mapping all extents
        and obviating window turns.
        3) If the logical translates to a valid integer, that value is
        used as the RMS multibuffering count.

*WARNING*                                                       *WARNING*

RMS uses a very conservative approach to file and buffer management, and
for good reasons. If you define these logicals, and are, for example, running
a SKIM when your system crashes, you will most likely corrupt your NEWS.ITEMS
file, as there will be many modified buffers that will be unwritten. Life is
full of tradeoffs. This is but one of them.

Also, if you define these logicals to be large numbers, be sure the
accounts that will be using them have sufficient process quota to
make good use. Locks are taken out for each buffer - be sure that ENQLM
is large enough, NEWs dies horribly if you run out locks. Also, be sure
that there is a large enough working set to contain these buffers.

*ADVICE*

The biggest, and safest, advantage I've seen from these patches is to
be sure that the NEWS.GROUPS file is entirely buffered throughout a SKIM
run. As no new records are written to NEWS.GROUPS, only item counts
changed, this file is safe from corruption.

Using SET FILE/STATISTICS and MONITOR RMS to see the effect, if any, of
this tuning is well advised.

The patches (to NEWSFILES.C and NEWSDELETE.C) are posted in the reply to
this message.

As always, use at your own risk. Feedback and further suggestions are
encouraged.
********************************************************************************
Saul Tannenbaum                         |
Manager, Scientific Computing           |Internet: SAUL@HNRC.TUFTS.EDU
USDA Human Nutrition Research Center on |
    Aging at Tufts University           |
*********************** Standard Disclaimers Apply *****************************