Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!tuegate.tue.nl!eba!wjw
From: wjw@eb.ele.tue.nl (Willem Jan Withagen)
Newsgroups: comp.sys.apollo
Subject: Re: DPCI and pty probs.
Keywords: DPCI, OS10.2, pty
Message-ID: <526@eba.eb.ele.tue.nl>
Date: 5 Jun 90 09:40:11 GMT
References: <1990Jun1.145336.424@quintro.uucp>
Sender: wjw@eba.eb.ele.tue.nl (Willem Jan Withagen)
Reply-To: wjw@eb.ele.tue.nl
Followup-To: comp.sys.apollo
Organization: Eindhoven University of Technology, The Netherlands
Lines: 60

In article <1990Jun1.145336.424@quintro.uucp> bep@quintro.UUCP (Bryan Province) writes:
>We have DPCI V5.0 running over ethernet on a DN3000 at SR10.2.  Dterm locks
>up several times a day.  

Well we are running just about the same from DN4500, and with the sam kind of 
luck. ( It also runs on a serial line, this to used pty's. And this also hangs)
As an example, here's a sesion which got hung while executing the dterm_server.
the serial server also uses pty's for its connections:

 1382 ttyp0   S     0:02 dpci_server -netbios dpci1 -line 2 -baud 9600 -retries 100 -signal
 1436 ttyp0   S     0:00 /sys/dpci/dterm_domain /bin/start_csh 1382 sio2 N dpci1 0

You can debug the servers by specifing -debug {1,2,3} and this will give 
you all kinds of info. But the problem here is caused, by starting up the 
/bin/start_csh with something like 'exec /bin/start_csh' and there the server
halts.
If one removes all pty's from /dev, then the server will create a temporary pty
and afterwards this one will be removed. Hence this will "always" work.

Just for those intrested: I've also booted a server on an DN4000 running OS9.7
and that works without any problems, except that it's a little slower.
But dterm does not hang.

I also have another "problem" with the DPCI. The manual says that for all
communication versions you can load the network software in EMS. 
( except for the DPCI1 version, which I desprately need ), but the DPCI501
version complains that the -ems switch is not known, even if it's used as the
first switch. 

Questions to those at Apollo: 
    1)	Why is there no -ems for the DPCI1. It should not
	be too hard. since the ones with dpciring and dpci503 DO have this 
	working.
    2)	When is the limit on 63 processes abandoned, since we quite often
	run out of processes. ( Every DPCI uses 2-5 processes )
	I know that it's a promisse in OS10.3, but when is that going to be
	released, and (more inportant:) shipped.
    3)  Why is it so hard to fix something so essential?
	I know it's the wrong question from the problem side, but
	seen from my ( and others ) side it's the right question. We're 
	going to invest more in the DPCI when and if the pty problem is
	fixed. But I don't like to be naged by users, wanting to get new
	pty's since the old ones are "used up".
	Not only the DCPI suffers, but more essential are the TCP programs
	which get messed up.

So far there have been only two DPCI users on the net. Are there any more
out there, and are you happy??

Greetings,


	Willem Jan Withagen               

Eindhoven University of Technology   DomainName:  wjw@eb.ele.tue.nl    
Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET
P.O. 513                             Tel: +31-40-473401
5600 MB Eindhoven                 
The Netherlands