Conference hydra::amiga_v1

    re: .0
    
    I guess that this means I can't extract files via Lharc (like I tried
    to do with 539 and 540) How can we make these readable?
    
    Cheers,
    Glenn
    
    

>but I cant extract...

  $ CVTARC U FFxxx.LZH  converts the file to stream_lf, which you
  can examine and extract from on VMS. Was that the question?
  CVTARC.EXE is in EOT::AMIGA:[AMIGA.TOOLS]CVTARC.EXE.

  Set it up as a foreign command first:
  $ CVTARC:==$MYDISK:[MYDIR]CVTARC.EXE

  Dave

I just examined the FF disk list that came out today. Rather than whine about
when will someone upload the disks (unless that will actually occur today :-),
does anyone have the AWP program (a replacement for PointerX) and could upload
it to EOT?

I've just put FF541-FF550 in eot::amiga:[upload].

I'm now managing the Amiga archives on gatekeeper, so these took a slightly
different route, and were lharc'ed on Unix instead of on an Amiga. Please
let me know if these came out broken.

Unfortunately, they are still fixed block files, and that isn't what
I meant by "broken." I'm still trying to find a way to get the .lzh files
from Unix to VMS as sequential files.

In the meantime, I notice that the previous set of fish disks haven't
moved out of upload. If people aren't using the fixed block vversions, I'll
quit moving them. Please let me know if that's the case.

	<mike

    Re: -.1
    
    A real easy way to get them to VMS in stream format would be for you
    to use NFS and mount the VMS disk under ultrix. Then, placing files on
    that disk (from ultrix) automatically makes them available to VMS AND
    they will get created in stream format.

Mike, please keep the fish going!  Doing cvtarc on them is a small price to pay
for getting fish online!

And thanks for the latest set... There was something interesting on just about 
every one of them!

john

    As .-1 said, cvtarc is easy to run.  I always check files before
    uploading to see if they need cvtarcing - just takes a few moments
    (since I do my uploads overnight anyway, the time is not an issue -
    I start a command file and go to bed (good thing it's a local call!)).

    What is an issue is that we are getting great access to Amiga s/w
    and you are not sure that anyone cares/does anything with the results.
    
    On this floor there are two Amiga users here that go "fishing" regularly.
    I think that's true for a lot of people in DEC.
    
    I suspect that if you got a mail message every time one of the files
    you uploaded got accessed you'd be really grumpy about the high
    volume of mail...

    Do please continue to upload fish disks!

    Yours
    Eben Gay

    
    
    	I would also like to add my thanks...
    
    
    	BUT I do seem to have a problem with some of the latest...
    	I took my Ami into work at the week end and after downloading
    	found that the following were corrupt
    
    	FF511 ; FF513 ; FF516 ; FF518 ; FF519 ...
    
    	I did CVT them all before uploading.. anybody else having with
    	them..???
    
    	Steve G	

Ok, I'm glad to know the things are being used, even if they aren't
being copied into place.

I'll check on the NFS mount, but I don't hold much hope for it. The only
VMS system on the building ethernet is a firefox used for booting printers
and similar things...

	<mike

I start my FTSV as soon as I see the phrase "FF* uploaded to EOT..."

    re .8 -
    yes I have those ones as corrupt as well and was going to put in a plea
    to re upload them.
    
    regards
    kevin

Since the list ended in "...", I'm not quite sure what is wanted.

If you could *mail* me the currupt list, I'll see what I can do about
replacing them.

While I'm on the topic, does anyone have a set of the Contents files
around? The archives on gatekeeper are missing 300-350 and 501-540. I'm
going to replace them, but would like to do it in some saner way than I
currently have.

	<mike

� While I'm on the topic, does anyone have a set of the Contents files
� around? The archives on gatekeeper are missing 300-350 and 501-540. I'm

    Note 1156.* seems to have them all, but perhaps not in a convenient
    form for your purposes?

    Pete (who also extends a hardy "thanks"; saves us cheapskates a fortune!)

	I have complained about problems with the fish disk archives in the
    past.  While I have not had a chance to unpack this last set, I want to
    thank all the people involved for the effort put into collecting these
    disks.  Since I need to CVTARC the files anyway to check them out before
    I down load them, I've copied the CVTARCed files back to EOT.  I hope that
    saves some people some trouble.

					With appreciation
					Max Woodbury

I can't seem to find the Fish descriptions for disks 531-540.
Could someone direct me to the note that describes these disks?
(I know there's a postscript file containing them all, but I
am looking for plain text)

Many thanks,
Peter

    Note 1156 has the ascii text descriptions.

First of I'd like to thank Mike (I'll be mellow when I'm dead) Meyer for 
the latest bunch of Fish disks.

But there's got the something else if I say "first of"... ;-)
These archives were not created from the original disks and not with an Amiga 
LHARC (or a badly configured one). They don't have the correct file attribute
bits set and their top level directory is i.e. "ff445/".
I have no idea, what kind of files are pure now or not, since the "p" flag is 
set for all of them...

Cheers,

<CB>

Ouch. I was afraid of something like that; that's why I made sure to point
it out.

You're right - the archives weren't created on an Amiga; they were created
on a Unix box. That's because I'm putting them (in a completely different
form) on gatekeeper; it seemed easier to move one copy to work, and then
build the archives.

I'll try and get them fixed this week. I'll need to set things up to build
all the appropriate files on the Amiga (the gatekeeper archives will have
the same problem) before doing so, though.

BTW, new versions of 511-520 are being copied to eot: even as I type.

	<mike

Re .18:

> BTW, new versions of 511-520 are being copied to eot: even as I type.

       Unless there was a problem with the file attributes or something
    like that, the versions I currently have, passed the CRC checks that Fred
    published.  Just to be sure, I checked them again just now and they 
    passed without even a .info file being wrong.  (I can't say the same for
    411-420 though!  Someone played with the windows on those before they 
    archived them.)  I remember that there was a problem at the time with 
    511-520, but I think it got fixed.

	I do want to thank you for the effort of uploading all those disks.
    There are only 5 disks in my entire set of 550 that have significant 
    problems.  (Minus a few for the disks that were withdrawn from 
    circulation.)  When I get those problems fixed, I'll check my notes and 
    start uploading anything that I DONT see in the archives that was 
    supposed to be there.

    Only some of the file between 511 to 520 had errors (crc)..BUT 
    on the VAX side they all passed the lharc t ff5xx test...
    
    I won't be able test anymore for the next 3-weeks as I'm on training in
    BTO..
    
    	Regards
    	Steve Goldstein

Re .20:

	Still confused - I was checking out the unpacked floppies with BRIK
    and the checksums Fred provided.

Since my 7-month old didn't sleep well last night, I got the new version
of those disks done. These were built on an Amiga, and all the bits
should be right.

Someone should delete all the older versions of FF541-FF550.

	<mike

Re: .22

>Since my 7-month old didn't sleep well last night, I got the new version
>of those disks done. These were built on an Amiga, and all the bits
>should be right.
Heh, who said that infants were good for nothing? ;-)

>Someone should delete all the older versions of FF541-FF550.
Incidently you should be able to that yourself, since the protection of the
[upload] directory allows this. 
But being the destructive kind, I arranged for their disposal... ;-)

