| |
DB9ER > APPLE 27.02.97 22:04l 123 Lines 7415 Bytes #-10822 (0) @ EU
BID : 272734DB0EAM
Read: DH9MEC DJ3YQ DF5GI DB9SH GUEST DK3EL
Subj: Net/Mac2.3.62(JNOS)3/4.asc
Path: DB0AAB<DB0FSG<DB0IGL<DB0KCP<DB0ULM<DB0LX<DB0RBS<DB0SWR<DB0FP<DB0SON<
DB0SIF<DB0KH<DB0EAM
Sent: 970227/1817z @:DB0EAM.#HES.DEU.EU [Kassel TheBox DB8AS] $:272734DB0EAM
de DB9ER @ DB0EAM.#HES.DEU.EU (Dieter)
to APPLE @ EU
SLEEP <seconds> was added to allow users to put NET/Mac to sleep for some time.
Sometimes this seems to be necessary after sending a command (like RESET) to a
TNC. During the sleep period, which may last between 1 and 60 seconds, NET/Mac
will not service any ports.
NETMACICONS [ON|OFF] allows you to control the type of Icon that the NET/Mac
configurationfiles will have. When switched to ON, files like 'ftpusers',
'alias', 'hosts.net' and 'autoexec.net' will eventually get a NET/Mac-like Icon.
Some users did not like this because they would like to see TeachText or some
other file-editor launched (instead of NET/Mac) whenever they double-click on
the very file. When you decide to change the creator of the file to the NET/Mac
application, the filetype will still remain TEXT, so that any editor will be
able to edit the file. I myself changed the Icons to NET/Mac-like Icons, because
I feel these files are really NET/Mac configuration files, and therefore should
look like NET/Mac-documents. The default for NETMACICONS is ON.
System 7.1 has a bug in AddResMenu() that messes up the HELP-window. NET/Mac
now has it's own MyAddResMenu() to fix that. NET/Mac will check if it is running
under 7.1 and if so it uses it's own routines, otherwise the system's AddResMenu
will be used.
Under the 'Settings' menu a new item '...View Statistics' was installed.
This allows you to display a window, in which the realtime statistics are shown.
For some reason I don't understand yet, background tasks will slow down a lot
when this window is up, and therefore it 'self-destructs' in 15 seconds. I am
still looking for the cause of this and will try to solve the problem as soon as
possible.
APPLESHARE [<HOSTNAME> <PATH_TO_MQUEUE_FOLDER>] was implemented in version 2.3.10.
I wrote this command because I got sick of having to deal with badly performing
AppleTalk TCP/IP links. The bad links are caused by some 'DUP MBUF' problem,
which happens to occur much more on AppleTalk than on TNC-links. I think the
problem rises when an ACK for a frame was received before the frame itself has
been deleted from the outbound-frame-queue. Of course the chances, that this will
happen on AppleTalk are relatively large because of it's high speed. On my network
it happens most of the time when one of my Mac 512Ke's transfers SMTP-files to
the IIx or SE/30. The IIx and SE/30 seem to ACK so quick, that the 512 doesn't
have enough time to remove the transmitted frame from the queue. The new command
allows the 512 to directly put the file to be transmitted into the MQUEUE folder
of the IIx using AppleShare instead of the TCP/IP link. Sending out a 585K file
took 7 minutes over TCP/IP, while the transmission lasted only 2.5 minutes over
AppleShare. Bad links sometimes perform so bad, that I cannot get more than about
5K sent in ONE HOUR! For the time being, you can define only 1 AppleShare host.
In my case this did not appear to be a problem, because usually one Mac only
forwards mail to one of the others. This happens to be the case since in Holland
we are used to do hop-to-hop forwarding, and when mail comes in on one of the Macs
it will be forwarded to the 'next in line' and to the next etc. So only the 'next
in line' Mac has to be defined as AppleShare host. If for some reason the Apple-
Share volume appears to be not-online, then NET/Mac will use TCP/IP-forwarding
automatically.
| Suppose mail comes in at pa2aga for
| pa3ecp@pa2aga. The aliasfile of pa2aga
A | will reroute that to pa3ecp@pi8mac.
p |--- pa2aga on 433.025 MHz. -- TNC pa2aga has 1 AppleShare node: pi8mac,
p | so the mailfile will (if possible) be
l | alias: pa3ecp pa3ecp@pi8mac forwarded over an AppleShare link.
e |
T | pi8mac discovers the mail in it's own
a |--- pi8mac on 430.675 MHz. -- TNC mqueue-folder, while it is still
l | addressed to: pa3ecp@pi8mac, and will
k | alias: pa3ecp pa3ecp@pa2aga-2 send it over the loopback-link to
| itself. Then it will get aliassed to
c | pa3ecp@pa2aga-2, while pa2aga-2 is it's
a |--- pa2aga-2 on 1259.675 MHz. -- TNC known AppleShare node. Therefore, again
b | it will be sent over via AppleShare.
l | alias: pa3ecp pa3ecp@pa3ecp
e | Finally pa2aga-2 encounters mail for
| pa3ecp@pa2aga-2, and will send it to
itself. The mail will then be rerouted
to pa3ecp@pa3ecp and will finally be
delivered over the TNC-link. pa2aga-2
knows 1 AppleShare node: pa2aga
example of the APPLESHARE command as it is in the autoexec.net of pa2aga:
appleshare pi8mac "HD of PI8MAC:TCP/IP:spool:mqueue"
Note: AppleShare mail-delivery will take place ONLY if the file gets QUEUED by
NET/Mac (like in hop-to-hop forwarding). If you just typed a mail yourself, then
IM/Mac will queue it. Therefore the first hop will go over a TCP/IP link while all
next (AppleTalk-)hops may be using this AppleShare feature. I may decide to enhance
this, but will not do so until the system has proven to REALLY be an enhancement.
So far my AppleTalk TCP/IP links have been running well with this mod, and I'll
keep my fingers crossed!
We've tested this feature on standard AppleShare-volumes as well as TOPS-volumes.
NET/Mac 2.3.14 contains new AppleTalk drivers. So far these seem to be much more
reliable than the old drivers.
I just want you to know that:
1) You cannot mix NET/Mac 2.3.14 and pre-2.3.14 versions on 1 AppleTalk trunk,
because they will not be able to communicate with eachother
2) When one Mac on the AppleTalk link tries to send to another, while the other
one isn't running NET/Mac yet, the first one seems to freeze for maybe half
a minute or so, but don't panic... it will continue to run without problems
3) The new NET/Mac may be used to connect to an ethernet-LAN over a Shiva
FastPath or Cayman GatorBox. If no such gateway is discovered on the Apple-
Talk LAN, NET/Mac will report 'No AppleTalk Gateway was found' when processing
the 'attach' command for the AppleTalk port
NET/Mac 2.3.15 contains upgraded new AppleTalk drivers. Again you cannot mix 2.3.15
with earlier versions. Furthermore the last number in the attach-statement for the
AppleTalk interface cannot be larger than 586, so 600 is invalid for NET/Mac 2.3.15.
Dewayne WA8DZP, who sent me these fixes, wrote about hem:
'When you do a trace for an AT interface now, the AT addresses are displayed in the'
'standard net:node:socket convention for both source and destination. The maximum '
'packet size in the "attach at0" command should now be 586. This code will find any'
'host running NET/Mac who is in the same AT zone. This should be a BIG improvement '
'over the old LAP code that could only work over one network. '
Read previous mail | Read next mail
| |
