ENFSNMPM gets mainInit: node name 'NODEA' is not valid, getaddrinfo() rc=1

book

Article ID: 38973

calendar_today

Updated On:

Products

CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware CA Compress Data Compression for MVS CA Compress Data Compression for Fujitsu

Issue/Introduction

Problem:

Upgraded Common Services from r11 to r14.1

Had been using ENFSNMPM before for basic messaging. Updated the ENFSNMPM procedure for r14.1 but when the task starts it fails with RC=0004. The only indication of a problem are the following messages in the CAW1LOG sysout:

09:50:52 CAIENF SAPI/SNMP Trap Service, Version 3.0 - Feb 17 2012
09:50:52 MAIN: Started on Fri Mar 4, 2016 - asid(007A)
09:50:52 MAIN: Sysname: z/OS
09:50:52 MAIN: Nodename: NODEA
09:50:52 MAIN: Version: 01
09:50:52 MAIN: Release: 12.00
09:50:53 mainInit: node name 'NODEA' is not valid, getaddrinfo() rc=1
09:50:53 MAIN: main_init return rc=4

 

Cause:

This is generally a problem trying to resolve the hostname of the system.

Basically, the current level of the code is issuing a standard gethostname() function and it is returning the HOSTNAME of the system, NODEA. This is then passed on a getaddrinfo() request, which results in a DNS call. Based on the failure, there was a DNS problem resolving the name.

 

Resolution:

Many times we see this simply due to a timing issue where ENFSNMPM starts prior to your TCP/IP network or RESOLVER task fully being initialized. If you are able to restart the ENFSNMPM task to get past the problem than this is the likely concern. Try to delay the start of ENFSNMPM until TCP/IP and RESOLVER are fully initialized.

If it is not a timing problem, check with your network administrator to verify the system hostname, and that it is properly defined to DNS.

 

Additional Information:

Take a look at your TCP/IP task to see whether it is picking up it's Host name from the TCPIP.DATA file. Look for the following message:

EZZ0162I HOST NAME FOR tcpstackname IS host_name

This message displays the host name for a TCP/IP stack. The host name is determined in the following way:

  1. The name on the stack's TCPIP.DATA HOSTNAME statement is used. The z/OS® UNIX search order is used to find the stack's TCPIP.DATA statements. See information about the search orders that are used in the z/OS UNIX environment in z/OS Communications Server: IP Configuration Guide for a description of this search order.
  2. If there is no valid HOSTNAME statement, the VMCF node name with which VMCF was started is used.
  3. If VMCF was not active when the stack was started, the CVTSNAME value (the SYSNAME=value in IEASYSxx that was IPLed) is used.

Environment

Release: CA90SV00200-14-Common Services-for z/OS
Component: