Conference hydra::amiga_v1

    
    The new version has been changed significantly in the area of the
    script language.
    
    The changes make the scripting much more powerful but are pretty much
    incompatible with the previous commands.  Therefore the authors have
    cautioned that previous scripts will most likely no longer work.  So
    you probably should not drop in the new version until you have had the
    opportunity to review the changes.
    
    Another big item is that the authors indicate that they have checked
    out VLT under WB 2.0 and that the icons and requestors have the 3d
    look.  They also mention that this version does not use the new
    features of WB 2.0 so you still need the extra libraries.
    

    Outside of the script language, what else has changed?
    
    ... Rich

    
    What's the difference between VLT and VLTjr?
    
    - Doug
    

    Hi Doug,
    
    No TEK stuff (definitely) and no arexx support (I think) in VLTjr.
    
    - steve

>What's the difference between VLT and VLTjr?

VLTjr leaves out the Tektronix graphics emulation which many people
don't use.

Dave

    
    Is anyone using VLTjr with VAX EMACS?
    
    Whenever I wipe a region, the screen display gets messed up. Does
    anyone know the correct settings to get this to work?
    
    - Doug
    

    Re: .2

    One significant change is that Kermit and XMODEM are no longer bundled
    with VLT; instead you need XPR-compatible versions of the latter,
    ie/ xprkermit.library. This makes things more flexible, but I don't
    recall seeing either one kicking around. According to the docs, there
    are versions of both on BIX.
    There's a lot of bug fixes listed, and one change I'm glad of is that
    now VLT behaves itself when used on a custom screen.

    Re: back a couple

    I believe VLTjr has and does support AREXX. I can't say I've tried it
    (not having AREXX), but with this new version I always get a requestor
    for volume 'rexx'. I haven't scoured the docs yet, but I never got that
    one before.

    Pete

The change to xprkermit is a minus, in my opinion. The menu entries & etc.
are still in place, so the user interface didn't change. But the xpr version
of kermit has been unreliable enough that I wouldn't use it before, and
there's not a new version of xprkermit for this.

There's been ARexx support in VLT for as long as I've been using it (the
previous three versions). I haven't looked at the new stuff yet, but
it should be much better, since it was designed with Rexx in mind, and
not tacked on at a later date.

The other major change is that there's now a menu of "user" commands.
You can set the command to be issued to VLT, and the string in the
menu.

Finally, there's now a way to get mouse more information out of the
mouse events - for instance, ctrl/meta/shift key status. When I've got
a working machine again, I'll hack up code so GNU Emacs will read
those events and act the same way as mg does on your local system.

There are probably other changes, but I can't go look at them...

	<mike

     I just upgraded to the new version without much difficulty.
     The number of files in the kit is intimidating and the warning
     about script changes set me up for a major effort. I don't
     have complicated dial in scripts but I only changed one command,
     fvbk "off" to no_screen_gadgets ( or something like that). All
     of the wait, delay, send, emit commands are still there.
     (non-arexx scripts)
     
     Seems nice so far.
     Dave

    You may find an XPR 2.0 implementation of the XMODEM protocol (with
    sources), for use with VLT(jr), by Marc Boucher as:

                       CRISTA""::AMIGA:XPRXMODEM.LZH

    Pete

       Anyone got XPRKERMIT??
       
       Art
       

    I have a version that came off a Fish disk (where else). I'll try to
    upload it tonight.
    
    John

>a version that came off a Fish disk (where else)

Unless it is on a very new Fish disk, it is usually available. For example:

$ copy TAPE::USER2:[AMIGA.FISH.Z300]FF330.ZOO  []

Copy it to your account and use (for example) the VMS ZOO:

To list the files:

$ zoo l ff330.zoo [.XPRKERMIT]*

I won't go into details for extracting the wanted files or deleting the 
unwanted files, but all of this can be done on VMS (and I assume ULTRIX) too. 

I don't know how fast John can upload part of a FF disk, but XPRKERMIT is 
already available and no one should have to download the whole FF disk
if they don't want to.

Just trying to save some space on TAPE::, WJG:: etc.

Dave

       re: .12 - John
       re: .13 - Dave
       
       Thanks for the offers and pointers.  I pulled FF330.zoo and now
       have the XPRKERMIT files.
       
       By the way, I did a directory of TAPE:: looking for XPRK*.* and
       found it in the RECALLED subdirectory.
       
       Thanks again,
       
       Art
       

    Seems like the nwe version (VLTjr (Non-Graphics) Version V4.824) has
    fixed the Kermit Bye command.  Now instead of exiting the Kermit server
    on the VAX it goes the whole way and logs out the VAX process.
    
    This may be the way it is intended to work, but, because there is no
    implementation of the Kermit Finish command (what Bye used to do) it is
    a complete pain in the neck.
    
    Anyone know a work around for this.
    
    By the way ... I can't see what all the excitement is about ZModem
    compared to Kermit with 1000 byte packets ... but I'm willing to be
    educated.
    
    Peter

    
�    Anyone know a work around for this.
    
    Besides *not* using server mode (yuk), I suppose spawning a subprocess
    before you invoke Kermit would at least keep you from being logged out
    of your main process.
    
�    By the way ... I can't see what all the excitement is about ZModem
�    compared to Kermit with 1000 byte packets ... but I'm willing to be
�    educated.
    
    Try it, you'll like it! I was a die-hard Kermit fan (even at 80 byte
    packets) until I tried zmodem. After having my share of problems with
    xmodem, I thought I'd never stray far from good old, reliable Kermit.
    Even if there's not much speed difference between zmodem and Kermit
    (using ~1K packets), it's a lot more convenient and just as reliable.
    It's not picky about file types, file names, and if your down/upload
    get's interupted mid-stream, you can restart at the point of
    interuption. Just the latter point can save a lot of hair pulling.
    And thanks to the recent flow control fixes to RZ/SZ by Steve McAfee (I
    think), I no longer have to change my zmodem defaults when my baud
    rate changes, not to mention a slight increase in xfer rates. Give it a
    try, since you can always go back...
    
    Pete

    re kermits bye..
    
    when I am using kermit (albeit mostly on a Compaq) I use Kermit via a
    spawned process (as the last reply indicated). A bye will then logout
    the spawned process and let you continue. The other way is to use
    FINISH in place of BYE. this will drop Kermit on the VAX back to the
    Kermit 32> prompt and then you can do what you like.
    
    However given a choice between kermit and any of the others (x/z modem
    etc) kermit is simply in a slow race all on its own. I only use Kermit
    when the others don't work, or when I need to do wildcard transfers -
    although a recent reply had a command procedure to 'add' this to
    zmodem. I havent tried this yet but will (thanks to the poster).
    
    regards
    k

>			or when I need to do wildcard transfers -
>    although a recent reply had a command procedure to 'add' this to
>    zmodem. I havent tried this yet but will (thanks to the poster).
    
    Now I know why I still use kermit.  'add'ing wildcarding via a
    command procedure sounds like a real kludge for something that should
    be part of the basic functionality.
    
    sigh...
    dennis
    

    re .16
    
>    Besides *not* using server mode (yuk), I suppose spawning a subprocess
>    before you invoke Kermit would at least keep you from being logged out
>    of your main process.
    
    Yes, it solves this problem but creates two others:
    
    When control is returned to the main process echo is turned off.  This
    is only an irritation since it can be restored by SET TERM/ECHO.
    
    The second effect is that from here on the left arrow, right arrow and
    delete keys no longer have the desired effect and I don't know how to
    restore their operation.  If anyone has experienced this (and knows how
    to fix it) let me know.
    