Cheers,

<CB>

    
    	I'm getting checksum errors on trying to un-lharc FF-546 and FF-543
    from a Vax.  They fail v and t  and of course x
    
    	Reg
    

    
    Reg,
    
    Those fish disks need a   CVTARC U  and then they'll be ok on the VAX
    
    Frank
    

re         <<< Note 5015.25 by VSSCAD::GATULIS "Frank Gatulis 226-6140" >>>
>                     -< They are in the wrong file format >-

    
>    Reg,
    
>    Those fish disks need a   CVTARC U  and then they'll be ok on the VAX
    
>    Frank


	Thanks Frank,  I remembered the notes about them being 
potentially corrupt, but didn't remember the CVTARC fix.

	I must read all replies to all topics and rememeber them
	I must read all replies to all topics and rememeber them
	I must read all replies to all topics and rememeber them
	I must read all replies to all topics and rememeber them
	I must read all replies to all topics and rememeber them
	.
	.
	.
	x 50000

	Reg

I've just copied FF551-560 to eot::amiga:[upload].

Don't forget to do a cvtarc u on them before using.

Just out of curiosity - what is the possibility of me getting an account
on EOT so I could do that after coping them to EOT?

	Thanx,
	<mike

    
    
    	An account on EOT is possible. Send me mail and we can work out
    the details.
    
    		Steve P.
    		EOT system manager
    

Re: .27, .28

Not to cluter this topic, but since the AMIGA:[UPLOAD] directory on EOT:: is
writable, things like purging/deleting or CVTARC'ing there are possible 
without any local account.
On the other hand, Mike seems to be a bit short on VMS accounts to boot, so
this might not be a bad idea after all. ;-)

Cheers,

<CB>

    What is this having to CVTARC files ? I've *never* had to do this to 
    a file to get it to unpack/work etc. I use either Pathworks or
    a modem to transfer the stuff home.
    
    
    				Jamie.

re .29,

I think what Mike needs a VMS account for in this case is to run CVTARC, 
which is a real VMS specific thing. CVTARC does RMS file format conversion, 
which requires access to the RMS functions in VMS.

john

    If those files are 'CVTARC'ed, will I still be able to copy them to a
    pc with ethernet-card and just unpack them at home (using Cross-Dos :*)??
    I don't hope i will have to to something to de-'CVTARC' them, 'cause I
    can't even run 'CVTARC' in my account.
    
    Ave, Frank Ederveen
    
    P.S. why is FF559.lzh on EOT:: so/too big?
    	 I just copied it from DECWRL:: and
         now it does fit on a MSDOS-disk. 

If you just Zmodem the files to your home, a CVTARC is not needed. If you intend
to UN-LHARC them on VMS, or use kermit, then the CVTARC is necessary. CVTARC
simply changes the RMS file attribute so that these operations work
correctly under VMS. Since Mike transfers this in the easier manner available
to him and does not use VMS, the files do not end up in this format.

As I said, to me this is a non-issue bercause I simply xfer all the disks
home and every thing is fine, but not everyone does or can do this.

Keith

re .29

Hey, I have a VMS account! If I can run CVTARC on the copies on EOT from
it, that would solve the problem. So where do I find CVTARC? The problem
isn't VMS per se; it's that I don't have a tape drive on a machine that
has disks the VMS system can talk to, so I'd have to copy them *another*
time in the process of getting them to EOT::.

re FF559: It's so big because there are  > 650K of .lzh files on the disk.
Those don't compress much (best was 99.7%) when I lharc the disk. The
remaining 230K compress down to less than 100K, but it's still bigger
than an stock IBM PC floppy.

Three disks (none of them ff559) have the DECWRL Scheme->C package I ported
to the Amiga. I submitted that as lharc'ed files because it's *huge*. Even
lharcing everything large enough to notice, I had to mail Fred two floppies.
It would have taken six if I hadn't lharced things but had left them
organized in any sane manner. I don't blame fred for distributing them
in the .lzh form.

In the past, disks have run 300-400K after lharcing. This set of 10 had 1
each in the 3xxK, 4xxK and 5xxK brackets, 6 in the 6xxK bracket, and one
over 700K. I expect that lharc'ed things are going to get more popular on
the Fish disks, meaning that the archiver are going to become more
archivers and less compressers as time goes on. Since the Amiga floppies
are bigger than IBM PC floppies, this means you're going to start seeing
more archives that don't fit on the IBM PC.

	<mike

    
    	I'm going to set-up an account on EOT:: and provide a copy
    od CVTARC in it.
    
    		Steve P.
    		EOT::system 
    

    Thanks for explaining why CVTARC is required.
    
    I have another question about FISH disks; when I unpack them on my
    hard drive then click on a doc icon, it always gives me an error even
    though I have the required viewer (ppmore or something) in C:... does
    anyone know how I can overcome this ?
    
    Also, is there any way I could change what viewer is used when
    displaying such documents ? Is the info stored in the .info(!) file ?
    
    Thanks,
    
    				Jamie.

    I'm going to assume you are referring to an error concerning 
    the program "more" or "muchmore" not being in C:
    
    This has been a topic of some debate on USENET. For some reason, Fred's
    icons all expect his "more" text viewer to be in C:. Since the Fish
    disks come provided with a "more" in the C directory, this works fine
    when you are referencing the floppy. But the CBM distribution places
    the "more" program in "utilities", so this fails when you copy
    everything to your harddisk and try to use it.
    
    IMHO; the Fish disk is wrong and should either refer to "more" being in
    utilities, or shouldn't have a "C:" prefix on it so that your PATH
    setup will be applied.
    
    There are several ways you can make it work - choose the one that meets
    with your approval:
    
    1) Copy "more" into c:
    
    2) Change the .info files so that the "c:" prefix is removed, or change
    it to "sys:utilities/more"
    
    3) Under 2.0, create a linked file to the sys:utilities/more file
    (I haven't tried this, but I assume it will work).
    
    4) Read the text files from the CLI.
    
    
    Keith

    Re: .37 and .38
    
    All the FISH disks I have seen expect the muchmore utility to be in :c/
    which is not the same as C: if you have done a CD to another device.
    
    To check and/or change select the icon and use the INFO menu (in
    workbench) item to edit it and tell it where and what text viewer to
    use.
    
    John
    

Re: just using "more" as the tool.

That only works for 2.0. I think Fred is doing the right thing - he's
pointing at a tool he knows will be there. Using sys:utilities/more
is really the only acceptable alternative, at least until 2.0 is much
more widespread.

I've just had it pointed out to me that the fish disk archives I put
on gatekeeper were missing any subdirectories. Has anyone noticed this
problem for the fish disks on EOT::? Has anyone noticed subdirectories
*being* in lace for 54?, 55? and 560? Particularly PowerSource, on
547?

	Thanx,
	<mike

Re: .38

As others have pointed out, you can use the Info menu item to edit
the tool type of the icon to be a viewer on your system.

If you don't plan on keeping the icon around, or you just want a
quick look without any hassle, you can use one of most under used
features of the Workbench: multiple selection.

Click on the System drawer so you can see the "More" icon.  You can
then use More to read any file simply by clicking once on more,
pressing the shift key on you keyboard, and then without releasing the
shift key, double click on the icon for the file you would like to
read.

The Workbench supports passing arbitrary files as arguments to any program
using the above scheme.

The default tool in the icon is just that: the default tool used if you
do not select a tool via multiple selection.

    I've been having some trouble with some of the new Fish disks
    (particularly 517, 531 and 541).  They're fixed length 512
    byte record files, and when I try to use CVTARC to convert
    them to STREAM-LF, it complains with this (apparently) bogus
    error message:
    
    CVTARC: : non-translatable vms error code: 0x1828A, vms message:
    %rms-e-flk, file currently locked by another user
    %NONAME-E-NOMSG, Message number 00000002
    
    I've even tried some other conversion methods, with no luck.
    The closest I've gotten is to copy them from EOT to my ULTRIX
    node, where I can at least get a partial lharc listing before
    the inevitable checksum errors.
    
    Any ideas?  This particular problem wasn't covered in the last
    40 replies.  Even when CVTARC doesn't complain, I still get the
    checksum errors.
    
    Steve

I found out that I've been cut off from my supply of Fish Disks. You'll get
no more wrong format files from me. Sorry...

	<mike

    
    	First off I would Like to offer my thanks to Mike for all His
    efforts in getting the Fish Disk...
    
    
    	Now he has been cut off (so to speak) from his source , how about 
    we all chip in some money say $2 with someone collecting it all first and 
    then send it to Fred to get the next set of disks....???
    
    	I'm also trying to work a way of getting the disks mail directory to
    me/us here at DEC... but I first need to find out the distrubuter's
    usenet address (It not Fred he just compiles them ) any Ideas..???

    
    
    	I've just pulled off the latest fish disks ff571-ff580 from
    	ftp.informatik.rwth-aachen.de and uploaded them to
    	EOT::AMIGA:[UPLOAD]
    
    
    	Enjoy..
    	Steve G
    

Fred is the original distributer for all the Fish disks. I believe he's
current got ~60 people he mails to direct. The rate you're interested in
is probably the $3/disk for orders of 100 or more disks. Contact (and more
price) information is on each disk. Anyone who further distributes the
disks is redistributing them, and they are all probably pretty much equal.

Note that Fred is *not* doing this for profit. If you can get them from
someone other than him, please do so.

Oh yes - you're welcome.

	<mike

    They show up on the Internet on grind.mumble (I can find out) and the
    c.s.a. groups did a collection to fund a Internet repository getting
    direct mailings (again, I think this is grind).  So, all we have to do
    is have someone watch for the new annoucements and ftpmail the disks
    off of grind.
    
    George
    

	re  "Fred doesn't do this for profit"

	I had a follow up conversation with someone on the 
usenet-something recently; I was trying to track down some re-con'd CD 
drives.  Anyway, it turned out that the guy I was talking to was just 
about to ship a drive to fred....   huh ?    Yes, he didn't have a CD  
drive on his system (recall the fish disks have been available on CD 
in a couple of forms for quite a while now).   He (the usenet guy) 
went on to explain that fred is a regular computer nerd type, not much 
salary, lots of hours, not much equipment, lots of dedication, etc,    
I suppose I'd more or less suspected this 3 or 4 years ago  (-:

	Reg

At least, lharc reported a problem when I de-archvied it. However, I know
that nothing was missing from the disk (the disk was *full* afterwards).

