Conference hydra::amiga_v1

    terminal servers have been known to have their port configurations
    changed.  Kermit transfers worked fine for me for a long time, then
    all of a sudden they just died randomly.  The server I dial into had
    changed.  
    
    I changed the com file I use to startup kermit to:
    
    $ SET TERM/NOBROAD/EIGHT/PASTHRU
    $ run user1$:[brannon.unpack]kermit.exe
    $ SET TERM/BROAD/NOEIGHT/NOPASTHRU
    
    to make sure a) no broadcast message appear during the file transfers
                 b) set to 8 bits instead of the default 7 bits so that
                    binary files can be sent without having to use kermit
                    7 bit quoting
                 c) pasthru to tell the terminal server to keep it's mitts
                    off my data.
    
    That got downloads working for me, haven't tried uploads recently.
    
    Dave

    Dave,
    
    thanks for those - will try them next time.
    
    regards
    kevin

    Tried the SET TERM /NOBROAD/EIGH/PASTH but nothing different - still
    unable to upload except (slowly) with kermit.
    
    any other ideas???
    
    thanx 
    	kevin

    Can you give us more details as to what hardware is involved.  What
    kind of machine are you uploading to?  Are you using a direct terminal
    port or going through a terminal server, etc.?  What baud rates?
    
    Also, in what ways do the transfers fail?  Are you getting partial
    uploads that abort in the middle, or nothing at all?  Or perhaps you
    have trouble trying to use the files after uploading...?

    Hi,
    
    Hardware:
    
    	Either a VAX8550 or a VAX3500, via DECserver, at 19k2 and 9600.
        Also from either my AMI or a Compaq SLT286.
    
    With x/z modem sometimes the first packet gets thru, sometimes not. If
    the first gets thru I can usually manage about 30char per sec transfer 
    rate. The error message is usually is usually a timeout. 
    
    Kermit will get thru most times - but is even slower than kermit
    usually is. I figure this points at an 8bit problem but I can't find
    where I am doing anything wrong.
    
    Fortunately I don't upload very often :-}.
    
    	Thanx, 
    	kevin.

    hmm... assuming the SET TERM/EIGHT put your vax end into eightbit mode,
    and your terminal emulator is set for 8bit, then the DECserver
    is the problem.
    
    It could be that you are running into a problem with overloading
    the server - it might have problems with high speed file transfers
    swamping it's buffers.  Try dropping the line speed to say, 2400.
    Another thing to try is /PASSALL instead of /PASSTHRU.
    
    Dave

    will give that a go next time I have the ami in the office.
    
    thanx k

What is the difference between PASTHRU and PASSALL?

Dave

    
        Except for KERMIT, I also have never been able to get uploads to
    work as desired. I have to live in the 7-bit "TYMNET and server"
    world (which eliminates using XMODEM), but ZMODEM functions
    correctly. I do my downloads with Online! via ZMODEM -- this works
    great because of the "autostart" ability of Online! when VMS starts
    the transmission. This same feature has proved a hardship for my
    uploads however. Does anyone have this working on upload?

    Does any other communications program besides Online! support Zmodem?    
        
    Does anyone know how to change KERMIT's message size (say to 1k)?
    
    Taking 90 minutes to upload a file via KERMIT that is 1/3rd the
    size of an FF disk (which take 30-90 minutes to download at 1200
    baud) is very distasteful. There must another way.
        

    PASSALL places the port communications is a mode that prevents VMS
    from interpreting ANY character; in other words they are all passed
    on, no handshaking possible unless it's in the application program.
    
    PASSTHRU does the same thing, but will allow XON/XOFF ONLY to function
    (provided TTSYNC is enabvled also). Remaining characters are passed
    on.
    
    

    Here are a few suggestions...
    
    Check SYSGEN parameters on the VAX for TTY_TYPAHDSZ and TTY_ALTYPAHD,
    the default values for these may be too small for high speed uploading.
    I am currently using a value of 2000 for both on my system.
    
    When I upload via ZMODEM, I start the receiver (RZ) on the VAX end
    without any parameters.  Then start the sender (I'm using VLT) on the
    Amiga.
    
    There is an option in ZMODEM, FRAME SIZE or something like that, which
    causes the sender to wait for ACK responses to come back between
    frames.  This will help reduce data overruns, etc.

    OK  I just checked here - ~dsz is 78 and ~ahd is 200. I will try and
    get them increased.
    
    Will look into the others
    
    thanks
    k

    I'm using the latest VLTjr and I keep getting a transfer failure.
    The VMS side reports an "invalid device" type error.
    
    My sysgen parameters are as suggested.
    
    Any ideas?
    

    Re 3941.11 the sysgen params.
    
    You little beauty. xmodem works like a charm now. 
    
    a million thanx, plus a few.
    
    regards
       k

    How are you guys doing this??!?!?! I keep getting a VMS device error
    from RZ. I've even tried assign fake logicals that look like my
    amiga devices thinking it was because the filenames being sent included
    it. Can someone post a detailed step-by-step method of doing X/Y/Zmodem
    uploads that will work through TSN/WATN?  Thanks.

     
     Well these things do get tricky. I don't know what your device error
     is about, and I haven't followed this discussion in detail, but I can
     show you my terminal set up on VMS and the External Options I use
     in VLT.  I have SZ and RZ defined as foreign commands.
     RZ:==$MYDISK:[MYDIR.MYSUBDIR]RZ.EXE
     SZ:==$MYDISK:[MYDIR.MYSUBDIR]SZ.EXE
     
     I start by entering RZ at the DCL prompt. RZ then waits for
     action from VLT on the amiga. I pull down to send file from the
     transfer menu, which gives me a file requester where I type the name
     of the file to transfer. I click OK (or whatever) and it transfers
     the file to the VAX. When it is finished RZ returns to the DCL prompt.
     
     Going through TSN is very slow for large files even at 2400 baud. I
     gave up downloading large files, and never uploaded large files
     through TSN (22 char/sec average!). I can send quite a lot of text if
     I use lharc first though) The first "block(s)?/packet(s)? (probably in
     over my head here) do go quickly (about 220 char/sec).
     
     This is my terminal setting on VMS:
     
Terminal: _VTA210:    Device_Type: VT100         Owner: Dave Robinson
Physical terminal: _LTA238:                   Username: ROBINSON
LAT Server/Port: ZK34C5/LC-3-1

   Input:   9600      LFfill:  0      Width:  80      Parity: None
   Output:  9600      CRfill:  0      Page:   48      

Terminal Characteristics:
   Interactive        Echo               Type_ahead         No Escape
   No Hostsync        TTsync             Lowercase          Tab
   Wrap               Scope              No Remote          No Eightbit
   Broadcast          No Readsync        No Form            Fulldup
   No Modem           No Local_echo      No Autobaud        Hangup
   No Brdcstmbx       No DMA             No Altypeahd       Set_speed
   Line Editing       Overstrike editing No Fallback        No Dialup
   No Secure server   Disconnect         No Pasthru         No Syspassword
   No SIXEL Graphics  No Soft Characters No Printer Port    Application keypad
   ANSI_CRT           No Regis           No Block_mode      Advanced_video
   No Edit_mode       DEC_CRT            No DEC_CRT2        No DEC_CRT3
     
     
     Here are my settings in the Exteranl Options section of VLT:
     
Text Mode  -C        Delete after -off
Overwrite -N         Keep partial  on
I/O buff size -16    Send full path  off
Frame Size -0        Use received    -off
Autoactivate -on     Default      (my field is empty but I think RAM
                                   is set as the default somewhere else)


     BTW, I now use an FX number instead of TSN for off hours downloading.
     Ten times faster for large files!
     
     Dave
     ps. Thanks for the definition of Passal/pasthru.

    Do you send a file from any device and directory, or is your file
    always in the same directory as VLT or default?
    
    Also, what version is your RZ?
    
    
    Your VLT setting abilities appear different than what VLTjr offers
    (I don't remember a menu option for autoactivate or full path --
    probably the 2 things that are not working for me that I need).
    I'm going to try VLT instead tonight. If you think 2400 baud TSN
    is slow, try 1200 (112 chrs/sec). We don't have 2400 in Connecticut.
    Guess I have to move closer to work.
    
    
    BTW - what is FX?
    
    
    Thanks so far -- we'll get this licked yet.
    

         >  Do you send a file from any device and directory, or is your
           file
     
     When I get the file requester I just type in the file location.
     
     >      Also, what version is your RZ?
     
     I am not sure. I think I started using RZ around January or February
     of this year. I haven't changed anything since then.
     
     I am using the latest version of VLTjr but I just upgraded last week.
     
     FX is some kind of internal-to-DEC system where you can call a local
     (to you) FX number at a DEC site. This line then gives you a dial tone
     allowing you to dial a distant DTN, which for example may be the same
     number you are now accessing through TSN. I am sure there are others
     and other conferences that can explain in detail. 
     
     Dave

    DEC has dozens of "WATS" lines, used for making all the long distance
    calls essential to doing business.  These lines are billed on a flat
    rate basis, i.e. DEC pays $xxx per month regardless of how often the
    line is (or isn't) used.

    The "FX" (Foreign Exchange) system is an attempt to utilize otherwise
    idle WATS lines during off-peak hours.  Between the hours of 7pm to 7am
    weekdays, and 24 hours on weekends, some of the lines are switched to
    accept incoming calls.  The lines are connected (via the phone network)
    to "local" numbers in various remote areas ("foreign" exchanges).

    Dialing a nearby FX number gets you a DTN dial tone, you then use DEC's
    internal phone system to complete your call.  FX lines are intended
    specifically for modem connections.

    See the (JETSAM::)TSN conference, topic 181, for more information.

    I think I'm missing something. I assume you're selecting an external
    protocol in VLT; and I would guess it's xprxmodem. How do you declare
    these external options you've listed? I don't have these in the
    VLT pulldown menus. Am I missing something? I get the feeling that
    there's an xpr program I don't have.
    
    
    Concerning FX:
    
    I don't suppose there are any 800 or Connecticut local numbers?
    Or will I have to wait until I relocate to ZK? :-)

>I think I'm missing something. I assume you're selecting an external
>    protocol in VLT; and I would guess it's xprxmodem.

No, I am using xprZmodem, at least one version of which is available on 
WJG::AMIGA:XPRZMDM2.ZOO;2.  I don't remember how I originally set it up,
but I think it is in the docs. If not, then I got the info from this conference.
You could look for old VLT notes. I think it was relatively painless to set up.

>  I don't suppose there are any 800 or Connecticut local numbers?


Can't help ya there. 

>    Or will I have to wait until I relocate to ZK? :-)

There may be  more dialups in ZK than in CT. Software folks tend to
work strange hours, and often don't have to be near a particular "box" ;-}
No offense meant to the "nutmeg state"; as that tidbit reveals, I'm from there 
originally.

Dave

    I'll check it out -- thanks!
    
	VLT itself only has XMODEM and ZMODEM in its pulldown menu -
    so am I correct in assuming that when I select Zmodem as an external
    protocol that I'll also have the ability of selecting that "autostart"
    ability of zmodem downloading? Were the options you listed in the
    earlier reply settable via the EXTERNAL pulldown menu?

>Were the options you listed in the
  >  earlier reply settable via the EXTERNAL pulldown menu?

Yep.

    Hummm. They are not there in mine. Must be because you've selected
    the ZMODEM external protocol and VLT somehow is notified on these
    options. I'll download the XPRZMODEM tonight and see if that makes
    them appear.
    
    Thanks for your help -- I think I'm close.

    It works! Zmodem uploads! When you install the ZPRZMODEM and select
    it, the external pulldown menu provides the options for that protocol.
    Thanks for your help!

    
    I would recommend the following terminal settings for general PC to VAX
    communications - especially if ASCII captures are performed once
    in a while (or ascii sends).
    
    /TTSYNC/HOST/ALTTYPE
    
    /PASTHRU/NOBROADCAST may also be desired, depending on circumstance.
    
    My VLT options are the same as yours, expect I choose to let VLT
    do "Overwrite", and I don't want "Partial" keeps. I often prepare
    a download command procedure on VMS and let ZMODEM's "autostart"
    ability capture the files overnight (fish releases are often a good
    example), and these settings make script re-runs easier.
    
    
    I am now dropping Online for VLT with ZMODEM! Thanks again.
    

    Question: Is there anyway to take advantage of VLT's postscript
    ability in, let's say, ASCII, ReGIS, SIXEL, etc?

    Ooops; I should have said it sort of works. It works fine when I
    direct dial (which costs me $$$ because of long distance), but Zmodem
    (and sometimes but rarely, Kermit) fails to upload through TSN.
    Kermit or Zmodem downloads through TSN work fine, but uploads fail.
    I've tried various packet sizes, using TERM/ALT, setting the SYSGEN
    parameters - nothing seems to fix it. I exit with errors and a
    terminated TSN connection. Watching the modem lights, it looks like
    a handshaking problem - the VAX seems to send a"XOFF", the Amiga
    keeps send, then another XOFF, then a quick XOFF, then line dropped.
    (This is the proper way to handle a system failing to respond to
    XOFF).
    
    Any ideas? Have people actually tried binary Zmodem uploads through
    TSN?
    
    Keith

    Try typing ^X and ^R before logging into TSN.  This is supposed to
    enable some internal buffering on the network paths.  Also, you may
    need to limit ZMODEM's frame size to avoid data overrun.

    Well i spoke a bit to soon re the sysgen parms working....
    
    on ALICAT:: I was able to upload a .lzh file (it was the new virusx 
    that i used to check the upload with)  However I am now at a customer
    site and having heaps of probs trying to upload - same symptoms... Have
    tried setting the sysgen as before but no effect. In this case I am 
    using a compaq (how I hate braindead singletasking MSdos!!)with kermit 
    and xmodem. I will try a few more of the ideas here but it looks like 
    sneakeNET is going to start getting a thrashing....
    
    regards
    kevin