Conference hydra::amiga_v1

    $ CVTARC :==@MVCAD3::USER0:[AMIGA.TOOLS]CVTARC.EXE;
                ^
                `--- Change the "@" to "$"
                     [ @ on VMS = Amiga's EXECUTE; $ = RUN ]
    
    Also, the above will "work", but you really don't want to use a
    node reference here.  The above definition will cause your process
    to open a DECnet link to MVCAD3:: to "copy" the program into memory
    EVERY time you say CVTARC.  (And this is true even if you are on
    MVCAD3 at the time.)  Leave out the node name and specify your own
    device and directory to run it from your local file, it's a *LOT*
    faster that way...
    

    I just had to smile...but as .1 says...its as simple as defining
    it as a foreign command, just like xmodem, compress, etc...
    
    glad to see we're all human after all ;-)
    
    scott.

    re the bad headers...I think its because of the automaic "chopping"
    being done by the vt100/200...other programs (like comm1.3x) disable
    "chop" on ARC files...also from looking at the notes to the latest
    vt100 (2.8) ACS (who has done thae last two releases) changed the
    chopping function.
    
    chop is required (for those that know this, skip the rest) due to
    the padding done by some protocols...ie xmodem.  It pads the image
    out to an even 128 byte packet with nulls or ^Z depending on
    implementation.  Since ami wants executables to be the exact correct
    size, they "chop" off any NULL or ^Z bytes at the end of the
    transferred image.  this is why sometimes the last file in an arc
    gives a bad header message.   Some people but in a dummy last file
    to prevent problems.
    
    I switched back to vt100...(don't really need the big chars or
    vt200/240 stuff from home)...its smaller, has a lot of the features
    that made smokey 1.0 more attractive in the latest release, I have
    source, its PD, etc.  Plus...no more problems on xfers of ARC files
    by kermit OR Xmodem!
    
    scott

    OK, once I got CVTARC correctly defined, it works fine.  The converted
    file is in STREAM_LF format.
    
    I'll try some downloads tonight using Handshake/Xmodem.

    Thanks for the help.  By the way, Scott, Handshake is a really nice
    program... you should check it out.
    
    Ed.              
    

    I got some puzzling results the other day while comparing download
    times of XMODEM and KERMIT.  I took at fixed length file (MVCAD3::virusck)
    and ran CVTARC on it to convert it to stream_lf for downloading
    by XMODEM.  The download works fine but I got CRC failure on the
    file while dearcing.  I then downloaded the original fixed length
    version with KERMIT but still got the CRC failure while dearcing.
    Is it something I'm doing wrong or is it the original file?
    Incidentally, I'm using Smokey 0.6 for the download at 1200 baud
    on a Hayes modem.  Could the problems be attributed to a faulty
    phone line?  There are times when I see the download of the file
    pause for 15 seconds or more and I wonder if the protocols are having
    to resynchronize with each other due to static problems.

    use ARC or VMSSWEEP on VMS to check if the original file is intact.
    Even though KERMIT does retransmit bad packets, I've had files
    corrupted with no complaints from Kermit.  The way that works for
    me is to use ARC T whatever.arc on the VAX before downloading,
    and then do the same thing on the amiga after downloading.
    
    One gotcha on the amiga version of arc - do a ARC L whatever.ARC
    before testing it.  Testing an arc file with a corrupted directory
    will hang your CLI.
    
    -Dave

    re .6
    
    another reason you get these crc errors on the arc file is due to
    "chopping" the file...arc files should be left alone...it turns
    out the the original vt100 (hence smokey) were a bit too agressive
    in chopping files...use vms arc to add a file zzzzpad.txt (or some
    such name that comes alphabetically at the end of the arc file to
    give some extra padding...(crc error only on last file,right??)
    
    to smokey maintainer, look at the newest vt100 (2.8) to see a "fixed"
    chop scheme, or do like they do in Comm1.x, etc.  Don't chop if
    file ends in ".arc" (kind of a kludge, but it works...)
    
    scott.

    I did find another little quirk in preparing VMS files for downloading
    with Xmodem...
    
    I originally tried a version of CVTARC that had a size of 90+ blocks.
    This version would indeed produce a Stream_Lf version of a 510 byte
    block file, but Xmodem was unable to begin transferring the Stream_Lf
    file.
    
    I did a little looking around in various directories, and found
    that there were also two versions of Xmodem; one was 30+ blocks,
    the other was 90+ blocks.
    
    I also found another (77 block) version of CVTARC that works fine
    with the 90+ Xmodem.  The Xmodem and CVTARC files that worked for
    me are in LEDS3::USER6:[ACCIARDI.AMIGA].
    
    So, to summarize, the only combination that worked for me was the
    95 block Xmodem and the 77 block CVTARC.  I can't explain this,
    but I spent all eveneing trying different combinations.
    
    Ed.

This stuff all seems pretty inconsistant. I wish there was a real
good arc like and xmodem like pair which EVERYONE would adopt.

I have a 17 block xmodem and a 92 block cvtarc which aork ok. 

John

	Does anyone out there have a version of CVTARC.EXE that works under
	VMS V5.4-2? We just upgraded VMS and CVTARC no longer works.

	Pointer to EXE or sources please.


Thanks 8^)
Bob Dupre
SWA Sales Support

    RE: -1
    	Thanks for the pointer. All's well in CVTARC land now.
    
    Bob 8^)