🚀 go-pugleaf

From: uunet!samsung!swlvx2!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2!idsvax.ids.com!mikebw@U
Date: Thu, 13 Jun 91 11:42:03 EST
Subject: DRSI bug extingushed

I finally found the DRSI bug that I have been after for a while, having
exchanged messages with a number of tcp-group subscribers hunting for it.
This is the well-known "CHECKSUM ERROR" while tracing outgoing frames.
While frames are correctly transmitted and received by the DRSI drivers,
a local trace shows almost all outgoing frames to have CHECKSUM ERRORS,
and to refuse to disply their data fields.  While annoying, this does not
really affect operation.

The solution is to raise "mem nibufs" higher, because of what is is going
on in the DRSI driver.  NOS defaults to "mem nibufs 5" and "mem ibufsize 2048"
which are reasonable.  If the DRSI device is attached with a standard line
such as "attach drsi 0x300 7 ax25 dr0 1024 256 1200" then it has also
proven safe to decrease "mem ibufsize" to 1024.  I have found that "mem
nibufs 8" seems to cure the problem completely.

The idea is to raise "mem nibufs" to the point where "mem stat" shows no
counts for "Ibuffail".

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)


----
From: uunet!samsung!swlvx2!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2!idsvax.ids.com!mikebw@U
Date: Thu, 13 Jun 91 11:04:26 EST
Subject: Re: New NOS from PA0GRI

In reply to D. Crompton, crompton@NADC.NADC.NAVY.MIL:

The status command is implemented in main.c as function dostatus().  I do
not have MS-DOS 5.0, so I can't test anything, but the only part of the
function that looks suspicious in relation to the operating system is the
direct access to the _CS and _DS pseudo-variables.  You might try commenting
out the report of load segments and see if that fixes it.  If so, then the
problem is in 
Turbo/Borland C, and not in NOS.

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)


----
From: Bdale Garbee <bdale@col.hp.com>
Date: Wed, 12 Jun 91 17:58:56 MDT
Subject: Re: nntp in NOS

> Our NNTP server administrators have suggested that it might be better to get
> a manual feed from the news server rather than have NOS query the server
> periodically (currently the timer is set to one hour).

For use of NNTP as a news transport, there is indeed considerable sentiment
in favor of a "push" use of NNTP, where the upstream site passes articles along
as they arrive.  The "pull" mechanism is used almost exclusively by client
software around here.  There is no doubt fertile ground for discussion of
whether NOS stations are "clients" or "downstream sites" in this kind of
context.  At least for on the air stations, the "client" model probably makes
more sense, as it is likely to generate the least spurious traffic in the
case of systems that are not on the air full time.

> Doesn't NOS have to be running as an NNTP server also for this to work?  I've
> scanned through the code and it looks like NOS runs as an NNTP client only. 
> Am I right/wrong, half-right?...

There is nntp code floating around, probably not what is in NOS by default,
that implements full client and server.  It's what I've played with.

> If it will work, will NOS still be able to query the server for
> newsgroups that aren't on the normal forward list?

Should be able to.

Bdale


----
From: "James C Walker(Cap'n)" <70007.4651@CompuServe.COM>
Date: 13 Jun 91 10:15:47 EDT
Subject: TCP & DX clusters

       Has anyone successfully run a NOS node and DX Cluster node togather
on the same PC ? I'd like to find a way that they could work together (in on
.03, out on .63). Any help appreciated.
 
       Cap



----
From: uunet!samsung!swlvx2!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Wed, 12 Jun 91 04:59:55 EST
Subject: NOS bug: TMP files, Borland C++ 2.0

 
In using the new PA0GRI NOS, it was found that TMP##.$$$ files created with
the tmpfile() function (in the SMTP server, for example) were not being
automatically removed upon file close, as they should have been.  The PA0GRI
code contains functions in PC.C for tmpnam() and __MKNAME(), which proved to
be the source of the problem.  These functions are identical to those in the
KA9Q 910605 code.
 
Using the Borland C++ 2.0 compiler, my linker failed with a fixup overflow
error.  This appeared to result from declaring __MKNAME to use the pascal
calling convention without prototyping it; I was able to compile and link
successfully after removing the "pascal" keyword, but TMP files were not
being deleted.
 
After tracing with the debugger in assembly language mode, here is what was
found.  The original idea in NOS is to write a new function tmpnam() to
replace the library function with the same name.  The new tmpnam() calls
the NOS function __MKNAME(), instead of the library function _MKNAME().
Note the difference in the underbars.  (At the object module level, these
were being expanded in accordance with the ordinary C convention into 
___MKNAME() and __MKNAME(), respectively.)  While the TMP file creator was
using the NOS code, however, the fclose() library function was found to be
calling _MKNAME() directly instead of going through tmpnam().  Since the
__MKNAME() and _MKNAME() functions were producing different paths prefixed
to the file names, the file destructor in fclose() was unable to function.
 
The obvious solution, renaming the NOS function __MKNAME() to _MKNAME so
that fclose() would also call the NOS function instead of the library
function, was not a reasonable option because fclose() is in the _TEXT
segment and expects to make a near call to __MKNAME(), which also causes
the exactly opposite fixup overflow error.)  While definitely possible
to write a MAKEFILE script that would override the default segment names
for compilation and linking of PC.C, the only advantage that the NOS
functions have over the library in this case is that they offer the option
to use a directory specified by the TMP environment variable other than the
current directory for TMP files.
 
