Conference 7.286::atarist

    uudecode, and the matching uuencode, are a sinple technique to avoid
    shipping non printing character around. Basically, 3 bytes of raw
    data are encoded in the low 6 bits of 4 characters. Decimal 32 is
    then added to each byte. Decoding reverses the operation.
    
    I picked up a BASIC program to do my initial decoding.
    
    The next step is to pick up arc.ttp and arcshell.prg ( Imight have
    the extensions wrong).
    
    arc takes a number of files, applies some data compression algorithm
    to each and produces a .ARC file. Alternatively, it extracts files
    from a .ARC file. There is a program arcx.ttp that only does
    extractions and has serious disadvantages. arcshell is a very nice
    interface to arc.
    
    There is also something called squeeze that you may need someday.
    
    You should try to get the compiled uud and uue programs because
    they work faster and better than the BASIC uudecode.
    
    I have not heard of .BINARY and I don't believe in it because file
    extensions can only be 3 characters. I think you may have
    misunderstood. Some programs are not encoded and therefore must
    be downloaded as binary images. .ARC files are also binary images.
    This means that you must be able to download binary images.
    
    I assume that whatever you intend to use is capable of binary transfers
    otherwise you are not going to get very far this weekend.
    

    .BINARY files are actualy UUEncoded files.  The files Martin Minow
    gets/has from USENET have either a .BINARY or .SOURCE extension
    which only serves to indicate which news group (source or binary)
    the files came from.  In most cases the files are actualy UUEncoded.
    
    I prefer to UUDecode UUE files on the Vax before downloading since
    it makes the files much smaller and therefore the download time
    is less.  The Vax program for UUDecoding can be copied from:
    	LIBRTY::USR:[WALLACE.PUBLIC.ST]UUDECODE.EXE
    
    	Ray

    Just a word of caution to over-eager prospective file transferers,
    and a request for further information.
    
    I'm sure it's cockpit error on my part, but could someone make
    absolutely certain (ie test it) that the uudecode.bas works.  I
    tried and was unable to get anything out of it that ran.  i'm very
    suspicious of code which was obviously translated from c to basic,
    and depends upon (or works around) "a bug" in atari basic.
    
    then, could someone, in step by step fashion, explain which files
    to transfer, in which order, to get the show on the road.  for example,
    i wanted to get whack over (because it appears to be flavour of
    the month, and furthermore appears to be capable of any further file
    transfers i might want to do.)    so, i:
    
    1.  used sterm which came on a pd disk with my atari, turned
    on logging, and copied over uudecode.bas (it interpreted, hooray!)          
    
    2.  now, i either need a uuencoded whack.prg, or a uuencoder which
    runs on vms (neither of which i could find)
                    -or-
     a uuencoded arc.prg, and a uuencoded whack.arc (neither of which
    i could find -- whack.arc appears to be non-uuencoded, not that
    it made any difference to me.)
    
    so where have i gone wrong; where have i stepped in it?

    is EVERY file which ends .UUE also ARCed.  is EVERY file which ends
    .ARC also uuencoded?  
    
    i hope i'm not the only dickhead out here who can't get this to
    work, or figure out a way to make it work; but then i can't fix
    a toaster either.
    
    						dd

    
    
    Hi,
    
    	I may be able to shed some light on a few of your questions
    but don't take anything I say as gospel as I am new to this as well.
    
    	About your uudecode.bas...I don't know if it will work but I
    have a copy of uudecode.ttp which does work and which you can copy
    from my account if you want. (It wont take long to copy as you are
    just up the road). As for .UUE files and .ARC files, I have been
    merrily copying pd software and as yet I have to find a .UUE file
    that HASN'T been an archive file when de-coded and on your other
    question I havn't un-archived a file yet that gave me .UUE files,
    is it possible?? I don't know.
    
    	Now for my questions, I have been trying to decode and un-archive
    files on the VAX (it must be quicker right??) the problem I have
    is that I do not know how to arrange the .UUE files. (most of the
    ones I have are originally from the USENET ( I think ) in the
    format V-------.BINARY and it appears that I may have to append
    some of them together. I have done this to some of them with success.
    However sometimes when I try to un-archive them using VMSSWEEP it
    says it could not find mark arc , or something along those lines.
    	Secondly when using VMSSWEEP I occasionally get CRC check failed,
    is this a genuine fault or is it just the VAX saying, I have un
    archived it but I dont really think I can run it???
    
    	Sorry for the barrage of questions but hopefully someday I will
    know enough to help others.
    
    Regards,
    
    		Jason.
    

    
    
    Jason
    
    I have found when using VMSSWEEP and getting a CRC failure that
    changing to 8 bit mode usually helps. Just type 8 to the prompt
    and try again.
    
    					Paul.

    What is this '8' command? I have VMSSWEEP which claims to be version
    2.8 and it rejects any attempt to enter an '8' as a command.
    
    Coincidently, I had a problem with the WHACK.ARC file on Jeff's
    account on PRNSYS::. When I downloaded it and tried to de-ARC on
    the ST the ARC.TTP program bombed. When I used VMSSWEEP it said
    it was stripping the 8'th bit and treating it as text. I was able
    to download and use the WHACK.PRG file in Jeff's account.
    

    
    
    Re -1
    
    The version I have is 3.1 which has an option for swapping between
    7 and 8 bit compression. Don't ask me what it means I'me just a
    user. Type ? and the options are displayed.
    
    					Paul.

    From where can I copy VMSSWEEP 3.1?
    

    RE .5, sorry, isn't a .ttp program a binary file?  so, remembering
    that all i have currently is sterm and uudecode.bas, how could i
    copy that across to the st?
    
    i think this is one of those things where i'm going to have to borrow
    a disk off someone who's already done this, and as i've had a kind
    offer, that's what i shall do.
    
    so my initial warning stands, to wit:  those who have yet to try
    this, as you can see by all the comments in this note, beware! 
    by far the easiest way to get this whole thing started is to copy
    someone else's disk which has at least a uudecode and a de-arcing
    program, and most probably kermit or whack or something like that.
    Then you'll be set for life.  or until you feel the need to buy
    something bigger and better, but slightly incompatible with your
    st!
    
    							dd

    Check the notes on Uniterm. I think that Ray has that in his
    directories in uuencoded form. Uniterm support both Xmodem and Kermit
    and so will let you download binaries.
    
    		Good Luck
    
    p.s. the uniterm files are large so you may need to copy them piece
    meal.
    

    re .9
    
    I found VMSSWEEP 3.1 in PEOVAX::PEOVAX$DUA0:[LEWIS.ATARI].
    

    RE: .4
    
    I have UUENCODE.EXE (and .C) which I probably copied from somewhere
    on MKTUP1::.  Using it, you could uuencode WHACK or KERMIT, transfer
    it the same way you transfered UUDECODE.BAS, uudecode it on the
    ST, and then be able to transfer files using WHACK or KERMIT.  So
    bootstrapping yourself without physically getting a disk from somebody
    else isn't that hard.
    							Larry

    re .-1
    
>        I have UUENCODE.EXE (and .C) which I probably copied from somewhere
>        on MKTUP1::.  


    is there a directory spec for that?  this is EXACTLY what i've been
    looking for.
    
>    So bootstrapping yourself without physically getting a disk from
>    somebody else isn't that hard. 

    sorry for being negative, but this is conjecture unless you've actually
    done it (ie used uuencode to encode, say, whack.prg, then used
    uudecode.bas on the other end to decode it) 
    
    i will try this and report my findings, same bat-note, different (?)
    bat-results.
    
    					dd 

    I too would like UUENCODE.EXE. I now have UUDECODE.EXE on the VAX
    but when I type "R UUDECODE" the VMS prompt dissapears and the screen
    just echo's everything I type. ^C gets me back to the VMS prompt.
    Can someone reply with the actual commands to UUDECODE.
     I guess when I get UUENCODE I'll be asking the same question!
    Thanks.
    Howard.

    Uudecode requires an input and output file name on the command line,
    otherwise it reads and writes to the terminal, typical unix behavior.
    Of course, you have (define, declare, assign?) it first like this:
                                                    
                $ UUDECODE :== $ UUDECODE$DISK:[UUDECODE$DIRECTORY]UUDECODE
    
    Then use it like this:
    
                $ UUDECODE INPUT_FILE_NAME OUTPUT_FILE_NAME
    
    /dana gould/

    
    
    Hello Howard,
    
    	I don't know all the commands but I know enough to get by.
    If you define something like 
    
    decode :== $directory_name:uudecode.exe
    
    and then at the dcl prompt type  "decode" followed by the name of
    the file you want to decode it appears to work.
    
    Maybe someone else can shed some light on more advanced commands?
    
    Jason.
    

    Oops, sorry, you don't need to specify an output name, that's at
    the beginning of the encoded file.  But you do need to define it
    so that you can specify the input file name.  As far as I know,
    there are no advanced commands.  Oh well, it's Monday morning.
    
    /dana gould/

    Thank you all. It now makes more sense AND it works!!
    ..Howard

    Both UUDECODE.EXE and UUENCODE.EXE are now available. They can be
    copied from: MILRAT::DISK$USER3:[WALLACE.PUBLIC.ST].
    
    Note, I use UUDECODE frequently but have never used UUENCODE.
    
    	Ray

                             -< HELP Xmodem >-

    
    I have Xmodem on ST and Xmodem on VAX. But when I type send
    it halts after a while. When I look in the logfile in VAX it say's
    something about not receiving ACK, decimal 0.

    Are there different versions of Xmodem ?

    Please, could anyone help me sort this out !

    HG    
   
    

I accomplished an XMODEM transfer once using Uniterm and the VMS XMODEM
in my [...ST] area.  What are you using at the ST end?

At the ST end I have a comm. package K-COMM with XMODEM in it.

I am wondering whether X-MODEM maybe only can manage some kind of
binary files for example "fixed length 128 byte records".

In that case I would be very grateful if someone could let me know
where I can find a program for doing transversion.

I have copied some good stuff (Thanks to you all who have contributed
to that) but I cant get it downloaded, and the only option I have
is X-MODEM !

If I ever get down KERMIT or WHACK I will use that !

Regards,

HG

X-MODEM is no longer a problem.

I've received a copy of GEM-KERMIT so I have skipped X-MODEM, but still
if anyone can answer my question in earlier replies I would be grateful
I am curius to know what I did wrong.

Regards,

HG 

Re: Xmodem

How were you connected to the VMS system - directly, LAT, TSN, etc?

Xmodem can only be reliably used on transparent connections which rules LAT
and TSN out.

If there is a VMS implementation, try Zmodem.  It is MUCH faster than kermit
and can handle non-transparent connections.  It can also recover if the
connection breaks during a transfer and you restart.  The ST end of Zmodem
is DSZ which was recently posted to comp.{binaries,sources}.atari.st.

mike

        I fought with xmodem for a while too. One thing I did find was
    that the file name must be about 8 characters of so long otherwise
    VMS xmodem just sits there logging errors.

    I'm planning to bring in my ST to Digital one of these days, and
    to do some downloading.
    So then I will use Uniterm (kermit) on the ST and Kermit on a VAX to
    get some .arc files from my directory to the ST.
    
    My question is now:
    What will be the speed of data exchange (bytes/sec.).
    Or, how long does it take to download 300 kbyte of data.
    (Speed between the vax and terminal is 9600 bits/sec. so this shouldn't
    cause problems, I think the question will be: How fast is kermit
    {or is there a better, faster way}).
    
    Thanks in advance
    
                         Jan-Willem
    

>                            -< What's the speed ?? >-

I've had no problem using UNITERM and the ST at 9600 connected to a vax.
I even had great success one time at 19200.

CHad

    Hey Jan W.
    
    Dont forget ,if you connect to a lat, to  Local> SET FLOW XON, and
    to do a  Kermit32> server, and then in uniterm use the PUT (ST>VAX)
    and GET (VAX>ST) with BINary mode selected. 
    
    Anyway that was giving me a little problems in the beginning.
    
    ����Martin
    
    

    The STRANSF protocol which WHACK implements is much more efficient
    than Kermit.  Kermit's packets contain a maximum of about 90 data
    bytes.  The the amount of protocol per data byte is very significant
    using kermit (about 1 byte per 40).
    
    Whack does 1K transfers, I think, and the protocol overhead is minimal.
    
    Steph

    
    Thanks for the answers.
    I know Whack should work better, but I don't have it (and since
    I'm leaving DEC at the end of this month it's no use downloading
    it (whack=for digital internal use only)).
    
    My main question is still unanswered:
    How long does it take to get 300kbyte from my VAX-account to my
    ST, using kermit?
    (Is it 15 minutes, 1 hour, 2 hours, or ... ???????)
    
               Jan-Willem

    That would take me 90 minutes on my 1200 baud modem. The way I estimate
    the time is: Do dir/size. Multiply block size by 512. Divide this
    number by 56 which is about the transfer rate across the modem.
    Finally divide by 60 for number of minutes. It's accurate to a minute
    or so. Of course if I could remember the constant 3.35 I'd divide the 
    number of kilobytes by 3.35 for number of minutes!!
    ...Howard

    
    Oke,
    So the speed is: 300Kbyte/90 minutes=55.5 bytes/sec.
    Speed of the modem is 1200bits/sec. =150  bytes/sec.
    
    So it looks as kermit is the bottle-neck for speed !?
    I'm afraid that my 9600 bits/sec. line will give about the same
    speed as downloading through a 1200 bits/sec. line.
    (I hope I'm wrong about this).
    
            Jan-Willem  8-(

    I recently got a program called SHADOW from Antic's The Catalog.
    It's a background file transfer program which is reset proof and
    includes a reset proof RAMdisk.  It seems fairly solid with two
    exceptions.  First it doesn't get along with CLI.ACC from START,
    and if the buffer reserved for holding downloads fills up you
    are out of luck.  With a 100K buffer this is rarely an issue.
    
    The nice thing about background downloading is the ability to
    examine something you just downloaded while in the process of
    downloading something else.
    
    BTW what is Batch Ymodem?
    
    Martin H.

  My experience on a VAX and ST with UNITERM/KERMIT and VAX-KERMIT is that
  9600 is much faster than 1200, etc etc etc.  One night a friend and I
  at school downloaded many ss disks worth in a few hours at 9600 including
  dearcing and copying onto floppy (download was into a RAMdisk) and also
  formatting 4-5 RD53 drives on a uVAX II to distract me.

  For best response, if you have the memory, make a good size RAMdisk and
  do all your copying into that first.  You can go 565K-585K on a 1 meg
  machine and UNITERM V2.0C for a RAMdisk.  That allows you to bring down a
  disks worth or so and then dearc it in RAMdisk and then copy onto floppy.

CHad

>    Whack does 1K transfers, I think, and the protocol overhead is minimal.

Whack sends data in 255-byte packets with an overhead of 7 bytes per
packet.  Each packet has a 1-byte byte count.  Where Whack get's it's
speed over Kermit is in two ways:

1. Whack doesn't bother with ACK messages.  It relies on the underlying
communication layer (SSU and XON/XOFF) to perform flow control, and
sends a NAK message if it gets a packet sequence error or a CRC error. 
In Kermit, after sending each 90-byte packet, KERMIT sits and WAITS for
a reply.  You loose a lot of time waiting for these replies, but this
means Kermit works reliably on lines that have no flow control.

2. Whack assumes the wire is full 8-bit.  Kermit has 8-bit modes, but I
think it often assumes that only 7 bits of the wire are good, and has to
pack the data accordingly.

KERMIT's bottleneck is still come port baud rate.  Kermit does get
faster with faster lines, partially because the time spent waiting for
the ACK messages is reduced.

    Ok, well I know that a variant of Xmodem (Ymodem or Zmodem) does
    provide a 1K block size if all is set up correctly, and a minimum
    of protocol.  The error recovery techniques are not very good, at
    least for Xmodem.
    
    Unfortunately, I haven't done any VAX Xmodem transfers, so all I
    can says is that IF you get it going, it will probably be considerably
    more efficient than Kermit.
    
    Steph

    
    
    re; .34
    
    If you receive data to RAM-DISK you will acheive a throughput of
    approximately 230 characters/second using KERMIT at 9600 baud. This
    means you could transfer 300K in less than 25 minutes.
    
    
    Andy
    

    
    re .39
    
    300K in 25 minutes sounds great (instead of 90 minutes), thanks
    for all the info.
                       Jan-Willem :-)

Re: .-1

Just as a point of reference.  Using Xmodem with 1k packets I get 300kb in
50-55 minutes @ 1200 baud between my microVAX and my st.  I know this from
experience.  2400 baud takes about 30 minutes.  And I haven't tried 9600.

The limiting factor in this case seems to be the hardware itself and not the
protocol.  Kermit seems to be protcol limited.

Has anyone tried xmodem at 9600 baud?

mike

    re: .-1
    
    > The limiting factor in this case seems to be the hardware itself and
    > not the protocol.  Kermit seems to be protcol [sic] limited.
    
    Umm, just to clear this up: 
    
    This message seems to imply that Kermit transfers do not scale with
    the speed of the comm line. This is not true. 9600 bps Kermit transfers
    will run 4x as fast as 2400 bps Kermit transfers.
    
    Kermit does not use the line bandwidth as effectively as other transfer
    methods, but it makes far fewer assumptions about file types and
    line transparency.
    
    For ST <-> VAX transfers, I recommend STRANSF/WHACK.
    				- HBM

Re: .-1

My point was not that kermit at 9600 baud is or isn't 4x as fast as kermit
at 2400 baud.  Higher baud rate transfers can be limited by the hardware
(and software) on each end of the line.  Thus 9600 buad may not be (and with
a heavily loaded VAX on one end won't be) 4x faster than 2400 baud.

While the [xyz]modem protocols make no assumptions about file type or contents,
leaving the user to know/guess, they do assume a transparent connection.

>>  Umm, just to clear this up: 
    
>>  For ST <-> VAX transfers, I recommend STRANSF/WHACK.

Good - give me the two VAX versions of STRANSF - I have seen only one so far.

Unless you meant to say -

        For ST <-> VAX/VMS transfers, I recommend STRANSF/WHACK.

mike

    re: .-1

> My point was not that kermit at 9600 baud is or isn't 4x as fast as kermit
> at 2400 baud.  Higher baud rate transfers can be limited by the hardware
> (and software) on each end of the line.  Thus 9600 buad may not be (and with
> a heavily loaded VAX on one end won't be) 4x faster than 2400 baud.
    
    My response was not meant as a simple, glossed over treatment of
    serial file transfer performance. But your original note implied
    that the limiting factor in KERMIT performance was the protocol.
    This turns out not to be the case. Clearly, an overloaded VAX is
    going to have problems performing *any* transfer protocol.
    
    > Good - give me the two VAX versions of STRANSF - I have seen only
    > one so far.

    > Unless you meant to say -

    >    For ST <-> VAX/VMS transfers, I recommend STRANSF/WHACK.
    
    Well, we all know that VMS is the only *real* (and certainly default)
    operating system for VAXen.
    				- HBM
    
    "You guys don't have an operating system. What you've got is a
    religion." [spoken in reference to UN*X]

It really shouldn't be too hard to convert STRANSF to the other VAX
operating system.  You delete the entire set of TFILE routines, which
exist primarly to emulate raw I/O on Unix, and delete the entire set of
BFILE routines, which exist to emulate disk I/O on Unix, and replace
them with their native equivalents.  The only hard part is implementing
Tpeekc.

Nigel Haslock once voulnteered to do the port, but apparently lost
interest, perhaps after seeing all those SYS$QIO calls.

    Hello out there!!
    
    I'm in the beginners phase of downline loading and have got some
    questions that probably are very easy answered. Since I discovered
    the large amount of PD to load from the net I tried to get started
    but just hanging in the last tree.
    
    Status of my things:
    
    I, with help of Xmodem, loaded UUDECODE.TTP and also a small piece
    called IDLE.UUE. Both loaded successfully according to KCOMM and
    Xmodem.
    
    As i understand the thing, I now have to double click on UUDECODE.TTP
    and do the decoding in order to have IDLE.UUE converted to IDLE.PRG.
    
    Qustion 1:  How large (bytes) is the UUDECODE.TTP on the ST floppy??
    		Just to make sure it's complete.
    
    Question 2: I have tried to locate some doc on UUDECODE but failed,
    		so what exact are the parameters asked for to convert
    		the file IDLE.UUE
    
    ---------------------------------------------------------------------
    Hope to continue.....................
    
    Tobbe
    

If you can run UUDECODE.TTP without getting an error 35, you got the
whole thing intact.

When you run it, it puts up a form for you to enter the command line. 
Type the name of the file you wish to decode, the rest is automatic.

    Jeff, 
    
    thanks for the promt response, its quite fascinating writing an
    reply in Sweden and have the answer/comment read a couple o hrs
    later.
    
    However, I soory to say it did not help. When doubleclicking on
    UUDECODE.TTP the box appears and I write in my case 
    
    Parameters:IDLE.UUE
    
    Off it goes and 3 seconds later I think I could see 3 bombs for
    1/100 of sec and then I get back to the opened directory window
.PRG     again. But no file IDLE.PRG is produced.
    I have tried the UUDECODE.EXE on the VAX for the same IDLE.uue file
    and no problems.
    
    Any ideas??
    
    Tobbe
    
    P.S.  I'm running on a ACB (Auto CAll BAck) and a DECSERVER 200
    and I think I saw some notes on problems with Xmodem and DECSERVER.
    If I set "SET SESS PASSALL" on the server i think I get all the
    file types transmitted correctly. I hope to get WHACK and STRANSF
    running but I need to load WHACK with help of Xmodem
    
    D.S.
    

    re .45
    
    I got cut off from my DECserver 200 for a while and since then have
    been bogged down with other activities. Apart from that, I have
    been using Uniterm and ymodem with a high degree of success.
    
    I may have time to resume work on STRANSF in another 3 weeks. Anyone
    else who wants to can look at my interim version, just send mail.

I have updated my "intruduction to file transfer between VMS and the
Atari ST" to:
	
	- include information about ZOO.
	- note that KERMIT's SET FILE TYPE BLOCK works on STREAM_LF files.
	- Discuss the problems with uploading text files (the ^M's).

PRNSYS::DUA1:[LOMICKAJ.HOBBY.ST]XFERINTRO.TXT.

    Hi,
    
    Could anyone please give me a pointer to UNTURTLE V1.3. I have TURTLE
    but havnt used it due to the fact there was no restore feature built
    in. Apparently UNTURTLE fill this spot!
    
    Thanks
    
    Pat K.

    I am not aware of UNTURTLE, but I have been using a program called
    FRUTILITY. Turtle outputs standard directory structured diskettes,
    but these become difficult to restore when restoring whole directory
    trees which may span diskettes. Frutility allows restoring of entire
    directory paths, and I found that it is satisfactory. Frutility has
    been uploaded to Delphi, and I believe is on the BCS Atari board:
    617-397-4607. Also, It appears in the Boston Computer Society public
    domain disks. I think that Delphi is available in the UK.

    lately i have been bringing MAC files over to run my spectre128.
    all the files are stuffed,in MAC format.  My transverter program
    doen't seem to work. none of my dearc files will do it. can
    someone tell me how to unstuff programs so i can transvert them
    to spectre format and run them?

Hi Ken

I'll try to answer your question here:

All the files are in MacBinaryFormat: this is a special format that allows
Mac files to reside on an ordinary (non mac) filesystem. You download them
to your atari (TOS side of life) and the transverter then transfers them 
to the sunny side of above mentioned life. The transverter knows about
MacBinary and restores the files correctly on the spectre disk. You should
then run a program called UNSTUFFIT to unstuff the .STUFFIT-things. Unstuffit
is also on RT95:: in a non stuffed form. So after downloading it and then
transverting it this should show up as an application with its icon. 

Hope this helps,
If you don't succed, tell me

---markus---

    Help ??
    
    I am trying to transfer files from VMS to an ATARI 520st using Uniterm,
    and Kermit.
    
    I have had very limited success so far... I seem to be able to transfer
    some .PRG files, but others will not run once transfered (Error
    38, or 2 bombs).
    
    I have also transfered some .ARC files across, but cannot get the
    ARC.TTP to run - it fires up, I type the parameters in 
    (ie lh file *), the screen goes blank, and then I am returned to
    my file window. If I type in an incorrect file name, I get a message
    to this effect, so I guess the program is all there.
    
    I have tried deArcing the files in VMS, then transfering them, but
    I still can't get them to work.
    
    I have checked the file types and transfered any to "Variable 510"
    format.
    
    I have done a SET FILE TYPE BINARY on those files that need it,
    and have set Binary on the Uniterm side.
    
    I even tried to bring some .NEO files over, but when I viewed them
    through Degas, and they were all junk.
    
    My main question is - What am I doing wrong ?? Why do some .PRG
    files run, and others not ? Why can I not do anything with the 
    .ARC files on my local machine ? 
                                                                      
    Simply user error I guess !!
    
    Thanks in advance,
    
    		Ian.
    

    >I have done a SET FILE TYPE BINARY on those files that need it,
    >and have set Binary on the Uniterm side.
    
    I think on the VMS kermit you have to do a set file type fixed. I'm not
    sure if this helps for files which are already on the vms side.
    
    Oswald

    
    Thanks, I tried SET FILE TYPE BINARY, but.... no joy as yet.
    
    Still trying,
    
    Ian.

When I use Uniterm/Kermit to download a binary file (ARChives) and I get the
problems you are describing, it is always because the file I downloaded was in
streamLF file format on the VAX. Using CVTARC V on the file before downloading
the file will correct the problem.

	Ray

    
    Thanks for the couple of replies I've had, but I still can't get
    it to work.
    
    Heres what I am doing....
    
    $COPY remote-file local-directory
    $CVTARC V local-file
    $KERMIT - (Some thing to invoke Kermit)
    KERMIT> SET FILE TYPE BINARY
    KERMIT> SERVER
    
    Atari - 	Transfer
    		Select Binary
    		Select Get
    		Enter filename
    
    I do this for both ARC.TTP and the .ARC file.
    I exit to TOS.
    Double click on ARC.TTP - then in the prompt window type...
    lh file.ARC *.*
    The screen clears, the disk drive hums, and I am then returned
    back to TOS. No listing, no hold screen, nothing.
    
    I have also tried to create an .ARC file with...
    ah *.PRG ARC.ARC but this does exactly the same thing. Nothing !
    
    I am now worried that ARC.TTP is not transfering properly for some
    reason ?
    
    Is there anything else in the Kermit set up on the VAX or Atari
    I have to worry about ???
    
    Thanks again,
    
    Ian (Getting rather desperate) Flack.

    
    Hi Ian,
    
    Firstly there are some funny arc.ttp's about. There is another note
    that points out one version of arc.tpp is stripped of most commands and
    only responds to an "x filename"
    
    I have a working ARCSHELL.prg which calls aARC.ttp which has never
    failed to work. It a lot more user friendly, put arcshell and arc.ttp
    in the same directory.
    
    If you send me a disk I will copy it for you and you can try it.
    BUT I am going on holiday FRIDAY for two weeks.
    
    SO:-Another way you can get it is off notso::dua0:[keane.st]. I will 
    dearc the arcshell arc to get a arcshell.prg, which although long will
    bootstrap you so you can get started!
    
    
    In the same directory is ARC.doc, which gives you all the command
    syntax's you will ever need
    

    
    I agree with .60.
    
    I too use ARCSHELL.PRG and it has never failed me yet.
    
    I also use a front-end DCL command procedure I wrote which asks for a 
    file you want to transfer (.ARC), invokes CKermit, sets up the required
    parameters and waits 20 seconds for you to set up the atari before
    doing the biz.
    
    I have posted the address for these files elsewhere in this conference
    maybe as a reply to this note (I can't recall right now). If you want
    it and can't find the posting of the required files and their location,
    just reply here and I'll dig them out for you.
    
    Jonathan

    I have used ARC with ARCshell (probably the same one that Pat's using
    as it came from his directory) Occasionally I get this same 'funny'.
    
    Usually after running the described sequence. Then you click on arc, it
    gives the top filename and doesn't unpack/list/display anything.
    
    I usually get round this with the tried and tested power off, wait 15
    secs, power on!. Maybe it's the program, maybe it's summat to do with
    the STe.
    
    Which brings me on to point 2, Ian, what's your machine?. You say you
    run the program and it bombs, therefore you must have got a file, but
    it may not be compatible with your TOS revision. STe's are favourites
    for this sort of problem.
    
    Richard

	Thanks again for all the help. Jonathan I can't seem to find
	any of the software listed in this note. Any chance in posting
	the file spec ?

	As I think that Kermit on my system is set up with some wierd
	default parameters I would be interested in both your command
	procedure to call Kermit, and ArcShell.

	If this doesn't work, I give up (for the time being).

	Many thanks again,

	Ian.

    Hi Ian,
    
    No problem. The location is as follows :
    
            COMICS::SYS$SYSDEVICE:[VAXDSM.ST]
    
    The files you need are 
        
          KERMIT.COM        the front end DCL command procedure
          WERMIT.EXE        The Ckermit image
    
    The file are WORLD readable so you should have no problem. ARCSHELL.PRG 
    is something entirely different and resides only on the ST. The way to
    use KERMIT.COM is as follows :
    
    I use UNITERM (Great !!! 8^)) on the ST, dial into work and then
    execute KERMIT.COM from the $ prompt.
    
    $ @KERMIT.COM                 should reside in the directory where the
                                  files to be transferred are.
    
    It will prompt you for the file to transfer to which you enter
    xxxxx.ARC where xxxxx is the file name. It will then invoke WERMIT.EXE
    (Ckermit) and set up all the required transmit parameters. As it does
    so it will display them on the screen. These parameters can be altered
    or added to by editing KERMIT.COM.
    
    Once it has set things up it will show the CKermit > prompt and hang
    for 15 or 20 seconds (I can't remember how I set it up (:-( ) before
    beginning the transmit. This delay is to allow you to break into
    UNTERM's receive screen (Alt-T) and select Binary Mode. Enter the file
    name to receive (xxxxx.ARC) ant then sit back and relax. It has never
    failed me yet so I hop it works for you.
    
    Before doing all this (and assuming you use UNITERM) from the menu ,
    be sure to set file transfer type to KERMIT and blocksize 1024. Set
    timeout and retry to 20 and I think I use CRC checking.
    
    Give it a go and let me know the results.
    
    Cheers for now, 
    
    Jonathan

    by the way,
    
    once the file is on the ST, the .ARC file can be put through
    ARCSHELL.PRG in the usual way which I will presume you know.
    
    Let us know the score
    
    Cheers and good luck
    
    Jonathan

Even easier is to use the kermit server

at the

CKERMIT> 

prompt type SERVER

Now ALT-T to get to the file transfer program

A GET will send a file from VAX to ST

A PUT will send from ST to VAX

No more SEND or SRECEIVE commands

Chad

    
    It works !!
    
    Sorry to not have replied earlier, but I've been away.
    
    It looks like the problem was caused by several things.
    
    a) I was having problems with the VMS file type,
    b) s I have now changed my ST Kermit setting so that Retransmit &
    Time Outs = 20, Packet Size = 1024
    c) And finally, my version of ARC.TTP seemed to be currupt ?? I
    have now got a good version and ARCSHELL (Lovely !!)
    
    All works OK now !!
    
    Thanks for all the help....
    
    Ian.
    
    PS. I tried to use CKermit, but it's linked under >VMS 4.7, but no
    real worries - I'll use it when/if they upgrade (??!!)
                                       
    Thanks again.

I have heard a few people recently mentioning that they have to call long
distance into the maynard area (PKO,MLO,etc..) in order to do
upload/downloads.  It is quite possible that there is a local (ie: toll free)
phone number that you can use to call into the Maynard facilities. This/these
numbers are only for modem use and for use after hours and on weekends.

In order to find out the phone number for your town (calling area) just call
maynard tellecom customer service at 3-2420. Anyone who answers the phone
should be able to help you. What you want to do, is ask them for the "FX
phone number into Maynard" from whatever town you live in.

Once you get the number, all you have to do is, dial it, then wait for a dial
tone (yes another dial tone, not the one you got when you first picked up the
phone), then dial the 5 digit DTN extension for your particular computer/lat.

I have talked to the people at the above extension and have explained that I
was going to post this note, they said it was ok to post. So they are sitting
their waiting for your call :-)...call today and save on those toll calls.

If anyone has any questions on this please feel free to contact me and/or the
extension above.

Also, if you do not work in the Maynard area, you may want to talk to your
local TelleComunications group to see if there are FX lines into your
facility.

	Ray

There are these numbers and you can actually dial any DTN (8nnnmmmm) from them.
I call a number in Groton and dial ZKO while my father, who works at SHR,
calls that same number and dials SHR.

Chad

As of about a year ago I noticed a little problem when using this technique.
Seems that you need a second or two delay after dialing the "8" in the DTN.
I have a Hayes compatible modem and insert (I think) a comma to get a two
second delay. Without the delay I could not reach the right number. No one
here in telecommunications seemed to be aware of that change - I had to find
out by trial and error.

Interesting. I don't do that.  It works fine.  I do have to delay after the
local number before dialing the dtn - 8nnnmmmm.  Each line must be different.

An aside: I don't know what the policy is on the use of the lines but as you
can dial any DTN, you can dial voice lines too (when the lines are in service,
ie, not during business hours)

    
    
    Lately there have been certain phone numbers at 2400 baud that 
    have new modems at the DEC sights.  This has been causing very
    impossible xfer conditions over uniterm and xmodem.  Even to the
    point of locking up uniterm and scrolling illegibles on the screen.
    
    My problem is that I have finally got the xmodem xfers going on a
    different phone number and it was working fine.
    
    Now what i am running into is a problem at the ST end.
    When i am asked what the name of the file to put the download
    into my hard drive as it will not take what i put in.
    
    The error message is CANNOT OPEN FILE
    
    Why can't i open a file that i am naming myself.
    
    Can anyone tell me?
    
    The other end starts ok and xmodem xfers are ready to go on vax.
    
    
     Ken

    
    
    Just wanted to add this reply to my own note.
    
    I solved my own problem by going off to a different route directory.
    
    My main directory ran out of possible names at the limit of GEM.
    
    IE the hard drive is c and the main was at the limit.
    
    I had to go off to c/atari and download to that.
    
    Hope i have cleared it up if anyone has the same problem.
    
    
    kp.

    
    Hi,
    
    
    I have pulled a couple of archived programs from PANARTHEA. These were
    arcgsh32.zoo and mint06b.zoo.
    
    When I tried to check the archive on the vax using VMSWEEP v 3.5, I
    obtained a listing of the archives OK. However whenever I try to
    extract anything long, I get an access vio.
    
    Aha I thought, I've upgaded VMS to 5.3, may need a new link!
    
    I found Vmssweep 3.7 .FOR on the net, I compiled and linked OK, but I
    still could not extract from the zoo archives.
    
    So I re-requested them all AGAIN, DEUUD'ed them and tried again, same
    results.
    
    PLEASE, Please what is going wrong?, Has anyone succeeded in
    de-archiving the above two archives?
    
    regards
    
    Pat K.

I also received the files, but had no problems at all. (VMS 5.3-1)

-Hans

    I'm getting a problem de-arcing a number of recent files from
    Terminator. ARC announces that it cannot handle certain files in the
    ARC, and suggests that I don't have the most recent version.

    Can anyone tell what the most recent VAX version of ARC is; and where I
    can find it. Also the most current version of ARC for the ST?

    Many thanks,

    Carl

    
    Hi Carl,
    
    I have just installed VMSSEEP V 3.7, I think this is the latest VMS
    dearcer, but I dont know what is the latest ST dearc.
    
    (I still get access vios with 3.7, although I downloaded the failing
    arcs last night and they decompacted OK on the ST Funny isnt it?
    
    Pat
    

UUD is creating the ARC file in a streamlf format. VMSweep does not handle
streamlf, which is why you are getting the errors. Either cvtarc the files or
run VMS ARC instead.  ARC.EXE can be copied from
OLDTMR::$1$DUA8:[WALLACE.PUBLIC]

	Ray

    Hi Ray,,
    
    I dont know which complaint you are answering, but in my case:-
    
    No, its not the streamlf problem!!!!!!  Its only ZOO'z that blow up, 
    BUT I can extract short <10K files, biggies, though, blow VMSSWEEP up with
    an access violation. (They all Dezoo OK at home on the ST)
    
    ANY suggestions welcome.
    
    
    Pat K.
    

re .-2

>ARC.EXE can be copied from
>OLDTMR::$1$DUA8:[WALLACE.PUBLIC]

>	Ray

This should be [WALLACE.PUBLIC.ST] I believe.

Cheers,

    Derek.

     Hum I had the same problem some time ago in triing to unzoo gcc
    bin.zoo, a very huge file. I got from "somewhere" (???) zoo version
    2.01, compiled it and (ho surprise) it worked on stream files.
    
     You can access it at bachus""::disk$ps2:[pirlet.zoo].
    
     Enjoy
    
    	Louis Richard

    There is a newer version of ARC out there.  The last 2 files I brought
    down said something like I THINK YOU NEED A NEWER VERSION OF ARC.  I've
    requested arc602st from parnathea archives.  I will try this version
    and report on success/failure.
    
    Joe

    I do despair!  I've read all these replies very carefully but I
    still don't seem to have cracked it!
    
    I have a problem with UUDECODE.  I have copied a number of files
    from Panarthea, and I have the same trouble with all of them so
    it must be me.  After using UUDECODE.EXE on the VAX or UUDECODE.TTP
    on the ST, I get the same result when I try to de-arc the resulting
    .ARC file:  ie. ----
    
    Lookin> ARC L QUIX.ARC
    Name          Length    Date
    ============  ========  =========
    QUIX.DOC          4316  26 Sep 88
    An entry in QUIX.ARC has a bad header.
      2 bytes skipped.
      
Now the file starts off looking like this:-
    
    table
     !"#$%&'()*+,-./0123456789:;<=>?
    @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
    begin 644 quix.arc
    M&@A154E8+D1/0P      *@D  #H1V(PMR=P0   ,#10$'"BP( A($:) *G"0z
    M0!5( QH^C @BR4(0(+! (H!1(X& !R%$.5A@Y,8J
    table
     !"#$%&'()*+,-./0123456789:;<=>?
    @ABCD........etc.
    
    and I've repeated the uudecode after removing various bits of the
    header,  all with the same result.
    
    Please can someone tell me what I have to do!
    
    Also, some files come in several parts with some comments in between
    each part such as "include .uub".  Now an earlier note said you
    can do the include manually, but what does that mean?  Does it mean
    editing out the "include .uub" and the spaces until the gobbledygook
    is concatenated?
    
    Thanks,
    
    Theo
    

    Hello again already,
    
    Another problem.  When trying to transfer files from VMS to an RX23
    floppy in a VAXstation using PCDISK, I sometimes encounter the
    following:
    
    A:\>IMPORT BANDWURM.ARC
    %PCDISK-E-EIMPORT, Error importing DISK$USER:[SUBTLE]BANDWURM.ARC;1
    to A:\BAN
    DWURM.ARC
    -RMS-W-RTB, 25943 byte record too large for user's buffer
    A:\>
      
    Any ideas on how to overcome this problem would be appreciated.
    
    Thanks,  Theo

    Hi,
    
    I've solved .83 thanks.  I needed to use CVTARC.  Only just found
    out about it.

    But I still have the .84 problem.
    
    Regards,  Theo

CVTARC should solve .84 as well.

	Ray

    Can UUDECODE.EXE be used with file types xxx.arc.uax, x = a, b, c, etc. 
    When I use UUDECODE, I get No end line.  Would UUD.EXE be more
    appropriate?
    
    	Steve

>    Can UUDECODE.EXE be used with file types xxx.arc.uax, x = a, b, c, etc. 
Yes, just remove all of the lines between and including the "include" "begin"
pairs between each part. Do NOT remove the "begin" line of the first part.

>Would UUD.EXE be more appropriate?
Yes, UUD (OLDTMR::$1$DUA8:[wallace.public]uud.exe) will handle the files from
terminator which use this syntax as long as you have concatenated them all
into one file.


	Ray

    
    
    Having never had a jot of trouble with downline loading programs and
    arcs with my systems both PC's and ST's I suddenly seem to have hit a
    block. I have read the aforementioned XFerintro document which I found
    helpful... But I still have problems.
    
    Question 1 Should I be copying across the network with straight copy or
    is there something which would make a better job of retaining the
    original file characteristics.
    
    Q2   I have just copied across an ARC file which was "variable length
    max 512 bytes". Arc on the vax and the ST both seem to have probs with
    it. Any ideas.
    
    

    Paul,
    
    	re your Q2:  I believe that you have to 'CVTARC' it before
    transferral to your ST. If you don't have CVTARC, then let me know.
    
    Jim

    
    
    Thanks Jim...
    
    I am actually using a thing called bilf for the conversion. And I think
    I now understand what was going wrong. I can even get Sbreak to work
    which is what started the whole process off. I can't understand how I
    a have survived in sich ignorance for the last 4 years or so.
    
    							Paul.