rob@cires.colorado.edu (Rob Cuthbertson) (01/10/89)
Well, I have been unable to reach cc.columbia.edu this past week, but I ftp'ed a copy of ker384.x (1, 2, &3) from a site in Kentucky (thanx guys!) and downloaded it to my Apple ][+ using AE Pro 4.3 (ProDOS). I converted the files to DOS 3.3 using CONVERT from the B side of the AE disk, and put them on a data disk formatted from the Apple System Master disk. When I try to EXEC the first two files, I get as far as the "Checking to see that all file names are spelled correctly and that there is enough space on the disk" message, and then it hangs. The disk drive is still spinning, and the head is moving back and forth at about 1/4 second intervals. Has anyone else seen this happen? If so, did you manage to recover anything from these files? Any guesses as to WHY this happens? Does anyone know when cc.columbia.edu will be reachable again? (I haven't done ANY looking around to see what the problem might be yet) I don't care if you post answers or mail them to me, but if you know what is going on, please answer somehow. --Rob Cuthbertson +----- -----+ | [4mcires%rob@boulder.colorado.edu[m <--[4mOR[m--> [4m..!{ncar.nbires}!boulder!cires!rob[m | | "I'm going to let you in on a \/\/\/ little secret, Ray. K-mart sucks." | +----- \/\/ -----+
numccann@PLAINS.NODAK.EDU ("Lester I. McCann") (01/11/89)
Subject: Problems Unpacking Kermit 3.84 Comments: To: info-apple@BRL.MIL To: "Lester I. McCann" <NUMCCANN@plains.NoDak.edu> |When I try to EXEC the |first two files, I get as far as the "Checking to see that all file names are |spelled correctly and that there is enough space on the disk" message, and |then it hangs. The disk drive is still spinning, and the head is moving back |and forth at about 1/4 second intervals. | |Has anyone else seen this happen? If so, did you manage to recover anything |from these files? Any guesses as to WHY this happens? | |--Rob Cuthbertson I had the exact same problem over the weekend with version 3.85, and I had the same problem when I tried 3.81 many months ago. I have no idea why that happens, and I have no idea how to work around it. I, too, would appreciate information on this. Perhaps we need a new way to distribute kermit? Lester McCann numccann@plains.nodak.edu
ALBRO@NIEHS.BITNET (01/11/89)
This is related to the problem of EXECing the parts of Kermit 3.84 or thereabouts. I had no problem getting a working version of Kermits 3.75, 3.80 or 3.84, but only because I had worked out the frustrations on even earlier versions. First, the file names assigned to the text files are different from those the "maker" program expects. They must be changed. Second, both files should be run through TEX to strip linefeeds before trying to EXEC them. The default disk should contain nothing except a 2-sector HELLO file and the two kermit text files. (DOS 3.3 of course). There is a "header" on part one of the kermit text file that gives you step by step instructions (such as to start execing at record number 25), but you have to read it with a separate text editor. All in all, the way the split kermit "execable" files are set up has to be the most inconvenient conceivable.
SEWALL@UCONNVM.BITNET (Murph Sewall) (01/11/89)
>earlier versions. First, the file names assigned to the text files are >different from those the "maker" program expects. They must be changed. Changed in version 3.85. The EZ Install expects APP385.1 and APP385.2 (Of course practically any software lets you download text files with any name you like -- or you just use the DOS 3.3 RENAME command). >Second, both files should be run through TEX to strip linefeeds before >trying to EXEC them. The default disk should contain nothing except a >2-sector HELLO file and the two kermit text files. (DOS 3.3 of course). STANDARD (from the Woz factory :-) Apple 'T' or 'TXT' files don't waste space storing superfluous LF's after CR's (that's Microsoft "showing off" - 'cause MS-DOS disks have soooo much room *snicker*). Apple DOS 3.3 'T' files expect the 8th (high) bit to be set as well (I'm NOT sure whether the EZ Install is sensitive to the 8th bit 'cause I've ALWAYS had it set -- either I've used SOFTERM, which lets me set it as an option, or Kermit (which takes care of it automatically -- if you download with an older Kermit, it'll also del LF after CR). It doesn't matter if you have files on the disk besides the two EZ Install files (so long as they don't take up so much room that there's not enough space for the Install to do its thing), ===> BUT <=== the EZ Install does seem sensitive to whether the files are stored in contiguous sectors, so it DOES appear to help if the files are on a fresh disk. >There is a "header" on part one of the kermit text file that gives you >step by step instructions (such as to start execing at record number 25), >but you have to read it with a separate text editor. All in all, the >way the split kermit "execable" files are set up has to be the most >inconvenient conceivable. Not so; FORCING you to MAIL a blank disk in a stamped, return addressed, disk mailer would be more inconvenient :-) Some would regard PURCHASING commware as (ahem) inconvenient :-O Remember, those EZ Install files go through all those EBCDIC-->ASCII and vice-versa gateways and still work. You can EXEC the program on a ][+, a //e, a //e+, a //c, a IIgs, a Franklin (even the old not a //e but not quite a ][+ either Franklin), a BASIS, Laser 128's and probably clones I'm not aware of. The other limitation is the size of files that can be sent to (practically) everyone. APP385.2 is 55,957 bytes, which pushes the limits of acceptable "mail" on some systems (some are limited to 20K bytes or less - alas mailing software to those places isn't very practical). Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited) According to the American Facsimile Association, more than half the calls from Japan to the U.S. are fax calls. FAX it to me at: 1-203-486-5246
SEWALL@UCONNVM.BITNET (Murph Sewall) (01/13/89)
>This is an addendum to my earlier comments on unpacking KERMIT 3.84/3.85, and >on Murph Sewall's reply. Apple does not store line feeds after carriage >returns >in its text files, but it doesn't remove them if they are already there either! The point is, because the LF's are NOT standard for Apple text files, the ONLY way they get there is if they are IMPORTED from somewhere else (usually by XModem or ASCII capture). If you can get rid of them with TEX on the VAX, do so. You'll only have to do that ONCE (to create a working Kermit-65). UNLIKE XModem, Kermit KNOWS that most of the World uses CR-LF while Apple uses only CR :-). Actually, the Kermit on EACH END knows what the appropriate text format is for the system it's on (one of the reasons for differentiating between 'text' and 'binary' file transfers). If you download with Kermit, it will make the LF's go away AND set the 8th bit correctly for the operating system it's running under. XModem is strictly "what you see is what you get" while Kermit is transparent only for 'binary' file transfers. Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited) According to the American Facsimile Association, more than half the calls from Japan to the U.S. are fax calls. FAX it to me at: 1-203-486-5246