PROCSECTCNT documentation

[Mario Dhaenens]

Hello,

I get following error when I try to start my application.
"process or global section table is full"

When I increase SYSGEN Parameter PROCSECTCNT to form 256 to 1000 the application starts. OK.

What is the impact on all other processes running on the same I64 server?
Is there any documentation about this sysgen parameter;
Of course there is the help in SYSGEN.


%LIB-E-ACTIMAGE, error activating image -SYSTEM-F-SECTBLFUL, process or global section table is full
%TRACE-E-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
LIBRTL LIB$FIND_IMAGE LIB$FIND_IMAGE_SYMBOL
1812 0000000000002800 FFFFFFFF901BC750

[Robert Gezelter · Accepted solution]

Mario,

As documented in the internal SYSGEN HELP text, the increased value increases the size of the process header.

Since this increase is 32 bytes/section, I would generally not be concerned. Increasing PROCSECTCNT from 256 to 1,000 will only increase the process header by less than 24K (K==1024 bytes).

See the OpenVMS Internals and Data Structures Manual for details of the layout of the process header.

The impact of increasing PROCSECTCNT is generally small.

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

Hello Mario.

The sysgen parameter description (you indicated those already) for this item is pretty clear:

MCR SYSGEN
SYSGEN> help SYS_PARAMETERS PROCSECTCNT
:
"PROCSECTCNT sets the number of section descriptors that a process can contain. Each section descriptor increases the fixed portion of the process header by 32 bytes. Set a value greater than the maximum number of image sections in any section to be run, as indicated by the linkage memory allocation map for the image."

>> What is the impact on all other processes running on the same I64 server?

24KB memory set aside ((1000-256)*32 ).
That's probably 1 extra physocal page touched, and 2 unused.

>> Of course there is the help in SYSGEN.

How about ANALYZE/SYSTEM ... SET PROC ... SHOW PROC /PST

That should tell you how many you really need. It can help figure out WHICH IMAGE contributes how many sections.

For example:

$ pipe write sys$output "SHOW PROC/ID=20200487/PST" | anal/system | perl -pe "$x{$1}++ if /](\S+);/; print if /allo/} { for (keys %x
) { print qq($x{$_}\t$_\n)}"
Last entry allocated 00000033
5 CMA$LIB_SHR.EXE
8 DCE$SOCKSHR_IP.EXE
2 DPML$SHR.EXE
1 WSI$MESSAGE.EXE
1 CXXL$LANGRTL.EXE
1 WSI$COMMON_SS.EXE
6 WSI$COMMON.EXE
1 DCL.EXE
6 DTSS$SHR.EXE
2 DCE$KERNEL.EXE
3 WSI$MANAGER.EXE
1 SECURESHRP.EXE
3 WSI$IPCSHR.EXE
3 CMA$OPEN_LIB_SHR.EXE
5 DCE$LIB_SHR.EXE
1 DCE$RPC_MSG.EXE
2 CXXL$011_SHR.EXE


hth,
Hein.

[John Gillings]

Mario,

If you're worried about increasing PROCSECTCNT, and affecting all processes, you may be able to increase the number of sections available to a particular application for a specific process by decreasing the WSEXTENT of that process.

The process section table and the working set list grow into each other. Any unused space in the WSLE is available for additional process sections. PROCSECTCNT is the *minimum* available).

The WSLE is sized by WSMAX. Most modern systems set PQL_MWSEXTENT to WSMAX, so the entire WSLE is used. You would need to reduce PQL_MWSEXTENT, so you can set the WSEXTENT for an individual process lower than WSMAX. That should free up some space in the WSLE to be used for process section table entries.

(on the other hand, an extra page or two per process is unlikely to break the bank).