Prelude

Dramatis Personae

• 1 x Sun SPARC Classic running SunOS 4.1.3
• 1 x PowerMac running MacOS 7.5.1
• 1 x Apple //c running ProDOS 8, CP/M 56k
• 1 x Ex-Apple ][ Hacker (31) running on really hot & strong coffee
• and various folks from the net, from the memory of my mailbox: Nathan Mates, Matthew Pearce, Chris Camfield, Paul, John D. Baker, Richard Der, Nancy Crawford, Bob Jensen, Tom Kelly, Randy Shackelford, Jeff Klassen, David Empson, and Curt Schroeder.

1. The (possibly impossible) Mission?

Luckily, a colleague of mine offered me his Apple //c which has 2x5.25" (#6) and 2x3.5" drives (#5); and so I just neeed a program that would be able to transfer the CP/M files from the 5.25" disks to the ProDOS 3.5" (800k) disks, whcih then can be read my my PowerMac and moved over to my Sun SPARC ia TCP/IP. That's the theoretical part.

On with the practical part: the first thing to do is to find a FAQ because many other folks might have had the same problem. But which FAQ? The CP/M FAQ im comp.os.cpm or the comp.sys.apple FAQ or ...?

Ok; I got stuck and send out a request in some newsgroups on August 18 with "Subject: Q> from CP/M to DOS?"

Many folks replied, I was pointed to the FAQs, the repository at asimov.net and a program called CHAMELEON which would do the transfer job. Gerat, I think, that's an easy one...

[BTW: I remember that the PEEKER, a German Apple 2 magazine which has long folded, once offered a contest in writing the shortest conversion program to convert anything from Apple CP/M, UCSD Pascal, DOS3.3 and ProDOS to anything else; maybe someone still has the program which won this contest? Is Uli Stiehl, the editor of PEEKER, online anywhere?]

2. A troublesome Chameleon

I take a closer look and find a "stdio.h" in the source directory. Wow! Cretainly a UNIX professional, who created this package... oh, boy. So I delete the "stdio.h" and I get nulib compiled on the Sun without any more tweaks.

[I also tried to download A2dearc.gz from asimov.net which is said to be a Mac utility to unpack .SHK files; I don't know since downloading with Netscape which results in automatic UnStuffing, which doens't give me an executable; I'd suggest to upload A2dearc.hqx to asimov!!]

Ok, it's time for a second article.

  From: jh@Germany.EU.net (Joerg Heitkoetter)
  Newsgroups: comp.sys.apple2,comp.emulators.apple2
  Subject: Sun to Mac to //c and back
  Date: 30 Aug 1996 19:44:03 +0200
  Organization: EUnet Deutschland GmbH, Research & Development

  Folks,

  I want to transfer some old textfiles from CP/M on 5.25"
  disks to my Sun; so I first have to gather the programs for this
  task from the net, as per FAQ:

  (1) get CHAMELEON.SHK a progam that is said to be able to read
      CP/M disks from ProDOS

  (2) get an archiver which can read the CHAMELON.SHK file;

  Fine; So I get the CHAMELON.SHK file, and find I need nulib,
  for UNIX so I get nulib (from a Linux archive) [which btw is bundled
  with a stdio.h (Wow!) and therefore cannot be compiled out of
  the box -> THROW the stdio.h away! and it compiles fine...]

  I compile nulib and find that my CHAMELON.SHK file contains the
  things I want:

  jazz(jh): ~/tmp/apple2> nulib v CHAMELEON.SHK
  CHAMELEON.SHK   Created:01-Jul-91  21:52   Mod:01-Jul-91  21:52     Recs:    2

  Name                  Kind  Typ  Auxtyp Archived         Fmat Size Un-Length
  -----------------------------------------------------------------------------
  CHAM.SYSTEM           File  SYS  $2000  01-Jul-91  21:52  shk  83%     19516
  CHAMELEON.DOC         File  TXT  $0000  01-Jul-91  21:52  shk  54%     27341

  (have an eye on the "Typ" section) so I extract the files:

  jazz(jh): ~/tmp/apple2> nulib xv CHAMELEON.SHK
  Extracting 'CHAM.SYSTEM' (data)...overwriting...unshrinking (I)...done.
  Extracting 'CHAMELEON.DOC' (data)...overwriting...unshrinking (I)...done.

  Then I start Fetch on my Mac and transfer the files to a ProDOS 720K
  disk; great I think and move the disk over to the //c and voila
  the disk is readable; but--the files have type $00 not SYS and TXT
  as expected; ok I thought, let's bload the files and bsave them with the
  appropriate type; but this doesn't seem to work; it's
  always WRONG FILE TYPE (load, bload, run, exec, whatever);

  So here's the question: How do I change the attribute of a ProDOS
  file from $00 to SYS/TXT/whatever? and What's wrong in the above?
  -- 
  Have fun,	-joke

  Boah ey, bei EUnet gib's jetz' den Interschrott Exploder 3.0 für umsonst.
  (Wow, EUnet now offers the fine Microsoft Explorer 3.0 for free download.)

3. Problems, and non-problems.

  Newsgroups: comp.sys.apple2,comp.emulators.apple2
  From: skaratso@oucsace.cs.ohiou.edu (Stavros Robert Karatsoridis)
  Subject: Re: Sun to Mac to //c and back
  Organization: Ohio University C.S. Dept, Athens
  Date: Fri, 30 Aug 96 20:52:04 MET DST

  [..]
  Well, I don't know about the ".DOC" file, which you should be able to read
  on the UNIX box or the Mac. As for the other program, here is a work-around:

  Get into ProDOS BASIC
  Insert the Chameleon disk, and type
  PR#3
  CATALOG

  Look at the catalog, at the ENDFILE column. Write the number you see there
  on the line that contains CHAM.SYSTEM

  Then type,
  CREATE CHAM2.SYSTEM,TSYS
  BLOAD CHAM.SYSTEM,TSYS,A$2000
  BSAVE CHAM2.SYSTEM,TSYS,A$2000,Lxxxxx (where xxxxx is the number you got from

  the ENDFILE part of the catalog.

  To run the program, you should be able to type
  -CHAM2.SYSTEM

  Hope this helps

  Stavros

Good idea, Stavros, but it doesn't work. My ProDOS always gets me a FILE TYPE MISMATCH.

  From: shack@deimos.frii.com (Randy Shackelford)
  Newsgroups: comp.sys.apple2,comp.emulators.apple2
  Subject: Re: Sun to Mac to //c and back
  Date: Sat, 31 Aug 96 02:40:39 MET DST
  Organization: Front Range Internet, Inc, Fort Collins, Colorado

  In article <507pv7$s38@darla.visi.com>, Nathan Mates  wrote:
  >In article <507993$2qv@Germany.EU.net>,
  >Joerg Heitkoetter  wrote:
  >>Then I start Fetch on my Mac and transfer the files to a ProDOS 720K
  >>disk; great I think and move the disk over to the //c and voila
  >>the disk is readable; but--the files have type $00 not SYS and TXT
  >>as expected; ok I thought, let's bload the files and bsave them with the
  >>appropriate type; but this doesn't seem to work; it's
  >>always WRONG FILE TYPE (load, bload, run, exec, whatever);

  Actually BASIC gives FILE TYPE MISMATCH since that's the closest it can get to
  ProDOS 8's unsupported storage_type error

  >   Shoulda noticed this before; the problem (as email conversations
  >seems to have turned out) comes down to 3 letters: M-A-C. Idiot box
  >****ing insisits on adding resource forks to files, making them
  >unreadable under ProDOS 8.

  If a file has no resource fork, copying it to a ProDOS disk doesn't add one;
  I just verified this on my Powerbook. I took a copy of Appleworks on a 3.5 disk
  and copied all the files to my Powerbook's RAM disk, then put in a blank ProDOS
  disk and copied 'em to it. Appleworks ran fine off this disk.

  >   I am > < (fingers about 1/8" apart) close to actually recommending
  >that people wishing to download stuff to Apple IIs AVOID Macintoshes
  >completely. In the FAQ. This is because of their BONEHEADED and
  >UNNECESSARY inisistence on adding resource forks.

  Doing so would be propagating an inaccuracy, something you've been railing
  against so much lately. I have my workstation equipped //e and my IIgses
  networked with my Macs, and I can transfer files under ProDOS 8 and they
  work slicker than snot.

  >   When something appears to do what you want, but prevents you from
  >actually doing it, that is worse than not supporting it directly.  If
  >it's going to trip up far more people than will benefit, I'm going to
  >recommend against such things.

  What say you get off your Mac hating high horse and help find a solution?
  Didn't I see someone saying here not long ago that any file with with a
  certain file type/creator combo can be copied to a ProDOS disk without
  making the file an extended storage type file? I never worried about finding
  out since I never use sneakernet. If you can set the type such that the
  files copy properly, end of problem, correct?

  Failing that, I have a ProDOS 8 program I wrote for my own use which can read
  an extended file's data fork and write its data into a standard file. I also
  have an unfinished program for deleting extended files under ProDOS 8. Last
  I worked on it, it worked except for causing the blocks_used field of the
  volume directory header on the affected disk to be off by one.
  --
  Randy Shackelford                                 US Air Force officer
  shack@frii.com                                    and Apple aficionado



  From: shack@deimos.frii.com (Randy Shackelford)
  Newsgroups: comp.sys.apple2,comp.emulators.apple2
  Subject: problem solved (Re: Sun to Mac to //c and back)
  Date: Sat, 31 Aug 96 03:34:38 MET DST
  Organization: Front Range Internet, Inc, Fort Collins, Colorado

  I jumped on info-mac to see if there was any app to strip the resource fork
  off a file. In the disk directory, I found the very thang. It's the file

  ftp://mirrors.aol.com/mir02/INFOMAC/info-mac/disk/file-stripper-utilities.hqx

  It has a drag and drop app for stripping the resource fork and another to do
  the same for the data fork. There's even one to strip the name resource,
  maybe that would cause files copied to DOS disks to not be forked, who knows.
  Here's the procedure for getting a Mac downloaded file to work in ProDOS 8:

  download it
  drag the file's icon onto the resource fork stripper app icon
  copy the file to a ProDOS disk
  stick the disk in your Apple II

  I tested this with a simpletext file, I got Appleworks to open it pretty as
  you please.

  Just goes to show how much more productive a little resourcefulness is rather
  than mindless griping.
  --
  Randy Shackelford                                 US Air Force officer
  shack@frii.com                                    and Apple aficionado

Good point, Randy; resource forks are no problem if all downloads have been done in binary mode; anyway, I fetched: ftp://mirrors.aol.com/mir02/INFOMAC/info-mac/disk/file-attributes.hqx and use it in my solution below.

4. What does ProDOS really stand for? Professional or Problematic DOS?

However, the .bsq extension tells us that we have to convert this file with BINSCII, then we need to UnShrink it, see below.

As for ProDOS, the generic way to change the attribute of a ProDOS program is copied from a reply by Nathan Mates (the very helpful c.s.a2-FAQ maintainer):

  With BLOAD and BSAVE, and non-'BIN' filetypes, you must specify the
  alternate type. For example, to change a filetype from $00 to SYS, try
  the following:

    BLOAD FUBAR,T$00,A$1000,Lxxx
    CREATE BARFU,TSYS
    BSAVE BARFU,TSYS,A$1000,Lxxx

  Where 'xxx' is the file length of the file. If you didn't force
  binary mode in downloading, the filesize will pribably be different
  from what nulib showed. [By the way, the c.s.a2 FAQ has a section on
  changing ProDOS filetypes with a program (that you'd have to
  download), as well as changing it manuall like above in the
  downloading Todd Whitesel's BINSCII.TXT section.]

Now, here comes the fun part: my ProDOS downs't have this byte count (which anyone else seem to have) I would need for the ",L" option. A "CAT" on my system just gives me FILENAME, TYPE, LENGTH IN BLOCKS and MODIFIED DATE; I seem to have a very old version of ProDOS? (It's ProDOS 8 v1.9 10-Jul-89)

And when I try the above I ALWAYS get a "FILE TYPE MISMATCH" error, AaaarrrgghhhHH!

5. To BINSCII or not to BINSCII?

Interesting chicken & egg problem: I cannot use a BINSCII encoded program with which I would be able to change the file type of any program, because I cannot change the file type of the BISCII.TXT distribution;

And then: if I was able to change the file type of the BINSCII.TXT file, I wouldn't need BINSCII.TXT since the I could simply change the file type of CHAM.SYSTEM, are you still with me? ;-)

6. Of Creators, Resources Forks and other Crap

It's PSYS/pdos; so I unpack the CHAMELEON.SHK archive on my Sun using nulib and download CHAM.SYSTEM once again with Fetch, and give PSYS/pdos as type/creator; then I copy the file to the ProDOS disk; reboot the Apple //c with this disk and voila, chameleon starts up;

I transfer the files to the ProDOS disk (unfortunately you have to do this one by one), and insert the disk into the Mac. I select all the text files from the disk and drop them in the Fetch window; then I hurry to the Sun and load the first file; yeah; we got it made!!!!!

[I also tried to give CHAMELON.DOC a type creator or PTXT/pdos but this doens't work; I thought that ProDOS TYPES may be P<ProDOS type>, but that's not the case; for the textfile chose TEXT/pdos and voila...do the same for BINSCII.TXT, if you have the time...]

Hmm, yes, one caveat: *always* do the conversion on the Mac desktop! Then copy the file to the ProDOS disk; if you copy anything directly to the disk, it doesn't work. Only a MacOS-guru will be able to tell us why.

7. Unresolved Riddles

Resource forks are no problem, if all downloads happen in binary mode; forks are added on ProDOS disks, but they are separated from the files, just like on PC disks; i.e., they do NOT modify the file content.

Some problems may arise, when you download the files directly to the ProDOS disk; you have to store the files on the Mac's desktop; THEN copy the files to the disk; I still don't know why.

I guess that the file type can easily be changed with a sector/disk editor, since it's stored in the ProDOS directory entry somewhere; who knows which byte has to be changed?

Would anyone please upload A2dearc.hqx to asimov.net?

Postlude

Many of the old Apple 2 hackers couldn't go on with Apple but had to get into other, cheaper platforms. I went on to use an Atari ST, others went PC, et cetera; well, all this should be (and stay) in the past; peace, folks! ;-)

Aftermath: Dissolving the Riddles

  Date: Sun,  1 Sep 96 09:55:05 PDT
  From: rder@pro-palmtree.cts.com (Richard Der)
  To: Joerg.Heitkoetter@Germany.EU.net
  Cc: comp.sys.apple2-news@newsbase.cs.yale.edu
  Subject: Re: FYI> Hitch-Hiking from Sun/ *NIX to Apple // via Mac and back

  jh@Germany.EU.net (Joerg Heitkoetter) wrote:
  >Well--I still don't know why my ProDOS' CAT doesn't list the byte
  >count of a file.

  Try this:
  >From the "]" prompt, type "PR#3" without the quotes.
  Then type "CATALOG" without the quotes.

  This should give you a FULL directory listing with all the info.
  ProDOS' "CAT" command produces a crippled directory listing, with
  the byte count being one of the things that are lacking. "CATALOG"
  is the more powerful command. The byte count is the number in the
  "Endfile Subtype" column.

  This should work with real 128K Apple IIe and //c or above or
  any emulator that is at that level (that is, can do the 80 column
  text screen).

  For 40 column only emulators, skip the "PR#3" step. This will
  still give you all the information, but it will look ugly.

Maybe, I simply should have asked David Empson? He seems to have answers for everything, so enjoy...

  From: dempson@actrix.gen.nz (David Empson)
  Newsgroups: comp.sys.apple2
  Subject: Re: FYI> Hitch-Hiking from Sun/ *NIX to Apple // via Mac and back
  Date: Sun, 1 Sep 1996 12:26:24 +1200
  Organization: Empsoft

  Joerg Heitkoetter  wrote:
  [snippage]

  > I compile nulib and find that my CHAMELON.SHK file contains the
  > things I want:
  > 
  > jazz(jh): ~/tmp/apple2> nulib v CHAMELEON.SHK
  >  CHAMELEON.SHK   Created:01-Jul-91  21:52   Mod:01-Jul-91  21:52
  >                  Recs:    2
  > 
  >  Name             Kind  Typ  Auxtyp Archived         Fmat Size Un-Length
  > ------------------------------------------------------------------------
  >  CHAM.SYSTEM      File  SYS  $2000  01-Jul-91  21:52  shk  83%     19516
  >  CHAMELEON.DOC    File  TXT  $0000  01-Jul-91  21:52  shk  54%     27341
  > 
  > (have an eye on the "Typ" section) so I extract the files:
  > 
  > jazz(jh): ~/tmp/apple2> nulib xv CHAMELEON.SHK
  > Extracting 'CHAM.SYSTEM' (data)...overwriting...unshrinking (I)...done.
  > Extracting 'CHAMELEON.DOC' (data)...overwriting...unshrinking (I)...done.
  > 
  > Then I start Fetch on my Mac and transfer the files to a ProDOS 720K> disk;

  It would be an 800K disk.  The Apple II doesn't support 720K disks
  unless you have a SuperDrive and a SuperDriver controller, or something
  similar.

  > great I think and move the disk over to the //c and voila
  > the disk is readable; but--the files have type $00 not SYS and TXT
  > as expected; ok I thought, let's bload the files and bsave them with the
  > appropriate type; but this doesn't seem to work; it's
  > always WRONG FILE TYPE (load, bload, run, exec, whatever);

  Each command in ProDOS basic expects a certain file type.  LOAD/RUN are only
  for BAS (Applesoft BASIC), EXEC is only for TXT files that contain BASIC
  commands (or ProDOS commands).  The only "universal" command is "-", which
  starts a program using the appropriate method (EXEC for atext file, RUN for
  BASIC, BRUN for binary, or launching a SYS file directly).

  BLOAD and BSAVE assume a BIN file by default, and report a FILE TYPE
  MISMATCH if you attempt to use them with another file type.  You can
  override this with the "T" argument (specifying the file type), but you
  also have to specify a load address.  In this case, the correct command
  would have been:

  BLOAD CHAM.SYSTEM,T$00,A$2000

  You could then save it back as a SYS file as follows:
  DELETE CHAM.SYSTEM
  CREATE CHAM.SYSTEM,TSYSBSAVE CHAM.SYSTEM,TSYS,A$2000,L19516

  (The length is obtained from the "Un-Length" column in the NuLib listing
  earlier; it should have also been reported by an 80-column CATALOG
  command.)

  > So here's the question: How do I change the attribute of a ProDOS
  > file from $00 to SYS/TXT/whatever? and What's wrong in the above?

  I'd normally use a file type changer utility, but the above method will
  work for most files, as long as they aren't too big.

  In a subsequent quoting, shack@deimos.frii.com (Randy Shackelford)
  wrote:
  > If a file has no resource fork, copying it to a ProDOS disk doesn't add
  > one; I just verified this on my Powerbook. I took a copy of Appleworks on
  > a 3.5 disk and copied all the files to my Powerbook's RAM disk, then put
  > in a blank ProDOS disk and copied 'em to it. Appleworks ran fine off this
  > disk.

  This is true, but it only works because the files have a creator of
  'pdos' and a known file type.  If you take an arbitrary Mac file (with
  any creator other than 'pdos', or an unrecognised file type) and copy it
  to a ProDOS disk, the Mac will make it into an extended file, so that it
  can preserve the Mac file type and creator.

  Any such file cannot be accessed by ProDOS-8, unless you run a resource
  fork stripping utility on it.

  To ensure a file will end up as a standard file on a ProDOS disk, make
  sure its file type is set to 'TEXT' and its creator to 'pdos', BEFORE
  copying it to the ProDOS disk.

  You can then use a file type changer on the Apple II to set the correct
  file type.  If it is supposed to be a SYS file, you can set the Mac file
  type to 'PSYS' before copying the file.  Most other file types require a
  binary encoded file type which cannot be entered from the keyboard.


  Back to Joerg Heitkoetter :
  > Good point, resource forks are no problem if all downloads have been
  > done in binary mode;
  Not necessarily.  If the file ends up with the wrong file type/creator,
  then it will be unusable by ProDOS-8 (see above).


  > What does ProDOS stand for? Professional or Problematic DOS?
  Professional, but only if you have good utilities.  The actual operating
  system doesn't have a user interface - most of your hassles have been
  with BASIC.SYSTEM, which is rather primitive.

  ProDOS itself doesn't care about file types (except for SYS and DIR).
  >      BLOAD FUBAR,T$00,A$1000,Lxxx
  >      CREATE BARFU,TSYS
  >      BSAVE BARFU,TSYS,A$1000,Lxxx
  > 
  >      Where 'xxx' is the file length of the file. If you didn't force
  >   binary mode in downloading, the filesize will pribably be different
  >   from what nulib showed.
  >> Now, here comes the fun part: my ProDOS downs't have this byte count
  > (which anyone else seem to have) I would need for the ",L" option.
  > A "CAT" on my system just gives me FILENAME, TYPE, LENGTH IN BLOCKS and
  > MODIFIED DATE; I seem to have a very old version of ProDOS? (It's ProDOS 8
  > v1.9 10-Jul-89)
  CAT is the 40-column version of the catalog.  You need to use CATALOG to
  get all the fields, and you must be in 80-column mode to read it.

  > And when I try the above I ALWAYS get a "FILE TYPE MISMATCH" error, #@$@$@!
  This may be because the files are extended (see above) and therefore
  unreadable by ProDOS.

  BASIC.SYSTEM has a small set of error messages, and it uses the same
  message for several ProDOS errors.  In this case, it is probably getting
  a ProDOS "unsupported storage type" error, and displaying the message
  which is the closest match.  A large number of errors collapse into a
  generic "I/O ERROR", which doesn't tell you very much.

  Summary time:

  > Well--I still don't know why my ProDOS' CAT doesn't list the byte count of
  > a file.
  Because it doesn't fit.  Use CATALOG.

  > Resource forks are no problem, if all downloads happen in binary mode;
  > forks are added on ProDOS disks, but they are separated from the files,
  > just like on PC disks; i.e., they do NOT modify the file content.
  Wrong on most counts.

  1. The binary download is necessary to ensure that CR and/or LF are not
  changed.

  2. To ensure the file has no resource fork (strictly speaking: to ensure
  the file is standard, not extended), it is necessary to set the creator
  to 'pdos' and the file type to 'TEXT', 'PSYS' or an appropriate ProDOS
  file type (which cannot be entered on the keyboard, since it requires
  entering three binary values from 0-255 as a character) before copying
  the file to the ProDOS disk.

  3. On a ProDOS disk, an extended file (with data fork and potentially a
  resource fork) is stored as two logical files, with an "extended key
  block" connecting the two forks.  The single directory entry points to
  the extended key block, and a different "storage type" is used.  The
  storage type indicates how the file contents are organised.  The major
  storage types are: directory, one block files (seedling), multi-block
  files with a single index block (sapling), multi-block files with a
  two-level index (tree), extended files (which includes two forks, each
  of which may be seedling, sapling or tree), and special files such as
  PASCAL areas.  ProDOS-8 does not support extended files, but GS/OS (on
  the IIgs) does.

   By comparison, on an MS-DOS disk, the resource fork is stored as a
   completely separate file in the hidden RESOURCE.FRK directory.  Any
   Macintosh directory information is stored in a hidden file somewhere
   else.  The PC is able to deal with the data fork quite happily, but it
   is easy to get it separated from the resource fork, and to lose the
   associated Macintosh directory information.

  > Some problems may arise, when you download the files directly to the
  > ProDOS disk; you have to store the files on the Mac's desktop; THEN
  > copy the files to the disk; I still don't know why.
  This may be something that Finder is doing to make things easier.  I
  suspect that other programs writing directly to a ProDOS disk might
  always create an extended file, but Finder only does this if necessary
  (if the file already has a resource fork, or it has a non-ProDOS
  type/creator).

  > I guess that the file type can easily be changed with a sector/disk
  > editor, since it's stored in the ProDOS directory entry somewhere;
  > who knows which byte has to be changed?
  You can change the file type this way, but it is easier to use something
  like File Attribute Zapper.

  However, changing the storage type using this method is NOT a good idea,
  because the storage type reflects the physical structure of the file.  To
  change an extended file into a standard file, you would have tomanually
  extract the required information from the extended key block, store it in the
  directory entry, then mark the extended key block and the resource fork as
  free in the bitmap.  There is at least one utility program to do all this.

  -- 
  David Empson
  dempson@actrix.gen.nz
  Snail Mail: P.O. Box 27-103, Wellington, New Zealand

Author's reply to a later follow-up:

  Newsgroups: comp.sys.apple2
  From: jh@Germany.EU.net (Joerg Heitkoetter)
  Organization: EUnet Deutschland GmbH, Research & Development
  Subject: Re: FYI> Hitch-Hiking from Sun/ *NIX to Apple // via Mac and back

  In article <50rgc4$eqa@news.fwi.com>, tsullivan@mail.fwi.com (Tom Sullivan) wri!
  [..]
  |> Jees, in retrospect, wouldn't it have been faster to simply retype
  |> them?
  No; it was was quite worthwile. 2nd I didn't had a printout of some
  stories; and 3rd I even found 2 stories that even didn't really remember.

  --
  Have fun,       -joke
  
  ===== ______  __         __    ==  Jörg Heitkötter
  ==== / __/ / / /__  ___ / /_  ===  Research Fellow, EUnet Engineering Task Force
  === / _// /_/ / _ \/ -_) __/ ====  Emil-Figge-Str. 80, D-44227 Dortmund
  == /___/\____/_//_/\__/\__/ =====  Tel/Fax +49-231-972 -1038/-1188

  "We are what we repeatedly do. Excellence, then, is not an act, but a habit."
        --Aristotle