Conference csc32::consolemanager

664.0. "DEFMBXBUFQUO and OpenVMS with PCM" by OPG::SIMON (Simon Jackson @reo 830 X3879) Thu Mar 30 1995 09:33

Hi,
   we had a high priority problem recently with a customer who had problems
getting PCM to work. The problem has been resolved as a problem with the setting
of the DEFMBXBUFQUO sysgen parameter. Below you will find an explanation of the
effects of this parameter on PCM. Hope this is of use to some other people as
well.

Cheers Simon...


   ------------------------------------------------------------------------




    The aim of the following is to provide a basic understanding of the
    buffer and file quota requirements for PCM V1.5a on OpenVMS. This has
    been written in response to a customer situation where quota settings
    caused PCM problems.

    PCM Components:
    ---------------
    
    The PCM software makes use of considerable numbers of mailboxes in
    order to implement an IPC system between it's software components.

    The components which need to be considered are as follows:

    o Console Daemon Process (Parent).

    o Console Controller Processes (Children).

    o Event Notification System Process (ENS).

    Mailboxes:
    ----------

    When a mailbox is created by a process it requires a buffer to be
    allocated for Input/Output messages. This buffer is allocated as part of
    the crembx() call. The buffer size is set by the calling process or can
    be defaulted to a SYSGEN default. In the case of PCM V1.5 all the
    listener and connect mailboxes created use the system default value for
    their buffer. This is defined by the SYSGEN parameter MAXMBXBUFQUO.

    Each time the mailbox is created the value of MAXMBXBUFQUO is deducted
    from the BYTLM quota for the process which creates the mailbox. If the
    BTYTLM quota is exceeded thaen the mailbox create will fail. In certain
    cases this is a fatal error within PCM. Therefore it is vital to tune
    these parameters correctly.

    Due to a message size requirements in PCM the MAXMBXBUFQUO should never
    be set to less than 1024. Increasing it significantly above that value
    will have knock on effects on process quotas as will be discussed
    below.

    Mailboxes for Parent Process:
    -----------------------------

    The Parent process creates the following mailboxes:

    o 1 for connect listenter.
    o 2 for each Child process (the number of Children is dependant on the
                                number of managed systems 1 Child per 16
				systems managed).
    o 2 for the ENS process.
    o 2 for each active user connect (e.g. C3, Connect, Monitor)

    The total number of Mailboxes should then be multiplied by the
    MAXMBXBUFQUO quota to obtain the BYTLM required for the mailboxes of
    the Parent.

   On a PCM system the default BYTLM for the Parent process is 655350 Bytes.

    Mailboxes for Child Processes:
    ------------------------------

    The Child process creates the following mailboxes:

    o 1 for each managed host listener on the Child (up to 16).
    o 2 for connection to the parent.
    o 2 For ENS connection.
    o 2 for each active user connect (e.g. C3, Connect, Monitor, Archive
                                      Watch)

   On a PCM system the default BYTLM for the Child processes is 655350 Bytes.

    Mailboxes for ENS process:
    --------------------------

    The ENS process creates the following mailboxes:

    Permenant:
    
    o 6 for the various ENS listeners.
    o 2 for the Parent process.
    o 2 Per Child Process.

    Transitory:

    o 2 per API connect (CMUserSendEvent()).
    o 2 per Monitor Interface.
    o 2 per C3 process and a second 2 for an eventlist if running under the
      C3.
    o 4 if using the OSCInt preprocessor.
    o 2 Per action routine (If the action is the multiple event type using
                            API e.g. EventList action).


   On a PCM system the default BYTLM for the ENS process is 1024000 Bytes.


    Example:
    --------

    Taking the following scenario:

    PCM managing 24 systems running 5 concurrent C3 displays with 4
    concurrent managed system monitors running from each. In addition the
    ENS process is managing 10 Eventlist actions.

    MAXMBXBUFQUO = 1056

    Parent:

    Number of Mailboxes:

	1 +   Connect Listener.
	4 +   2 Children for 24 systems.
	2 +   ENS.
	10+   5 C3 processes.
	40    4 Monitors from each of 5 C3 processes.
        __
	57
	__

    This is then multiplied by the MAXMBXBUFQUO quota.

       57 x 1056 = 60192 Bytes.

    So the parent BYTLM must be in excess of this value to satisfy the
    requirements for Mailboxes.

    Child:

    The worse case for a child is the one with 16 attached systems and I
    shall assume that all the monitor sessions are to it's managed systems.

    Number of Mailboxes:

    16+ 1 for each managed system.
    2 + Connection to Parent.
    2 + Connection to ENS.
    50  5 C3s and 20 Monitors.
    __
    70
    --

    This is then multiplied by the MAXMBXBUFQUO quota.

       70 x 1056 = 73920 Bytes.

    So the child BYTLM must be in excess of this value to satisfy the
    requirements for Mailboxes.
    

    ENS:

    Number of Mailboxes:

     6 + ENS Listeners.
     2 + Parent connect.
     4 + 2 Children.
     40  20 Monitor Sessions
     20  5 C3 processes with attached Eventlist.
     20  10 EventList Action Routines.
     __
     92
     --

    This is then multiplied by the MAXMBXBUFQUO quota.

       90 x 1056 = 95040 Bytes.

    So the child BYTLM must be in excess of this value to satisfy the
    requirements for Mailboxes.
    
     
    NOTE:

    The processes will require additional BYTLM to the above for other
    internal buffering requirements.

    
    Open File Requirements:
    -----------------------

    Each of the created mailboxes have a channel assigned and the Channel
    is counted against the process FILLM quota.

    In addition the the Mailboxes each Process type has the following files
    and hence Channels open:

    Parent:

    Permanent:
    
    o 3 For Sys$Input sys$Output and Sys$Error.
    o 3 For ConsoleManager LOG EVENT and TIMES files.

    Transitory:
    
    o 1 For each Child.

    Child:

    Permenant:

    o 3 For Sys$Input sys$Output and Sys$Error.
    o 3 For ConsoleManager LOG EVENT and TIMES files. 
    o 3 For each managed host for the LOG EVENT and TIMES files.

    Transitory:

    o 1 For each PsuedoTerminal during creation of Psuedoterminal command.

    ENS:

    o 3 For Sys$Input sys$Output and Sys$Error.
    o 1 For each action routine (Open during dispatch of action).


    During a reconfigure all the Main processes Parent Children and ENS
    Open the Configuration database.

    In the above eaxmple the process have the following number of files
    open:

    Parent:

    57+ Mailboxes.
    8   Other Files.
    __
    65
    __

    Child:

    70+ Mailboxes.
    54  Other Files.
    ___
    124
    ___

    ENS: 

    90+ Mailboxes.
    13  Other Files.
    ___
    103
    ___

