I seem to be getting the following error message more and more
frequently lately. This is on D3/NT (7.4.4) using AccuTerm with a nailed
port.

*** Nailed port 2050 failed to connect: PIB 50 already active ***

I am talking about responsible users who log off properly every night,
yet the next morning their nailed port is stuck.

I try LOGOFF from another terminal (numerous times), which either tells
me the line was logged off successfully, or it tells me the line has
failed to respond. I try RESET-USER, which also doesn't help. The only
thing that helps is a shutdown and restart of D3.

Is anyone else having this problem? Any solutions?

Sholom

Are you doing anything with DCD?

In the cold start macro include:
trap dcd exit

During the login process for each telnet port, include:
EXECUTE "DCD-ON"
EXECUTE "XONOFF (F"

For serial ports include:
EXECUTE "DCD-OFF"


This is working for us.


"SH" <shamada (AT) prupipe (DOT) com> wrote

Questions:
1) How many pibs on the system
2) what's the where status of port 50 when this happens
3) what's the lu or who show for port 50 when this happens
4) Does this only happen in the morning, or does it happen later in the
day if they've been logged of for a while
5) Are all the users "nailed" or do some come in uncontroled
6) Does it always happen to the same port, or does it happen to various
pibs?

Mark Brown

"SH" <shamada (AT) prupipe (DOT) com> wrote

36 active people, but there are 113 pibs defined in the pibs file in DM

It doesn't show in the WHERE command at all

Nothing. Doesn't exist

Hard to say. I get complaints in the morning, and I get complaints in
the afternoon. So I guess it does happen during the day.

We use a mix of AccuTerm and Wintergrate. Since I can't nail a port in
Wintegrate, I reserve all ports from 0-30 for Wintegrate users. I then
nail all AccuTerm users above port 30.

Various pibs.

Thanks for your interest and advise.

I'm going to try Jeffreys idea tonight (hopefully), but I would like to
hear any other peoples ideas as well.

Maybe port 2050 actually is active. When you install PC's, do you
copy the Accuterm .ATLY and/or .ATCF files from other PC's? Maybe you
have two .ATCF files that tell two workstations to connect on the same
nailed socket port 2050.

<grabbing at straws on this one>
Also, the system uses ports down in that range for outbound
connections. So if you use the browser on your D3 server and then
boot D3, port 2050 or some others in there might be temporarily
occupied, and the port initialization might fail. Rebooting D3 would
work because the port is not occupied the second time around.
</>

Maybe I'm just overly cautious but I recommend against using IP Ports
down in the 2050 range. According to my \etc\services file, ports
2049 and 2053 are defined for other purposes. You probably won't have
a port conflict with other software, but why ask for trouble?
Anything from 10000 to 64000 is relatively safe, try 21050, etc...

Finally, if a plain logoff doesn't work, try "logoff (k" - I don't
know exactly what it does these days but I believe it does a much
lower-level reset than the standard logoff which just operates at the
user workspace level. Actually I believe standard logoff actually
escallates itself to do a (k) if it can't kill a port. So many
changes have been made in this area over the years, I have no idea
what they do in there anymore.

I hope something here helps.
T


SH wrote:

Jeffery,

Assuming one or more of the Serial Ports are modems,
do you also set them to DCD-OFF ?

And, of course, Port 0 (zero) on D3/Linux should never do an 'exit',
just OFF.

Dave Weaver, Weaver Consulting


Jeffrey Kaufman wrote:

Correct Dave. Modems and serial printers also should have DCD off and
xon/xoff on. Since that is the inittab default, I did not list them. In fact
I really don't need to execute the DCD-OFF at login either.

You can do an exit on port zero, but then you have to do a d3 -0 to get back
in. As you suggested, it is better to just do an off.

Jeff

"Dave Weaver" <weaver22 (AT) pacbell (DOT) net> wrote

Sholom:

When you issue a reset-user you might want to use the "(x" option. It is
supposed to delete the underlying NT pib; you can look at the results of
"nt_pinfo" to see the underlying NT pibs.

If the Pib is still active you can issue the "dev-remov p{n}" command where
{n} is the Pib#.

Hope this helps.

Bill

"SH" <shamada (AT) prupipe (DOT) com> wrote

Bill

Just to let you know, your idea worked.

First issue: dev-remov p50
Then issue: dev-make -t telnet -n 50 -a "s,2050"

Thanks alot, guys.

Sholom

Bill H wrote: