Conference hydra::amiga_v1

    
    
    the utilities ZOO, ARC, LHARC, WARP are on
    
    	TAPE::AMIGA:[AMIGA.Utilities]
    
    VAX/VMS versions are on 
    
    	TAPE::AMIGA:[AMIGA.TOOLS]
    
    
    		Steve Peters
    

    Re .0:
    
>   I'm looking for the ZOO and ARC files, has anyone some pointer to these 
>   files ?
    
    For the AmigaDOS versions, start with the following:
    	TAPE::AMIGA:[AMIGA.UTILITIES]ARC023.BIN		AmigaArc executable
    	TAPE::AMIGA:[AMIGA.UTILITIES]ARC23.ARC		AmigaArc archive
    	TAPE::AMIGA:[AMIGA.UTILITIES]ZOO200.ARC		AmigaZoo archive
    	TAPE::AMIGA:[AMIGA.UPLOAD]LHARC121.ZOO		AmigaLHArc archive
    
    There's a "chicken and egg" problem here.  You'll need to use
    ARC023.BIN (suitably downloaded to c:arc on your Amiga) to decompose
    the other .ARC files.  Once you decompose ZOO200.ARC, you'll have the
    Amiga Zoo utility with which you can decompose LHARC121.ZOO.
    
    The Fred Fish disks and our other downloadable stuff are kept in .LZH
    and .ZOO archives (saves LOTS of space and downloading time), so you'll
    need to have both LHarc and Zoo in order to take advantage of them.
    
    The VMS versions of each of these utilites are also available.  These
    are particularly helpful when you want to examine the documentation for
    the archived program of your choice before downloading it.
    	TAPE::AMIGA:[AMIGA.TOOLS]ARC.EXE	VMS Arc
    	TAPE::AMIGA:[AMIGA.TOOLS]LHARC.EXE	VMS LHArc
    	TAPE::AMIGA:[AMIGA.TOOLS]ZOO.EXE	VMS ZOO
    
    Happy downloading!

    
    Well, I've studied this note and several others regarding downloading,
    compression/decompression programs, file formats and so on, and I'm
    still not getting anywhere. Bear with my lengthy explanation - I'd like
    to think I've thought of just about every logical possibility.
    
    I have a 500, with the Commodore modem, and the AmigaTerm software.
    Although I appear to have the 1.3 ROM's and WB 1.3 came with the system
    when I bought it last November, the Amiga Term disk can only be used
    from a cold boot, and it comes up with WB1.2 running AmigaTerm V1.0.2.
    
    I can dial into TSN OK. I set up the LAT with the right commands
    (SET PORT LOCAL SWITCH ^A, SET SESSION PASSALL, FORWARD). In the LAT
    designated for my TSN account, I can access either VMS or ULTRIX.
    
    I've copied ARC023.BIN and the other stuff Bill mentioned in .2 to
    my both my VAX/VMS and my ULTRIX accounts. I've copied and used CVTARC
    on the VMS side. I also, just for giggles, copied ORBITS.LZH (Take a bow,
    Paul), AND was able to use VMS' lharc to look at the directories, etc.
    
    BUT, I also copied XMODEM.C from TAPE:: and tried to use to shove
    stuff home, but it didn't seem to work. So, I tried under ULTRIX/RISC
    V4.2, with identical results! (I can understand that VMS does a lot
    of seemingly strange things to files, but ULTRIX should have worked. I
    adjusted the constants in the source code so that it would compile).
    
    The problem seems to be a re-apparition of the 16 block problem. I can
    get the first 16 blocks of a file (in most cases) onto my A500, and
    then I have to wait for it to time-out and hope that I can still talk
    to my {VMS | ULTRIX} system after the time-out. What's interesting is
    that the file format difficulties seem to be irrelevant: I created a
    text file locally on the ULTRIX system that was just under the 2048
    byte 'wall' that I seem to be hitting, and it copied fine. A text
    file over that limit goes bonkers and hangs - BUT those first 2048
    characters seem to transfer OK.
    
    Needless to say, I'm not real happy. I'd understand Bill's comments
    about "Chicken and Egg", but unfortunately, I can't seem to get up
    to bat, much less first base.
    
    Is there a known problem with this version of AmigaTerm? (or any, for
    that matter?). I'm trying to use Xmodem; should I try another edition
    of Xmodem for my VMS or ULTRIX systems to make AmigaTerm happy? Should
    I wander down to the local pusher and buy some other communications
    software package for the Amiga just to get started?
    
    Ironically, I do have a copy of lharc (from a recent Amiga Tech), but
    I can't get orbits.lzh up my modem line. Interestingly, for you ULTRIX
    users, I copied it 'dcp -i' from TAPE::, and then used lharc to extract
    the user's manual here at work, so the image on my ULTRIX disk is OK.
    (lharc cheerfully created the 'missing' directories for me, so I had
    to chase down the directory tree on my system to get at the doc!).
    
    Any suggestions, pointers, or other help, either here or via mail at
    GURU::COOLIDGE (sorry, it wasn't named that way with the Amiga in mind)
    would be greatly and sincerely appreciated.
    
    

I don't know anything about AmigaTerm, but that _might_ be the problem.
The best suggestion I can give is to get a hold of a copy of one of the
following (they are either PD/Shareware, and are excellent):

Handshake
VLT(jr)
Smokey 

You seem to have all the right pieces in terms of utilities.  Maybe 
someone at ZK could give you a hand (I'm in LKG).  If not, try stopping
by System Eyes in Nashua (I think John Sauter will even be there this
week).  They can certainly help you out.

Steve  

    
    Within minutes of posting .3, a friend from VMS CSSE came over and
    offered to load up a couple of disks of goodies for me. I'll give
    them a try and report back. My eventual goal is to make a step-by-
    step cookbook for ULTRIX (and OSF) users to follow. I was hoping
    to be able to get this going with the OOTB (Out Of The Box) stuff
    that came with the system, but that's clearly out of the question.
    
    Yes, I am quite aware of John Sauter and System Eyes this week.
    Unfortunately, both my wife and I celebrate our birthdays in August,
    which means coughing up Automobile Excise taxes here in New Hampsha...
    
    The response in this conference is stupendous! Thank You !!
    
    

  >Yes, I am quite aware of John Sauter and System Eyes this week.
  >  Unfortunately, both my wife and I celebrate our birthdays in August,
>    which means coughing up Automobile Excise taxes here in New Hampsha...
 

I think the advice to see John was meant to mean roughly: Your
dealer can help you with technical issues as well as sell you things.

 In this case, your dealer has expertise in using an Amiga to dial
 up DEC and use the various tools on Amiga and DEC systems. Also,
 System Eyes carries the Fred Fish Public Domain disks with the
 the terminal emulators mentioned in a previous note. I suspect
 you could get more than enough of the right utilities on Amiga disks
 for under $10.  Then, with gratitude for the guidance they provided,
 you can buy "regular" software at System Eyes in the future, when excise 
 taxes are no longer an issue.

 Dave

    Zmodem is clearly the most efficient and reliable transfer protocol
    around today.  I suggest you try to get yourself onto Zmodem as soon
    as possible.
    
    You might try using PASSTHRU instead of PASSALL, that keeps the flow
    control working.  Actually, I've never needed *any* of these options
    with Zmodem - the protocol already avoids the "dangerous" control
    characters.
    
    Here are a few items you may find useful from the Fish library:
    
    	VLT	Fish #468 & 455 (VT100, Xmodem, Kermit, XPR* [Zmodem, etc.])
    
    	XPRZmodem  Fish #459
    
    	Handshake  Fish #449 (VT100/VT220, Xmodem, Kermit, XPR*)
    
    	VT100	Fish #330 (VT100, X/Y/Zmodem, Kermit)  [XPRKermit is also
    		on this disk.]
    	VAXterm	Fish #369 (VT220, text file transfers only)
    

    Don't forget that you need ARP if you want to run VLT (or VLTjr).
    Zmodem is definitely the fastest and least problem-giving file transfer
    method. The diskette in the briefcase if probably more reliable if you
    have access to a networked PC at work.

    Lindsay

I believe that you are running into the xon/xoff problem of xmodem. If you
look at the baud rate of the terminal on your host system you will find it
is running at 9600 baud. You probably do not have a modem tht runs at that
rate. More likely 1200 or 2400. The modem at work accepts characters until
fills its buffer and then sends back an XOFF to stop traffic. XMODEM is
expecting something else and assume the other side is crazy. It will wait
until there is a timeout and try again. While it is waiting for the buffer
to fill it is able to transfer a few blocks of data.

Try Z-modem.

-Tom-

    
    re .6 - I don't know John personally, but I've been to System Eyes
    		and I have a discount card to prove it ;-) and Steve was
    		very nice to me when I was in there a few weeks ago. I'm
    		merely trying to avoid a problem that I have of wanting to buy
    		everything in sight on site when I walk in. (I have the
    		same problem with amateur radio stores, too...). I know
    		I'll need a hard disk at some point, for example.
    		
    		A friend in VMS CSSE handed me a pair of disks this morning,
    		with arc, zoo, lharc, zoom, zip, lhunarc, disk salve,
    		diskperf, iconmaster, VLTjr, X/Zmodem, and SID, so that
    		ought to keep me busy for a while!
    
    re .9 - I suspect the baud rate of the system is at about 10Mb/sec ;-)
    		I'm coming in on TSN to a LAT. On the ULTRIX system, I
    		did give it an 'stty 1200' command which it silently
    		accepted to no avail. I do have XON/XOFF enabled in the
    		AmigaTerm menu, but it sounds like that aspect needs to
    		be explored further. I'm running the C= 1680 (?) at
    		1200 baud. (My wife brought me home a Codex 2520 modem
    		to try, but I have no documentation to get it hooked up
    		and on the air quickly.)
    
    Thanks for all the advice - and keep it coming! "Film at 11"...

    
    Well, I'm here to report back, with a happy ending. Thanks to my
    sympathetic friend "next door" in CSSE, I finally tried out VLTjr
    and used ZMODEM to copy ORBITS.LZH up to my 500.
    
    It was easy and it was hard. The SZ program on VMS *AND* ULTRIX both
    work fine. (Almost spooky - I started the transfer from the VMS/ULTRIX
    side and then went back to the VLT menu to start the transfer on the
    A500 side only to find it had beat me to it!).
    
    I did get a lot of errors, and ended up disabling XON/XOFF on the
    A500 side. The problems that I appear to have been having under XMODEM
    under AmigaTerm seem to have been caused by very noisy phone lines:
    ORBITS.LZH is 74222 bytes long, and took 44 minutes at 1200 baud,
    with a total error count of over 300.
    
    I haven't played with it enough yet to isolate the problem, but it
    could be:
    		1.) The CBM 1680 modem itself
    		2.) The fact I'm ~6 miles out in the woods on a rural
    			(but Baby Bell, nonetheless) exchange.
    		3.) The trunk between my exchange and Concord (NH)
    		4.) The FX line from Concord to our Contoocook facility
    			(DOO), which is on a independent exchange.
    		5.) The line from DOO to "DEC" (MKO? ZKO? whatever),
    			although I suspect that's the cleanest part.
    
    What does all this mean? Well, the good news is that most of us here
    really might not see so many problems, so if you can get XMODEM to
    work, following .2's instructions really ought to work. It also means
    that if you can get around the RMS problems on VMS, it makes little
    difference if you're using VMS or ULTRIX.
    
    I plan to try some more experiments, using a Tymnet portal, varying
    combinations of XON/XOFF involvement, and so forth, and then write
    it all up cookbook-style so that other newcomers will be able to get
    up to speed fairly quickly. AFTER I figure out how to put Orbits on
    its own bootable disk. (I'm working on it ;-).
    
    My sincere thanks to all who provided tips.
    
    

    Anyone know how to use wildcards with vmz zmodem? I have tried
    SZ *.* 
    but this doesn't work. Any other ideas?
    

Re: .12

VMS ZMODEM doesn't do wildcards, so you use a dcl wrapper to do them for
you.  Someone posted such a thing some time ago.  It didn't suit my taste,
so I wrote another.  You may or may not like this, and may need to adapt it
to your dcl environment - mine is somewhat customized.  At a minimum you
will need to revise the line "$	sz = ..." according to where you keep your
version of the SZ executable.

The format of the command this procedure accepts is pretty much a superset
of what the SZ executable takes.  In particular, options are passed
through.  (I don't use options much, so there may be side effects or
problems with various option usage.)

In addition to doing wildcards, this does its best to minimize file naming
incompatibilities between the vax and the amiga.  If you are sending a file
with a null extension it will usually be able to omit the trailing dot in
the amiga filename.  Version numbers are supressed when sending the most
recent version of a file.  For older versions they appear as a third dotted
component of the name.  Files are always sent without directory
qualification.  The name of each file is displayed before it is sent, and a
short pause is included which gives you time to ^C if you don't want it
sent.  (I learned this last the hard way.  With a wildcard which
accidentally selects a bunch of files it was nearly impossible to get
things stopped without hanging up.)

	Paul

$!
$!	sz.com	do sz with wildcards
$!
$!	format: @sz [-opt]... wildcardedname ...
$!
$	say := write sys$output
$	mydir = f$parse(".;0") - ".;0"
$	sz = "$$tools:sz"
$	command = "sz"
$	wildcount = 0
$	opts_with_args = "LImwc"
$	on error then goto CLEANUP
$	on control_c then goto CLEANUP
$	on control_y then goto CLEANUP
$	n = 0
$ NEXT:
$	n = n + 1
$	wild = p'n'
$	if f$extract(0,1,wild).nes."-" then goto DOFILE
$	opt = f$extract(1,f$length(wild),wild)
$	if f$extract(0,1,opt).eqs."\" then opt = f$edit(opt-"\","lowercase")
$	if opt.eqs.""
$	then
$		n = n + 1
$		wild = p'n'
$		goto DOFILE
$	endif
$	if f$length(opt).eq.1
$	then
$		if (opts_with_args - opt).nes.opts_with_args
$		then
$			n = n + 1
$			opt = opt + " " + p'n'
$		endif
$	endif
$	command = command + " -" + opt
$			t = "''command'"
$	goto NEXT
$!
$ DOFILE:
$	if wild.eqs."" then goto DONE
$	wildcount = wildcount + 1
$	path = f$parse(wild,"*.*;0")
$	if path.eqs."" then say "Illegal filename: ",wild
$	if path.eqs."" then goto NEXT
$			t = "''path'"
$	first = f$search(path,1)
$	file = first
$	if file.eqs."" then say "File not found: ",wild
$ FIND:
$	if file.eqs."" then goto NEXT
$			t = "''file'"
$	newest = f$search(f$parse(";0",file),2)
$	filedir = f$parse(file,,,"node")+f$parse(file,,,"device") -
		+ f$parse(file,,,"directory")
$			t = "''filedir'"
$	filename = f$parse(file,,,"name")
$	filetype = f$parse(file,,,"type")
$	if filetype.nes."." .or. file.nes.newest -
	then filename = filename + filetype
$	if file.nes.newest then -
	filename = filename + "." + (f$parse(file,,,"version") - ";")
$			t = "''filename'"
$!
$	say "Sending: ",file
$	say ""
$	wait 00:00:05		! give chance to ^Y out of mistake
$	set default 'filedir'
$	'command' - 'filename'
$	set default 'mydir'
$!
$	file = f$search(path,1)
$	if file.eqs.first then goto NEXT
$	goto FIND
$!
$ DONE:
$	if wildcount.eq.0 then 'command'
$!
$ CLEANUP:
$	set default 'mydir'
$	exit

    re: -.2
    
    I have been using wildcard in SZ.EXE and it does work!
    MAke sure you define your symbol $SZ  :==$DISK:[DIRECTORY]SZ.EXE
    					     ^ make sure the $ is there.
    
    Also I use the 211 block size of SZ.EXE (30-Jul-1990).
    
    $ SZ *.dat will xfer all .dat files etc..

    The version that I have does NOT support wildcards, and is 93 blocks.
    
    How about a pointer to this version?

re: .-2    

>    I have been using wildcard in SZ.EXE and it does work!
>   MAke sure you define your symbol $SZ  :==$DISK:[DIRECTORY]SZ.EXE
    					     ^ make sure the $ is there.
    
>    Also I use the 211 block size of SZ.EXE (30-Jul-1990).
    
>    $ SZ *.dat will xfer all .dat files etc..

That image, does NOT support VMS wildcarding, I built those images, and
are avail on CGOU01::AMNEW:, your SZ command above must be a symbol for
a command procedure that then gathers the file names and forms the command
string for SZ.EXE. (You probably are using Clints cmd procedure post a while
back). There is no VMS wild carding within the SZ source, since they are all
ported un*x utlities.

The only difference between the 211 block version and the 93 block version is
that the 211 block version has the RTL linked into the code, so as to work
on more versions of VMS. (as long as they were copied from CGOU01::AMNEW:).
Since these images contain some fixes I had made to flow control and file
name handling problems.

/Steve.

    re : .-.1
    
    Sorry, you are right, I am actually calling Clint' .com file.
    
    I got mixed up due to the re-org of our local cluster being
    shutdown and my logicals are still not fully tested.
    

    
    re .11
    
    It turned out to be item #4: The Contoocook FX line was doing
    compression on me. I learned this in the JETSAM::WATN conference,
    which was created only a few weeks ago.
    
    Since the transition to WATN, things have been going smoothly, with
    file transfers over the Commodore 1200RS modem running at about
    110-115 CPS (or very close to the theoretical limit, including
    CRC comparison overhead, etc.). This is using the Tymnet switch,
    of course. Now if I could only afford a DF296...