🚀 go-pugleaf

From: Adrian Godwin <agodwin@acorn.co.uk>
Date: Tue, 9 Jul 91 17:35:58 +0100
Subject: Sources for Amiga NOS ?


Does anyone have sources for version 2.5 (or later) of Amiga NOS, please ?

I can't seem to contact G1YYH, and I believe the kit that was on thumper 
contains only binaries and configuration files.

-adrian (g7hwn)


----
From: jal@acc.flint.umich.edu (John Lauro)
Date: Tue, 9 Jul 91 10:19:43 EDT
Subject: Re: tmpname(), __MKNAME()

	I see it's time to introduce myself... I'm in Languages R&D at
	Borland, and I'm trying out NOS ka9q to provide routing through our
	SLIP connection to the Internet. Eventually I would like to get
	Internet mail integrated with our internal LAN-based e-mail and have
	some sort of PC-based news reading and posting. (By the way, any
	suggestions on how to do this on a Novell network would be
	appreciated).

I highly recommend Pegasus mail and the Charon gateway.  Both programs
are available via anonymous FTP.  I don't have the sites handy but
if I remember correctly pmail is on splicer.cba.hawaii.edu and Charon
is on omnigate.clarkson.edu.  Pmail is designed to work with Novell, and
Charon is a SMTP -> Pmail gateway and requires a dedicated PC.  Pmail
will work without the gateway.

   - John


----
From: gerry@n5jxs.jsc.nasa.gov
Date: Tue, 09 Jul 91 08:42:17 cst
Subject: 9600 baud trials and tribbles

Well, the 9600 baud project is alive and sputtering here in Houston.  I'm open
to suggestions, as we haven't had any earth-shattering successes.

We've grafted a couple of PacComm 9600 bps modems to Tiny-2's.  These are 
interfaced to a pair of Icom IC-251 multimode radios.  (I know, I know, they
aren't "real" radios, but they're what we had to work with and we really wanted
2 identical radios to do initial testing and characterizations with.)  We are 
connected directly to the varactor for Tx and to the top of the squelch pot for
Rx (tried the tie-point of the discriminator, but it didn't work...:-)  

We see about a 50% thru-put, with incrementing delays.  We are typically using 
a txd of 700 ms. and axd of 200 ms.  If we start on a quiet channel, we see 
good turnaround the first few packets, then it dies off, slowly.

We have a few ideas:  
1.  Timers are not optimized for 9600 bauds.

2.  Radios are not optimum.  (We're working on that one, but 2 meters is where
we want to keep the user channels).

3.  We're getting 455 kc into the modems and confusing them sometimes.

Our next step is to get together with our RF guru and his test gear and make 
sure that the hardware is configured well for RF compatibility.  Then, we pro-
pose to retire to the bar for a couple of rounds.  Especially if the RF rework
dosn't make things work perfectly.

Any suggestions?  E-mail preferred, summary if the results indicate it.

Thanks, Gerry Creager
gerry@n5jxs.jsc.nasa.gov


----
From: Tim Shepard <shep@lcs.mit.edu>
Date: Tue, 9 Jul 91 09:17:55 EDT
Subject: Re: Automatic local network problem with 0618



>I have found a bug which I haven't seen anyone else mention yet.  Any
>automatic route created by way of a netmask doesn't work.  For some reason it
>sets the subnet address to be identical to the interface's address, with the
>correct number of significant bits, however, it is unusable.  You need to add
>a manual entry for the local network subnet address.  This wasn't the case in
>the 1130 release.  I suspect the problem is in iproute.c, which has been
>changed quite a bit to include hashing of the routing table.
>
> [ ... ] 
>
>Has anyone already found the cause of this problem?  If so, please let the
>group know - I don't want to unnecessarily reinvent the wheel :-) :-)
>
>			   ttfn
>			   Chris Cox  W0/G4JEC

This sounds like the same bug as below.  Maybe this will help.

				-Tim
----included message----
     Date: Wed, 5 Jun 91 11:36:20 EDT
     Message-Id: <9106051536.AA23584@PTT.LCS.MIT.EDU>
     From: Tim Shepard <shep@lcs.mit.edu>
     Sender: shep@PTT.LCS.MIT.EDU
     To: karn@thumper.bellcore.com
     Subject: Bug in NOS 910423 ip routing table code
     
     
     Phil,
     
     I believe I have found a bug in the IP routing code in NOS 910423.
     I looked at the NOS 910524 sources and saw no obvious evidence that
     the bug had been fixed.
     
     In ifnetmsk(), there is this line of code:
     
	     rt_add(ifp->addr,mask2width(ifp->netmask),0L,ifp,0L,0L,0);
     
     rt_add() adds this to the routing table with rp->target set to be the
     complete IP address of the interface.  This complete IP address is
     used to determine the hash bucket in rt_add().  It is also compared
     against in rt_lookup().  The problem is that the local address bits
     that are non-zero in target cause the entry to wind up in the wrong
     bucket and even if it was in the right bucket, the local address bits
     that are on in rp->target will cause the comparison in rt_lookup() to
     fail as well.
     
     To fix this, I added this line to the beginning of rt_add():
     
	     target &= (~0L << (32 - bits));
     
     This could also be fixed by masking the ifp->addr argument with
     ifp->netmask in the call to rt_add() in ifnetmsk(), but I believe my
     fix is better because it makes the behaviour of rt_add() easier to
     understand.
     
			     -Tim


----
From: John Howie <seb618@computer-studies.napier.ac.uk>
Date: Mon, 8 Jul 91 14:08:13 BST
Subject: Re: Flat ampr.org

Folks,

	I know that a lot of you are going to disagree but...

	I think it would be desirable to add more address information to
our host.domainname set up before we are forced to do so out of neccessity. For
example:

	Here at Napier CS my userid is seb618 and my machine is hades. Assuming
that the machine name 'hades' is unique within the UK academic community it
would mean that my mail address could be seb618@hades.ac.uk. In order for any
user with access to JANET (our educational network) to mail me their system
would have to know that:

	a) my machine existed,
	b) how to send mail to it.

	Now let's extend this to a worldwide scale. Assume that the machine
