no PCB available, but MAXPROCESSCNT is high enough

[Carleen Nutter]

MAXPROCESSCNT=600, BALSETCNT=598, but once 487 processes were active, new login attempts (via Multinet Telnet) generated "no PCB available" error messages.
Is there another sysgen parameter that is comming into play?

[Richard Whalen]

What version of VMS?

More recent versions of VMS have moved PCBs into S2 space.

[Carleen Nutter]

Node is AlphaServer ES45 with 4 cpus, 16 GB memory and running VMS 7.3-2 and Multinet 4.4a.

[Richard Whalen]

I checked my information from Bootcamp 2006 and it was the swap slots that moved to S2 space in 7.3-2. This made the process headers smaller and process headers are now smaller so there is less penalty for having a large balsetcnt.

MultiNet telnet (server) creates a network terminal and causes loginout to run on it. So I would not expect the problem to be MultiNet related.

Is it possible that you are running up against CHANNELCNT?

[Hoff]

If you can reproduce this behavior, then try a parallel log in attempt over DECnet, LAT, or the serial console. This in an attempt to differentiate OpenVMS from Multinet as the trigger.

There were some wrinkles around larger unit numbers; Rich W. would know of Multinet ran afoul of those. There is a case where LOGINOUT slams into the larger unit numbers, and this did derail TCP/IP Services and telnet access.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1074590

[Ian Miller.]

does multinet telnet have a service limit?

[Carleen Nutter]

Thanks for the answers so far. As far as I know there is no telnet limit for multinet.
I'll dig a bit deeper - but sounds like I didn't miss something totally obvious.

[Jeff Chisholm]

There's a cell in memory, PMS$GL_PROCCNTMAX which stores the maximum number of observed processes on the system, since the last boot. I'm thinking you're not seeing the whole picture, are overlooking some processes. The -F-NOSLOT error is quite specific, you are out of entries in the process entry slot table.

[Richard Whalen]

I'm not aware of any limits to the unit numbers in MultiNet. Trying alternate methods of logging in when it happens is a good idea to determine if it is a MultiNet problem or a VMS problem.

[Jim_McKinney]

If you haven't already done so, you should confirm that the system agrees with your estimation of the maximum concurrent processes observed (as Jeff Chisholm previously suggested). Either use SDA to look where he suggests or do the following

$ mcr agen$feedback -write_feedback
$ search sys$system:agen$feedback.dat proc

and see things from VMS' perspective.

[Carleen Nutter]

Jeff and Jim are correct - I was not seeing the whole picture. Since the estimated maximum number of processes was calculated was based on activity several months ago, a number of detached processes had been created by printer symbionts and interfaces. Additionally, yesterday there was an unusually large number of batch processes submitted to one of the batch queues. I think it was the batch jobs that pushed us over the limit. I'll be increasing the maxprocesscnt by several hundred at the next reboot opportunity.
Thanks all for your help and suggestions.

[Carleen Nutter]

The forum responders confirmed that the error is really related to the maxprocesscnt sysgen parameter. So digging deeper revealed some unusualy high activity and a no-longer-valid assumption about the number of non-interactive processes that must be included in the count.

[Joseph Huber_1]

Just a tip: if really the batch jobs produced too many active processes, then you should review the /JOB_LIMIT settings of the queue(s): even if there is a runaway procedure submitting bactch jobs, it may trouble the batch queue, but not the systems process slots:
without job_limit , users can make (not-intended) denial of service attacks !