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