home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20081 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  5.1 KB
  1. Path: sparky!uunet!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Convert MSDOS or UNIX text format to VMS format
  5. Date: 30 Dec 1992 13:34:13 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 87
  8. Distribution: world
  9. Message-ID: <1hs8glINNnqs@gap.caltech.edu>
  10. References: <1992Dec30.085139.3959@cerberus.ulaval.ca>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <1992Dec30.085139.3959@cerberus.ulaval.ca>, 2020211@SAPHIR.ULAVAL.CA (Sylvain Chamberland) writes:
  15. >First let me tell you I'm not a programmer, I'm not even studying computers.
  16. >I'm just a biology grad student who has to cope with a VAX account and is
  17. >sourly mourning his former unix account...  ;-)  (no kidding I DO prefer unix
  18. >to VMS!)
  19. >I have seen the recent wave of the "flames" thread, so I will try to be clear
  20. >and precise...  ;-)    (anyway I got a thick skin!)
  21. >
  22. >Here's my problem: I don't have any archive utility on my system here so I went
  23. >to get a C source for "zip" by anonymous ftp. The source was written so it could
  24. >be portable, and I got the VMS supplementary files.
  25. >
  26. >But it appears the source is not in a VMS format, because the VAX EDIT editor
  27. >will not accept any of the *.c or *.h files as files containing many lines. It
  28. >appears to me a whole file is considered as being composed of one or a few
  29. >lines by the editor or the compiler. The VAX C compiler ("CC") won't compile
  30. >the source, it does not seem to recognize the format.
  31.  
  32. Sounds like you copied the files using IMAGE or BINARY mode.  You need to copy
  33. text files in ASCII mode.  If that's not the problem, then there's probably a
  34. problem with the files on the host from which you're copying.  If you'd let me
  35. know where you're getting the sources, and which files you're dealing with,
  36. I'll ftp them to here and let you know the results.
  37.  
  38. >(Please note that I used the VAX C compiler successfully to compile a source
  39. >for a ymodem file transfer protocol...)
  40. >
  41. >I checked the contents of the files with the VMS DUMP command, and the end of a
  42. >line is marked by the character 0A hex (line-feed I guess). I checked a file
  43. >created by EDIT and a line is terminated by 00... so I deduced the problem is
  44. >the character for the end of line.
  45.  
  46. Sounds like you copied the files in IMAGE format, so you've got something that
  47. looks like a STREAM file but VMS thinks is a fix-length, 512-byte record file.
  48. You could use Joe Meadows' FILE utility (available, I think, from
  49. VMSSERV@FHCVAX.BITNET) to change the record type in the file.
  50.  
  51. >So I would be very grateful if somebody told me how I could transform these
  52. >files in a format readable by the VAX C compiler...  :)
  53.  
  54. Try copying them in ASCII mode, if you haven't already done that.  If that
  55. doesn't work, give me the information I requested above, and I'll see what I
  56. can do to help you.
  57.  
  58. >I tried to see what I could do with commands like CoNVERT, but nothing so far
  59. >has worked. I don't know much about VAX, and I don't have any idea of what 
  60. >the heck is a "FDL"...
  61. >
  62. >I tried to transfer some files back and forth my IBM PC clone using the ymodem
  63. >protocol I just told about, then compared two versions of the same file with
  64. >the command ANALYZE/RMS_FILE: the original file, and one which went to my
  65. >computer and back. The "record type" had changed from "fixed" to "stream-LF",
  66.  
  67. AH!  My guess was correct.  FTP the files again, but this time don't use IMAGE
  68. or BINARY mode.
  69.  
  70. >the analysis told about something like "VBN 8" that had changed to "9"... also,
  71. >there appeared to be no limits to the size of the blocks anymore. But the
  72. >transfered file could be taken by EDIT (and read by the VAX C compiler, "CC"),
  73. >despite the fact that it said that the text format was not standard. I checked
  74. >with DUMP, and the end of a line was identical in both!
  75.  
  76. EDT isn't completely happy with stream files.  You can ignore its message about
  77. the format being nonstandard.
  78.  
  79. >(On screen, with TYPE, there are line feeds without carriage returns for the
  80. >original file, while there are carriage returns on screen for the transfered
  81. >file).
  82.  
  83. Yup.  The original file is fixed-length, 512-byte records with no carriage
  84. control.  You'll see a line feed every time there's an end of line in that
  85. file.  Once you transferred the files back and forth, you had a STREAM file,
  86. and RMS understood that whenever it saw a line feed, that was the end of a
  87. record.
  88.  
  89. >Anyway, I'm at a complete loss, and I'm WAY out of my league, and would really
  90. >appreciate if somebody could tell me what's going on...   :)
  91.  
  92. I've described this briefly above.  If you need more details, e-mail me.
  93. --------------------------------------------------------------------------------
  94. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  95.  
  96. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  97. understanding of astronomy is purely at the amateur level (or below).  So
  98. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  99. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  100. hold me responsible for it, but my organization had nothing to do with it.
  101.