Conference hydra::amiga_v1

    I had the same problem a while back .Many of the files that are
    located throughout the net have been run through a process that
    takes an arced file and puts it in a format that can be dearced
    on the Vax .If I were to take an arced file from my amiga to the
    Vax and try to dearc it I would get the same error you are seeing
    on the Amiga .I believe the process is CVTARC.exe located in Dave
    Weckers account .When I move anything (up,or download) I always
    arc the files and then perform the transfer .If you can run arc
    on the file from the vax then chanches are you have to convert it
    before downloading .

    re.: .1  would you please have mercy on my eyes and follow these
    rules:
    
    1. the period that ends a sentence follows immediately the last
    character of the sentence.  
    	e.g.
    
	    This is a sentence.
    
    2. two spaces follow the period at the end of a sentence.
    	e.g. 
    
    	This is a sentence.  This is another sentence.
    
    
    Thankyou for your cooperation and support.
    
    

    re: .2  .picky, .picky, .picky...
    
    re: .1  downloaded files can arrive corrupted over semi-noisy
    lines using even Kermit.  The CRC can't detect errors that compute
    to the same CRC.  VMSSWEEP and CVTARC/ARC on VMS are a great sanity
    check on if the ARC was intact before you downloaded.
    
    -dave

    689.1
    I had the same problem but gave up.  Do  you have cvtarc.exe in
    your directory?  To 689.2.  Thanks for the laugh .I did not even
    notice the writing style of 689.1 until you mentioned it .I went
    back to take another look at 689.1 and cracked up .

    Sanity check procedure: (correct me if I'm wrong.)
    
    1 - copy arc file to your directory
    2 - run cvtarc against arc file
    3 - attempt to dearc on vax
    4 - if no errors then download to amiga
    

    It has been my understanding that CVTARC was written so that files
    readable on the Vax could be converted to a format required by kermit.
    If you type in the command to run CVTARC without any arguements
    you get info stating what the program needs.
    
    CVTARC u (infile) (outfile) !stream_lf for VAX
    CVTARC v (infile) (outfile) !fixed length records for kermit
    This was mentioned once in this notes file someware,in a discussion
    with D. Wecker about replacing VMSweep with ARC.(hell on punctuation
    but good on memory) I use kermit in image mode for all my transfers
    with the Vax and have had very good luck. I don't know about XMODEM.
    I know that if I download from "deep thought",or Plink using XMODEM,
    WXMODEM respectivly,and then upload to the vax I get header errors
    trying to dearc until I run CVTARC.
    
    bill
    

    
    Make sure you dial up on an 8-bit line.  If you use a line that
    strips off the 8'th bit, then your transfer won't work.
    
    I used to dial up to a lat-11 here that stripped the 8th bit, but
    now I know better...
    
    						--Mike

    Is it necessary to set the terminal on the vax to eight bit mode?
    $ set term/eightbit

    i always use  $ set term/nobroadcast/eightbit
    just to be safe.  I have it in a KERMIT.COM procedure that does
    the set term, then kermit, then set term/broadcast.
    

    RE: .0
    
    I get the same message, but its because I keep forgetting something.
    
    To transfer ARC files kermit must also be set to binary mode. I
    seem to always forget to do that. Lucky me, I always end up sitting
    thru two xfers.
    
    	$KERMIT
    	set file type binary
    	server
    
    If you are using VT100 from the amiga set the COM setup option to
    IMAGE.
    

    re. .2
    
    Thank you is comprised of two words; "Thank" and "you."

    I stand corrected  .Thankyou  .I mean "Thank" "you."  .No, better
    just make that thanks.
    

    As long as we're getting picky, a sentence should end with a period.
        John Sauter

    unless it's a question or exclamation.
    
    zzz...zzz........

    Another question about ARC.  I recently downloaded an arc file to
    ram: and began the download of a second larger file to ram:.  I
    then started up a new cli and tried to dearc the first file in ram:
    to disk.  The arc command failed and came up with the message "arc
    command file not found".  I reran the arc command with df0:c/arc
    and got the same message.  I first thought that the problem was
    a memory limitation but the workbench showed that I had 145K bytes
    left.  Anyway, after the second download finished and I shut down
    Smokey, the arc command suddenly worked!  Is there something mutually
    exclusive to running arc and Smokey together?  

re: .15

I have noticed this too.  While I didn't investigate much, I think that all of
the destination files of a single Kermit transfer remain busy until the the
entire transfer is complete.  It is inconvenient.

	Paul

    I've seen this with VT100 v2.6&7 too...