From: bruce@ais.com (Bruce C. Wright)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Request for technical assistance in CMU/Tek programming
Date: 19 Nov 92 13:51:40 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <9211181737.AA06500@uds2.ferranti.com>, jlhall@ficc.ferranti.com (Jonathan Luke Hall) writes:
> This article was originally posted to vmsnet.networks.tcp-ip.cmu-tek,
> but it has been suggested to me that I should post this to the CMU/Tek
> mailing list.
> 
> This is a request for technical information about the CMU/Tek programming
> interface and possible restrictions inherent in VMS.
> 
> I am currently involved in a project with developers on VMS and other
> platforms that requires communications over a TCPIP network.  [...]
> 
> Questions:
>  1) Am I correct in assuming that not being able to share a device
>     channel is a basic limitation within VMS?  

Yes.

>  2) If this is a basic limitation of VMS, is there an existing
>     workaround for CMU/Tek that allows two processes to share a TCP
>     connection?

I'm not familiar with the internals of CMU-TEK, but I'd be surprised
if there were.  While it's not impossible to do this, it would be an
odd way to structure a driver on VMS and I suspect it wasn't done.

Now having said this, why can't you effectively provide this kind of
service yourself?  For example, a `server' task could perform the
actual TCP connection, and do all of the actual I/O to CMU-TEK, and
the other programs could communicate with it by a mailbox (or some
other mechanism).  Except for the initialization, this could be made
to look very much like a socket interface shared between multiple
processes (though obviously the `channel' or `socket' numbers in the
various subprocesses will have little relationship to each other
except for what they happen to connect to on the other end).  Such a
server task is, literally, trivial to write on VMS.

> If the only answer is to use ASTs within a single process, we are
> aware of that "solution" and are prepared to implement it.  An AST
> solution does have its drawbacks, as we have found out.  VMS does not
> allow the use of locks to force single thread access when one of
> the contenders for the lock resource is an AST thread of a process
> that has the lock resource.  The solution to this is to use event
> flags, but this requires more code changes.

What are the locks for?  You _are_ aware, I hope, that AST's are
already guaranteed to be single-threaded in the sense that a single
process can have, at most, one AST active at a time.  (More than that
can be _queued_ but only one can be _active_).  If all you're trying
to do is to ensure that multiple AST's aren't corrupting each other
or allocating each other's resources, then you're trying to solve
a problem that doesn't exist.

On the other hand, if you are trying to lock resources that are
also used by other processes (such as database records), you might
be better off to maintain event queues that are sent between lock
manager AST's and TCP/IP AST's.

It is also possible to avoid AST's either mostly or entirely, and do
the bulk of the processing at process level, using asynchronous I/O.
It is not necessary for I/O on VMS to be synchronous as it usually is
on Unix;  you can issue a QI/O and go on with other processing, checking
the result of the I/O either at some later point in normal process-level
code or in an AST.

The way you word the question makes me suspect that you are setting
yourself up for some of the deadlock or synchronization problems
that are possible when using AST's or event flags and that you
don't fully understand their mechanism.  For example, waiting for
an AST to fire while you are inside another AST is a guaranteed
way to lock up because, as noted above, AST's are single-threaded.

> The "easy" solution of ASTs is not so "easy" in our environment.
> Basically, we need the "No, you can't do that on VMS..." documentaion
> for our management to explain the change in design and schedules for
> our implementation.

If you're having this much trouble figuring out the VMS environment
and/or dealing with your management's understanding of it, you might
be very well advised to find a local VMS guru that you can pay for a
few hours of consulting to go over some of the possible designs for
your problem in detail.  It might save you from an expensive mistake.

Good luck,

Bruce C. Wright