Conference csc32::consolemanager

    There is no absolute answer for your question.
    What are the settings of SYSGEN params DEFMBXBUFQUO DEFMBMXMSG?
    Chances are the setting of DEFMBXBUFQUO is rather high and every
    temporary mailbox that isn't created with hardcoded values will use
    the sysgen params above.
    
    You can also tune the parameters for the child daemons with the
    following magic logicals. Note that the values listed are the defaults
    for each quota. Youwill not find these logicals defined by default:
    
    
          CONSOLE$DAEMON_ASTLM               1024
          CONSOLE$DAEMON_BIOLM               1024
          CONSOLE$DAEMON_BYTLM             327680
          CONSOLE$DAEMON_CPULM                  0
          CONSOLE$DAEMON_DIOLM               1024
          CONSOLE$DAEMON_FILLM               1024
          CONSOLE$DAEMON_PGFLQUOTA          30000
          CONSOLE$DAEMON_PRCLM                 64
          CONSOLE$DAEMON_TQELM               1024
          CONSOLE$DAEMON_WSQUOTA             2048
          CONSOLE$DAEMON_WSDEFAULT            512
          CONSOLE$DAEMON_ENQLM               1024
          CONSOLE$DAEMON_WSEXTENT            8192
          CONSOLE$DAEMON_JTQUOTA             1024
    

	The two parameters are set with the following values:

	DEFMBXBUFQUO=2112
	DEFMBMXMSG=256

	Note that if I increase DEFMBXBUFQUO the problem is delayed but still 
	occurs !

	Thanks for your help

If you increase the value of DEFMBXBUFQUO then your allocating even more
    bytlm per mailbox. Try this:
    
    DEFINE/TABLE=CONSOLE$LOGICAL_NAMES CONSOLE$DAEMON_BYTLM 80000    
    
    This will double the available bytlm to the child daemons. The value
    I posted in -2   of 327680 is wrongs. It's really 32768!
    
    Regs,
      Dan

        Re .-1
        
        Running PCM V1.5 MUP A. To me it appears that the Daemons have
        BYTLM quota around 600 000 even without any logical names. The
        values appears to be as if it was inherited from process
        "Console Daemon". I hope those Ctrl processes are not "pooling"
        the BYTLM with each other and Daemon?
        
        veli

Veli,

  The child daemons are created as detached processes, they do not inherit
  any values from thier parent, the creprc call explicitly sets the quota
  values, when you define these logical names, it is the creprc values that
  you are changing. Now, having said that, we dont allow you to lower the
  values with the logical names, only increase them.

Cheers,
Phil

So, reading all replies in this thread, do you expect following:

Process index: 0021   Name: Console Ctrl 01   Extended PID: 00014321
--------------------------------------------------------------------
Status : 00140001 res,phdres,login
Status2: 00000001 quantum_resched
PCB address              8425BC00    JIB address              84182180
PHD address              89329800    Swapfile disk address    00000000
Master internal PID      01430021    Subprocess count                0
Internal PID             01430021    Creator internal PID     00000000
Extended PID             00014321    Creator extended PID     00000000
State                       HIB      Termination mailbox          0000
Current priority                9    AST's enabled                KESU
Base priority                   4    AST's active                 NONE
UIC                [00001,000004]    AST's remaining               971
Mutex count                     0    Buffered I/O count/limit     1006/1024
Waiting EF cluster              0    Direct I/O count/limit       1008/1024
Starting wait time       1B001B1B    BUFIO byte count/limit     571894/573942
Event flag wait mask     DFFFFFFF    # open files allowed left     974
Local EF cluster 0       60400000    Timer entries allowed left   1005
Local EF cluster 1       C0000000    Active page table count         0
Global cluster 2 pointer 00000000    Process WS page count        3164
Global cluster 3 pointer 00000000    Global WS page count          204

I do not have any CONSOLE$DAEMON_xxxx logicals defined? According to earlier
replies, I would not have expected to see so high BYTLM there?

Veli

    No we don't. The two possibilities are that the logicals are defined or
    the sysgen param PQL_MBYTLM has been increased to 600000.
    
    Regs,
      Dan

Veli,

  Is this causing you a problem? If not, why are you so concerned?

Cheers,
Phil

>  Is this causing you a problem? If not, why are you so concerned?
        
        I have had the same RWMBX problems and our external/internal  business
        relies quite heavily now on PCM. I've been investigating these
        RWMBX problems, read these notes very carefully, tried to
        implement the ideas if they seem reasonable. As part of
        "doublechecking" things just happened to note that Console Ctrl
        0x processes had already QUITE HIGH Bytlm quotas.
        
        We do not have ANY logicals of type CONSOLE$DAEMON... and
        neither can this behaviour (large BYTLMs ) be because of PQL
        params. PQM_xBYTLM are considerably lowe than 570 000.
        
        So, on my system PCM does not behave the way it should according
        to this string of replies. Hopefully this "bug" will not fixed
        on possible future MUP kit :-)
        
        veli

Veli,

  The RWMBX problem has been IPMT'd and I am currently spending my
  time fixing this problem, you should see something you can test
  in a couple of weeks hopefully.

Cheers,
Phil