home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / internal / 1804 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  3.1 KB

  1. Xref: sparky vmsnet.internals:1804 vmsnet.misc:1189 comp.unix.internals:2170 comp.unix.questions:15964
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!darwin.sura.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!mccall!mccall!tp
  3. Newsgroups: vmsnet.internals,vmsnet.misc,comp.unix.internals,comp.unix.questions
  4. Subject: Re: Writing UNIX file sys from VMS
  5. Message-ID: <1993Jan26.084204@mccall.com>
  6. From: tp@mccall.com (Terry Poot)
  7. Date: Tue, 26 Jan 1993 08:42:04 CST
  8. Reply-To: tp@mccall.com (Terry Poot)
  9. References: <18148@umd5.umd.edu>
  10. Organization: The McCall Pattern Co., Manhattan, KS, USA
  11. Nntp-Posting-Host: mis1
  12. Nntp-Posting-User: tp
  13. Lines: 52
  14.  
  15.  
  16. In article <18148@umd5.umd.edu>, bleau@umdsp.umd.edu writes:
  17. >...
  18. >An ACP would be the best solution here. 
  19.  
  20. If you find one, please tell DEC so they can speed up VMS-POSIX file operations!
  21.  
  22. >Thirdly, in case the first two alternates are impossible or unworkable, is
  23. >there possibly some intermediate format which would be easy to implement and
  24. >write at the VMS end, and be easy to read at the UNIX end?  
  25.  
  26. Two spring immediately to mind: VMS Backup and unix tar. There are unix
  27. utilities to read a backup tape, and VMS utilities to both read and write tar
  28. tapes. Probably these wouldn't need any major changes to operate on a disk.
  29. (Other archive formats are available on both systems: Zip, Zoo, etc., and can do
  30. compression, if that's useful to you.)
  31.  
  32. I'd guess you could simply mount it /foreign on VMS and treat it pretty much
  33. like a tape. You might have to tweak the qio's a little, or maybe not. I've
  34. never done this on a disk. Similarly, on unix, you use the raw disk device name,
  35. and you should be able to directly read raw disk blocks. 
  36.  
  37. I wouldn't be surprised if this would work with no software changes, with both
  38. systems treating the raw disk basically like a tape, though, like I said, I've
  39. never tried it.
  40.  
  41. >This format could
  42. >be restrictive in the follwoing ways: ...
  43.  
  44. Either Backup or tar format would be less restrictive than what you said you'd
  45. be willing to accept.
  46.  
  47. If you do have to write some software to access the raw disk, I'd write _only_
  48. that. On VMS, write a file to disk copy routine and copy your chosen archive
  49. format onto the disk. On unix, write a filter to read the disk and pass it to
  50. stdout, and pipe it into tar or vmsbackup. (Dunno if vmsbackup will do this, tar
  51. might be a better choice if you have to much with the software.)
  52.  
  53. >3) concatenate files into a single file are COPY it to a /FOREIGN mounted
  54. >disk,
  55. >   so it starts at block 0 and keeps going - already tried and proves too hard
  56. >   for both ends to use, mainly because there is no demarcation between data
  57. >   sets 
  58.  
  59. If that is that close to working, I'd say creating an archive and copying that
  60. onto the disk is the way to go. Any archive that VMS can write and unix can read
  61. should work. There is none that ships standard with both systems, but there is a
  62. wealth of free tools to do the job.
  63. --
  64. Terry Poot <tp@mccall.com>                   The McCall Pattern Company
  65. (uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
  66. (800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
  67.