name 'hades' is unique in the whole Internet my email address might be
seb618@hades.edu. Can you imagine the countless thousands of machines who
have not heard of 'hades' and don't know how to forward mail to it. For
every machine to be able to communicate with every other machine the mail
forwarding and routing tables would be unimaginably huge.

	Currently my tcp/ip address for ampr is gm7jgr@gm7jgr.ampr.org. Now
hands up all the people who can mail me based on that host.domainname alone.
I'll bet it is only the people with whom I regularily contact anyway. My
*real* email address is seb618@hades.cs.napier.ac.uk. For any machine in the
world connected to the Internet the address should be reachable for mailing
purposes. Their machines will know, based on the domain, where to forward
mail to. If my ampr address was gm7jgr@gm7jgr.sc.gb.ampr.org then other
hams could mail me and their machines would forward on the mail based on
the doamin name.

	Now I admit that the cellular concept is a nice one but do many
people know how it works? There are two main methods. The first is that
when an incoming call is to be passed on to a handset all the cells in a
net will broadcast that a call is waiting to be forwarded and the handset,
on hearing this, will reply. The cell that picks up the reply first then
routes the call. The second method is for the handset to periodically
broadcast and the listening cells update a central call router whenever they
hear a handset.

	The first method would require EVERY ampr station to broadcast to
a would-be receiving station and the second would mean that mail could be
forwarded according to old routing information beacuse the ham on holiday
hasn't powered up his equipment at the campsite! Also, at speeds of 1200
baud these two schemes would be unworkable. Now I know that there are other
methods but these are the two most common ones.

	If we are ever going to set up a global tcp/ip ampr network, perhaps
with real Internet links, in which mail can be sent from anyone to anyone we
are going to have to lose the flat domain. There will be those who lose out,
eg. anyone who operates mobile.

	I agree that this is only a problem with mail routing. However, if
anyone can prove that another method is workable without resorting to
dedicated machines/broadcasts/etc. then I'd be willing to change sides!! I
do not, however, believe that routing based on callsigns is a good idea. If I
move down to England or Wales or the Channel Islands then my callsign
changes likewise. In addition, if I go to a CEPT country my callsign changes
again! What happens to all my old mail???

	Sorry if all this was a bit long!!!! Flames (on the length) to /dev/null
or NUL on a PC!

	Cheers, John....

P.S. I object to the statement that the FCC are responsible for the ampr
     domain level 'cos across here they aren't!!!


----
From: gerry@n5jxs.jsc.nasa.gov
Date: Tue, 09 Jul 91 08:32:45 cst
Subject: Re: tc.

