NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/vms/14360

Internet Message Format | 1992-08-31 | 5.0 KB

Path: sparky!uunet!olivea!decwrl!concert!ais.com!bruce
From: [e-mail] (Bruce C. Wright)
Newsgroups: comp.os.vms
Subject: Re: at the risk of drawing severe flamage - q's about VMS/DCL & Unix
Message-ID: <[e-mail]>
Date: 31 Aug 92 11:04:12 GMT
References: <[e-mail]>
Organization: Applied Information Systems, Chapel Hill, NC
Lines: 88

In article <[e-mail]>, [e-mail] (Ronan Waide) writes:
> Hi all,
>
> I'm currently working with a Unix system and will soon be returning (after
> Christmas) to a VAX 8350 (8530??) running VMS 5.3 ish. What I want to know
> is if the vanilla VMS comes with any feature resembling a Unix pipe? To any
> who may be unfamiliar with the concept, it's a means of connecting the output
> of one program/command directly to another so for instance, you could run a
> file through sort to sort it and then put the output through a program to
> throw away doubles; on Unix, this is simply a matter of piping sort's output
> to the input of the second prog, while the only way I'm aware of on VMS to do
> this would by to /OUTPUT=SYS$SCRATCH:TEMPFILE and then read TEMPFILE into the
> next program.
>
> <<<<<Now donning NOMEX underwear in anticipation of flamage ;-7 >>>>>

Not sure why you're afraid of flamage;  that seems like a reasonable
question.

There are several ways this kind of facility can be accomplished on
VMS.  They all have some advantages and disadvantages.

    1)    You can use mailboxes.  This is the usual VMS interprocess
    communications mechanism;  for many purposes this is exactly
    what you want.  The problem is that it is not "exactly" a
    Unix pipe, you give it "records" rather than "streams of bytes";
    this causes problems with programs that want to read their input
    as a stream of bytes because each "read" operation from the
    mailbox wants to read the entire "record" that had been written.
    If you control the program's use of the mailbox this isn't a
    problem because you can always write a low-level routine that
    hides this implementation from the high-level code, but if
    you're trying to use a program from elsewhere (DEC for example),
    it may or may not work the way you'd expect.  Mailboxes are
    usually one-way;  although the "consumer" program can write
    to its input mailbox this just has the effect of sending the
    data right back to itself.

    2)    The older style pseudo-terminal driver (versions available from
    DECUS and from DEC with older versions of DECwindows).  This
    mechanism has two drivers, a "producer" driver (PYDRIVER) and a
    "consumer" driver (TWDRIVER) that implement a two-way terminal-
    like connection between two programs.  Unlike pipes and mailboxes,
    this is an effective two-way connection;  this may or may not be
    desirable for your application.  It's very easy to use, and can
    be used very nicely to do things like create virtual terminal
    sessions and the like.

    3)    The newer style pseudo-terminal driver found with newer versions
    of DECwindows.  This uses the FTDRIVER, which is somewhat more
    difficult to use (from the "producer" side, not the "consumer"
    side, which still just sees a "normal" terminal connection) than
    the TWDRIVER/PYDRIVER combination, but on the other hand is more
    efficient.

    4)    You can also use the DECnet task-to-task mechanism.  This is
    sort of like a two-way mailbox in that both programs can read
    and write to each other in the expected way, but the interaction
    is record-oriented like a mailbox rather than byte-oriented like
    a pseudo-terminal.

There isn't a very pretty command-line interface to these facilities
in standard DCL like there is in the Unix shell - most people use the
mechanism you described with /OUTPUT=tempfile and then starting the
next program with /INPUT=tempfile (or however the respective programs
support I/O redirection;  often they'll allow redirecting SYS$OUTPUT and
SYS$INPUT which is conceptually more like the way it's done on Unix
although the syntax is much wordier).

But there are programs around that will allow you to use the |, >, and <
characters to do this like you can on Unix - you can get VMS Posix or
the DECUS software tools (see the DECUS library posting I put on here
a few days ago).  The down side to it is that processes on VMS are very
"heavyweight" compared to processes on Unix, and have much more context
that needs to be copied -- therefore this use of pipes is much less CPU
efficient than it is on Unix.  (The usual VMS way to chain programs
together is to use dynamic linking, and call in a new image into the
_same_ process either as a subroutine or to replace the current image.
This is very efficient, even more so than forking a new process on Unix,
but less flexible - the called image often has to be aware that it might
be called dynamically, and you can't normally do this dynamically from
the command line, only within your program code).

That's a quick summary of your possible approaches - you need to look
at the documentation to get the complete story, but this will give you
enough to know where to look & what your choices are -

Bruce C. Wright