Conference lassie::ucx

5409.0. "document ioctl() restrictions?" by CUJO::SAMPSON () Fri Apr 04 1997 00:07

           <<< TURRIS::DISK$NOTES_PACK:[NOTES$LIBRARY]DECC.NOTE;1 >>>
                                   -< DECC >-
================================================================================
Note 2135.0              document ioctl() restrictions?                3 replies
CUJO::SAMPSON                                        28 lines   3-APR-1997 01:03
--------------------------------------------------------------------------------
	Hello,

	The DEC C RTL Reference manual documents an ioctl() socket routine.
The UCX (TCP/IP Services for OpenVMS) Socket Programming manual does not
even mention this routine.

	We have customers who somehow get the impression (from what these
documents do and do not say) that the workaround ioctl routine provided
by UCX in SYS$COMMON:[SYSHLP.EXAMPLES.UCX] would not be needed for some
newer version of OpenVMS (V7.1), or UCX (V4.1), or DEC C (V5.5).  That is,
they expected the DEC C RTL ioctl() routine to fully implement all of the
functions for sockets.

	Testing shows that the ioctl() routine provided by DEC C RTL
does not implement the FIONBIO (non-blocking I/O) function, returning
-1 and setting errno to ENOSYS (which it is not documented to do).
Okay, it may have been mentioned in some (OpenVMS?) release notes
somewhere, but who remembers where?

	Do "we" (e.g. UCX) ever plan to implement FIONBIO for the DEC C
RTL ioctl() routine?  If not, shouldn't this restriction be clearly
documented (in both appropriate manuals)?

	Should I raise this issue as a QAR against the documentation?
If so, which database should get the QAR?

	Thanks,
	Bob Sampson
================================================================================
Note 2135.1              document ioctl() restrictions?                   1 of 3
XDELTA::HOFFMAN "Steve, OpenVMS Engineering"          7 lines   3-APR-1997 13:19
                          -< Wrong Folks -- Ask UCX >-
--------------------------------------------------------------------------------

   ioctl is platform- amd driver-specific.  I'd avoid it.

   If you want UCX to add ioctl calls, you'll want to raise
   this with UCX engineering.  (DEC C "calls through" to the
   UCX support code...)

================================================================================
Note 2135.2              document ioctl() restrictions?                   2 of 3
CSC32::J_HENSON "Don't get even, get ahead!"         18 lines   3-APR-1997 15:14
                           -< more details, please? >-
--------------------------------------------------------------------------------
I would to see a response to this from dec c engineering.  Note 1513 cites
some restrictions, but apparently has missed some.  And, we're starting
to see problems reported by customers who are running on OpenVMS V7.0
and later.  I expect that we will be seeing more of this, and the
CSC needs some concrete answers to give customers.  If the answer
is to compile with /prefix=except=ioctl, we need to know that.  If
there's more to it than that, we need to know that, also.

If this is already addressed or documented elsewhere, a pointer would
be greatly appreciated.

And, FWIW, if you compile with /prefix=all or /standard=vaxc, the
compiler calls decc$ioctl instead of ioctl.  Does decc$ioctl pass
this on to ucx, or does it handle it all by itself?

Thanks,

Jerry
================================================================================
Note 2135.3              document ioctl() restrictions?                   3 of 3
CUJO::SAMPSON                                        16 lines   3-APR-1997 23:05
                      -< cross-posting to UCX conference >-
--------------------------------------------------------------------------------
	Jerry,

	The problem here, as I see it, is that DECC$IOCTL, the only
"officially supported" ioctl there is, doesn't implement (some? all?)
basic socket functions (e.g. FIONBIO).  I agree that DECC$IOCTL is
just a jacket for a UCX-provided routine, so it's up to UCX to add
the missing implementation.  However, customers generally don't care
about this level of detail; it should "just work", especially when
no restrictions are documented.  Currently, the best available
workaround is provided by UCX as an unsupported example in
SYS$COMMON:[SYSHLP.EXAMPLES.UCX]UCX$IOCTL_ROUTINE.C.  This can reduce
the severity of the problem to the annoyance level.  Customers just
want us to either finally do it right, or document the restrictions.

	HTH,
	Bob Sampson

    Hi Bob,
    
    I'll run this note by the engineering team and ask if we should
    document the restriction.  Will get back to you with the result.
    
    Thanks for reporting!
    
    - Vickie White, tech writer for the UCX team