Conference hydra::amiga_v1

    14-34 minutes at 19.2 Kbaud?  That IS slow.  I can download a 760 block
    Fred Fish disk at 1200 baud over the phone line in 1 hour.  At this
    rate you should be able to do the same thing in less than 5 minutes.  I
    would assume that the problem is in the speed of the protocol program
    and that's what's slowing you down.  I doubt if you could ever achieve true
    19.2 Kbaud transfer rate.
    
    I use Online! terminal emulator with Zmodem protocol.  Zmodem is
    supposed to be faster than Xmodem (plus it doesn't care about the VMS
    file format).  The increase in speed of Zmodem won't bring you up to
    19.2 but it should help a bit.
    
    

    Problem being, I can't find Zmodem for the Vaxmate(I*M compatible).
    One of the biggest slow downs seems to be extensive writes to disk during
    transfer... I don't believe you can control the transfer buffer size in
    Handshake.
    
    							Ed
     
    

Re: .2

>    One of the biggest slow downs seems to be extensive writes to disk during
>    transfer... 

The easiest way to solve that problem (if you have the memory) is to
download to the RAM: disk.

If you don't have enough memory, you might try the following:  If the
terminal program allows you to, download the file into a pipe while a
CLI tries to copy the pipe to the disk.  This should have the effect
of increasing the disk buffering of the terminal program.

For example,  in the terminal program begin the download into the file
"pipe:x".  Immediately, switch to a CLI and enter the command,
"copy pipe:x df0:foo.arc".

If the file you are downloading is an archive, you might even be able
to unpack the archive from the pipe without having to store it on disk.
Try something like:

	arc -x pipe:x

    Hi,
    
    1. VLT has an option for changing the amount of buffer used.
    
    2. Use cross-dos. This would mean putting a 5�" drive on the Amiga or
       finding a MSDOS machine at work that has a 3�" drive.
    
    Regards
    	Mike

    I have been lately taking my amiga 500 into work and hooking it up to
    our 3600 so I can download the latest fish disks. Using Zmodem at 9600
    to the microvax it takes 6 minutes for a typical Fish disk to transfer
    (A typical fish disk is around 400-500K in size).
    
    If you find that handshake is a bit limiting why try try some other
    comms packages such as VLT or JRCOMM.
    
    Shaun.
    

    Here's an offbeat idea.  Have you tried doing transfers at a slower
    baud?  Does the transfer protocol programs you are using show any
    errors during the transfer?  What I'm thinking is, maybe at such a high
    baud rate, the programs can't quite keep up or maybe the serial port on
    the amiga just can't handle 19.2 kb reliably.
    
    I know that this is kind of a wierd idea, but I base it on a problem I
    experienced once while a field service engineer in Kalamazoo, Michigan. 
    We had just upgraded a DEBNT ethernet interface on a 8800 to a DEBNA
    which is about 30% faster.  The customer had several Evans and
    Sutherland CAD stations attached to the e-net and served by the 8800. 
    Instead of speeding up transfers to the 8800, the DEBNA seemed to slow
    them down by about a factor of 10 or more.  Putting the DEBNT back in
    solved the problem.  After some troubleshooting with a LAN analyzer
    (not by me, but by other personnell in the office) and discussions with
    remote support, it was determined that the problem was that the e-net
    interfaces in the CAD stations were only single-buffered rather than
    double-buffered as in DEC interfaces.  The DEBNA was just too fast for
    them.  The buffer would fill and the next packet send to the CAD
    station would not get an acknowledge packet back.  The 8800 would then
    wait for a timer to expire before trying again, resulting in extremely
    low file transfer rates.  The solution was to set the timer in the
    Network Exec on the 8800 to a much lower value.
    
    What has all this got to do with your problem?  I don't know.  Probably
    nothing, but I find it hard to believe that the protocol programs could
    be slowing down your transfer rates by the amount they seem to be
    doing.  Like I said in my first reply, I would only expect to see about
    a 30% improvement with Zmodem over Xmodem (not scientifically arrived
    at, just a SWAG).
    
    Ken
    

     Thanks all,
    
    Last night, on my 1meg 500, I used ram: as my download path, as well as
    a ram drive on the vaxmate to try to speed things up, the result....
     Transfer of a >300k file in around 4 minutes.
     It is a bit of a pain to set up & maintain,(especially with multiple		
     files .. copy-delete-copy-delete...etc) however so I've found a
     zmodem program for the Vaxmate so I can use Jrcomm's sizable buffer with
     zmodem.
    	Boy, it's hard to believe that the disk read & writes can chew up so
     much time.
    	By the way, anyone out there familiar with MSDOS?
    	Can I increase the buffer for transfers by adding buffers to Config.sys?
    	Right now I believe buffers=6, I notice that the vaxmate has to read
    	quite often as well.
    								Thanks
    									Ed
    
    

