tom@hcr.UUCP (Tom Kelly) (08/12/87)
I too have been looking for a way to switch the phone line from
VOICE 1: IDLE to DATA 1 without human intervention. I have discovered
that killing the Phone Manager process (ph) and removing the LCK..ph0
file does the trick, in that uucp will now use the line on demand.
Furthermore, the line is no longer automatically answered.
I would prefer a more elegant way, partly because cu(1) doesn't seem
to work, and I like using the phone manager for terminal emulation
because you can swap between the remote session and a local unix session.
I have been having a few problems with the communications system though,
and if anyone has suggestions or insights, I'll be grateful.
The basic problem is that sometimes the modem seems to get into a strange
state. A symptoms of this state are that when uucp is dialing, I can hear
the dial tone and ringing (as I can when ph is dialing for me). Another,
more serious problem is that the connection is dropped as soon as the
remote site answers (uucp reports LOST LINE, ph reports disconnection).
Sometimes I can clear the condition by toggling between VOICE and DATA
mode. Sometimes that doesn't work, but I can do it by killing ph and
restarting it. Sometimes nothing seems to work short of a reboot (which
so far has always worked).
I have only noticed this with ph running, but haven't run the other
way long enough to say that ph is a contributing factor.
Any advice or comments by mail please to me, and I'll post a summary.
Thanks.
Tom Kelly (416) 922-1937
HCR Corporation, 130 Bloor St. W, Toronto, Ontario, Canada
{utzoo, ihnp4, decvax}!ihnp4!tomrichard@islenet.UUCP (Richard Foulk) (08/15/87)
In article <2772@hcr.UUCP> tom@hcr.UUCP (Tom Kelly) writes: > I too have been looking for a way to switch the phone line from > VOICE 1: IDLE to DATA 1 without human intervention. I have discovered > that killing the Phone Manager process (ph) and removing the LCK..ph0 > file does the trick, in that uucp will now use the line on demand. > Furthermore, the line is no longer automatically answered. > > I would prefer a more elegant way, partly because cu(1) doesn't seem > to work, and I like using the phone manager for terminal emulation > because you can swap between the remote session and a local unix session. > If uucp will use the line okay then cu should also, unless the cu on the 7300 has been modified, which I doubt. Perhaps you just need to change the permissions on the port. cu does allow you to switch between the remote session and local unix processes. To get a local shell just type ~!sh at the beginning of a line. And since the remote half of cu stays connected anything coming from the remote system will show up on you screen while you're in you local shell. So if you make a script or an alias that sends a line of text to the modem port you can alternately command the local and the remote systems from your local shell. You can also use the window system to get a local shell if you prefer playing with windows. The Phone Managers terminal emulator is so slow I can't see how anyone could stand to use it, except maybe at 300 baud. And it seems to have gotten even slower with the new release. -- Richard Foulk ...{dual,vortex,ihnp4}!islenet!richard Honolulu, Hawaii
jbm@uncle.UUCP (John B. Milton) (08/17/87)
I had a problem with my system that might be related. The reason it might be
is that I had to do the line toggle. My problem is mostly that I don't have
two phone lines. I wanted to be able to use data and the phone manager and
the off-hook sensing stuff. What I did was put a Y on my one phone line and
plug one of each leg of the Y into line 1 and line 2. Everything seemed to
work just fine for a while. Then I noticed that one night uucp couldn't get
out. So I tried to do a remote dial terminal emulator. It would kind of go
off for a while, then come back complaining about line problems.
To get out of this situation, I called up the phone manager and switched
voice from line 1 to 2 and back. After that it would work fine for a while.
I would get a dumb look on my face, shrug my shoulders and go on. Then it
would do the same exact thing the next night. What I seemed to track it down
to was ringing. Things would lock up after a ring. It might be that the PC
can't deal with both lines ringing at the same exact time. There might also
be some kind of weird current looping problem that only happens on some
machine/line/connection/switcher/phase-of-the-moon situation. Whatever, I
gave up and moved the Y connection further down. What I have now amounts to
tap. In this setup the PC doesn't know when I pick up the phone. One of these
days I will be able to afford to buy another line.
I hope this is useful to someone.
John
--
John Bly Milton IV {ihnp4|cbosgd}!n8emr!uncle!jbm
(614)294-4823 (home, where the ATT 7300 [uncle] lives)
(614)424-7677 (work, where the HP 9836 lives)dca@kesmai.COM (David C. Albrecht) (08/17/87)
I posted this earlier but I think it fell dead at my doorstep. I hacked something together which provides some of the functionality required to let uucp dial out when required. It does it, however, by leaving the phone line in the switched to data state in the phone manager and then controlling the dial in/out status line from the shell. More specifically it is a routine which wraps around uucico and a set of script files which use phset and a file in /usr/spool/uucp to control the phone line. It is mainly meant for one line systems. Unfortunately, you must reset the line state any time after switching the line around in the phone manager as I never was able to figure out how to trap the exit from the phone manager since it is a global task that just grabs your screen. phconfig basically takes the following options: phconfig -s switch line to outgoing phconfig -r switch line to incoming phconfig -b switch line to bidirectional phconfig -d shut line down phconfig -o system outgoing until communication to system is successful then shut down line. If I ever figure a good place to put it there is a second shell script (phset) which will reset the line to the state you last put it in after it gets played with by the phone manager. If there is any interest I will post the various pieces parts that make these utilities up. Dave Albrecht
mhw@ihlpf.ATT.COM (Marc Weinstein) (08/18/87)
in article <2772@hcr.UUCP>, tom@hcr.UUCP (Tom Kelly) says: > > I too have been looking for a way to switch the phone line from > VOICE 1: IDLE to DATA 1 without human intervention. I have discovered > that killing the Phone Manager process (ph) and removing the LCK..ph0 > file does the trick, in that uucp will now use the line on demand. > Furthermore, the line is no longer automatically answered. > > I would prefer a more elegant way, partly because cu(1) doesn't seem > to work, and I like using the phone manager for terminal emulation > because you can swap between the remote session and a local unix session. > If you get the latest version of the phone manager (3.5.1), it comes with a program called phtoggle, which toggles the line from VOICE to DATA. I have set up cron jobs to do this at certain times of the day and all the systems which talk to mine have Systems entries which correspond to these times. Uucp will basically wait until the line has been set to DATA, which isn't all bad. If you really want something to go out, I typically queue up a bunch of stuff and then do a Uutry to the system I'm interested in (after toggling the phone line). You can also set up a job (perhaps in cron) or a shell which you can execute at will to first toggle the line, then do a uucico (or cu), then toggle the line back. > The basic problem is that sometimes the modem seems to get into a strange > state. A symptoms of this state are that when uucp is dialing, I can hear > the dial tone and ringing (as I can when ph is dialing for me). > > Sometimes I can clear the condition by toggling between VOICE and DATA > mode. Sometimes that doesn't work, but I can do it by killing ph and > restarting it. Sometimes nothing seems to work short of a reboot (which > so far has always worked). > Several of us have seen this problem (or a similar problem). The most bothersome effect is that the modem refuses to answer, even in DATA mode. I think it might involve a situation where the OBM is attempting to call another system when a call comes in. I think it gets confused and the modem and/or the getty do not get reset correctly. I've noticed the same thing with toggling VOICE to DATA and back - it seems to clear the problem most of the time. Have you called the hotline?? There may be a fix available... Marc Weinstein Bell Labs - Indian Hill, Naperville, IL ihnp4!ihlpf!mhw
lenny@quincy.UUCP (Lenny Tropiano) (08/19/87)
In article <137@kesmai.COM>, dca@kesmai.UUCP writes: | [... stuff removed for brevity ...] | | phconfig -s switch line to outgoing | phconfig -r switch line to incoming | phconfig -b switch line to bidirectional | phconfig -d shut line down | phconfig -o system outgoing until communication to system is successful | then shut down line. | | If I ever figure a good place to put it there is a second shell | script (phset) which will reset the line to the state you last | put it in after it gets played with by the phone manager. | | If there is any interest I will post the various pieces parts that | make these utilities up. | | Dave Albrecht I am very interested in your phone manager utilities. Please post or mail to my site... Thank you. -Lenny Tropiano -- Lenny Tropiano ...seismo!uunet!swlabs!godfre!quincy!lenny -or- American LP Systems, Inc. ...cmcl2!phri!gor!helm!quincy!lenny 1777-18 Veterans Memorial Hwy. Islandia, New York 11722 +1 516-582-5525
brad@bradley.UUCP (08/23/87)
Yes Please post them... -brad