[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3563.0. "Contiguous gblpage, min & dynamic, installation??" by KERNEL::PULLEY (Come! while living waters flow) Thu May 08 1997 17:42

    I'm confused.
    
    In the installation guide for C++ May 1996 for v5.3 ... in section 1.3
    it talks about system parameters and points me to tables 1-3, 1-4, 1-6.
    What I don't understand is what is meant by minimum and dynamic.
    For table 1-4, they seem to be teh same value for both.
    In table 1-6, they are very different.
    E.g., minimum and dynamic value given in 1-4 for clisymtbl is 500.
    For contiguous gblpage count min is 900 and dynamic is 95 in table 1-6.
    Waht does it all mean?
    
    Thanks for any comments,
    Steve.
    
T.RTitleUserPersonal
Name
DateLines
3563.1Set to the Minimums (or higher) via MODPARAMS & AUTOGENXDELTA::HOFFMANSteve, OpenVMS EngineeringMon May 12 1997 20:1643
   You're not the only one that is confused -- I suspect the wording on
   the tables should be "minimum" and "default", I don't know where the
   "dynamic" is coming from here.  I further suspect this confusion may
   have been due to a cut-and-paste from a SYSGEN table that once included
   the settings of some PQL SYSGEN parameters...  The PQL SYSGEN parameters
   are paired, with both a "PQL_D" default and a "PQL_M" minimum form.)

   When no PQL parameter is specified on a process creation, the default
   value is used.  And the lowest setting one can have is the minimum
   value.

   Table 1-6 lists the minimum amount of *contiguous* global section
   pages, unlike the previous tables that indicate total requirements.
   The page tables used for global sections, just like disk sectors,
   can become fragmented.  The only way to clear this is to deinstall
   and/or delete some resident stuff, or (unlike disks) to reboot...

   Set the minimum values as required in the documentation, ignore the
   default (or "dynamic" settings) remembering when making the changes
   to use SYS$SYSTEM:MODPARAMS.DAT and AUTOGEN, and using the ADD_ or
   the MIN_ syntax on the entries -- do not, for instance set GBLSECTIONS
   to 10, use ADD_GBLSECTIONS=10 or MIN_GBLSECTIONS=currentvalue+10.  Also
   remember to account for other usage of the parameter -- GBLPAGES and
   GBLSECTIONS parameters are pretty cheap, and it does not normally
   hurt typical OpenVMS operations nor memory usage to overconfigure
   these settings by 10% to 20%, or more.  (And when in doubt, "add
   more memory".  See the performance manual for the specific overhead
   involved with increasing these settings...) 

   (I'd recommend whomever is in control of the KITINSTAL add a couple
   of f$getsyi("FREE_GBLPAGES") and f$getsyi("CONTIG_GBLPAGES") calls,
   to verify these settings.  (The underlying requirement for these
   checks has, however, likely been entirely superceded by the INSTALL
   changes made in the OpenVMS V6.2 release -- INSTALL now tests for
   room *before* deinstalling the old image.  And this change makes it
   rather harder to end up with no DCLTABLES installed when sufficient
   contiguous pages do not exist.  Of course, the C++ kit likely also
   installs on pre-V6.2 systems, too.)

   I'd log a QAR against the C installation documentation.  This is
   rather confusing...

3563.2kitinstal.com does that another way. I assume it is okDECC::ERICWFri May 16 1997 18:4212
The KITINSTAL.COM checks for GBLPAGES by issuing

$ VMI$CALLBACK GET_SYSTEM_PARAMETER CXX$N_GBLPAGES CONTIG_GBLPAGES
$ VMI$CALLBACK GET_SYSTEM_PARAMETER CXX$N_GBLSECTS FREE_GBLSECTS

and then checking to see if the values are in range.  I assume those checks are
suitable substitutes for the F$GETSYI() calls you mentioned in .1, and that the
calls will work on VAXVMS V5.5-2 / AlphaVMS V6.1 and beyond.  I have not ever
seen the code fail when running on pre-6.2 systems.  Is there some restriction I
am not aware of?

Eric