Jim Taking John McKown's hint - which followed on from Mark Jacobs's very sensible suggestion - I have looked into inetd.conf.
Unfortunately I do not have a system to hand so I can't be sure what exactly is contained within the inetd.conf file as supplied. I did discover what might be the inetd.conf file as supplied in the series of redbooks with the name IBM z/OS V1Rx Communications Server TCP/IP Implementation Volume 2: Standard Applications There is what may be the supplied inetd.conf - *not* in the INETD chapter unfortunately - but in the chapter for "Remote Execution" and only up to V1R8. From V1R9, the good authors of the redbook decided to use the inetd.conf file they set up themselves for the INETD chapter and replaced the sample used hitherto. The following is the file found in the V1R8 version of the redbook which is identical to the file found in the V1R7 version of the redbook and I am rashly going to assume it is the same as can be found in any recent release. <quote> Example 9-11 Sample /etc/inetd.conf file with orexecd/rexecd record #========================================================= ================================== # service | socket | protocol | wait/ | user | server program | server program # name | type | | nowait | | | arguments #========================================================= ================================== # otelnet stream tcp nowait BPXOINIT /usr/sbin/otelnetd otelnetd -l - m -t -c 10800 #shell stream tcp nowait BPXOINIT /usr/sbin/rshd rshd -LV #login stream tcp nowait BPXOINIT /usr/sbin/rlogind rlogind -m exec stream tcp nowait BPXOINIT /usr/sbin/rexecd rexecd -LV #finger stream tcp nowait BPXOINIT /usr/sbin/fingerd fingerd #smtp stream tcp nowait BPXOINIT /usr/lib/sendmail sendmail -bn #talk dgram udp wait BPXOINIT /usr/sbin/talkd talkd </quote> Incidentally I see I have formatted this "quotation" way better than it is presented in the redbook! So you will find here a precise match between the two "missing" files as reported in the messages. It remains only for you to confirm that, indeed, the "#" comment characters have been removed and then to ask whoever was responsible what he/she had in mind when the comment characters were removed. This assumes, of course, that the person responsible is still available, that is, has not been "let go" or was not a consultant. If the person is not available, you should check the installation notes or whatever he or she left either for his/her successors or as a conclusion of the "engagement" respectively. - Looking up a BPXF024I message is clearly a bit of a challenge. It seems you need to note that, in this case, the process "inetd" is in some way responsible but then check the following embedded message with the header FOMN0019, courtesy of "IBM Lookat": http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/BPXZA8A0/SPTMN0019 <quote> 1.2.5.15 FOMN0019 FOMN0019 execv server: errdesc, rsn=reason_code Explanation: The execv() of the server programs associated with a request has failed. In the message text: server Pathname of server program being executed. errdesc Error description associated with the errno returned from execv() . reason_code The reason code returned from execv(). System Action: inetd will abandon the request. System Programmer Response: Ensure that the server program exists. If the name is wrong, correct the appropriate entry in the inetd configuration file. </quote> I guess you could add the another "action" to the "System Programmer Response" which is "replace the '#' comment character in inetd.conf or take the <expletive deleted> line out since the <expletive deleted> line shouldn't have been there in the first place". But maybe that's a bit strong for your anodyne IBM message! The explanation is sufficiently clear not even to get into that old topic of how to look up the "reason code" but just to be complete it means the following from the z/OS UNIX System Services Messages and Codes manual: <quote> 006C - JRFileNotThere - The requested file does not exist. Action: The service cannot be performed unless the named file exists. </quote> Chris Mason On Tue, 1 Mar 2011 09:22:18 -0600, Petersen, Jim <[email protected]> wrote: >This is what I am seeing in OPERLOG > >BPXF024I (OMVSKERN) Mar 1 00:17:37 inetd[84607211]: FOMN0019 execv >/usr/sbin/talkd: EDC5129I No such file or directory., rsn=053B006C > >BPXF024I (OMVSKERN) Mar 1 00:18:10 inetd[721369]: FOMN0019 execv >/usr/sbin/fingerd: EDC5129I No such file or directory., rsn=053B006C > >___________________________________________ >Jim Petersen > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Jacobs >Sent: Tuesday, March 01, 2011 9:09 AM >To: [email protected] >Subject: Re: Where can I find > >I think the real question is why are task's executing under zOS are >attempting to access these daemons? > > >On 03/01/11 09:53, Petersen, Jim wrote: >> I am seeing messages in my OPERLOG that tasks are trying to access /usr/sbin/talkd and /usr/sbin/fingerd and they are not in /usr/sbin. I am on z/OS 1.11 and I don't think they were there at 1.10 either. >> >> ___________________________________________ >> Jim Petersen ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