>    Try it, you'll like it! I was a die-hard Kermit fan (even at 80 byte
>    packets) until I tried zmodem. After having my share of problems with
>    xmodem, I thought I'd never stray far from good old, reliable Kermit.
>    Even if there's not much speed difference between zmodem and Kermit
>    (using ~1K packets), it's a lot more convenient and just as reliable.
>    It's not picky about file types, file names, and if your down/upload
>    get's interupted mid-stream, you can restart at the point of
>    interuption. Just the latter point can save a lot of hair pulling.
>    And thanks to the recent flow control fixes to RZ/SZ by Steve McAfee (I
>    think), I no longer have to change my zmodem defaults when my baud
>    rate changes, not to mention a slight increase in xfer rates. Give it a
>    try, since you can always go back...
    
    Given that there is not a performance difference of any consequence
    between the two (with 1K packets) then the situation seems to be this:
    
    ZModem advantage: Can restart broken transfers.
    	I don't ever remember having a broken transfer to work about.
    
    ZModem advantage: Not picky about filetypes.
    	This doesn't really worry me.  I just need to CVTARC V FILE.EXT
    	before transfer.  It certainly is an advantage, though minor.
    
    Kermit advantage: Can upload and download wildcards controlled from the
    	Amiga end.  Saves using a command procedure.  Does the command 
    	procedure work in both directions?
    
    Kermit advantages: In my perception ... 100% reliable, never gives me a
    	duff transfer, never hangs, has lots of features such as remote
    	commands, directories etc when used on a PC (which is also a
    	requirement for me).
    
    Kermit advantage: Can change from receive to send and back without
    	having to do anything on the VAX end.
    
    Major Kermit frustration: Current VLT implementation with no Kermit
    	FINISH command!!!
    
    I havn't had the time yet to try out ZModem but I will soon. I need to
    search this file to find out where the most functional versions of the
    software resides.
    
    I'm sure someone will be fairly quick to tell me I'm talking through my
    hat!!
    
    By the way if anyone is using a version of Kermit-32 on VAX that is
    more than a month or two old it won't support 1K packets; they should
    change to CKermit or the latest release of Kermit-32.  See the Kermit
    Conference for details of where to get these.
    
    Peter

    I think you forgot one of the most important differences between
    using KERMIT and ZMODEM -- ZMODEM doesn't care what the file types
    are. It's been a long time since I had to deal with that STREAM_LF
    and CVTARC issue.
    
    Also, as pointed out, ZMODEM doesn't log you off the system when
    done.

    re: "left arrow, right arrow and delete keys"
    
    Try SET TERM/LINE_EDIT
    

ZMODEM adjusts its block size on the fly based on the failure rate.
If you are in an area with bad phone lines this can dramatically
improve transfer times.  Also, the recover capability becomes more
important with bad phone lines.  VLT can automatically detect ZMODEM
transfers (maybe Kermit also, I don't know).  This means all you have
to do to transfer a file is issue the sz or rz command on the VAX.

If you are using Kermit, rather than doing a cvtarc v you can
issue the Kermit command SET FILE TYPE BLOCK.  Much easer :-).

Rather than clutter the Handshake note (4484.*) I thought I'd
move the VLT discussion to here.  

Summary:

VLT screen scrolling is not quite right using EVE in 48 line mode.

I think John is correct when he says it is related to holding the
the arrow keys down for repeat movement. I don't think this is
a vt200/vt100 mode mismatch which creates a lot more problems
than this.

So, does anyone who frequents the BIX amiga.user conference
want to report the bug to Willy Langeveld?  According to the
docs that is where he hangs out.

Meanwhile, I'm going to test different combinations of setups
to see if I can affect the bogus scrolling.

Dave

Re .23:

	I think I had a similar problem but it was very easy to solve.  If I
    remember correctly, VLT is normally set up for a 40 row screen.  When I
    told VMS that I had 40 rows, not 48, the problems went away.  It's been
    a while so I don;t remember exactly what the problem was or what I did,
    but I haven't had troulbe with any screen editor and VLT recently.

    Well I've seen VLT mess up scrolling in EVE without repeat and a 24
    line default display and terminal set to VT100.  It seems to occur
    during certain split screen scrolling operations.  The fix is to Ctrl-W
    and everything is okay.  If I get a chance, I'll try and see if I can
    catch the problem with SET HOST/LOG or some such thing.
    
    -tl