Hi,
    in the base note I managed to put MAXMBXBUFQUO rather than DEFMBXBUFQUO
all the way through. well that's the great thing about cut and paste "Once Wrong
Always Wrong"

Sorry about that people!!!

Cheers simon...

    Simon,
      I have a minor nit with the statement about mailbox channels and
    FILLM. It's not quite correct. When you open a file it is indeed a
    tick against the FILLM quota. However, when you assign a channel
    to a device via the $ASSIGN system service it is not counted against
    FILLM. There is a sysgen param known as CHANNELCNT that defines the
    number of channels that each process may have. The Channel Control
    Block table is allocated from P1 space and is sized according to
    the SYSGEN param. Note also that CHANNELCNT is non-dynamic thus any
    change requires a system reboot.  Note also that opening a file
    *also requires a channel* so CHANNELCNT can limit the number of files
    that you can open, i.e., if CHANNELCNT is less than FILLM then you will
    run out of channels before you have exhausted then FILLM quota.
    
    Regs,
      Dan

Dan,
     thanks for putting me right. I knew about the CHANNELCNT parameter, but
did not fully understand the difference.

Cheers Simon...

    Your quite welcome..... you Unix pukes need all the VMS help you can
    get :-0 ;-} !!!!!!!!!!!
    
    Regs,
      Dan