Help With AmigaUW
Cary @ Vanderbilt Math Dept
thought I'd post a message here for some help in getting it to
work. After trying to compile it on this Ultrix system and having
it fail everytime, he mailed me with the answer to my woes...
There is a "CFLAGS=" line in the makefile that basically
UNdefines any of the CFLAGS=xxxx lines you might uncomment.
Comment out the CFLAGS=<nothing> line to keep it from doing
this. Now then, I've gotten it compiled cleanly and am ready
to try it out. Run uwserverd in 8-bit mode on the Amiga and fire
up Term using uw.device unit 0.. dial into the Unix and run auw
in 8-bit mode. Fire up another Term using uw.device unit 1, it
works! But.. Both term windows have the same thing in them!
I'm typing this message on the top window (both using Workbench
as a public screen) and what I type in one appears on the other.
I'm obviously doing something wrong... The docs are very scarce,
and using Unit 1 whether it's wrong or right was totally a guess
on my part. I didn't see any reference as to how to start up
the second session in the docs at all...
As always, any and all help will be greatly appreciated!
Mark Johnson (JIAFS)
I am using it to call up the mainframe at work from home. The dialer dials
the number fine, but when the mainframe answers the line and the modems
connect, the dialer does not exit. The countdown timer continues, and if
left alone, will eventually timeout and reset the line. I can exit the
dialer by clicking on the exit button and I will be connected to the system,
but then my console definition and macros aren't loaded. I haven't had
this problem dialing any other system...this one seems to answer the line
and connect to my modem faster than the others.
Can anyone give me any suggestions??? I am running it on an A3000, with a
Supra 2400 modem, if this helps...
Thanks,
Mark
BTW, I also tried using JR-Comm with this number. It worked fine...however,
I like Terminus much better (aside from this one quirk)!
----
--
: Mark Johnson : "He tried to : /// AMIGA: :
: mjoh...@vab02.larc.nasa.gov : kill me with a : /// The computer :
: NASA-Langley Research Center : forklift..." : \\\ /// for the :
: THESE ARE MY OPINIONS! MINE! : - MST3000 : \\\// creative mind:
Stefan G. Berg
> in 8-bit mode. Fire up another Term using uw.device unit 1, it
> works! But.. Both term windows have the same thing in them!
> I'm typing this message on the top window (both using Workbench
> as a public screen) and what I type in one appears on the other.
> I'm obviously doing something wrong... The docs are very scarce,
> and using Unit 1 whether it's wrong or right was totally a guess
> on my part. I didn't see any reference as to how to start up
> the second session in the docs at all...
Aha! (as a German would say :) You just detected a hidden feature in
Amiga UW. Actually you are supposed to _always_ use uw.device unit 0.
I have heard that Term and older versions of Terminus have a problem
with opening the same device and unit number multiple times, but I
have been doing this on Terminus 2.0a many times already and there is
no problem.
If you use uw.device unit 1, then you are opening something like a
triple connection. This is not mentioned in the docs, but there are
some neat things you can do with it. For one you can go with one
Terminus session into hex mode and disable zmodem auto detection. Then
start a zmodem download. The Terminus session with hex modem will not
accept the download, but the other session will. So you end up
downloading a file and you can monitor all the data going through your
line on the Terminus session using the hex output.
Stefan
--
,-------------------------------------------------------,
|Usenet sgb...@charon.bloomington.in.us Stefan G. Berg|
|Internet sgb...@ucs.indiana.edu MetaMail // AMIGA |
|Bitnet sgberg@iubacs GE Mail s.berg5 \X/ w/ bms |
`-------------------------------------------------------'
Charles E Rick Taylor IV
>In article <27gj70$s...@perot.mtsu.edu> cct...@perot.mtsu.edu (Cary @ Vanderbilt Math Dept) writes:
>> in 8-bit mode. Fire up another Term using uw.device unit 1, it
>> works! But.. Both term windows have the same thing in them!
>> I'm typing this message on the top window (both using Workbench
>> as a public screen) and what I type in one appears on the other.
>> I'm obviously doing something wrong... The docs are very scarce,
>> and using Unit 1 whether it's wrong or right was totally a guess
>> on my part. I didn't see any reference as to how to start up
>> the second session in the docs at all...
>Aha! (as a German would say :) You just detected a hidden feature in
>Amiga UW. Actually you are supposed to _always_ use uw.device unit 0.
>I have heard that Term and older versions of Terminus have a problem
>with opening the same device and unit number multiple times, but I
>have been doing this on Terminus 2.0a many times already and there is
>no problem.
Another things ... make sure you're *not* using owndevunit.device ...
I had forgotten it was installed on my VLT and had a similar problem
as you describe above. Oddy enough, I could resolve it by opening
unit 1 then switching to unit 0 within VLT until I traced the problem
to owndevunit. Remove that, and it worked fine. Maybe worth a
notation in the docs.
>If you use uw.device unit 1, then you are opening something like a
>triple connection. This is not mentioned in the docs, but there are
>some neat things you can do with it. For one you can go with one
>Terminus session into hex mode and disable zmodem auto detection. Then
>start a zmodem download. The Terminus session with hex modem will not
>accept the download, but the other session will. So you end up
>downloading a file and you can monitor all the data going through your
>line on the Terminus session using the hex output.
--
+ Rick __ + MAIL:cha...@hubcap.clemson.edu + Atari 2600,TG16 + Sonic is +
| /aylor | cha...@eng.clemson.edu | Sega,SNES,A3000 | my roll |
+-------------+---------------------------------+-----------------+ model... |
+ "Every Girl Already Has A Boyfriend" --- Murphy's Law Of Dating +----------+
Stefan G. Berg
>
> Another things ... make sure you're *not* using owndevunit.device ...
> I had forgotten it was installed on my VLT and had a similar problem
> as you describe above. Oddy enough, I could resolve it by opening
> unit 1 then switching to unit 0 within VLT until I traced the problem
> to owndevunit. Remove that, and it worked fine. Maybe worth a
> notation in the docs.
I didn't have any problems with the owndevunit. All I did was call the
uwserverd with lockserial, like this:
RUN >NIL: <NIL: UUCP:c/LockSerial "uwserverd -s -m"
That will basically keep the serial port reserved for uw as long as
the server is running.
Colin Stuckless
>In article <27gj70$s...@perot.mtsu.edu> cct...@perot.mtsu.edu (Cary @ Vanderbilt Math Dept) writes:
>> in 8-bit mode. Fire up another Term using uw.device unit 1, it
>> works! But.. Both term windows have the same thing in them!
>> I'm typing this message on the top window (both using Workbench
>> as a public screen) and what I type in one appears on the other.
>> I'm obviously doing something wrong... The docs are very scarce,
>> and using Unit 1 whether it's wrong or right was totally a guess
>> on my part. I didn't see any reference as to how to start up
>> the second session in the docs at all...
>Aha! (as a German would say :) You just detected a hidden feature in
>Amiga UW. Actually you are supposed to _always_ use uw.device unit 0.
>I have heard that Term and older versions of Terminus have a problem
>with opening the same device and unit number multiple times, but I
>have been doing this on Terminus 2.0a many times already and there is
>no problem.
The problem is that Term is using OwnDevUnit.library to take full
control of unit 0 of uw.device. I don't think there is a way to turn
this off within Term itself. So, what I did was just renamed
OwnDevUnit.library to DontOwnDevUnit.library :-)
Reboot, start up Term, and everything works fine. I agree that the
docs for uw.device are a little vague, so here's a step by step
procedure. Hope this is of some help. If you want to bug the author
about it, drop by IRC channel #amiga, and talk to Ezy :-)
1. Compile auw on your Unix machine.
2. Copy uw.device to your devs: directory on your Amiga
3. Start uwserverd on your Amiga. (run uwserverd -m)
-m gives an 8-bit connection. If this doesn't work, try it without
the "-m". Also, if you use a device other than serial.device in
your term prog, type "run uwserverd -D <device_name> -m". For
example, I do "run uwserverd -D gvpser.device -m".
4. Load up your terminal program. Go into the serial preferences of
your Terminal program and change the device it's using to be "uw.device".
5. Dial your unix machine, and login as normal.
6. Start auw (the program you compiled) on the Unix machine. Use "auw -m"
if you're using an 8-bit connection.
7. Now, load up another copy of your terminal program, select uw.device and
the same unit number (0), and you have another login.*
* If it says something to the effect of "uw.device unit 0 already in use by
program <whatever>", then make sure OwnDevUnit.library in your libs:
directory is either renamed to something else, or moved to a different
directory (so your terminal program won't use it). You will have to
reboot or flush the lib from ram in order for it to not be controlling
the term program.
If you have problems compiling the auw program on Unix, I suggest you
contact the author. I believe he's in the process of making the unix
makefile a bit easier for people who don't know much about makefiles :-)
Hope this helps. It's really a wonderful device, I can now download and
still do other things over a single connection.
>Stefan
>|Usenet sgb...@charon.bloomington.in.us Stefan G. Berg|
>|Internet sgb...@ucs.indiana.edu MetaMail // AMIGA |
>|Bitnet sgberg@iubacs GE Mail s.berg5 \X/ w/ bms |
Colin Stuckless
col...@cs.mun.ca
colins on IRC
Charles E Rick Taylor IV
>In article <1993Sep19.2...@hubcap.clemson.edu> cha...@hubcap.clemson.edu (Charles E "Rick" Taylor IV) writes:
>>
>> Another things ... make sure you're *not* using owndevunit.device ...
>> I had forgotten it was installed on my VLT and had a similar problem
>> as you describe above. Oddy enough, I could resolve it by opening
>> unit 1 then switching to unit 0 within VLT until I traced the problem
>> to owndevunit. Remove that, and it worked fine. Maybe worth a
>> notation in the docs.
>I didn't have any problems with the owndevunit. All I did was call the
>uwserverd with lockserial, like this:
>RUN >NIL: <NIL: UUCP:c/LockSerial "uwserverd -s -m"
>That will basically keep the serial port reserved for uw as long as
>the server is running.
Yes, but for those of us who don't have "lockserial" (what's that
anyhow?), owndevunit causes problems. I was just pointing out a
simple solution (i.e. don't use it. :) )
Point: Mention of "lockserial" as a way of calling uwserverd isn't in
the docs, nor is mention of problems with "owndevunit". Maybe we
shoudl write the author and let him know of these problems/fixes so he
can incorporate them in the docs. (Now where's that archive w/his
email address...)
Osma Ahvenlampi
--
Osma Ahvenlampi - oahv...@snakemail.hut.fi
Stefan G. Berg
> sgb...@charon.bloomington.in.us (Stefan G. Berg) writes:
>
> >In article <1993Sep19.2...@hubcap.clemson.edu> cha...@hubcap.clemson.edu (Charles E "Rick" Taylor IV) writes:
> >>
> >> Another things ... make sure you're *not* using owndevunit.device ...
> >> I had forgotten it was installed on my VLT and had a similar problem
> >> as you describe above. Oddy enough, I could resolve it by opening
> >> unit 1 then switching to unit 0 within VLT until I traced the problem
> >> to owndevunit. Remove that, and it worked fine. Maybe worth a
> >> notation in the docs.
>
> >I didn't have any problems with the owndevunit. All I did was call the
> >uwserverd with lockserial, like this:
>
> >RUN >NIL: <NIL: UUCP:c/LockSerial "uwserverd -s -m"
>
> >That will basically keep the serial port reserved for uw as long as
> >the server is running.
>
> Yes, but for those of us who don't have "lockserial" (what's that
> anyhow?), owndevunit causes problems. I was just pointing out a
> simple solution (i.e. don't use it. :) )
Lockserial comes with the owndevunit distribution. Just get the latest
version of owndevunit and lockserial should be in there. It also comes
with the AmigaUUCP package. Basically what it does is to manage the
serial port for you. Since I have my serial port in use by Getty all
the time (a program which can receive calls from users and redirect
them to some other program), I need some mechanism to tell Getty to
stop listeing. That is the exact use of lockserial, if you don't use a
program like Getty, then forget about lockserial... you don't need it.
Sorry, I should have mentioned that earlier.
> Point: Mention of "lockserial" as a way of calling uwserverd isn't in
> the docs, nor is mention of problems with "owndevunit". Maybe we
> shoudl write the author and let him know of these problems/fixes so he
> can incorporate them in the docs. (Now where's that archive w/his
> email address...)
Stefan
--
,-------------------------------------------------------,
|Usenet sgb...@charon.bloomington.in.us Stefan G. Berg|
|Internet sgb...@ucs.indiana.edu MIME // AMIGA |
Stefan G. Berg
> What's this AUW, and why should one use that instead of DNet?
My reason for using AUW instead of DNet is because DNet crashes my
machine. I suspect it has to do with mapping my Kickstart into the 32
bit RAM local to my 040 processor. But I will _not_ use my original
Kickstart ROM to operate my Amiga, because the speed would just suck.
For other people there might be other reasons. For one, AUW is a heck
of a lot easier to run... at least it was for me. Other people seem to
have more problems with it. But basically there are only three
programs involved: the Amiga device, the Amiga server, and the Unix
server. That's it... now look at dnet and start counting those dozens
of programs. Of course DNet has a lot more features, but for some
people all this extra stuff might not be necessary.
Stefan
--
,-------------------------------------------------------,
|Usenet sgb...@charon.bloomington.in.us Stefan G. Berg|
|Internet sgb...@ucs.indiana.edu MIME // AMIGA |
Colin Stuckless
>sgb...@charon.bloomington.in.us (Stefan G. Berg) writes:
>>In article <1993Sep19.2...@hubcap.clemson.edu> cha...@hubcap.clemson.edu (Charles E "Rick" Taylor IV) writes:
>>>
>>> Another things ... make sure you're *not* using owndevunit.device ...
>>> I had forgotten it was installed on my VLT and had a similar problem
>>> as you describe above. Oddy enough, I could resolve it by opening
>>> unit 1 then switching to unit 0 within VLT until I traced the problem
>>> to owndevunit. Remove that, and it worked fine. Maybe worth a
>>> notation in the docs.
>>I didn't have any problems with the owndevunit. All I did was call the
>>uwserverd with lockserial, like this:
>>RUN >NIL: <NIL: UUCP:c/LockSerial "uwserverd -s -m"
>>That will basically keep the serial port reserved for uw as long as
>>the server is running.
>Yes, but for those of us who don't have "lockserial" (what's that
>anyhow?), owndevunit causes problems. I was just pointing out a
>simple solution (i.e. don't use it. :) )
>Point: Mention of "lockserial" as a way of calling uwserverd isn't in
>the docs, nor is mention of problems with "owndevunit". Maybe we
>shoudl write the author and let him know of these problems/fixes so he
>can incorporate them in the docs. (Now where's that archive w/his
>email address...)
Ezra is aware of the situation. He has a "fixed" version of uw.device
which works when using multiple units (ie. uw.device unit 0 in your first
terminal, unit 1 in your second, etc.).
Easiest way to contact him is to drop by channel #amiga on IRC. He also
has an auto-configure script for the Unix side of things, to make installation
a little easier.
>--
>+ Rick __ + MAIL:cha...@hubcap.clemson.edu + Atari 2600,TG16 + Sonic is +
>| /aylor | cha...@eng.clemson.edu | Sega,SNES,A3000 | my roll |
>+-------------+---------------------------------+-----------------+ model... |
>+ "Every Girl Already Has A Boyfriend" --- Murphy's Law Of Dating +----------+
Colin Stuckless
col...@cs.mun.ca
Jack Radigan
>Hi. I am having a small problem with the dialer in Terminus 2.0a.
>I am using it to call up the mainframe at work from home. The dialer dials
>the number fine, but when the mainframe answers the line and the modems
>connect, the dialer does not exit. The countdown timer continues, and if
>left alone, will eventually timeout and reset the line. I can exit the
>dialer by clicking on the exit button and I will be connected to the system,
>but then my console definition and macros aren't loaded. I haven't had
>this problem dialing any other system...this one seems to answer the line
>and connect to my modem faster than the others.
Did you turn on the MONITOR option to see if the modem is returning a
recognizable CONNECT string when it connects? If the dialer doesn't see
that string it won't exit.
-jack-