BTW, if you are re-archiving these disks, it would probably be better to
make them identical to the disks that are already on EOT. In other words,
don't archive the files in a subdirectory ff###, but put them in the
top level instead. If that's the way you get them, then that's life.

	Thanx for the disks,
	<mike

    
    I found that testing the ff578.lzh received a BADCRC error on the
    spice3.lzh file.
    I used the address posted earlier and retrieved a new copy which is
    good and has been uploaded to eot::.
    
    wayne
    

    
    
    	All I did was to ftpmail the file over from either GRIND or
    Informatik services and the uudecoded them ...
    
    	So that was how they were stored on those nodes....Sorry if this
    has caused problems BUT I didn't want to dearchive them in a VAX
    because all files that don't have a .xxx get a . so the file becomes 
    different again... ie xxxx becomes xxxx.  but xxxx.info stays the
    same..
    
    
    		Steve G

    I repacked the latest batch of Fish archives to eliminate the extra
    directory levels.  Somebody please verify the restructured files (now
    on EOT), then we can purge the bogus copies...

    Once again, I have repacked the new Fish disks (581-589) to remove the
    FF58x directories.  The archives are now on EOT::AMIGA:[UPLOAD].  Disk
    #590 is still among the missing.

Re: .53

And once again you didn't "fix" it. ;-)
I really appreciate your effort, but unfortunately the original archiv
was (un)packed on a non-Amiga system (or w/o the correct switches) and
all the file protections bits (especially the pure or script bit) are 
invalid plus any filenote has gone with the wind, too.

I would really like to see someone putting the "real" disks on EOT.
The early availibility of the Fish disk via FTP is very nice for a
"first glance" or quick download of a long awaited tool.
However, these archives are no substitute for those made directly from
the original disks...

Cheers, 

<CB>

    
    	I'm still waiting to hear from Stefan at "INFORMATIK" to find out
    how they are storing them... 
    
    	I've seen from his signature that he has an Amiga A3000 so the
    files might be O.K. 
    
    	As soon as he replies I'll let you know..
    
    	Steve G

I kinda liked the individual ffxxx top level directories. It makes organizing
them on a hard disk much easier...

john

I wish Fred would organize the disks differently - with each separate item
in its own archive.  This would eliminate the losses from people breaking
things down on different machines.

The current organization presents problems here whenever you want to
download a single item.  It is very wasteful of connect time to download a
complete disk for a single item.  The straightforward alternative is to
unpack the archived disk and then repack the relevant items, but as
mentioned, this looses important file attributes.  What I usually do is
delete all the large irrelevant items from the archive, but this is a royal
pain.

	Paul

    Actually, I like the organization of the directories on decwrl.dec.com
    (DECWRL::).  Each disk is complete in ffxxx.lzh but individual programs
    (or more accurately directories) are also packaged seperately.  This 
    allows me to only pull what I want instead of having to pull the entire
    disk and then trim it later.
    
    George
    
    (Ps: Currently decwrl goes to ff580 and is organized):
    
    	/pub/micro/amiga/fish
    		/f1 - /f5
    
    			/ffxxx
    
    So...FF432 would be in directory:
    
    	/pub/micro/amiga/fish/f4/ff432
    
    		ff432.lzh 		whole disk
    		?			individual pieces
    
    BTW, I know this is a ``different'' distribution than Fred's original
    but I personally prefer it as I usually only want a couple of selected
    articles.
    
    George
    

Re. last few


Am I talking such gibberish or is it something else? :-)

First of, the FF581-FF589 disks on EOT:: DON'T have the correct protections
set. As far as I can tell, these archives were not created on the Amiga.

Second, yes a directory tree like on DECWRL is very convienient if you want to
select a specific item.
However, EVERY FILE NOT STORED ON AN AMIGA FILESYSTEM OR IN AN AMIGA ARCHIV
(LHARC, ZOO) WILL LOOSE CERTAIN PROPERTIES DESCRIPED SEVERAL NOTES BACK!!!

Sorry for shouting, but I feel very strongly about the pure bit or filenotes.
If you don't care about those, fine. I'll wait for the "Original" then.

Cheers,

<CB>

We get the originals from Fred Fish at our user group in town. Wayne usually
picks them up shortly after they arrive and lharcs them and sticks them on
a TK50. He's not in today, but I have the tape and will upload to EOT:

Steve

Ok, they are in EOT::AMIGA:[UPLOAD]FF581.LZH to FF590.LZH (same file names so
they overwrote the previous non-originials).

Steve.

Just as an FYI,the archives on DECWRL were built from original disks.

Before I was cut off, I was built the DECWRL archives on my Amiga at the
same time as I built the archives I copied to EOT, all from disks that Fred
had put in the mail himself. The first time, I tried doing it on Unix, and
someone pointed out the problem. I redid that group, and did all the rest on
the Amiga.

The others were copied from an FTP site with the same organization, and
should have come from original disks.

Since I'm here, I should note that I plan to replace all the old .zoo files
with .lzh files (at least, as many of them as possible) in the next month
or so.

	<mike