We have the source to SNDM (it's open source).

The message we're seeing in the job log is from where a routine checks for socket descriptor (SD) is less than 0. At this point it fails, and writes out the error condition and the SD to the job log. I don't see anywhere else that modifies the SD variable besides the return from socket(). Unfortunately, this check is long after the call to socket(), when it's too late for errno(). One odd thing is that the connect() call with this SD isn't reporting a -1 result.

This utility isn't checking errno() for error numbers at this point. I've got a plan to change it to capture errno() and dump when it gets a negative socket, but we don't want to put that in production on a Friday, and we aren't seeing the problem in our test environment. (Actually, the other odd thing is that this is affecting our production webserver jobs most, not our test webservers.)

We're going to IPL over the weekend anyway, so maybe that'll take care of the problem. If not, I'm going to try to get at the errno() returned by the system and that should tell us what's going on.

Thanks for your help.

--

John Maassel
Programmer/Analyst
3776 South High Street
Columbus, OH 43207
Phone: (614) 492-7413


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, September 30, 2011 1:36 PM
To: Midrange Systems Technical Discussion
Subject: Re: Are negative socket descriptors valid?

hi John,

-1 indicates an error.
0 or higher is a valid descriptor.

There should never be any other negative numbers (besides -1) returned by the socket() API. But, are you certain that the -250 to -350 is returned by the API? How would you know that, do you have the source code?

It seems to me that the sockets used by CGI are build/handled by Apache.
and the sockets used by SNDM are built/used by SNDM. So I don't see why you'd ever see a socket descriptor yourself?


On 9/30/2011 7:55 AM, Maassel, John R. wrote:


We've been running the SNDM command without trouble for years. Now
we're seeing a large number of sends failing because of an invalid
socket descriptor (the integer returned by the socket() function and
passed to all other functions, like connect(), select(), etc.).
They're in the -250 to -350 range and another piece of SNDM is
rejecting this as invalid as it's less than zero.

I checked the API for the socket() API and it describes 2 return
codes: -1 if there was an error, or 'n' if there was not.

It doesn't say whether n is supposed to be positive, but other
platforms I've coded on (and with the file descriptor for open() on
the i) expect the socket to be positive.

Are negatives allowed? If they are not, why is the system suddenly
returning negative sockets? We upgraded from V5R4 to 6.1 about a
month ago.

What may or may not be related is we're seeing a bunch of this
happening in CGI jobs.

Any advice will help. Thanks.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

________________________________

Notice from Bob Evans Farms, Inc: This e-mail message, including any attachments, may contain confidential information that is intended only for the person or entity to which it is addressed. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.