socket_fd( (formerly decc$socket_fd) allocates a new socket fd on every call

[Jeff44]

Our application mostly uses VMS channel #'s for IP sockets with the $QIO interface. There are a couple of operations such as select() which we cannot figure out how to do in the $QIO interface so we occasionally require the corresponding socket descriptor. We've found that calling socket_fd() on an open socket returns a different descriptor id each time. After 1000 or so of these calls socket_fd() starts returning -1. We can certainly keep track of this to avoid looking it up however it seems that this would be better done by socket_fd() so that it returns the same value on subsequent calls.

[Ian Miller.]

Is this a suggestion for improvement or are you reporting a bug?

[Jeff44]

I would call it a bug however the documentation is a bit ambigious and you could perhaps argue that this is the documented behavior. I'd still argue that it isn't useful for it to work this way but "improvement v. bug" is always in the eye of the beholder.

From:
http://h71000.www7.hp.com/doc/82final/6529/6529pro_013.html

Here the documentation implies that there is a single descriptor assocated with each socket that is returned:

"Returns the socket descriptor associated with a Socket Device Channel (SDC) for direct use with the OpenVMS C Run-Time Library."

But here in the description it says that it creates (associates) a file descriptor:

"This function associates a valid socket channel with an HP C run-time library file descriptor, and returns the file descriptor. The file descriptor can then be used with any HP C run-time library function that takes a file descriptor or socket descriptor as an input parameter."

[Ian Miller.]

Sounds to me the documentation could be improved but the routine doing what is expected.

Sounds like you should call socket_fd() once and save the value.

[Jeff44]

Just above decc$socket_fd() in the documention is the complimentary routine, decc$get_sdc(). decc$get_sdc() takes a socket decscriptor and returns the assocated VMS channel. No matter how many times this routine is called it returns the same channel. I think it is reasonable to expect that decc$socket_fd() would behave the same way.

I believe the current behavior of socket_fd() is a bug because allocating a new socketfd on each call has only drawbacks with no benefits. If you could explain to me why it is useful for the function to behave this way then perhaps I would agree with you.

[abrsvc]

I have to agree with Ian here. While the documentation can be interpreted in different ways, it sounds to me like a one time call. It is possible to have multiple channels open to the same socket. Each woul dhave its own descriptor. I would interpret the docs as stating that each call would provide a unique descriptor similar to a Fortran call using LIB$GET_LUN. Each call will return a different LUN.

The reason for the -1 return from the call is most likely the exhaustion of available descriptors.

Dan

[David Jones_21]

decc$socket_fd is just a public wrapper around the internal decc$$socket() function, which allocates an FD (and associated CRTL structures) for doing socket I/O (filling in
the VMS channel you supply). It doesn't try to find an existing socket FD with the specified VMS channel assigned.

Are you sure you can't accomplish what need using the IO$_SETMODE|IO$M_xxxATTN functions with ASTs that fire when the channel is ready?