Actually, the READ: Y/N flag is not even added or updated in messages that are 
listed in the /spool/areas file.  So, they should never have the flag set if 
you read them from within NOS.  Note, please, that reading 'em with VIEW, BM
or PCElm (2.1...) will result in the flag being inserted and set.

gerry


----
From: gerry@n5jxs.jsc.nasa.gov
Date: Tue, 09 Jul 91 08:40:31 cst
Subject: BBS (reverse) forwarding

OK.  Here goes...  The local BBS (AA4RE-type) is complaining that he cannot 
forward mail to me because I am sending a message claiming he's got an invalid
BID.  Anyone seen this and what do I do to crunch it?

Thanks,  gerry


----
From: gerry@n5jxs.jsc.nasa.gov
Date: Tue, 09 Jul 91 08:35:23 cst
Subject: Re: NOS? Points....

The AX routing 'feature' has been biting me lately with a couple of stations,
not the least of which is the local BBS that ships mail to me.  When I set a 
route for him, I'd appreciate it to last a while.  Unfortunately, the first
time he beacons (?!) the ax route is updated to include the digi about 1000 
yards from my antenna.  I then have to go thru a busy digi for the rest of 
eternity.  Suggestions?

gerry n5jxs
gerry@n5jxs.jsc.nasa.gov


----
From: "Paul A. Barrow" <PBarrow@PBarrow.eche.ualberta.ca>
Date: Tue, 9 Jul 91 15:41:42 MDT
Subject: WD8003EP on Zenith 159

Setting the shared RAM address for the Clarkson WD ethernet driver 
is proving to be an elusive task (at least for me). The manual for the
Western Digital card suggests placing the shared RAM setting at D0000,
however, the Zenith 159 (Model ZDE 1217) does not work well with this
configuration. NOS gets as far as the command prompt, then it is power
up reboot time.

Other  "coordinated address" settings (i.e., both card and driver using
the same address) are not necessarily as catastrophic, BUT don't result
in a functioning lan connect either. What does work, but I don't understand,
is to set the card to D0000 (851968) and tell the driver that it is
at D000 (53248).

If someone has an explanation for this behavior, or better yet, knows
a "coordinated address" that works, I would appreciate the information.
Given that the driver does not seem to need the shared memory link
to the card, exactly what was it supposed to do?



Thanks in advance and 73,

Paul, VE6ATS
pabc@n5jxs.jsc.nasa.gov


----
From: rob@sys2.pe1chl.ampr.org (R.E. Janssen (PE1CHL))
Date: Tue, 9 Jul 91 22:41:46 MET
Subject: fix for tmpfile/tmpnam 'problem' in Borland RTL

Sidney,

The problem in the tmp file routines is not something that crept in between
TC++ and BC++, or even between TC and TC++...  It was already there in TC 2.0
Professional (I don't know about earlier versions).
I fixed it for TC 2.0 and this fix does not work for BC++, so that's what the
stir-up is al about.
As the people handling bugs@borland probably don't know this history, I mail
this to you.  I hope you want to forward it internally with the necessary
explanations.

The point is that all temporary names generated by the RTL refer to files
in *the current directory*.
This creates nice, short names but it has a problem:  when a tmpfile() is
created, the name is generated, and only a "sequence number" is kept in
the FILE struct.  Later, when the file is fclose()'d, the fclose() routine
sees the sequence number, re-generates the same name for that and removes
the file.

The problem is, that the "current directory" may have *changed* between
the call to tmpfile() and the call to fclose().  Then, the remove of the
temporary file fails.  (in theory it could even remove the wrong file!!!)

In a "normal application", the current directory is usually never changed,
so this problem may have gone unnoticed for a long time.  However, in NOS
(and NET) a "cd" command is available to the user, and temporary files can
often be open for long times.  Then, the problem occurs.

There are different possible fixes to this...  You could store tmpfiles
in the root directory, but even then the "current drive" could change,
getting the same problem.  Also, people don't like files in their root
directory.
A flexible fix is to let the user set an environment variable (conventionally
named "TMP") that holds the pathname of a drive+directory to be used for
temporary files.
These two can be combined by using the TMP variable when defined, and using
the root directory of the current drive when no TMP variable is found in
the environment.  In the latter case it would be preferable to "remember"
the current drive the first time a tmpfile is generated, and keep using
that drive forever for the lifetime of the program.

I am sure your RTL developers can use these hints to write a better file name
generation routine.  As an example I'll include my fixed version (it has
also been posted to tcp-group a while ago).  It does not implement the
"remember current drive when TMP not defined" hack described above.
A version for the RTL would probably want to avoid the call to sprintf().

