fritz@ecs.umass.edu (11/29/89)
I have recently started downloading some files from the SIMTEL20 system. The only problem is that when I download them and try to UN-ARC them...they all seem to have a CRC MISMATCH and the file is automatically marked corrupt. Is there some sort of special ARC program I should be using? I've tried PAK, and PKXARC and they both giveK8 the same trouble. Please responde via BITNET Email... FRITZ@UMAECS.BITNET -Brian Fritz
ts@uwasa.fi (Timo Salmi LASK) (12/03/89)
In article <8643.2572b0cb@ecs.umass.edu> fritz@ecs.umass.edu writes: >I have recently started downloading some files from the SIMTEL20 system. The >only problem is that when I download them and try to UN-ARC them...they all >seem to have a CRC MISMATCH and the file is automatically marked corrupt. Is >there some sort of special ARC program I should be using? I've tried PAK, and >PKXARC and they both giveK8 the same trouble. This is a problem that keeps recurring with getting files from file sites such as, for example, Simtel20 and ours. I can assure you that the files are perfectly ok. There are two very very common errors that users make in handling the files. Let's revisit: 1) Remember that the .arc files are binary files. This means that before using the command get in ftp, you MUST set the file type right. In the case of Simtel you have to give the command tenex, at most other sites (ours included) you have to give the command binary. 2) Even when you have managed item one, you still have to transfer the file to your PC from your mainframe. The most common file transfer protocol here is Kermit but some users use z-modem as well. Much errors are made here. Again you have to remember that the .arc files are binary files so you have to set file type binary before you attempt sending from your mainframe. If you are using kermit you are also well-advised to see that the sending kermit and the receiving permit use the same parity. If your host mainframe is a Unix system, your best bet is parity even. 3) Then apply arc, pkxarc, pkunpak, or arce. All are ok. If you have done steps 1 and 2 properly, no problems will remain here. ................................................................... Prof. Timo Salmi (Site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: vakk::salmi Bitnet: salmi@finfun
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (12/04/89)
In article <8643.2572b0cb@ecs.umass.edu> fritz@ecs.umass.edu writes:
* I have recently started downloading some files from the SIMTEL20 system. The
* only problem is that when I download them and try to UN-ARC them...they all
* seem to have a CRC MISMATCH and the file is automatically marked corrupt. Is
* there some sort of special ARC program I should be using? I've tried PAK, and
* PKXARC and they both giveK8 the same trouble.
I've been getting files from SIMTEL with great success for nearly two years,
until about a week ago. Then I, too, started getting files I couldn't un-arc!
I've tried PKUNPAK, PK35, ARCE, and a couple others. NOTHING WORKS!
---------HELP!------------
-------
regardz,
Kenkevin@kosman.UUCP (Kevin O'Gorman) (12/05/89)
In article <8643.2572b0cb@ecs.umass.edu> fritz@ecs.umass.edu writes: >I have recently started downloading some files from the SIMTEL20 system. The >only problem is that when I download them and try to UN-ARC them...they all >seem to have a CRC MISMATCH and the file is automatically marked corrupt. Is >there some sort of special ARC program I should be using? I've tried PAK, and >PKXARC and they both giveK8 the same trouble. I don't want to presume, but... I had a problem like this. I was uudecoding on a unix system and using kermit to send the .ARC file to my PC. The problem was that I was forgetting to 'set file type binary' on the unix end. The .ARC was getting clobbered but there was enough there for the archive program to partly recognize the file. So, take a look at how you're doing the equivalent transfer.
simmons@ncrcae.Columbia.NCR.COM (James Simmons) (12/05/89)
One Item Prof. Salmi didn't mention, is the case of using LISTSERV. If you
request archives from a LISTSERV server, or download from the binaries
newsgroup, the file is usually split into pieces after it is uuencoded for
transmission. You must save each of these pieces in a separate file and
remove the headers (up to the "cut here" lines). You must then concatenate
all the pieces togeather before uudecoding. If you don't remove the headers
and just save all the pieces to one file, you will have CRC errors in the
archive.
Believe me, I speak from experience!
Reply-To: simmons@ncrcae.Columbia.NCR.COM (James Simmons)
________________________________________________________________________________
President: NCR PC User Group, Inc. | International Association of PC User Groups
101 Whitehorse Road | Same Address
Lexington, SC 29072 |
________________________________________________________________________________hardin@hpindda.HP.COM (John Hardin) (12/06/89)
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: >In article <8643.2572b0cb@ecs.umass.edu> fritz@ecs.umass.edu writes: >* I have recently started downloading some files from the SIMTEL20 system. The >* only problem is that when I download them and try to UN-ARC them...they all >* seem to have a CRC MISMATCH and the file is automatically marked corrupt. Is >* there some sort of special ARC program I should be using? I've tried PAK, and >* PKXARC and they both giveK8 the same trouble. >I've been getting files from SIMTEL with great success for nearly two years, >until about a week ago. Then I, too, started getting files I couldn't un-arc! >I've tried PKUNPAK, PK35, ARCE, and a couple others. NOTHING WORKS! >---------HELP!------------ Don't know if this will help anyone, but I have noticed that SIMTEL archives appear to be corrupted when I uudecode them using one of the scripts that was posted here a while back for decoding multi-part submissions. The symptom is that the decoding appears to work but the failure is on the dearchiving step. When I put the parts together by hand (i.e., using vi), stripping off all the extraneous stuff, and then run the single piece through uudecode, the dearchiving step works fine. I haven't the expertise in script writing, nor the time, to debug this. The decoding script works fine for stuff from comp.binaries.ibm.pc, however. John Hardin ------------
rk@cs.strath.ac.uk (Richard Kingslake) (12/06/89)
In article <5439@ncrcae.Columbia.NCR.COM> simmons@ncrcae.Columbia.NCR.COM (James Simmons) writes: >One Item Prof. Salmi didn't mention, is the case of using LISTSERV. If you >request archives from a LISTSERV server, or download from the binaries >newsgroup, the file is usually split into pieces after it is uuencoded for >transmission. You must save each of these pieces in a separate file and >remove the headers (up to the "cut here" lines). You must then concatenate >all the pieces togeather before uudecoding. If you don't remove the headers >and just save all the pieces to one file, you will have CRC errors in the >archive. > My copy of uudecode automatically removes headers etc and concatenates files. I simply hand it the name of the first file, un-doctored, and it goes ahead and uudecodes the lot! It is called: UU-DECODE 3.07 BY RICHARD MARKS and is *very* easy to use. I recommend it. Richard Kingslake JANET: rk@uk.ac.strath.cs ARPA: rk@cs.strath.ac.uk UUCP: !seismo!mcvax!ukc!strath-cs!rk or rk@strath-cs.uucp
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (12/06/89)
In article <35180011@hpindda.HP.COM> hardin@hpindda.HP.COM (John Hardin) writes: * kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: * >In article <8643.2572b0cb@ecs.umass.edu> fritz@ecs.umass.edu writes: * >* I have recently started downloading some files from the SIMTEL20 system. The * >* only problem is that when I download them and try to UN-ARC them...they all * >* seem to have a CRC MISMATCH and the file is automatically marked corrupt. Is * >* there some sort of special ARC program I should be using? I've tried PAK, and * >* PKXARC and they both giveK8 the same trouble. * >I've been getting files from SIMTEL with great success for nearly two years, * >until about a week ago. Then I, too, started getting files I couldn't un-arc! * >I've tried PKUNPAK, PK35, ARCE, and a couple others. NOTHING WORKS! * >---------HELP!------------ * Don't know if this will help anyone, but I have noticed that SIMTEL archives * appear to be corrupted when I uudecode them using one of the scripts that * was posted here a while back for decoding multi-part submissions. The symptom * is that the decoding appears to work but the failure is on the dearchiving * step. When I put the parts together by hand (i.e., using vi), stripping off * all the extraneous stuff, and then run the single piece through uudecode, * the dearchiving step works fine. I haven't the expertise in script writing, * nor the time, to debug this. The decoding script works fine for stuff from * comp.binaries.ibm.pc, however. Well, since I went back over my tracks again, and tried a couple things again, What I found is that the "autoftp" shell and programs I got from the net recently seem to have a problem (I have been using them for _some_ of my recent downloads). The shell provides for each file to be specified as either _binary_ or _ascii_ retrieval, but, seems to be using the mode specified for the _first_ file for all files! so that when I ask for an ascii-mode text file followed by a binary-mode arc file, the arc file is retrieved in ascii mode! So the solution is to run separate shell jobs for the two modes, which still isn't bad because it's still a _heck_ of a lot easier than doing the ftps manually. ---------------- regardz, Ken Leonard
pfratar@watserv1.waterloo.edu (Paul Frattaroli - DCS) (12/06/89)
In article <35180011@hpindda.HP.COM> hardin@hpindda.HP.COM (John Hardin) writes: > >Don't know if this will help anyone, but I have noticed that SIMTEL archives >appear to be corrupted when I uudecode them using one of the scripts that WHAT?? You shouldn't have to uudecode anything you get off of Simtel. Just dearchive, using arc -x [file] >was posted here a while back for decoding multi-part submissions. The symptom >is that the decoding appears to work but the failure is on the dearchiving >step. When I put the parts together by hand (i.e., using vi), stripping off >all the extraneous stuff, and then run the single piece through uudecode, If a single part uudecodes, then you don't need to concatenate them together in the first place. If all the parts need to concatenated together, then uudecode will complain about a short file when you try to decode a single part. >the dearchiving step works fine. I haven't the expertise in script writing, >nor the time, to debug this. The decoding script works fine for stuff from >comp.binaries.ibm.pc, however. > >John Hardin >------------ Also, multiple part archives from Simtel don't need to be concatenated together. Each are separate stand alone archives. ....Paul F -- Paul Frattaroli - Department of Computing Services University of Waterloo Waterloo, Ontario Canada N2L-3G1 < pfratar@watshine.UWaterloo.ca > < pfratar@watserv1.UWaterloo.ca > --------------------------------------------------------------------------------
mbb@cbnewsh.ATT.COM (martin.b.brilliant) (12/07/89)
From article <324@watserv1.waterloo.edu>, by pfratar@watserv1.waterloo.edu (Paul Frattaroli - DCS): > In article <35180011@hpindda.HP.COM> hardin@hpindda.HP.COM (John Hardin) writes: >> >>Don't know if this will help anyone, but I have noticed that SIMTEL archives >>appear to be corrupted when I uudecode them using one of the scripts that > > WHAT?? > You shouldn't have to uudecode anything you get off of Simtel. > Just dearchive, using arc -x [file] Mucho confusion here. We are not talking about files direct from SIMTEL, but via a server like listserv@vm1.nodak.edu. For MAIL ... UUENCODE shipments, these come in parts, almost like the parts posted in c.b.i.p., and have to be concatenated together. If anybody wants to use it, I enclose (after my signature block) the ksh script I now use for both c.b.i.p. and listserv to concatenate and uudecode. It will take a single file argument, or multiple file arguments. The file(s) may already contain concatenated segments. It shows the Subject lines so you can make sure all the parts are there in the correct order. Then after stripping out the junk between sections it lets you verify that there is now only one Subject line. It also creates a text file from the header of part 1, which contains useful comments in distributions from c.p.i.p., but not from listserv. Finally, it leaves a file called uuctemp that is uudecodable, though normally you would not need that as the uudecoding has already been done. Notice the two-line sed command near the middle; it does all the dirty work. You could use that alone as a two-liner (take out the last two words) and then run uudecode on the output. M. B. Brilliant Marty AT&T-BL HO 3D-520 (201) 949-1858 Holmdel, NJ 07733 att!hounx!marty1 or marty1@hounx.ATT.COM Disclaimer: Opinions stated herein are mine unless and until my employer explicitly claims them; then I lose all rights to them. Notice: Communication will cease 12/30/89 due to retirement. for File do Text=`grep '^begin ' $File` && break done echo $Text grep Subject $* Temp=uuctemp read A?"Hit RETURN to continue, INTERRUPT to abort." sed '/END.*cut here/,/BEGIN.*cut here/d /End of part/,/Part .* of/d' $* > $Temp echo created $Temp, should show one Subject line: grep Subject $Temp read A?"Hit RETURN to continue, INTERRUPT to abort." uudecode $Temp set $Text echo created $3 Text=${3%.*}.hdr sed '/^begin [0-7][0-7]* [^ ]*$/ { q }' $File >> $Text echo created $Text: `wc <$Text` lines, words, characters
msschaa@cs.vu.nl (Schaap MS) (12/07/89)
In article <1081@baird.cs.strath.ac.uk> rk@cs.strath.ac.uk writes: >My copy of uudecode automatically removes headers etc and concatenates >files. I simply hand it the name of the first file, un-doctored, and it >goes ahead and uudecodes the lot! It is called: >UU-DECODE 3.07 BY RICHARD MARKS >and is *very* easy to use. I recommend it. It even checks checksums (for example from comp.binaries.ibm.pc). It was posted a couple of months ago in c.b.i.p. Michael
w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) (12/10/89)
Ken, AutoFTP defaults to whatever the last FTP mode was. This was
done do it wouldn't be necessary to put the mode on each line of the
list of files. You only have to put the mode in when it changes.
Keith
--
Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.arpa BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdzdrv@cbnewsj.ATT.COM (dennis.r.vogel) (12/11/89)
In article <8643.2572b0cb@ecs.umass.edu>, fritz@ecs.umass.edu writes: > I have recently started downloading some files from the SIMTEL20 system. The > only problem is that when I download them and try to UN-ARC them...they all > seem to have a CRC MISMATCH and the file is automatically marked corrupt. > > -Brian Fritz I, too, have noticed the same thing. With a bit of experimenting I was able to ascertain that the second last line of each uuencoded file that I receive is always incorrect. The last two lines are always: M end I always change the second last line so the file ends with: ` end and I get my uudecoded files to unarc successfully. Now that I've figured out what is wrong and how to fix it, would someone tell me why it is this way in the first place? An incompatibility between two systems or networks perhaps? Dennis R. Vogel AT&T Bell Laboratories Lincroft, NJ
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (12/11/89)
In article <KPETERSEN.12548821459.BABYL@WSMR-SIMTEL20.ARMY.MIL> w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) writes:
* Ken, AutoFTP defaults to whatever the last FTP mode was. This was
* done do it wouldn't be necessary to put the mode on each line of the
* list of files. You only have to put the mode in when it changes.
Yep, and that's not all... The user must remember that "binary" and "tenex"
modes are not the same, 8-( , even though both apply to "binary" files!
Between missing mode-flags and wrong mode-flags, I got myself tangally totalled.
My aplologies to the author for what may have seemed (to some) a flame, and
for what may have given some (many?) reservation about using Autoftp.
-----------
Autoftp is a _damnfine_ piece of work.
------------
regardz and chagrinz,
Ken