home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / internal / 1802 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  4.9 KB
  1. Path: sparky!uunet!stanford.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!asuvax!gatech!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!umd5!umdsp.umd.edu!BLEAU
  2. From: bleau@umdsp.umd.edu
  3. Newsgroups: vmsnet.internals
  4. Subject: Writing UNIX filesystem from VMS
  5. Message-ID: <18160@umd5.umd.edu>
  6. Date: 26 Jan 93 18:09:20 GMT
  7. Sender: news@umd5.umd.edu
  8. Reply-To: bleau@umdsp.umd.edu
  9. Organization: University of Maryland Physics Dept.
  10. Lines: 77
  11.  
  12. Hi, netters.  I may be about to cross the line between the two worlds and
  13. become an outcast of both, but perhaps there are some on each end that can
  14. assist me.
  15.  
  16. I am a manager/programmer at a VMS site.  We have a VAXstation 3100-76 running
  17. VMS 5.4-x, soon to be V5.5-1, and have Fortran and C available.  We have as
  18. a requirement distributing data to other systems on megneto-optical media
  19. (rewritable optical disks, the 600MB ISO variety).  This works well for most
  20. sites, since they also run VMS.  There are, however, several sites which run
  21. some variant of UNIX, and we'd like to keep the same media in sending data to
  22. them.  The problem is, they can't read VMS ODS-2 file format, and I don't know
  23. how to write a UNIX file system.  
  24.  
  25. Yet.  
  26.  
  27. That's where you can help.  If we're to write something that can be mounted and
  28. read by a UNIX system, I need some specialized software at this end.  I need to
  29. find out the specification for a UNIX file system, and then construct a program
  30. that will do it all for me.  It then occurred to me that this may have already
  31. been done.  
  32.  
  33. So, VMSers, have any of you heard of this having been done, and can you give me
  34. pointers?  If it has not, could it be done be mounting the optical disk
  35. /foreign and addressing it in a block oriented fashion?  Would the drive which
  36. reads it get the blocks in the same sequence I wrote them, or would the MSCP
  37. info on the disk cause some problems?  Has anyone tried this, and what problems
  38. have you encountered along the way?  An ACP would be the best solution here. 
  39. If you know of a third party that sells a low-cost package that'll do this,
  40. please mention it, too.
  41.  
  42. And UNIXers, you, too, can help.  Do you know where I can get info on a UNIX
  43. file system?  A specification is best.  Is there perhaps a set of code
  44. somewhere - written in C, of courses - that actually writes a UNIX file system,
  45. code that I could port to VMS, strip out the low level writes and replace them
  46. with appropriate VMS writes and i/o requests, and have 90% of what I need
  47. already working?  Either nonlicensed or free code is best, plase.
  48.  
  49. Thirdly, in case the first two alternates are impossible or unworkable, is
  50. there possibly some intermediate format which would be easy to implement and
  51. write at the VMS end, and be easy to read at the UNIX end?  This format could
  52. be restrictive in the follwoing ways: not allow any updates of files or
  53. directories, is to be written completely only once at the VMS end, is to be
  54. read only at the UNIX end, allow only one level in a directory hierarchy (flat
  55. file system), assume files are contiguous, have no record separators (basicly
  56. UNIX stream format or VMS fixed-512 format), and any other simplifying
  57. assumptions.  This may be the easiest to implement at both ends and would get
  58. the job done, at the risk of producing something *quite* nonstandard.
  59.  
  60. We've considered other solutions, and none of them get a very good reception:
  61. 1) writing to 8mm tape - easily written and read, but strong project
  62.    requirement toward using the same media for all, so this is a last choice
  63. 2) FTPing the files - hard to automate with UCX's FTP, and would require
  64.    loading down the net on a daily basis with hefty amounts of data (multi-MB),
  65.    something I think network managers would frown on, not to mention being
  66.    impolite ;-)
  67. 3) concatenate files into a single file are COPY it to a /FOREIGN mounted disk,
  68.    so it starts at block 0 and keeps going - already tried and proves too hard
  69.    for both ends to use, mainly because there is no demarcation between data
  70.    sets 
  71. 4) borrow someone else's system which runs UNIX, NFS mount the optical disk
  72.    from it on the VMS system, and use the NFS and remote UNIX systems to
  73.    perform the conversion by just COPYing the files - would pose too large a
  74.    burden on someone else (translate: probably couldn't get anyone to agree),
  75.    since this would be every couple of days on a regular basis
  76.  
  77. I'd normally say email the answers to me at bleau@umdsp.umd.edu, but this
  78. sounds like a topic where interaction during the answer phase would be most
  79. productive.  Post your replies to vmsnet.misc and we can start the thread
  80. there, rather than posting to four (or more) news groups.  I'll looko there in
  81. the next week or so.  If you have specific questions, you can either post them
  82. or email to me directly at the above address.  If you email it, I'll post your
  83. question with my reply to aid the brainstorming.  Thanks for the help, all.
  84.  
  85. Larry Bleau
  86. University of Maryland
  87. bleau@umdsp.umd.edu
  88. 301-405-6223
  89.