[comp.unix.xenix] SCO unix 3.2 - modem port name usage

bblue@crash.cts.com (Bill Blue) (04/08/90)

In article <36@mnopltd.UUCP> gatech!stiatl!mnopltd!neal writes:
>tty1A has modem control; tty1a does not.  You want to enable tty1A in the 
>ttys file.   You DO want to specify the terminal type in ttytype as "modem".
>This causes various bits of magic to occur.

What bits of magic, specifically?  Unix only or Xenix too?

--Bill

neal@mnopltd.UUCP (04/08/90)

->In article <36@mnopltd.UUCP> gatech!stiatl!mnopltd!neal writes:
->>tty1A has modem control; tty1a does not.  You want to enable tty1A in the 
->>ttys file.   You DO want to specify the terminal type in ttytype as "modem".
->>This causes various bits of magic to occur.
->
->What bits of magic, specifically?  Unix only or Xenix too?

Oops! I get to correct my own posting!  After this got loose I realized that
the terminal type should be "dialup", NOT "modem".   As far as magic, I noticed
that when the port is enabled or disabled, the revelant dialer program is 
called to poke the modem into or out of auto-answer state.   Beyond that, I 
can't comment except to say the whole thing works properly in a bi-directional
persuasion.   Since ttys/ttytype is a BSD/xenix aberration, this would not
be the case in more formal AT&T (feh!) versions of unix and I can't comment
on SCO Unix.

------------------------------------------------------------------------------
Neal Rhodes                       MNOP Ltd                     (404)- 972-5430
President                Lilburn (atlanta) GA 30247             Fax:  978-4741
       uunet!emory!jdyx!mnopltd!neal Or uunet!gatech!stiatl!mnopltd!neal
------------------------------------------------------------------------------

bblue@crash.cts.com (Bill Blue) (04/09/90)

In article <40@mnopltd.UUCP> gatech!stiatl!mnopltd!neal writes:
>
>->In article <36@mnopltd.UUCP> gatech!stiatl!mnopltd!neal writes:
>->>tty1A has modem control; tty1a does not.  You want to enable tty1A in the 
>->>ttys file.   You DO want to specify the terminal type in ttytype as "modem".
>->>This causes various bits of magic to occur.
>->
>->What bits of magic, specifically?  Unix only or Xenix too?
>
>Oops! I get to correct my own posting!  After this got loose I realized that
>the terminal type should be "dialup", NOT "modem".   As far as magic, I noticed
>that when the port is enabled or disabled, the revelant dialer program is 
>called to poke the modem into or out of auto-answer state.   Beyond that, I 
>can't comment except to say the whole thing works properly in a bi-directional
>persuasion.   Since ttys/ttytype is a BSD/xenix aberration, this would not
>be the case in more formal AT&T (feh!) versions of unix and I can't comment
>on SCO Unix.

I thought this might be what you were hinting at.  In my experience
with Xenix, the terminal type specified in ttytype has nothing to do
with bi-directional operation, only with the default terminal type
that may be associated with that port, and then only if you use tset
creatively in your .profile or .login.  True bi-directional port
operation is more or less automatic when the port is enabled and then
used for outgoing traffic.

---

One really interesting Xenix behavior I've noticed with bi-directional
ports and never seen discussed anywhere is that the modem turnaround
(dial -h or equivalent) that resets the modem for dial-in operation
after a call has completed, is sensitive to entry placement in the
Devices file.  It seems that you must place the major (modem control)
device entry (ACU entry) before the minor (no modem control) entry for
the same device if you have both entered in the file.  For example:

	ACU tty1A - 2400-19200 dialHA24
	Direct tty1a - 1200-19200 direct
	ACU tty2A - 1200-4800 dialHAHST
	Direct tty2a - 2400-19200 direct

If the Direct entry is not there for that device, it will reset normally
at call completion.  Likewise if it appears AFTER the ACU entry.  But
if you place the Direct entry first:

	Direct tty1a - 1200-19200 direct
	ACU tty1A - 2400-19200 dialHA24

the modem turnaround will not occur.  Everything else will appear to
function normally.

Anyone know why this is?

--Bill