Make sure the L_tmpnam definition in stdio.h is adapted to the longer
temporary names this function generates, or some nasty and difficult-to-find
bugs may be the result (I already had to find out...)

I hope this info is sufficient and useful.  If you have more questions you
can contact me at "rob@cmgit.uucp".

73,
Rob




/* low-level routine used by tmpnam, fixed to use TMP environment variable */

char *pascal __mkname (char *tmpname,unsigned int tmpnum)

{
   char *tmpdir,*p;
   static char staticname[80];

   if (tmpname == NULL)
      tmpname = staticname;

   p = tmpdir = getnenv("TMP");         /* get tempdir name */
   if (p[0] != '\0')
      p += strlen(p) - 1;               /* point to last character */

   sprintf(tmpname,"%s%sTMP%u.$$$",
                   tmpdir,
                   ((*p != '/' && *p != '\\')? "/":""),
                   tmpnum);

   return tmpname;
}

unsigned int _tmpnum = 0;

/* new tmpnam function.  calls above routine to generate the name, but */
/* is otherwise the same as the tmpnam() in the library. */
char *tmpnam (char *name)

{
   do
   {
      if (_tmpnum == 0xffff)
         _tmpnum = 2;
      else
         ++_tmpnum;

      name = __mkname(name,_tmpnum);
   }
   while (access(name,0) != -1);

   return name;
}

/* read the value of an environment variable */
/* same as getenv(), but return "" instead of NULL when it does not exist */
char *getnenv (name)
char *name;
{
   char *rv;

   if ((rv = getenv(name)) == NULL)
      rv = "";                          /* NULL replaced by "" */

   return rv;
}


----
From: "Chris Cox W0/G4JEC" <g4jec@g4jec.ampr.org>
Date:  Tue, 9 Jul 1991 18:46:19 -0500
Subject: Re: Automatic local network problem with 0618

Tim,

>From your description, that is precisely the problem!  Thanks very much for
the reply, and code fragment.

It is much more elegant than my hack :-) :-)

By the way, another problem has manifested itself.  This new release is
locking up within a couple of hours of running.  There are no warning messages
displayed on the console, and so far I haven't been able to track it down.  I
was going to start investigating it tonight...

Best 73's & thanks again,


                                   ttfn
                               Chris W0/G4JEC

chrisc@moron.vware.mn.org   g4jec@g4jec.ampr.org   g4jec@g4jec.vware.mn.org

11th Hour Contest Group (North American Chapter)   Minneapolis, MN   EN34ju


----
From: Don Koch <nt1l!aardvark@UCSD.EDU>
Date: Tue, 09 Jul 91 23:15:14 EDT
Subject: Re: Managing ampr.net domain namespace


>Question of flatness of NAME space (I will not make comment on address
>issues, that is a different beast) is filled with plenty on controversy.

No kidding :-).

>As for MANAGEMENT, splicing AMPR.ORG into subdomains according to first
>two or three first letters of callsign would most propably be GOOD IDEA.

Acutally, I was thinking of country/state names.  Since the US is divided
into call areas by number, your method could be moved to that level (e.g.,
instead of ka.ampr.org, you could use w9.ampr.org).  Unfortunately, having
a call from the 9 call district doesn't mean you still live there (in Phil's
case, he is (was?) in 2 land and is moving (has moved?) to 6 land).  This
is why I would suggest using standard 2 letter country (and then state)
codes (e.g., fi.ampr.org or ma.us.ampr.org).

>For automatic maintance of this database you would need canonical Regular
>Expressions to convert any arbitary call sign to DNS subdomain, and something
>magical for those call signs which start with number -- DNS doesn't allow
>any such:
>	4A5BC.4A.ampr.org -> d4A5BC.d4X.ampr.org
>where "d" is magic cookie. (Letter)

Another reason to use country names (unless you know of a country that
starts with a number :-).

>Also, subdomaining would let master/secondary servers be in places, where

Yep.

>Still, it would require that all sites/systems needing access to DNS database
>for country/region XYZZY would either need copy of its database, or Fully
>Connected Network.

As far as mail goes, nope.  You just make MX entries like:

