Why use U* over VMS

[Terry Poot]

In article <803 at inews.intel.com>, bhoughto at cmdnfs.intel.com (Blair P. Houghton)
writes:
>In article <69986 at iuvax.cs.indiana.edu> hughes at copper.ucs.indiana.edu (larry
hughes) writes:
>>In article <1380 at tharr.UUCP> sweh at 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 <tp at mccall.com>                The McCall Pattern Company
(uucp: ...!rutgers!ksuvax1!mccall!tp)     615 McCall Road
(800)255-2762, in KS (913)776-4041        Manhattan, KS 66502, USA