Re: QZSOSMAPD job permission denied CPE3401 problem -- MIDRANGE-L

Hi Tom,

Thanks! You got me questioning my assumptions, always a good thing. TCP was started, I was able to telnet, ftp, etc. The interfaces were active, the host table was fine, the domain info was good. Then I looked at port restrictions and voila! two restrictions -- one for port 449, the other for 8471, both restricted to my user id. I have a vague recollection of testing that, but must have thought I removed them after testing. They sat there lurking until I IPLd or tried to end/start the *SVRMAP or *DATABASE host server.

I removed both restrictions, end the two host servers in question and restarted them, and everything's back to normal.

Thanks again for the knock on the head<g>.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /

Tom Liotta wrote:

Peter Dow (ML) wrote:

I'm on a v4r4 model 150 that's been running forever (apparently since Feb.2007) but was re-IPLd last night. When it came backup, the QZSOSMAPD job had the following messages in its log:

Job 099893/QUSER/QZSOSMAPD submitted. Object changed. Object changed. Permission denied. Host server communications error occurred on bind() - Inet socket.

The "Permission denied" (CPE3401) error doesn't say what object is the problem. Is there any way to find out?

Peter:

What you're looking at appears to be a bit different from an authority failure from an attempted object access. This is a "permission" restriction that's being violated, or at least it's being reported as such.

The reference is to the bind() API for a socket. The docs for sockets APIs shows this for possible errors from bind():

"
[EACCES] Permission denied.

The process does not have the appropriate privileges to bind local_address to the socket pointed to by socket_descriptor (for example, if socket_descriptor is a socket with an address family of AF_INET, and the sockaddr_in structure (pointed to by local_address) specified a port that was restricted for use).
"

The EACCES error condition pretty much is the C macro name for the errno 3401. We often look at the message description that results from putting the letters [CPE] together with the errno -- in this case [CPE3401]. When you execute DSPMSGD CPE3401, you should see "Permission denied." as the returned text.

Now, as for tracking down what's going wrong, I guess the first thing I'd do is verify that my various TCP/IP configuration elements were as I expected. I'd start with the CFGTCP menu.

Do my interfaces have the right addresses? Are they started? Is TCP/IP running with them? (Did TCP/IP even start? Heh, that's a better starting place, I guess.) Use option 1.

Is my host table correct? Is my host name properly qualified and is it assigned to the correct address? Is my fully-qualified host name the first name assigned to the address or is it instead assigned as one of the aliases? Use option 10.

Is my host and domain name correct? Does it match what's assigned in the host table? Am I defining DNS access correctly? Use option 12.

If TCP/IP is running apparently okay and basic configuration seems okay, then you might want to look at option 4 to see if any port restrictions are showing up. You might also want to review the services table in option 21 to verify that the services that begin with [as-] are there and are assigned to the expected ports.

If everything seems reasonable, I'd probably ENDHOSTSVR *ALL and ENDTCPSVR *ALL and wait a couple minutes to let everything finish nicely (if any are running). Then, I'd ENDTCP OPTION(*CNTRLD) and wait for it to end nicely. I might even bring the line description down and back up.

When all of it was quiet, I'd start bringing them back up in the opposite order. I'd watch for any indication of trouble -- joblogs, QSYSOPR, QHST, basic stuff.

STRTCP by itself. Then STRTCPSVR for all or just ones you want, and finally STRHOSTSVR *ALL or one at a time.

It's possible that it was nothing but a timing issue during startup, e.g., TCP/IP didn't get going by the time the Server Mapper was starting. See if a controlled startup of services lets everything work.

If anything _doesn't_ work, then you have a good indication of where to look. You can at least ignore what would have come next.

At this point, that's about as far as I can go. And if you run into a specific issue in that sequence that you can't figure out, Scott Klement might be the best help you can get.

Tom Liotta