CGORMAN@DREW.BITNET.UUCP (08/31/87)
A while ago, I wrote the following to the net: > I am reasonably new to the net and was really delighted with the idea > behind Bednarik's VMSHAR program (never having had such niceties at my > fingertips before). However, although I have cut'ted and past'ted between > the dotted lines, the darned archives always seem to give me a failed > checksum (about 50% of the time). I can't believe that I am alone in this > dilemma (I might be wrong), but has anyone had problems with lotsa failed > checksums. I am on BITNET. I thank you all for the responses. Here is a summary of what I was told: From: bitnet%"sloane@ukanvax.bitnet" 28-AUG-1987 14:08 I have also had problems with failed checksums. The problem is usually that the original file contained TAB characters, or had lines that were longer than 80 characters. The RSCS protocol doesn't seem to tolerate control characters or lines longer than 80 characters very well. Someday I hope to modify VMS_SHAR to handle control characters and long lines. From: BITNET%"CADS_COLE@GALLUA" 28-AUG-1987 14:08 The problem with the checksum nonsense is twofold, and ya just have to ignore it as far as I'm concerned... First, if the original file contained <TAB>'s, by the time it reaches you, it no longer does. Now it's got multiple spaces. Thus, CHECKSUM failure #1. Also, completely blank lines are turned into lines with 5 spaces followed by a carriage return. (At least it seems true of everything I've ever received.) I suppose, if you want, you can edit with the above in mind and see if you can get a matching checksum, but I'm not sure it's worth it. From: arpa%"art@mitre.arpa" 28-AUG-1987 14:16 Tabs often are expanded by gateways. This results in many Fortran programs no longer working as the continuation code now is in the wrong place. [I think that this was what prompted me to complain in the first place. Many submissions are in FORTRAN, and a couple have not worked without my re-indenting them to fix this problem (not a pleasant task) - Chris] Thanks to those who responded to me: From: bitnet%"sloane@ukanvax.bitnet" 28-AUG-1987 14:08 From: BITNET%"CADS_COLE@GALLUA" 28-AUG-1987 14:08 From: BITNET%"DHASKIN@CLARKU" 28-AUG-1987 14:12 From: BITNET%"W_COSTA@UNHH" 28-AUG-1987 14:12 From: arpa%"art@mitre.arpa" 28-AUG-1987 14:16 From: UK%"ABBOTTP%mail.aston.ac.uk@Cs.Ucl.AC.UK" 28-AUG-1987 23:24 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Chris Gorman BITNET: Cgorman@DREW Student sys$manager BBS: 201-377-8245, -8193, -7861 Drew University Computer Center (300/1200/2400 baud) Madison, NJ ATT: 201-377-3000 x205 POST: BC-COMPCEN Shift to the Left! Drew University Shift to the Right! Madison, NJ 07940 USA Push on! Pop off! Byte! Byte! BYTE!! -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
u3369429@murdu.OZ (Michael Bednarek) (09/01/87)
Some comments on VMS_SHAR, prompted by recent articles: In article <8708280748.AA23729@ucbvax.Berkeley.EDU> CGORMAN@DREW.BITNET (Chris Gorman, 201-377-3000 [x 205]) reported: " [VMS_SHAR failed CHECKSUM in about 50% of all cases] which was re-iterated by ASIDONHO@JHUIGF.BITNET (Tom O'Toole) in article <8708290345.AA16361@ucbvax.Berkeley.EDU> : " [also has CHECKSUM failures, reports that blank lines are received " as lines containing four spaces] to which CADS_COLE@GALLUA.BITNET (Kevin Cole; Gallaudet U.; Washington; DC) in article <8708282314.AA11538@ucbvax.Berkeley.EDU> responded: " [Advises to ignore failed CHECKSUMs, because " 1. <TAB>s are eaten by some mailers, " 2. blank lines are turned into lines containing 5 spaces] The first thing one will notice, is that all these messages (and others that I received by mail) originate from BITNET. I read comp.os.vms on a UN*X machine under what, I think, is called USENET. I have no idea about the idiosyncrasies of BITNET/JNET/JANET/... I unpack every source posted to comp.os.vms which is packaged using VMS_SHAR and they all unpacked fine so far, except in one case where it contained control characters like <BEL>. CHECKSUM sometimes fails, but that never affected the functionality of the source. Re: Blank lines As VMS_SHAR precedes every line with a "X" (or a "V" if the line was split), blank lines should not present a problem because there aren't any. Re: Trailing white space I find it difficult to imagine a source file whose functionality relies on trailing white space. Thus VMS_SHAR makes no attempt to preserve it. Of course, I know FORTRAN FORMAT statements like: 100 FORMAT(114H1THIS IS THE TITLE FOR A NEW PAGE,IT IS 114 CHARACTERS .LONG AND THE LAST CHARACTER IN THE PREVIOUS LINE IS A SPACE,2X,I3) but I'm quite happy that VMS_SHAR will be no party in propagating this style of programming. But even this example could be properly transmitted if one would add sequence numbers in cols. 73-80 (remember punch cards?). Re: <TAB>s and other non-standard characters No source file should contain any control characters like TAB,BEL,FF,ESC,..., if the poster wants to insure transmission integrity. All languages provide mechanisms to express these characters other than verbatim; e.g. in DCL: ESC[0,8]=27, in Fortran: Character*1 ESC/27/. Unfortunately, text formatting TABs have to be converted to the appropriate number of spaces. For this reason, I included a TPU procedure DETAB in part 2 of my VMS_SHAR submission. I hope this clarifies some of the confusion. Additionally, I recommend re-reading VMS_SHAR.READ_ME, which lists the features/restrictions/history of VMS_SHAR. I'm grateful for any suggestions, as it was only because of those that I wrote VMS_SHAR in the first place. P.S.: When I was about to post this article, Chris's summary appeared. One more point he mentions in <8708312229.AA03277@ucbvax.Berkeley.EDU>: " [problems with lines which are longer than 80 characters] VMS_SHAR splits/joins such lines. However, somebody mentioned that there may still be problems. He changed the value "79" in VMS_SHAR's TPU procedure to "78" and that seemed to work. Note that "79" occurs twice in line 194 of VMS_SHAR.COM . Michael Bednarek u3369429@{murdu.oz.au | ucsvc.dn.mu.oz.au} Institute of Applied Economic ...{UUNET.UU.NET | seismo.CSS.GOV}!munnari! and Social Research (IAESR) {murdu.oz | ucsvc.dn.mu.oz}!u3369429 Melbourne University mb@munnari.oz.au Parkville 3052, Phone : +61 3 344 5744 AUSTRALIA "POST NOe!ue!ueno