Conference hydra::amiga_v1

    Which program did you use for kermit transfer on the AMIGA
    side ?
    If it is Smokey, check if the transfer mode is IMAGE because I had
    a problem like that before and it was because the mode was settled
    wrong.
    
    Pier
    

    also remember to tell kermit that the file type (on the vax side)
    		KERMIT> set file type binary
    
    could also be the "chopping" being done by the terminal prog...disable
    (if possible) for arc files.

Re: .0

>    to copy to my amiga.  The file I received was no good.  I'm not
>    sure what the problem was. I know that at least one of the 3 files
>    in the archive was bad.  In any case, my disk got trashed and I had to
>    ostart over again.  The trahed disk was my 40M hard disk, so now,
>    a few days later, I am trying again - a bit more carefully.  

I haven't seen ARC corrupt a disk before, but I have seen it crash the
machine if the .arc file was badly mangled.

If what happened was:

	You run ARC while connected to your hard disk
	It seems to process awhile
	Your system crashes
	When you reboot, your hard disk seems to hang when first accessed

Then you didn't really loose your disk.  When you first access any disk
volume, AmigaDOS does a quick check to make sure that the disk appears
to be in a reasonable, consistent state.  If the disk fails this quick
test, AmigaDOS will attempt to rebuild the allocated block bitmap for
the disk.

The above process is called disk validation.  The disk validator can
fix a floppy up in just a few seconds.  However, fixing a hard disk
can take several minutes (maybe as much as a half hour!).  (By the way,
the 1.3 fast file system validates a hard disk about 20 times faster
than the 1.2 slow file system.)

One way to cause the disk validator to have to repair the disk is to
crash the machine while it is in the process of writing to the disk.

So, if your disk corruption problem followed the scenario that I
described, the disk would have been repaired automatically if you
waited long enough.

    re: .2
    SET FILE TYPE BINARY should only be necessary when uploading files
    to the VAX.  The sender knows how to handle the file, it's only the
    receiver that needs to be told...

    HERE IS THE PROCEDURE THAT WORKS FOR ME, IT HAS BEEN USED MANY,
    MANY TIMES.
    
    1.  First, if you are connecting to the VAX via a terminal server,
    when you first connect and get the "Local>" prompt, type:
        Local> Set Port Local Switch ^A (^A means control-A)
    
    This will let you get back into the server after logging into the
    system.
    
    2.  Log into your account on the system.  If you are on a server,
    type "^A".  This will bring you back into the Local> prompt.  Type:
         Local> Set Session Passall
         Local> Resume Session
    
    This allows all characters to be passed through the server.  If
    you do not do this, some control characters may not be passed through
    and any binary file transfer will fail.
    
    3.  After resuming your session, type the following commands:
         $ Set Terminal/eightbit/nobroadcast
    
    This sets your terminal port to 8 bits (not really necessary for
    Kermit but it is for Xmodem) and prevents the system from sending
    any messages to your terminal during the download which would hose
    it.
    
    4.  On your Amiga Online! program, set protocol to Kermit, File
    Type to Binary and Auto-chop off.  (Auto-chop actually is not used
    on Kermit in Online, but set it off anyway).
    
    5.  On the file you wish to download, convert it to variable, 510
    bytes by the command.
         $ CVTARC V filename.arc
    
    Do this on all your files you download.  If you use Xmodem, use
    CVTARC U filename.  I run VMS ARC first to make sure that the ARChived
    file is good.  There are a lot of bad files out there on the system
    and there is no point in downloading them if they won't work.  If
    you do de-ARC them under VMS, you must convert them to Stream_lf
    using the CVTARC U filename command.  Don't forget to change it
    back to Kermit format when done.
    
    6.  You are now ready for the download.  Run kermit and type the
    following commands:
    
         Kermit>Set Delay 20 (sets the delay for download to 20 seconds)
         Kermit>Set File Type Binary (I always do this, needed or not)
         Kermit> Send filename.ARC
    
    7.  Select RECEIVE from the ONLINE! protocal menu.  Type in the
    destination drive and subdirectory in the requestor window.  You
    do not need to type in the filename as this is transmitted via Kermit.
    
    8.  The file should now download and de-arc without further problem.
     If you have a noisy phone line, you may get a bad download as I
    have read that Kermit error-checking is not all-inclusive.  Also
    note that not all downloaded files work.  There are some that don't
    but Juggler does.
    
    9.  When I de-ARC, I use ARC X filename.ARC.  This has always worked
    for me.
    
    Good luck.  I now use XMODEM as it is a bit faster.  If you want
    info on that, send me a VAXMAIL at USFSHL::APPLEMAN and I will send
    the procedures to you.
    

    I'm having trouble getting CVTARC to run on this side of the pond.
    COPYing to my area from either TAPE or LEDS3 gives me access violation
    as soon as I try to run. Any ideas please ?
    

Don't RUN it. CVTARC needs to be executed as a "foriegn command".

First do this (in login.com if you don't want to do it every time):

	$ CVTARC  :== $device:[directory]CVTARC

	(ex.  $ CVTARC :== $user1:[guineau.amiga]CVTARC)
			   ^
			   |

			   Don't forget the "$"!!!

now you have a new command called, what else, CVTARC

now type:
	 $ CVTARC -u filename.arc or
	 $ CVTARC -v filename.arc

John

    Thanks. Trouble is I get all this Amy help and forget how good ole
    VMS does it!