One of the problems with the "normal" version of XModem is its use of ACK/NAK
to control transfer of packets.  A packet is transmitted and then, before the
next packet is sent, the transmitter must recieve an ACK for the packet.  The
net effect is a fairly long waiting period, esp. if the receiver must write
to disk before ACKing the packet.  Normally this is minor for a null modem
connection at 19.2K.  What does this have to do with your setup.. probably
nothing... however I would suggest you get a copy of the shareware program
PROCOMM for the Vaxmate which supports a multitude of protocols including
XModem, ZModem and Kermit.  

Just in case anyone is curious.. one of the ways ZModem increases its speed
over XModem is its use of a sliding window transmission protocol.  Essentially
what this means is you do not need to wait for an ACK on the packet just sent.
Instead you can send up to (normally) 5 packets before you must have received
the ACK.  When the oldest packet is ACKed the "window" is opened for another
packet to be sent.  If it is not ACKed within a certain timeframe it is
assumed not to have been received and it resent.  Again, the speed increase 
from this protocol is not incredibly big for a direct connect null modem
connection but try it sometime on a packet switched network and you will come
to really love sliding windows.

- Jeff

    I'm using PROCOMM now on the Vaxmate.....
    My version doesn't offer ZMODEM protocol.
    What version do you have?
    
    								Thanks 
    									Ed
    

I've been using Procomm for so long know that I don't remember off hand what
version it is.  I'll look it up tonight.  If I remember the history I received
a new version about one year ago that had some custom stuff including ZModem
put into it.  It may not be on the "normal" shareware version.

- Jeff

I guess from reading from .0 to this point I forgot on which side you the 
the problems with on the VAX---VAXmate side or the VAXmate----AMIGA side.  
if you are concerned with the VAXmate you can do two things 

	1. use MS-DOS ramdrive (if you have enough memory)
	2. or use the BUFFERS=20 
	              FILES = 20 on your config.sys file

the second option will not be as effective as the first one.

if the problem is on the amiga side do not forget to use the ADDBUFFER 
command and use like ADDBUFFER df1: 100 (again it assumes you have enough 
memory). I have tremendous improvement in downloads when useing the 
addbuffers (since the amiga drives are so sloooow).

