Initializing the monitoring agent results in a U4039 abend plus a CEEDUMP

When you initialize the IBM® Z OMEGAMON® AI for Networks monitoring agent, you receive this message:

USER COMPLETION CODE=4039 REASON CODE=00000000

A SYMPTOM DUMP OUTPUT marker was generated that included the following system dump output plus a CEEDUMP:

13.48.xx STC06457 IEA995I SYMPTOM DUMP OUTPUT   283
283       USER COMPLETION CODE=4039 REASON CODE=00000000
283      TIME=13.48.XX SEQ=40266 CPU=0000 ASID=00D2
283    PSW AT TIME OF ERROR 078D1400  8B145FA ILC2 INTC 0D
283    NO ACTIVE MODULE FOUND
283    NAME=UNKNOWN
== Register values for SYMPTOM DUMP OUTPUT not included here ==

At the END OF SYMPTOM DUMP mark, the following log entry for the CEEDUMP was found:

CEE3204S The system detected a protection exception (System Completion Code=0C4).
From entry point KN3ACTMD at compile unit offset +00000096 at entry offset +000000
96 at address 20263A66. CEE3DMP V1 R11.0: Condition processing resulted in the 
unhandled condition.
ASID: 00D2 Job ID: STC07457 Job name: OMXEN3
Step name: OMXEN3 UserID: KN3USER
====== End of log entry message for CEEDUMP =======

Analysis of the CEEDUMP for these entries indicates that either the KN3ACTCS or the KN3ANMON load module was in control when the abend occurred. The failing CSECT varies and the SYMPTOM DUMP shows NO ACTIVE MODULE FOUND and NAME=UNKNOWN.

The problem is the result of an incorrectly linked load module. This could happen if you installed and maintained new code on a test environment and then copied or broadcasted it to other LPARs.

Proper execution of KN3ANMON and KN3ACTCS depends on the level of z/OS® used when the SMP/E APPLY step performs the original LINKEDIT of these modules. Typically, the system on which the code is installed, maintained, and executed is the same. When product installation, maintenance, and execution all occur on the same system, the libraries used to link and run the load modules are identical. As such, there is no need to re-link the KN3ACTCS and KN3ANMON load modules.

Problems can occur, however, if the level of the required link libraries differs from where the load modules were originally linked compared to where the load modules will execute.

To resolve the problem, run the KN3LINK job to re-link the load modules on the system in the environment where KN3ACTCS and KN3ANMON load modules will execute, especially if the level of the required link libraries where the modules execute might be at a different level from where the load modules were originally linked.

If the problem persists, re-link the modules in the environment in which they are to run.

To facilitate the re-link of KN3ACTCS and KN3ANMON, IBM® Z OMEGAMON® AI for Networks ships sample job KN3LINK. The sample KN3LINK job is found in the &rhilev.&midlev.RKANSAMU dataset. The following examples demonstrate when KN3LINK might need to be run to produce properly linked KN3ACTCS and KN3ANMON load modules.

In Example 1. KN3ACTCS/KN3ANMON are SMP/E installed, SMP/E maintained on LPAR_A.
The modules execute on LPAR_A. There is no need to run KN3LINK to re-link the load modules.
In Example 2, KN3ACTCS/KN3ANMON are SMP/E installed and SMP/E maintained on LPAR_A.
The load modules are then copied to LPAR_B where they will execute. KN3LINK must be run on LPAR_B to produce newly linked copies of the load modules.

To confirm the build date and time for KN3ACTCS, consult message KN3CT051, found in the KN3ACTCS log. To confirm the build date and time for KN3ANMON, consult message KN3N015I, found in the KN3ANMON log.