Conference hydra::amiga_v1

Both SSU and UW protocols were incorporated into Mike Leibow's
"meshugana" emulator for the Amiga.  It's around somewhere.  In any
case, it already exists, and works fine on the Amiga.  If you can't find
it, I have Mike's number in Rochester and could give him a call.

Actually, if I were to do it again today, I wouldn't use SSU.  I used
SSU at the time, because there were no good PY/TW drivers, as there are
now.  Using the PY/TW driver pair that come with VMS, it is easy to
rolly our own multi-session protocol that doesn't have nearly the
overhead that SSU has.  The problem with SSU is that the protocol
requires a full turn-around handshake on all switch session commands,
which really eats up bandwidth if you want to do frequent session
changes, as well as seriously complicating the control flow of the
parser, since you have to wait for the ACK before transmitting data to
the newly selected session.  This is done to allow SSU to ride through
line errors with very little possibility of data going to the wrong
session.  It's so cleverly inefficient, it's patented.  On the other
hand, SSU does have the advantage of buying the flow control problem
for you, and providing a full 8-bit binary data path for each session.

Now, I have two other protocols implemented on VMS for multiple
sessions.   I haven't yet incorporated them into Whack due to a lack of
time and interest to make it a priority, but I do have VMS ends for
them.

1 - I have a minimal implementation of UW for VMS.  UW stands for "Unix
Windows" and has been in use for some years.  It has the advantage of
being portable for use on other systems.  However, it's not symmetrical,
so I find it architectually offensive.  I don't recall how flow control
is done in UW, it's been a long time.  I think they just XON/XOFF the
serial line, which means a hold screen in one session would hold all
other windows as a side-effect.

2 - I have a pretty good implementation of the "Pixette" protocol, a
prototype terminal of Digital's now defunct Eastern Research Lab.  This
protocol is so simple, I can give it here:

	^Pn - switch to session n

it's symmetrical.  Session creation, in either direction, is a side
effect of sending data to that session.  Session closure is simply
logging out the VMS end, and is under user control at the terminal end.
You simply close windows that you aren't using.  Flow control is
supposed to be done with XON/XOFF independently on each session, so to
do it properly requires that you go down to the interrupt level and
queue each session's incoming characters to a separate input queue, and
do the multiplexing there as well.  However, either end can simply
XON/XOFF the wire, and it should work okay, except for the hold-screen
side effect.

I'd recommend using this one.

Please post this mesasge to the NOTES conference.  I'm very busy on a
project now, but in a month or two I should have time to help out anyone
that want's to code the Amiga end.

    John,
    
    thanks for following up on that.  Interesting stuff.  Meshugena 
    doesn't support file transfers if I recall correctly.  I suspect
    most amiga users are looking for a way to do file transfers while
    doing other things like reading notes.
    
    SSU sounds like the right thing to use, given that it is a VMS 
    supported utility, and the newer terminals require it to use the
    multiple terminal session feature.  That makes it easier to convince
    system managers to install it.  Having an alternate of a more efficient
    method would be nice too.
    
    Hmmm.. I wonder if it would be possible to implement the protocol
    to talk to the SSU as sort of a serial device driver/handler/etc.
    so that the multiple sessions appear as different serial devices on
    the Amiga - that way you don't have to add SSU support to every
    terminal emulator.  And when line noise locks up your terminal
    emulator, the other terminal emulator doing the file transfer keeps
    running.  A bit wasteful of memory, but given the lack of sources
    for vt2xx and vt3xx terminal emulators for the Amiga...
    
    Dave

    Doesn't the Atari ST version of this (who's name escapes me but it was
    done by Jeff Lomicka) do file transfers as well as normal communication
    stuff at the same time?  I think it allows you to adjust which gets a
    higher priority.

On  wjg::amiga: there is a program called uw.exe (and the source uw.c).

This is a minimal Unix Windows implementation for VMS given to me by
Jeff Lomicka.

What does it do?

Download MESH.ARC (Meshugena). Install it on your amiga. Run it and log into
your VMS account.

Make a foreign command for uw ( $ uw :== $dev:[directory]uw) then double click
on the RIGHT mouse button in the Meshugena window. You will get a popup
requestor with some options. Select "Enable Sessions" and click OK. Now 
type $ uw  in the terminal window. This will "lock up" the Meshugena window
running uw.exe.

