🚀 go-pugleaf

From: "James C Walker(Cap'n)" <70007.4651@CompuServe.COM>
Date: 01 Jul 91 11:21:33 EDT
Subject: latest NOS source ?

 
What the latest, most stable version of NOS available ? Is the source code
available and compile tested ? We're running G1EMM v 1.16 DLF here and would
like to have the source. Unfortunately, most versions of the source I've
gotten would not compile without changes (and I'm just learning C).
 
All help appreciated!
 
Cap



----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Mon, 1 Jul 91 11:53:50 EDT
Subject: BCC compile


Thanks for all of the help on BCC and NOS. I have it working.
Kelvin's last note which I will reprint here was the  method 
I used.

Change __MKNAME to MakeName in two places (remove the pascal
keyword in one) in pc.c


	From: kelvin@thed.uk22.bull.com (Kelvin Hill)
	Message-Id: <9107011025.AA26120@thed.uk22.bull.com>
	Subject: Re: BC+2.0 compile
	To: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
	Date: Mon, 1 Jul 91 11:25:15 BST
	In-Reply-To: <9107010430.AA10980@NADC.NADC.NAVY.MIL>; from "D. Crompton" at Jul 1, 91 12:30 am
	X-Mailer: ELM [version 2.3 PL11]
	
	Doug,
	  I also have just compiled it up using BCC. If you change __MKNAME
	in pc.c to MakeName and remove the pascal keyword, it'll compile and
	link correctly. 
	  Also, if you need to produce a version without AX25 configured for 
	lan use etc, you need to put #ifdef AX25 around ax25_dump in ipdump.c
	and the axip_input call in config.c
	  Hope this helps,
	          Kelvin.
	
	-- 
	Kelvin J. Hill - BULL HN Information System Ltd, Hounslow, England, UK.
	Internet - kelvin@thed.uk22.bull.com   | UUCP - kelvin@cix.compulink.co.uk
	   ""      kelvin@kelvin.uk22.bull.com | AMPRnet - kelvin@g1emm.ampr.org
	
It seems that the executable size is slightly smaller with BCC. About
4K. There are so many different compilers and versions floating around 
it is hard to compare. 

Thanks Again, Doug



----
From: Bdale Garbee <bdale@col.hp.com>
Date: Mon, 01 Jul 91 12:13:56 MDT
Subject: Re: ftp

> I have been try to ftp in to your hpcsos and lately I have not been able to,
> do you kmow what the problem is? Is it on your side or mine.

We upgraded the hardware and OS on col.hp.com, aka hpcsos.col.hp.com, about a
week ago.  I had forgotten that we were previously running a locally-modified
version of the FTP daemon.  The default version worked for some people and not
for others, apparently, as a result of our specifying options in our inetd
configuration that aren't supported by the default daemon until HP-UX 8.0.

I think it's all better now.

Bdale


----
From: bill@tuatara.uofs.edu (Bill Gunshannon)
Date: Mon, 1 Jul 91 12:59:44 EDT
Subject: NOS in a box

I understand that DR-DOS is ROMABLE.  If this is in fact true, does anyone
know what it would take to make a ROMABLE NOS image and therefore make a
completely ROMed IP swithc that could be used in remote locations??  It
would (obviously?) be a stripped down version without things like clients
or even most of the servers.  Has anyone tried this??  Can it be done??

bill   KB3YV

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   


----
From: "ATDECC::LARNER" <larner%atdecc.decnet@consrt.rockwell.com>
Date: 1 Jul 91 12:30:00 PST
Subject: nroffing ka9qnos.nr ?

I've tried numerous combinations of macro packages to nroff the
file ka9qnos.nr, but can't seem to find one that works properly. I'm
on a sparcstation with OS 4.1. Could someone please tell me the proper
command? -- Tnx

Dan Larner
Allen-Bradley Co., 1201 S. Second St., Milwaukee, WI 53204 ; (414) 382-4096
Home: 2604 Aberdeen Ct., Waukesha, WI 53188 ; (414) 524-9083
larner%atdecc.decnet@consrt.rockwell.com (internet)
wv9z@wa9kec.wi.usa.na (AX.25)
  


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Sat, 29 Jun 91 23:42:40 EST
Subject: RE: PA0GRI notes

I have been using PA0GRI NOS in several versions for a few weeks now,
compiling under Borland C++ 2.0 with the changes I sent you separately,
and I have not seen anomalies of the sort you describe.  In particular,
I have not seen services shutting down of their own accord.  Several
users who have been testing my versions have likewise not reported this.

The only thing I can think of is that you are running out of or corrupting
your memory.  You mentioned getting the linker fixup error on __MKNAME().
If you don't correct this, you will cause the stack to go unbalanced on
each open or close of a temporary file, with unpredictable and probably
serious consequences.  Do you show any "invalid frees" or the like on
"mem status"?  Do you have any error messages in your logfile?

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


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Sat, 29 Jun 91 23:31:32 EST
Subject: RE: BCC compile

The fixup error from the linker when you try to compile PA0GRI NOS under
Borland C++ 2.0 is the manifestation of the problem with tmpnam() and
__MKNAME() in PC.C which I mentioned earlier.  The problem, without going
into the details, is that the old library called tmpnam() and let it call
__MKNAME() both on file creation with the tmpfile() function and on file
deletion with the fclose() function, but the new libraries call tmpnam()
on file creation and call __MKNAME() directly on file deletion.  This is
not a big deal except that Borland decided to define __MKNAME as a near
function using the pascal calling convention, which prevents you from
accessing it normally when compiling in large model.

The work around I have been using is to disable the tmpnam() and __MKNAME()
replacement functions in PC.C, using the library routines.  This causes
temp files to be created in the current directory, which can prevent them
from being deleted if the user changes directories between the call to
tmpfile() and the call to fclose().

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)
 
