In this case, taking the traditional IBM approach, according to the manual, we
are entitled to conclude that *only* the EPROTONOSUPPORT, decimal 1110,
hexadecimal 0456, is a valid code to result from a socket() call.
From the z/OS Communications Server IP CICS Sockets Guide manual:
<quote>
7.5.42.3 socket() call return values
A nonnegative socket descriptor indicates success. The value -1 indicates an
error. To determine which error occurred, check the errno global variable,
which is set to a return code. Possible codes include:
EPROTONOSUPPORT
The protocol is not supported in this domain, or this protocol is not supported
for this socket type.
</quote>
"Possible codes include" indeed, my unmentionable in a family list!
So the *problem* which derives from this *issue* is that you have a return
code from a socket() call and it is *not* EPROTONOSUPPORT.
At this point, depending on you are entitled to be somewhere from mildly
irritated to spitting blood. I fear I tend to the latter end of that spectrum
when faced with this sort of nonsense[1] but you may be more sanguine if
you'll pardon the upset pun!
From the UNIX System Services Messages and Codes manual list of return
codes (errnos), section "2.0 Return codes (errnos)", we discover that decimal
167, hexadecimal A7, corresponds to EMVSNORTL with the meaning "Access to
the OpenMVS version of the C RTL is denied.".
OpenMVS of course equates these days to "UNIX System Services" and it's a
pretty solid bet that "RTL" stands for "Run-Time Library".
I'll now leave it to you to find out how you could have be failing to have the
services of the "C run-time library" available.
-
Having said all the above, I reminded myself that the *issue* of APIs for
socket programming is a troublesome one. It may be that the socket() call you
are using/trying-to-use is *not* the "non-UNIX" flavour - implemented by the
IP component of z/OS Communications Server - but rather than the "UNIX"
flavour - implemented by z/OS UNIX System Services Language Environment.
The z/OS Communications Server IP CICS Sockets Guide manual, which
documents only EPROTONOSUPPORT as a possible return code for the socket()
call, describes the "non-UNIX" API.
The manual which describes the "UNIX" API, z/OS XL C/C++ Run-Time Library
Reference", is rather more forthcoming regarding return codes to the socket()
call. The following are covered: EACCES, EAFNOSUPPORT, EAGAIN, EINVAL,
EIO, ENOBUFS, ENOENT, our old friend EPROTONOSUPPORT and finally
EPROTOTYPE.
However, searching the manual for "EMVSNORTL" turns up the following in
section 3.3, "Standards":
<quote>[2]
Dependencies
Some functions have the following dependencies identified. If the
dependencies are not met, then the function fails, and returns an errno of
EMVSNORTL. Functions defined by the standards that cannot fail, will cause
abnormal termination and return Language Environment condition CEE5001.
POSIX(ON) required refers to whether the enclave can run with the POSIX
semantics.
POSIX is an application characteristic that is maintained at the enclave level.
After you have established the characteristic during enclave initialization, you
cannot change it.
When you set POSIX to ON, you can use functions that are unique to POSIX,
such as pthread_create().
One of the effects of POSIX(ON) is the enablement of POSIX signal handling
semantics, which interact closely with the z/OS Language Environment
condition handling semantics. Where ambiguities exist between ANSI and
POSIX semantics, the POSIX run-time setting indicates the POSIX semantics
to follow.
</quote>
So it looks as if it might be the case that, with some not completely solid
justification given that this code is likely to show up first and never
thereafter
for the initial socket() call, EMVSNORTL is a return code which could apply to
*all* socket calls and so is mentioned separately. Well, I don't buy it but an
IBM lawyer would!
Given the disparity in return codes, it is distressing to appreciate that both
the APIs actually map to one lower-level API, the "z/OS UNIX System Services
Callable BPX Sockets" API. Take a look at the famous Figure 3, "TCP/IP
networking API relationship on z/OS" in the z/OS Communications Server IP
Sockets Application Programming Interface Guide and Reference manual.
-
Checking back to your post, I see I have addressed only your question 1.
You may find that questions concerning CICS are best posed on the CICS-L
list:
http://www.listserv.uga.edu/archives/cics-l.html
-
[1] I encountered this lackadaisical approach to documenting return codes for
socket calls when I was putting together a presentation on just that subject,
socket calls, in the context of teaching sockets. I remember going to
classrooms where there were sets of AIX manuals and checking the
documented return codes against what the whatever MVS was called then
manual. IIRC there was rarely a complete correspondence and the lack of
correspondence could *not* be explained somehow by the difference
in "platform".
[2] While "spell-checking", I discovered that mine works better than the one
IBM uses!
-
Chris Mason
On Thu, 21 Apr 2011 13:49:14 -0700, John Weber<j...@fiteq.com> wrote:
Hi,
We are calling from z/OS CICS COBOL to a C program which is opening a
socket to start a TCPIP connection and we got back error 167 from the socket
() function call.
However, if we call from Batch to the same C program as above, the socket
opens correctly.
Three questions:
1. What does errno = 167 from the socket() call mean?
2. Do we need any user privileges (such as Unix root) for a CICS user to
perform this function within Unix?
3. Is there any step by step how to configure the CICS to allow a C routine
to open a socket in Unix?
We urgently need some guidance on this issue.
Thank you in advance for your support.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