nt1l.ma.us.ampr.org.  MX    IN     1 nt1l.ma.us.ampr.org.     ; known host
*.ma.us.ampr.org.     MX    IN     2 mailhost.ma.us.ampr.org. ; local
*.us.ampr.org.        MX    IN     3 relay.ma.us.ampr.org.    ; out-a state
*.ampr.org.           MX    IN     4 relay.ma.us.ampr.org.    ; out-a country
*.                    MX    IN     5 smarthost.ampr.org.      ; not ampr.org!

>  Thinking that KA9Q is forever in NJ is an error - Phil noted us, he moves...

The reason I chose to pick on him.  That and NJ is 2 land, not 9.

>> Besides, why couldn't you have both a "top level" and a subdomain name
>> for the same address (e.g., nt1l.ampr.org and nt1l.ma.us.ampr.org are
>> the same ip address), the latter mostly for mail routing?  Mail routers

>  There is such DNS information unit, as CNAME for aliasing one entity to
>another.  Yes, it can be done.

This I already knew (and is why I suggested it).  A typical entry (assuming
an ORIGIN of ampr.org.):

nt1l         IN   A      44.56.0.63
nt1l.ma.us   IN   CNAME  nt1l

>TROUBLE is in defining these (preferrably top-level) CNAMEs pointing to
>real data entries.  If regional maintance updates only their zones (sub-
>domains), who updates top-level ?  (Must be automatic!)

I don't see why the top-level Domain Name Server has to know about
CNAMEs.  I can assure you that nic.ddn.mil doesn't know about them.
For secondary servers (and you should have at least one in each zone)
you do zone transfers.  The primary server is the one that is changes
and the information is transfered to the secondary machines automatically.

>> The next best (or actually better) thing would be a set of mail hosts
>> with reasonable connections to some decent DNS servers (could be the
>> same machine for any given region).  If your machine doesn't know the
>> destination site's IP address, it sends it to the local mail host and
>> lets it figure it out.  (I haven't seen any instances of mail hosts
>> in this area.  Are there any areas using one?)

>  Yep.  I call local mail hosts with term  "Intelligent Mailer".
>They have full knowledge of the network at their disposal, or very least
>they know that pseudo-domains .UUCP, and .BITNET are handled better elsewere.
>(But for Internet at large they are SMART beasts.)

As the above example showed, you might have two different mailers that
were "Intellegent" about different areas; one machine may know about
local ampr.org stuff while another might know other Internet (and Outernet :-)
routing.

>  Your point could be valid for direct connectivity, but MXes are different
>subject - and how to handle things like feed from USA to OH-land ?

The first problem is handling the physical feed problem :-).  After
that:

