[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 20: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.R	Title	User	Personal Name	Date	Lines
810.1	some things that don't work...	COOKIE::KITTELL	Richard - Architected Info Mgmt	`Wed Mar 20 1991 13:21`	10
	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.2	The dispatch table is NOT a global section	TOOK::GUERTIN	I want my MCC	`Wed Mar 20 1991 14:30`	3
	That was way back when. It hasn't been a global section for ages. -Matt.
810.3	What's your pgflquo?	TOOK::GUERTIN	I want my MCC	`Wed Mar 20 1991 14:33`	5
	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.4	INFO: process limits	COOKIE::KITTELL	Richard - Architected Info Mgmt	`Fri Mar 22 1991 10:40`	22
	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.5	yes, but the sysgen param VIRTUALPAGECNT is more important	TOOK::GUERTIN	I want my MCC	`Fri Mar 22 1991 10:49`	1

810.6		COOKIE::KITTELL	Richard - Architected Info Mgmt	`Fri Mar 22 1991 15:56`	4
	RE: .5 Sorry Matt, I meant to include that the VIRTUALPAGECNT is 402000.
810.7	This is getting interesting	TOOK::GUERTIN	I want my MCC	`Mon Mar 25 1991 09:55`	15
	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.8	smaller table works fine	COOKIE::KITTELL	Richard - Architected Info Mgmt	`Mon Mar 25 1991 12:51`	25
	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.9	Yes. Please use LOTS and LOTS of elipsis'	TOOK::GUERTIN	I do this for a living -- really	`Mon Mar 25 1991 13:39`	14
	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.