Date: Sat, 10 Apr 93 04:30:17 PDT
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 #94
To: tcp-group-digest
TCP-Group Digest Sat, 10 Apr 93 Volume 93 : Issue 94
Today's Topics:
DOS 6.0 and stat cmd
Duplicate post to the NOS-BBS-GROUP and the TCP-Group
Ethernet question
JNOS108e !!??
KA9Q bug - hang on tcp close
Thoughts on 108e
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, 09 Apr 93 10:40:50 CDT
From: ed@wa9yyf.ampr.org (Ed Curran)
Subject: DOS 6.0 and stat cmd
To: tcp-group@ucsd.edu
Hi All,
For what it's worth, I am running grinos 20.p on a 286 machine compiled
with TC 2.0.
I added in Doug's fixes (thanks Doug) to main.c ( adding a case 6:)
and to ksubr.c and now the stat command works fine.
Thanks to all,
Ed wa9yyf
------------------------------
Date: Fri, 9 Apr 93 11:39:48 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Duplicate post to the NOS-BBS-GROUP and the TCP-Group
To: nos-bbs@hydra.carleton.CA
I AGREE - I really don't like doing that either. I don't think?? Phil
subscribes to nos-bbs and since much of this discussion revolves around
his code I thought that tcp-group might be a better place. Sometimes it
is really hard to make a decision which group to use and who see's what.
I am open for guidance on this also???
nos-bbs as I see it was created to reduce the noise on tcp-group about
the use of NOS - not the development - or am I wrong on that?
If that is the case then I suspect that the updating of the code threads
should be on tcp-group?
tcp-group is distributed in digest form to all tcp'ers who want to
see it in this area - nos-bbs is not. I understand that nos-bbs is
digested now?? If so What is the subscription procedure. I would like
to get it on our local AMPR distribution.
And as you guessed it I am CC'ing this to both! If you get only one copy
of this message (meaning you are only subscribing to only one or the other)
Then let us know what you expect to hear in the group you are in?
I am sure that tcp-group is a much larger audience, probably mainly because
it is older. It is also much less responsive in it's turn around time.
NOS-BBS will turn a message around - often as it is being sent. tcp-group
returns can take a day or more at times here.
Doug
------------------------------
Date: 09 Apr 1993 15:37:38 -0400 (EDT)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: Ethernet question
To: tcp-group@ucsd.edu
As a previous "user-only" of Ethernet, who is now installing/administrating
an Ethernet network.....
1> Could I please get some input on good (preferably inexpensive) combinations
of Ethernet hardware cards along with the appropriate JNOS drivers that
some of you are using. An approximate cost of hardware, size of network,
driver being used, and any "gotchas" would be appreciated.
2) Thanks in advance ;-)
73 from Brian A. Lantz KO4KS@KO4KS.#TPAFL.FL.USA.NA 3100813105
Internet: brianlantz@delphi.com
Amprnet: ko4ks@ko4ks.ampr.org [44.98.0.167]
------------------------------
Date: Fri, 9 Apr 93 11:44:42 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: JNOS108e !!??
To: crompton@NADC.NADC.NAVY.MIL, nos-bbs@hydra.carleton.CA
BTW, there's a reason I changed availmem() to return a boolean flag,
and removed the call to coreleft(): they didn't work anyway.
My storage allocator uses the DOS allocmem() call to get additional
blocks of memory when the initial allocation is exhausted. These new
blocks of memory can be noncontiguous with earlier allocations, and in
fact they can be in high memory (under DOS 5.0 or higher).
The sbrk() call, which the standard malloc() uses to get memory from
the system, and which I used until I changed to allocmem(), can only
extend the existing heap through contiguous memory until it hits
memory that has already been allocated to another MS-DOS task (like a
TSR or an internal MS-DOS table). This became a serious problem back
when I made the necessary changes to support very large FILE tables;
MSDOS would often allocate the additional file table space required
right after net.exe, and malloc() would fail immediately after net.exe
was started. (This took a while to diagnose...)
Soapbox on...
How utterly typical of MS-DOS environments! Overcoming a seemingly
trivial limitation like the default maximum of 20 open files required
that I first rewrite all of stdio. (The Borland implementation had a
hard-coded file table size, and I didn't want to require NOS users to
have and modify Borland library source code. And I wanted to rewrite
stdio anyway to work over network sockets.) Then I had to rewrite the
storage allocator to get around the problem mentioned above. God, how
I hate statically-dimensioned arrays...
Soapbox off...
I removed the call to coreleft() because it was far too simpleminded
to work with this more general memory management scheme, and I didn't
feel like expending the required effort to make it work right. To
find out how much memory is available now, you really have to ask DOS
(and possibly QEMM or whatever memory manager you're using) because
only it/they know which high memory blocks are reserved or already
allocated to other programs. It didn't seem worth the effort, since
the only real reason to care is to find out whether you're running low
enough on memory to start a reclamation effort. And that's easily done
by seeing whether you can malloc a few k.
Phil
------------------------------
Date: Fri, 9 Apr 93 7:44:38 PDT
From: Glenn Engel <glenne@lsid.hp.com>
Subject: KA9Q bug - hang on tcp close
To: tcp-group@ucsd.edu
I added the following fix to tcpsock.c to wake up any processes waiting
on a socket if the socket gets closed from the other end.
*** /tmp/fdiff1_a04474 Fri Apr 9 10:36:32 1993
--- tcpsock.c Tue Mar 30 17:42:58 1993
***************
*** 257,262
up->errcodes[0] = tcb->reason;
up->errcodes[1] = tcb->type;
up->errcodes[2] = tcb->code;
}
del_tcp(tcb);
break;
--- 257,263 -----
up->errcodes[0] = tcb->reason;
up->errcodes[1] = tcb->type;
up->errcodes[2] = tcb->code;
+ psignal(up,0); /* wake up any waiting processes */
}
del_tcp(tcb);
break;
--
Glenn
--------------------------------------------
| ___ | |
| / / | Glenn R. Engel |
| HEWLETT/hp/PACKARD | (206) 335-2066 |
| /__/ | NN7N |
| Lake Stevens | |
| Instrument Division | glenne@lsid.hp.com |
--------------------------------------------
------------------------------
Date: Fri, 9 Apr 93 09:44:54 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Thoughts on 108e
To: nos-bbs@hydra.carleton.CA
Ok - after I write this I will be putting jnoska9q.zip out at ucsd's
hamradio/packet/tcpip/incoming.
These files can be copied over 108df. I am not happy with the results
though. I have a nagging crash problem here. I have not been able to
determine the cause. I probably will not have time to do anything more
with it until after the weekend.
For better or for worse here are my thoughts on this -
Many years ago as I remember it Kelvin, G1EMM picked up the NOS cause
because of problems experienced with KA9Q code. I was never able to make
KA9Q (back then) run for more than a few days. Also at that time I was
just a user, so I did not follow (at the code level) what was going on.
I do know though that the reliability of the code improved greatly over
the years. The current WG7J - actually all versions 1.01 on have generally
been very reliable for me.
I know that the current KA9Q base is all new but I would caution everyone
from thinking that it is some kind of 'magic bullet' that is going to
solve everyone's problems. Indeed it is a radical change that may in
fact prove to have many more problems when used in a much larger scale
with WG7J code. Actually as I understand it the code (KA9Q) may not be
as good under marginal condition machines - 8088/286 and non 16550 or
low-end ethernet cards. Since the consensus (not mine) seems to be to
satisfy every fringe with the WG7J package, I think we should step back
and look at what we are doing. We may have what we think is better code
but actually have a lot of unhappy campers.
Perhaps this is a project that should go in parallel with WG7J code for
awhile?
Doug
------------------------------
End of TCP-Group Digest V93 #94
******************************
******************************