CHANNELCNT / FILLM

[Wim Van den Wyngaert]

Does anyone know why the system parameter CHANNELCNT exists ?

As I understand it, it is some kind of maximum for FILLM (or am I wrong ?).

I added a check for the usage of this parameter and found 3 nodes out of 140 that suffered from it (all processes that connect to many other nodes and I guess it is caused by network problems we had some day).

How to check this quota ?
$ write sys$output f$getsyi("CHANNELCNT")
to get the maximum allowed.

To get the highwatermark :
$ ana/sys
>set proc/id=xxxxx
>eval @CTL$GL_CHINDX
>exit

[labadie_1]

Channelcnt refers to the number of files, mailboxes, devices opened.
Fillm is just the maximum number of files a process can open

sda>eval @CTL$GL_CHINDX
gives you the number at the end of
sda> sh proc/chann
total number of open channels:

[labadie_1]

in fact fillm concerns the maximum number of files and active network logical links.

[David B Sneddon]

Wim,

CHANNELCNT dictates the size of a process table
in P1 space. This is the maximum number of channels
that your process can have assigned at any one
time.
The channel number returned from $ASSIGN is just
an index into this table. Because channels are
used for things other than just OPENs in high
level languages it doesn't always directly
relate to number of "files". Channels are used
behind-the-scenes in various system services so
it is possible to have things hang or break for
no apparent reason until you look at things like
FILLM and CHANNELCNT and what was happening at
the time.
Exactly what problem are you seeing?

Regards
Dave

[Kris Clippeleyr]

Wim,

If I'm not mistaken (working from fading memory here), the CHANNELCNT defines the size of the table in P1 space that holds the addresses of the CCBs (channel control blocks) used by the process.
You can find that table at CTL$GL_CCBBASE (at least on VAX). The channel number is an index in this table.

Hope this helps.

Kris

[Wim Van den Wyngaert]

Based upon some processes I checked :

FILLM : open files + all busy NET devices

CHANNELCNT : fillm + the exe + files behind the exe + status blank devices (???) + BG devices + DCL.EXE + mbx

Why wasn't this implemented more clearly ? E.g. mbxlm etc in authorize ?

[David B Sneddon]

Wim,

You wouldn't want a different limit for each file
type. What is associated with the channel is
largely irrelevant. It is the channel control
block that identifies what is channel is pointing
to. All you need is for CHANNELCNT to be "large
enough" so that the process on the system that
has many channels assigned, Pathworks is a big
user of channels as is backup, can do its job
and that FILLM is set to a "bit less" than
CHANNELCNT to allow for those behind-the-scenes
assignments.

Dave

[Ian Miller.]

Was this prompted by this thread?
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=625161

If you are not memory contrained then set it up to 4096 (adds 10 alpha (8k) memory pages to each process) and thats usually ok for most things. Can now be up to 64k channels if you want (old limit was 2047).

The explainations so far say what it is. Why is it there ? I guess its part of the VMS idea of having limits on the use of system resources by a process.

[Wim Van den Wyngaert]

David and Ian,

I do not agree. Quotas are not invented to put on the maximum value. They are used to limit things.

If I put channelcnt on 10.000 then all users can open 10.000 channels (e.g. mailboxes).

I would like to see that I can :
1) limit the number of network connections a process can open
2) limit the number of mailboxes
3) limit the number of files the process opens (not exe, not .com, not dcl)

BTW : what are NET devices that have a blank status ?
and of course, per user, not on system level.

[David B Sneddon]

Wim,

On my desktop Alpha I have CHANNELCNT=8192 and
my UAF entry has FILLM=8000. If you set your
CHANNELCNT to 10000 and your FILLM to 1000, how
many files will you be able to open?
CHANNELCNT puts an absolute limit on the number
of channels a process can use. This structure
is NOT dynamic therefore it needs to be known
when the process is created so the space can be
allocated. The FILLM entry in the UAF can be
different for each user. Since FILLM can be
easily changed, setting a large CHANNELCNT and
changing FILLM should not present any problems.

Dave

[labadie_1]

The post of David makes me think at CTLPAGES
It is only a system parameter (no uaf> mod user/ctlpages=...), and if one user needs a high Ctlpages, you must raise it.

[Wim Van den Wyngaert]

I would also like to add :
1) documentation is bad
CHANNELCNT specifies the number of permanent I/O channels
available to the system.

This special parameter is used by Compaq and is subject to
change. Do not change this parameter unless Compaq recommends
that you do so.
-> on almost all system you MUST modify it
2) default of 256 is too low

[Ian Miller.]

I agree the documentation needs an update and the default needs reconsidering (probably been 256 for a long time now). If you contact hp (try openvmsdoc@hp.com) then the VMS documentation writers will add it to their long list.

[John Gillings]

Wim,

>I do not agree. Quotas are not invented
>to put on the maximum value. They are
>used to limit things.

Regardless of your agreement, CHANNELCNT is not a "quota". It's a system parameter for sizing a data structure used to hold CCBs. CCBs are held in a simple, statically allocated array of fixed sized entries in P1 space. Enteries are accessed by an index. It's sized the same for all processes, that's why it's a system parameter. Some systems need more than others. The default is certainly too small for todays systems, and the maximum value has been increased a few times over the last few versions.

Now, you could propose an open ended type of structure, say a linked list, instead of a table, so it was unnecessary to impose a limit or preallocate space, but that naturally takes up more space and is more difficult to manage. CCBs are not very large, only 32 bytes, so a more complex structure would increase the structural overhead (2x64 bit pointers would take it up to 48 bytes) and increase the possibility of errors (broken links, allocation failures etc...)

>I would like to see that I can :
>1) limit the number of network connections a process can open
>2) limit the number of mailboxes
>3) limit the number of files the process opens (not exe, not .com, not dcl)

These would need to be per-process quotas held in the UAF, not system parameters.

Personally I can't see a lot of merit in having per-channel-type limits. Just a whole lot more knobs that can, and would be set wrong. Very few system managers really know how many mailboxes a particular process uses, let alone how many is "reasonable". Similarly for network links, files, mapped sections or any of the numerous other consumers of CCBs. It would be just another set of unwanted errors to bump up against.

Quotas really only have one purpose - to prevent accidental or malign consumption of system resources from affecting other processes. For trusted, debugged code they're superfluous.

For most systems CHANNELCNT of 1024 is usually more than adequate. For systems running Advanced Server, Web servers, data bases or other connection intensive software, you may need to increase CHANNELCNT, but rarely over (say) 8192. Most instances of depletion are due to leaks.

[Wim Van den Wyngaert]

John,

Then lets get rid of DIOlimit and so. Nobody needs them. Make it system limits (they almost are because the minimum is defined is sysgen).

My point is that you put all the limits in sysuaf or none. Now they are 90% in sysuaf, 10% in sysgen (or hardcoded ?). But above all, channelcount is a limit that makes fillm incorrect. If I get a fillm of 1000, I don't want channelcnt to appear.

And, if a limit is incorrectly implemented on system level instead of process limit, it should be rewritten.

Wim