home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11973 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.7 KB
  1. Xref: sparky comp.arch:11973 comp.sys.dec:6629 comp.sys.sgi:18355 comp.sys.hp:14387
  2. Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
  3. Path: sparky!uunet!paladin.american.edu!gatech!swrinde!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!network.ucsd.edu!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol
  4. From: zrepachol@cc.curtin.edu.au
  5. Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
  6. Message-ID: <1992Dec29.044012.1@cc.curtin.edu.au>
  7. Lines: 51
  8. Sender: news@cujo.curtin.edu.au (News Manager)
  9. Organization: Curtin University of Technology
  10. References: <Bzo3tJ.KGo@usenet.ucs.indiana.edu> <15609357@zl2tnm.gen.nz>
  11. Date: Mon, 28 Dec 1992 19:40:12 GMT
  12.  
  13. In article <15609357@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
  14. > mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
  15. >> Actually, I've seen alot of people here call RMS "the file system."  For those
  16. >> of you who still think that RMS is the file system, I'll clue you in: RMS
  17. >> is not the file system.
  18. > 
  19. > Perhaps you'd like to explain why the back of the RMS manual looks like:
  20. > 
  21. >         V M S
  22. >         _________________
  23. >         
  24. >         *Volume 6B*
  25.                          ^
  26. Perhaps you could tell the nice reader what else is in vol 6.
  27.  
  28. > 
  29. >         *File System*
  30. > 
  31. >         Record Management
  32. >         Services (RMS)
  33. > 
  34. > Seriously, RMS is all-pervasive in VMS.  Sure, you can do QIOs to the 
  35. > XQP yourself, and RMS even provides an interface to make this a little
  36. > easier.  But 99.999% of the time, there is no reason to do so.  This is
  37. > what differentiates the VMS approach from the Unix universe.  Files on
  38. > VMS can (almost) always be read and written using RMS, often this means
  39. > that you can use tools intended for sequential files on indexed or 
  40. > relative files.  Compare the Unix approach, where if you use anything 
  41. > other than a sequential file, other utilities can't do anything useful
  42. > with it.  It's a standardisation issue more than anything else -- provide
  43. > a standard, easy way to do something and it will be used.  If you don't
  44. > you get a plethora of non-standard wheel re-inventions.  Providing an
  45. > ISAM package with the *FORTRAN* compiler (of all things) as one poster
  46. > commented on, just doesn't cut it in this regard.
  47. > 
  48.  
  49. But U*** still loses because it has no way of telling the application what
  50. TYPE of file structure it is...
  51.  
  52. > This is what VAX C does.  It still succeeds in being dreadfully slow,
  53. > although it wouldn't take much effort by someone who knew something about
  54. > file handling to write a VAXCRTL that does block I/O and goes like a
  55. > scalded cat.  VAXCRTL is completely braindamaged in nearly every respect,
  56. > and seriously needs to be thrown away and started again.  
  57. > 
  58.  
  59. Never a truer word spoken... The intertwining of the C language and Unix IO
  60. is a *HUGE* mistake.
  61.  
  62. ~Paul
  63.  
  64.