>Defining tertiary MX into US, trinary into Sweden, secondary and primary into
>Finland ?  Sounds simple, but isn't that usually.
>(It isn't easy to define 4 MXes for every of hundreds of hosts...)

Herein lies the problem.  It isn't filling in the MX records, but figuring
out what to fill them in with (don't you love ending a sentence with not
one but TWO prepositions!).  Ajacent countries/states shouldn't have too
much of a problem (Florida to Quebec?  Just keep pushing it north) but
getting it overseas is the real problem.  (I supposed you could push
it towards the nearest IP tunnel - if you know where it is.)

>Yes, mail routing can be a heck of a problem.

Not compared to connection routing!

We can at least use subdomaining for solving the mail routing problem to
fixed stations.  The mobile station is another problem (for another posting).

>>Don Koch

>	/Matti Aarnio <mea@utu.fi>  oh1mqk
>	   Postmaster on a high-trafic system

Don Koch
aardvark@nt1l.uucp
aardvark%nt1l.uucp@primerd.prime.com
aka: aardvark@primerd.prime.com
   (a postmaster on another high-traffic system)


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Tue, 9 Jul 91 23:53:22 EDT
Subject: NOS TMP Files



Enough has already been said about this but I just wanted to
say that I made the changes that Kelvin suggested to PC.C and awhile
back and with an enviroment variable defining the exact path - I.E.
TMP=c:\tmp - I have seen no problems in the code. No crashes - everything
works OK. I can change directories after openning temporary files etc.
The temp files open and close in the directory stated in the TMP
enviroment variable. I (and others) have this running in a number of
systems with similiar results. Not to say that there is not a problem
lurking but it has not shown up on my well used system.

Doug


----
From: gvdg@tophat.cdh.cdc.com
Date: Wed, 10 Jul 91 11:18:25 MDT
Subject: New(er) NOS 0618

Hello All,
Some good and some bad news.
I uploaded to ucsd.edu in /hamradio/ka9q/incoming and onto wb3ffv XBBS
my latest version of nos_0618 date stamp 0709.
Nos now compiles without any Warning messages from TCC 2.0.
I made suggested mods to tmpnam and its co-workers. It should all work
under C++ 2.0 as well. I don't have C++, still recovering from the 
international pricing of Borland. (a complementary copy would be welcome).
I also added N1BEE's mods for axheard and filter (minus the typo"s)(bhoe)
The f10 key is now also mappable with fkey. As long as not redefined it
will do its 'old trik'. Once remapped with fkey 68 "my faforite command"
only the defined escape ( ^] ) will work. Don't put esc ( ^[ / 0x1b )
in escape as you can forget more 'inteligent' work like vi.
Now the bad ones.
Apparently my connection to the internet filters ip 93 frames out so
my axip digi's don't work. Never made it to ah or vk land nor back.
The encap still has the problem picking the wrong address for the originating
station , not found yet. I will fix the netmask, was aready on its tail.
Details for encap problem:
IP address of system 44.137.1.8 , IP address of interface 129.179.122.10
Now a encap should look like 
ip 129.179.122.10 -> 131.41.71.250
ipip 44.137.1.8 -> 44.14.0.1
But the ipip is 129.179.122.10 -> 44.14.0.1
This destroyes the complete use of it. A remote station via my works correct.
Guess the guessing of a interface is wrong.
Final note about the name space. Forget you are on the internet. Now see to
setup a network like that (44.x.x.x in NOT interconnected !!!!!). Every main
node needs a link to its next main node (for domain , linking etc.) Now phone
lins are cheap in the USA but you need a lot of them before you never go into
a toll line. (then it is ticking) Oh, you want to do it by radio ???
Nice honycomb network takes 3 receivers and 1 xmitter per node (4k$)
Who is going to supply all that. ???? Forget it. If we are HAMS we improvice
until it works. If i need to write email to someone not connected , not born
or whatever, i know i am in deep trouble. I don't want a zillion records
to go trough before finding out he moved 5 minutes ago. (to ca....)
Hope to satisfy all (or a small part of it at least).
Regards, Gerard.
-- 
Internet: gvdg@tophat.cdh.cdc.com       |     Gerard J van der Grinten
UUCP:     gvdgpc!gvdg                   |     Control Data Bv.
Telephone: 0(+31)-70-3119703            |     Van Markenlaan 5
                                        |     2805 VL RIJSWIJK    Netherlands


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Tue, 9 Jul 91 19:48:24 EST
Subject: Oops... TMP files and Borland C++

I sent out a message yesterday with the C source for a module MKNAME.C
that was supposed to fix the temporary file creation problem when compiling
under Borland C++ 2.0; unfortunately, I had a little version control problem
and sent the wrong file.  The comment explaining the change to the MAKEFILE
is also now corrected ("$*.c" instead of "$<").  Sorry.  -- Mike

***** start module MKNAME.C *****

/* New module MKNAME.C
   for PA0GRI NOS 910618v1.7a (910625)

   This module MUST be compiled in such a way that it is forced into
   the _TEXT segment.  This can be accomplished by using the "-zC_TEXT"
   compiler switch with the Borland C++ 2.0 compiler.  I have put this
   switch in a special compilation rule in MAKEFILE for reasons explained
   below.  It is possible to make all of PC.C go into the _TEXT segment,
   but that might put too much in there and cause trouble for the compiler.
   The best way is to put in only what we need, and that is why this must
   be a new and separate module.

   To compile this module right, there must be a special compilation rule
   included in MAKEFILE:

!if (($(CC) == bcc) || ($(CC) == bccx) || ($(CC) == BCC) || ($(CC) == BCCX)) 
mkname.obj: mkname.c
	$(CC) -c $(MODEL) $(CFLAGS) -zC_TEXT $*.c
!endif

   The MAKEFILE must be modified to add MKNAME.OBJ to the list of PCOBJS.
   The file PC.TL must be modified to include MKNAME.OBJ in the list of
   files that are bound into PC.LIB by the librarian.

   The tmpnam() and __MKNAME() functions in the run-time library are in
   the same object module, so both have to replaced together.  Those below
   must be used instead of the ones in PC.C; therefore, both tmpnam() and
   __MKNAME() in PC.C should be removed, as should the declaration of the
   variable _tmpnum.  Since these functions are never called from within
   NOS, this module will be preprocessed to have no compilable code in it
   if the compiler is not the right one.

   The pascal calling convention specifies that symbols are converted to
   upper case and an underscore character is not automatically prepended.
   It is intended that the __MKNAME() DIRECTLY replace the function of the
   same name in the run-time library.  This __MKNAME() function is called
   from run-time library modules tmpnam(), which is being replaced, and
   from fclose(), which is not.  The whole point of this awful kludge is
   to avoid rewriting fclose(), which would be a lot worse than this.

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

*/

