Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!munnari!murdu!u3369429 From: u3369429@murdu.OZ (Michael Bednarek) Newsgroups: comp.os.vms Subject: Re: Vmshar problem (SUMMARY!) Message-ID: <1292@murdu.OZ> Date: Tue, 1-Sep-87 01:47:57 EDT Article-I.D.: murdu.1292 Posted: Tue Sep 1 01:47:57 1987 Date-Received: Sat, 5-Sep-87 02:00:58 EDT References: <8708312229.AA03277@ucbvax.Berkeley.EDU> Followup-To: comp.os.vms Organization: I.A.E.S.R., Melbourne University Lines: 76 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. 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 . 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: 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