From: RC Bryan [rcbryan@hotmail.com]
Sent: Thursday, June 12, 2003 12:54 PM
To: Info-VAX@Mvb.Saic.Com
Subject: GNU-izing a Unix System V IPC, signal and socket system for
OpenVMS?

Is there any interest in GNU-izing a Unix System V IPC, signal and
socket system for OpenVMS?
 
Years ago, in porting a massive Unix based application (>3.5 million
lines of code) to VMS, my company developed an integrated system of
System V IPC, signal and socket routines.  The reason the development
occurred is because our software depends heavily upon having SIGIOs
interrupt the msgrcv service.  Since the basic UCX socket routines
don't issue a SIGIO on I/O completion, we were kind of stuck, but that
was a long time ago.
 
The actual development of these was before my time with the company. 
My personal feeling on developments like this is "you don't have to
write the operating system, the OS vendor has already taken care of
that for you."  While it is possible that there could have been a way
to make things work without writing a Unix subsystem, it is written,
it works and it is solid.  It is in use all over the world and I have
had to fix about two bugs in the last 18 months or so.
 
What is there:
1. Full System V IPCs.  Every last bit in every service is accounted
for.  I was blown away when I first saw how complete this is.  This
comes with ipcs and ipcrm routines.  Semaphores and other internal
data structures are maintained in memory that can only be accessed
only in kernel mode so they are safe from misbehaving programs.
2. TCP/IP Sockets.  This is not as complete as the IPCs.  We are kind
of subject to the underlying UCX stack.  This is a layer on top of
$QIOs, parallel to UCX.
3. POSIX signal handling.  This is pretty good.  The signals are
modeled as ASTs.  It was news to me that one process could schedule an
AST for another similar to the Unix kill service (via SCH$QAST) but it
is in there.  The availability of alarm, ualarm and kill is a given.
4. Integration between the IPCs and the sockets.  We evaluated all
kinds of products and nothing provided the ability to have an EINTR
return from a msgrcv; ie, breaking out of a IPC queue message read
when network I/O is received.
5. Process management.  It is kind of hard to quickly describe but
because we have to do interprocess ASTs, all processes must be known
to the subsystem.  It is possible to spawn independent child
processes, not subject to the quotas of the parent.  All background
processes can be run under the debugger and can use the "system" C-RTL
routine.  A facility to provide selective privileges and quotas for
background processes is included.  There is not a fork but there is a
functional replacement for fork/exec.
6. Child processes inherit process table logicals.  
7. Test routines that can be used to test/demonstrate about 95% of the
functionality. (Not 100% because the functionality was extended after
the initial development and the test routines were not amended.)
8. A set of disk I/O routines that when the I/O is complete, the data
is on disk -- 100% guaranteed.  This is one of those things where we
tried all the RMS options from the C-RTL and nothing would work 100%
of the time.  Our QIO routines bypass RMS and they work every time.
9. Active socket passing.  A construct that is common on Unix is to
open a TCP/IP socket from a client and pass it to a child process
after some initialization data has been exchanged.  We needed this and
it is part of the package.
 
What is missing:
1. UDP/IP. This is not used by our code so no effort was put into it.
2. Threading.  This is one reason I want to make this open source.  I
have some ideas of how to extend the code for full threading support
but I don't have time to implement them.
3. TCP/IP streams.  The new version of our product uses streams.  This
is another reason to make it open source.
 
Where we stand:
The code is currently has the bad old style closed source proprietary
restrictions but we don't make money on it as a separate product and I
don't see how it is going to do anything but help us and our
customers, to make it generally available.   I think that if I can
convince management that there is interest on the outside and that
people will be fixing bugs or adding enhancements, they will tell me
"take it away!"  Realistically, since I am the only one that knows
this code inside and out these days (there are other people but I am
the only one for almost two years), this will mean more work for me in
the short term, answering questions and fixing bugs but in the long
term, we will get a better product and the community will get a
valuable resource.
 
Comments anyone?
 
Regards,
/RC Bryan