Now double click the right mouse button again and get the requestor. Click on
"Create Session". Bang! Another terminal pops up. Hit return in this window
to find a USERNAME prompt. Log in to your account. Now double click again. 
Select "Create Session" again. Another terminal pops up, hit return, log
into your account...

Get the picture?!?  

Multiple Sessions!

No download capability yet.

john

The version of Meshugena on wjg is 1.0.

Does anyone have a later version?  I've tried contacting Mike Leibow with
no luck. Does anyone know where he can be reached?

john

I don't know the exact differences between the two but I have
WHEAT.ARC which is a DEC internal only emulator with files
dated Aug 88. MESH.ARC has files dated May 88. Both are by Mike 
Leibow and if I remember correctly similar. From WHEAT.DOC:

****************************************************************************
*                                                                          *
*  Wheat V1.0 -- A **VT220 terminal emulator                               *
*  Copyright   1988                                                        *
*  By Michael S. Leibow                                                    *
*                                                                          *
*  This program is for DEC INTERNAL USE ONLY because it uses the TD/SMP    *
*  protocol for use with SSU and DECserver 200.  Please do not give this   *
*  program away to people who are not employees of Digital Equipment       *
*  corporation.                                                            *
*                                                                          *
*  Author:  Michael S. Leibow      18-Aug-1988                             *
*                                                                          *
* **  VT220 is a trademark of Digital Equipment Corporation.               *
*                                                                          *
****************************************************************************

This is also version 1.0 !
Dave

Looks like the only difference is that WHEAT uses VAX SSU while Meshugena 
uses UW.

I'll try out Wheat and SSU tonight.  UW was a bit slow even wih data compression
at 2400 baud...

john

    Wheat is pretty slow as well. I tried it 2400 baud to a terminal server
    - It works very well but is slow when multiple sessions are active
    (stuff coming to screen etc...).
    
    John

    Does anybody know if real live customers are using the DECserver SSU
    stuff to do multisession with terminals or terminal emulators?
    
    Its an interesting feature, but I haven't heard noises of
    wide-acceptance.
    
    regards,
    dennis

Wheat is definetly more stable than meshugena. Meshugena hangs and gurus my
machine. Wheat didn't hang or crash once and seemed to run a bit faster.


If SSU is not installed on your system, you will need privs to do it. I 
had to reboot WJG from home last night...

john

    Re: .9
    
    I know of some customers that are using the capability of SSU in the
    terminal servers. It isn't widely used however.
    
    Re: .10
    
    If you dial in to a DECserver as I do then the SSU capability is built
    into the software there. It can enabled via SET PORT MULISESSION ENABLE
    and nothing new needs added to the VMS system.
    
    John

    I may be becoming senile, but do I detect some "layer confusion" here?  
    
    The layers I refer to are embodied in TDSMP and SSU.  If you can run
    TDSMP over an async line to a server that supports it, you'll get multi
    session without a need for SSU;  SSU will only get you multiple
    terminals on a single host.  TDSMP to a server that supports it is far
    superior than SSU.
    
    
    p.s.  my only experience using this stuff is with SSU from a VT420
    through a single session server to a vax;  the performance stinks.
    
    
    John

    re .12:
    If I understand you right, TDSMP is the protocol used over the wire
    and SSU is the host side software that does multiple sessions.
    
    With a TDSMP server built into a terminal server, I can get multiple
    sessions to multiple hosts, rather than just being limited to multiple
    sessions on a single host.  The hosts, of course, would each have to have
    SSU installed.
    
    Is that about right?
    
    It sounds like it just didn't catch on due to unacceptable performance.
    
    thanks,
    dennis
 

    Almost right Dennis, the hosts accessed through the server that ran
    TDSMP on the async line wouldn't need SSU.  You would simply get
    multiple seesions from the server as you do today w/ Decserver 200s,
    etc., with multiple virtual circuits using LAT (or Telnet for that
    matter). 
    
    John

    Don't know about performance not been acceptable. When I was using a
    VT330 the other year, I tended to use it in multi-session mode as I
    could flip the screens and change context without destroying what was
    'on-screen' in the other session. 
    
    I never tried displaying both session simultaneously etc. More likely
    reading notes in one session and editing or what ever in the other
    session.
    
    These days I prefer a workstation on my desk.
    
    Mike