(Gerard may not know this, since it is a strictly compiler-specific issue.)


----
From: brian@ucsd.edu
Date: Mon, 1 Jul 91 16:23:05 -0700
Subject: mail path test tcp-group ham-tcp-group@infoac.rmi.de

Testing mail to ham-tcp-group@infoac.rmi.de on list tcp-group
Do not reply to this mail.


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Sat, 29 Jun 91 23:19:32 EST
Subject: RE: NOS and C++

I have switched to PA0GRI NOS for the Borland C++ 2.0 compiler.  There are
a few incompatibilities, but I consider these minor.  As of NOS_0605, in
fact, the distributed MAKEFILE will run almost as is: change the CC=tcc
line to CC=bccx, and add -P-c to the CFLAGS.  This should produce at least
a successful compile.

Because of some internal differences in the newer run-time libraries, you
cannot use the replacement temporary file naming routines in PC.C, as I
explained in a detailed message to the group.  The work around I have been
using is to comment out the tmpnam() and __MKNAME() routines, letting the
compiler use its own.  I knwo how to fix this, but have no done it yet.
In the meantime, temporary files will be created in the current directory,
which only causes a problem if the user changes directories between the
calls to tmpfile() and fclose().

You also need to move the "extern Version2[];" declaration inside main()
in module MAIN.C outside of any function.  This is a plain ANSI thing that
carries over from KA9Q NOS.  Again, it is really trivial.

The NOS_0618 release of PA0GRI NOS is easier stil because of some changes
in the MAKEFILE.  You no longer need to add the -P-c switch to CFLAGS.
For sanity's sake, I would add the -w-par switch to suppress the useless
"paramter unused in function xxxx" warnings that spew forth.  The MAILBOX.C
file is extensively changed in NOS_0618, and will not compile unless there
is a prototype for function doarea() inserted before the first call to it.

The only files I have modified in NOS_0618 are:

Required:     MAKEFILE
              PC.C
              MAIN.C
              CONFIG.H

Fixes:        TTYDRIV.C
              DOMAIN.C
              SMTPSERV.C
              ALLOC.C

Something I am doing with the tcp timers:
              TCPCMD.C
              TCPTIMER.C
              TCPSUBR.C
              TCP.H

Something I am doing with the ax25 heard function:
              AXHEARD.C
              AX25CMD.C
              AX25.H

For documentation:
              VERSION.C

All else works fine.  Most of the files I have modified do not need to be.
The memory allocator does not do garbage collection right, but other than
this it is a very nice NOS.

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


----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Mon, 1 Jul 91 13:50:30 HST
Subject: Re: nroffing ka9qnos.nr ?

> I've tried numerous combinations of macro packages to nroff the
> file ka9qnos.nr, but can't seem to find one that works properly. I'm
> on a sparcstation with OS 4.1. Could someone please tell me the proper
> command? -- Tnx
> 
> Dan Larner
> Allen-Bradley Co., 1201 S. Second St., Milwaukee, WI 53204 ; (414) 382-4096
> Home: 2604 Aberdeen Ct., Waukesha, WI 53188 ; (414) 524-9083
> larner%atdecc.decnet@consrt.rockwell.com (internet)
> wv9z@wa9kec.wi.usa.na (AX.25)
>   
> 
> 

Try:  nroff -ms ka9qnos.nr
If you want to print it and you have a laser-printer on-line, then
troff -ms -t ka9qnos.nr | lpr -t
should do the trick.

Tony


----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Mon, 1 Jul 91 19:11:34 HST
Subject: main encap router?

Is anyone running a reliable system that has all the known encap routes?  I'm
looking at a routing table that seems to be growing every day and I'd like to
cut it down to size with a single 'route add 44.0.0.0/8
encap omnipotent.ampr.org'.


Antonio Querubin  
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet


----