That small advantage does not seem worth the effort.  My recommendation is
that users of the Borland C++ 2.0 compiler delete the functions tmpnam()
and __MKNAME() from PC.C, reenabling the library functions.
 
-- Mike Bilow, n1bee@n1bee.ampr.org [44.104.0.20]
               N1BEE @ KA1RCI.RI.USA.NA   (AX.25)
               mikebw@idsvax.ids.com   (Internet)
 


----
From: uunet!samsung!swlvx2!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2!idsvax.ids.com!mikebw@U
Date: Thu, 13 Jun 91 11:20:57 EST
Subject: Apology and Correction

I sent a reply to D. Crompton which was intended to go to him personally,
and in error sent the message to the tcp-group as a CC because of my
mailer picking up his address that way.  This would not warrant an
apology, except that I realized that what I said that message is wrong!
So now I have to send out this correction...

Doug,
About 5 minutes after I sent you the comment about MS-DOS 5.0, I realized
that what I said has a serious error.  My explanation about having the
source code stands as originally stated.  However, the function dostatus()
calls function dofstat(), both in main.c, which makes use of an undocumented
function to read the internal DOS tables.  These internal tables are very
different from one DOS version to the next, and there really is no choice
but to have the code act in a version specific manner if it wants to get
information about where the internal file pointers are.  The definitive
expert on this stuff is Ralf Brown, ralf@cs.cmu.edu.  You might see if you
can get the information from him as to where the "DOS List of Lists and
Such" is hiding out under MS-DOS 5.0.

-- Mike Bilow, mikebw@idsvax.ids.com


----
From: "James C Walker(Cap'n)" <70007.4651@CompuServe.COM>
Date: 14 Jun 91 13:53:18 EDT
Subject: Questions

Two questions for the group:
 
       Does anyone know of a good transverter for 140mhz or 440mhz ? A down
convertor would also be nice. Unfortunately the only one I've found (new or
used) is Hamtronics down convertor.
 
       Has anyone successfully run a NOS node and DX Cluster node together
on the same PC ? I'd like to find a way that they could work together (in on
.03, out on .63). Any help appreciated.
 
       Cap
 



----
From: Stuart G. Phillips <stu@suntan.tandem.com>
Date: Fri, 14 Jun 91 20:54:07 PDT
Subject: Re: DRSI bug extingushed


Oops !, sadly I could have told you the fix !  The version of NOS (in
actuality the 11/30/90 release) is built with IBUFsize set to 512 - 
considerably more than is needed for an AX25 frame of 256 bytes + header.

This version can be found on suntan.tandem.com by anonymous FTP in
the ~pub directory - nos1130_tto.zip.

I dont plan any further changes or bug fixes to the driver - several
folks have expressed interest in support for multiple boards but thats
not on the agenda.

The ball is passed on to ..... (you perhaps ?)

73's Stu N6TTO


----
From: John Gayman <wa3wbu!john@uunet.UU.NET>
Date: Fri, 14 Jun 91 22:07:31 EDT
Subject: unsubscribe


   Please unsubscribe me from the tcp-group list. Thank you.

-- John



----
From: John Gayman <wa3wbu!john@uunet.UU.NET>
Date: Fri, 14 Jun 91 22:07:31 EDT
Subject: unsubscribe


   Please unsubscribe me from the tcp-group list. Thank you.

-- John



----
From: uunet!samsung!swlvx2!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2!idsvax.ids.com!mikebw@U
Date: Fri, 14 Jun 91 13:31:10 EST
Subject: Source for NOS under MS-DOS 5.0

I sent a note to Ralf Brown, the keeper of the list of undocumented MS-DOS
interrupts (Ralf.Brown@B.GP.CS.CMU.EDU), and he replied that the DOS List of
Lists structure is unchanged from MS-DOS 4.x to 5.x.  Since I do not yet
have MS-DOS 5.0, I cannot test this.  He is releasing the new edition of
his interrupt list this weekend, by the way.  Assuming Ralf is right, and
he probably is, the only change required is one line of source code:

 
-------- in function dofstat() in module main.c --------
 
[existing code:]
 
	case 4:
		entrylen = 59;	/* DOS 4.x - I do not know what is in the
				 * extra 6 bytes */
		break;
	default:
		tprintf("Sorry, cannot handle this version of MS-DOS");
		return 1;
 
[change to:]
 
	case 4:
	case 5:				/* This is the new line. -- N1BEE */
 
		entrylen = 59;	/* DOS 4.x - I do not know what is in the
				 * extra 6 bytes */
		break;
	default:
		tprintf("Sorry, cannot handle this version of MS-DOS");
		return 1;
 
-------- end of listing ---------
 
If I find this does not work when I finally get MS-DOS 5.0, I will investigate
further.

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)


----
From: John Gayman <wa3wbu!john@uunet.UU.NET>
Date: Fri, 14 Jun 91 22:07:31 EDT
Subject: unsubscribe


   Please unsubscribe me from the tcp-group list. Thank you.

-- John



----
-- 
*****************************************************************
   ___  ____  ___    _  _ ___ ___   ___ ___ ___     ___ _  _
  /__/ / / /   /    /\ / /__   /   /__//__//   /__//__ /\ /
 / \  /   / __/_   /  / /__   /   /  //  //__ /  //__ /  /