...gss...
 

    
    Well, I tried out a number of these reply's and concluded.
    
      On a 1meg amiga, with a little over 500k showing for Free Ram, I
    couldn't use a ram disk on most of my transfers....
      However, transfering using ram disks on both ends is definately the way
    to go for speed.
      I tried use pipe as a download path to create a sort of pseudo buffer,
     and then quickly set up a copy to DF1:, but the transfer hung up after
    transfering 8k (I'll have to read up on the use of pipe:), this could
    be due to a misinterpatation on my part of the instructions I was given.
      Also using VLT, on the amiga and trying to set a larger buffer size
    from the menu, didn't work very well, since it doesn't multi-task (as
    far as I could tell) so I kept receiving -2 as a buffer size after
    setting it to 300k, guess there isn't much memory left over with this
    program (too many gadgets to use for my meager needs).
    	Jrcomm looked promising for setting a buffer size, but has some
    sort of problem transfering files between Procomm (my Vaxmate terminal
    prg.), there seems to be protocol incompatibilities.
    	What I finaly ended up doing is making a customized system disk for 
    the Amiga with the "Handshake" terminal program on it as well as all my
    compression programs (arc,zoo,lhwarp....etc), I then adjusted the
    buffer size in preferences to it's largest possible size ( I'm not sure
    if this helps with the terminal program), changed my start-up sequ. to
    addbuffers=100, and used a ram: drive on the Vaxmate for my "upload"
    files.
    	Results... a little larger than 700k in 12 min., almost a 50%
    improvement in speed.
    	I have a feeling that using the ram: drive on the Vaxmate had the
    most impact on this particular setup however.
    	I'll have to explore the pipe:x theory a little more....
    
    	All in all, a pretty enlightening expierience.
    
    	Too bad you can't adjust the buffer size in handshake.
    	Too bad I can't afford a ram board :'(.
    
    							Thanks 
    								Ed
     
    
    

When I want to download a large file to RAM: on my one meg Amiga, I fire up
AZcomm which is the smallest term program I have found with ZMODEM. Using the
ZMODEM continue, or restart, or whatever it is called, is also easier than on 
VLT.

Slight detour...

In fact, the other day I fired up VLT using a Scholar Plus modem and checked 
out the size of the programs I wanted to download. When I knew I wanted 
more RAM available, I just rebooted and started AZCOMM. From AZCOMM, I hit 
return and picked right up with the VMS prompt I had seen using VLT before 
rebooting. Sometimes things work in your favor. If this wasn't a fluke, 
then the designers of the AMIGA, Scholar-plus (and the telephone company?), 
VLT, and AZcomm should be congratulated for allowing an actual DWIW,
(Do What I Want)!

Dave

    Maybe related, maybe not...
    
    Back a couple of months ago, I got very interested in TSSNET
    (DECnet-Amiga) and talked with one of the developers at Syndesis about
    it.  He mentioned that they were using the ASDG serial cards because
    the Amiga serial port started having problems when the speed got up to
    19,200 (even some problems at 9600, but not as bad).  When they ran
    TSSNET on the regular A2000 serial port, the Amiga wasn't able to keep
    up and mucho packets were getting lost or corrupted.
    
    Could you be seeing symptoms of the same problem?  One would think that
    transfer times would be inversely proportional to the baud rate. 
    19,200 should be twice as fast as 9600 and 8 times as fast as 2400. 
    Maybe you could try a relatively short file at different baud rates and
    see if this is true.  If the transfer time isn't linear at high speeds,
    maybe there is a serial port problem.
    
    Well, it's a suggestion anyway...
    
    
    					John

    Re: .14
    
    Well, the 1.32 version (and later ones) of the serial.device should
    have no problems up to 19200 bps. I do transfer at 19200 bps here
    in the office with my lowly A500 and have only problems sending
    to the server, but that is probably a level/distance problem and
    can be fixed by using the right protocols (Kermit, ZModem). I have
    no problems at that speed with the Handshake or VLT emulations...
    
    I just wonder how far the TSSNET development has proceeded by now.
    Or should I start writting a DECnet-Amiga and stop waiting?
                                                                     
    Regards,
    <CB>

    Well, I hope TSSNET development is proceeding along well...
    I'm watching my mail for it! (Beta Version)
    
    ~Steve

re .15

Sorry for the digression but....

Your comment about decnet-amiga is quite interesting (apart from having to get
MIS provide a router instead of a terminal server for dial-in...).

Anyone have any ideas what the position would be if we (members of this conf)
managed to get the protocol info, and wrote a decnet-amiga amongst ourselfs.

Some points of the top of my head.

1. I believe it would become digital property
2. I don't believe we could ethically distribute it.
3. Maybe we would have to take the TSSnet approach and make each copy for
a specific address. 

Any other thoughts people?

Stan.

    re: .17
    
    Why write it in your spare time when there is a whole group of people
    somewhere in Littleton whose job is to get common VAX software running
    on PCs and Macintoshes?  The first reader of this conference who can
    make a strong business case to PCSG management can no doubt write
    his own ticket and get paid to work with Amigas.  (Think PCSG is
    still the name of the group...)
    
    Rumor has it that Macintoshes started getting attention from the
    corporation after one fellow wrote a midnight hack of either DECnet
    or some common network service like file transfer.  He now works
    at PCSG.
    
    Wes

Re .18

Good points. 

It is the PCSG btw (I support PCSA and MAC's).

How would we present a business case to PCSG management -

points....

- How many Amiga's are used in our customers sites 
- Have any of these asked for our plans in this area
- Is the Amiga considered to have a long life span (like MS-dos & OS/2)


I believe that TSSnet is going to be ported to amiga (rumor)

I believe BTW that we have a PCSG person in this conference.

I can't help feeling that it would be extremely difficult to get PCSG to
generate a decnet (and PCSA environment?) for our baby's!

Stan

    re .18:
    There was a significant population of MAC's out there AND customer demand
    enough to produce at least a couple of 3rd party DECnet-MAC products
    before DEC became interested.
    
    Can the same be said about the Amiga?
    
    Its going to have to be a very strong business case...
    
    However, DEC is more into third party relationships these days, 
    so that may be a more likely approach...
    
    regards,
    dennis

Just supposing...

'we' Wrote it as a midnight project (ala notes)

And the PCSG took it over.....

and offered it to the customer base....

and supported it....

This would not hurt the Amiga and indeed would perhaps promote it (for the
things it does so well).

And perhaps preserve the machine well into the 21st Century....

Stan.

    Does the fact that Amiga is the cheapest x-window server help the case?
    
    Chong.

    Re: .22, et al
    
    Well, this could help, but with the X/DECwindows terminals finally
    available, you would have a hard time convincing sales to push
    Amigas...
    
    I don't see PCSG doing a DECnet-Amiga any time soon. I do PCSA support
    here for a living and know some of the engineers, so I hope that
    I know whereof I speak.
    
    I'm not to sure of informed about DEC company policies, but since
    I'm "only" a temporary member of the workforce, would that cange
    any of the restrictions on a DECnet-Amiga project done by me/the
    Software Brewery? I mean, they even allowed me to be a member of
    the CBM booth at this years CeBIT...
    But a "midnight hack" presented in a nice and maintable form to
    PCSG might be just the ticket...
    
    Regards,
    
    <CB>

    
    one nit.
    
    DECnet-DOS is done by NAC (Networks & Communications) in Littleton,
    not by PCSG.
    
    -Dave  (DECnet-DOS support)

    Looks like we're discussing three areas here: 1) DECnet, 2) X-window
    support and 3) VMS Services for PC.  With the advent of X-window
    terminals (discussed by everybody BUT Digital), the argument FOR
    including Amigas in the development cycles lies elsewhere.  To me, the
    strongest is in the VMS Services area, since a 2000 can provide a
    worthy environment (at least as capable as the MAC).
    
    Perhaps, if the services were developed, the DECnet end of it would
    follow.

    re .25:
    VMS Services for PC is generally the name used for the VMS bits of
    PCSA.  Item 3 should read "DECnet PCSA Client for Amiga V1.0"
    in keeping with the current naming convention.
    
    X-Windows over DECnet will happen only after there IS a DECnet
    product, so lets leave that until later, plus X-windows isn't real 
    particular about what it needs for a transport layer.
    
    I see three areas of discussion here: 
    1) DECnet-Amiga V1.0,
    2) DECnet PCSA Client for Amiga V1.0, 
    3) DECnet PCSA Server for Amiga V1.0.
    
    Asynch DECnet-Amiga might be possible, but alot of work.  Most of it is
    in Microsoft C, but there's alot of MS-DOS/OS2/Intel specific code.
    
    What ethernet boards are available for the Amiga?
    Has anything happened further with the idea of having network vendors
    use the same interface to the network?  Anybody got a spec on it?
    
    Are there any reasonable symbolic debuggers available?
    (similar to symdeb on MS-DOS, or DDT on TOPS-10/20)
    
    Which C compiler and version is the closest match to Microsoft C 5.1?
    
    Since the PCSA pieces either require DECnet or ethernet, lets reduce
    the discussion, as a first step, to just:
    1) Async DECnet-Amiga, 
    2) Ethernet DECnet-Amiga.
    
    regards,
    dennis (DECnet-DOS engineering) (Amiga 1000 at home)
    

    Oh, NOOOOOOO!  Please, _please_, don't just slap together something
    out of MS-DOS bits and pieces.  Amiga's operating system has real
    device drivers, real multitasking, etc., etc.  I submit there is
    no technical reason holding back an Amiga-friendly port developed
    within the standard Amiga programming conventions.
    
    The hardware should shortly be there.  A few months ago Usenet was
    buzzing with the news that the Ameristar Ethernet board had been
    picked up by Commodore.  At the time, Ameristar offered Sun NFS
    services on Amiga.
    
    At the Siggraph convention this fall, I saw Dale Luck's X Windows
    product running both client and server tasks over Ethernet.  It
    was nice looking in monochrome, and unbelievable in color (beta
    version on a machine with Flicker Fixer.)
    
    Matt Dillon, a graduate student, has written networking software
    called DNET.  It allows multiple windows on an Amiga to control
    multiple processes on a BSD Unix machine over an asynch line.
    
    I take these examples to mean that writing parts of DECnet for Amiga
    would be quite do-able.  As the instigator of this current thread,
    I also think that the business side of the proposition would be
    more difficult than the technical side.
    
    Wes

Re .26 (At least I am not the only A1000 user...)

I am in agreement with what Dennis says about the order of construction.

Let's consider Asynch DECnet/Amiga (hey I like that - a product name!) first
- I believe the original DECnet/dos for I*B was Async only - Corrections 
welcomed - now look at the numbers of I*M's integrated using DECnet/dos 
(Look in PCSA notes file for details)

Now once that was done, the device drivers for Ethernet could be integrated.

Re .27

Re MS-dos port - It has it's good points and it's bad points.

From the bad side, the amigados O/S leaves MS-DOS for dead in as much as we
have a more VAX like environment - (maybe a port of DECnet/VAX? :-)   )

On the good side, all of the problems are sorted out, and it would make
things easier.

What do we want - a working kludge, or perfection, or....
Firstly a working kludge, followed shortly after by perfection....?

My 1c worth

Stan

    re .27:
    The current DECnet-DOS was originally a port of DECnet-Ultrix with
    system specific parts added as needed.  That's one of the advantages
    of 'C' code.  DECnet-OS/2 is a port of DECnet-DOS and used real device
    drivers, real multitasking, etc.  You port only the pieces that make
    sense and write the new pieces to take advantage of the new platform
    and you conform to the standard programming conventions for that 
    enviornment.  These are basic ground rules around here.
    
    Having Sun NFS and X Windows out there would help alot with the
    business side.  So would name recognition and more Amigas in Fortune
    500 companies.
    
    Writing parts of DECnet for the Amiga would be quite do-able based on
    your examples, assuming they are shipping robust products now and not
    just developer's kits.  I've seen the X Windows demo and was very
    impressed.                                      ^^^^
    
