Problems with Sun OS 3.5 UUCP/news

[Jim Burwell]

I'm having some strange problems with a Sun 3/160 running Sun OS 3.5/BSD4.3
Bnews 2.11...

We have a genuine Hayes 2400 on cua0 and a Concord 224E on cua1..  We are on
PBX system, and dial out over the Federal Telephone System.  There are several 
problems:


(1.) When a dialout or dialin is done at a specific baud rate, the modem stays
	locked at that baud rate.  We have several people who call in at 1200
	baud on both lines, and one uucp account we feed at 1200.  After the
	session is over, the modem remains at 1200 baud, not allowing anyone to
	dialin again at 2400.

(2.) The Concord line always answers with some garbage (usually the ascii
	string "20" + some \n's), and the "Password:" prompt.  I assume this
	is because getty() is getting modem status strings from the Concord,
	such as "RING", "CONNECT ####", and so forth.  I know the AT commands
	to shut this stuff off, but I have no idea how to make the system
	automatically initialize the modem with this command at startup and
	user logoff.  If I could get the OS to send an init string, I could
	probably solve this problem, and the problem in #1, assuming it would
	let me send the string at 2400 baud.

(3.) For some reason, uucico on our system REFUSES to receive a binary,
	16 bit compressed file.  The system batching our news must use the -C7
	option of sendbatch to encode the file in 7 bit ASCII type format,
	otherwise, uucico chokes on the news-batch with a FAILED (conversation
	complete).  I can't really figure this out, since our system seems
	to be able to SEND 8 bit data fine.  I have a node off of this system
	which gets it's news in 16 bit compressed format, and I have no
	problems.  I also just sent a 16 bit compressed file (uucp) to the
	system we are having trouble with, and THAT even worked..  The only
	thing that I can think of at the moment which would cause this problem
	is a modem connection which is using parity.  Our system is set up to
	use 7E1 at login.  I don't know if uucico changes the serial port
	options or not, but if it doesn't, parity (or the expectation of 
	parity) would mess up a g-protocol transfer fast :-).  Of course, this 
	doesn't make sense, since we seem to be TRANSMITTING with no problem.. 
	Perhaps this serial port can be configured to send w/o parity, and 
	receive with it? naahh..  BTW, just recieved a 16 bit compressed 
	binary file via UUCP back from the system were having trouble 
	communicating with..  No problem.  What is going on here?  It only 
	chokes on news?  This is bizarre! :-)


If anyone has any ideas or help, please get back to me via E-Mail.. I'll post
a summary if there is "suitable interest"...

Thanx,
Jim "the padded cell beckons" Burwell <grin>

jimb at faatcrl.UUCP