[comp.sys.hp] Callback on HP 9000/380

hendri@math.utwente.nl (Hendri Hondorp) (06/18/91)

Hello World,

Our system:	HP 9000/380 with 18 discless cnodes (9000/340) and
		10 X-terminals and a lot of PC's.
Our O.S:	HP-UX 7.05.
Subject:	Callback procedure.

We want to make a callback procedure for our users. A modem (Discovery
9632AM Intelligent Modem, 300-9600 Baud, Hayes-compatible) is connected 
to the built-in RS-232 interface.

We have made the following:
a.	uugetty is running on the modem-port tty09 (via inittab):
crw--w--w-   1 uucp     users      1 0x090010 Jun 17 15:49 /dev/tty09

b.	when users are logging in, a program asks them for a password 
	and (when correct) a background process calls the user back
	with ct. (The telephone number is stored in a file which looks
	like /etc/passwd).
	Ct uses cua09 or cul09:
crw-rw-rw-   1 root     other      1 0x090011 Jun 17 13:24 /dev/cua09
crw-rw-rw-   1 root     other      1 0x090011 Jun 17 14:45 /dev/cul09

In the manual page uugetty (1M) is a little line with the text: "Ct will
not work when uugetty is used with an intelligent modem such as a Penril
or a Ventel". So we have a problem.
After the whole procedure (login and callback) the modem is NOT correct 
configured and a new user cannot call the 380 again.  One of the things that 
happened is that the TR (Terminal Ready) led was out. I've found some code 
in C-kermit to hangup a modem with HP-UX:

	int ttyfd;
	unsigned long dtr_down = 00000000000,
			modem_rtn;

	ttyfd = open(device, O_RDWR | O_NDELAY);
	if (ttyfd < 0)
	{
		return(1);
	}
        if (ioctl(ttyfd,MCSETAF,&dtr_down) < 0) /* lower DTR */
	{
		return(1);
	}
        msleep(500);
        if (ioctl(ttyfd,MCGETA,&modem_rtn) < 0) /* get line status */
	{
		return(1);
	}
        if ((modem_rtn & MDCD) != 0) /* check if DCD is low */
	{
		return(1);
	}
        modem_rtn = MRTS | MDTR;       /* bits for RTS & DTR  */
        if (ioctl(ttyfd,MCSETAF,&modem_rtn) < 0) /*  set lines  */
	{
		return(1);
	}
        close(ttyfd);		/* close/reopen file descriptor */

	and this works fine but now the new user must call the 380 two
	times before (s)he's is connected to the machine.

My questions are:
a.	why can't we use uugetty and ct ? Uugetty is simular to getty
	except that uugetty supports using the line in two-directions.
	(in/outcall). What's the problem and is it possible to repair
	it (like I tried, but failed (?)).

b.	Are there more HP 9000/3xx systems configured with a callback 
	procedure and how did they do it ?

c.	Who knows a program for a callback procedure ?


Thanks for reading this and have a nice day.

Greetings from,

	Hendri Hondorp 			Fax    : +31 (53) 35 6695  		
	University of Twente, 		Tel    : +31 (53) 89 3377 	
	dep. Appl. Mathematics,		E-mail : hendri@math.utwente.nl
	Enschede 			UUCP   : ..!hp4nl!utrcu1!utmfu0!hendri 
	The Netherlands.

wehr@fmsrl7.UUCP (Bruce Wehr ) (06/20/91)

hendri@math.utwente.nl (Hendri Hondorp) writes:
> a.	uugetty is running on the modem-port tty09 (via inittab):
> crw--w--w-   1 uucp     users      1 0x090010 Jun 17 15:49 /dev/tty09
> 
> 	Ct uses cua09 or cul09:
> crw-rw-rw-   1 root     other      1 0x090011 Jun 17 13:24 /dev/cua09
> crw-rw-rw-   1 root     other      1 0x090011 Jun 17 14:45 /dev/cul09
> 
> My questions are:
> a.	why can't we use uugetty and ct ? Uugetty is simular to getty
> 	except that uugetty supports using the line in two-directions.
> 	(in/outcall).

    I'm not sure why uugetty doesn't work, but I *do* know that it's
    unnecessary. HP's terminal driver has port access interlock
    mechanisms built in to handle shared incoming and outgoing
    processes. Bit 0 of the minor number controls this, and you have
    them configured correctly (what's bit 4 for, BTW?).

> b.	Are there more HP 9000/3xx systems configured with a callback 
> 	procedure and how did they do it ?

    At my previous position, I configured a 9000/375 just the way you
    did (with a TrailBlazer), except we just used a regular getty.
    Users would just use ct directly - some created a shell script with
    all their appropriate parameters (one user named his et - for
    'phone home' :-)

    Anyway, I hope this helps.

-- 
               Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com)
                (..!uunet!srlvx0.srl.ford.com!wehr%dptc.decnet)
              Ford Motor Company - Engineering Technology Services
     P.O. Box 2053, Room 1153, Dearborn, Michigan 48121-2053 (313)337-5304