#ifdef __BORLANDC__
			/* This may also work using __TURBOC__, which is
			   always defined anyway if __BORLANDC__ is defined,
			   but I will leave it to someone else who actually
			   has the compiler to verify this.  -- N1BEE
			*/

#include <stdio.h>		/* for sprintf() */
#include <string.h>		/* for strlen() */

				/* These are the ANSI prototpyes, folks */
char far * near pascal __MKNAME(char far *, unsigned int);
char *tmpnam(char *);
char *getnenv(char *);

unsigned int _tmpnum = 0;


char far * near pascal __MKNAME(char far * tmpname,unsigned int tmpnum)
				/* Converted to modern C style  -- N1BEE */
{

	char *tmpdir,*p;
	static char staticname[80];

	if (tmpname == NULL)
		tmpname = staticname;

	p = tmpdir = getnenv("TMP");		/* get tempdir name */

	if (p[0] != '\0')
		p += strlen(p) - 1;		/* point to last character */

	sprintf(tmpname,"%s%sTMP%u.$$$",tmpdir,
			((*p != '/' && *p != '\\')? "/":""),tmpnum);

					/* Note that the default is to use root
					   if TMP= is not specified */

	return tmpname;
}

char *tmpnam (char *name)		/* Converted to modern C style */

{
	do
	{
		if (_tmpnum == 0xffff)
	 _tmpnum = 2;
		else
	 ++_tmpnum;

		name = __MKNAME(name,_tmpnum);
	}
	while (access(name,0) != -1);

	return name;
}

#endif

***** end module MKNAME.C *****


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Mon, 8 Jul 91 15:40:23 EST
Subject: NOS TMP file fix for Borland C++

After saying all last week that I was actually going to get around to doing
the correct fix for the temporary files problem that has been so bothering
Doug and others, here it is.  You need to break the tmpnam() and __MKNAME()
functions out of PC.C and get rid of them.  Then you use the new module
below which is called MKNAME.C, and you modify the MAKEFILE as explained in
the comments.  I have set this module so that it compiles into nothingness
unless the Borland C compiler is being used; that will probably be OK to
change (test for __TURBOC__ instead of __BORLANDC__), but I am not going to
take responsibility for that since I don't have the other compiler running
in a way that would let me test it.

-- Mike

***** Module MKNAME.C follows *****

/* New module MKNAME.C
   for PA0GRI NOS 910618v1.7a (910625)

   This module MUST be compiled in such a way that it is forced into
   the _TEXT segment.  This can be accomplished by using the "-zC_TEXT"
   compiler switch with the Borland C++ 2.0 compiler.  I have put this
   switch in a special compilation rule in MAKEFILE for reasons explained
   below.  It is possible to make all of PC.C go into the _TEXT segment,
   but that might put too much in there and cause trouble for the compiler.
   The best way is to put in only what we need, and that is why this must
   be a new and separate module.

   To compile this module right, there must be a special compilation rule
   included in MAKEFILE:

!if (($(CC) == bcc) || ($(CC) == bccx) || ($(CC) == BCC) || ($(CC) == BCCX)) 
mkname.obj: mkname.c
	$(CC) -c $(MODEL) $(CFLAGS) -zC_TEXT $<
!endif

   The MAKEFILE must be modified to add MKNAME.OBJ to the list of PCOBJS.
   The file PC.TL must be modified to include MKNAME.OBJ in the list of
   files that are bound into PC.LIB by the librarian.

   The tmpnam() and _MKNAME() functions in the run-time library are in
   the same object module, so both have to replaced together.  Those below
   must be used instead of the ones in PC.C; therefore, both tmpnam() and
   __MKNAME() in PC.C should be removed, as should the declaration of the
   variable _tmpnum.  Since these functions are never called from within
   NOS, this module will be preprocessed to have no compilable code in it
   if the compiler is not the right one.

   Note also that this function is named _MKNAME(), not __MKNAME().  It
   is intended that this function DIRECTLY replace the function of the
   same name in the run-time library.  This _MKNAME() function is called
   from run-time library modules tmpnam(), which is being replaced, and
   from fclose(), which is not.  The whole point of this awful kludge is
   to avoid rewriting fclose(), which would be a lot worse than this.

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

*/

