🚀 go-pugleaf

From: pbarrow@shiva.eche.ualberta.ca (Paul Barrow)
Date: Sun, 23 Jun 91 20:40:47 PDT
Subject: PE!1CHL codes

 
The codes and documentation files for the PE1CHL version of NOS
as well as information about the SCC driver have been placed
in incoming/pe1chl on thumper.
 
Please send any messages about these files to: pabc@n5jxs.jsc.nasa.gov.
 
*73* - Paul, VE6ATS


----
From: hughes@hazel.eecs.ucdavis.edu (S. Hughes)
Date: Sun, 23 Jun 91 22:42:55 pdt
Subject: Re: GATEWAY/NETROM MBOX Problem

I have also seen the problem with the mbox.  I though it might just be
my compile since I had made a few changes.
What I've seen is when a ax25 connection comes in and requests a 'chat.'
Everything looks okay, but anything typed at the console doesn't go out
to the ax25 station until they do the escape char.  Incoming characters
are displayed on the console.
Hope this helps at least confirm the problem.

Shayne
hughes@hazel.ucdavis.edu


----
From: efb@suned1.Nswses.Navy.Mil (Everett F Batey II)
Date: Mon, 24 Jun 91 15:17:15 PDT
Subject: Re: DOS 5.0 and bccx

Sorry if I belabor a NON- Tcp-group problem .. BUT since a lot of impact 
seems to have come down from the happening of MSD 5.0, Maybe someone has
found a fix to MSC mouse2.com/.sys not giving a visible mouse in the 
Dosshell ??? /Ev/


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Mon, 24 Jun 91 12:12:25 EST
Subject: RE: DOS 5.0 and bccx

Mark's solution for getting BCCX running under MS-DOS 5.0 will not work on
all machines, especially if they do not have his four megabytes of memory.
What he is doing, in effect, is running the compiler with access to expanded
but not extended memory.  That is why he reports that "the BCCX compiler
worked much better under DOS 3.3" -- it used physical extended memory
rather than remapped extended-as-expanded memory.

I now have BCCX running very speedily in my machine with 2 MB RAM under
DOS 5.0, but I did this by trashing the supplied EMM386 driver and putting
back QEMM.  It is my considered opinion that the EMM386 driver is junk.
If I tried invoking it with the NOEMS parameter, leaving all of my memory
as extended and none expanded, BCCX failed with a message about an
incompatible expanded memory manager.  If I tried invoking EMM386 with
the RAM parameter, BCCX crashed with a general protection fault.  What I
learned from Mark's message is that this may be a difference between his
machine and mine, or may be a result of running in a 2 MB machine instead
of a 4 MB machine.  I don't know.

The most serious problem with EMM386 is that it does not work as the manual
says it should and as VCPI compatibility requires.  In particular, if it is
in use for mapping extended memory into upper memory (becuase it was invoked
with the RAM or NOEMS arguments), it will not use AUTO mode, even if that is
specified, but rather ON mode.

QEMM does this, does it right, does it better, and does it faster.

