Date: Sat, 23 Jan 93 04:30:10 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #23
To: tcp-group-digest
TCP-Group Digest Sat, 23 Jan 93 Volume 93 : Issue 23
Today's Topics:
Clarkson Drivers
N6GN Microwave Link Construction Inf
nos futures (2 msgs)
RCS (2 msgs)
The New MMI??
TIP BBS
zip 2.0x
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Fri, 22 Jan 1993 13:31:05 EST
From: "Russell Nelson" <nelson@crynwr.com>
Subject: Clarkson Drivers
To: "TCP-GROUP" <TCP-GROUP@ucsd.edu>
On Wed, 20 Jan 93 21:48:15 CET, "BARRY TITMARSH" <BTITMARS@ESOC.BITNET> wrote:
By the way, Crynwr purchased the copyright on the packet driver
skeleton from Clarkson. Clarkson insists that I not use their name,
so I've changed it to "Crynwr Packet Driver Collection".
> Can some one tell me where to find the latest driver package..
> I was told by a local friend that there was a Version 11 driver pack out
> cant find i on the normal ftp sites still the old version 10
11.x is still in alpha test. I'll send an announcement to this list
when it's fully-baked.
--
-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice | LPF member - ask me about
Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
------------------------------
Date: 23 Jan 1993 22:35:54 -0500 (Sat)
From: Steve_Wright@kcbbs.gen.nz (Steve Wright)
Subject: N6GN Microwave Link Construction Inf
To: tcp-group@ucsd.edu
ARRRRGGGGGGHHHHH!!!! **WHY** isn't there a newsgroup for this subject ?
After all, packet on ham radio is all about getting RF bits going ....
here we see this being talked about in email and not where we all can
listen/watch. I filter many newsgroups in the hope of stumbling across any RF
discussion but rarely do I find it.
I call upon people in high places - can we have a discussion group for RF.
I'd like to see rec.radio.amatuer.packet.rf or somesuch. After all, we are
hams and hams are supposed to do it with frequency aren't we ??
yours in frustration,
Steve Wright - ZL1BHD
------------------------------
Date: Fri, 22 Jan 93 08:41:08 CST
From: Richard Elling <Richard.Elling@eng.auburn.edu>
Subject: nos futures
To: tcp-group@ucsd.edu, kz1f@legent.com
Walt> No.. It is more intuitive PERIOD, even for the unix luser. If people didnt
Walt> discover/exploit new and better technology we'd still be counting grains of
Walt> sand on the beach. The abacus would be too high tech.
hmmmm.... well the UNIX community does have GUI tools to make access to
information easier. I regularly use a GUI ftptool and do 99% of my ftp
by point and click. There are GUI fpt, mail, gopher, archie, talk, wais,
www, and weather clients. There are even mail clients that have indexes
of pictures. Many of these have versions that run under DOS, but obviously
only one at a time. And, of course, they are all free.
Jack> In the SMTP example, you create a message in "your favorite editor". The
Jack> message become an "object" which is dropped in the mailbox. The mailbox
Walt> Not really, the mail envelope would be dropped on the host it was destined to.
Walt> The object, envelope, would know how to get there, ie smtp.
I'm not convinced this is a scalable solution. It might be fine if there
were at most a dozen or so hosts. But with the internet gateways we've
already passed that size. Also, I think this is the wrong object to
interface with for mail. Mail should do to people or robots. ftp should
go to hosts.
> I clarify this only because I am underwhelmed with the discussion my remarks
> have generated to date and perhaps this my spur more (some) discussion.
At the risk of sparking a Jihad, I think that until we get real (preemptive)
multitasking OSes on the Intel machines to be widely used, we will be stuck
with whatever klunky interfaces we can devise using what are essentially
dumb ASCII terminals. I don't much care what OS it is, just that there is
one. Ok, even two or three :-)
Richard Elling Manager of Network Support
Auburn University Engineering Administration
richard.elling@eng.auburn.edu KB4HB.ampr.org (205)844-2280
------------------------------
Date: Fri, 22 Jan 1993 16:10:03 -0600 (CST)
From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
Subject: nos futures
To: tcp-group@ucsd.edu (tcp/ip networking group)
>No.. It is more intuitive PERIOD, even for the unix luser. If people didnt
>discover/exploit new and better technology we'd still be counting grains of
>sand on the beach. The abacus would be too high tech.
>
>> In the SMTP example, you create a message in "your favorite editor". The
>> message become an "object" which is dropped in the mailbox. The mailbox
>
>Not really, the mail envelope would be dropped on the host it was destined to.
>The object, envelope, would know how to get there, ie smtp.
Be careful about that, Walt! It may be more intutive (and I'm not sure I
agree that it is, at least for me), but it's not always easiest.
If I had to have an object on my desktop or in a folder to represent every
host to which I wanted to send mail or invoke FTP, I'd go crazy. I much
prefer a command line interface. On my X-terminal I have pull-down menus
for the hosts I use regularly. If I had to do this for every host I every
wanted to use I would be very upset. And if I have to have a desktop object
for every person to which I wanted to send mail (so that I could drop mail
into it) I'd throw the thing away!
For me, graphical approches are often an inconvience. I am a resonably fast
typist, and I would much rather type
elm kd4iz w5veo k3wgf
at a command line than have to select my text file icon and drop it into
three folders.
I'm not saying this is true for everybody, or even for most folks. And I'm
*certainly* not saying I don't like the idea of a OS/2 version of NOS! I'm
just saying that not everyone likes a mouse-based approach for everything.
It isn't always better.
As a final example, I remember when the Macintosh first came out. It seemed
very nice to be able to do word processing with a mouse. I could move the
cursor to just the spot I wanted to insert text, select text, etc. However,
I quickly tired of software that used *only* the mouse and did not let me
use cursor keys. As a touch-typist, it slows me down to have to reach from
the keyboard to the mouse just to move the cursor a few characters or lines.
The software vendors soon realized this and added cursor key support in the
applications.
73/Lee, N5LYT
------------------------------
Date: Fri, 22 Jan 93 08:08:06 -0600
From: sbrown@charon.dseg.ti.com (Steve Brown)
Subject: RCS
To: tcp-group@ucsd.edu
In Bob Nielsen's message of Wed, 20 Jan 93 22:13:50 MST
<RDoPXB2w165w@tapr.ampr.org>, Bob asks:
>What is RCS?
RCS is an acronym for Revision Control System. It is a Unix thing.
I am familar with it only in that context. Apparently, from the
traffic on this group, there is a DOS version of the same thing.
Works pretty well even though the command syntax can be painful at
times.
Here is part of the man page:
*********************************************************************
NAME
rcs - change RCS file attributes
SYNOPSIS
rcs [ options ] file ...
DESCRIPTION
rcs creates new RCS files or changes attributes of existing
ones. An RCS file contains multiple revisions of text, an
access list, a change log, descriptive text, and some con-
trol attributes. For rcs to work, the caller's login name
must be on the access list, except if the access list is
empty, the caller is the owner of the file or the superuser,
or the -i option is present.
Files ending in `,v' are RCS files, all others are working
files. If a working file is given, rcs tries to find the
corresponding RCS file first in directory ./RCS and then in
the current directory, as explained in co(1).
*********************************************************************
I think I can supply some citations for the original work, that sort
of thing, if you are _really_ interested.
*********************************************
| Steve Brown, WD5HCY | Simplicate |
| sbrown@charon.dseg.ti.com | and add |
| wd5hcy@kf5mg.#dfw.tx.usa.na | lightness. |
*********************************************
------------------------------
Date: Fri, 22 Jan 93 10:47:11 PST
From: cs161fex@sdcc10.UCSD.EDU ("DA BOLT IS BACK!" )
Subject: RCS
To: brian@UCSD.EDU, tcp-group@UCSD.EDU
Sorry I don't thinks this mail is for me.
------------------------------
Date: Sat, 23 Jan 93 01:57 GMT
From: Ian Campbell <softice@cix.compulink.co.uk>
Subject: The New MMI??
To: TCP-Group@ucsd.edu, kz1f@legent.com
In <9301212135.AA0069@RELAY.WESTBORO.LEGENT.COM> Walt writes:
> No.. It is more intuitive PERIOD, even for the unix luser. If people didnt
> discover/exploit new and better technology we'd still be counting grains of
> sand on the beach. The abacus would be too high tech.
I can see the advantages of this way of visualising the network in keeping
with the style of interface that many users will migrate to over the next
few years (OS2 PM, Windows [3 & NT], plus X, Motif), but would have two
observations:
1. The 'folder' presentation style was developed with the business and
office user in mind and would seem to work well in visualising the
directory structure and content of a node, but as an intuitive view
of the network and node inter-relationships I think a new approach
is required. Maybe a topological view of the network with coloured
paths indicating link type/speed - many users seem to enjoy walking
the network paths using Telnet or digipeating - this style of MMI
would facilitate such activity, with the user being able to adopt
the 'folder' style of display by double-clicking on a node in the
map.
2. In parts of the world where high speed interlinks (9k6 up) are
readily available it's all well and good to envisage a 'drag-and-drop'
style MMI, but for many places expecting file/message transfer to
occur in real or semi-real time over congested 1k2 links is surely
un-realistic. If such a system could be provided in two forms: real
time for capable areas or as a 'batch' front-end to NOS for the
less-capable....then we would have both an improvement in capability
and a possible start point for the next phase of development.
Many of the 'code wars' regarding NOS seem concerned with future operating
system selection and the inherent problems with increasing the size of the
NOS monolithic image. One possible solution may be to remove the NOS MMI
and distibute NOS as a library or more usefully an 'engine' with current
MMI functions (telnet, ftp etc) handled through API calls from the new
user interface. The first step in this process could be the development
of a 'batch' front-end (see 2 above) that would append the user commands
to the tail of AUTOEXEC.NOS so that any file/message transfer could be
carried out automatically in non-peak hours.
I'd be interested in aiding in the definition/development of a revised
object orientated front-end so any comments (especially flames and shouts
of HERESY or IDIOT) please pass on...
Ian - softice@cix.compulink.co.uk - G6ZIK (ex - it's a long story)
- - - - - - - - - - - - - - - - -
------------------------------
Date: Fri, 22 Jan 93 16:39:25 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: TIP BBS
To: crompton@NADC.NADC.NAVY.MIL, kf5mg@vnet.ibm.com
Jack,
The message that you got yesterday was cutoff, fortunately at a
point that made sense, due to a computer failure here.
Anyhow since then I have made some progress. I changed code in the
tipmail routine and now the tip bbs is 100% reliable on phone
dialin. I have one slight problem left. Anyhow here is what I did.
If you look at tipmail and study the code here is how I saw it
working.
When you start tip it does the necessarry initializations and then
ends up at the beginning of a for(;;) loop waiting for a carrier
detect "get_rlsd_asy" - once it sees this it goes about its business
of connecting the BBS to the user. After the user exits it drops
the line - "ioctl param down" and then waits for a loss of carrier
detect, then back to the beginning of the loop.
This is the way it did work - or should I say did NOT. I had much
trouble with the BBS - sometimes it would answer and I would see
nothing others it would answer with a buffer full of garbage that
would put it through 3 logins and then disconnect. Here is what I
did and my reasoning...
I wrote a 'c' phone BBS many moons ago in BDS 'C' on a CPM system. I
later converted it to MSC in DOS. In that program I simply waited
for a CD - went into the code and then a hangup or timeout I dropped
the line waited a few seconds and then went back to looking for a
CD. That's simple enough - so I made tip work that way.
If you look thru the i8250 code you will see that the modem status
interrupt code checks the RI line and when it sees a ring indication
from the modem it sets 'param up' - This is fine I guess but not
necessary when using an auto answer modem. I do not care about the
ring - only that I have a valid carrier detect - this would only
happen when the modem had answered and it was actually locked to
a data connection.
Anyhow I changed the code in this way - right after the 'for(;;)'
I put a 'ioctl paramup' then I pause a second, then I wait for
carrier detect. At the end of the for loop, just outside the loop
I pause 2 seconds (now you can see the hangup text!!) then I leave
the 'ioctl param down' - this hangs up the line - then I pause
5 seconds and then back to the beginning. I eliminated the final
check for CD to drop.
Putting the pauses in probably solves many of the problems. I often
find that fast systems require that when dealing with slow IO devices.
I also attempted to flush the input buffer before the BBS login prompt
is done. I had problems with garbage characters corrupting the login.
Either logging into a bogus account or using up the 3 logins attempts
and closing down. Because this uses the asy interrupt buffer any garbage
left in there is available when the BBS is started. All of the routines
block - including get_asy, so I am not sure what the best way would
be to clear the buffer - I guess you could reinitailize the count and
buffer pointers just before accepting input.
Anyhow it works well with the above changes and a 2400 baud internal
modem.
Next on the agenda is an xmodem interface and automatic transfer to
SLIP from the BBS.
By the way I use one of those smart phone front-ends ans it works
very nicely. It can transfer bewtween a FAX, MODEM, TAD or VOICE
phone. All of the phones in the house are fed thru it and when
data is active it gives a busy signal to the phones. It actually
answers the phone and then re-rings the other devices. If anyone
wants to try it my NOS is online - 2400 baud - use the following
(hayes) script to get to it - atdt12153555307,,22,22,22 The '22'
code is to connect to the modem port. Univperm is set so you can
login with any name at low priveledge.
To save bandwidth - those that needed the 10GHZ info I promised
I will get it out over the weekend to the group.
Doug
------------------------------
Date: Fri, 22 Jan 93 17:16:52 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: zip 2.0x
To: tcp-group@ucsd.edu
I have had reports that the new zip code blows up when using QEMM
and possibly other memory managers. Interesting that this code
recognizes the 386/486 and uses 32 bit code appropriately but it
must not follow some rule for extended/expanded memory???
Doug
------------------------------
End of TCP-Group Digest V93 #23
******************************
******************************