Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall.com!tp From: tp@mccall.com (Terry Poot) Newsgroups: comp.unix.programmer Subject: Re: Why use U* over VMS Message-ID: <1990Nov6.161325@mccall.com> Date: 6 Nov 90 22:13:25 GMT References: <803@inews.intel.com> <1089@dg.dg.com> <1380@tharr.UUCP> <69986@iuvax.cs.indiana.edu> Reply-To: tp@mccall.com (Terry Poot) Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 86 In article <803@inews.intel.com>, bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >In article <69986@iuvax.cs.indiana.edu> hughes@copper.ucs.indiana.edu (larry hughes) writes: >>In article <1380@tharr.UUCP> sweh@tharr.UUCP (Stephen Harris) writes: >>>How in VMS do you have filters and pipelines? >>>eg, what would be the VMS (DCL?) equivalent of >>> getso - | tbl | pic | eqn | rof | col | sqps | lpr -Ppost < file >>> >>>Is there an equivalent, or would it need a lot of temporary files? >> >>Yes, you would need a lot of temporary files. VMS already has a mechanism similar to pipes, called mailboxes. The major difference is that mailboxes are record rather than character oriented. "Fixing" this would only require a new device driver to implement a character oriented mailbox (aka pipe). Note that the record oriented nature is not an insurmountable problem, even now. You just have to make sure your buffers are properly flushed. I ported the PBMPLUS utilities to VMS and can pipe them all together just fine. The code that does the pipes has been floating around the net for a long time, and is widely available. I made a very simple mod to handle binary data. Thus this is possible, just not commonly done on VMS. One of the reasons for that is that VMS is slower at creating subprocesses than unix, another is just a cultural issue. >Would a POSIX-compliant VMS fix this? In answer to the various responses to this comment: Jay Maynard: >Uhm, Blair...could VMS be hacked up into POSIX compliance? If so, then it's >a looser standard than it should be... Why, because VMS can comply with it? :-) Yes, VMS will be made POSIX compatible. This will be delivered in '91. It will also be made XPG/3 compatible (not sure about the time frame). This is not a small project, DEC has been talking about it for over a year at DECUS sessions. Larry Hughes: >To answer the first question, a POSIX-compliant VMS would not >fix this, to my understanding. POSIX defines the calling standard >(interface) to the operating system. However, I don't have a deep >understanding of this, so don't take my word for it. As I said, VMS can already do this. If pipes are part of the POSIX standard, then it will be able to do it with even less work. Whether the standard VMS utilities are modified to work as filters is a whole 'nother question. Ran Atkinson: BTW, I agree with Jay that the POSIX standard is looser than it >should be -- especially in the Shell & Tools area. The fact >that DEC plans a POSIX compliant VMS without a major overhaul >is an excellent existence proof that the standard is too loose. Who said it wasn't a major overhaul? At the presentation I attended, they said that the POSIX system calls would be added to the VMS kernal, equal in status to the existing VMS system services. Supporting unix-style links will require major changes to the file system. This is a major, long-term project that DEC has been working on for years. They have announced their intention to support future POSIX standards as they stabilize (they are currently only talking about 3 of them, I forget which). They will have VMS branded by X/OPEN as XPG/3 compatible. They are going to add much if not most of the OSF technology (they already have Motif), especially the DCE (distributed computing environment), with the eventual goal of being completely compatible with the OSF specs. They fully intend to make VMS a proper superset of "standard" unix, as such a thing comes into existance. As far back as the founding of OSF, before they decided they were going to license code and not just write specs, Ken Olsen boasted that VMS would be the first OSF compliant operating system (which created a furor among unix vendors who think that open systems must be unix by definition, which would be a cute oxymoron). Who knows, if all the unix vendors had to implement OSF from scratch, they might have made it (especially since significant parts of Motif and the DCE come from DEC in the first place). Disclaimer: I am not affiliated with DEC except as a customer. The above information all comes from articles published in various DEC-oriented magazines, and presentations given by DEC employees that I have attended at various DECUS symposia. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA