Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!ptsfa!ihnp4!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.lang.c
Subject: Re: SYS$QIOW() (was: VMS Descriptors)
Message-ID: <1786@ttrdc.UUCP>
Date: Sun, 28-Jun-87 01:44:16 EDT
Article-I.D.: ttrdc.1786
Posted: Sun Jun 28 01:44:16 1987
Date-Received: Mon, 29-Jun-87 01:37:46 EDT
References: <7960@brl-adm.ARPA> <995@bloom-beacon.MIT.EDU>
Organization: AT&T, Skokie, IL
Lines: 19
Summary: kitchen sink system call

In article <995@bloom-beacon.MIT.EDU>, wesommer@athena.mit.edu (William Sommerfeld) writes:
< \begin{flame}
< sys$qiow() appears to be the equivalent to either write(), or
< writev(), or probably both at the same time, on UNIX systems.  This
< routine takes 12 arguments??!?  Eight of which are zero in this
< case??!??  No wonder DEC can't get the C runtime library to work
< correctly.

:-), I suppose....

sys$qiow() (and its synchronous brother, sys$qio -- the "w" stands for "wait")
is truly a kitchen sink system call through which all VMS I/O related activity
(except open and close, I think) ultimately goes.  It combines the function-
ality of UNIX read(), write(), ioctl(), select(), and more.
-- 
|------------dan levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an engihacker @        |		vax135}!ttrdc!ttrda!levy
|    at&t data systems division  |  Disclaimer:  try datclaimer.
|--------skokie, illinois--------|