>    I take these examples to mean that writing parts of DECnet for Amiga
>    would be quite do-able.  As the instigator of this current thread,
>    I also think that the business side of the proposition would be
>    more difficult than the technical side.
 
    "more difficult"?  I'd call it a long uphill frustrating battle.
    Just look at Macintosh and OS/2 as examples, and even MS-DOS a few
    years back.
    
    Good luck,
    dennis
       
    

    re .27:
    The first release of DECnet-DOS was DECnet-Rainbow 1.0 which used
    async DDCMP over the Rainbow's comm port.  The IBM systems happened
    later after a long time fighting the business issues around doing
    DECnet for non-DEC hardware...And yes, async DDCMP happened first,
    followed by ethernet support in a later release for IBM PC's.
    
    I'm encouraged to see ethernet to parallel port boxes available for
    laptops.  That would at least give the Amiga 1000s and 500s a way of
    hooking up to the wire.  We didn't have that option back in the Rainbow
    days.
    
    regards,
    dennis  (glad to see there are other A1000 users still out there...)

OK The original comment has caused some interesting points to be made -
In fact this note would be a good advertisment for Notes per-sei.


Now to get this of the ground what do we do.

Fortune-500 companies - can anyone provide input on Amiga Population.

Would we be able to get any sources to provide templates - Over to you
Dennis.

I like the idea of a general (3 or four people) working on various bits of
the code - I would see a private notesfile being setup for co-ordination.

How many internal people would need (and make use) of DECnet/amiga.

After it's written what do we do...

Give it to DECUS
Give it to PCSG

Another 3.23 Cents worth.

Stan Gifford.

    my turn.
 
    Plan A:   
      Step 1.  Convince some Fortune 500 companies to buy lots of Amigas.
    
      Step 2.  Have them beat up on their sales reps because DEC doesn't
               support a DECnet-Amiga under the NAS program.
    
      Step 3.  .... maybe that will lead to support for it or more demands
               for a DEC developed DECnet-Amiga.
    
      Without Step 1, you aren't going to get very far unless you use
      the argument that it is needed for "strategic" reasons.
   
    Plan B.
    
      Step 1.  Develop it as a midnight hack.
    
      Step 2.  Demo it.  Release it for internal use only.
    
      Step 3.  Hope you don't get stomped on for doing it and are able
               to convince somebody that it should be funded and shipped
               as a real product.
    

    
    .32 was a bit cynical, so in keeping with the new spirit of posting
    only "positive" things to the notesfiles :-)
    
    I'm not a fan of midnight DECnet hacks, since I'm one of the somebodies
    that does DECnet support.
    
    I can think of one large, multinational company that uses VAXes and
    probably has lots of Amigas.... CBM.  Are any of their VAXes running
    VMS?  DECnet?
    
    -Dave
    

Re: .29

>                           I've seen the X Windows demo and was very
>    impressed.                                      ^^^^


Hi, dennis

You saw three things the night of the BCS SIGGRAPH invitational:

	1.  A demo of color X-Widows (under field test).

	2.  A demo of the X-Widows developer's library (still being
	    developed).

	3.  A demo of the black and white X-Widows that you could have
	    bought by handing Dale a check.

Re: .33

>    I can think of one large, multinational company that uses VAXes and
>    probably has lots of Amigas.... CBM.  Are any of their VAXes running
>    VMS?  DECnet?

It appears that they run some flavor of Unix.

    It seems to me that a number of products owe their existance to
    midnight hacks - notes is one of them (I believe).
    
    I think there would be two major factos when the 'product' was
    presented to Digital :-
    
    1.	Commodore is listed as a competitor ! (this is a negative)
    
    2.	It adds yet another vendor to the list we support as connectable !
    	( a plus)
    
    The other comment about giving it away to DECUS etc, well if it was
    developed by Digits while in Digital's employ and/or they used official
    Digital DECNET/DOS sources as a start point and in light ot point 1
    above - I'd suggest FORGET IT !
    
    I'm not trying to be negative etc, but you'd probably be better of
    using point 2 and 'selling' it to Digital as a viable product. Of
    course someone would have to prove that the Amiga was/is a serious
    machine and people don't have it just for playing games.
    
    I remember the original Rainbow async DECNET, how close would the
    sources be for that ?
    
    I'd love async DECNET for my AMI, no more KERMIT or XMODEM from home !
    It might even allow the Ami to get into some serious areas it can't now
    if it could be networked into the DIGITAL world !
    
    Regards
    	Mike
    
    (My 1 cents worth)

    Re: last dozen...
    
    Well, well.
    
    I'm pretty close to biting the bullet, read: go on and develop it.
    However, some more questions:
    
    1. How much (if any) support could I expect from DECnet engineering
    (Dave B.) in terms of paperware and (hopefully) C sources. How much
    would that cost me (see 3.)? 
                               
    2. How far is TSSNET? Will they support Ethernet in their first
    release? 
    
    3. I'm thinking of marketing the finished product via the assets
    library, unless the DECnet group/PCSG would jump on it.
    
    If these answer would be answered to my satisfaction (now don't
    go and ask me what THAT is ;-), I'll take the plunge and get me
    an ethernet board for my A500 (if already available) or one for
    my A2500, which in turn would mean the purchase of an A3000 to replace
    the ole A2500 at home. And yes, you folks assume correctly that
    I would include ethernet support. Since CBM bought all the stuff
    from AmeriStar, they should be able to supply me with all infos
    and sources I'd ask them for, so no problem here...
    
    Well, wadaya think?
    
    Regards,
    
    <CB
    

    Re: .37, et al
    
    Reading the PCSAV2 conference and re-reading this thread I realized
    that there is a Dennis and a Dave Brannon working at the DECnet-DOS
    group... And I started to think that I'm slowly going whopey. ;-)
    
    You two aren't by any chance related, or what?
    
    <CB>

    
>    Well, wadaya think?
    
>    Regards,
    
>   <CB
       ^
       |

Well, <CB>, I think your missing a bracket :-) :-)    


Seriously, Great idea!! Do it!!!

John

RE: .32

I think (sarcasm and all) Dave Brannon has the right idea. It may become a
reality in a resonable amount of time if it is done as a midnight project
(not a hack!). It is much more difficult to turn down the baby that appears
on the doorstep than decide up-front "not" to do it. 

RE: TSSNET

My understanding (from talking with D.Luck) is the Syndesis net *is* TSSNET
ported to the amiga. I believe there was an actual ship last June of the
asynch only version. It was *supposed* to appear with Ethernet support this
December. This info is from the SigGraph timeframe.

RE: XWindows

Dale said it would work with the Syndesis software.

At SigGraph Dale was demoing 2 X-Servers running at ONCE on the same amiga
(one B&W, one Color). One was connected to a HP machine with the motif style
interface. The other was connected to a microvax running ultrix. He had a 
calculator on the screen with a digital logo on it! Overall - most impressive.

RE: Midnight development...

I think that it might prove fatally difficult to try and over distribute the 
project. The level of communication (human) needed to get things that are
intimate working on the amiga would assure that a notes file based (human)
communication would greatly impede coordination and resolution of problems.

An exception might be if one person was doing the vast majority and other
were doing specific and very well bounded "tidbits."

I guess what I am saying is: <CB> - if you do it in Deutschland get local help
and you will be done much sooner, Mike McGhie - Get Kevin Manderson hot on the
idea and a few other down under, the Dennis and Dave team - there is probably
a greater concentration of network oriented folks in LKG than elsewhere, but
I these folks don't have much spare time.

RE: Competition

Seems to me that Apple and IBM are listed as competitors to... so what?

RE: DECUS

There have been lost of software developed by Digital folks and passed on 
to DECUS. This does not usually seem to be a problem. It might be thought 
of as the orphanage for the babies that digital *does* kick off the doorstep!

I would very much like to see the Amiga get a good DECnet implementation and
would do work to make it happen.

	Thanks,
		-SES

    re: related
    yes, Dave and Dennis Brannon are related - twins.
    One of the many DECnet products Dave supports is DECnet-DOS.
    Mere coincidence.
    
    re: async DECnet
    Have you ever used async DECnet at 2400 baud?  think about it...
    
    re: spare time
    Interesting concept.  My time to do midnight projects is greatly tied
    to the midnight project I'm already doing for DEC.  Plus my knowledge
    of the Amiga hasn't progressed beyond writing simple programs, mostly
    due to lack of spare time.
    
    My background in the DECnet-DOS group is mostly terminal emulation
    and CTERM protocol (used by VMS "set host" or Ultrix "dlogin").
    
    DECnet-DOS sources have been given out to internal engineering groups
    in the past for specific purposes - Marty DELNI::M_SPENCE is the person
    to contact - she decides if its appropriate to do so.  Those sources
    are "as is" with no implied support; though like any other group
    reasonable questions will get reasonable answers as time & resources
    permit.
    
    regards,
    dennis
    

Re -.1

Async-decnet at 2400 

I wondered when this would come up!

Modem history in Australia (from my perspective).

First we had 300/300 then 1200/75 then 1200/1200 (Schools of thought
indicated that 1200/1200 would be about the max on PTT lines.

I use a 2400/2400 modem now and its pretty reliable (so much for aformentioned
school of thought!)

You can now get 9600/9600 baud dial up modems that have been designed to 
run over PTT.
(They admitadly have their own protocols for error correction) What you end up
with is a clean line!) (With a true transfer rate +- 9600 Huh +9600? Yup they
also do compression.)
Now these modems are a little more expensive, however who remembers what
the price was originally for digital watches/calculaters!

I would say go for it, and make the speed switchable (I would not have thought
that <CB> wouldn't have made it switchable BTW).

We can live with 2400/2400 for now, and in the future move over to high speed
modems when they become available!

Stan.

BTW There are a lot of customers out there who use 2400/2400 async decnet/dos
to do PCSA work!!!!!!

    We've been using 9600 baud modems in our group for over a year, and we
    are currently in the process of upgrading to the latest v.32/v.42 units.

    I just finished a rather lengthy call to CBM Germany.
    
    What it boils down to is:
    
    1. CBM currently has no A500 Ethernet board.
    
    2. However, a British/German company has one, with software written
    by PeriHelion, read Tim King aka AmigaDOS author.
    
    3. The German partner claims to have DECnet support (and distributes
    the color X version from Dale Luck...)
    
    This lead me to the following conclusion/plan of action:
    
    I'm gonna have loooong talks to these folks and especially Dale
    Luck at the Euro DevCon in Paris in two weeks. Dale will hold two
    seminars concerning networking the Amiga.
    
    The results of these talks will determine wether I'll proceed or
    cancel any development.
    
    Regards,
    
    <CB>

    Well, I knew this question would show up sooner or later.
    
    Dave and Dennis aren't the only people working on/near DECnet who play
    with Amigas.  There's even me, (Phase V Network Management architect
    among other things).  I'd plan on implementing Phase V, not Phase IV,
    since its the wave of the future. TSSNET (if its based on TCI's DECnet
    reverse engineering) would be Phase IV. No one outside DEC could be
    implementing Phase V today.
    
    Anyway, there's other code to start from than just DECnet-DOS. For
    instance, one of the versions of DECnet (for router products) is
    written in C and runs on a 68000 (I have NO idea what cross compiler it
    uses). There's a small group of guys working on a "stripped down"
    version of Phase V that would run in small memory configurations...
    
    A little project planning needed here...
    
    1 What are the requirements?
    2 What resources are available? How many, how long...
    3 What happens when the project is done? DEC owns it, but what does DEC
      do with it? DECUS? probably not.
    4 Support, and other such details can follow later.
    
    Seems we need requirements, here's my list.
    
    1) Implement Phase V (gets us OSI not just DECnet)
    2) Devices supported? Asynch DDCMP over serial port? Its the only
       builtin port all Amigas have.
    3) End Node implementation of Routing.
    4) NSP or ISO Transport class 4 (which is right depends on when the
       code hits the street)
    5) Session Control
    6) DNS Clerk (Phase V Name server, required for all Phase V nodes,
       Clerks are the "users" of the nameserver, much easier than
       implementing a full nameserver)
    7) Network Management? Yah, can't really get out of this (I wish)
    8) UID & Time services.
    
    And now for the hard question. What applications?
    
    9)  Mail-11
    10) CTERM? aka SET HOST?
    11) FAL/DAP?
    12) VAXNotes?
    
    What will be hard to do are:
    
    Devices/data links. Drivers deal with the wierdness of devices. Not
    much chance to reuse existing stuff.
    
    Session Control (that's where DECnet and the operating system trip over
    each other)
    
    Applications, Network Management, and DNS are hard to judge (AmigaDOS
    knowledge needed to see how they fit into DOS).
    
    The rest (yes even Routing) should be reasonably easy since they don't
    interact with the OS much. Of course my definition of easy means
    man-years of work sometimes.
    
    This will be *interesting* to watch develop.
    
    Mark
    
    PS good luck CB.
    

    
    It's been a couple days since the last note... Why go after DECnet-DOS
    or TCI's DECnet, aren't they based on single tasking operating
    systems?   There is a "DECnet for OS/2" that is based on a multitasking
    operating system.  Version 1.0 has already shipped.  Assuming that
    is written in C, just write Amiga versions of the libraries it
    calls, recompile and relink, ta da, you're done.  Just a large matter
    of programming :-)
    
    And when/if a future version supports Phase V, you've already done
    most of the work needed to port it.
    
    -Dave
    (the other brannon :-) )

I _just_ received my beta versions of X11 T3.1 and TSSnet T1.0.  Needless to
say I am anxious to bring in my Amiga and get things running.  I am planning
to run DECnet asynch over the serial port of my VS3100.

The one thing that had kind of slipped my mind was getting a nodename/address
for my Amiga.  This certainly shouldn't be a problem, but what I was wondering
is if it might be possible to 'borrow' an existing nodename/address. I really
only plan on testing for a couple of months, and I didn't want to go through
the hassle of getting/removing my node, since it's not going to be permanent.  
Our group doesn't have any 'spares' so...

If this isn't possible (or if I'm breaking policy) please let me know, and I
will get the paperwork in today!

This should be a neat little setup. :^) ;^)

~Steve

    Is thre any new status information about the DECnet - AMIGA project
    after the Paris - DEVCON ?
    I am very interested in this project, even in doing some work.
    If there is a lokal group here in Germany, i'd like to become a member
    (if possible).
    
    Regards
    	Michael