#ifdef __BORLANDC__
			/* This may also work using __TURBOC__, which is
			   always defined anyway if __BORLANDC__ is defined,
			   but I will leave it to someone else who actually
			   has the compiler to verify this.  -- N1BEE
			*/

#include <stdio.h>		/* for sprintf() */
#include <string.h>		/* for strlen() */

				/* These are the ANSI prototpyes, folks */
char far * pascal near _MKNAME(char far *, unsigned int);
char *tmpnam(char *);
char *getnenv(char *);

unsigned int _tmpnum = 0;


char far * pascal near _MKNAME(char far * tmpname,unsigned int tmpnum)
				/* Converted to modern C style  -- N1BEE */
{

	char *tmpdir,*p;
	static char staticname[80];

	if (tmpname == NULL)
		tmpname = staticname;

	p = tmpdir = getnenv("TMP");		/* get tempdir name */

	if (p[0] != '\0')
		p += strlen(p) - 1;		/* point to last character */

	sprintf(tmpname,"%s%sTMP%u.$$$",tmpdir,
			((*p != '/' && *p != '\\')? "/":""),tmpnum);

					/* Note that the default is to use root
					   if TMP= is not specified */

	return tmpname;
}

char *tmpnam (char *name)		/* Converted to modern C style */

{
	do
	{
		if (_tmpnum == 0xffff)
	 _tmpnum = 2;
		else
	 ++_tmpnum;

		name = _MKNAME(name,_tmpnum);
	}
	while (access(name,0) != -1);

	return name;
}

#endif

***** End module MKNAME.C *****


----
From: Henk Peek <henkp@nikhefk.nikhef.nl>
Date: Wed, 10 Jul 91 14:27:17 MET
Subject: Re: New(er) NOS 0618

>From: gvdg@tophat.cdh.cdc.com

>Apparently my connection to the internet filters ip 93 frames out so
>my axip digi's don't work. Never made it to ah or vk land nor back.

Why don't use UDP? UDP hasn't much overhead and does checksumming.
With UDP there is no need to start the worm as root!
or are you all at machines that speak only ISO protocols?  :-)

Henk, PA0HZP

Ps: I missed the comment period of rfc1226.


----
From: bill@tuatara.uofs.edu (Bill Gunshannon)
Date: Wed, 10 Jul 91 8:41:54 EDT
Subject: Re: Managing ampr.net domain namespace

According to Don Koch:
> 
> 
> Acutally, I was thinking of country/state names.  Since the US is divided
> into call areas by number, your method could be moved to that level (e.g.,
> instead of ka.ampr.org, you could use w9.ampr.org).  Unfortunately, having
> a call from the 9 call district doesn't mean you still live there (in Phil's
> case, he is (was?) in 2 land and is moving (has moved?) to 6 land).  This
> is why I would suggest using standard 2 letter country (and then state)
> codes (e.g., fi.ampr.org or ma.us.ampr.org).

Well, here we go again.  Confusing NAME with ADDRESS.  I don't know about
anyone else, but I have no intention of changing "bill gunshannon" to
"bill gunshannon wilkes-barre pa usa".  Names and addresses are two totally
different animals.  Just because the BBS system uses the two inter-changably
doesn't make it right.  No FQDN on the INTERNET necessarily reflects the
correct location or proper routing information for a message addressed to it
and this has worked fine up til now.  When (IF?) AMPR.ORG is ever fully
connected, then the system will work the way it was designed.  Trying to
hack he system to do things it was never intended to do isn't the answer.
Trying to fix the real problem (inter-connectivity) is the answer.

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: Derrick C. Cole <cole@concert.net>
Date: Wed, 10 Jul 91 09:53:56 -0400
Subject: like to subscribe

SUBSCRIBE


----