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

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

810.0. "INSVIRMEM from mcc_enr_enroll" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Mon Mar 18 1991 23:59

When I put all the directives for all the entities in our model into the
dispatch table, it gets rather large, as shown by the PSECT size:

MCC_DISPATCH                    00006AC4  (27332.) 

When I try to enroll it, the mcc_enr_enroll call fails with INVIRMEM.

Can an AM enroll multiple (smaller) dispatch tables to get around this?
T.RTitleUserPersonal
Name
DateLines
810.1some things that don't work...COOKIE::KITTELLRichard - Architected Info MgmtWed Mar 20 1991 16:2110
I doubled my wsquota from 4096 to 8192. Same thing.

I broke the dispatch table into three pieces. In my init routine the
enroll of the first table succeeds, the enroll of the second table fails
with the same error. If I skip the second and enroll the third, it
also fails.

Since the dispatch table is a global section, am I perhaps running to
some other limit?
810.2The dispatch table is NOT a global sectionTOOK::GUERTINI want my MCCWed Mar 20 1991 17:303
    That was way back when.  It hasn't been a global section for ages.
    
    -Matt.
810.3What's your pgflquo?TOOK::GUERTINI want my MCCWed Mar 20 1991 17:335
    Check out your process page file quota, and you sysgen parameter
    VIRTUALPAGECNT, both should be 40,000 if you do not use iconic map,
    much higher (100,000?) if you do use it.
    
    -Matt. 
810.4INFO: process limitsCOOKIE::KITTELLRichard - Architected Info MgmtFri Mar 22 1991 13:4022
RE: .3

Here's my process limits. They look big enough, no?

$ show work
  Working Set      /Limit= 866   /Quota= 4096    /Extent= 16384
  Adjustment enabled    Authorized Quota= 4096  Authorized Extent= 16384
$ show proc/quota

22-MAR-1991 08:40:28.25   User: KITTELL          Process ID:   2040449D
                          Node: CRUMBS           Process name: "KITTELL_I_1"

Process Quotas:
 Account name: YK1
 CPU limit:                      Infinite  Direct I/O limit:        50
 Buffered I/O byte count quota:     63712  Buffered I/O limit:     100
 Timer queue entry quota:             256  Open file quota:        100
 Paging file quota:                118791  Subprocess quota:        10
 Default page fault cluster:           64  AST quota:              148
 Enqueue quota:                      2048  Shared file limit:        0
 Max detached processes:                0  Max active jobs:          0
810.5yes, but the sysgen param VIRTUALPAGECNT is more importantTOOK::GUERTINI want my MCCFri Mar 22 1991 13:491
    
810.6 COOKIE::KITTELLRichard - Architected Info MgmtFri Mar 22 1991 18:564
RE: .5

Sorry Matt, I meant to include that the VIRTUALPAGECNT is 402000.
810.7This is getting interestingTOOK::GUERTINI want my MCCMon Mar 25 1991 12:5515
    Something doesn't add up and I can't put my finger on it.  We send out
    a dispatch table that is around 75 percent *empty*.  That's with all of
    phase5, phase4, Alarms, historian, exporter, pa, registration, domain,
    etc.  A Large dispatch table is something on the order of Phase4 (I'm
    sure your dispatch table is smaller).  A Huge dispatch table is
    something like Phase5 (probably more than twice the size of Phase4).  I
    think the Phase5 .MS files are around 2400 blocks (it would take you
    over a month just to type in the text for MS files).  I doubt very much
    that the dispatch table is full, or anywhere near full.
    
    I running out of guesses as to why you get Insufficient Virtual Memory,
    but I think it has little or nothing to do with the Dispatch Table
    size.  Did you try running on another system?  Are you running in a
    cluster environment?  Where is your paging file(s) located? (look for
    pagefile.sys).  How big is your page file?
810.8smaller table works fineCOOKIE::KITTELLRichard - Architected Info MgmtMon Mar 25 1991 15:5125
RE: .7

>    I running out of guesses as to why you get Insufficient Virtual Memory,
>    but I think it has little or nothing to do with the Dispatch Table
>    size.  Did you try running on another system?  Are you running in a
>    cluster environment?  Where is your paging file(s) located? (look for
>    pagefile.sys).  How big is your page file?

              System Memory Resources on 25-MAR-1991 10:45:39.54

Paging File Usage (pages):                      Free  Reservable       Total
  DISK$CRUMBS$PAGE:[CRUMBS]SWAPFILE.SYS;1      20000       20000       20000
  DISK$CRUMBS$PAGE2:[CRUMBS]SWAPFILE.SYS;1     20000       20000       20000
  DISK$CRUMBS$PAGE:[CRUMBS]PAGEFILE.SYS;1     418766      206512      525000
  DISK$CRUMBS$PAGE2:[CRUMBS]PAGEFILE.SYS;1    402663      199432      525000

This is a cluster, and I have tried running on other systems to no avail.

But Matt, your statements made it clear that I'd better start looking at
what I was doing, after all, Phase V fits, right? So I had a look-see and
decided I was suffering from too much granularity in the dispatch table.
To whit: I had forgotten about that powerful ellipsis (...) operator.
After greatly reducing the number of entries in my dispatch table enrollment
suceeds.
810.9Yes. Please use LOTS and LOTS of elipsis'TOOK::GUERTINI do this for a living -- reallyMon Mar 25 1991 16:3914
    Richard,
    
    I was going to ask you to define the IM debugging logical to 210:
    
    $ define MCC_IM_LOG 210
    
    and see if you get any internal error messages, such as "No block
    available for request", or "No memory for Dispatch Pool".  Which would
    indicate that you really did fill up the Dispatch Table.
    
    But it looks like you found a better solution.  Yes, we do use the
    elipsis alot (and apparently you should too).
    
    -Matt.