Thread View: vmsnet.internals
2 messages
2 total messages
Started by bleau
Tue, 26 Jan 1993 00:54
Writing UNIX file sys from VMS
Author: bleau
Date: Tue, 26 Jan 1993 00:54
Date: Tue, 26 Jan 1993 00:54
77 lines
5008 bytes
5008 bytes
Hi, netters. I may be about to cross the line between the two worlds and become an outcast of both, but perhaps there are some on each end that can assist me. I am a manager/programmer at a VMS site. We have a VAXstation 3100-76 running VMS 5.4-x, soon to be V5.5-1, and have Fortran and C available. We have as a requirement distributing data to other systems on megneto-optical media (rewritable optical disks, the 600MB ISO variety). This works well for most sites, since they also run VMS. There are, however, several sites which run some variant of UNIX, and we'd like to keep the same media in sending data to them. The problem is, they can't read VMS ODS-2 file format, and I don't know how to write a UNIX file system. Yet. That's where you can help. If we're to write something that can be mounted and read by a UNIX system, I need some specialized software at this end. I need to find out the specification for a UNIX file system, and then construct a program that will do it all for me. It then occurred to me that this may have already been done. So, VMSers, have any of you heard of this having been done, and can you give me pointers? If it has not, could it be done be mounting the optical disk /foreign and addressing it in a block oriented fashion? Would the drive which reads it get the blocks in the same sequence I wrote them, or would the MSCP info on the disk cause some problems? Has anyone tried this, and what problems have you encountered along the way? An ACP would be the best solution here. If you know of a third party that sells a low-cost package that'll do this, please mention it, too. And UNIXers, you, too, can help. Do you know where I can get info on a UNIX file system? A specification is best. Is there perhaps a set of code somewhere - written in C, of courses - that actually writes a UNIX file system, code that I could port to VMS, strip out the low level writes and replace them with appropriate VMS writes and i/o requests, and have 90% of what I need already working? Either nonlicensed or free code is best, plase. Thirdly, in case the first two alternates are impossible or unworkable, is there possibly some intermediate format which would be easy to implement and write at the VMS end, and be easy to read at the UNIX end? This format could be restrictive in the follwoing ways: not allow any updates of files or directories, is to be written completely only once at the VMS end, is to be read only at the UNIX end, allow only one level in a directory hierarchy (flat file system), assume files are contiguous, have no record separators (basicly UNIX stream format or VMS fixed-512 format), and any other simplifying assumptions. This may be the easiest to implement at both ends and would get the job done, at the risk of producing something *quite* nonstandard. We've considered other solutions, and none of them get a very good reception: 1) writing to 8mm tape - easily written and read, but strong project requirement toward using the same media for all, so this is a last choice 2) FTPing the files - hard to automate with UCX's FTP, and would require loading down the net on a daily basis with hefty amounts of data (multi-MB), something I think network managers would frown on, not to mention being impolite ;-) 3) concatenate files into a single file are COPY it to a /FOREIGN mounted disk, so it starts at block 0 and keeps going - already tried and proves too hard for both ends to use, mainly because there is no demarcation between data sets 4) borrow someone else's system which runs UNIX, NFS mount the optical disk from it on the VMS system, and use the NFS and remote UNIX systems to perform the conversion by just COPYing the files - would pose too large a burden on someone else (translate: probably couldn't get anyone to agree), since this would be every couple of days on a regular basis I'd normally say email the answers to me at bleau@umdsp.umd.edu, but this sounds like a topic where interaction during the answer phase would be most productive. Post your replies to vmsnet.misc and we can start the thread there, rather than posting to four (or more) news groups. I'll looko there in the next week or so. If you have specific questions, you can either post them or email to me directly at the above address. If you email it, I'll post your question with my reply to aid the brainstorming. Thanks for the help, all. Larry Bleau University of Maryland bleau@umdsp.umd.edu 301-405-6223
Re: Writing UNIX file sys from VMS
Author: Terry Poot
Date: Tue, 26 Jan 1993 14:42
Date: Tue, 26 Jan 1993 14:42
52 lines
3111 bytes
3111 bytes
In article <18148@umd5.umd.edu>, bleau@umdsp.umd.edu writes: >... >An ACP would be the best solution here. If you find one, please tell DEC so they can speed up VMS-POSIX file operations! >Thirdly, in case the first two alternates are impossible or unworkable, is >there possibly some intermediate format which would be easy to implement and >write at the VMS end, and be easy to read at the UNIX end? Two spring immediately to mind: VMS Backup and unix tar. There are unix utilities to read a backup tape, and VMS utilities to both read and write tar tapes. Probably these wouldn't need any major changes to operate on a disk. (Other archive formats are available on both systems: Zip, Zoo, etc., and can do compression, if that's useful to you.) I'd guess you could simply mount it /foreign on VMS and treat it pretty much like a tape. You might have to tweak the qio's a little, or maybe not. I've never done this on a disk. Similarly, on unix, you use the raw disk device name, and you should be able to directly read raw disk blocks. I wouldn't be surprised if this would work with no software changes, with both systems treating the raw disk basically like a tape, though, like I said, I've never tried it. >This format could >be restrictive in the follwoing ways: ... Either Backup or tar format would be less restrictive than what you said you'd be willing to accept. If you do have to write some software to access the raw disk, I'd write _only_ that. On VMS, write a file to disk copy routine and copy your chosen archive format onto the disk. On unix, write a filter to read the disk and pass it to stdout, and pipe it into tar or vmsbackup. (Dunno if vmsbackup will do this, tar might be a better choice if you have to much with the software.) >3) concatenate files into a single file are COPY it to a /FOREIGN mounted >disk, > so it starts at block 0 and keeps going - already tried and proves too hard > for both ends to use, mainly because there is no demarcation between data > sets If that is that close to working, I'd say creating an archive and copying that onto the disk is the way to go. Any archive that VMS can write and unix can read should work. There is none that ships standard with both systems, but there is a wealth of free tools to do the job. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads