Conference vmszoo::rms_openvms

    Steve,
      I'd argue that these parameters should rarely be modified from
    defaults at the SYSTEM level since it would be very rare to find a
    system where the same value for any of these parameters would be
    optimal, or even desirable for ALL files across the system.
    
      As with any tuning exercise, you need to understand the nature of what
    you're trying to tune and your objectives. Increasing buffer counts on 
    specific files *may* improve I/O performance, but at the expense of 
    increased memory consumption. Increasing them too far, or for files
    with little or no locality will simply swap file I/O for paging I/O.
    
      Know your data in order to tune applications and individual files, you're
    most unlikely to be able to tune the whole system with any of these
    knobs.
    						John Gillings, Sydney CSC

    HEAR! HEAR!   Very well said, John!   -- Elinor

    
    Of course, one has to know the data, it's obvious but my query is
    not yet answered.
    
    One simply has to know the significance of each sysgen parameters
    that tune RMS without this knowledge even if you know the data
    of the system, you don't have an idea what to go about tuning
    parameters which could correct or improve the situation.
    
    In a nutshell, can someone has the knowledge to tell what each
    RMS parameter control, illustrate under what conditions will
    that be applicable ?
    
    sl.
    

    Steve,                                                               
    
      OK, here is a rough outline of what the parameters are for and when
    they should be changed. Note that all RMS parameters except GBLBUFQUO
    are system wide defaults. They can be overridden per process with the
    SET RMS_DEFAULT command, or per file with the appropriate RAB or XAB
    setting. Also note that the SET RMS_DEFAULT/SYSTEM command changes
    the active SYSGEN parameters.
    
    RMS_PROLOGUE      - don't touch, this is not a tuning parameter
    RMS_FILEPROT      - default protection. Default value is 
    			(S:RWED,O:RWED,G:RE,W) which is usually reasonable.
    			See also SET PROTECTION/DEFAULT for changing this
    			on a per-process basis.
    RMS_EXTEND_SIZE   - controls how much a file is extended. Increasing
    			the value can reduce fragmentation at the expense
    			of disk space. Better to set an appropriate extend
    			quantity for each file with SET FILE/EXTENSION.
    RMS_GBLBUFQUO     - System wide quota on the number of global buffers
    			which may be allocated to RMS files. This is a
    			safety guard to prevent exhaustion of global
   			buffers. Increase if you find RMS is running out
    			of buffers and you have sufficient global sections
    			and global pages allocated.
    RMS_DFMBC         - Multiblock count. See RMS Reference RAB$B_MBC
    			Sec 6.11 for a detailed explanation. In summary:
    			"The use of the RAB$B_MBC field optimizes data
    			throughput for sequential operations, and does not
    			affect the structure of the file. It reduces the
    			number of disk accesses for record operations,
    			resulting in faster program execution. However, the
    			extra buffering increases memory requirements."
    RMS_DFMBxxx       - Multibuffer counts for various file and device
    			types. See RMS Reference RAB$B_MBF Sec 6.12. It's
    			a similar deal to MBC. More buffers *may* improve 
    			performance by reducing physical I/O, but cost more 
    			memory.
    
    The point against setting the SYSGEN parameters is that it would be
    extremely rare to find a system for which you could say "all sequential
    disk files should have a multibuffer count of 6" which is what you're
    saying if you set RMS_DFMBFSDK to 6. Indeed such a setting could even
    cause you trouble by depleting memory. So, I would again recommend
    that you DO NOT modify the SYSGEN parameters.
    
    You should be tuning *individual files* not whole systems. See the
    Guide to OpenVMS File Applications, Chapter 3 "Performance
    Considerations" In particular sections 3.2.2.1 and 3.5.2.3 cover multiple
    buffers and 3.3.2 covers mutliblock count. Use MONITOR RMS to check
    on buffer performance.
    
    						John Gillings, Sydney CSC

    
    Thanks John. Your run-down starts to shine some light onto this topic.
    It do put things into perspective, it's hard to find the needle in
    the sea bed, you definitely know what I mean.
    
    -steve
    

<<    RMS_GBLBUFQUO   - System wide quota on the number of global buffers
<<    			which may be allocated to RMS files. ...

  V7.1 Release Notes.  4.20.1.8. This parameter is obsolete as of
  OpenVMS Version 7.1.  The number of global buffers on a system
  can be sufficiently controlled by the system parameters GBLPAGES,
  GBLPAGFIL, and GBLSECTIONS.

  (And just between us, this parameter never really functioned (or 
  functions) in any earlier release.)

    
    so you mean system prior to V7.1 cannot be tuned globally on
    global file buffers with RMS_GBLBUFQUO.
    
    One has to resort to tuning via :
    
    1) set/file/global_buffer=n
    
    OR
    
    2) set RMS_DEFAULT /BUFFER_COUNT=count  /SYSTEM
    
    which is more preferable ? any difference in the end results ?
    
    Steve
                                                                  
    
    

  >  so you mean system prior to V7.1 cannot be tuned globally on
  >  global file buffers with RMS_GBLBUFQUO.
   
    No, not at all. GBLBUFQUO was an upper limit to the total number of
    global buffers in use accross all files in a system.
    
   
   >    1) set/file/global_buffer=n
    
    That is the primary way. Always has been, always will be.
    The alternative is a program dynamically setting FAB$W_GBC.

   > 2) set RMS_DEFAULT /BUFFER_COUNT=count  /SYSTEM
    
    No, those would be local buffers. Hmmm, maybe I see the 
    error in your thinking. Global buffers are NOT 'gloabl'
    or system wide means to select a number of buffers for
    a process. They are different buffers from local ones and
    contrary to the local ones, the data in them is visible to
    all processes on that system opening that file.
    
    Hein.