Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problems accessing /dev/term/00 (COM1) in SCO UnixWare 7.1

2 views
Skip to first unread message

Ernest Evans

unread,
Nov 30, 1999, 3:00:00 AM11/30/99
to
Greetings,

I'm trying to do some basic serial port access work on my SCO Unix box and
I'm getting no where fast.

This system is a Pentium III 400 with 256 MB and UnixWare 7.1.

I have an application that needs to access COM1, so I went into the scoadmin
tool, brought up the Serial Manager and enabled COM1 as a software
controlled serial port running at 9600 baud, 8 bits no parity, 1 stop bit,
with data set for both incoming and outgoing.

After I did this, SCO indicated the proper term name to use was
/dev/term/00s.

So, I wanted to test and make sure everything was working properly, so I
hooked up a Null-modem cable to the serial port on the Unix box and plugged
the other into the serial port of a PC. On the PC I brought up
Hyperterminal and set it up with the same settings to wait for data from the
Unix box.

I then went to my command line on the Unix box and echoed a string of
characters to the device:

# echo "test string" > /dev/term/00s

I expected "test string" to pop up on my Hyperterminal window on the PC, no
dice, I got nada, zip. In fact the Unix command line did not return until I
hit Ctrl-C, and then it returned with an error:

Unable to create device /dev/term/00s

Now I know the device exists, and UnixWare seemed to have no problems, but
I'm getting no where. I looked on the SCO website but none of the technical
articles addressed the problem I'm encountering.

Are there other things I need to do to the serial port to make it
accessible?

Note, I have already instead a serial port server on this system, and they
all work fine (all 8 ports), but I hadn't enabled the COM1 port until
recently. I expected the built in COM port to work as easily as a third
party serial port server, but maybe I'm mistaken.

Any help would be appreciated.

Thanks

Ernest Evans
ejev...@gte.net
Technical Lead: Globalsoft LLC


Roberto Zini

unread,
Nov 30, 1999, 3:00:00 AM11/30/99
to Ernest Evans

All releases of UnixWare 7 issued so far have a bug in the serial
driver which prevents the COM ports from being used unless you cross
pins DCD and DTR on the UnixWare side of the connection; this has been
confirmed by SCO and a patch is in progress (I've tested a beta copy
of the patch and the problem seems fixed now). In the meantime,
if you want to access a UnixWare 7 system via an enabled serial port,
make sure you build a cable with DCD and DTR pins crossed (UnixWare
side) and you'll be fine.

Hope this helps !

Best,
Roberto

--
---------------------------------------------------------------------
Roberto Zini email : fr...@strhold.it
Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)

swe...@scruznet.com

unread,
Nov 30, 1999, 3:00:00 AM11/30/99
to

If you really don't want to have the terminal enabled, in the long run,
the correct port to use is /dev/term/00t. This part should work
regardless of any other bugs or crossing of pins. But in general,
anything having to do with serial ports, is buggy.

-sw

Jean-Pierre Radley

unread,
Dec 1, 1999, 3:00:00 AM12/1/99
to
Roberto Zini opined (on Tue, Nov 30, 1999 at 08:56:16AM +0100):

|
| All releases of UnixWare 7 issued so far have a bug in the serial
| driver which prevents the COM ports from being used unless you cross
| pins DCD and DTR on the UnixWare side of the connection; this has been
| confirmed by SCO and a patch is in progress (I've tested a beta copy
| of the patch and the problem seems fixed now). In the meantime,
| if you want to access a UnixWare 7 system via an enabled serial port,
| make sure you build a cable with DCD and DTR pins crossed (UnixWare
| side) and you'll be fine.


I was promised at a Quarterly Business Briefing after SCO had bought
UnixWare from Novell, but before UW 7 appeared, that ttymon was great,
that it worked, and that I had nothing to fear in losing the familiar
OSR vocabulary for dealing with serial ports.

I won't embarass the SCO executive who said this by naming names, but
several years later, I'm still waiting for the fulfilment of that
promise.

--
JP

Tony Lawrence

unread,
Dec 1, 1999, 3:00:00 AM12/1/99
to
Jean-Pierre Radley wrote:

> I was promised at a Quarterly Business Briefing after SCO had bought
> UnixWare from Novell, but before UW 7 appeared, that ttymon was great,
> that it worked, and that I had nothing to fear in losing the familiar
> OSR vocabulary for dealing with serial ports.
>
> I won't embarass the SCO executive who said this by naming names, but
> several years later, I'm still waiting for the fulfilment of that
> promise.


ttymon is a good idea (it's entirely analagous to inetd and
it's good for the same reasons that inetd is) that was
flawed by incredibly clumsy semantics. The person that
wrote that puppy is definitely disturbed.

I keep telling myself that it's easy enough to write
enable/disable commands that will actually execute the
appropriate ttymon garbage, and it is, but it would also be
very easy for SCO to add that to the real enable/disable,
perhaps with a inittab.conf file that could even recognize
old /etc/conf/init.d files and produce correct output. It
really shouldn't be a big deal to do, and it really NEEDS to
be done.

The other stupidity about the wiring issues on serial ports
goes right back to Unixware 2 and it pissed me off then as
much as it does now :-)

--
Tony Lawrence (to...@aplawrence.com)
SCO articles, help, book reviews, tests,
job listings and more : http://www.ApLawrence.com

swe...@scruznet.com

unread,
Dec 1, 1999, 3:00:00 AM12/1/99
to
Tony Lawrence <to...@aplawrence.com> wrote:

> I keep telling myself that it's easy enough to write
> enable/disable commands that will actually execute the
> appropriate ttymon garbage, and it is, but it would also be
> very easy for SCO to add that to the real enable/disable,
> perhaps with a inittab.conf file that could even recognize
> old /etc/conf/init.d files and produce correct output. It
> really shouldn't be a big deal to do, and it really NEEDS to
> be done.

Theoretically, I was toying with the idea of getting
getty/login/enable/disable and related utils from some other OS
and porting it to UW7. I didn't put a whole heck of a lot
of thought into it, but I think it would be doable. Fortunately,
I don't have UW7 machine to mangle.

-sw

Roberto Zini

unread,
Dec 2, 1999, 3:00:00 AM12/2/99
to
Jean-Pierre Radley wrote:
>
> Roberto Zini opined (on Tue, Nov 30, 1999 at 08:56:16AM +0100):
> |
> | All releases of UnixWare 7 issued so far have a bug in the serial
> | driver which prevents the COM ports from being used unless you cross
> | pins DCD and DTR on the UnixWare side of the connection; this has been
> | confirmed by SCO and a patch is in progress (I've tested a beta copy
> | of the patch and the problem seems fixed now). In the meantime,
> | if you want to access a UnixWare 7 system via an enabled serial port,
> | make sure you build a cable with DCD and DTR pins crossed (UnixWare
> | side) and you'll be fine.
>
> I was promised at a Quarterly Business Briefing after SCO had bought
> UnixWare from Novell, but before UW 7 appeared, that ttymon was great,
> that it worked, and that I had nothing to fear in losing the familiar
> OSR vocabulary for dealing with serial ports.
>
> I won't embarass the SCO executive who said this by naming names, but
> several years later, I'm still waiting for the fulfilment of that
> promise.
>

We're on the same boat, but I think we're going to see the light
at the end of the tunnel (or is it an incoming train ? :-) During
these days I've tested the beta patch related to the serial port
problems first issued when UW 7.0.0 came out; the patch seems to
work fine (uhm, except for the fact that when logging in by using
a 38400 bps serial terminal I see garbage depicted on the screen and
I'm unable to reach the login prompt, session frozen). Apart from
these little issues, the patch seems to do its work as expected.

But this could arise another off-topic question; I see lot of
potentials under UnixWare 7, which perhaps will make it a
top-notch operating system in the future. But presently
speaking, I think it's still a non-mature OS (just try
by bringing it to single user level and back to multi
user to see); not to mentions approx 35 patches released
for it, with some reaching revision level "L" (starting
from "A"). Also, considering that UnixWare 7 is meant to
be the mixing of OpenServer 5 and UnixWare 2, I'd like to
see more "friendly" OpenServer 5 feature, such as divvy
(instead of the vtoc), the ability to add several
filesystems on a spare partition on your first disk,
getty (which actually does exist under UW7 but it's a
link to ttymon) and so on.

Just my 2 cents,

0 new messages