WARNING: Mark recommends using the -Qe and -Qx command line options when
invoking BCCX.  The manual (User's Guide, p. 181) cautions not to use the
-Qx command with BCCX.  In fact, it is ignored.  BCCX always uses extended
memory, or it fails.  However, I sent a message a few months ago about BCCX
trashing my hard drive, and the reason (never confirmed, but it was Borland's
best guess) was that I had invoked BCCX with the -lyx option, which lets the
linker (as opposed to the compiler) use extended memory.  The manual says
this is ignored also, but it is really not ignored if the linker is invoked
through the compiler (as it is in the NOS makefiles) instead of from the
command line.

It also happens that the linker when invoked through the compiler uses
extended memory whether the -lyx option is given or not, but the -lyx option
enables competing use of extended memory, since BCCX loads the TKERNEL
driver and then calls TLINK (not TLINKX, since TKERNEL is already loaded).
While this may have just locked up my computer under ordinary circumstances,
I had SMARTDRV caching the disk in extended memory, so TLINK, empowered by
the -lyx option given to BCCX, also decided to use that part of extended
memory where my disk cache was stored.  The rest, and my data, were history.

RECOMMENDATIONS:

1.  EMM386 is junk.  QEMM is better.  Use it instead.  You lose nothing.

2.  Never tell BCX or BCCX what you think it should be doing with the memory.
    If you have proper drivers loaded (HIMEM.SYS and QEMM), it knows what it
    is doing.  Don't use the -Qe, -Qx, -lye, or -lyx options when invoking
    BCX or BCCX.  At best they are ignored; at worst they are catastrophic.

3.  QEMM, when invoked with the DOS4 and RAM arguments, will correctly use
    the same memory as extended or expanded on call.  That is, it will report
    the same memory as available as both extended or expanded, and will
    give applications the proper handles.  This prevents trade-offs like
    Mark's choice of 4 MB as expanded, which is then unavailable as extended
    under EMM386 (despite the manual's assertion to the contrary).  This is
    a required VCPI feature, by the way.

4.  Load as many device drivers and TSRs as possible into upper memory, using
    the new DEVICEHIGH (in CONFIG.SYS) and LOADHIGH (in AUTOEXEC.BAT)
    statements.  If you are going to bother making upper memory, use it.
    Don't forget to issue the DOS=HIGH,UMB statement early in CONFIG.SYS.

5.  If you do stick with EMM386 instead of QEMM for some reason, don't
    trust it to do things right.  My AMI BIOS has setup in ROM at segment
    E000, but this is not needed once the machine is booted.  QEMM picked
    this up and put its EMS page frame at E000, but EMM386 did not and put
    its page frame at D000, reduding my upper memory by 64K.  Manually
    overriding this with the FRAME=E000 command line argument to EMM386
    fixed this, but I have low regard for operating systems that need to
    be in the hands of an experienced systems programmer to be installed
    correctly.

Flame off, I guess.  I never said "flame on," but I think it happened back
there somewhere without my noticing.

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


----
From: Anders.Klemets@cs.cmu.edu
Date: Tue, 25 Jun 91 00:45:54 -0400 (EDT)
Subject: Re: mbox forwarding problems

> As stated earlier, this problem happens with both G1EMM and PA0GRI
> variants of NOS.  I suspect it also occurs with vanilla NOS although
> we've never tested it.

Then please do so. And didn't the forwarding use to work correctly with
older versions? Using which version of G1EMM did you start experiencing
these problems?

I will not start looking for bugs in the mailbox code unless I know for
sure that they exist in the original KA9Q version. But I am afraid
someone else will have to try to find these bugs for a while since I
will be on vacation until the end of August. And I don't expect to have
much computer access while I am away.

73, Anders



----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Mon, 24 Jun 91 17:35:39 HST
Subject: mbox forwarding problems

We've noticed some problems with mailbox forwarding in both G1EMM and
PA0GRI versions of NOS.  When NOS is forwarding more than one message
to a BBS, the first message is usually sent properly.  However,
subsequent messages are sent using invalid SEND command lines.  In
most cases the TO token in the SP command line becomes a number
instead of the addresee.  When a WA7MBL BBS sees this, it misinterprets
the rest of the SP line and the message ends up being stored with
the sender name as the message subject.

The following is a log of an mbox forwarding session between
uhm.ampr.org (ah6bw-1) and kh6gpi.hi.usa.oc (running WA7MBL).

========
Net> AH6BW-1>KH6GPI <C C P>

AH6BW-1>KH6GPI <C C P>
AH6BW-1>KH6GPI <C C P>
KH6GPI>AH6BW-1 <I C P S0 R0>:
[MBL-5.13-H$]
KH6GPI BBS Honolulu, Hawaii
You have unread mail
KH6GPI BBS>

KH6GPI>AH6BW-1 <RR C P R0>
KH6GPI>AH6BW-1 <RR R R1>
KH6GPI>AH6BW-1 <I C P S1 R1>:
>

AH6BW-1>KH6GPI <RR R F R2>
AH6BW-1>KH6GPI <I C S1 R2>:
SP kj9u @ kh6gpi < kj9u 

AH6BW-1>KH6GPI <RR R F R3>
AH6BW-1>KH6GPI <I C S2 R3>:
test
>From kj9u@uhm.ampr.org Mon Jun 17 01:02:16 1991
Received: from uhm.ampr.org by uhm.ampr.org with SMTP
	id AA4047 ; Mon, 17 Jun 91 01:02:14 HST
Received: by uhm.ampr.org (901130 (G1EMM v1.6))
	id AA4044 ; Mon, 17 Jun 91 01:01:41 HST
Date: Mon, 17 Jun 
KH6GPI>AH6BW-1 <RR R R3>
AH6BW-1>KH6GPI <I C S3 R3>:
91 01:01:41 HST
Message-Id: <4045@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi
Subject: test

this was addressed to kj9u@kh6gpi

/EX

KH6GPI>AH6BW-1 <I C P S3 R4>:
>

AH6BW-1>KH6GPI <RR R F R4>
AH6BW-1>KH6GPI <I C S4 R4>:
SP 5
 < kj9u 

KH6GPI>AH6BW-1 <RR R R5>
KH6GPI>AH6BW-1 <I C P S4 R5>:
OK 15546

AH6BW-1>KH6GPI <RR R F R5>
KH6GPI>AH6BW-1 <RR R R6>
AH6BW-1>KH6GPI <I C S6 R5>:
 17 Jun 91 01:02:40 HST
Message-Id: <4049@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi.hi
Subject: another test

kj9u@kh6gpi.hi

/EX

Current msg# 1 : ?,A,B,C,D,E,F,G,H,I,J,K,L,N,R,S,T,U,V,W,Z >
KH6GPI>AH6BW-1 <RR R R7>
KH6GPI>AH6BW-1 <I C P S5 R7>:
>

KH6GPI>AH6BW-1 <RR R F R0>
KH6GPI>AH6BW-1 <I C P S6 R0>:
OK 15547

AH6BW-1>KH6GPI <RR R F R7>
KH6GPI>AH6BW-1 <RR R R1>
AH6BW-1>KH6GPI <I C S1 R7>:
n 91 01:03:14 HST
Message-Id: <4053@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi.hi.usa
Subject: test 3

usa

/EX

KH6GPI>AH6BW-1 <RR R R2>
KH6GPI>AH6BW-1 <I C P S7 R2>:
>

AH6BW-1>KH6GPI <RR R F R0>
AH6BW-1>KH6GPI <I C S2 R0>:
SP 7
 < kj9u 

AH6BW-1>KH6GPI <RR R F R1>
AH6BW-1>KH6GPI <I C S3 R1>:
test 4
>From kj9u@uhm.ampr.org Mon Jun 17 01:04:04 1991
Received: from uhm.ampr.org by uhm.ampr.org with SMTP
	id AA4059 ; Mon, 17 Jun 91 01:04:02 HST
Received: by uhm.ampr.org (901130 (G1EMM v1.6))
	id AA4056 ; Mon, 17 Jun 91 01:03:51 HST
Date: Mon, 17 Ju
KH6GPI>AH6BW-1 <RR R R4>
AH6BW-1>KH6GPI <I C S4 R1>:
n 91 01:03:51 HST
Message-Id: <4057@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi.hi.usa.oc
Subject: test 4

oc

/EX

KH6GPI>AH6BW-1 <RR R R5>
KH6GPI>AH6BW-1 <I C P S1 R5>:
>

AH6BW-1>KH6GPI <RR R F R2>
AH6BW-1>KH6GPI <I C S5 R2>:
F>

KH6GPI>AH6BW-1 <RR R R6>
KH6GPI>AH6BW-1 <I C P S2 R6>:
*** Done
>

AH6BW-1>KH6GPI <RR R F R3>
AH6BW-1>KH6GPI <D C P>
KH6GPI>AH6BW-1 <UA R F>
|B
|B::cmd:

=========
That was the mbox forwarding session.  Here's what the messages
actually looked like on kh6gpi.
=========

c kh6gpi
*** CONNECTED to KH6GPI
[MBL-5.13-H$]
KH6GPI BBS Honolulu, Hawaii
You have unread mail
KH6GPI BBS>
lm
 Msg# TS   Size TO     @ BBS  From   Date    Subject
15545 PN    458 KJ9U  @KH6GPI KJ9U   17-Jun  test
KH6GPI BBS>
rm
[15545] PY
Path: KH6GPI
Date: 17 Jun 91 11:16:36 Z
From: KJ9U
To: KJ9U@KH6GPI
Subject: test

>From kj9u@uhm.ampr.org Mon Jun 17 01:02:16 1991
Received: from uhm.ampr.org by uhm.ampr.org with SMTP
	id AA4047 ; Mon, 17 Jun 91 01:02:14 HST
Received: by uhm.ampr.org (901130 (G1EMM v1.6))
	id AA4044 ; Mon, 17 Jun 91 01:01:41 HST
Date: Mon, 17 Jun 91 01:01:41 HST
Message-Id: <4045@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi
Subject: test

this was addressed to kj9u@kh6gpi


KH6GPI BBS>
l< AH     b
*** DISCONNECTED

======
So the first message made it through ok.  But look at what happened
with the others.
======

cmd:|A
|A:AH6BW-1:cmd:k
g ax0 kh6gpi
cmd:Trying KH6GPI on ax0...  The escape character is: CTRL-X
AH6BW-1>KH6GPI <C C P>
KH6GPI>AH6BW-1 <UA R F>
mc off
MCON     was ON
cmd:k

Connected.

[MBL-5.13-H$]
KH6GPI BBS Honolulu, Hawaii
You have unread mail
KH6GPI BBS>
*** Invalid Command
KH6GPI BBS>
KH6GPI BBS>
l< AH6BW
KH6GPI BBS>
 Msg# TS   Size TO     @ BBS  From   Date    Subject
15544 PN    199 AH6BW         AH6BW  17-Jun  read your mail
15546 PN    503 5             AH6BW  17-Jun   < kj9u
15547 PN    484 6             AH6BW  17-Jun   < kj9u
15548 PN    486 7             AH6BW  17-Jun   < kj9u
KH6GPI BBS>
r 15546 15547 15548
[15546] PN
Path: KH6GPI
Date: 17 Jun 91 11:16:50 Z
From: AH6BW@KH6GPI.HI.USA.OC
To: 5
Subject:  < kj9u


another test
>From kj9u@uhm.ampr.org Mon Jun 17 01:03:05 1991
Received: from uhm.ampr.org by uhm.ampr.org with SMTP
        id AA4051 ; Mon, 17 Jun 91 01:03:03 HST
Received: by uhm.ampr.org (901130 (G1EMM v1.6))
        id AA408 ; Mon, 17 Jun 91 01:02:40 HST
Date: Mon, 17 Jun 91 01:02:40 HST
Message-Id: <4049@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi.hi
Subject: another test

kj9u@kh6gpi.hi


[15547] PN
Path: KH6GPI
Date: 17 Jun 91 11:17:06 Z
From: AH6BW@KH6GPI.HI.USA.OC
To: 6
Subject:  < kj9u


test 3
>From kj9u@uhm.ampr.org Mon Jun 17 01:03:32 1991
Received: from uhm.ampr.org by uhm.ampr.org with SMTP
        id AA4055 ; Mon, 17 Jun 91 01:03:30 HST
Received: by uhm.ampr.org (901130 (G1EMM v1.6))
        id AA4052 ; Mon, 17 Jun 91 01:03:14 HST
Date: Mon, 17 Jun 91 01:03:14 HST
Message-Id: <4053@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi.hi.usa
Subject: test 3

usa


[15548] PN
Path: KH6GPI
Date: 17 Jun 91 11:17:18 Z
From: AH6BW@KH6GPI.HI.USA.OC
To: 7
Subject:  < kj9u


test 4
>From kj9u@uhm.ampr.org Mon Jun 17 01:04:04 1991
Received: from uhm.ampr.org by uhm.ampr.org with SMTP
        id AA4059 ; Mon, 17 Jun 91 01:04:02 HST
Received: by uhm.ampr.org (901130 (G1EMM v1.6))
        id AA4056 ; Mon, 17 Jun 91 01:03:51 HST
Date: Mon, 17 Jun 91 01:03:51 HST
Message-Id: <4057@uhm.ampr.org>
From: kj9u@uhm.ampr.org
To: kj9u@kh6gpi.hi.usa.oc
Subject: test 4

oc


KH6GPI BBS>
k 15546 15547 15548
*** Msg # 15546 - Killed
*** Msg # 15547 - Killed
*** Msg # 15548 - Killed
KH6GPI BBS>
b
Disconnected Norma|

=======
The second, third, and fourth messages were addressed to 5, 6, and 7
respectively and the subject line is displayed as '< kj9u'.

However, the message contents and SMTP headers are intact.

In case anyone is wondering, the rewrite file looks like this:
=======
*@ampr.wslab.hawaii.edu $1@uhm.ampr.org r
*.ampr $1.ampr.org r
*%*@uhm.ampr.org $1@$2 r

*.noam $1.na r
*.us $1.usa.na r
*.usa $1.usa.na r

*.hi $1.hi.usa.oc r
*.hi.us $1.hi.usa.oc r
*.hi.usa $1.hi.usa.oc r

*.ampr.org $1.ampr.org

*@*.bitnet $1%$2.bitnet@uhunix.uhcc.hawaii.edu
*@*.uucp $1%$2.uucp@uhunix.uhcc.hawaii.edu
*@*.UUCP $1%$2.uucp@uhunix.uhcc.hawaii.edu

*@ah6bw* $1
*@kj9u.hi.usa.oc $1@kj9u.ampr.org
*@nh6of* bbsof
*@kh6jjx* bbsjjx
*@kh6gpi* bbsgpi
*@*.hi.usa.oc bbsunk

======
And the forward.bbs file looks like this:
======

nh6of
ax25 ax0 nh6of-1
nh6of
bbsof
all
--
kh6jjx
ax25 ax0 kh6jjx-10
kh6jjx
wh6bia
bbsjjx
--
kh6gpi
ax25 ax0 kh6gpi
kh6gpi
bbsgpi
--

=======

As stated earlier, this problem happens with both G1EMM and PA0GRI
variants of NOS.  I suspect it also occurs with vanilla NOS although
we've never tested it.

Anyone have a clue as to what's going on with this?



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


----