ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

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

book

Article ID: 38973

calendar_today

Updated On:

Products

CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services Datacom/AD CA ecoMeter Server Component FOC EASYTRIEVE REPORT GENERATOR FOR COMMON SERVICES INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA On Demand Portal CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware Compress Data Compression for MVS 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: