Re: Error 167 from socket() call in CICS
On Thu, 21 Apr 2011 13:49:14 -0700, John Weber 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. Do you have TCPIP.SEZATCP in both your //DFHRPL and //STEPLIB ? Is it before the CEE.SCEERUN? >However, if we call from Batch to the same C program as above, the socket opens correctly. That's because in batch a different version of the LE and TCPIP run-time is used. >Three questions: >1. What does errno = 167 from the socket() call mean? Chris has made this clear. And I totally agree with him about the lack of decent documentation in this area. >2. Do we need any user privileges (such as Unix root) for a CICS user to perform this function within Unix? I don't think so. Well, you will need an OMVS segment and things like that, but as far as I know, nothing out of the ordinary specific for using socket calls with respect to other Unix System Services... >3. Is there any step by step how to configure the CICS to allow a C routine to open a socket in Unix? Not that I know of. But the Comms Server manuals will get you a fair length on the right way... Cheers, Jantje. -- 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
Re: Error 167 from socket() call in CICS
On 22/04/2011 12:59 PM, Chris Mason wrote: John The *issue* here is that IBM - and possibly other vendors - when dealing with socket calls - that's socket calls in general not just the actual socket() call - just seem not to be comprehensive in documenting all possible return codes (errnos) for each call. For some reason which must somehow be related to the attitudes associated with the UNIX heritage and totally at odds with at any rate my experiences with the traditional IBM approach, only some subset of the possible return codes - according to some unfathomable whim of the manual author - actually appear. That's probably why IBM implemented errno2, which in an analog for a reason code. There is a shell script and TSO command BPXMTEXT which prints the man pages for errno2 codes. 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: 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. "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": [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. 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 C
Re: Error 167 from socket() call in CICS
John The *issue* here is that IBM - and possibly other vendors - when dealing with socket calls - that's socket calls in general not just the actual socket() call - just seem not to be comprehensive in documenting all possible return codes (errnos) for each call. For some reason which must somehow be related to the attitudes associated with the UNIX heritage and totally at odds with at any rate my experiences with the traditional IBM approach, only some subset of the possible return codes - according to some unfathomable whim of the manual author - actually appear. 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: 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. "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": [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. 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
Error 167 from socket() call in CICS
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