Troubleshooting Guide

IBM Z NetView
Version 6 Release 3
Troubleshooting Guide
IBM
GC27-2865-05
Note
Before using this information and the product it supports, read the information in “Notices” on page
651.
This edition applies to version 6, release 3 of IBM Z NetView (product number 5697-NV6 ) and to all subsequent
versions, releases, and modifications until otherwise indicated in new editions.
This edition replaces GC27-2865-04.
© Copyright International Business Machines Corporation 1997, 2019.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM Corp.
Contents
Figures.............................................................................................................. xvii
About this publication......................................................................................... xxi
Intended audience.................................................................................................................................... xxi
Publications............................................................................................................................................... xxi
IBM Z NetView library.......................................................................................................................... xxi
Related publications ..........................................................................................................................xxiii
Terminology in this Library.................................................................................................................xxiii
Using IBM Z NetView online help...................................................................................................... xxiii
Accessing publications online............................................................................................................xxiv
Ordering publications ........................................................................................................................ xxiv
Accessibility ............................................................................................................................................ xxiv
Tivoli user groups.....................................................................................................................................xxiv
Support information.................................................................................................................................xxiv
Conventions used in this publication....................................................................................................... xxv
Typeface conventions ........................................................................................................................ xxv
Operating system-dependent variables and paths............................................................................xxv
Syntax diagrams.................................................................................................................................. xxv
Part 1. Getting started with troubleshooting...........................................................1
Chapter 1. Diagnosing problems................................................................................................................. 3

Finding solutions.................................................................................................................................... 3
RETAIN database..............................................................................................................................3
Contacting IBM Software Support ........................................................................................................ 3
Determining the business impact.....................................................................................................4
Describing problems and gathering information............................................................................. 4
Working with IBM Software Support..................................................................................................... 4
Submitting problems........................................................................................................................ 5
Obtaining fixes.................................................................................................................................. 7
Additional support information.............................................................................................................. 7
Receiving weekly support updates...................................................................................................7
Exchanging information with IBM Z NetView Support.....................................................................8
Receiving information from Z NetView Support...............................................................................8
Subscribing to IBM Z NetView support updates ............................................................................. 9
Following the diagnostic path.............................................................................................................. 10
Chapter 2. Classifying problems............................................................................................................... 13

Identifying symptoms.......................................................................................................................... 13
ABEND.............................................................................................................................................13
DOC................................................................................................................................................. 15
INCORROUT.................................................................................................................................... 15
LOOP................................................................................................................................................16
MSG................................................................................................................................................. 17
PERFM............................................................................................................................................. 19
WAIT................................................................................................................................................20
Finding problem types......................................................................................................................... 21
Chapter 3. Documenting and reporting problems.................................................................................... 23

Collecting problem data....................................................................................................................... 23
Documenting any problem...................................................................................................................23
iii
Documenting ABEND problems........................................................................................................... 27
Dump of a NetView ABEND............................................................................................................ 28
Dump of an FLBTOPO ABEND........................................................................................................ 32
Documenting DOC problems................................................................................................................33
Documenting INCORROUT problems.................................................................................................. 34
Documenting LOOP problems..............................................................................................................35
Documenting PERFM problems........................................................................................................... 37
Documenting WAIT problems..............................................................................................................38
Capturing Message Log Data................................................................................................................40
Part 2. Diagnosing the NetView program.............................................................. 43
Chapter 4. NetView program problem worksheet.................................................................................... 45

General information............................................................................................................................. 45
System-related information.................................................................................................................45
Installation exits and Command Lists................................................................................................. 45
Problem description............................................................................................................................. 45
Problem classification.......................................................................................................................... 46
Abend problems..............................................................................................................................46
Message problems..........................................................................................................................46
Loop problems................................................................................................................................ 47
Wait problems.................................................................................................................................47
Incorrect output problems............................................................................................................. 48
Performance problems................................................................................................................... 48
Documentation problems...............................................................................................................49
Chapter 5. Troubleshooting and initial diagnosis for the NetView program............................................ 51

Logon/Bind problems with Command Facility.................................................................................... 52
NetView subtask ends abnormally...................................................................................................... 53
Abend A78 received at task or NetView termination.......................................................................... 54
Abend U0258, U0268, or U0269 is received...................................................................................... 54
DSI625I message........................................................................................................................... 55
Return Codes for U0258 and U0269 abend codes........................................................................55
Return Codes for U0268 abend code.............................................................................................55
Abend 301 is received..........................................................................................................................56
Abend code (0C4 or other) or unexpected results occurred during delinearization..........................56
BNH160I–BNH163I messages........................................................................................................... 57
BNH161I......................................................................................................................................... 58
BNH162I......................................................................................................................................... 58
BNH163I......................................................................................................................................... 58
CNM983E, CNM998E, or CNM999E message is received.................................................................. 59
DSI124I message is received.............................................................................................................. 59
DWO049W message is received for a DSIFRE request.......................................................................60
DWO049W message is received for a DSIGET request...................................................................... 61
DWO090A message is received........................................................................................................... 63
DWO158W message is received.......................................................................................................... 64
DWO627E message is received (MS Transport cancels).................................................................... 66
NetView Automation not properly occurring.......................................................................................66
NetView Automation unexpectedly driven.................................................................................... 66
NetView Automation not driven when expected........................................................................... 67
The NetView program is not attempting to archive Canzlog data...................................................... 69
A NetView operator cannot browse archived data..............................................................................70
EP/Local errors not being recorded..................................................................................................... 70
Unsolicited remote errors or distributed mainframe server errors not recorded.............................. 71
Solicited data not recorded..................................................................................................................71
RMTCMD RUNCMD command response is displayed on MVS console.............................................. 72
Diagnosing NetView security problems...............................................................................................73
iv
Chapter 6. Diagnostic tools for the NetView program.............................................................................. 75
Interactive Problem Control System................................................................................................... 75
Installation...................................................................................................................................... 75
Operation........................................................................................................................................ 76
Summary of VERBX CNMIPCS verbs.............................................................................................. 78
Options for some CNMIPCS verbs..................................................................................................79
Options for the CNMIPCS TRACE verb........................................................................................... 79
Examples of option selections....................................................................................................... 80
IPCS command output................................................................................................................... 81
Network log with CMDMON, TASKUTIL or TASKMON command output ...........................................96
Network log data format.................................................................................................................98
Using MSGMODID to identify message origin................................................................................98
Identifying message origin when printing Canzlog data................................................................99
SMF Log Record 38 Subtype 2 task utilization data............................................................................99
SMF Log Record 38 Subtype 4 command statistics data....................................................................99
NetView trace..................................................................................................................................... 100
Using NetView trace..................................................................................................................... 100
Locating the trace when MODE=INT is specified........................................................................ 100
Printing the trace when MODE=EXT is specified......................................................................... 103
Describing NetView trace records displayed with the TRACE command MONOPER keyword..106
Trace record descriptions............................................................................................................ 108
IP Services trace records............................................................................................................. 117
Status Monitor internal trace records.......................................................................................... 138
Security Authorization Facility trace record.................................................................................140
SNA Topology Manager NetView trace entries............................................................................148
First failure data capture trace.......................................................................................................... 150
Program-to-Program Interface (PPI) trace facility........................................................................... 151
Understanding the PPI Trace Anchor Block and the PPI Trace Table........................................ 151
Understanding the Program-to-Program Interface Trace Record.............................................. 152
Locating the Program-to-Program Interface (PPI) Trace Table..................................................155
Locating the Oldest Program-to-Program Interface Trace Record.............................................155
Generalized Trace Facility (GTF) Output Files............................................................................. 156
Chapter 7. Troubleshooting and initial diagnosis for IP Management...................................................157

No DVIPA configuration changes received........................................................................................158
No distributed DVIPA statistics recorded..........................................................................................159
No data is returned from a DVIPA 3270 command or its associated sample..................................159
A command issued with DOMAIN=ALL from a sysplex master NetView program returns
incomplete data............................................................................................................................ 159
Distributed DVIPA Connection Routing data is incomplete in the workspace.................................159
OSA or HiperSockets data is not returned........................................................................................ 160
IP interface data is not returned........................................................................................................160
The Telnet server port active connections count is 0....................................................................... 160
Expected zERT data is missing in the TEP or not returned on the CONNSEC QUERY commands.. 161
No data returned using LIST STATUS=XCFGRPS command............................................................ 161
BNH587I message is received during NetView initialization........................................................... 161
BNH638I message issued per stack for Discovery Manager Resource........................................... 162
PLEXCTL command fails.................................................................................................................... 162
START XCFGROUP problems............................................................................................................. 162
Discovery commands fail................................................................................................................... 162
BNH067I message is received; unexpected switch of master NetView..........................................162
BNH558E message is received; master NetView unable to contact enterprise system................. 163
Chapter 8. Diagnostic tools for IP Management.....................................................................................165

CNMTRACE......................................................................................................................................... 165
RXTRACE............................................................................................................................................ 165
Workspace issues.............................................................................................................................. 166
v
Chapter 9. Diagnosing NetView problems related to the GDPS Active/Active Continuous
Availability solution............................................................................................................................ 167
Troubleshooting and initial diagnosis for the GDPS Continuous Availability solution..................... 167
Multi-site Workload Lifeline product not receiving EIF updates.................................................167
Enterprise master processing problems......................................................................................168
Problems related to automation.................................................................................................. 169
Diagnostic tools to use with the GDPS Continuous Availability solution..........................................169
Part 3. Diagnosing NetView Management Console and GMFHS problems............. 171
Chapter 10. NetView Management Console problem worksheet..........................................................173

General information........................................................................................................................... 173
System-related information...............................................................................................................173
Problem description...........................................................................................................................174
Problem classification........................................................................................................................174
Processor traps.............................................................................................................................174
Message problems........................................................................................................................174
Loop problems (hang/lockup)...................................................................................................... 175
Wait problems...............................................................................................................................175
Incorrect Output problems.......................................................................................................... 176
Performance problems.................................................................................................................176
Documentation problems.............................................................................................................176
Chapter 11. Graphic Monitor Facility Host Subsystem problem worksheet..........................................177

GMFHS information............................................................................................................................177
RODM applications.............................................................................................................................177
RODM methods.................................................................................................................................. 177
Abend problems (processor exception/trap/fault)..................................................................... 178
Loop problems.............................................................................................................................. 179
Wait problems...............................................................................................................................180
Incorrect output problems........................................................................................................... 180
Chapter 12. Troubleshooting and initial diagnosis for NetView management console and GMFHS.... 183
Alert and Alert History problems....................................................................................................... 186
Alerts are not listed in the Event Viewer at the NetView Management Console Workstation... 186
Alerts are not listed in the Hardware Monitor Alerts History panel............................................ 186
Alerts do not change status..........................................................................................................186
Command problems...........................................................................................................................188
Cannot initiate an IP Session using NETCONV............................................................................ 188
Cannot initiate an LU 6.2 Session using NETCONV..................................................................... 189
Command results are unexpected from Network Management Gateways................................190
Commands failed to run because of COS Gateway errors.......................................................... 190
Commands failed to run because of OST errors..........................................................................191
Commands failed to run because of PPI Gateway errors........................................................... 191
Commands failed to run because of RODM Attribute errors.......................................................191
Commands failed to run because of Service Point errors........................................................... 191
Commands failed to run because of Time-out errors..................................................................191
Commands failed with IHS2069W message, Command Exit not installed................................192
GMFHS problems............................................................................................................................... 192
vi
Errors are received during GMFHS Configuration initialization...................................................193
GMFHS Status Solicitation fails....................................................................................................193
Instrumentation (z/OS-based only) problems.................................................................................. 193
Events are not received from z/OS Instrumentation...................................................................194
Component or Connection Status is not properly reflected on the Topology Console.............. 194
Status problems................................................................................................................................. 194
Resource status is incorrect.........................................................................................................194
The resource exists but the status is not updated...................................................................... 195
Multiple Init_Accept Flows received........................................................................................... 196
Status Update performance decreases....................................................................................... 196
Status changes to resources are not reflected in views..............................................................196
Topology Console problems.............................................................................................................. 197
Unable to connect to the Topology Server from the Topology Console..................................... 197
Topology Console hangs during Sign-on......................................................................................198
Topology Console hangs when accessing a view........................................................................ 198
There Is a duplicate GMFHS resource on the Topology Console................................................198
Problems occur with minimized Windows...................................................................................198
Property changes are lost.............................................................................................................199
Topology Server problems.................................................................................................................199
Server does not start and setup_env.sh is not found.................................................................. 199
Setup_sh.cmd is found but BINDIR is not set............................................................................. 199
Topology Server starts but then closes (Windows) .................................................................... 199
Topology Server starts but then closes (all platforms) .............................................................. 200
Topology Server does not complete initialization on AIX........................................................... 200
Server windows disappear on AIX platform................................................................................ 200
Incorrect timestamps if the Topology Server is on the Windows platform................................ 200
View problems....................................................................................................................................202
Expected configuration or more detail view is missing............................................................... 202
Resource icon is missing from view............................................................................................. 204
Tree View list is incorrect............................................................................................................. 204
View Layout is incorrect............................................................................................................... 205
Unable to open view..................................................................................................................... 206
Unable to monitor views of your network.................................................................................... 207
View does not show correct connectivity.................................................................................... 207
View does not contain resource................................................................................................... 208
Multiple correlated aggregate objects contain the same object.................................................210
Real resource is not shown as a member of a Correlated Aggregate object.............................. 211
Information displayed for Correlated Aggregate object changes............................................... 211
Cannot navigate between Correlated Aggregate object and Contained Resources...................212
Pop-up Menu in the Business Tree is not displayed on AIX platform.........................................213
Preview Image partially painted in View Properties Notebook...................................................213
The Topology Display Subsystem view is not complete............................................................. 213
Chapter 13. Diagnostic tools for NetView Management Console and GMFHS...................................... 215
Diagnostic tools for the NetView Management Console...................................................................215
Log files......................................................................................................................................... 215
Access to Online Help without the console................................................................................. 215
Topology Console Environment Information Window.................................................................216
Message help for the Topology Server.........................................................................................216
Diagnostic tools for GMFHS............................................................................................................... 216
GMFHS message logs.........................................................................................................................216
GMFHS output logs.......................................................................................................................216
Console log window........................................................................................................................... 219
GMFHS Trace......................................................................................................................................219
Starting and stopping the GMFHS trace.......................................................................................220
Viewing the GMFHS trace online..................................................................................................221
Using the GMFHS internal trace................................................................................................... 222
IPC task tracing.............................................................................................................................223
vii
Event Manager task tracing.......................................................................................................... 223
Part 4. Diagnosing NetView REST Server problems............................................. 225
Chapter 14. NetView REST Server problem worksheet......................................................................... 227

Loop problems (hang/lockup)...................................................................................................... 229
HTTP Status Code problems........................................................................................................ 229
Chapter 15. Troubleshooting and initial diagnosis for NetView REST Server........................................231
Debugging methods........................................................................................................................... 231
Status code 400................................................................................................................................. 232
Status code 401................................................................................................................................. 232
Status code 424................................................................................................................................. 232
Status code 500................................................................................................................................. 232
Keytool fails........................................................................................................................................232
Browser does not trust the website's certificate.............................................................................. 232
NetView REST Server fails to authenticate valid credentials........................................................... 232
NetView REST Server can't start........................................................................................................233
Chapter 16. Diagnostic tools for NetView REST Server..........................................................................235

The NetView REST Server log............................................................................................................ 235
Setting the log to DEBUG mode................................................................................................... 235
Reading the log to determine what is causing a problem with the Server................................. 235
Part 5. Diagnosing RODM problems.................................................................... 237
Chapter 17. RODM problem worksheet.................................................................................................. 239

RODM applications.............................................................................................................................239
RODM methods.................................................................................................................................. 239
Abend problems........................................................................................................................... 240
Loop problems.............................................................................................................................. 241
Wait problems...............................................................................................................................241
Chapter 18. Troubleshooting and initial diagnosis for RODM................................................................ 245

Debugging methods........................................................................................................................... 248
Application failure.............................................................................................................................. 249
Return Code 12 with Reason Code 20 received.......................................................................... 250
Return Code 12 with Reason Code 121 received........................................................................251
viii
Abend 0C8 is received at RODM initialization................................................................................... 255
Abend 9C5 is received....................................................................................................................... 256
Abend 9C5 with Reason Code 0...................................................................................................256
Abend 9C5 with Reason Code 33.................................................................................................256
RODM abends when SNA Topology Manager is starting...................................................................256
User application looping.................................................................................................................... 257
Asynchronous method looping.......................................................................................................... 257
User API does not return from EKGWAIT..........................................................................................257
Incorrect output is in the EKGPRINT Data Set..................................................................................258
RODM fails to complete Checkpoint Processing............................................................................... 258
Abnormal reaction from RODM..........................................................................................................259
Slow response from RODM................................................................................................................ 260
Chapter 19. Diagnostic tools for the Resource Object Data Manager (RODM)......................................261
The RODM log.....................................................................................................................................261
Defining the RODM log (EKGSI101)............................................................................................. 261
Components that output data to RODM log files......................................................................... 262
Log-Level values........................................................................................................................... 262
The RODM log formatter...............................................................................................................265
The RODM Internal Trace.................................................................................................................. 301
Dumping dataspaces allocated by RODM......................................................................................... 302
RODM memory dump utility...............................................................................................................302
Starting the memory dump utility................................................................................................ 303
Coding the control parameters.................................................................................................... 304
Class listing report........................................................................................................................ 305
Class Index report........................................................................................................................ 308
Object Listing report..................................................................................................................... 308
Object Index report...................................................................................................................... 309
Statistical report........................................................................................................................... 310
Informational messages for the RODM memory dump utility.................................................... 311
RODM load function error listing....................................................................................................... 312
Part 6. Diagnosing SNA Topology Manager problems...........................................315
Chapter 20. SNA Topology Manager problem worksheet...................................................................... 317

Installation exits and command lists................................................................................................ 317
Problem information.......................................................................................................................... 318
Abend problems........................................................................................................................... 319
Loop problems.............................................................................................................................. 319
Wait problems...............................................................................................................................320
Chapter 21. Troubleshooting and initial diagnosis for the SNA Topology Manager.............................. 323
Problems during initialization............................................................................................................ 325
Wrong autotask error....................................................................................................................326
Insufficient storage for Topology Manager initialization.............................................................326
Error reading initialization file FLBSYSD...................................................................................... 326
Error reading customization table FLBOSIDS, FLBSRT, or FLBEXV............................................ 327
ix
Cannot connect to VTAM CMIP services......................................................................................328
Cannot connect to RODM............................................................................................................. 329
FLBTOPO task abends....................................................................................................................... 331
Abend during initialization............................................................................................................331
Abend after initialization.............................................................................................................. 332
User abend....................................................................................................................................332
Abend error conditions.................................................................................................................332
Topology Manager unexpectedly shuts down...................................................................................333
Topology Manager reinitializes unexpectedly...................................................................................335
Topology Manager seems to be suspended......................................................................................335
Automatic Monitoring is failing.......................................................................................................... 336
SNA Topology Manager cannot receive Agent Node Topology Data................................................ 337
RODM Object missing some attribute values....................................................................................339
Resources are not shown in the Views..............................................................................................340
Monitor Operation unexpectedly ends.............................................................................................. 342
Monitor Operation ended normally.............................................................................................. 345
Topology Manager or VTAM CMIP Services was ended by an operator..................................... 345
Topology Manager or VTAM CMIP Services unexpectedly ended.............................................. 345
An active VTAM path or session became inactive....................................................................... 345
Monitor operation stopped because of a Network Problem....................................................... 345
Blank status history for a Topology Manager resource.....................................................................346
A Locate Resource request does not find the resource.................................................................... 346
Cannot activate, deactivate, or recycle a resource........................................................................... 347
Network problems........................................................................................................................ 347
Generic commands fail.................................................................................................................347
Incorrect NetView Management Console command profiles...........................................................347
Objects are not purged...................................................................................................................... 347
Objects unexpectedly purged............................................................................................................350
The resource status is unknown........................................................................................................354
The Resource Is a node other than an APPN network node....................................................... 354
Resource is an APPN network node.............................................................................................355
Resource is a TG that does not connect two network nodes...................................................... 355
Resource is a TG that connects two network nodes................................................................... 355
Resource is a TG circuit................................................................................................................ 356
Resource is a link..........................................................................................................................356
Resource is a port......................................................................................................................... 356
Resource is an interchange node or a migration data host......................................................... 356
Resource is a t5Node................................................................................................................... 357
Resource status incorrect or not being updated...............................................................................357
Aggregate resource status incorrect or not being updated.............................................................. 361
Status of the Aggregate Resource Is unknown........................................................................... 362
Status of the Aggregate Resource Is known but incorrect..........................................................362
View of Topology Objects is not available for display....................................................................... 362
InterDomainNetworkCircuit view................................................................................................ 363
NnDomainNetwork view...............................................................................................................363
InterDomainCircuit view...............................................................................................................364
NnDomain view.............................................................................................................................364
SnaLocalTopology view................................................................................................................ 365
Link-Port view............................................................................................................................... 365
Real resource views......................................................................................................................365
Subnetworks shown in the same nnDomainNetwork view.............................................................. 366
Class of Node Object does not match node type.............................................................................. 367
Unexpected resources are displayed................................................................................................ 368
Resources reported by the agent nodes......................................................................................369
Status of the resource Is shown as unknown..............................................................................370
Status of an existing resource is not unknown............................................................................ 370
Status of a nonexistent resource is not unknown....................................................................... 371
Unexpected aggregate resources in views.................................................................................. 371
x
Exception view resource displays are incorrect................................................................................372
Chapter 22. Diagnostic tools for the SNA Topology Manager................................................................ 375
SNA Topology Manager messages.................................................................................................... 375
SNA Topology Manager log entries....................................................................................................376
SNA Topology Manager log record formats................................................................................. 376
System Interface log entries-Major Code 22...............................................................................378
SNA Topology Manager log entries—Major Code 78................................................................... 385
Common log entries-Major Code 79............................................................................................ 413
SNA topology manager traces........................................................................................................... 415
External tracing (GTF)...................................................................................................................415
Tracing internally.......................................................................................................................... 418
Trace events................................................................................................................................. 420
Recovery from Trace Errors..........................................................................................................429
TOPOSNA LISTxxxx Requests......................................................................................................429
Part 7. Diagnosing MultiSystem Manager problems.............................................431
Chapter 23. MultiSystem Manager worksheet....................................................................................... 433

Wait problems...............................................................................................................................434
Chapter 24. Troubleshooting and initial diagnosis for the MultiSystem Manager program..................437
Routing messages.............................................................................................................................. 438
Improving INITTOPO processing...................................................................................................... 438
RODM errors - FLC070E and FLC076E.............................................................................................. 439
RODM errors - Return Code 12 and Reason Code 122.....................................................................439
Issuing commands that contain case-sensitive text........................................................................ 439
Command support failures................................................................................................................ 439
GETTOPO command failures............................................................................................................. 440
Tracing GETTOPO command processing..................................................................................... 440
GMFHS is unavailable during GETTOPO command processing.................................................. 440
Failures in the IP environment..................................................................................................... 440
Command failures in the SNA environment.................................................................................441
Object status update failures.............................................................................................................442
Missing IP Objects from NetView Management Console Views....................................................... 443
Aggregate Object contains identical Real Objects............................................................................ 443
Part 8. Diagnosing Automated Operations Network problems............................. 445
Chapter 25. AON problem worksheet.....................................................................................................447

Abend problems........................................................................................................................... 448
Loop problems.............................................................................................................................. 449
xi
Wait problems...............................................................................................................................449
Chapter 26. Troubleshooting and initial diagnosis for AON................................................................... 453

AON and NetView initialization..........................................................................................................453
AON automation routines.................................................................................................................. 453
EZLEFAIL routine.......................................................................................................................... 454
EZLERECV routine.........................................................................................................................456
Part 9. Diagnosing Event/Automation Service problems......................................459
Chapter 27. Event/Automation Service problem worksheet................................................................. 461

System-Related information..............................................................................................................461
Alert adapter service information......................................................................................................461
Confirmed alert adapter service information.................................................................................... 462
Message adapter service information............................................................................................... 462
Confirmed message adapter service information............................................................................. 462
Event receiver service information.................................................................................................... 463
Alert-to-trap service information...................................................................................................... 463
Trap-to-alert service information...................................................................................................... 463
Abend problems........................................................................................................................... 464
Loop problems.............................................................................................................................. 465
Wait problems...............................................................................................................................465
Chapter 28. Troubleshooting and initial diagnosis for the Event/Automation Service......................... 469
Event/Automation Service abends.................................................................................................... 474
Event/Automation Service task might be suspended....................................................................... 475
START, STOP, or RECYCLE commands do not function properly..................................................... 475
A service does not complete initialization.........................................................................................475
Event/Automation Service fails to initialize.......................................................................................475
Alert adapter fails to initialize............................................................................................................476
Confirmed alert adapter fails to initialize.......................................................................................... 476
Message adapter fails to initialize..................................................................................................... 477
Confirmed message adapter fails to initialize................................................................................... 477
Event Receiver fails to initialize......................................................................................................... 478
Trap-to-Alert service fails to initialize............................................................................................... 478
Alert-to-trap service fails to initialize................................................................................................ 479
Unwanted services are starting......................................................................................................... 479
Alerts are not forwarded to the expected event server.................................................................... 480
Alerts are not converted to the expected Event Integration Facility events....................................481
An Alert is continuously forwarded................................................................................................... 482
An Alert is incorrectly cached............................................................................................................ 483
Messages are not forwarded to the designated event server...........................................................483
Messages are not converted to Event Integration Facility events....................................................485
A message is incorrectly cached....................................................................................................... 485
Event Integration Facility events are not forwarded to the hardware monitor................................486
Event Integration Facility events are not converted to alerts...........................................................487
No reply from an event server to which an Event Integration Facility event was sent.................... 487
xii
Negative response from an event server to which an Event Integration Facility event was sent... 488
SNMP traps are not forwarded to the Hardware Monitor................................................................. 488
SNMP traps are not converted to Alerts............................................................................................ 489
Recycling the NetView PPI................................................................................................................ 490
Recycling the Event Receiver for IP Connectivity problems.............................................................490
Recycling the Trap-to-alert service for IP Connectivity problems................................................... 490
Chapter 29. Diagnostic tools for the Event/Automation Service............................................................491

Output log...........................................................................................................................................491
Using online help................................................................................................................................491
Using commands................................................................................................................................491
DISPLAY STATUS..........................................................................................................................491
DISPLAY QSTATS..........................................................................................................................493
Trace...................................................................................................................................................493
The IP trace option....................................................................................................................... 494
NCCF GENALERT................................................................................................................................ 496
RPCINFO.............................................................................................................................................496
Using the TestMode statement..........................................................................................................497
Looping the Alert or Message Adapter to the Event Receiver.......................................................... 497
Looping the alert-to-trap service to the trap-to-alert service.......................................................... 497
Part 10. Diagnosing Z NetView Enterprise Management Agent problems............. 499
Chapter 30. Z NetView Enterprise Management Agent worksheet....................................................... 501

Abend problems........................................................................................................................... 502
Processor Traps............................................................................................................................ 503
Loop, hang, or lockup problems...................................................................................................504
Wait problems...............................................................................................................................504
Verifying TCP/IP stack or DVIPA Information ............................................................................. 505
Chapter 31. Troubleshooting and initial diagnosis for the Z NetView Enterprise Management Agent 507
NetView agent is not displayed in the Navigator view...................................................................... 508
Active/Active Sites subnode is not displayed in the physical Navigator view..................................509
NetView agent node unexpectedly goes offline ...............................................................................509
Z NetView subnode unexpectedly goes offline ................................................................................ 509
Tivoli Enterprise Monitoring Server becomes inactive while the NetView agent is running............510
NetView agent workspace has no data............................................................................................. 510
A GDPS Continuous Availability solution workspace has no data.................................................... 512
NetView agent workspace has partial data or incomplete data....................................................... 514
Message "KFWITM081E The link target cannot be found" when attempting to link to the
workspace of another product..................................................................................................... 514
No NetView agent workspaces available.......................................................................................... 515
Workspace names displayed in navigation tree are unreadable......................................................515
NACMD fails with BNH805I during initialization...............................................................................515
No commands available from the Take Action window....................................................................515
No NetView agent situations available..............................................................................................516
Incorrect results when using the icons in the NetView Command Response Summary view to
find or sort data.............................................................................................................................516
Cross-Product links missing from link list......................................................................................... 516
xiii
Problems with cross-product linking when linking to an OMEGAMON workspace......................... 516
Security problems.............................................................................................................................. 517
NetView agent workspaces have no column headings for the table views......................................517
Cannot start the NetView agent.........................................................................................................517
Missing NetView data when hub Tivoli Enterprise Monitoring Server is active on both
controllers..................................................................................................................................... 518
Chapter 32. Diagnostic tools for the Z NetView Enterprise Management Agent...................................519
Using NetView online message and command help for the NetView agent.................................... 519
Using the CNMTRACE function for NetView host components of the NetView agent function.......519
Using the NACTL command to troubleshoot the NetView agent......................................................521
Using the DISPPI command to troubleshoot a PPI connection between NetView and the
NetView agent............................................................................................................................... 521
Problem determination for a NetView agent.....................................................................................521
Problem determination flow for the NetView agent....................................................................521
Determining if the problem was caused by the NetView agent.................................................. 522
NetView agent communication layer messages and tracing...................................................... 527
Using the KDC_DEBUG environment variable............................................................................. 528
Setting up RAS1 tracing................................................................................................................529
Understanding and using RAS1 logs............................................................................................ 533
Capturing z/OS logs to send to software support........................................................................534
Appendix A. Diagnostic command summary....................................................... 539

NetView diagnostic commands...............................................................................................................539
NetView VERBX CNMIPCS commands....................................................................................................541
NetView Service Aid commands............................................................................................................. 544
RID DSIMSX........................................................................................................................................546
TASKURPT.......................................................................................................................................... 547
DSISTRLS........................................................................................................................................... 556
DSI24TRC........................................................................................................................................... 562
DSIMODQY......................................................................................................................................... 564
DSIGTVBA.......................................................................................................................................... 565
DSIGV2VR.......................................................................................................................................... 567
DSIGADHX..........................................................................................................................................568
DSISHWVR......................................................................................................................................... 569
WAIT timeout and storage limits............................................................................................................ 570
Appendix B. Flows and control blocks................................................................ 571

Request unit flows................................................................................................................................... 571
Control blocks..........................................................................................................................................575
Control blocks used during Command Facility initialization.............................................................575
Control blocks used during Operator Station logon (TVB)................................................................577
Control blocks used during Session Monitor initialization................................................................ 580
Control blocks used during Hardware Monitor initialization............................................................ 587
Control blocks used during Status Monitor initialization.................................................................. 588
Appendix C. RECFMS record formats.................................................................. 591

RECFMS header....................................................................................................................................... 591
RECFMS 00.............................................................................................................................................. 591
Text vector..........................................................................................................................................597
Detail qualifier vector.........................................................................................................................597
Name list vector................................................................................................................................. 597
Null Vector..........................................................................................................................................599
RECFMS 01.............................................................................................................................................. 599
RECFMS 02.............................................................................................................................................. 600
RECFMS 03.............................................................................................................................................. 600
RECFMS 05.............................................................................................................................................. 603
xiv
Release level data (RECFMS 05)....................................................................................................... 603
IBM System/38.................................................................................................................................. 603
IBM 3104............................................................................................................................................604
RECFMS 05, 3174 configuration information....................................................................................604
RECFMS 05 for the 3174: RPQ, patch, and DFT information............................................................619
Appendix D. DSINDEF data set format................................................................637
Appendix E. MDB to AIFR cross-reference.......................................................... 643
Notices..............................................................................................................651
Programming Interfaces..........................................................................................................................652
Trademarks..............................................................................................................................................652
Privacy policy considerations.................................................................................................................. 652
Index................................................................................................................ 655
xv
xvi
Figures
1. The Diagnostic Path for Classifying, Documenting, and Reporting Problems........................................... 11
2. NetView Error Message Format.................................................................................................................. 18
3. Sample memory dump of a NetView ABEND............................................................................................. 29
4. Sample memory dump Data of an FLBTOPO ABEND.................................................................................32
5. Example of the DSI625I message.............................................................................................................. 55
6. Diagnosing a Storage Overlay Problem Using IPCS................................................................................... 61
7. Diagnosing a Control Block Overwrite Problem Using IPCS...................................................................... 66
8. Syntax of the CNMIPCS Routine................................................................................................................. 77
9. Example of Summary Output......................................................................................................................82
10. Example of Output from the ASID Command.......................................................................................... 82
11. Example of Output from the CPOOL Command....................................................................................... 83
12. Example of Output from the D Command................................................................................................ 84
13. Example for Output from the IPCS DISPLAY Command..........................................................................85
14. Example of Output from IPCS DISPMOD Command................................................................................86
15. Example of Output Produced Using the DTCB Command....................................................................... 86
16. Example of Output from the IPCS LRCE Command................................................................................. 87
17. Example of Output from the MAP Command........................................................................................... 88
18. Example of Output Produced Using the MAP(sum) Command............................................................... 88
19. Example of Output from the NLDM Command.........................................................................................90
20. Example of Output from the NPDA Command......................................................................................... 91
21. Example of Output from the IPCS QUE Command.................................................................................. 92
22. Example of Output from the SAVEAREA Command.................................................................................92
23. Example of Output from the IPCS STORE Command.............................................................................. 93
xvii
24. Example of Output from IPCS TBLUSECT Command.............................................................................. 94
25. Example of Output from IPCS TRACE Command Using a Select Option.................................................94
26. Example of Output from IPCS TRACE Command Using a Trace Option..................................................95
27. Example of Output from the WHO Command.......................................................................................... 95
28. Example of Common Global Variables Output.........................................................................................96
29. Example of Task Global Variables Output................................................................................................ 96
30. Example of a Printed Network Log........................................................................................................... 97
31. Format of a Network Log in Storage......................................................................................................... 98
32. NetView Trace Records in memory dump output (MODE=INT)............................................................103
33. NetView Trace Records in Trace Log (MODE=EXT)............................................................................... 105
34. Example of HLL API Trace Area Output on Abend.................................................................................150
35. Data Structure: Program-to-Program Interface Trace Record..............................................................152
36. Example of the Output from the CNMS4501 Installation Exit.............................................................. 156
37. Examples for Correctly Defining RODM Attributes................................................................................ 193
38. Example of Current Trace Settings Displayed by the GMFHS TRACE Command................................. 221
39. PARM Keyword Example........................................................................................................................ 267
40. Example of JCL for EKGRLOG.................................................................................................................267
41. Formatted Log Record Header............................................................................................................... 269
42. Unformatted RODM Log Record Type 0................................................................................................. 270
43. Formatted RODM Log Record Type 0..................................................................................................... 272
48. Expanded Function Block....................................................................................................................... 277
xviii
49. Unformatted Log Record Type 3............................................................................................................ 278
60. Formatted RODM Log Record Type 8 for Segment and Window Statistics...........................................292
61. Formatted RODM Log Record Type 8 for API Statistics........................................................................ 294
64. Unformatted Log Record Type 10.......................................................................................................... 299
65. Formatted RODM Log Record Type 10...................................................................................................300
66. Example of Instream JCL for Generating a Charts Report.................................................................... 303
67. Coding Control Parameters in a SYSIN Data Set................................................................................... 305
68. Class Listing Report................................................................................................................................ 305
69. Class Index Report..................................................................................................................................308
70. Object Listing Report.............................................................................................................................. 309
71. Object Index Report................................................................................................................................309
72. Statistical Report.................................................................................................................................... 310
73. Sample RODM Load Function Error Listing............................................................................................ 313
xix
74. Example output of IP tracing for the alert adapter service................................................................... 494
75. SDSF print to database panel................................................................................................................. 535
76. RU Flow Diagram for Operator Station Logon........................................................................................ 571
77. RU Flow Diagram for START Hardcopy Device...................................................................................... 572
78. RU Flow Diagram for Starting a Cross-Domain Session........................................................................ 573
79. RU Flow Diagram for Starting a Cross-Domain Session to support session monitor conversations
for Continuous or Persistent Sessions.................................................................................................... 574
80. RU Flow Diagram for Operator TAF Session.......................................................................................... 575
81. Control Blocks Used during Command Facility Initialization................................................................ 576
82. Control Blocks Used during Operator Station Logon............................................................................. 577
83. Control Blocks Used during Session Monitor Initialization................................................................... 581
84. Control Blocks Used during Hardware Monitor Initialization................................................................ 587
85. Control Blocks Used during Status Monitor Initialization......................................................................589
86. Sample of a DSINDEF data set............................................................................................................... 641
xx
About this publication
The IBM Z® NetView® product provides advanced capabilities that you can use to maintain the highest
degree of availability of your complex, multi-platform, multi-vendor networks and systems from a single
point of control. This publication, the IBM Z NetView Troubleshooting Guide, provides information for use
in diagnosing and solving network problems that occur in the NetView product. This includes support for
the following functions:
• NetView program
• Graphic Monitor Facility host subsystem (GMFHS)
• NetView management console
• Resource Object Data Manager (RODM)
• Systems network architecture (SNA) topology manager
• MultiSystem Manager
• Automated Operations Network (AON)
• Event/Automation Service (E/AS)
Intended audience
This publication is for system programmers and operators who need to diagnose, document, and report
software and hardware problems.
Publications
This section lists publications in the IBM Z NetView library and related documents. It also describes how
to access NetView publications online and how to order NetView publications.
IBM Z NetView library

The following documents are available in the IBM Z NetView library:
• Administration Reference, SC27-2869, describes the NetView program definition statements required
for system administration.
• Application Programmer's Guide, SC27-2870, describes the NetView program-to-program interface
(PPI) and how to use the NetView application programming interfaces (APIs).
• Automation Guide, SC27-2846, describes how to use automated operations to improve system and
network efficiency and operator productivity.
• Command Reference Volume 1 (A-N), SC27-2847, and Command Reference Volume 2 (O-Z), SC27-2848,
describe the NetView commands, which can be used for network and system operation and in
command lists and command procedures.
• Installation: Configuring Additional Components, GC27-2851, describes how to configure NetView
functions beyond the base functions.
• Installation: Configuring the NetView Enterprise Management Agent, GC27-2853, describes how to
install and configure the IBM Z NetView Enterprise Management Agent.
• Installation: Getting Started, GI11-9443, describes how to install and configure the base NetView
program.
• Installation: Migration Guide, GC27-2854, describes the new functions that are provided by the current
release of the NetView product and the migration of the base functions from a previous release.
• IP Management, SC27-2855, describes how to use the NetView product to manage IP networks.
© Copyright IBM Corp. 1997, 2019 xxi

• Messages and Codes Volume 1 (AAU-DSI), GC27-2856, and Messages and Codes Volume 2 (DUI-IHS),
GC27-2857, describe the messages for the NetView product, the NetView abend codes, the sense
codes that are included in NetView messages, and generic alert code points.
• Programming: Pipes, SC27-2859, describes how to use the NetView pipelines to customize a NetView
installation.
• Programming: REXX and the NetView Command List Language, SC27-2861, describes how to write
command lists for the NetView product using the Restructured Extended Executor language (REXX) or
the NetView command list language.
• Security Reference, SC27-2863, describes how to implement authorization checking for the NetView
environment.
• Troubleshooting Guide, GC27-2865, provides information about documenting, diagnosing, and solving
problems that occur in the NetView product.
• Tuning Guide, SC27-2874, provides tuning information to help achieve certain performance goals for
the NetView product and the network environment.
• User's Guide: Automated Operations Network, SC27-2866, describes how to use the NetView
Automated Operations Network (AON) component, which provides event-driven network automation, to
improve system and network efficiency. It also describes how to tailor and extend the automated
operations capabilities of the AON component.
• User's Guide: NetView, SC27-2867, describes how to use the NetView product to manage complex,
multivendor networks and systems from a single point.
• User's Guide: NetView Enterprise Management Agent, SC27-2876, describes how to use the NetView
Enterprise Management Agent.
• Using Tivoli System Automation for GDPS/PPRC HyperSwap Manager with NetView, GI11-4704, provides
information about the Tivoli® System Automation for GDPS®/PPRC HyperSwap® Manager with NetView
feature, which supports the GDPS and Peer-to-Peer Remote Copy (PPRC) HyperSwap Manager services
offering.
• Licensed Program Specifications, GC31-8848, provides the license information for the NetView product.
• Program Directory for IBM Z NetView US English, GI11-9444, contains information about the material
and procedures that are associated with installing the NetView product.
• Program Directory for IBM Z NetView Japanese, GI11-9445, contains information about the material and
procedures that are associated with installing the NetView product.
• Program Directory for IBM Z NetView Enterprise Management Agent, GI11-9446, contains information
about the material and procedures that are associated with installing the IBM Z NetView Enterprise
Management Agent.
The following books are archived:
• Customization Guide, SC27-2849, describes how to customize the NetView product and points to
sources of related information.
• Data Model Reference, SC27-2850, provides information about the Graphic Monitor Facility host
subsystem (GMFHS), SNA topology manager, and MultiSystem Manager data models.
• Installation: Configuring Graphical Components, GC27-2852, describes how to install and configure the
NetView graphics components.
• Programming: Assembler, SC27-2858, describes how to write exit routines, command processors, and
subtasks for the NetView product using assembler language.
• Programming: PL/I and C, SC27-2860, describes how to write command processors and installation exit
routines for the NetView product using PL/I or C.
• Resource Object Data Manager and GMFHS Programmer's Guide, SC27-2862, describes the NetView
Resource Object Data Manager (RODM), including how to define your non-SNA network to RODM and
use RODM for network automation and for application programming.
xxii IBM Z NetView: Troubleshooting Guide

• SNA Topology Manager Implementation Guide, SC27-2864, describes planning for and implementing
the NetView SNA topology manager, which can be used to manage subarea, Advanced Peer-to-Peer
Networking, and TN3270 resources.
• User's Guide: NetView Management Console, SC27-2868, provides information about the NetView
management console interface of the NetView product.
Related publications
You can find additional product information on the IBM Z NetView web site at https://www.ibm.com/us-
en/marketplace/ibm-tivoli-netview-for-zos.
For information about the NetView Bridge function, see Tivoli NetView for OS/390® Bridge Implementation,
SC31-8238-03 (available only in the V1R4 library).
Terminology in this Library

The following terms are used in this library:
CNMCMD
For the CNMCMD member and the members that are included in it using the %INCLUDE statement
CNMSTYLE
For the CNMSTYLE member and the members that are included in it using the %INCLUDE statement
DSIOPF
For the DSIOPF member and the members that are included in it using the %INCLUDE statement
IBM® Tivoli Netcool®/OMNIbus
For either of these products:
• IBM Tivoli Netcool/OMNIbus
• IBM Tivoli OMNIbus and Network Manager
MVS™
For z/OS® operating systems
MVS element
For the base control program (BCP) element of the z/OS operating system
NetView
For the following products:
• IBM Z NetView version 6 release 3
• IBM Tivoli NetView for z/OS version 6 release 2 modification 1
• NetView releases that are no longer supported
PARMLIB
For SYS1.PARMLIB and other data sets in the concatenation sequence
VTAM®
For Communications Server - SNA Services
Unless otherwise indicated, topics to programs indicate the latest version and release of the programs. If
only a version is indicated, the topic is to all releases within that version.
When a topic is made about using a personal computer or workstation, any programmable workstation
can be used.
Using IBM Z NetView online help

The following types of IBM Z NetView mainframe online help are available, depending on your installation
and configuration:
• General help and component information
• Command help
About this publication xxiii

• Message help
• Sense code information
• Recommended actions
Accessing publications online

IBM posts publications for this and all other products, as they become available and whenever they are
updated, to the IBM Knowledge Center at https://www.ibm.com/support/knowledgecenter. You can find
IBM Z NetView documentation on IBM Z NetView Knowledge Center.
Note: If you print PDF documents on other than letter-sized paper, set the option in the Print window that
enables Adobe Reader to print letter-sized pages on your local paper.
Ordering publications
You can order many Tivoli publications online at http://www.ibm.com/e-business/linkweb/publications/
servlet/pbi.wss
You can also order by telephone by calling one of these numbers:
• In the United States: 800-426-4968
• In Canada: 800-879-2755
In other countries, contact your software account representative to order Tivoli publications. To locate
the telephone number of your local representative, perform the following steps:
1. Go to http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss.
2. Select your country from the list and click the grey arrow button beside the list.
3. Click About this site to see an information page that includes the telephone number of your local
representative.
Accessibility
Accessibility features help users with a physical disability, such as restricted mobility or limited vision, to
use software products successfully. Standard shortcut and accelerator keys are used by the product and
are documented by the operating system. Refer to the documentation provided by your operating system
for more information.
For additional information, see the Accessibility appendix in the User's Guide: NetView.
Tivoli user groups

Tivoli user groups are independent, user-run membership organizations that provide Tivoli users with
information to assist them in the implementation of Tivoli Software solutions. Through these groups,
members can share information and learn from the knowledge and experience of other Tivoli users.
Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM provides the following
ways for you to obtain the support you need:
Online
Please follow the instructions located in the support guide entry: https://www.ibm.com/support/
home/pages/support-guide/?product=4429363.
Troubleshooting information
For more information about resolving problems with the IBM Z NetView product, start with Chapter 1,
“Diagnosing problems,” on page 3. You can also discuss technical issues about the IBM Z NetView
xxiv IBM Z NetView: Troubleshooting Guide

product through the NetView user group located at https://groups.io/g/NetView. This user group is for
IBM Z NetView customers only, and registration is required. This forum is also monitored by
interested parties within IBM who answer questions and provide guidance about the NetView
product. When a problem with the code is found, you are asked to open an official case to obtain
resolution.
Conventions used in this publication

This section describes the conventions that are used in this publication.
Typeface conventions
This publication uses the following typeface conventions:
Bold
• Lowercase commands and mixed case commands that are otherwise difficult to distinguish from
surrounding text
• Interface controls (check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list
boxes, items inside list boxes, multicolumn lists, containers, menu choices, menu names, tabs,
property sheets), labels (such as Tip:, and Operating system considerations:)
• Keywords and parameters in text
Italic
• Citations (examples: titles of publications, diskettes, and CDs
• Words defined in text (example: a nonswitched line is called a point-to-point line)
• Emphasis of words and letters (words as words example: "Use the word that to introduce a
restrictive clause."; letters as letters example: "The LUN address must start with the letter L.")
• New terms in text (except in a definition list): a view is a frame in a workspace that contains data.
• Variables and values you must provide: ... where myname represents...
Monospace
• Examples and code examples
• File names, programming keywords, and other elements that are difficult to distinguish from
surrounding text
• Message text and prompts addressed to the user
• Text that the user must type
• Values for arguments or command options
Operating system-dependent variables and paths

For workstation components, this publication uses the UNIX convention for specifying environment
variables and for directory notation.
When using the Windows command line, replace $variable with %variable% for environment variables
and replace each forward slash (/) with a backslash (\) in directory paths. The names of environment
variables are not always the same in the Windows and UNIX environments. For example, %TEMP% in
Windows environments is equivalent to $TMPDIR in UNIX environments.
Note: If you are using the bash shell on a Windows system, you can use the UNIX conventions.
Syntax diagrams
The following syntax elements are shown in syntax diagrams. Read syntax diagrams from left-to-right,
top-to-bottom, following the horizontal line (the main path).
• “Symbols” on page xxvi
About this publication xxv

• “Parameters” on page xxvi
• “Punctuation and parentheses” on page xxvi
• “Abbreviations” on page xxvii
For examples of syntax, see “Syntax examples” on page xxvii.
Symbols
The following symbols are used in syntax diagrams:
Marks the beginning of the command syntax.
Marks the end of the command syntax.
Indicates that the command syntax is continued on the next line.
Indicates that a statement is continued from the previous line.

|
Marks the beginning and end of a fragment or part of the command syntax.
Parameters
The following types of parameters are used in syntax diagrams:
Required
Required parameters are shown on the main path.
Optional
Optional parameters are shown below the main path.
Default
Default parameters are shown above the main path. In parameter descriptions, default parameters
are underlined.
Syntax diagrams do not rely on highlighting, brackets, or braces. In syntax diagrams, the position of the
elements relative to the main syntax line indicates whether an element is required, optional, or the
default value.
When you issue a command, spaces are required between the parameters unless a different separator,
such as a comma, is specified in the syntax.
Parameters are classified as keywords or variables. Keywords are shown in uppercase letters. Variables,
which represent names or values that you supply, are shown in lowercase letters and are either italicized
or, in NetView help, displayed in a differentiating color.
In the following example, the USER command is a keyword, the user_id parameter is a required variable,
and the password parameter is an optional variable.
USER user_id
password
Punctuation and parentheses

You must include all punctuation that is shown in the syntax diagram, such as colons, semicolons,
commas, minus signs, and both single and double quotation marks.
When an operand can have more than one value, the values are typically enclosed in parentheses and
separated by commas. For a single value, the parentheses typically can be omitted. For more information,
see “Multiple operands or values” on page xxviii.
xxvi IBM Z NetView: Troubleshooting Guide

If a command requires positional commas to separate keywords and variables, the commas are shown
before the keywords or variables.
When examples of commands are shown, commas are also used to indicate the absence of a positional
operand. For example, the second comma indicates that an optional operand is not being used:
COMMAND_NAME opt_variable_1,,opt_variable_3
You do not need to specify the trailing positional commas. Trailing positional and non-positional commas
either are ignored or cause a command to be rejected. Restrictions for each command state whether
trailing commas cause the command to be rejected.
Abbreviations
Command and keyword abbreviations are listed in synonym tables after each command description.
Syntax examples
The following examples show the different uses of syntax elements:
• “Required syntax elements” on page xxvii
• “Optional syntax elements” on page xxvii
• “Default keywords and values” on page xxvii
• “Multiple operands or values” on page xxviii
• “Syntax that is longer than one line” on page xxviii
• “Syntax fragments” on page xxviii
Required syntax elements

Required keywords and variables are shown on the main syntax line. You must code required keywords
and variables.
REQUIRED_KEYWORD required_variable
A required choice (two or more items) is shown in a vertical stack on the main path. The items are shown
in alphanumeric order.
REQUIRED_OPERAND_OR_VALUE_1
REQUIRED_OPERAND_OR_VALUE_2
Optional syntax elements

Optional keywords and variables are shown below the main syntax line. You can choose not to code
optional keywords and variables.
OPTIONAL_OPERAND
A required choice (two or more items) is shown in a vertical stack below the main path. The items are
shown in alphanumeric order.
OPTIONAL_OPERAND_OR_VALUE_1
OPTIONAL_OPERAND_OR_VALUE_2
Default keywords and values

Default keywords and values are shown above the main syntax line in one of the following ways:
About this publication xxvii

• A default keyword is shown only above the main syntax line. You can specify this keyword or allow it to
default. The following syntax example shows the default keyword KEYWORD1 above the main syntax
line and the rest of the optional keywords below the main syntax line.
• If an operand has a default value, the operand is shown both above and below the main syntax line. A
value below the main syntax line indicates that if you specify the operand, you must also specify either
the default value or another value shown. If you do not specify the operand, the default value above the
main syntax line is used. The following syntax example shows the default values for operand OPTION=*
above and below the main syntax line.
KEYWORD1 OPTION=*
COMMAND_NAME
KEYWORD1 OPTION= *
KEYWORD2 VALUE1
KEYWORD3 VALUE2
Multiple operands or values

An arrow returning to the left above a group of operands or values indicates that more than one can be
selected or that a single one can be repeated.
KEYWORD= (
,
REPEATABLE_OPERAND_OR_VALUE_1
value_n )
Syntax that is longer than one line

If a diagram is longer than one line, each line that is to be continued ends with a single arrowhead and the
following line begins with a single arrowhead.
OPERAND1 OPERAND2 OPERAND3 OPERAND4 OPERAND5 OPERAND6
OPERAND7 OPERAND8
Syntax fragments
Some syntax diagrams contain syntax fragments, which are used for lengthy, complex, or repeated
sections of syntax. Syntax fragments follow the main diagram. Each syntax fragment name is mixed case
and is shown in the main diagram and in the heading of the fragment. The following syntax example
shows a syntax diagram with two fragments that are identified as Fragment1 and Fragment2.
COMMAND_NAME Fragment1
Fragment2
Fragment1
KEYWORD_A= valueA KEYWORD_B KEYWORD_C
Fragment2
KEYWORD_D KEYWORD_E= valueE KEYWORD_F
xxviii IBM Z NetView: Troubleshooting Guide

Part 1. Getting started with troubleshooting
© Copyright IBM Corp. 1997, 2019 1

2 IBM Z NetView: Troubleshooting Guide
Chapter 1. Diagnosing problems
To begin diagnostic procedures for problems that might occur in the NetView program or any of its
components, you must first understand the methods that can help you define and solve a problem or
document and report the problem to IBM Software Support.
Finding solutions
RETAIN database
If you have the IBM Information/Access program, you can search the RETAIN database, based on a
keyword string, to find similar problems and their solutions.
Contacting IBM Software Support

IBM Software Support provides assistance with product defects.
Before contacting IBM Software Support, your company must have an active IBM software maintenance
contract, and you must be authorized to submit problems to IBM. The type of software maintenance
contract that you need depends on the type of product you have:
• For IBM distributed software products (including, but not limited to, Tivoli, Lotus®, and Rational®
products, as well as DB2® and WebSphere® products that run on Windows or UNIX operating systems),
enroll in Passport Advantage® in one of the following ways:
Online
Go to the Passport Advantage website at http://www.ibm.com/software/howtobuy/
passportadvantage/pao_customers.htm.
By phone
For the phone number to call in your country, go to the IBM Software Support website at http://
techsupport.services.ibm.com/guides/contacts.html and click the name of your geographic region.
• For customers with Subscription and Support (S & S) contracts, go to the Software Service Request
website at https://www.ibm.com/support/servicerequest/.
• For customers with IBMLink, CATIA, Linux, System/390®, iSeries, pSeries, zSeries, and other support
agreements, go to the IBM Support Line website at http://www.ibm.com/services/us/index.wss/so/its/
a1000030/dt006.
• For IBM eServer™ software products (including, but not limited to, DB2 and WebSphere products that
run in zSeries, pSeries, and iSeries environments), you can purchase a software maintenance
agreement by working directly with an IBM marketing representative or an IBM Business Partner. For
more information about support for eServer software products, go to the IBM Technical Support
Advantage website at http://www.ibm.com/servers/eserver/techsupport.html.
If you are not sure what type of software maintenance contract you need, call 1-800-IBMSERV
(1-800-426-7378) in the United States. From other countries, go to the contacts page of the IBM
Software Support Handbook on the web at http://www.ibm.com/servers/eserver/techsupport.html and
click the name of your geographic region for phone numbers of people who provide support for your
location.
To contact IBM Software Support, follow these steps:
1. “Determining the business impact” on page 4
2. “Describing problems and gathering information” on page 4
3. “Submitting problems” on page 5

Additional support for the Z NetView product is available at http://www.ibm.com/software/tivoli/
products/netview-zos/.
Determining the business impact

When you report a problem to IBM, you are asked to supply a severity level. Therefore, you must
understand and assess the business impact of the problem you are reporting. Use the following criteria:
Severity 1
The problem has a critical business impact. You are unable to use the program, resulting in a critical
impact on operations. This condition requires an immediate solution.
Severity 2
The problem has a significant business impact. The program is usable, but it is severely limited.
Severity 3
The problem has some business impact. The program is usable, but less significant features (not
critical to operations) are unavailable.
Severity 4
The problem has minimal business impact. The problem causes little impact on operations, or a
reasonable circumvention to the problem was implemented.
Describing problems and gathering information

When describing a problem to IBM, be as specific as possible. Include all relevant background
information so that IBM Software Support specialists can help you solve the problem efficiently. To save
time, know the answers to these questions:
• What software versions were you running when the problem occurred?
• Do you have logs, traces, and messages that are related to the problem symptoms? IBM Software
Support is likely to ask for this information.
• Can you re-create the problem? If so, what steps were performed to re-create the problem?
• Did you change the system? For example, did you change the hardware, operating system, or
networking software?
• Are you currently using a workaround for the problem? If so, be prepared to explain the workaround
when you report the problem.
Working with IBM Software Support

If it is necessary to call IBM Software Support, first collect the appropriate information. See “Collecting
problem data” on page 23. When you call IBM Software Support, a dispatcher asks for customer
identification information, such as your account name, access code, and program license number. You
and the dispatcher determine the type of help that you need. The dispatcher assigns a problem number
and places your call on a queue for an IBM Software Support representative.
The representative uses the information from the worksheet to form a keyword string and search a
database containing symptoms and resolutions for problems. This database also contains information
about problems currently under investigation. The representative might ask you for additional information
to produce other keywords that can help locate and solve the problem.
If the representative finds a similar problem description in the database, a solution is probably available.
The keyword string can be varied to widen or narrow the search for similar problems.
If the search does not produce a solution, the representative verifies that you have the necessary
information to discuss the problem with a specialist. Your call is then placed in a queue accessed by IBM
Software Support specialists.
An IBM Software Support specialist helps you refine keyword strings and conducts additional searches of
the database.

An IBM Software Support representative can solve most problems, but in cases when no solution is
found, the problem is sent to an IBM Software Support specialist. If the specialist cannot find a solution,
and if the problem is a new one, the specialist can enter an authorized program analysis report (APAR)
into the RETAIN database. An APAR is a request for a correction in the program.
A number is assigned to your APAR. If you are asked to send documentation about your problem to IBM
Software Support, write this APAR number in the upper right corner of each piece of documentation.
The APAR and other types of documentation allow the program specialist to examine the problem in
greater detail and develop a solution. If this solution is a coding change, it is put into a program temporary
fix (PTF) and sent to you. All information about the solution is entered into the RETAIN database. This
procedure keeps the database current with problem descriptions and solutions and makes the
information available for future searches.
If you want information about: See:

Building a keyword string “Building a keyword string” on page 6
Submitting problems
You can submit your problem to IBM Software Support in one of two ways:
Online
Go to the IBM Software Support website at http://www.ibm.com/software/support/ and follow the
instructions.
By phone
For the phone number to call in your country, go to the contacts page of the IBM Software Support
Handbook at http://techsupport.services.ibm.com/guides/handbook.html and click the name of your
geographic region.
If the problem you submit is for a software defect or for missing or inaccurate documentation, IBM
Software Support creates an Authorized Program Analysis Report (APAR). The APAR describes the
problem in detail. Whenever possible, IBM Software Support provides a workaround that you can
implement until the APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the
Software Support website daily, so that other users who experience the same problem can benefit from
the same resolution.
Using keywords
Each problem type has an associated keyword. The keyword is used as a general identifier and to search
the RETAIN database. If you have access to the RETAIN database, you can search it. Otherwise, you can
provide IBM Software Support with the keyword and they do the search. In searching the RETAIN
database, you can determine whether:
• Your particular problem has already been reported
• There is a bypass for your problem
• Your problem has been solved
• A solution exists for your problem
An accurate and precise search string produces usable results. A string search contains the following:
• The keyword that represents your problem type
• The level of the NetView product and, if applicable, the load level of the NetView management console
you are using
• Additional symptoms of the problem
If you proceed through all seven classifications and cannot match your problem to any of those problems
described, see “Documenting any problem” on page 23.
Chapter 1. Diagnosing problems 5

Building a keyword string
A keyword string is a set of descriptive words that you use to identify a problem. A keyword is a word or
abbreviation that describes one part of a program failure. These keywords can be used to search for
solutions in the RETAIN database. Use keywords in a string to completely describe the problem. A search
string can contain any keyword that represents your problem type, information about the level of the
NetView program you are using, and additional symptoms of the problem. For example, if the failure is an
abnormal end (abend) of a task, the keyword used is ABEND. Other problems have the following
keywords:
• DOC
• INCORROUT
• LOOP
• MSG
• PERFM
• WAIT
Table 1 on page 6 describes how to develop a keyword string:
Table 1. How to Develop a Keyword String

Use This Type of Example of a Keyword
Type of Keyword Description or Value Keyword to... String
Component The component Find all reported xxxxxxxxx 5697NV6
identification identification number problems with the
for the operating NetView program or one
system. The component of its components.
ID number for Z
NetView V6.3.0
operating under z/OS is
5697NV6.
Failure • ABEND Refine your search to MSGDSIxxxx, where
just that type of failure xxxx is the message
• DOC for the NetView program number (for example,
• INCORROUT or one of its 172I).
• LOOP components.
• MSG
• PERFM
• WAIT
Symptom Details about the failure. Refine your search BNJyyyyy identifies the
gradually (combining the name of the NetView
symptom keywords in module that issued the
various ways) so that abend.
you receive all problem
descriptions that might
match your problem.
Dependency Program or device- Help reduce the number APPN
dependent keywords of problem descriptions
that define the you must examine.
environment in which
the problem occurred.

For example, if there is an abend in a DSI NetView module, enter the following keyword string:
5697NV6 ABENDnnn DSIyyyyy
Where:
5697NV6
Component ID for the program
ABEND
Type of problem
nnn
Abend code number
DSIyyyyy
NetView module that issued the abend failure message.
Obtaining fixes
A product fix might be available to resolve your problem. To determine what fixes are available for your
IBM software product, follow these steps:
1. Go to the IBM Software Support website at http://www.ibm.com/software/support/.
2. Under Find product support, click All IBM software (A–Z). This opens a software product list.
3. In the software product list, click IBM Z NetView. This opens the IBM Z NetView support site.
4. Under Solve a problem, click APARs to go to a list of fixes, fix packs, and other service updates for
IBM Z NetView.
5. Click the name of a fix to read the description and optionally download the fix. You can also search for
a specific fix; for tips on refining your search, click Search tips.
For more information about the types of fixes that are available, see the IBM Software Support Handbook
at http://techsupport.services.ibm.com/guides/handbook.html.
Additional support information
Receiving weekly support updates

To receive weekly email notifications about fixes and other software support news, follow these steps:
1. Go to the IBM Software Support website at http://www.ibm.com/software/support/.
2. Click My support in the upper-right corner of the page under Personalized support.
3. If you have already registered for My support, sign in and skip to the next step. If you have not
registered, click register now. Complete the registration form using your email address as your IBM
ID and click Submit.
4. Click Edit profile.
5. In the Products list, select Software. A second list is displayed.
6. In the second list, select a product segment, for example, Systems Management. A third list is
displayed.
7. In the third list, select a product sub-segment, for example, Network Management & Performance.
A list of applicable products is displayed.
8. Select one or more products for which you want to receive updates, for example, IBM Z NetView.
9. Click Add products.
10. After selecting all products that are of interest to you, click Subscribe to email on the Edit profile
tab.
11. Select Please send these documents by weekly email.

12. Update your email address as needed.
13. In the Documents list, select Software.
14. Select the types of documents that you want to receive information about.
15. Click Update.
If you experience problems with the My support feature, you can obtain help in one of the following ways:
Online
Send an email message to erchelp@ca.ibm.com, describing your problem.
By phone
Call 1-800-IBM-4You (1-800-426-4968).
Exchanging information with IBM Z NetView Support

To reduce the time that it takes to resolve your problem, you can send trace and diagnostic information to
IBM Z NetView Support. To submit diagnostic information to IBM Z NetView Support, follow these steps:
1. Open a problem management record (PMR). You can use the IBM Support Assistant, located at http://
www.ibm.com/software/support/isa/ or the Service Request tool, located at http://www.ibm.com/
support/servicerequest.
2. Collect the diagnostic data that you need. Diagnostic data helps reduce the time that it takes to resolve
your PMR. You can collect the diagnostic data automatically or manually. To collect the diagnostic data
automatically, you can use the IBM Support Assistant.
3. Compress the files by using the ZIP or TAR format.
4. Transfer the files to IBM Z NetView Support. Various methodologies for doing any sort of transfer are
explained at http://www.ibm.com/software/support/exchangeinfo.html. All of these data exchange
methods are explained on the IBM Support website, located at http://www.ibm.com/software/
support/.
Receiving information from Z NetView Support

In order to resolve a problem, a Z NetView technical support representative might ask you to download
diagnostic tools or other files. You can use FTP to download these files.
Before you begin

Ensure that your Z NetView technical-support representative provided you with the preferred server to
use for downloading the files and the exact directory and file names to access.
Procedure
To download files from Z NetView Support:
• Use FTP to connect to the site that your Z NetView technical-support representative provided and log in
as anonymous.
• Use your email address as the password.
• Change to the appropriate directory:
cd fromibm
• Change to the directory that your Z NetView technical-support representative provided.
cd nameofdirectory
• Enable binary mode for your session.
binary

• Use the get command to download the file that your Z NetView technical-support representative
specified
get filename.extension
• End your FTP session.
Subscribing to IBM Z NetView support updates

To stay informed of important information about the IBM Z NetView products that you use, you can
subscribe to updates. By subscribing to receive updates, you can receive important technical information
and updates for specific IBM Z NetView support tools and resources.
For general information about RSS, including steps for getting started and a list of RSS-enabled IBM web
pages, visit http://www.ibm.com/software/support/rss/.
My Notifications
With My Notifications, you can subscribe to Support updates for any IBM product. You can specify that
you want to receive daily or weekly email announcements. You can specify what type of information you
want to receive (such as publications, hints and tips, product flashes (also known as alerts), downloads,
and drivers. My Notifications enables you to customize and categorize the products about which you want
to be informed and the delivery methods that best suit your needs.
Procedure
To subscribe to Support updates:
1. Subscribe to the IBM Z NetView feed located at http://www.ibm.com/software/tivoli/products/
netview-zos/, which enables you to stay informed of regular updates to the information. To set up
your RSS feed, go to link to information center RSS feed setup page.
2. To subscribe to My Notifications, begin by going to the IBM Support Portal at http://www.ibm.com/
software/support/ and clicking My Notifications in the Notifications portlet. If you have already
registered for My support, sign in and skip to the next step. If you have not registered, click Register
now. Complete the registration form using your email address as your IBM ID and click Submit.
3. Click Edit profile.
4. Click Add products and choose a product category; for example, Software. A second list is displayed.
5. In the second list, select a product segment; for example, Data & Information Management. A third
list is displayed.
6. In the third list, select a product sub-segment, for example, Databases. A list of applicable products
is displayed.
7. Select a product (for example, IBM Z NetView) for which you want to receive updates.
8. Click Add products.
9. After selecting all products that are of interest to you, click Subscribe to email on the Edit profile tab.
10. Select Please send these documents by weekly email.
11. Update your email address as needed.
12. In the Documents list, select the product category; for example, Software.
13. Select the types of documents for which you want to receive information.
14. Click Update.
Results
Until you modify your RSS feeds and My Notifications preferences, you receive notifications of updates
that you have requested. You can modify your preferences when needed (for example, if you stop using
one product and begin using another product).

Following the diagnostic path
Figure 1 on page 11 illustrates the flow of work when you are classifying, gathering information, and
solving problems. Take the following diagnostic path to simplify the task of solving program problems.

Figure 1. The Diagnostic Path for Classifying, Documenting, and Reporting Problems

Chapter 2. Classifying problems
When a problem occurs in a NetView component, look at the symptoms described in this chapter to
decide which type of problem has occurred. The symptoms for each of seven problem types have a name
that is synonymous with its keyword. Keywords are described in Chapter 1, “Diagnosing problems,” on
page 3.
When you decide what the problem keyword is, you can use it to develop a keyword string. See Chapter 1,
“Diagnosing problems,” on page 3 for information about the keyword string.
In the following topics, the symptoms are described for ABEND, DOC, INCORROUT, LOOP, MSG, PERFM,
and WAIT problems.
Identifying symptoms
The symptoms described in this section can apply to any NetView component.
Note: For problem determination, keep the internal NetView trace active or use the default size of 4000.
ABEND
The ABEND symptoms apply to the NetView program, GMFHS, RODM, SNA topology manager, and Event/
Automation Service (E/AS).
If, after reading about abends, you categorize your problem as an abend, see “Documenting ABEND
problems” on page 27.
NetView program
Choose the ABEND keyword when one or more of the following symptoms occur:
• An MVS ABEND message is displayed at the system operator console. The message that contains the
abend code is found in the system console log.
• The DSI172I message is displayed.
Abend problems are classified as follows:
User abend codes
NetView user abend codes originate in the NetView program. Some abend failures can be caused by
incorrect job control language (JCL) or definition statements, such as references to an incorrect
library. An abend problem can also result from a VSAM or VTAM error. Check allocation of VSAM or
VTAM parameters in this case. Some NetView user abend codes result from commands in which the
abend is an intended form of error recovery.
System abend codes
System abend codes result from such actions as issuing a system supervisor call instruction (SVC) in a
program with an incorrect event control block (ECB) address.
Program check abend problems are hardware-detected error conditions, such as a branch or store to
an address that is incorrect, or an attempt to run an instruction that is incorrect (ABENDS0C4 or
ABENDS0C1).
For information about: Refer to:

NetView user abend codes Online help facility (type HELP ABEND and use the
scroll function to locate the abend code).
MVS system abend codes MVS System Codes, SA38-0665

GMFHS
For GMFHS, choose the ABEND keyword when the following messages are written to the system console:
GMFHS IS DUMPING FOR TASK taskname, COMPLETION CODE = completioncode

GMFHS SDUMP FOR TASK taskname COMPLETED, RETURN CODE = returncode,
REASON CODE =reasoncode
where
taskname
Name of the GMFHS task that caused the abend
completioncode
Abend completion code
returncode
SDUMP return code
reasoncode
SDUMP reason code
Additional diagnostic information, including the function traceback is available in the GMFHS job output
under the CEEDUMP data set.
RODM
If RODM, one of its components, or an application fails, RODM writes a return code and reason code to the
RODM log. The return code and reason code might also be returned to your application. You might not see
an external symptom of the failure (unless the return code with reason code is returned to the application
to signal the failure).
For RODM, choose the ABEND keyword when one or more of the following symptoms occur:
• An MVS ABEND message for the RODM address space is displayed at the system operator console.
• One of the following RODM messages is received:
– EKG5010E
– EKG1981E
– EKG1982E
– EKG1983E
– EKG1984I
– EKG1985I
– EKG1986I
– EKG1987E
– EKG1988E
– EKG1989E
– EKG1996E
• The user application receives a return code of 12 and a reason code of either 20 or 194.
• The RODM log contains a type 7 log record.
For information about: See:

RODM return code and reason code combinations Chapter 18, “Troubleshooting and initial diagnosis
for RODM,” on page 245
The contents of the RODM log Chapter 19, “Diagnostic tools for the Resource
Object Data Manager (RODM),” on page 261

SNA Topology Manager
Choose the ABEND keyword for the following symptom for SNA topology manager:
• An MVS abend message is displayed at the system operator console or NetView issues the DSI819I
message. The message that contains the abend code is found in the system console log.
The following is an example of the abend message that is generated if the SNA topology manager abends:
DSI819I NETVIEW IS DUMPING FOR TASK FLBTOPO.

COMPLETION CODE= X'hhhhhh', DOMAIN=domainid.
For information about: See:

Abend codes Online help facility (type HELP ABEND and use the
scroll function to locate the abend code).
Troubleshooting scenarios “Abend during initialization” on page 331 and
“Abend after initialization” on page 332.
Use the diagnosis procedures described in the z/OS
Communications Server library to gather
information about problems with VTAM CMIP
services.
DOC
Choose the DOC keyword when one or more of the following symptoms is true for the documentation or
online help panels:
• They contain incomplete or inaccurate information about installation, operation, customization,
messages, or diagnosis.
• They are inconsistent in describing the use of a program function.
Report these problems to IBM Software Support only if the documentation problem affects the operation
or use of the NetView program.
If you have categorized your problem as a documentation problem, see “Documenting DOC problems” on
page 33.
INCORROUT
Choose the INCORROUT keyword when you receive one of the following symptoms:
• You receive unexpected output such as a garbled message, and the problem does not seem to be a
loop.
• When displaying the view, the resource information contains strange or garbled characters.
• The view displayed does not show a resource that is part of your network.
• The view displayed does not show the expected relationships between resources.
• The view displayed does not show the expected status of resources.
• Incorrect data is written to the NetView database, RODM checkpoint data sets, the RODM log, or the
RODM job input.
• You issue a NetView command and receive unexpected results.
• The data received by your RODM application is not what you expect.
• You receive a reason code that is not expected.
If you suspect that the SNA topology manager component is producing incorrect output, verify that all
required functions are working. For example, if the status of an object is not being updated, verify that the
following items are true:
• NetView management console is active and communicating with your mainframe server system.
Chapter 2. Classifying problems 15

• GMFHS is active and processing data in the RODM data cache.
• RODM is active and processing requests.
• The SNA topology manager is active, storing any received information in the RODM data cache, and
monitoring the required agent nodes.
• The agent nodes are sending the correct SNA topology information.
If you have categorized your problem as an incorrect output problem, see “Documenting INCORROUT
problems” on page 34.

The reason codes that RODM sends in response to IBM Z NetView Resource Object Data Manager and
a particular RODM function request GMFHS Programmer's Guide
The contents of the NetView management console IBM Z NetView User's Guide: NetView Management
views created by the SNA topology manager Console
The contents of the objects created in the RODM IBM Z NetView Data Model Reference
data cache by the SNA topology manager
Troubleshooting scenarios Chapter 21, “Troubleshooting and initial diagnosis
for the SNA Topology Manager,” on page 323.
Use the diagnosis procedures described in the z/OS
Communications Server library to gather
information about problems with VTAM CMIP
services.
LOOP
Choose the LOOP keyword when one or more of the following symptoms occur:
• Part of the program repeats itself as seen in a system or NetView trace. A repeating program is
indicated when the same message or set of messages is being repeatedly displayed or logged.
• The same message or set of messages is being repeatedly displayed on the workstation.
• A command has not completed after the expected time period, and the processor is used more
frequently than usual.
• There is high processor use, console (operator terminal) lockout, or high channel activity to a NetView
database.
• System commands are not accepted after issuing a RODM subsystem command or a NetView RODM
component command.
• The TASKUTIL, TASKMON, or TASKURPT command display shows increased processor use by a
particular NetView task that cannot be explained.
• The CMDMON DISPLAY command shows increased processor use by a particular NetView command or
set of commands that cannot be explained.
Loops have two forms:
Enabled loop
A loop is enabled if system commands can be run and responses are returned to the console.
Disabled loop
Disabled loop symptoms are similar to symptoms of an enabled loop, but system commands are not
accepted. You cannot interrupt the system from the operator console.
The SNA topology manager has a command (TOPOSNA QUERYDEF) that queries local settings and does
not require a significant amount of time to process. You can use this command to determine whether the
manager task is looping.

Note: Consider the current workload on the SNA topology manager. Sometimes, the manager must
process a large amount of incoming data; therefore, increased processor usage is not necessarily a sign of
a loop. A loop is probably occurring if the increased usage is sustained for an excessive period.
To determine if the SNA topology manager task is looping, do the following tasks:
1. Issue the TASKUTIL, TASKMON, or TASKURPT command for the SNA topology manager autotask
(FLBTOPO). If the results indicate that processor use has increased, the task might be looping.
2. Issue the TOPOSNA QUERYDEF command to determine whether the task is in an enabled loop or a
disabled loop.
3. If the response to the command is received within a short amount of time, chances are the tasks are
not looping, but are currently processing a large amount of received data.
4. If the response to the command is received, but it takes an unusually long time, the task is probably in
an enabled loop.
5. If no response is received after waiting for an unusual amount of time, the task is probably in a
disabled loop.
If you have categorized your problem as a loop problem, see “Documenting LOOP problems” on page
35.

The CMDMON, TASKUTIL, TASKMON, TASKURPT, IBM Z NetView Command Reference Volume 1 (A-N)
or TOPOSNA QUERYDEF command or NetView online help
MSG
A problem can cause a message to be displayed at the system console or at an operator terminal. Choose
the MSG keyword when one or more of the following symptoms occur:
• The message received is not the expected response or indicates an error condition.
• The message is issued with an incorrect format (misspelled words or unprintable characters in the
message), or the message is not displayed as it is documented in the NetView online help.
Use the HELP command for an online explanation of a message. For example, for more information about
RODM message EKG3100E, enter the following:
HELP EKG3100E
When you are using NetView management console and a problem originates at the mainframe server, a
message is displayed at the system console or at the workstation.
RODM messages can be issued from any of following sources:
• NetView messages issued while accessing RODM
• The RODM data cache manager
• The RODM load utility
Each source has a range of messages:
Message Range Component

DWO651 to DWO752 The NetView program when you are accessing RODM
EKG0001 to EKG7005 RODM data cache manager
EKG8001 to EKG8593 RODM load utility
FLB400 to FLB599 SNA topology manager

Message Range Component
FLB600 to FLB604 SNA topology manager issues these messages to create log entries in
the network log. See “SNA Topology Manager log record formats” on
page 376 for a description of these messages.
FLB605 to FLB619 SNA topology manager
Each message issued by the NetView program is displayed in the form xxxn…ny, where:
xxx
Is a prefix identifier, such as DSI, BNJ, AAU.
Notes:
• If the message associated with your problem does not have a prefix of AAU, AQN, BNH, BNJ, CNM,
DFI, DSI, DUI, DWO, EZL, FKV, FKX, FLB, FLC, and IHS, the problem is probably not with the
NetView program.
• IHS and EGV prefixed messages are issued from the NetView management console for
programmable workstations.
• EKG prefixed messages are from RODM.
• FLB prefixed messages are from the SNA topology manager.
n…n
Is a message number. The message number is component-unique. For informational messages
displayed at the workstation, the prefix and message number might not be displayed. However, for
Presentation Manager type messages, online help is available by pressing the F1 key.
y
Is a suffix defining the type. This suffix is not displayed for VIO pop-up messages. The types are as
follows:
I
Is an information message
A
Signals that an action must be taken
D
Signals that a decision is required immediately
W
Is a warning message
E
Indicates an error condition
S
Indicates a severe error condition
Figure 2 on page 18 is an example of a message.
Figure 2. NetView Error Message Format
Informational messages do not require user response or interaction. Decision messages require a
response from the operator for the program to continue processing. Warning messages inform you of a
possible problem. Investigate warning messages to ensure that the operation of the product is not

affected. Eventual action or error messages indicate that an error condition exists. An error message must
be corrected before the processing of operator or RODM application requests can continue.
If one of the following situations occurs, see “Documenting INCORROUT problems” on page 34:
• A message contains incorrect data.
• A message is issued under conditions that normally does not cause the message to be issued.
• The message indicates missing data.
If the message describes an abend, see “Documenting ABEND problems” on page 27.

Specific messages NetView online help
PERFM
Choose the PERFM keyword if performance is not as expected. Performance problems can occur because
one or more of the following conditions exist:
• NetView commands (including VTAM commands and system commands entered from a terminal logged
on to the NetView program) take an excessive time to complete.
• NetView performance characteristics are below expectations.
• System response is slow.
• CPU initialization is increased.
Use the TASKUTIL or TASKMON command to measure CPU utilization.
• Many status updates are being forwarded to the graphic data server.
• Resource definitions at the mainframe server or workstation, or both, are not correct.
• Communication errors exist between the mainframe server and the workstation.
• RODM API requests take an excessive amount of time or CPU resources to complete.
• Updates to the NetView external log take an excessive amount of time or CPU resources to complete.
• Updates to NetView management console views take an excessive amount of time to be displayed.
The multitasking features of the workstation operating system enable you to process many tasks at the
same time. A virtual memory management technique in the workstation operating system, called
swapping, enables more active program code and data to be stored concurrently than the amount of
memory that is physically installed on your system. The workstation operating system places inactive
portions of running programs in a swap file on a disk when a program does not fit into available memory.
If there is not enough storage available on the disk, the program that is running cannot continue.
If all available disk storage is used, the workstation cannot perform the specified request and you receive
an error message. You can receive either of the following:
• A message stating that no disk storage is available.
This message includes the cause of the error, the time the error occurred, and instructions on how to
increase your storage space.
• A message stating that a resource cannot be allocated.
This message is received when the specified maximum number of resource definitions is reached.
Determine whether the number of resource definition specifications can be increased.
The SNA topology manager at times must process a large amount of incoming data. There can be periods
of peak activity where the performance of the topology manager is degraded. This is usually a temporary
condition, depending on the frequency and amount of data being received from the agent nodes.

Performance can be adversely affected by enabling certain trace functions. Examples of these TOPOSNA
TRACE categories are:
• SIGNALS
• RODM
• RODMDUMP
If you have categorized your problem as a performance problem, see “Documenting PERFM problems” on
page 37. If the symptoms of the problem do not match this classification, proceed to the next problem
classification.

Resource definitions IBM Z NetView SNA Topology Manager
Implementation Guide
Host and workstation methods for controlling and IBM Z NetView Tuning Guide
improving the performance of NetView
management console
The TRACE, TASKUTIL, and TASKMON commands The IBM Z NetView Command Reference Volume 1
(A-N) or the NetView online help
WAIT
Use the WAIT keyword when processing stops for a NetView task with no abnormal completion (ABEND)
codes and no increased processor use. For example, use WAIT if you enter a NetView command and
receive no response, but the processor and all other jobs start and end normally.
Choose the WAIT keyword when one or more of the following symptoms occur:
• The operator cannot enter commands or communicate with the NetView program, and the system does
not seem to be in a loop. Using several TASKUTIL commands from another task should not show an
increase in the CPU time for the operator task in question.
• There is no response to commands.
• The workstation does not respond to keyboard or mouse commands, and the system does not seem to
be in a loop.
• There is no response from a graphical workstation.
• RODM has not ended abnormally.
• The SNA topology manager-related views at the graphical workstation are not receiving the expected
updates.
• There is no excessive processor use.
• The processor and all other jobs are starting and ending normally.
A message from the NetView program that indicates you are waiting for some data, such as one of the
following messages, is not necessarily evidence of a problem:
BNJ913I HARDWARE MONITOR WAITING FOR DATA,

ENTER 'NPDA END' TO CANCEL REQUEST
AAU913I SESSION MONITOR WAITING FOR DATA,

ENTER 'NLDM END' TO CANCEL REQUEST
Workstation specifics:
When there is no response from NetView management console at the workstation, the workstation
operating system might be swapping because of the increased demand on the memory resources for the
workstation operating system. This condition is indicated to you by increased disk light activity on your
system disk drive.
SNA topology manager specifics:

The SNA topology manager has a command (TOPOSNA QUERYDEF) that queries local settings, and does
not require a significant amount of time to process. You can use this command to determine whether the
manager task is suspended.
1. Issue the TASKUTIL command for the SNA topology manager autotask (FLBTOPO). If the results
indicate little or no processor usage by the task, the task might be suspended.
2. Issue the TOPOSNA QUERYDEF command to determine whether the task is suspended.
3. If the response to the command is received, the manager task is not suspended.
• If you are experiencing slow response time to local commands (such as QUERYDEF), the rest of your
system might be overloaded.
• If you are not receiving any information or responses, and it does not seem that newly issued
requests (such as TOPOSNA MONITOR requests) are being sent, one of the VTAM CMIP services
tasks might be suspended.
• If you are not receiving information or responses, but it seems that newly issued requests are being
sent, your agent nodes might have ended because of an abend or stop processing.
4. If no response is received after waiting for an unusual amount of time, the task is probably suspended.
Note: The TOPOSNA TRACE command is processed by the appropriate command processors. The SNA
topology manager task does not perform any processing related to these commands. These commands
can still be processed if the topology manager task is suspended.
If you have categorized your problem as a wait problem, see “Documenting WAIT problems” on page
38.

The TASKUTIL and TOPOSNA commands The IBM Z NetView Command Reference Volume 1
(A-N) or the NetView online help
Finding problem types

If the symptoms do not match any of the problem types described in this chapter, see Chapter 3,
“Documenting and reporting problems,” on page 23 to describe the problem.

Chapter 3. Documenting and reporting problems
IBM Software Support is the first point of contact for NetView customers who need help with a program
problem after installation is complete. Contact the local marketing systems engineer for assistance on
problems encountered during installation.
Collecting problem data

Each type of problem requires specific documentation. Although you might not know your problem type,
gather the basic information described in “Documenting any problem” on page 23 before calling IBM
Software Support.
Documenting any problem

For all problems, including those for which you cannot identify the type, you must include information for
the following items:
• The NetView component ID number, FMID, release number, and RSU level.
Record the NetView component ID number, the function modifier identification (FMID), and
maintenance level of the current service upgrade (RSU) level. The component ID number is
5697NV600.
• Recently applied NetView maintenance, such as a program temporary fix (PTF) or an authorized
program analysis report (APAR).
Record any recently applied NetView maintenance, such as PTFs or APAR fixes. Use the DISPMOD
command to obtain PTF levels online. The PTF level is in the memory dump, following the module
identifier.
To report a problem, refer to the IBM Software Support website at http://www.ibm.com/software/
support/. Click Submit/Track Problems and then follow the instructions to report the problem to
IBM Software Support.
• A scenario leading to the problem (gathered from the network log)
Research the scenario leading to the problem, including the commands entered before the problem
occurred. You can obtain this information in the network log from the operator who has the problem.
Record the commands exactly as they were entered. Consider the following items:
– What was the first indication of the problem?
– What were you trying to do?
– What should have happened?
– What actually did happen?
– Has the function worked before?
– Can you recreate the problem?
• Memory dump of NetView address space
Use one of the following commands:
– NVINFO with the DUMP keyword.
– MVS DUMP and use the JOBNAME keyword to specify the NetView job name. If NetView trace is
running internally, also specify the DSPNAME keyword using CNMTRACE as the data space name.
• The NetView trace

Unless otherwise requested, keep the internal NetView trace active at all times with SIZE=4000 or
more. If you have specified MODE=EXT, see “Description of NetView trace records (MODE=EXT)” on
page 103. If you have specified MODE=GTF, see “Generalized Trace Facility (GTF) Output Files” on page
156.
Some problems might require different trace options.
• The message log
Copy message log data as described in “Capturing Message Log Data” on page 40.
• CNMSTYLE
Use one of the following methods:
– Use the NVINFO command to save a formatted copy of the CNMSTYLE settings as well as other data
associated with the NetView program. NVINFO can also capture Canzlog data like PRINT. See the
online help of the NVINFO command for details.
– Locate and save a copy of the CNMSTYLE file (and any member that it includes) used to start the
NetView program.
• The output from the status monitor preprocessor job (if applicable)
The output from the status monitor preprocessor job contains status monitor preprocessor messages.
• The application trace log (if applicable)
Save the application trace log for traces created by the graphic service facility.
• The NetView management console IHSERROR.LOG and IHSERROR.BAK (if applicable)
The IMSERROR.LOG file resides in the path %BINDIR%/TDS/server/log. The IHSERROR.LOG is a binary
formatted file that must be reformatted before the log can be read by the IBM Software Support
representative.
• The RODM START JCL (if applicable)
Locate and save a copy of the JCL used to start RODM.
• RODM log records (if applicable)
While RODM is running:
1. Use the MODIFY command to move all the RODM log records into the log file.
2. Use the RODM log formatter to format the log file and print it.
• The customization file (EKGCUST) used to start RODM (if applicable)
Locate and save a copy of the customization file (EKGCUST) used to start RODM.
• An unformatted RODM address space memory dump (if applicable)
If your problem is related to a failure in accessing data, dump the RODM address space. Otherwise,
most RODM diagnosis is accomplished without a memory dump of the RODM address space.
• A copy of the NetView High-level Language (HLL) remote interactive debugger (RID) and first
failure data capture (FFDC) trace logs (if applicable).
– The NetView HLL API service routines maintain an eight-entry, continuously wrapping trace area.
This 48-byte area is referred to as the first failure data capture area (FFDCA). Its name is HLBFFDCA
and it is located in the DSIPHLB control block (for PL/I), and the DSICHLB control block (for C).
– You can print the contents of this trace area during job execution by including the appropriate PL/I or
C print statements in your service routines. If a failure occurs, this area identifies the server support
API module that was running at the time of the failure.
– The remote interactive debugger (RID) can be used to trace all high-level language (HLL) calls and
their results. RID can be used on any SNA topology manager task and command processor, except
for the LOGOFF command processors.
• An unformatted user address space memory dump (if applicable)

Locate and save an unformatted user address space memory dump if you are using a user-written
program that uses RODM API or a PPI task.
• The GMFHS data model and resource definition file
Locate and save a copy of the files used to load the GMFHS data model and resource definition files into
the RODM data cache. These files are not necessary if you have not modified the GMFHS data model
and you are not creating any user-defined objects in the RODM data cache. These files are documented
in the IBM Z NetView Resource Object Data Manager and GMFHS Programmer's Guide.
• The GMFHS trace print data set or GTF (if applicable)
Locate and save a copy of the GTF or the GMFHS printed trace data sets that include entries from the
time before and during the problem. These procedures are documented in Chapter 13, “Diagnostic
tools for NetView Management Console and GMFHS,” on page 215.
• VTAM or NCP traces to the agent nodes (if applicable)
Locate and save a copy of the GTF trace data set that includes the VTAM buffer trace information or NCP
line trace information captured before and during the problem. Only trace information related to the
agent nodes being used are needed. The procedures used to create this information are documented in
the z/OS Communications Server library. (These traces are needed for SNA topology manager problems
associated with VTAM CMIP services.)
• Copy of VTAM CMIP services trace information (if applicable)
Use the diagnosis procedures described in the z/OS Communications Server library to gather
information about problems with VTAM CMIP services.
The SNA topology data model and resource definition files (if applicable)
Locate and save a copy of the files used to load the SNA topology data model and resource definition
files into the RODM data cache. You do not have to provide these files if you have not modified the SNA
topology data model or the definitions of the objects created by these files.
• The initialization files used to start SNA topology manager (if applicable)
Locate and save a copy of the initialization file FLBSYSD used to start the SNA topology manager.
• The customization files used to customize SNA topology manager (if applicable)
Locate and save a copy of the following customization files containing the tables used to customize the
mapping of OSI status to display status, the solved status for resources created in RODM, and the
resources in exception views:
FLBOSIDS
OSI-Display Status
FLBSRT
Status Resolution
FLBEXV
Exception View
• Copy of TOPOSNA trace information (if applicable)
Locate and save a copy of the GTF trace data set that includes SNA topology manager trace entries from
the time before and during the problem. You probably must create the problem again to obtain this
trace information. The topology manager traces are usually not active because some of the trace
categories can significantly affect performance.
Use the TOPOSNA TRACE command to enable all trace categories; then, create the problem again.
When creating a problem again, ensure that all the information that is provided is obtained from the
same occurrence of the problem.
Note: It is difficult to create problems that depend on timing (such as trace conditions). It is also
difficult to obtain trace information for intermittent problems.
• Managing your data collection
Chapter 3. Documenting and reporting problems 25

The information you collect about a problem helps you create a keyword string. You might find it easier
to track the information you gather if you record it on one of the following worksheets:
– Chapter 4, “NetView program problem worksheet,” on page 45
– Chapter 10, “NetView Management Console problem worksheet,” on page 173
– Chapter 11, “Graphic Monitor Facility Host Subsystem problem worksheet,” on page 177
– Chapter 17, “RODM problem worksheet,” on page 239
– Chapter 20, “SNA Topology Manager problem worksheet,” on page 317
– Chapter 23, “MultiSystem Manager worksheet,” on page 433
– Chapter 25, “AON problem worksheet,” on page 447
– Chapter 27, “Event/Automation Service problem worksheet,” on page 461
– Chapter 30, “Z NetView Enterprise Management Agent worksheet,” on page 501

Trace options “Using NetView trace” on page 100
The network log “Network log with CMDMON, TASKUTIL or
TASKMON command output ” on page 96
How to use the IHSERROR.LOG file "The NetView management console
IHSERROR.LOG and IHSERROR.BAK (if
applicable)" in “Documenting any problem” on
page 23
How to obtain and format the RODM log “The RODM log” on page 261
Dumping the RODM data spaces allocated by “Dumping dataspaces allocated by RODM” on
RODM page 302
The RID function IBM Z NetView Programming: PL/I and C
The FFDCT function “First failure data capture trace” on page 150
VTAM and NCP trace information z/OS Communications Server library
The SNA topology data model IBM Z NetView Data Model Reference
The GMFHS data model IBM Z NetView Resource Object Data Manager and
GMFHS Programmer's Guide
The GMFHS trace “GMFHS Trace” on page 219
The DISPMOD, DEFAULTS, and OVERRIDE NetView online help
commands
Dumping the NetView Address Space "Dump of NetView address space" in
“Documenting any problem” on page 23 and z/OS
library
Dumping the NetView External Log z/OS library
The TOPOSNA trace command “SNA topology manager traces” on page 415
The SNA topology data model IBM Z NetView Data Model Reference
The CNMTRACE function “Using the CNMTRACE function for NetView host
components of the NetView agent function” on
page 519

Documenting ABEND problems
To obtain the information you need before reporting abend problems to IBM Software Support, gather the
information indicated in the following list:
• "Any Problem Checklist" information
All applicable information in the list under “Documenting any problem” on page 23.
• The abend code
The abend code can be located in the following places:
– In the ABEND message that is displayed at the system console or a display screen (DSI172I)
– In a message in the system or network log
• An unformatted memory dump of the abend
If a memory dump occurs, save the memory dump data set (such as SYS1.DUMP) onto a tape or
cartridge. The terms dump data set and unformatted memory dump refer to the unchanged data set of
the memory dump. The unformatted memory dump is the data required by IBM Software Support.
If there is a RODM problem and a memory dump does not occur, use MVS commands to create a
memory dump of the RODM address and a memory dump of the user application.
You can view or print the memory dump data set, without altering it, by using an interactive memory
dump viewing utility such as the Interactive Problem Control System (IPCS).
Note: You can use a formatting utility on the unformatted memory dump to create a formatted file for
printing out the memory dump. The formatted files contain printer control characters, making these
files unusable by IBM Software Support; therefore, keep a copy of the original source.
• The program status word (PSW) at the time of the abend failure
In the memory dump, find the instruction to which the address in the program status word (PSW)
points. To help you locate the PSW instruction in a memory dump, use a memory dump formatting
utility to find the work area labeled RTM2WA SUMMARY. The summary shows the completion code, the
registers at the time of the error, and the PSW.
Note: Use the VERBX CNMIPCS SUMMARY command or the IPCS STATUS command to view the
memory dump data set.
In most cases, the instruction address in the PSW points to the instruction in error. If the last word of
the PSW has the high order (far left) bit on, the address is the remaining 31 bits of that word. If the high-
order bit is off in the last word of the PSW, the address is the last 3 bytes of the word.
For system ABEND 0C4 with a reason code 10 (segment translation exceptions) or 11 (page translation
exceptions), the PSW points to the instruction that failed. After finding the PSW address in the memory
dump, record the name of the module containing the PSW address by scanning from the right margin of
the memory dump printout backward to the module name. You can then record the program temporary
fix (PTF) level and entry point of the module.
For any type of NetView problem, keep a copy of the unformatted memory dump that is used by the
IBM Software Support representative to create an authorized program analysis report (APAR). Also,
save the network log and the MVS system log to use for reference.
If the module begins with a DSI, BNJ, AAU, DUI, DWO, EKG, or CNM prefix, it is a NetView module. If the
module does not begin with one of these prefixes, the problem is probably not in the NetView program.
• The contents of the general registers at the time of the abend failure
• Information about the location of the abend
See “Dump of a NetView ABEND” on page 28. This information consists of:
– The name of the module containing the failing instruction
– The compilation date and the PTF level of the module

– If any maintenance has been applied to the module containing the failing instruction, the latest PTF
level displays just after the module name.
The offset into the module of the instruction pointed to by the PSW
Note: The procedure used to locate abend information is different for the SNA topology manager
component. This procedure is described in “Dump of an FLBTOPO ABEND” on page 32.
• The RODM applications and methods involved
A list of the RODM applications and methods involved in the failure.
Dump of a NetView ABEND

The NetView program creates a complete address-space memory dump. Use this memory dump to help
IBM Software Support diagnose your problem.
Figure 3 on page 29 is an example of a complete address-space dump showing the type of information
to record for abend failures.
All memory dumps taken by the NetView program contain a title. The title format is: xxxx ABEND IN
NETVIEW, ERRMOD=yyyy, RCYMOD=DSIMSX, DOMAIN=zzzz.
Where:
xxxx
Specifies a system or user abend code.
ERRMOD=yyyy
Specifies the name of the load module that abended.
The NetView program uses the CSVQUERY macro to try to determine the actual name of the module
where the error occurred. Failing that, it uses the program module name in the SDWA. The ERRMOD
field is blank if the SDWA is blank.
If you receive:
DUMP BY DSIMSX, NO SDWA PROVIDED
At the time the abend occurred, the NetView program did not have addressability to the SDWA. The
NetView program is unable to provide any information concerning the reason for the memory dump or
the load module that contains the error.
RCYMOD=DSIMSX
Specifies the name of the error recovery module.
DOMAIN=zzzz
Specifies the NetView domain where the abend occurred.
Figure 3 on page 29 shows a sample NetView memory dump:

1 2 3
0DAC30B8 47F0F01E 19C4E2C9 | .00..DSI |
4 5
0DAC30C0 C5D5C440 4040F2F0 F1F44BF2 F1F140E3 | END 2014.150 T |
0DAC30D0 C9E5D5E5 F6E990EC D00C18CF 47F0C034 | IVNV6Z..}....0{. |
0DAC30E0 40404040 40404040 00000000 184150D0 | ......&} |
0DAC30F0 400841B0 0008187D 1E7B4130 40045030 | ......'.#.. .&. |
0DAC3100 700058A0 405C5820 A0045020 400418D3 | .... *....&. ..L |
0DAC3110 50B040F4 1F775070 40F04070 406441A0 | &. 4..&. 0 . ... |
0DAC3120 008040A0 40669260 406941E0 001840E0 | .. . .k- ..\.. \ |
0DAC3130 406A4DE0 C3F01277 4770C21A 1F551F66 | .(\C0....B..... |
.
.
.
0DAC35F0 41000003 50001158 417040FC 5070115C | ....&..... .&..* |
0DAC3600 58A0405C 5870A004 58A07010 5870A034 | .. *............ |
6 7
0DAC3610 58F070B8 05EF19FB 4780C59A 58704050 | .0........E... & |
0DAC3620 D501700E C9924770 C59AD507 40FCC9A0 | N...Ik..E.N. .I. |
0DAC3630 4770C586 D2074114 C9A047F0 C72C41A0 | ..EfK...I..0G... |
0DAC3640 01C050A0 40F04170 00045070 40F447F0 | .{&. 0....&. 4.0 |
0DAC3650 C72C19FB 4780C652 D207410C 40FC9240 | G.....F.K... .k |
Figure 3. Sample memory dump of a NetView ABEND
Notice the following information in Figure 3 on page 29:

• The name of the module containing the failing instruction is DSIEND, which you can verify in the
following way:
1. Find the location in storage to which the PSW points.
2. Scan backward until you see a module name ( 3 ) that is followed by a date and PTF level. The PTF
level, in this case, is TIVNV63 ( 5 ).
• The date ( 4 ) is the compilation date of the module, which, in this case, is the 150th day of 2014.
• The instruction at which the PSW points ( 7 ) is X'19FB'.
• The hexadecimal offset to the instruction to which the PSW points is X'55E'.
• The module begins at location X'DAC30B8' ( 1 ).
• The module begins with instruction X'47F0F0nn' ( 2 ).
• The failing instruction, X'05EF' ( 6 ) is located just before the instruction at which the PSW points ( 7 ).
If REGF was found to contain zeros, the following example is the keyword string used to perform a
database search for this abend:
5697NV600 ABEND0C1 DSIEND
Where:
5697NV600
Specifies the NetView component ID number
ABEND
Specifies the type of problem
0C1
Specifies the abend code
DSIEND
Specifies the module containing the ABEND
If the abend is from a failure, the keyword is ABENDxxx, where xxx is the abend code in hexadecimal
(such as ABEND0C4, ABEND604 or ABEND13E).
Typical user abends are documented by ABENDUxxxx, where xxxx is the abend code in decimal. Refer to
the NetView abend codes. A NetView user abend can be caused by circumstances in the system. If you
have no information about how to recover from or prevent the abend, continue gathering documentation.

Determining which task failed
To determine the task that abended in GMFHS, look at the console log.
To determine the task where an abend occurred in the NetView program, locate the task name and
associated MVS TCB.
Notes:
• You can use the IPCS verb exit to determine the task name and associated MVS TCB. The information is
in the task vector block (TVB). Each task within the NetView program is represented by a TVB. Except
for the autotask TVBs, all TVBs are built at initialization and are in contiguous storage.
• The first TVB in the chain is pointed to by the main vector table (MVT). The MVT is the main control
block in the NetView program. You can find the MVT in the memory dump in one of the following ways:
– Use the contents directory entry (CDE) for DSIMNTEX. This CDE is under the TCB for the main task.
When looking at the formatted TCBs, the main task TCB, DSIMNT, is the TCB with the formatted CDE
for the subtask module DSIMNT. You can scan the CDE entries for DSIMNTEX.
– Use the following commands to search the memory dump for the module name DSIMTM:
- VERBX CNMIPCS IPCS 'FIND'
- VERBX CNMIPCS 'DISPMOD'
- VERBX CNMIPCS 'SUM'
The characters MVT follow the module name. The next word contains the address of the MVT.
When you have located the MVT:
1. Verify that you are at the correct MVT by looking for NV63. The word before NV63 indicates the start of
the MVT. The word begins with X'F1'.
2. Look for the TVB chain pointer at offset X'48'. The first TVB indicates the primary program operator
interface task (PPT). The TVBs are chained together at X'4'. The TVB for the main task is not part of
this chain and is pointed to by the MVT +X'1AC'. The TVB +X'C' contains the TCB address.
3. Search the TVB chain until you find the TVB containing the address of the abending TCB. This is the
task that abended. The task name is found at offset X'44' within the TVB.
You can use the VERBX CNMIPCS 'DISPLAY' or IPCS RUNCHAIN command to display and search the
TVB chain. Table 2 on page 30 shows the commonly used fields within the TVB.
Table 2. Commonly Used Fields within the TVB

Location Explanation
X'4' Pointer to the next TVB (TVBNEXT)
X'8' Address of the TIB control block (TVBTIB)
X'C' Address of the MVS TCB (TVBTCB)
X'30' 4 bytes of indicator flags with status of the task (TVBIND1, TVBIND2, TVBIND3, and
TVBIND4)
X'3C' 8 bytes for the LU name (TVBLUNAM)
X'44' 8 bytes for the task name (TVBOPID)
Out-of-storage condition leading to an ABEND

If this is the first time you have initialized the NetView program, storage might be insufficient. Use the
formulas from the IBM Z NetView Tuning Guide to ensure that storage is adequate.
Notes:
• A NetView internal trace is always necessary for these out-of-storage conditions. Run the NetView
internal trace with its default options.

• The DSI124I message indicates that the NetView program is running out of storage. You can automate
this message to create a console memory dump of the NetView program before it abends.
• The BNH160I message indicates storage loss or problems with the storage accounting in NetView
program for global storage.
• Messages in the range BNH161I—BNH163I give you warnings about storage shortages before they
occur. The DSI124I message indicates a more severe storage condition. If you see DSI124I messages,
you might be ignoring important early warning messages or have disabled storage limits using the
DEFAULTS or OVERRIDE commands. The SMF type 38 subtype 2 data can help you review the storage
history for NetView program. You can use the NetView TASKURPT sample to retrieve this data, or use
TASKURPT as a guide to writing other SMF reports.
If your system is running successfully and the NetView program begins to run out of storage, you may
receive multiple abends. Save the memory dump data set from the first abend. In the system log, look for
a message that indicates that a partial memory dump was created. If only a partial memory dump was
created, you can re-create the problem with a larger memory dump data set to get a complete memory
dump. A complete memory dump is usually required by IBM Software Support to solve short-of-storage
problems.
If your storage calculations are correct, but you still have short-of-storage problems, run the NetView
internal trace and gather the following:
• Storage calculations from IBM Z NetView Tuning Guide for your operating system.
• The network log after several TASKUTIL or TASKMON, RESOURCE, and SESSMDIS command
invocations, and optionally, at least one CMDMON DISPLAY invocation as close to the time of the
problem as possible.
• The first memory dump of the abend, or a console memory dump if you are getting messages indicating
an out-of-storage condition. Dump the entire NetView address space.
Out-of-storage memory dump:
Look for queues in an out-of-storage memory dump. Use IPCS to obtain a list of these queues:
VERBX CNMIPCS 'QUE(ALL)'
• Each task has a public and private message queue that can build up if you do not process the message
event control block (ECB). This might happen if you have AUTOWRAP turned off. You can use the IPCS
RUNCHAIN command to find out how many elements exist. The message queues point to an internal
function request (IFR) that contains a normal BUFHDR and are chained together at X'18'. To determine
how many messages are queued, run the entire chain.
The NetView program monitors the message queue, counts the number of messages, and places the
count in the public queue. You can determine the number of messages on the public queue by checking
the TVB X'CC' for 4 bytes. The TVB characters begin with X'F2'.
The operator station task (OST), NetView-to-NetView task (NNT), and the primary POI task (PPT) have
three public and three private queues, as follows:
– The normal public and private message queues are chained off the TVB, TVB X'24', and X'28'.
– The high private and public message queues are chained off the TVB, TVB X'DC', and X'D4'.
– The low private and public message queues are chained off the TVB, TVB X'D8', and X'D0'.
The optional task (OPT) has one public and one private message queue. The normal public and private
message queues are chained off the TVB, TVB X'24', and X'28'.
The data services task (DST) has one public message queue, one private message queue, and two
internal queues. The normal public and private message queues are chained off the TVB, TVB X'24', and
X'28'. For DSTs, you can check two internal queues to determine if they are backed up and possibly
using more storage. You can find the internal queues in the TID control block. The TID is pointed to by
TIB X'70' and begins with F4.

In the TID, check queues X'AF0' and X'AF8'. These two queues point to a NetView buffer that has a
BUFHDR. The chain pointer is at X'18' in the BUFHDR. These two queues represent requests to be
processed by the DST. For example, the BNJDSERV task represents hardware events to be recorded to
VSAM. The amount of storage used for these buffers is variable, but 400 bytes is the average size.
If the hardware monitor TID queues are backed up, you might receive abend 778 in VTAM because of a
shortage in CSA SP229. This happens because VTAM expands the buffers into the CSA SP229 subpool.
• Coding the RATE statement allows you to detect an excessive rate of hardware events and set a
blocking filter when the excessive rate is detected.
• In the session monitor, check a VSAM record queue to determine whether it is backed up. Find the TVB
for AAUTSKLP and the TIB pointer at X'8'. The TIB X'6C' points to the AAUTSCT control block. Scan the
AAUTSCT, looking for the name AAUTSTRR. The word that follows AAUTSTRR is the address of the
AAUTSTRR. The AAUTSTRR X'24' is a pointer to the AAUTSTAT control block. The AAUTSTAT X'84' is a
count of the number of records waiting to be written to the session monitor database. The amount of
storage used by each of these requests varies, but an average size is 400 bytes.
Dump of an FLBTOPO ABEND

Note: This section is for C modules.
The procedure used to obtain information about the location of an abend for the SNA topology manager is
different from NetView dumps described previously.
0E29E6C8 47F0F026 01C3C5C5 | .00..CEE |

0E29E6D0 00000120 00000E46 47F0F001 183F58F0 | .........00....0 |
0E29E6E0 C31C184E 05EF0000 000047F0 303A90EB | C..+.......0.... |
0E29E6F0 D00C58E0 D04C4100 E1205500 C3144720 | }..\}<......C... |
0E29E700 F01458F0 C28090F0 E0489210 E00050D0 | 0..0B..0\.k.\.&} |
0E29E710 E00418DE 05301851 58405004 58505000 | \........ &..&&. |
0E29E720 48604000 18164910 3D844720 30844170 | .- ......d...d.. |
.
.
.
1
0E29E870 D2035040 40104860 40004190 044D1969 | K.& ..- ....(.. |
0E29E880 47803278 4180044E 19684780 32784960 | .......+.......- |
0E29E890 3DBC4780 3278196B 47803278 41A005E4 | .......,.......U |
0E29E8A0 196A4780 32784180 05881968 47803278 | .........h...... |
0E29E8B0 1B88BF81 50384780 31FEBF6F 503C4780 | .h.a&......?&... |
0E29E8C0 31FE4860 60061266 478031FE 58A0C1F4 | ...--.........A4 |
.
.
.
0E2A3F80 00000000 90000000 0040001B 00139481 | ......... ....ma |
0E2A3F90 976DC393 81A2A2C9 C46DA396 6D9996A3 | p_ClassID_to_rot |
0E2A3FA0 A8405000 0064FFFF FF343825 00004007 | y &........... . |
2
0E2A3FB0 005D0000 00000000 C6D3C2E3 D9C6C540 | .)......FLBTRFE |
3
0E2A3FC0 40C3D6D4 D7C9D3C5 C440D6D5 40C1A487 | COMPILED ON Aug |
0E2A3FD0 40F1F140 F2F0F1F4 40C1E340 F1F47AF4 | 11 2014 AT 14:4 |
4
0E2A3FE0 F57AF3F4 40C6C9E7 D3C5E5C5 D37EE3C9 | 5:34 FIXLEVEL=TI |
0E2A3FF0 E5D5E5F6 E9000000 47F0F026 01C3C5C5 | VNV6Z....00..CEE |
Figure 4. Sample memory dump Data of an FLBTOPO ABEND
Using the sample memory dump data shown in Figure 4 on page 32 as an illustration, use the following
procedure to collect information for an SNA topology manager abend:
1. Locate the address of the failed instruction in the PSW.
Use the existing NetView procedures to locate the value of the PSW and the address of the instruction
that failed.
The contents of the second word of the PSW (not shown in the sample data) is X'8E29E870'. Ignoring
the high-order bit gives the address of the failed instruction: X'0E29E870' ( 1 ).
2. Find the name of the failing module.

After finding the PSW address in the memory dump, scan forward from that location until you find the
module name: FLBTRFE ( 2 ) in the right margin of the memory dump printout. You can identify it as a
module name because it has a compilation date and possibly a PTF level (COMPILED ON...).
3. Record the compilation data of the module
After recording the name of the module, you can also record the compilation data of the module:
August 11, 2014 at 2:45 p.m. ( 3 ).
4. Obtain and record the level of the module
Obtain the PTF level of the module: TIVNV6Z ( 4 ). TIVNV6Z indicates that this is the base V6R2M1
version of this module to which no PTFs have been applied.
Notes:
• Remember that character data can be split when the memory dump is printed or browsed. This is
especially important when visually searching for character data, such as COMPILED ON when trying to
locate module names. This is not a concern when using the IPCS tool (FIND command).
• If the module does not begin with an FLB prefix, the problem is probably not with the SNA topology
manager.
• The module name and other module information is at the end of the module for the SNA topology
manager.

Using IPCS and the IPCS verb exit “Interactive Problem Control System” on page 75
Generating a memory dump MVS library
Task vector blocks (TVBs) “Determining which task failed” on page 30
Coding the RATE statement IBM Z NetView Administration Reference
Reporting a problem to IBM Software Support Chapter 3, “Documenting and reporting problems,”
on page 23
Documenting DOC problems

If you have encountered a problem with NetView documentation, gather the information indicated in the
following list before calling IBM Software Support:
• The order number and revision level of the manual or the number of the online help panel
Identify the order number and revision level of the manual or the number of the online help facility
panel involved. The manual numbers display on the back cover in the form xxxx-xxxx-y, where xxxx-xxxx
is the order number and y is a 1- or 2-digit revision number. The panel number is displayed in the upper
left corner of the screen.
• The location of the error in the manual or panel
Locate the pages in the document or the panels that contain incorrect or incomplete information, and
prepare a description of the problem.
Report a documentation problem to IBM Software Support only if the problem affects the operation of
NetView, or if the problem involves online help panels.

Documenting INCORROUT problems
If your system is encountering incorrect output problems, gather the information indicated in the
• The specific output that is incorrect
Record the output that is incorrect.
• The expected output
Record how the output differs from what was expected. Answer the following questions:
– Is all or part of the output missing?
– Is the output duplicated?
– Is there more output than expected?
– Is the information inaccurate?
If you are having problems with the output from:
– NetView automation not occurring properly, see “NetView Automation not properly occurring” on
page 66.
– EP/local errors not being recorded, see “EP/Local errors not being recorded” on page 70.
– Unsolicited remote errors or distributed mainframe server errors not being recorded, see
“Unsolicited remote errors or distributed mainframe server errors not recorded” on page 71.
– Solicited remote data or distributed mainframe server data not being recorded, see “Solicited data
not recorded” on page 71.
Examine the internal trace and isolate the problem to a specific operation or module.
Sometimes incorrect output can be caused by problems in an installation exit or other customization
problems. For example, a problem in exit DSIEX04 can cause incorrect output at the network log.
If the problem is a database recording failure, a recording filter might not be set appropriately, or an
installation parameter can be causing the problem.
• A listing of the NetView automation table, the MVS message processing facility (MPF) member, and
the message revision table, if applicable
The message processing facility can filter out some messages that are routed to the NetView program.
Check the message entries in the MPF table.
If your problem is related to automation, see “NetView Automation not properly occurring” on page
66.
The message revision table can affect message text, color, route codes, descriptor codes, display, and
logging attributes for messages to be written on MVS consoles.
• A copy of the command procedure or user-written command processor
If a command might be related to the incorrect output, include a copy of the command procedure or
command processor.
• Copy of your VTAM resource definitions (if applicable)
This information is necessary for SNA topology manager VTAM CMIP services problems.
Locate and save a copy of the VTAM and NCP definitions being used when the problem occurred. Only
provide the definitions used to establish the communications path between the NetView program,
VTAM, and the agent nodes. These definitions are documented in the z/OS Communications Server
library.

• Copies of the agent node configurations (if applicable)
This information is necessary for SNA topology manager problems.
Locate and save a copy of the configuration of the agent nodes that are involved in the problem. This
information can be obtained by saving a copy of the configuration files being used by the
communications manager. In addition, the communications manager provides the DISPLAY command,
which can be used to capture the current configuration information:
DISPLAY > file.out
• Copies of the agent node topology data (if applicable)

Locate and save a copy of the configuration and topology databases of the agent nodes that are
involved in the problem. The communications manager provides the DISPLAY command, which can be
used to capture the current configuration and topology information:
DISPLAY > file.out
• Copies of related views from the NetView management console workstation (if applicable)
Capture NetView management console views that are related to the problem. Explain the information in
the view that relates to the problem.
Also include views that are incorrect, describing in detail objects that are missing or are incorrect in the
view.
Documenting LOOP problems

If your system has looping problems, gather the information and perform the diagnosis indicated in the
• The network log
Print and save a copy of the network log containing several TASKUTIL or TASKMON command outputs,
and optionally, at least one CMDMON DISPLAY invocation, for the time period preceding and during the
loop.
• The NetView trace log
If the NetView trace is not already running, use the NetView TRACE command to turn it on while the
system is still running. Code the TRACE command as follows:
'TRACE ON,MODE=INT,SIZE=4000'
After the trace has run at least one minute, request a console memory dump of the NetView address
space and the NetView internal trace address space (see “Locating the trace when MODE=INT is
specified” on page 100 for additional information about the trace records).
Check the following in the NetView trace:
– Examine the MVS trace entry types to determine whether there is a pattern. The PSW address always
points to service routine modules DSIGMN and DSIFMN because they process these requests. These
entries do not necessarily indicate a loop and do not prevent you from searching for more
information.
– After locating the loop, record some of the PSW addresses within the loop, and use the memory
dump to determine what modules and offsets are involved. If the addresses are for VSAM or VTAM
modules, you might need a map of the link pack area (LPAMAP).

– Compare the TCB address found in the MVS trace with a NetView TVB. You can do this by scanning
the TVB chain and checking the TVB X'C' for the TCB address. Use IPCS to scan the TVB chain.
– The field MVTITDSI (at offset X'AA8' in the MVT) contains the address of a control block that contains
Internal Trace Dataspace Information (ITDSI). The ITDSI contains the name, token, and ALET of the
data space, as well as the size of the starting address of the trace table in the data space. If this
address is zero (0), the NetView trace is not active or you specified something other than MODE=INT
on the TRACE command. See “NetView trace” on page 100 for a layout of the trace table header and
the entries in the trace table.
– After you determine the TVB address, you can examine the NetView trace to see the type of entries
made by the task. All NetView trace entries contain the TVB address at X'8'.
– You can use the network log to determine whether a command or command list is involved in the
loop. After you determine the task name, search the log for entries related to the task.
• The SMF Log: NetView Task Utilization Records
Print and save NetView SMF type 38 subtype 2 data. The TASKURPT sample can be used to write this
data to the NetView network log.
• Messages associated with the loop
Write down any messages that are displayed on the terminal at the time of the loop.
• A console memory dump
Obtain a memory dump to use in determining what modules are in the loop.
Use the MVS DUMP command to dump the entire NetView address space and, if you requested it, the
NetView internal trace dataspace CNMTRACE. Look for repetitive entries for NetView tasks in the trace
tables to determine what NetView modules are in the loop. NetView modules begin with the AAU, BNJ,
CNM, DSI, DUI, or DWO identifiers. If the module you locate does not begin with DSI, BNJ, AAU, DUI, or
CNM, the problem is probably not with the NetView program.
• A copy of the command list or user-written code
If a command list or user-written command processor was running at the time the loop occurred,
include a copy of the command list or command processor. Retain a copy of all applicable command
lists and command processors that were processing at the time of the loop.
• Module name, compilation date, PTF level, and offset into module of the loop (if applicable)
Use the procedure documented in “Dump of an FLBTOPO ABEND” on page 32 to locate the addresses
of the loop instruction that failed and the name of the module or modules containing the instructions.
The referenced procedure demonstrates computing the offset of a failed instruction in an SNA topology
manager module using sample memory dump data.
After collecting all of the required documentation, report the problem to IBM Software Support.

Using IPCS “Interactive Problem Control System” on page 75
The MVS DUMP command z/OS MVS library
The CMDMON, TASKUTIL, TASKMON, and TRACE IBM Z NetView Command Reference Volume 1 (A-N)
commands or NetView online help
on page 23

Documenting PERFM problems
If your system is encountering performance problems, gather the information indicated in the following
list before calling IBM Software Support:
• Local conditions, modifications, and user code
Record any modifications to your system or your network. Do you have installation exits, command lists,
or command procedures running, and does the performance degradation relate to any user-installed
code? Performance problems can be related to system and networking constraints. Your marketing
division representative can help you identify possible causes of a performance problem.
• Description of the operation attempted, the results expected, and the results received
Record the actual performance, the expected performance, and the source of information for the
expected performance. Obtain a network log showing messages without a command or command
response. If a document is the source of expected performance information, note the order number and
page number of the document.
• The size and type of operating environment, and the number of devices being monitored
Record information describing your NetView operating environment. Include the following:
– The number and type of active NetView tasks (use the NetView LIST command to obtain this
information)
– The type of operating system, access method, and other programs in your network environment
– The number of devices being monitored, if you are using the status monitor
• A listing of the NetView automation table, the MVS message processing facility (MPF), if being used
for automation, and the message revision table
• NetView SMF Type 38 Subtype 2 Resource Allocation Records
Print these records to see a performance history for tasks in the NetView program. The TASKURPT
sample can display statistics for a single task or all tasks in the NetView program. Archived SMF data
might provide information about resource usage trends leading up to a failure.
• NetView SMF Type 38 Subtype 4 Command Statistics Records
Dump these records to see a resource usage history on a time interval basis for any NetView commands
or procedures monitored by NetView Command Statistics function. Archived SMF data might provide
information about resource usage trends at command level leading up to a failure.
• Several TASKUTIL or TASKMON command outputs in a network log
If possible, supply old TASKUTIL or TASKMON command outputs for comparison.
• The output of at least one CMDMON DISPLAY command output as close to the time of the problem
as possible
• Output of the RODM cell-pool data, using the MODIFY command
Locate and save a copy of the VTAM and NCP definitions being used when the problem occurred.
Provide the definitions used to establish the communications path between the NetView program,
VTAM, and the agent nodes. These definitions are documented in the z/OS Communications Server
library.
• Copies of the agent node configurations (if applicable)

Locate and save a copy of the configuration of the agent nodes that are involved in the problem. This
information can be obtained by saving a copy of the configuration files being used by the
communications manager. In addition, the communications manager provides the DISPLAY command,
which can be used to capture the current configuration information:
DISPLAY > file.out
• The number of outstanding operations (if applicable)

Record information describing your SNA topology manager operating environment. Include the number
and type of topology monitor operations (use the TOPOSNA LISTREQS command to obtain this
information).

Performance IBM Z NetView Tuning Guide
NetView automation “NetView Automation not properly occurring” on
page 66
The output of the RODM cell-pool data, using the “Unformatted Log Record Type 8” on page 287
MODIFY command
z/OS Communications Server resource definitions z/OS Communications Server library
The CMDMON, TASKUTIL, TASKMON, LIST, and IBM Z NetView Command Reference Volume 1 (A-N)
TOPOSNA commands or NetView online help
on page 23
Documenting WAIT problems

If your system is encountering WAIT problems, gather the information indicated in the following list
before calling IBM Software Support:
• The NetView trace and the activities leading up to the wait
To identify which task is in the wait state, examine the trace record, and research the activity that took
place before the wait.
For RODM and GMFHS, also obtain the RODM log and GMFHS trace information.
• A console memory dump, to determine the name of the module and hexadecimal offset into the
module issuing the wait in the task that seems to be suspended
Obtain a console memory dump.
For RODM and GMFHS, use the MVS DUMP command to dump both the RODM and GMFHS address
spaces. The DUMP command is described in MVS library.
For the NetView program, you can dump the data using the MVS DUMP command with the CSA, NUC ,
RGN, SQA, and TRT options. Use IPCS to search the memory dump as follows:
1. Find the TVB that was having the problem.
After you locate the TVB, get the TCB address from the TVB and examine the TCB/RB structure.
Normally, the first request block is in a wait state from DSIWAIT. This is normal because NetView

tasks wait on a list of event control blocks (ECBs) until one or more ECBs are posted. The posting of
one or more ECBs signals the NetView task that there is work to process.
To determine whether a task is in a normal wait state, use the save areas to determine what called
DSIWAIT. DSIWAIT is a service routine that is started by the DSIWAT macro. For an operator task,
DSIOST is the dispatching module. This means if DSIOST called DSIWAIT, the task is in its normal
wait state waiting for work.
2. DSIWAIT is called with a four-word parameter list. The first word is the ECB address or a pointer to
the ECB list. The parameter list can be pointed to by register 1 in the current save area or register 1
in the previous save area. The previous save area is pointed to by the current save area plus 4.
Determine whether the task is waiting on only one ECB. The parameter list X'C' indicates whether
the wait is on a single ECB or a list of ECBs. If X'C' is X'80', the first word of the parameter list is
pointing to an ECB list. This can be causing the problem, because the task waits on the entire ECB
list rather than on one ECB.
3. The TIB control block contains a standard parameter list and save area. This parameter list and save
area are often used by DSIGMN and DSIFMN, and by DSIWAIT and DSIPOST.
The TIB control block is pointed to by the TVB and is built when the task is initialized. The TIB
contains a parameter list and save area for mainline processing and exit processing.
Note: This exit processing applies to an immediate request block (IRB) exit and not NetView
installation exit processing.
Examine the following parameter lists and save areas to determine the last GET, FREE, WAIT, or
POST:
TIB X'3BC'
Contains the mainline parameter list.
X'3CC'
Contains the mainline save area.
X'414'
Contains the first exit parameter list.
X'424'
Contains the first exit save area.
The save areas follow standard save area conventions. Table 3 on page 39 describes fields of
interest in the TIB.
Table 3. Fields of Interest in the TIB

Location Explanation
X'2C' Pointer to the normal CWB. The CWB contains a save area at X'4' that is for the current
command processor or the last one run (TIBNCCWB).
X'328' Pointer to a command list block (CLB) that contains the current command list name
(TIBCLBWK).
Determine the module in which the wait occurred by locating the address of the last instruction run
under the problem task. The last instruction run is WAIT SVC (0A01). If this is not true, do further
analysis to determine whether the program is in a loop or the code is running as expected.
If the module issuing the wait is DSIWAIT, you can find the issuer of the wait routine (command facility
DSIWAT macro) by finding register 13 in the current save area (the save area at the time of the SVC 1)
and backing up one save area. This save area is that of the issuer of the NetView DSIWAT macro. Record
the following:
1. The name and the compilation date of the module.
2. The hexadecimal offset into the module.

A wait state has many external symptoms, including a locked keyboard and no response to commands.
If this happens, request a console memory dump while the system is in the wait state.
Note: Request a console memory dump and not a cancel memory dump.
It is important that you request the console memory dump before issuing any commands or trying to
clear up the wait state. The memory dump indicates what the task was doing and why it is in a wait
state.
• A copy of the command procedure or user-written command processor
If a command procedure or user-written command processor was running at the time the wait
occurred, include a copy of the command procedure or command processor. Retain a copy of all
applicable command procedures and command processors that were processing at the time of the wait.
• Module name, compilation date, PTF level, and offset into module (if applicable)
Use the procedure documented in “Dump of an FLBTOPO ABEND” on page 32 to locate the address of
the instruction that failed and the name of the module containing the instruction. The referenced
procedure demonstrates computing the offset of a failed instruction in an SNA topology manager
module using sample memory dump data.
Locate and save a copy of the VTAM and NCP definitions being used when the problem occurred.
Provide the definitions used to establish the communications path between NetView, VTAM, and the
agent nodes. These definitions are documented in the z/OS Communications Server library.

The DUMP command z/OS MVS library
VTAM resource definitions z/OS Communications Server library
Capturing Message Log Data

If you have entered an NVINFO command together with a Canzlog filter specification, relevant log data is
already captured along with other important information. Otherwise, your first step is to determine a time
range when you suspect the messages relevant to your event might have been issued. Even if you know
the exact time of events, always extend the time for a few seconds before and after to capture messages
that may have clues for causes and effects.
If problem determination is not to be done on the same system where the problem has occurred, Canzlog
data can be copied to send to IBM Service or to any other z/OS system where the NetView program can
be run.
To effect such a copy, take note of the time (or time range) where you suspect the error occurred. Convert
time values to Universal Time (UT) by subtracting any adjustment for daylight saving time and also
removing the adjustment for local time zone. The result of these operations is sometimes called
Greenwich Mean Time (GMT). All references in this section to year, month, day, hour, minute, and second
use Universal Time (UT).
Do LIST STATUS=CANZLOG and look in this display for the high-level qualifier (HLQ):
* D01NV LIST STATUS=CANZLOG

' D01NV
CNM600I CANZLOG STATUS: Active
Total messages, this IPL: 3903
Average Message Rate, prior minute: 50
Buffering available for about 480 thousand messages
Max storage: 512 megabytes

Current storage: 128 megabytes
Stress level: 0
Skip level: 5
Skip gap: 1
Data available from 08/19/18 06:20:32 at HLQ=XYZ01ABC
For system ABDEF7 archiving running at subsystem ABCD
Find the file whose name (suffix to the HLQ) is NV.CANZLOG.INDEX. Always copy this file.
Further files are named after the oldest record referred to in that file. You can determine the most recent
record (for practical purposes) by looking at the name of the next sequential file of the same type.
If the incident is in the recent past (consider 800,000 messages as "recent"), then the data for the event
might not have been archived yet. You can force most of this recent data to be written earlier than normal
by issuing the CANZLOG CUE command.
Information about the data set naming convention can be found in IBM Z NetView Installation: Configuring
Additional Components in a section entitled "Defining Canzlog Archive Data Sets."
All this data can be packaged, compressed, or encrypted (or any combination of these actions) by any of
the common procedures that can be reversed when received. The recipient of the data can choose a new
HLQ, then install the data under that name, make the local (non-archiving) NetView program use the new
HLQ, and can then browse the data exactly as if it were produced locally.
In case you do not archive Canzlog data, substitute the following two steps:
• Locate and save a copy of the network log that includes entries recorded before and during the
problem. The network log is a sequential record of operator station activity, including commands
entered and messages received. For automation command execution problems, the CNM493I
parameter on the DEFAULTS or OVERRIDE command has been set to YES, so that indications of
automation are included in the network log.
• Locate and save a copy of the system log that was generated from the time before and during the error.
The system log is the data set that stores job-related information, operational data, descriptions of
unusual occurrences, commands, and messages.
Using PRINT to Capture Canzlog Data

Use the BROWSE command and specify TO and FROM times as you have determined. It is best to use the
Canzlog filter NVMVS unless you are certain that only one type of message is relevant to your problem.
Verify that the time range that you selected covers all relevant events.
You can issue the PRINT command directly from the browse panel or, independently, from anywhere
NetView regular commands are supported. Use the option DETAIL=SUPPORT on this command, unless a
strong reason exists to use another option. Be sure to specify the time range that you selected by using
FROM and TO keywords, or TO and FOR keywords. If you want to specify a different output dataset from
that is recorded by the CZ.PRINT.OUTPUT style statement, see the online help for the PRINT command.
Using NVINFO to capture Canzlog Data

Like PRINT, you can issue NVINFO commands to capture Canzlog Data. For example, issue the following
command:
NVINFO OUTDSN=hlq.mlq.NVINFO filter_spec
or if CZ.PRINT.OUTPUT is specified in CNMSTYLE, issue the following command:
NVINFO filter_spec
The Canzlog messages requested together with other information will be stored in the OUTDSN data set if
both OUTDSN and CZ.PRINT.OUTPUT in CNMSTYLE are specified. They will be stored in the data set that
is specified by CZ.PRINT.OUTPUT in CNMSTYLE when OUTDSN is not specified. See the online help for
details.

Using the Canzlog Browse Facility Remotely
It is possible to browse archived Canzlog data from a site with no access to your system. To be sure that
all relevant data is in the archive, either shut down the NetView program by using the CLOSE STOP
command or issue the CANZLOG CUE command.
Then Canzlog data can be copied for relaying to IBM Service or to any other z/OS system where the
NetView program can be run.

Part 2. Diagnosing the NetView program

Chapter 4. NetView program problem worksheet
This chapter contains the worksheet you can use to gather the information required in determining the
cause of failures within the NetView licensed program.
Not all of these questions apply to your situation, but knowing specific background information makes it
easier to report problems and find solutions.
If you need additional information, an IBM Software Support representative can assist you in gathering it.
Copying of these data sheets is permitted without payment of royalty if each reproduction is done without
alteration.
The following information is required for all problems.
General information
Record the following general information:
1. Date:
2. Problem Number:
3. Component ID:
4. Recommended service update (RSU) level:
5. Installation Option:
System-related information
Record the following system-related information:
1. Operating system and RSU level:
2. Access method and maintenance level:
3. Other products and their maintenance levels:
Installation exits and Command Lists

1. Are you running any installation exits with the NetView program? If so, which ones?
2. Can you remove or bypass the exit and re-create the problem?
3. Is there any other user-written code (command processors, command lists) running in this
environment?
4. Can you bypass these and successfully run the function you are attempting?
Problem description
Describe your problem by answering the following questions:
1. What are the symptoms of the problem?
2. What were you trying to do?
3. What should have happened?
4. What actually did happen?
5. Has the function worked before?

6. Have you made any recent changes to the system?
• Changed or added hardware
• Applied software maintenance
• Other:
7. Can you re-create the problem with the NetView trace running default options?
Problem classification
Check one of the appropriate problem categories below that matches the symptoms associated with your
problem:
Abend problems
For abends or processor exception problems, complete the following:
1. What is the abend code?
2. What processes were taking place at the time of the abend?
3. Online help facility (type HELP ABEND and use the scroll function to locate the abend code).
4. Gather the following documentation before contacting IBM Software Support:
• A copy of the network log containing the output of several TASKMON, TASKUTIL, or TASKURPT
commands. See “Network log with CMDMON, TASKUTIL or TASKMON command output ” on page
96.
• A copy of the trace log. See “NetView trace” on page 100.
• The first unformatted memory dump of the abend.
• A completed NetView problem worksheet.
5. Gather the following information from the memory dump:
a. What is the program status word (PSW) at the time of the abend?
b. In what module did the abend occur?
c. What was the module compiled?
d. What is the PTF level of the module pointed to by the abend?
e. What is the offset into the module pointed to by the PSW at the time of the abend?
f. List the registers at the time of the abend.
Message problems
For message problems, complete the following:
1. Record the message ID and any error codes displayed.
• Message ID:
• Does the message contain any return codes, feedback codes, error codes, or sense information? List
the codes or information.
2. Check the message in the NetView online help to determine user action.
3. What processes were taking place when the message occurred?
• Commands:
• Other:
4. If the message was unexpected and cannot be corrected by following the actions in the NetView
online help, gather the following documentation before calling IBM Software Support:

• A hardcopy of the network log containing the output of several TASKMON, TASKUTIL, or TASKURPT
96.
• The message ID:
• The exact text of the message on the log.
5. Did you follow the actions in the NetView online help? If so:
• What occurred?
• Is this what was expected?
• If not, what was expected?
6. Did the message text differ from what was published?
• Has local modification been made to change the message text?
• Has an update been made to the system that might have changed the message?
Loop problems
For loop problems, complete the following:
1. What events led up to the loop?
2. What data was being displayed?
3. What was the last command entered?
4. If this is an enabled loop (see “Documenting LOOP problems” on page 35), obtain the following
documentation:
• After obtaining a console memory dump, cancel the NetView program with a memory dump.
Note: If the loop is still occurring after the NetView program has been canceled, look for a problem
with a different program.
5. If this is a disabled loop (see “Documenting LOOP problems” on page 35), obtain the following
documentation:
• A document describing the scenario leading to the problem.
• A hardcopy of the system log.
commands, and optionally, at least one CMDMON DISPLAY invocation as close to the time of the
problem as possible. See “Network log with CMDMON, TASKUTIL or TASKMON command output ”
on page 96.
• A hardcopy of the trace log. See “NetView trace” on page 100.
• The addresses of instructions within the loop.
• A memory dump obtained by using the CPU RESTART function.
Note: If ABEND071 does not occur in the NetView program and normal processing resumes, this is
not a NetView problem.
6. What are the modules involved in the loop?
7. What are the dates that the modules were compiled?
8. What are the PTF levels of the modules involved in the loop?
Wait problems
For wait problems, complete the following:
1. What is the scenario leading to the problem?
Chapter 4. NetView program problem worksheet 47

4. Gather the following documentation before calling IBM Software Support:
• A copy of the system console log.
96.
• A copy of the system console memory dump.
5. What is the name of the module in which the wait occurred?
6. What is the date that the module was compiled?
7. What is the PTF level of the module involved?
8. What is the offset into the module where the wait occurred?
Incorrect output problems

For incorrect output problems, complete the following:
1. What were the events that led to the problem?
2. What data (for example, a message or display) is in error?
96.
• The NetView trace. See “NetView trace” on page 100.
• A description of the events leading to the failure.
5. How does the output differ from what is expected?
6. If expected messages do not display, have messages been filtered out:
• From the message processing facility (MPF)?
• Using the message revision table?
• Through the automation table?
• Through installation exits?
Performance problems
For performance problems, complete the following:
2. What is the actual performance?
3. What was the expected performance?
commands, and optionally, at least one CMDMON DISPLAY invocation as close to the time of the
problem as possible. See “Network log with CMDMON, TASKUTIL or TASKMON command output ”
on page 96.
• A copy of the NetView trace. See “NetView trace” on page 100.
• A dump of NetView SMF record type 38 subtype 4 across the performance issue period. See “SMF
Log Record 38 Subtype 4 command statistics data” on page 99.

• Descriptions of any modifications to your system:
• Information describing your NetView operating environment:
Documentation problems
For documentation problems, complete the following:
1. Identify the order number, revision level, and title of the manual or the number of the online help
panel involved.
2. Identify the location of the error in the manual or panel. For manuals, provide the chapter and section
name.
3. Describe the problem the error caused.
4. If the problem affects the operation or use of the NetView program, call IBM Software Support.
5. If the problem is with an online help panel, call IBM Software Support.
Chapter 4. NetView program problem worksheet 49

Chapter 5. Troubleshooting and initial diagnosis for
the NetView program
Use Table 4 on page 51 to locate examples of problems you might encounter when using the NetView
program. To use the table:
1. Locate your problem scenario using the first two columns.
2. Go to the indicated page for a description of the problem and resolution steps for correcting the
problem.
3. Follow the resolution steps to correct your problem.
If you cannot solve your problem by using the examples, follow the instructions in Chapter 2, “Classifying
problems,” on page 13 and Chapter 3, “Documenting and reporting problems,” on page 23 before
contacting IBM Software Support.
The following table indicates where to find information about a particular problem (category):
Table 4. Problem Categories and Scenarios

Problem Problem Scenario Page
Category
Abend NetView subtask ends abnormally. “NetView subtask ends abnormally”
on page 53
Abend A78 is received at task or NetView “Abend A78 received at task or
termination. NetView termination” on page 54
Abend U0258, U0268, or U0269 is received. “Abend U0258, U0268, or U0269 is
received” on page 54
Abend 301 is received. “Abend 301 is received” on page 56
Abend code (0C4 or other) or unexpected results “Abend code (0C4 or other) or
occurred during control block linearization unexpected results occurred during
processing. delinearization” on page 56
Archive The NetView program is not attempting to archive “The NetView program is not
Canzlog data. attempting to archive Canzlog data”
on page 69
A NetView operator cannot browse archived data. “A NetView operator cannot browse
archived data” on page 70
Automation NetView Automation unexpectedly driven. “NetView Automation unexpectedly
driven” on page 66
NetView Automation not driven when expected. “NetView Automation not driven when
expected” on page 67
Commands Logon/Bind problems with Command Facility. “Logon/Bind problems with Command
Facility” on page 52
RMTCMD RUNCMD command response is displayed “RMTCMD RUNCMD command
on the MVS console. response is displayed on MVS
console” on page 72
Logon Logon/Bind problems with Command Facility. “Logon/Bind problems with Command
Facility” on page 52

Table 4. Problem Categories and Scenarios (continued)
Category
Messages BNH160I-BNH163I messages. “BNH160I–BNH163I messages” on
page 57
CNM983E, CNM998E, or CNM999E message is “CNM983E, CNM998E, or CNM999E
received. message is received” on page 59
DSI124I message is received. “DSI124I message is received” on
page 59
DSI1625I message is received. “DSI625I message” on page 55
DWO049W message is received for a DSIFRE “DWO049W message is received for a
request. DSIFRE request” on page 60
DWO049W message is received for a DSIGET “DWO049W message is received for a
request. DSIGET request” on page 61
DWO090A message is received. “DWO090A message is received” on
page 63
DWO158W message is received. “DWO158W message is received” on
page 64
DWO627E message is received (MS Transport “DWO627E message is received (MS
cancels). Transport cancels)” on page 66
MS Transport MS Transport cancels (a DWO627E message is “DWO627E message is received (MS
received). Transport cancels)” on page 66
NetView NetView Automation not properly occurring. “NetView Automation not properly
Automation occurring” on page 66
Recording EP/Local errors are not being recorded. “EP/Local errors not being recorded”
on page 70
Unsolicited remote errors or distributed mainframe “Unsolicited remote errors or
server errors not recorded. distributed mainframe server errors
not recorded” on page 71
Solicited data not recorded. “Solicited data not recorded” on page
71
Unsolicited remote errors or distributed mainframe “Unsolicited remote errors or
server errors not recorded. distributed mainframe server errors
not recorded” on page 71
Security Diagnosing NetView security problems. “Diagnosing NetView security
problems” on page 73
Logon/Bind problems with Command Facility

If you cannot log on to a command facility terminal:
1. Verify whether VTAM is active.
2. Verify whether the following VTAM definitions are correct:
• LU
• Terminal

• Local statements
3. Verify whether logon mode table entries are correct:
• Do these values correspond to the correct BIND parameters for the appropriate devices?
• Have you entered all commas in multiple MODEENT cards?
4. Verify whether the operator is defined correctly. Use another operator to take the following actions:
• Use the QOS command to determine whether an operator is currently defined to the NetView
program.
• Use the LIST SECOPTS command to determine the value of the OPERSEC keyword, which indicates
the method of operator security definitions in effect.
• If necessary, redefine the operator in DSIOPF and an SAF product.
5. Verify whether no hardware problems exist with local or remote hardware.
6. Verify whether sufficient VTAM APPL statements are defined:
• Use the LIST STATUS=OPS command to determine if all VTAM APPLs are in use. Hexadecimal
notation is used.
7. Verify that the LU (terminal) is not defined in the CNMSTYLE member using the HARDCOPY statement.
Reference:

Defining the operator to the NetView program IBM Z NetView Administration Reference
The logmode table IBM Z NetView Installation: Configuring Additional
Components
The QOS, LIST, and DEFAULTS commands NetView online help
NetView subtask ends abnormally

If a NetView subtask ends abnormally, the DSI819I message or the DSI172I message is issued. These
messages contain the abend code and the name of the subtask that failed.
The DSI172I message is issued:
DSI172I SUBTASK luname/operatorid ABENDED WITH CODE X'code'
Where:
luname
Is the name of the logical unit.
operatorid
Is the operator identifier.
code
Is the code used for problem classification. The abend code has 6 alphanumeric characters, yyyzzz,
where:
yyy
Is the system completion code.
zzz
Is the application program (the NetView program and your application) completion code.
The subtask identified by luname/operatorid has ended with the indicated abend code. If the subtask is
an operator station task (OST), this message is displayed on the screen when the task is reinstated. For
any other type of task, this message is queued to the authorized receiver.
The DSI819I message is issued:
Chapter 5. Troubleshooting and initial diagnosis for the NetView program 53

DSI819I NETVIEW IS DUMPING FOR TASK task. COMPLETION CODE= X'hhhhhh'
Where:
task
Is the name of the task for which the NetView ESTAE/ESTAI exit (DSIMSX) is driven.
• For the NetView main task, it is SYSOP.
• For an operator station task (OST), it is the ID of the operator that is logged on.
• For a data services task (DST), it is the task name defined in CNMSTASK.
• For any task name that cannot be determined, UNKNOWN is used.
hhhhhh
Is the hexadecimal completion code. The first three digits are the system completion code and the
last three digits are the user completion code.
If the first three digits are non-zero, this is a system completion code. If the last three digits are non-
zero, this is a user completion code.
If both sets of three digits are non-zero, it usually means that a subtask module ended and passed
trash in register 15.
An abend occurred. The NetView ESTAE/ESTAI exit gets control and performs a supervisor call (SVC)
dump. The routing code for this message is 2 (master console information), 10 (system error/
maintenance), or 11 (programmer information).
1. Save the memory dump data set.
2. See “Documenting ABEND problems” on page 27.
Abend A78 received at task or NetView termination

If you receive system abend A78 at task termination, code running under that task might have initiated a
DSIGET with the Q=YES keyword specified and freed the storage with DSIFRE Q=NO.
To determine if this coding error occurred, use the diagnostic aids described for return code 20 in the
documentation for the DSIFRE macro.

The DSIFRE macro IBM Z NetView Programming: Assembler
Abend U0258, U0268, or U0269 is received

If there is an interface problem between the NetView and VTAM programs, you receive abend code
U0258 (X'102'), U0268 (X'10C'), or U0269 (X'10D'). Use the following information to solve the problem
(which can be a VTAM definition or an installation problem) before pursuing the problem with IBM
Software Support.
Each time a command facility subtask issues a VTAM request parameter list-based macro and an error
occurs, the NetView program enters the command facility or terminal access facility (TAF) SYNAD/LERAD
exit routine. In a TAF environment, if the request parameter list (RPL) is valid, register 10 contains the
address of the RPL. In a non-TAF environment, if the RPL is valid, register 3 contains the address. VTAM
passes major and minor return codes to SYNAD/LERAD in register 0. If VTAM receives an RPL that is not
valid (return code = X'18'), the subtask abends. The termination code in a non-TAF environment is abend
code U0258 (X'102'). The termination code in a TAF environment is U0269 (X'10D').
VTAM passes a return code (register 0=X'102') indicating that the RPL is not valid for one of the following
reasons:
• The RPL is already in use.

• A check is issued before the RPL exit routine is scheduled.
• The RPL has been overlaid.
DSI625I message
The DSI625I message is not issued when the RPL is not valid because the contents of the RPL are not
reliable or do not pertain to the request causing the abend.
At the time of the abend, register 0 does not contain the return code passed to DSISYN or DSISYNX
because register 0 is used as an abend work register.
In either a TAF or non-TAF environment, if a valid RPL is received (register 0 is not X'018') and a should-
not-occur (SNO) logic error is encountered, you receive abend U0269 or abend U0258, and the following
message:
DSI625I UNEXPECTED SYNAD OR LERAD ERROR FOR

taskid(sourcelu), macroname FAILED
RTNCD = X'code' FDBK2 = X'code'
SYSTEM/USER SENSE = X'code'
SNOCODE = snocode
Figure 5. Example of the DSI625I message
Where:
taskid
Specifies the ID of the task issuing the macro
sourcelu
Specifies the LU issuing the macro
macroname
Specifies the name of the macro
snocode
Specifies the should-not-occur code
Return Codes for U0258 and U0269 abend codes

In Table 5 on page 55, the return codes are found in the DSI625I message for user abend U0258
(X'102') or U0269 (X'10D').
Table 5. Return Codes for User Abend U0258 (X'102') and U0269 ('10D')
Return Code Explanation
2 The request type (RPLREQ) field is outside the range expected by DSISYN, or the
macro is not issued by the command facility. Some macros have request type codes
within the numeric range of DSISYN tables, but the command facility does not use
them.
6 The communication identifier (CID) in the receive-any RPL does not match any CID in
RPLs pointed to by DSINAT. The command facility does not recognize the session.
7 A CID that is not valid was passed to or received from VTAM (no abend occurs in the
TAF environment).
In a non-TAF environment, if a valid RPL is received and an SNO physical error is encountered, no memory
dump occurs, but you receive user abend U0268 (X'10C') and the DSI625I message.
Return Codes for U0268 abend code

In Table 6 on page 56, the return codes are found in the DSI625I message for user abend U0268
(X'10C').

Table 6. Return Codes for User Abend U0268 (X'10C')
Return Code Explanation
3 The VTAM return codes in RPLRTNCD and RPLFDB2 fields are not in DSISYN tables.
4 A sense value is indicated in DSISYN return code tables, but a match is not found in
DSISYN SNA sense table.
5 No match is found for user sense in DSISYN user or BSC sense table.
8 An operation check on a remote BSC device has occurred. The operation has been retried
six times.
9 Both the SNA and BSC sense values are zero (0); the device is not a local 3270. This
sense value is valid only for local 3270s.
Any error messages and applicable return codes that are issued are listed in the network log. In the
NetView memory dump, register 13 points to the save area of the module that issued the RPL CHECK
macro before the abend occurred. In the memory dump, use register 14 from the save area to find the
module that called module DSISYN or DSISYNX.

Messages issued by the NetView program NetView online help
Abend 301 is received

You receive abend 301 because of a double-wait error. Double-wait errors occur if O SECSTAT is not
coded in DSICNM and two NetView programs are running under one VTAM.

Coding the O SECSTAT statement IBM Z NetView Administration Reference
Abend code (0C4 or other) or unexpected results occurred during

delinearization
When multiple NetView buffers need to be transferred to a destination together, such as in RMTCMD
processing, the NetView program combines buffers and related structures (linearization) and splits them
into their constituent parts (delinearization). The DSIADLIN module performs delinearization. If the
DSIADLIN module detects inconsistencies in the linearized data, it issues the following message and
creates a dump of the NetView address space that you can use in diagnosing the problem:
DWO050E FOR PROBLEM DEBUG: COMPONENT: RMTCMD MODULE: DSIADLIN

RC: 4 Badly formatted UADSB vectors
This type of problem might be caused by the transmission of the buffer across the network, such as in
RMTCMD processing. To diagnose transmission problems if you use LU 6.2 sessions, consult with the
VTAM support group to determine what documentation to gather, such as buffer traces and a VTAM
internal trace. To diagnose transmission problems if you use TCP/IP sessions, consult with the TCP/IP
support group to determine what documentation to gather, such as an IP packet trace and a SYSTCPIP
component trace.
Note: The task under which DSIADLIN is running when it dumps storage (for RMTCMD, this is the
DSIUDST task) suppresses the creation of dumps for subsequent errors detected by DSIADLIN while the
task is active. Thus, to create another dump for this type of problem, restart the task.

BNH160I–BNH163I messages
BNH160I–BNH163I messages indicate storage loss or problems with the storage accounting in the
NetView program for global storage. The IBM Software Support specialist might suggest using the
following diagnostic command DSIDIAGG to monitor and report storage discrepancies:
DSIDIAGG
DSIDIAGG STORAGE ON *
OFF task/LU name/opid
Where:
STORAGE
Required keyword that starts or stops a diagnostic storage accounting mechanism for all tasks or the
tasks whose names match the task name, LU name, or opid pattern.
ON
Turns on the specified accounting.
OFF
Turns off the specified accounting.
*
Enables or disables the accounting for all tasks.
task/LU or name/opid
Identifier of up to 8 characters which can include "?" or "*" wildcard characters.
Note:
1. Using an asterisk (*) or other general task name patterns causes higher than normal CPU utilization.
Use these only when the severity of the problem requires them.
2. Commands are cumulative, and more than one pattern can be used by using the command over to
add more patterns.
3. DSIDIAGG STORAGE with no other operands causes the active settings to be displayed.
4. If you want to diagnose a BNH160I message condition, enter a DSIDIAGG command using the LU
name, task ID, or operator ID for the task named in the BNH160I message. Then, start the task and
rerun the scenario that causes BNH160I. BNH160I contains additional data about the storage in
question. The DSIFRE service also issues diagnostic messages if discrepancies are found in the use
of DSIGET and DSIFRE for the specified task.
5. When BNH160I messages are being diagnosed, it is best to issue the DSIDIAGG command to set ON
each task indicated by a BNH160I message. This command provides information about which
program issued DSIGET and which program issued DSIFRE.
6. Diagnostics are issued by DSIFRE using the message IDs TRACEFMN, TRACEGMN, and TRACEDIA.
7. While a task is running, you can use the RID stop command to stop a task during a storage
discrepancy. The RID stop command is shown here:
RID TASK=opid,ID=DSIGMN
RID stop provides additional information and stops a task during various DSIGET and DSIFRE
discrepancies. If it does not stop, information is written to the log and the operator. These
diagnostics are useful for testing new applications running on the NetView program.
8. DSIDIAGG STORAGE OFF * removes the diagnostic command, and eliminates the diagnostic CPU
utilization.
9. Take note of the additional data produced by the BNH160I messages produced when a task ends,
and any TRACEFMN data. IBM Software Support might ask you to send a NetView log containing the
data if the modules seem to be Tivoli programs.

10. The DSIDIAGG command uses message DSI633I to indicate that the command was processed.
Numeric return codes are used to indicate problems with the operands. To display the return codes,
use PIPE NETV MOE DSIDIAGG STORAGE ON/OFF luname | CONS. The return code has the
following values:
Return Code
Meaning
100
Too few operands
104
Command name (token 1) too long
108
Fourth operand missing
112
Second operand length error
116
Second operand name error
120
Third operand length error
124
Third operand name error
128
Fourth operand length error
200
No working storage for tables left
BNH161I
This message is issued when a task exceeds criteria based on the DEFAULTS or OVERRIDE command
settings. You can review the cause of BNH161I messages and take the following actions:
• Add automation to suppress the BNH161I messages that are a result of limits you want to enforce.
• Add automation to take corrective action in the event of excessive CPU, storage, or other excessive
activity.
BNH162I
This message indicates that the NetView region below the 16 MB line is depleted. This can be caused by
the following situations:
• Starting the NetView program with a region that is too small. MVS starts using storage below the 16 MB
line after the above 16 MB area is depleted.
• Problems in programs using below-the-line storage. Use the TASKMON command to review task
storage use.
BNH163I
This message indicates that the NetView region above the 16 MB line is depleted. This can mean that the
region is too small for the workload, or a task is looping or has other storage management problems. Use
the TASKMON and TASKURPT commands to review the storage usage. Consider increasing the NetView
region size the next time the NetView program is started. Use the OVERRIDE command to set limits for
the storage a task uses if a loop is suspected.

CNM983E, CNM998E, or CNM999E message is received
If an abend occurs while you are using a high-level language (HLL), a CNM983E, CNM998E, or CNM999E
message is issued.
1. See “First failure data capture trace” on page 150 to gather first failure data capture (FFDC)
information.
2. To re-create the abend, use the remote interactive debugger (RID) function.
3. The HLL API also provides a 48-byte user trace area called HLBFFDCA. This user trace area is provided
for recording diagnosis information at key points in your code. Declare an overlay structure to format
HLBFFDCA according to the type of debugging information you must record.
4. After an abend of an operator station task (OST), NetView-NetView task (NNT), or primary program
operator interface task (PPT) command processor, you receive NetView CNM998E, CNM983E, and
CNM999E message. The user trace area and HLL trace area are displayed at the NetView operator
console and recorded in the network log (NETLOG), using the CNM998E, CNM983E, and CNM999E
message. The CNM998E message provides the name and the entry point address of the HLL command
processor in control at the time of the abend. The CNM983E message dumps the user trace area. The
CNM999E message dumps the NetView HLL trace area.

Gathering first failure data capture information “First failure data capture trace” on page 150
The RID function IBM Z NetView Programming: PL/I and C
The HLL API trace area output See Figure 34 on page 150
DSI124I message is received

The DSI124I message indicates that the NetView program is running out of storage. You can automate
this message to perform a console memory dump of the NetView program before the ABEND.
1. Monitor storage using the following NetView commands:
• CMDMON
• RESOURCE
• SESSMDIS
• TASKMON
• TASKUTIL
2. If the NetView program detects a GETMAIN failure, the DSI124I message is issued. If MVS detects a
problem while processing a GETMAIN request, an abend such as ABEND 878 occurs. In either
situation, a memory dump is necessary for solving the out-of-storage problem. Verify that your
memory dump data sets are large enough to hold a complete memory dump for out-of-storage
problems. Determining the memory dump data set size for NetView dumps depends on your operating
system. Also, when you dump the data, ensure that a partial memory dump message is not issued.

Automating the DSI124I message IBM Z NetView Automation Guide
Determining if your memory dump data sets are The appropriate information for your operating
large enough to hold a complete memory dump for system
out-of-storage problems
The CMDMON, RESOURCE, SESSMDIS, TASKMON, IBM Z NetView Command Reference Volume 1 (A-N)
and TASKUTIL commands or NetView online help

DWO049W message is received for a DSIFRE request
A program writes beyond the end of the storage it had obtained with a NetView DSIGET service macro.
When the program issues a DSIFRE request, message DW0049W is sent to the MVS console.
If the maximum number of memory dumps specified by the STORDUMP initialization parameter and the
DEFAULTS STORDUMP command have not been taken, the NetView program issues an MVS SDUMPX
macro to cause MVS to dump the NetView address space to a SYS1.DUMPxx data set.
If the memory dump has successfully completed, use the following resolution steps to debug the storage
overlay problem.
1. Use the IPCS dump-formatting utility to format the memory dump.
2. From the IPCS Browse Option Pointer panel or IPCS Storage panel, issue the IPCS STATUS
subcommand to verify that the Dump Title indicates the error occurred during a DSIFRE service
request. For example, enter:
IPCS STATUS
If the Dump Title indicates the error occurred during a DSIGET service request, see “DWO049W
message is received for a DSIGET request” on page 61.
3. From the IPCS Browse Option Pointer panel or IPCS Storage panel, issue the IPCS SUMMARY
subcommand to display the general purpose registers at the time the data was dumped. For example,
enter the following command:
IPCS SUMMARY REGISTERS
The SUMMARY subcommand displays the summary output panel.

4. Issue the FIND command from the summary output command line to find the registers at the time the
data was dumped in the summary output. For example, enter the following command:
FIND 0033
The FIND subcommand displays the problem request block (PRB) with WLIC field 0033. See reference
1 in Figure 6 on page 61.
The general purpose registers at the time the data was dumped are pointed to by the supervisor
request block (SVRB), the request block before the problem request block in the chain. See reference
2 in Figure 6 on page 61.
5. Use the general purpose registers pointed to by the SVRB to find the program that caused the storage
overlay. Record the contents of these registers by writing them down or printing the IPCS panel.
The following list shows the general-purpose registers that contain diagnostic information; they are
circled in Figure 6 on page 61 for easy reference:
Register 2
The return address of the program that issued the NetView DSIFRE service macro to free the
storage.
Register 3
The length of the storage specified on the DSIFRE macro.
Register 4
The address of the storage being freed by the NetView DSIFRE service macro.
Register 5
A pointer to the return address of the program that issued the NetView service macro DSIGET to
get the storage.
This return address might be incorrect if the program overlaid more than 4 bytes of storage. In this
case, use the NetView internal trace entry for this storage address and find the return address
after the DSIGET call.

If the program did not issue a DSIGET macro, it might have called a common service routine that
called DSIGET on behalf of the program.
Register 7
The return code from the DSIFRE macro, reported as an odd number less than 100. This return
code is also put into the return code field of the DSIFRE trace record to identify the trace request
that failed.
Register 8
The address of the task vector block (TVB) of the program that issued the NetView DSIFRE service
macro to free the storage.
Figure 6. Diagnosing a Storage Overlay Problem Using IPCS

6. From the IPCS Browse Option Pointer panel, select the pointer to see the IPCS Storage Panel.
Locate the program that issued the NetView service macro DSIGET and DSIFRE.
• If the program that issued the NetView DSIGET/DSIFRE service macro is a NetView module, contact
IBM Software Support.
• If the program that issued the NetView DSIGET/DSIFRE service macro is not a NetView module, try
to determine why the storage freed by the DSIFRE macro has overlaid the storage. To do this, look at
the program that issued the DSIGET and DSIFRE macro, the length of the storage, and the storage
address.

The DEFAULTS STORDUMP command NetView online help
DWO049W message is received for a DSIGET request

You receive the DWO049W message (without a DWO115W message) when a program attempts to get
storage using the NetView DSIGET service macro, and the NetView program detects one of the following
situations:
• The storage pooling structures in memory are damaged.
• NetView internal storage maps are inconsistent.
• A possible storage overlay was detected while attempting to get storage.
The caller of the DSIGET macro gets a zero return code in register 15 if the NetView program can get the
storage after detecting the error. The caller gets a non-zero return code in register 15 if the NetView
program did not obtain the storage.

If the memory dump has been successfully completed, use the following resolution steps to debug the
problem.
2. From the IPCS Browse Option Pointer panel or IPCS Storage panel, issue the IPCS STATUS
subcommand to verify that the Dump Title indicates the error occurred during a DSIGET service
request. For example, enter the following command:
IPCS STATUS
3. If the Dump Title indicates the error occurred during a DSIFRE service request, see “DWO049W
message is received for a DSIFRE request” on page 60.
4. If the Dump Title indicates that the error occurred during DSIGET, perform the following steps:
a. Review the sequence of events before the failure.
b. Review the NetView log to determine the active commands and tasks.
c. Review the NetView trace data for DSIGET/DSIFRE activity that might point out the failing program.
d. Review any recently changed user-written programs for storage overlay problems. The problem
detected during DSIGET generally indicates that NetView Storage Management control blocks and
maps were overlaid. For example, a program owns an area of storage adjacent to NetView storage.
The program writes beyond the end of its storage and overlays NetView storage.
5. From the IPCS Browse Option Pointer panel or IPCS Storage panel, issue the IPCS SUMMARY
REGISTERS subcommand to display the general purpose registers at the time the data was dumped.
The SUMMARY subcommand displays the summary output panel. Capture the contents of these
registers by writing them down or by printing the IPCS panel.
The following list shows the general purpose registers containing diagnostic information for a NetView
DSIGET service macro failure:
Register 2
The return address (GPR 14) of the program that issued the NetView DSIGET service macro to get
the storage.
If the program did not issue a DSIGET macro, it might have called a common service routine that
issued a DSIGET on its behalf.
Register 3
The length of the storage requested by the DSIGET macro.
Register 4
The address of the fullword that the beginning address of the obtained storage is returned.
Register 5
Zero.
Register 7
NetView internal failure code, reported as an odd number greater than 100. This return code is
also put into the return code field of the DSIGET trace record to identify the trace request that
failed.
Register 8
The address of the task vector block (TVB) of the program that issued the NetView DSIGET service
macro to get the storage.
6. Contact IBM Software Support if the error is persistent or seems to be caused by the NetView
program.

The DEFAULTS STORDUMP command NetView online help
DWO090A message is received

When the Canzlog archive feature is enabled, an instance of the NetView program attempts to save
Canzlog data to sequential data sets, adding one or more data sets to the archive as needed. If an error
occurs when allocating a new data set or writing data to a data set, then the NetView program issues the
DWO090A message to alert operators to the problem. The DWO090A message issued by the Canzlog
archive function is usually one of these:
DWO090A ALLOCATE error for Canzlog. Maintenance required.
or
DWO090A WRITE error for Canzlog. Maintenance required.
Additional messages can be issued by the NetView program or other components, such as DFSMSdfp or a
security product (such as RACF®), to provide more information about the nature of the problem, as well as
the type of Canzlog archive data set (index or message) to which the error applies.
Reasons for which the NetView program would issue message DWO090A, along with some actions that
can be taken, include the following:
• Insufficient available space on the volume on which a data set is being allocated or extended. Check the
volume(s) upon which allocation was requested and either supply another volume with sufficient space
or delete data from a volume so that there is sufficient space for the data set the next time that the
NetView program attempts to allocate a Canzlog archive data set. If the data sets created by the
Canzlog archive function are managed by the Storage Management Subsystem (SMS), then it may be
necessary to examine and change a storage class or storage group selected when the Canzlog archive
data sets are allocated. If statements that can affect volume selection are changed in the NetView style
sheet, then a NetView operator can run the RESTYLE ARCHIVE command to put the changes into effect.
Examples of statements that can affect volume selection include:
– For index data sets:
- ARCHIVE.INDEX.VOLUME
- ARCHIVE.INDEX.UNIT
- ARCHIVE.INDEX.STORCLAS
– For message data sets:
- ARCHIVE.MESSAGE.VOLUMES
- ARCHIVE.MESSAGE.UNIT
- ARCHIVE.MESSAGE.STORCLAS
These and other statements related to the Canzlog archive function are described in the sample
NetView style sheet, CNMSTYLE, as well as in the IBM Z NetView Administration Reference.
• Insufficient space defined for the data set to which the NetView program attempted to write data. The
NetView program writes up to 4096 80-byte records to an archive index data set (other than the
primary archive index data set) and writes 8192 1024-byte records to an archive message data set.
Consider the characteristics of the devices upon which the data sets are written (primary and secondary
allocation sizes, space units, and block sizes) and determine whether these devices can accommodate
these amounts of data.
If SMS is used to provide the characteristics of the data sets created by the Canzlog archive function,
then it might be necessary to change a data class or management class selected when the Canzlog
archive data sets are allocated. If a data management configuration results in the release of unused

space from the primary extent of a data set (for example, the partial release setting in an SMS
management class), an archive data set could be left with less space than is necessary to hold the
amounts of data described above. In that event, provide a secondary allocation that allows the archive
data sets to grow large enough to accommodate the amounts of data described above. If statements
that can affect space allocation are changed in the NetView style sheet, then a NetView operator can
run the RESTYLE ARCHIVE command to put the changes into effect. Examples of statements that can
affect space allocation include:
– For index data sets:
- ARCHIVE.INDEX.SPACE
- ARCHIVE.INDEX.BLOCKSIZE
- ARCHIVE.INDEX.DATACLAS
- ARCHIVE.INDEX.MGMTCLAS
– For message data sets:
- ARCHIVE.MESSAGE.SPACE
- ARCHIVE.MESSAGE.BLOCKSIZE
- ARCHIVE.MESSAGE.SPACE
- ARCHIVE.MESSAGE.MGMTCLAS
These and other statements related to the Canzlog archive function are described in the sample
NetView style sheet, CNMSTYLE, and in the IBM Z NetView Administration Reference.
• No authorization to create new archive data sets. For an instance of the NetView program to
successfully write data to a Canzlog archive, the following must be permitted.
– A virtual operator station task (VOST), attached by the primary program operator interface task (PPT)
and with PPT's authority, allocates an archive data set (which can be a primary index data set, an
index data set, or a message data set) and writes a first record to the archive data set. The VOST also
requests that any allocated data set is cataloged.
– Task DSILOGMT reads data from index data sets (the primary index data set and any index data set
indicated by records within the primary index data set). Task DSILOGMT also can write to an index
data set and/or the primary index data set. Note that DSILOGMT's access to the Canzlog archive data
sets is not restricted by NetView command (READSEC, WRITESEC) security.
• I/O errors allocating or writing data sets. If the device(s) upon which Canzlog archive data sets are being
written experience I/O errors, the NetView program might not be able to save Canzlog data. One
possible reason for an I/O error is that the system does not have write access to the volume on which
the I/O is being attempted. Another possible reason is that there is a defect in the device (possibly a
disk or control unit). The actions described for insufficient space on a volume can be applied here to
circumvent the problem.
DWO158W message is received

If you receive a DWO158W message, a command work block (CWB) or service work block (SWB) was
inadvertently overwritten.
If the memory dump has been successfully completed, use the following resolution steps to diagnose the
control block overwrite condition:
From the IPCS Browse Option Pointer panel or the IPCS Storage panel, issue the IPCS SUMMARY
subcommand to display the general purpose registers at the time the data was dumped. For example,
enter the following command:

IPCS SUMMARY REGISTERS
The SUMMARY subcommand displays the summary output panel.

2. Issue the FIND command from the summary output command line to find the registers at the time the
data was dumped in the summary output. For example, enter the following command:
FIND 0033
The FIND subcommand displays the Problem Request Block (PRB) with WLIC field 0033. See Figure 7
on page 66 for an example of the display.
The general purpose registers at the time the data was dumped are pointed to by the supervisor
request block (SVRB). The SVRB is the request block before the problem request block in the chain. To
display the SVRB, use the UP PF key.
3. Use the following general purpose registers pointed to by the SVRB to find the program that caused
the control block overwrite condition.
• Register 2 contains the base register (GPR 12) of the caller of the program that issued the NetView
service macro DSILCS to free the command work block (CWB) or service work block (SWB).
• Register 6 points to the work block being freed by the NetView service macro DSILCS.
• Record the contents of these registers.
4. From the IPCS Browse Option Pointer panel, select the pointer to see the IPCS Storage panel.
5. Locate the program that issued the NetView service macro DSILCS to free the work block.
• If the program that issued the NetView service macro DSILCS is a NetView module, contact IBM
Software Support.
• If the program that issued the NetView service macro DSILCS is not a NetView module, determine
why the work block freed by the DSILCS macro has been overwritten. Do this by looking at the
program that freed the work block.
a. Locate the work block that DSILCS was trying to free.
1) Look at the first word at the work block address. It is structured in the following way:
Byte 0 = CBH ID of work block

(X'D1' for SWB, X'C9' for CWB)
Byte 1 = In-use block (X'FF')
Byte 2-3 = Work block length
(X'0258' = SWBEND-DSISWB for SWB and
X'0170' = CWBEND-DSICWB for CWB)
If it is not, see whether the values are recognizable as user data.

2) Look at the storage preceding the work block address, and, if possible, determine whether it is
recognizable user data.
b. If the data is user data, look at the programs that create or manipulate the user data structures;
otherwise, contact IBM Software Support.

Figure 7. Diagnosing a Control Block Overwrite Problem Using IPCS
1
Problem Request Block (PRB) with WLIC field 0033
2
Supervisor Request Block (SVRB) points to the save area
3
Base Register (GPR 12) of the program issued the NV DSILCS free macro
4
Address of the NV control block DSISWB or DSICWB being freed
DWO627E message is received (MS Transport cancels)

If you receive a DWO627E message, the MS transport layer has encountered an error that has caused it to
cancel outstanding transactions and reinitialize its interface with VTAM.
If you code VTAMCP.USE=YES in the CNMSTYLE member, ensure that any partner host can receive MDS-
MUs with the VTAM control point (CP) name specified as the destination.

Using the VTAMCP statement IBM Z NetView Administration Reference
NetView Automation not properly occurring

Use the following sections to solve problems when NetView automation is unexpectedly driven or
NetView automation is not driven when expected.
NetView Automation unexpectedly driven

Use the following resolution steps when NetView automation is unexpectedly driven.
1. See which automation table is active and try to determine which automation statement was
unexpectedly driven. Use the AUTOTBL command to check the status.

2. If a command list or command processor was processed as a result of this unexpected automation,
look for a CNM493I message in the network log. A CNM493I message identifies which automation
statement caused the command processor to be run.
Note: If the DEFAULTS and OVERRIDE commands were used to suppress the CNM493I message, the
message is not shown in the network log.
3. Try to determine which message or management services unit (MSU) caused the automation to be
driven. If you find that this is a new or changed message or MSU, you might need to alter your
automation statement to avoid automating this message or MSU (your automation statement might be
too general).
4. If it seems that automation is being driven multiple times for the same message, use the Canzlog log
to check the attributes of the message. Note especially the routing codes and destination console.
Check the EMCS attributes for the NetView tasks that are automating the message. It is possible that
multiple tasks are specifying routing criteria with the extended console attributes, causing the
message to be delivered to more than one console. To correct this, adjust the extended console
attributes, or make a corrective automation statement to eliminate automation for certain messages
by task.
Also, check whether the message is logged twice with different time stamps. If a second instance of
the message is logged after automation completion of the first instance, the automation action might
have produced the second message. To correct this, review the automation to prevent the reissuing of
the message.

Corrective automation statements IBM Z NetView Automation Guide
Information about using the CNM493I message IBM Z NetView Automation Guide
with the DEFAULTS and OVERRIDE commands, and
the AUTOTBL command
The DEFAULTS and OVERRIDE commands NetView online help
NetView Automation not driven when expected

Use the following resolution steps when NetView automation is not driven when expected.
1. Check the appropriate system log, network log, or Canzlog log to determine whether you received the
message or MSU that you expected to drive automation.
2. If you believe the NetView program received the message or MSU:
a. Determine which automation table is active.
b. Check the automation table entry that you expected to be driven and compare each part of the
automation statement to the message or MSU it was intended to match. If the message has
changed in any way, your automation statement might no longer match as expected.
c. Check the automation statements that precede the statement you expected to be driven. Did the
message or MSU match the conditions on a preceding statement?
d. If the automation statement you expected to be driven is within a BEGIN-END pair, did the
message or MSU you expected to match qualify to enter the BEGIN-END pair?
You can use the AUTOCNT report with an automation listing to determine whether parts of your
table are not being reached. This might occur as the result of a BEGIN-END pair or an ALWAYS that
occurs before the intended statement.
e. If the automation statement called a command procedure, did the command procedure run without
errors?
3. If you believe that the message was issued by z/OS, take the following actions:

• Check for Message Revision Table (MRT) entries that apply to the message. In order for a solicited
message to be automated, it must be displayable. This restriction does not apply to unsolicited
messages.
• Check for Message Processing Facility (MPF) entries that apply to the message. If you are using the
AUTO and SUPPRESS keywords in the MVS MPF table for the message in question, see the
explanation in IBM Z NetView Automation Guide for more information about the special
considerations for these keywords when using EMCS consoles.
• If the message was not found in the Canzlog log, try viewing the log with fewer filters. In particular,
view all automatable messages and all trace messages. If the message still cannot be found in the
Canzlog log, determine whether MRT action suppressed the message from being logged and marked
it non-automatable.
• If the message is found in the Canzlog log, display the message attributes using DISPMSG. Check
whether the message is automatable. If a console name is given, use DISCONID to determine
whether the message was destined for a console owned by a NetView task. Check whether the time
interval for automation has a reasonable value.
• Use a NetView internal trace to determine what the CNMCSSIR task did with the message. The
NetView trace also indicates whether the message was sent to another operator or whether a
command or command list was scheduled to run. For example, if the message was sent to another
operator, or if a command was scheduled to run, an MQS entry exists.
• Search for DWO201I and DWO202I messages in the network log. If either of these messages is
found, an error occurred in the MVS dataspace for EMCS console messages. When this occurs,
system message queuing to some or all of the extended consoles in use by the NetView program, is
temporarily stopped. The messages that were destined for the EMCS consoles in use the NetView
program during this time are lost. To alleviate this problem, ensure that the extended console
attributes and dataspace size are set appropriately for your installation.
4. If you did not receive the message or MSU:
a. Verify that the component issuing the message is operational.
b. For messages, determine whether an ASSIGN command setting or a command procedure WAIT or
&WAIT suppressed or misrouted the message.
c. Ensure that the message or MSU has not been deleted or changed by an installation exit before
automation.
d. If the message should have been issued by MVS and you are using the subsystem interface for MVS
messages, take the following actions:
Ensure that the message passed through the subsystem interface. Use the following information to
determine the location of the message:
• Messages are found in a wraparound table within the message buffers in the CNMCANZ0 data
space. Use a memory dump of the CNMCANZ0 data space to examine all of the write-to-operator
(WTO) messages that are to be automated.
Note: The CNMCANZ0 data space is owned by *MASTER*. In order to obtain a memory dump of
CNMCANZ0, specify a value such as '*MASTER*'.CNMCANZ0 or 1.CNMCANZ0 (when the ASID of
*MASTER* is 1). You specify this value for the DSPNAME keyword when you reply to the WTOR
that is issued as a response to the z/OS DUMP command.
• If the message is not found in the subsystem interface address space, check the MVS message
processing facility (MPF) table entries that apply to that message.
• Check the message revision table entries that apply to the message.
• Use a NetView internal trace to determine what the CNMCSSIR task did with the message. The
NetView trace also indicates whether the message was sent to another operator or whether a
command or command list was scheduled to run. For example, if the message was sent to
another operator, or if a command was scheduled to run, an MQS entry exists.
e. If the message should have been issued by MVS and you are using the EMCS consoles to receive
MVS messages:

1) Determine which EMCS console should have received the message. Ensure that this extended
console is active. You can use the DISCONID command to display the MVS consoles in use by
the NetView program.
2) If you are using the AUTO and SUPPRESS keywords in the MVS MPF table for the message in
question, see the explanation in IBM Z NetView Automation Guide for more information about
the special considerations for these keywords when using EMCS consoles.
3) Check the message revision table entries that apply to the message.
4) Search for DWO201I and DWO202I messages in the network log.
If either of these messages is found, an error occurred in the MVS dataspace for EMCS console
messages. When this occurs, system message queuing to some or all of the extended consoles
in use by the NetView program, is temporarily stopped. The messages that were destined for the
EMCS consoles in use the NetView program during this time are lost. To alleviate this problem,
ensure that the extended console attributes and dataspace size are set appropriately for your
installation.

EMCS console attributes IBM Z NetView Automation Guide
The DISCONID command NetView online help
The NetView program is not attempting to archive Canzlog data

This section describes steps to take when an instance of the NetView program does not attempt to save
Canzlog data to an archive although such an attempt was expected.
• Check the definitions in the NetView style sheet.
For the NetView program to save Canzlog data to an archive, a valid high-level qualifier must have been
supplied with the ARCHIVE.HLQ statement, and ARCHIVE.WRITE must have the value YES. If
ARCHIVE.WRITE = YES is coded, then look for a message like this:
BNH803I VALUE *NONE* FOR KEYWORD ARCHIVE.HLQ CONFLICTS WITH VALUE YES
FOR KEYWORD ARCHIVE.WRITE
and possibly
DSI089I INVALID STATEMENT IN NCCF MEMBER CN@STYLE

ARCHIVE.HLQ xxxxxxxxxxxxxxxxxxxxxxxxxxx
which would indicate that the ARCHIVE.HLQ statement does not have a valid value. Note that the
sample CNMSTYLE shipped with the NetView program specifies ARCHIVE.WRITE = YES and has no
(uncommented) ARCHIVE.HLQ statement.
• Determine whether this instance of the NetView program was able to access the Canzlog.
When an instance of the NetView program gains access to the Canzlog, it issues this message:
DWO854I Canzlog is active.
If this message was not issued, the most likely reason is that there was no subsystem initialized for that
instance of the NetView program. Ensure that a statement like this:
SUBSYS SUBNAME(xxxx) INITRTN(DSI4LSIT)
appears in the IEFSSNxx member of PARMLIB, where xxxx is the subsystem name and matches the
corresponding characters at the beginning of the name of the start procedure for that instance of the
NetView program.
• If there was another instance of the NetView program running in the same logical partition, check its
configuration.

Only one instance of the NetView program in a logical partition can write Canzlog data to an archive. The
instance of the NetView program that has the Canzlog archive function enabled gets access to the
Canzlog and obtains exclusive control of a SYSTEM-scope resource representing archiving, becoming
the instance of the NetView program that attempts to archive Canzlog data. The LIST
STATUS=CANZLOG command can be used to show whether archiving is taking place and which
subsystem (and associated instance of the NetView program) is attempting to archive Canzlog data.
Another way to identify the instance of the NetView program that can archive Canzlog data is to display
information about the SYSTEM-scope resource that represents archiving.
If no MVS installation exit (for example, ISGNQXIT) altered the resource name, the MVS command D
GRS,RES=(SYSZCNM,CANZLOG.ARCHIVE) shows whether the resource representing archiving is held.
The following display indicates that the instance of the NetView program with jobname NVPROC is the
one that attempts to archive Canzlog data:
ISG343I 16.57.00 GRS STATUS 018

S=SYSTEM SYSZCNM CANZLOG.ARCHIVE
SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS
NMPIPL28 NVPROC 0036 006AE538 EXCLUSIVE OWN
The following display indicates that no instance of the NetView program on the logical partition can be
archiving Canzlog data:
ISG343I 16.58.49 GRS STATUS 901

NO REQUESTORS FOR RESOURCE SYSZCNM CANZLOG.ARCHIVE
If an MVS installation exit (for example, ISGNQXIT) changes the name of the resource that represents
archiving, specify that resource name in the RES keyword on the D GRS command.
A NetView operator cannot browse archived data

If a NetView operator can browse data in the active Canzlog, but cannot browse Canzlog data known to
have been saved in an archive, even if explicitly requested by date, then do the following:
• Ensure that there is an ARCHIVE.HLQ statement in the NetView style sheet that provides the correct
high-level data set qualifier for the archive
• Ensure that the users attempting to browse archived data have permission to access the archive data
sets, including all index data sets and message data sets The access may need to be granted in either or
both of (1) a security product (such as RACF), or (2) though READSEC command security in the NetView
program.
EP/Local errors not being recorded

EP/local errors are not being recorded at the hardware monitor database.
If EP/local errors are not being recorded at the hardware monitor database, take the following actions:
1. Use the NetView command LIST STATUS=TASKS to ensure that BNJMNPDA is an active task. Start the
task if it is not active. Also, determine whether a task abend was recorded at the time the error should
have been recorded.
2. Ensure that recording filters have not been set to block these records from being recorded.
3. Determine whether any errors are being recorded.
4. Check SYS1.LOGREC to determine if the error is recorded there. If the error is not recorded, this is not
a hardware monitor defect.
If you follow the preceding steps and do not identify your problem, document it in the following way:
1. Obtain the following documentation:
• Listings of the CNMSTYLE member for NetView installation.

• Data from SYS1.LOGREC for the error in question.
• The network log and the NetView trace from the time of the failure.
2. Follow the instructions in Chapter 2, “Classifying problems,” on page 13 and Chapter 3, “Documenting
and reporting problems,” on page 23 before contacting IBM Software Support.

Task statement IBM Z NetView Installation: Configuring Additional
Components
Unsolicited remote errors or distributed mainframe server errors not

recorded
Unsolicited remote errors or distributed mainframe server errors are not being recorded.
If remote device errors are not being recorded and you are using focal point alerting, check each step at
the focal point and the distributed mainframe server in the following way:
1. Ensure that DSICRTR, BNJDSERV, and xxxxxLUC (where xxxxx is a 1–5 character domain name such as
CNM01) are active tasks for the correct NetView domain, using the NetView command LIST
STATUS=TASKS. Start the tasks at both the focal point and distributed servers if the tasks are not
active. Also determine whether a task abend was recorded at the time of the error.
2. Ensure that recording filters have not been set to block these records at the focal point or the
distributed mainframe server.
3. Determine whether any errors are being recorded.
4. Check SYS1.LOGREC to determine whether the error is recorded there. If the error is not recorded, this
is not a NetView defect.
5. Ensure that VTAM CSECT ISTMGC00 is link-edited as reusable in NETVIEW.V6R3USER.VTAMLIB. Also,
be sure that there are no concatenated libraries containing versions of ISTMGC00.
6. If you change the APPLID of the NetView hardware monitor, ensure that you specify it in ISTMGC00
and code ACBNAME=BNJHWMON.
If you followed the preceding steps and do not identify your problem, use the following steps:
1. Obtain the following information:
• Listings of the CNMSTYLE member for NetView installation (focal point and the distributed
mainframe server).
• From SYS1.LOGREC, data for the error in question
• A memory dump of CSECT ISTMGC00
• A VTAM buffer trace of task DSICRTR, or user-defined APPLID
• The network log and the NetView trace at the time of the failure

Coding the task statement in the CNMSTYLE Sample CNMSTYLE
member
Solicited data not recorded

If solicited data is not being recorded, take the following actions at the focal point and the distributed
mainframe servers:

1. Ensure that DSICRTR, BNJDSERV, and xxxxxLUC (where xxxxx is a 1–5 character domain name such as
CNM01) are active tasks for the correct NetView domain, using the NetView command LIST
STATUS=TASKS. Start the tasks at both the focal point and distributed servers if the tasks are not
active. Also, check that a task abend was recorded at the time of the error.
2. Determine whether errors are being recorded. If not, document the problem.
3. Ensure that for VTAM, ISTMGC00 is link-edited as reusable in NETVIEW.V6R3USER.VTAMLIB. Also, be
sure that there are no concatenated libraries containing versions of ISTMGC00.
4. If you change the APPLID of the NetView hardware monitor, ensure that you specify it in ISTMGC00
and code ACBNAME=BNJHWMON with AUTH=CNM.
5. Check any error messages issued in response to the solicitation command. If error messages are
present, give this information to IBM Software Support when discussing this failure.
If the responses for a NetView command are not returning to the originating console, check the NetView
automation table at the focal point and the distributed mainframe server. The responses might be
suppressed or routed to another task by the NetView automation table.
If you followed the preceding steps and do not identify your problem, document the problem in the
following way:
• Listings of the CNMSTYLE member for NetView installation from the focal point and the distributed
mainframe server
• A VTAM buffer trace of BNJHWMON and DSICRTR, or of the user-defined APPLID, from the focal
point and the distributed mainframe server
• A VTAM path information unit (PIU) trace of the unit for which the solicitation was performed
• The complete text for any message issued because of the solicitation
• The network log and the NetView trace from the time of the failure

Coding the task statement in CNMSTYLE member Sample CNMSTYLE member
RMTCMD RUNCMD command response is displayed on MVS console

RMTCMD RUNCMD commands are sent to a service point from a distributed NetView program. The
responses from the service point for the RUNCMD are sent to the MVS console of the mainframe server
where the service point resides, instead of being returned to the distributed NetView program where the
remote RUNCMD was issued. For example, you issue the following command from network A01NV:
RMTCMD LU=B01NV,RUNCMD SP=B0488LAA,APPL=APPLNAME,LOG OPER1
If the service point B0488LAA resides under LU B02NV instead of under B01NV, the RUNCMD can get to
B0488LAA but the response might not be returned to A01NV. The RMTCMD logs on the operator issuing
the command. If OPER1 is logged on to A01NV and sends the RMTCMD to B01NV, OPER1 is logged on to
B01NV. If the RMTCMD finds B0488LAA on B02NV, OPER1 might not be logged on to B02NV. Therefore, if
the NetView program does not have an authorized receiver, the response is returned to its MVS console.
This problem might occur when you issue log commands that direct the responses of the commands to a
service point.
If responses are not being returned to the NetView program that issued the command, verify that the
service point specified in the RUNCMD is under the LU specified in the RMTCMD.

RMTCMD and RUNCMD commands NetView online help
Diagnosing NetView security problems

If you experience security problems where the authorization does not match your expectations, refer to
the IBM Z NetView Security Reference.
If you use a system authorization facility (SAF) product such as Resource Access Control Facility (RACF),
and you experience performance problems, a possible cause might be excessive security authorization
calls. To enhance performance of security within the NetView environment, refer to the IBM Z NetView
Tuning Guide.
If you cannot solve the problem, gather detailed information about your security setup and processing by
using an SAF TRACE record, as described in “NetView trace” on page 100 and in “Security Authorization
Facility trace record” on page 140, and contact IBM Software Support.

Chapter 6. Diagnostic tools for the NetView program
This chapter contains information about the following diagnostic tools:

• Interactive problem control system (IPCS)
• Network log with CMDMON, TASKUTIL or TASKMON command output
• SMF Log, Record 38, Subtype 2, NetView task utilization data
• SMF Log, Record 38, Subtype 4, command statistics data
• NetView trace
• Session monitor trace
• First failure data capture trace
• NetView program-to-program interface (PPI) trace facility which includes:
– Understanding the PPI trace anchor block and the PPI trace table
– Understanding the PPI trace record
– Locating the PPI trace table
– Locating the oldest PPI trace record
– Generalized trace facility (GTF) output files
Use these tools to diagnose problems with the NetView program and its components.
Interactive Problem Control System

The interactive problem control system (IPCS) is a component of MVS that is used for diagnosing software
failures. You can use the IPCS to perform the following tasks:
• Format and display memory dump data
• Locate modules and control blocks
• Validate control blocks
• Check certain system components
IPCS also provides a verb exit interface so that you can write a verb exit routine to generate a unique
diagnostic report that is not available in IPCS.
The NetView program provides an IPCS verb exit routine for analyzing NetView dumps from an MVS
system. Use the routine with NetView Version 2 Release 4 or later. The routine assists you in analyzing a
NetView dump before you contact IBM Software Support and during the analysis of a problem while you
are in contact with IBM Software Support.
The IPCS verb exit routine that is provided with the NetView program has both a command-line interface
and a panel interface. The panel interface is available if the environment is set up under TSO to allow ISPF
panels to be displayed. The panel interface provides more powerful functions than the command-line
interface, such as the ability to select multiple tasks or the ability to specify an IPCS symbol wherever a
storage address is required. It also provides help text through the ISPF help interface.

IPCS IPCS library
Installation
The NetView IPCS code is installed in the data set defined with the CNMLINK qualifier. The default for this
is NETVIEW.V6R3M0.CNMLINK; however, your data set can be different.

The ISPF panels used with the NetView IPCS code are installed in the data set defined with the
SCNMPLIB qualifier. The default for this is NETVIEW.V6R3M0.SCNMPLIB; however, your data set can be
different.
For information about how to enable the NetView IPCS code to run in a TSO IPCS environment, see IBM Z
NetView Installation: Configuring Additional Components.
Operation
The NetView program provides a verb exit routine, CNMIPCS, that functions similarly to any standard
IPCS verb exit routine. The output from CNMIPCS is written to both the terminal and the IPCS print file.
All numeric values displayed in error messages are in hexadecimal.
When you run the CNMIPCS verb exit routine, the routine reads the IPCS symbols CNMASID and MVT.
If CNMASID is found, CNMIPCS uses this variable as the address space identifier (ASID) for running the
command entered.
If the MVT symbol is found and contains the same ASID as CNMASID, the symbol MVT is used as the
pointer to the NetView main vector table (MVT) control block. If CNMASID is not found, the ASID portion
of CNMASID is set to the MVT ASID.
If both symbols are not found, CNMIPCS searches for the NetView MVT control block in the default ASID
passed from IPCS. If this search is unsuccessful, CNMIPCS continues searching for the control block in
the remaining ASIDs.
If the NetView MVT control block is found, the IPCS symbol CNMASID and MVT are set and CNMIPCS runs
the requested command. Otherwise, CNMASID is set to the default ASID, a message is issued indicating
the MVT was not found, and (if it is a non-NetView specific command) the command is run.
If CNMIPCS cannot find the NetView MVT control block and you are able to locate it, you can set the MVT
symbol manually using the IPCS LITERAL command.
Note: You can modify the address space against which CNMIPCS runs (including a non-NetView address
space) by specifying the ASID verb.
By default or if you specify MENU, CNMIPCS runs the panel interface. The actions on the main panel
correspond to the verbs listed in the syntax. Some verbs do not have a corresponding selection in the
panel interface, and some functions that are available in the panel interface are not available in the verb
interface.
Note:
1. If you start CNMIPCS either with the MENU option or without any options and if an ISPF environment is
not active or the main panel is not available to TSO, CNMIPCS runs using the SUMMARY verb.
2. If you specify a verb other than MENU, the output for the specified verb is displayed and the menu is
not displayed.
3. When you specify the MENU option, a single formatting action is performed, after which CNMIPCS
ends. To perform another formatting action, run CNMIPCS again.
The syntax for the CNMIPCS routine is shown in Figure 8 on page 77.

'MENU'
VERBX CNMIPCS
' ASID (asid_number) '
' CPOOL ( SelOp ) '
' D (address) '
' DISPLAY ( SelOp ) '
'DISPMOD'
' DTCB (address) '
'LEVEL'
' LRCE ( SelOp ) '
' MAP (sum) '
'NLDM'
'NPDA'
' QUE ( SelOp ) '
' SAVEAREA (address) '
' STORE ( SelOp ) '
'SUMMARY'
'TBLUSECT'
' TRACE ( TraceOp ) '
' WHO (address) '
TraceOp
ALL
DISP
FRE
GET
LOST
MENT
MENTMXIT
MQS
MXIT
POS
PSS
SAF
STOR
SUM
TRTVB ( SelOp )
TCP
WAT
SelOp
ACTIVE
ABEND
Chapter 6. Diagnostic tools for the NetView program 77
ALL
Summary of VERBX CNMIPCS verbs
The following list shows the verbs that can be specified on the CNMIPCS command. Unless indicated
otherwise, a selection on the main menu in the panel interface provides the same information as the verb.
MENU
Displays the main menu for the panel interface if CNMIPCS is run in an ISPF environment and the
CNMIPCS panels are available to TSO. From the main menu, you can select an action to perform. The
selections on the main menu correspond to other verbs that are available. Any information that can be
retrieved using a verb other than MENU can be retrieved using the panel interface. MENU is the
default verb.
Note: If ISPF panels cannot be displayed, SUMMARY is used as the default verb.
ASID(asid_number)
Changes the address space identifier (ASID) number. The CNMASID symbol is set to this address
space. If the MVT is found, the MVT symbol is also set to point to the main vector table.
For either the panel or the command-line interface, CNMIPCS formatting is performed on the
specified ASID number, until the ASID number is changed again with the ASID verb.
CPOOL(options)
Displays the CPOOL storage allocation by task, subpool, and CPOOL size. This command is specific to
D(address)
Displays storage with offsets. As an alternative to the D verb, the panel interface provides a more
powerful storage display facility. It enables multiple storage area definitions (each with its own static
or dynamic length) and chaining of similar and dissimilar blocks of storage.
DISPLAY(options)
Displays summary information about task vector blocks (TVBs). This command is specific to the
NetView program.
DISPMOD
Displays LMOD and CSECT information.
DTCB(address)
Displays the TCB and RB structure.
LEVEL
Displays the NetView IPCS verb exit level. The panel interface does not provide a selection that
corresponds to this verb; instead, the NetView IPCS verb exit level is always displayed near the top of
the main menu.
LRCE(options)
Displays the LRCE chain for TVBs. This command is specific to the NetView program.
MAP(sum)
Displays storage usage.
NLDM
Displays status information for the session monitor. This command is specific to the NetView
program.
NPDA
Displays status information for hardware monitor. This command is specific to the NetView program.
QUE(options)
Displays the number of messages on the queues for TVBs, and others. This command is specific to the
NetView program.
SAVEAREA(address)
Displays the SAVEAREA trace.
STORE(options)
Displays storage counters for TVBs. This command is specific to the NetView program.

SUMMARY
Displays summary information about the memory dump, including CSECT information.
TBLUSECT
Displays the counters for the automation table. This command is specific to the NetView program.
TRACE(options)
Displays the NetView internal trace header and formatted trace records. This command is specific to
WHO(address)
Attempts to determine if the address is a module or a control block.
Options for some CNMIPCS verbs

The following option variables are valid only with the CPOOL, DISPLAY, LRCE, QUE, and STORE verbs and
with the TRTVB trace option. The panel interface provides corresponding selections (and multiple task
selections) for main menu items that require task selection.
ABEND
Selects all abending TVBs.
ACTIVE
Selects only active TVBs. This is the default option.
ALL
Selects all TVBs.
LU(lu_name)
Selects a specific logical unit (LU) name.
OP(operator_id)
Selects a specific operator ID or task name.
TCB(address)
Selects a specific task control block (TCB). If you do not specify an address or if you enter zero for the
address, the TVB symbol is used.
TIB(address)
Selects a specific task information block (TIB). If you do not specify an address or if you enter zero for
the address, the TVB symbol is used.
TVB(address)
Selects a specific TVB. If you do not specify an address or if you enter zero for the address, the TVB
symbol is used.
Note:
1. If a TVB is found for options ABEND, TVB, TIB, TCB, OP, or LU, the IPCS symbols TVB, TIB, and TCB are
set for the task found. For the ABEND option TVB, TIB, and TCB are set to the last abending task found.
2. If you are entering a variable that contains single quotation marks, preserve the single quotation
marks by enclosing them in another set of quotation marks. For example the address variable for a
TVB can be entered as a blank, null, zero, decimal value, or a hexadecimal value. When specified as a
hexadecimal value, the following quotation mark rule is observed:
…'DISPLAY(TVB)' Blank
…'DISPLAY(TVB())' Null
…'DISPLAY(TVB(0))' Zero
…'DISPLAY(TVB(100))' Decimal value
…'DISPLAY(TVB(X''64''))' Hexadecimal value
Options for the CNMIPCS TRACE verb

The following option variables are valid only with the TRACE verb. When you select trace formatting from
the panel interface, you can select one or more trace record types.
ALL
Display all records. This is the default.

DISP
Displays only DISPs.
FRE
Display only FREs.
GET
Displays only GETs.
LOST
Display only LOSTs.
MENT
Displays only MENTs.
MENTMXIT
Display only MENTs and MXITs.
MQS
Displays only MQSs.
MXIT
Displays only MXITs.
POS
Display only POSs.
PSS
Displays only PSSs.
SAF
Displays only SAFs.
STOR
Display only GETs and FREs.
SUM
Displays a summary by TVB.
TCP
Displays only TCP entries.
TRTVB(options)
Displays a specific TRTVB internal trace header and formatted trace records.
WAT
Display only WATs.
Examples of option selections

The following examples show option selection when using the DISPLAY command:
Example 1
Displaying a summary of all TVBs found:
VERBX CNMIPCS 'DISPLAY(ALL)'
Example 2
Displaying a summary of a task with a task name of BNJDSERV:
VERBX CNMIPCS 'DISPLAY(OP(BNJDSERV))'
Example 3
Using DISPLAY to read the TVB symbol and display a summary of the task with one of the following
examples:
VERBX CNMIPCS 'DISPLAY(TVB)'

VERBX CNMIPCS 'DISPLAY(TVB())'
VERBX CNMIPCS 'DISPLAY(TVB(0))'

Example 4
Using DISPLAY to find X'64' and display a summary of the task with one of the following examples:
VERBX CNMIPCS 'DISPLAY(TVB(100))'

VERBX CNMIPCS 'DISPLAY(TVB(X''64''))'
IPCS command output

The following are examples of the IPCS output when you run the CNMIPCS routine.
Summary Output
Figure 9 on page 82 shows an example of the IPCS output when you issue the SUMMARY command
(VERBX CNMIPCS 'SUMMARY') or select Summary on the main menu. In the example, the IPCS symbol
MVT is defined if the main vector table (MVT) is found. IPCS symbols TVB, TIB, and TCB are defined for
the last abending NetView task found.
The following list shows the field descriptions:
Field
Description
a
Control block name
b
Offset of address into control block
c
CSECT name
d
Date of CSECT
e
Offset of address into CSECT
f
PTF level of CSECT

CNMIPCS SUMMARY
ASID in hex = 00000021 Job name = NVPROC
MVT address in hex = 00008190 NetView version = NV63
TVB 40250 IND1-4 00008100 TIB 1179A0 TCB 8D5BB0 OPT 5 DSIQTSK DSIQTSK
ABENDING TASK DSIQTSK TCB 8D5BB0 RTM 7F70A090 TCB CC 940C4000
Registers at time of abend from RTM2
REG 0 06BA2610
REG 1 00000000 a b
REG 2 0000AB90 DSIMVT +0000
REG 3 FFFFFFFF
REG 4 06D10030
REG 5 06BDE030
REG 6 00114F74
REG 7 00114F74
REG 8 06BA2100
REG 9 00114F74 c d e f
REG A 06560D7E DSIQTSKI 2009.096 +1FFE TIVNV63
REG B 0655FD7F DSIQTSKI 2009.096 +0FFF TIVNV63
REG C 0655ED80 DSIQTSKI 2009.096 +0000 TIVNV63
REG D 06BA2580
REG E 8655FBC8 DSIQTSKI 2009.096 +0E48 TIVNV63
REG F 00000001
PSW at time of abend from RTM2 7F70A090

PSW 078D2000 8655FCE4 00040011 00115070 DSIQTSKI 2009.096 +0F64 TIVNV63
NetView IPCS version NV63 PTF level TIVNV63 Time-Date 08.32 05/18/19
Figure 9. Example of Summary Output
ASID Command Output

Figure 10 on page 82 shows an example of the IPCS output when you run the CNMIPCS routine with the
ASID command. The following ASID commands search ASID X'64':
VERBX CNMIPCS 'ASID(X''64'')'

VERBX CNMIPCS 'ASID(100)'
If the MVT is found in the specified ASID, the SUMMARY command is run. If the MVT is not found in the
specified ASID, a warning message is issued and the SUMMARY command is run.
Could not find MVT in ASID 64
CNMIPCS SUMMARY
ASID in hex = 00000064 Job name = SSIPROC
Figure 10. Example of Output from the ASID Command
CPOOL output
Issuing the CPOOL command or selecting Task CPOOL information on the main menu displays CPOOL
storage allocation by task, subpool, and CPOOL size.
Figure 11 on page 83 shows an example of the output when you run the CNMIPCS routine with the
CPOOL command using the default option of ACTIVE:
VERBX CNMIPCS 'CPOOL'
See “Options for some CNMIPCS verbs” on page 79 for other options that can be specified. The following
list shows the field descriptions:

Field
Description
a
TVB address - if zero, then this is for non-queued storage
b
Subpool
c
Size of individual cells
d
Total number of cells in use
e
Total number of cells allocated
f
Maximum number of cells ever allocated
g
Amount of above the line storage in use
h
Amount of above the line storage allocated but not in use
i
Amount of below the line storage in use
j
Amount of below the line storage allocated but not in use
(a) (b) (c) (d) (e) (f) (g) (h) (i) (j)
CELLS TOTAL HIGH ABOVE ABOVE STG BELOW BELOW STG
TVB SP SIZE USED CELLS WATER STG USED NOT USED STG USED NOT USED
000000 00 8 5 3B 5 50 1B0 0 0
000000 00 18 5 9 6 A0 60 0 0
000000 00 30 4 4 5 E8 0 0 0
000000 00 60 3C8B 3CDE 3C8B 16EDF0 F60 28 FC0
NOTE: All numbers are in hexadecimal
Figure 11. Example of Output from the CPOOL Command
Display storage output

Figure 12 on page 84 shows an example of the output when you run the CNMIPCS routine using the D
command. The D command displays storage from a memory dump. For a more powerful display facility,
you can select Storage at address or symbol below on the main menu. If you use the D command, the
default is 24 lines, but it can be overridden by the SHOWLEN option. The following example illustrates the
D command with the SHOWLEN option:
VERBX CNMIPCS 'D(X''60C8'') SHOWLEN(X''33'')'
Note: The D command displays storage only in 4-word multiples; therefore, it truncates X''33'' to X''30''.
Field
Description
a
Storage address
b
Offset
c
Storage in hexadecimal

d
Storage in EBCDIC
a b c d
00007CD0 - 0000 - F1000D90 D5E5F6F2 00000000 05845230 | 1...NV63.....d.. |
00007CE0 - 0010 - 858B3610 858B86B0 05720150 05720158 | e...e.f....&.... |
00007CF0 - 0020 - 000419F8 00000000 00000000 00000000 | ...8............ |
Figure 12. Example of Output from the D Command
Display task output

Figure 13 on page 85 shows an example of the IPCS output when you run the CNMIPCS routine with this
DISPLAY command:
VERBX CNMIPCS 'DISPLAY'

VERBX CNMIPCS 'DISPLAY(ACTIVE)'
Instead, you can select Task summary on the main menu; when you do that, the Task Selection panel is
displayed so that you can select the active TVBs or any subset of tasks.
The example shows the output produced when you run the CNMIPCS routine with the DISPLAY command
using the default option of ACTIVE. See “Options for some CNMIPCS verbs” on page 79 for other options
that can be specified. The following list shows the field descriptions:
Field
Description
a
The TVB address.
b
Flags from TVB (TVBIND1 — TVBIND4).
c
The TIB address.
d
The TCB address.
e
The task type.
f
The TVB task priority. For MVS dispatching priority, subtract this number from 255.
g
The LU name of the task.
h
The operator ID or task name of the task.

a b c d e f g h
TVB 59418 IND1-4 00000000 TIB 1A338 TCB AED330 MNT 0 SYSOP SYSOP
TVB 4B1A8 IND1-4 80088400 TIB 1E030 TCB AD5840 PPT 0 CNM03PPT CNM03PPT
TVB 4B328 IND1-4 00008000 TIB 1F018 TCB AD5610 OPT 9 NATASK
TVB 4B4A8 IND1-4 00008000 TIB 21018 TCB AD4880 DST 3 DSI6DST DSI6DST
TVB 4B628 IND1-4 00008000 TIB 23018 TCB AD5460 DST 3 DSIHPDST DSIHPDST
TVB 4B7A8 IND1-4 00008000 TIB 25018 TCB AD2D18 DST 5 DSIUDST DSIUDST
TVB 4B928 IND1-4 00008000 TIB 27018 TCB AD4D18 DST 4 DSIROVS DSIROVS
TVB 4BC28 IND1-4 00008000 TIB 29018 TCB AD4B68 DST 1 DSILOG DSILOG
TVB 4BDA8 IND1-4 00008000 TIB 2B018 TCB AD29F8 DST 6 DSICRTR DSICRTR
TVB 4C0A8 IND1-4 00008000 TIB 2D018 TCB AD2848 OPT 5 CNMCSSIR CNMCSSIR
TVB 4C228 IND1-4 00008000 TIB 2F018 TCB AD2528 OPT 5 CNMCALRT CNMCALRT
TVB 4C3A8 IND1-4 00008000 TIB 31018 TCB AD2378 DST 2 DSISVRT DSISVRT
TVB 4C528 IND1-4 00008000 TIB 34018 TCB AD4460 DST 1 DSIGDS DSIGDS
TVB 4C6A8 IND1-4 00008000 TIB 36018 TCB AD3E88 DST 2 DSIELTSK DSIELTSK
TVB 4C828 IND1-4 00008100 TIB DE018 TCB AC5C18 DST 5 AAUTSKLP AAUTSKLP
ABENDING TASK AAUTSKLP TCB AC5C18 RTM 7F604090 TCB CC 940C4000
Registers at time of abend from RTM2

R0 03E4AD1C R1 03E4ACB0 R2 00000000 R3 00000000
R4 03D241C8 R5 FFFFFFFF R6 03E4AB10 R7 0000016C
R8 03D206F8 R9 03D241C8 RA 03DF5EE0 RB 03E4AC50
RC 83DF4EE0 RD 03E4AC08 RE 00000004 RF 00000000
PSW at time of abend from RTM2

PSW 078D3000 83DF576E 00040004 7F558000
TVB 4C9A8 IND1-4 00008000 TIB 71018 TCB AD39B8 DST 6 AAUTCNMI AAUTCNMI
TVB 4CB28 IND1-4 00008000 TIB 73018 TCB AD3808 DST 7 DSIAMLUT DSIAMLUT
Figure 13. Example for Output from the IPCS DISPLAY Command
DISPMOD output
Figure 14 on page 86 shows an example of the LMOD and CSECT information displayed when you run
CNMIPCS with the DISPMOD command:
VERBX CNMIPCS 'DISPMOD'
Instead, you can select Load module/CSECT (DISPMOD) on the main menu.
Field
Description
a
Load module name
b
Starting address of load module
c
Ending address of load module
d
CSECT name.
e
Starting address of CSECT
f
Offset of CSECT into load module
g
Date in CSECT
h
PTF level in CSECT.

a b c d e f g h
LMOD LMOD ENT LMOD END CSECT ADDRESS OFFSET DATE PTF LEVEL
DSIDCAMS 000060C8 00006637 DSIDCAMS 000060C8 +0000 05/15/19
DSIEX14 00007C38 00007C3F DSIEX14 00000000 +0000 LMOD
DSIDTEND 00007C90 00007E5F DSIDTEND 00007C90 +0000 19.287 TIVNV63
Figure 14. Example of Output from IPCS DISPMOD Command
Note:
1. If no CSECT name is found in the load module, the CSECT column entry contains the load module
name; the ADDRESS column entry is zero and the DATE column entry contains LMOD.
2. The DISPMOD command uses a best guess algorithm and therefore might display erroneous
information for some CSECTs or load modules.
Display TCB output

following DTCB command:
VERBX CNMIPCS 'DTCB(X''8D5BB0'')'
Instead, you can select TCB and RB structure on the main menu. If you do that, the Task Selection panel
is displayed so that you can select the active TVBs or any subset of tasks, as long as the NetView program
is the target address space. If the NetView program is not the target address space, you must specify the
address of a TCB on the Task Selection panel.
TCB ADDRESS: 008D5BB0 COMP CODE 940C4000 RTM2 7F70A090

REGS 0 - 15 FROM TCB
R0 01A21158 R1 01A21158 R2 01383D28 R3 0138462C
R4 00000004 R5 01381018 R6 02506F93 R7 01383650
R8 02507F92 R9 82505F94 R10 00000004 R11 01679FFF
R12 01384CAC R13 01383E28 R14 00000200 R15 00000000
RB ADDRESS:008D5868 PSW 078D2000 8655FCE4 INT CODE 00040011 PRB

REGS 0 - 15 FROM RB
R0 0655A8E8 R1 00040250 R2 000402B0 R3 06191800
R4 FFFFFFFB R5 06B42400 R6 00040250 R7 861BDF18
R8 000060C8 R9 0610C220 R10 00000000 R11 0610C6E0
R12 06100CA0 R13 000372B0 R14 0610110C R15 0610C674
RB ADDRESS:008DF600 PSW 070C1000 8260920E INT CODE 0002000C SVRB

REGS 0 - 15 FROM RB
R0 06BA2610 R1 00000000 R2 00000000 R3 FFFFFFFF
R4 06D10030 R5 06BDE030 R6 00114F74 R7 00114F74
R8 06BA2100 R9 00114F74 R10 06560D7E R11 0655FD7F
R12 0655ED80 R13 06BA2580 R14 8655FBC8 R15 00000001
Figure 15. Example of Output Produced Using the DTCB Command
LEVEL command output

The LEVEL command displays the NetView IPCS verb exit level. Enter the following command:
VERBX CNMIPCS 'LEVEL'
The following example shows the output when you use the LEVEL command to run the CNMIPCS routine:
Note: Because the level information is displayed on the main menu, a corresponding selection is not
available on the main menu.

LRCE output
following LRCE command with the operator_id option:
VERBX CNMIPCS 'LRCE(OP(KATIEF))'
Instead, you can select Task LRCE information on the main menu. If you do that, the Task Selection
panel is displayed so that you can select the active TVBs or any subset of tasks.
See “Options for some CNMIPCS verbs” on page 79 for other options that can be specified on the LRCE
command. The following list shows the field descriptions:
Field
Description
a
The TVB address
b
The flags from TVB (TVBIND1 - TVBIND4)
c
The TIB address
d
The TCB address
e
The task type
f
The task priority
g
The LU name of the task
h
The operator ID or task name of the task
i
The LRCE address
j
The name associated with LRCE
k
The command list block address
l
The address of the first of a chain of blocks containing the command procedure in storage
m
The name of the procedure represented by this CLIST block (CLB)
n
The type (CLIST or REXX)
o
The load mode (LOCAL if loaded for this execution, or GLOBAL if loaded with LOADCL)
a b c d e f g h
TVB 39440 IND1-4 80089400 TIB CB338 TCB BC6510 OST 0 ALEXF KATIEF
i j
LRCE 4EF0108 LRCE name DSICLIST
k l m n o
CLB: 4FF77A8 IPB: 4EF0228 MAINMENU CLIST LOCAL
CLB: 4FEEBF8 IPB: 4EF0168 LOGPROF1 CLIST LOCAL
LRCE 4EF00A8 LRCE name DSIAPPCC
LRCE 4EF0048 LRCE name DSINCCF
LRCE 4EF0CA8 LRCE name DSIVIEW
Figure 16. Example of Output from the IPCS LRCE Command

MAP output
The MAP command and the Storage map and Storage map summary selections on the main menu
display the storage usage. To use the MAP command, enter the following command:
VERBX CNMIPCS 'MAP'
Figure 17 on page 88 shows an example of the output when you run the CNMIPCS routine using the MAP
command:
MVS LEVEL SP7.2.2 HBB77A0
ASID 50
REGION SIZE REQUESTED
< 16M 7FB000

> 16M 4800000
REGION SIZE ALLOCATED
< 16M 7D000

> 16M 1507000
************************************
SUBPOOLS 245 & 255 ABOVE 16 MEG
DFE 7F643460 AREA 794000 SIZE 8

DFE 7F6C4610 AREA 794400 SIZE 8
DFE 7F6643D0 AREA 7945D0 SIZE 8
Figure 17. Example of Output from the MAP Command
Figure 18 on page 88 is an example of the output when you run the CNMIPCS routine using the
MAP(sum) command:
VERBX CNMIPCS 'MAP'(sum)
MVS LEVEL SP7.2.2 HBB77A0
ASID 50
REGION SIZE REQUESTED
< 16M 7FB000

> 16M 4800000
REGION SIZE ALLOCATED
< 16M 7D000

> 16M 1507000
**** SUBPOOL SUMMARY ****

SP 0 ALLOCATED ABOVE 16M 198000 FREE D0
BELOW 16M 1E000 FREE 960
SP 2 ALLOCATED ABOVE 16M 49000 FREE 0

BELOW 16M 0 FREE 0
SP 6 ALLOCATED ABOVE 16M 11D000 FREE 0

BELOW 16M 1B000 FREE 2298
SP 9 ALLOCATED ABOVE 16M 2AE000 FREE 380

BELOW 16M 0 FREE 0
Figure 18. Example of Output Produced Using the MAP(sum) Command

NLDM output
NLDM command:
VERBX CNMIPCS 'NLDM'
Instead, you can select NLDM information on the main menu.

The following symbols are set if they are found:
SKTVB
Contains the address of the TVB for task AAUTSKLP
SKTIB
Contains the address of the TIB for task AAUTSKLP
SKTID
Contains the address of the TID for task AAUTSKLP
SKSTRR
Contains the address of control block AAUTSTRR for task AAUTSKLP
SKGLOB
Contains the address of control block AAUTGLOB for task AAUTSKLP
SKSCT
Contains the address of control block AAUTSCT for task AAUTSKLP
SKCTL
Contains the address of control block AAUTCTL for task AAUTSKLP
CNTVB
Contains the address of the TVB for task AAUTCNMI
CNTIB
Contains the address of the TIB for task AAUTCNMI
CNTID
Contains the address of the TIB for task AAUTCNMI
CNSCT
Contains the address of control block AAUTSCT for task AAUTCNMI
CNCTL
Contains the address of control block AAUTCTL for task AAUTCNMI
Figure 19 on page 90 is an example of the output when you run the CNMIPCS routine using the NLDM
command.

**** EVENT COUNTERS ****
No of PIU buffers proc-ed 1F5D9 NO of PIUs processed 2082C1
No of SAW buffers proc-ed 482C No of SESS STARTS proc-ed 2E95
No of SESS ENDS processed 23CB No of SESS rec-ed to VSAM 149E
** SESSION COUNTERS **
No of ASB control blocks AD0 ASB cnt blk highwater mark AE5
No of SESS being filtered 0 SESS filter highwater mark 0
No of SESS with host endpt AC9 No SESS keeping RTM data 1F
No of SESS keep-g XNET dat 0 No of SESS keep-g DOM dat 95C
No of SSCP-SSCP sessions 4 SSCP-SSCP highwater mark 4
No of SSCP-PU sessions 5 SSCP-PU highwater mark 5
No of SSCP-LU sessions F3 SSCP-LU highwater mark F5
No of LU-LU sessions 9CD LU-LU highwater mark 9E0
No of SESS wait-g for VSAM 6 Record queue h-water mark 17
No of SESS KEEP-G acnt dat AD0
** RESOURCE COUNTERS **
No of ARB control blocks 88C ARB cnt blk highwater mark 8A4
No of SSCP ARBS 5 SSCP ARB highwater mark 5
No of PU ARBS 5 PU ARB highwater mark 5
No of LU ARBS 869 LU ARB highwater mark 881
No of LINK ARBS 19 LINK ARB highwater mark 19
** STORAGE COUNTERS **
No of bytes for RTM data 9B0 No of bytes for SESS parms 3C8CA
No of bytes for TRACE data 6758C2 No of bytes for ACCT data 22000
No of bytes ASB cnt blk B6000 No of bytes ARB cnt blk 3D000
AAUTSKLP has 19 ADXs allocated and 0 ADXs in use
AAUTSKLP has 0 transactions waiting
AAUTSKLP has 5 unsolicited DSRBS and 0 are in use
AAUTSKLP has A solicited DSRBS and 0 are in use
AAUTCNMI has B ADXs allocated and 0 ADXs in use
AAUTCNMI has 0 transactions waiting
AAUTCNMI has 1 unsolicited DSRBS and 0 are in use
AAUTCNMI has A solicited DSRBS and 0 are in use
Figure 19. Example of Output from the NLDM Command
NPDA output
Figure 20 on page 91 shows an example of the hardware monitor output from IPCS when you run the
CNMIPCS routine with the NPDA command:
VERBX CNMIPCS 'NPDA'
Instead, you can select NPDA information on the main menu.

The following symbols are set if they are found:
BNTVB
Contains the address of BNJDSERV's TVB
BNTIB
Contains the address of BNJDSERV's TIB
BNJTACR
Contains the address of control block BNJTACR for task BNJDSERV
BNJTDIR
Contains the address of control block BNJTDIR for task BNJDSERV
BNJTDSTF
Contains the address of control block BNJTDSTF for task BNJDSERV
Figure 20 on page 91 shows an example of the output when you run the CNMIPCS routine with the
NPDA command.

Hardware Monitor
BNJTDIR address 936F030 BNJTDSTF address 936F134
PURGE NOT IN PROGRESS

REPORTS FUNCTION ON
RATE VALUE IN SECONDS: 1
DBFULL VALUE: 0 DBFULL COUNTER: 0
Alert Control Records
OPER DOMAIN REL FLAG LAST ACK USE SENT FILT

C45108 NRAM5 64 10 773461B2 773461B3 01 00001DCE 00000000
PRIMARY ALERT QUEUE

DSRB HEAD COUNT PROCESSING SEQUENCE WRAP
0010C158 0D7BF850 0000000D 0D7BF030 773461B1 00C8
SECONDARY ALERT QUEUE

DSRB HEAD COUNT PROCESSING SEQUENCE WRAP
00000000 00000000 00000000 00000000 00000000 0000
TIDOST pointer 0 TIDPPT pointer 0
BNJDSERV has 5 unsolicited DSRBS and 0 are in use
BNJDSERV has 5 solicited DSRBS and 3 are in use
Figure 20. Example of Output from the NPDA Command
Message queue output

QUE command with the default option of ACTIVE:
VERBX CNMIPCS 'QUE'

VERBX CNMIPCS 'QUE(ACTIVE)'
Instead, you can select Task message queue information on the main menu. If you do that, the Task
Selection panel is displayed so that you can select the active TVBs or any subset of tasks.
Field
Description
a
The TVB address.
b
The operator ID (task name) of the task.
c
TVBMPUBQ - The number of messages on the TVB public message queue.
d
TVBMPUBH - The number of messages on the TVB high priority public queue. The data services tasks
(DSTs) high priority message queue is the TIDOSTQ. TVBMPUBH is not used by DSTs.
e
TVBMPUBL - The number of messages on the TVB low priority public queue. The data services tasks
(DSTs) low priority message queue is the TIDPPTQ. TVBMPUBL is not used by DSTs.
f
TVBMPRIQ - The number of messages on the TVB private message queue.
g
TVBMPRQH - The number of messages on the TVB high priority private queue.
h
TVBMPRQL - The number of messages on the TVB low priority private queue.

a b c d e f g h
TIDOSTQ TIDPPTQ
TVB OPID TVBMPUBQ TVBMPUBH TVBMPUBL TVBMPRIQ TVBMPRQH TVBMPRQL
1B6E0 NTV90PPT 0 0 0 0 0 0
25E00 DSIMONIT 0 0 0 0 0 0
25C00 DSITIMMT 0 0 0 0 0 0
97080 NETOP1 0 0 0 0 0 0
76E00 CNMTAMEL 0 0 0 0 0 0
Figure 21. Example of Output from the IPCS QUE Command
Note: Some queues apply only to certain tasks. These special queues are displayed under the task to
which they apply if they have any items on the queues.
Save area output

The SAVEAREA command and the SAVEAREA trace selection on the main menu run the SAVEAREA chain
backward, forward, and then forward again using the initial SAVEAREA.Figure 22 on page 92 shows an
example of the IPCS output when you run the CNMIPCS routine with this SAVEAREA command:
VERBX CNMIPCS 'SAVEAREA(X''06BA2580'')'
FOLLOWING +4 POINTER BACKWARDS
S/A 06BA2580
R14= DSIQTSKI 2009.096 +0E48 TIVNV63 R15=
00000000 BAC 06BA2060 FOR 06A54938 R14 8655FBC8
R15 00000000 R0 06BA2610 R1 06A548F8 R2 00000000
R3 00000000 R4 06A54A4C R5 00114F08 R6 00040250
R7 00006DC8 R8 06BA2100 R9 000060C8 R10 06560D7E
R11 0655FD7F R12 0655ED80
S/A 06BA2060
R14= DSIQTSK 2009.096 +0258 TIVNV63 R15=DSIQTSKI 2009.096 +0000 TIVNV63
00000000 BAC 000372B0 FOR 06BA2580 R14 8655AB40
R15 0655ED80 R0 06BA2466 R1 06BA20F0 R2 00000001
R3 00040250 R4 00000000 R5 000060C8 R6 00040250
R7 00006DC8 R8 00000000 R9 06BA2100 R10 06BA2108
R11 0655B8E7 R12 8655A8E8
Figure 22. Example of Output from the SAVEAREA Command
Storage counter output

Figure 23 on page 93 shows an example of the IPCS output when you run the CNMIPCS routine with this
STORE command using the default option of ACTIVE:
VERBX CNMIPCS 'STORE'

VERBX CNMIPCS 'STORE(ACTIVE)'
Instead, you can select Task storage counters on the main menu. If you do that, the Task Selection panel
is displayed so that you can select the active TVBs or any subset of tasks.
Field
Description
a
The TVB address.
b
The operator ID or task name of the task.
c
TVBCUPOL is the amount of queued cell-pool storage in use by this task.
d
The amount of queued non-cell pool storage in use by this task.

e
The amount of non-queued storage in use by this task. This value is directly affected by the storage
management techniques for this task, and might be inaccurate (or even negative). This value is not to
be used as an indication of an error, but can be of value when viewed in the light of other storage
values. The sum of all the TVBGUSTR values for all the active tasks does not reflect the total of all
non-queued storage in use by the NetView program.
f
The number of items on the public message queues for this task.
a b c d e f
OPID TVBCUPOL TVBCUSTR TVBGUSTR TVBQCNT
TVB 5968 SYSOP 6FFA 0 10A20D 0
TVB 4B918 C01NVPPT 10FF3 E828 B9C0 1
TVB 21E00 DSIDCBMT 0 0 C00 0
TVB 21C00 DSIHLLMT 0 0 C00 0
TVB 21A00 DSISTMMT 0 0 C00 0
TVB 21800 SYSOP 0 0 C00 0
TVB 21600 C01NV 0 0 276C 0
TVB 21400 DSILOGMT 0 9C CA8 0
TVB 4BB10 DSILOG 4FFB 1F28 1800 0
TVB 4BD08 DSICRTR 3FFC 284A 18C8 0
TVB 4BF00 DSITRACE 2FFD 1F28 1800 0
TVB 4C0F8 CNMCSSIR 2FFE 0 23E0 0
TVB 4C2F0 CNMCALRT 0 0 EA6 0
TVB 4C4E8 DSISVRT 7FF9 12DE6 1800 0
TVB 4C6E0 DSIGDS 8FF8 284A 1800 0
TVB 4C8D8 DSIAMLUT 3FFC 1D3C 1BB0 0
TVB 4CAD0 BNJDSERV DFF5 FA92 3210 0
TVB 4CCC8 BNJMNPDA 0 6000 C00 0
TVB 4CEC0 C01NVLUC 4FFB 2ED4 9281 0
TVB 4D0B8 C01NVVMT 6FF9 3355 17419 0
TVB 4D2B0 C01NVBRW 1FFE 0 C00 0
TVB 4D4A8 DSIUDST 2FFD 2E12 1800 0
TVB 4D6A0 CNMTAMEL 31FE3 54A04 1E566 B
TVB 4D898 DSI6DST 6FF9 4E12 5FE0 0
TVB 4DA90 DSIHPDST 3FFC 4E12 1800 0
TVB 4E270 DSIROVS 1FFE 247A 1800 0
TVB 4E468 DSIELTSK FFF 2C2A 1800 0
TVB 4E660 AAUTSKLP 14FF3 13523A 8214 0
TVB 4E858 AAUTCNMI 7FF9 1F3A6 1800 0
TVB 4EC48 DSIKREM 1FFE 3956 1800 0
TVB 4F038 DSIQTSK 4FFC 1000 2A00 0
TVB 4F230 DUIFSSCO 2FFD 0 3146 0
TVB 74010 KATHI2 19FF1 10038 CA51 0
TVB 21200 AUTO1 13FF3 E848 4934 0
TVB 21000 AUTO2 7FF9 0 D24 0
TVB 22080 DUIFEAUT 6FFA 0 9282 0
TVB 25080 DUIFCSGW BFF5 0 F53 0
TVB 5B080 DBAUTO1 FFF4 E828 4AD8 0
TVB 5C010 DBAUTO2 FFF4 E828 47F4 0
TVB 5D010 SSMMON 13FF3 28B5C 299A 0
TVB 60010 AUTONET 17FF2 FFB8 2504 0
TVB 646D0 KATIE EFF5 E828 D24 0
TVB 644D0 ALEX 7FF9 0 D24 0
TVB 642D0 ROB 7FF9 0 D24 0
TVB 640D0 MARYANNE 7FF9 0 D24 0
TVB 67010 SADIE 7FF9 0 D24 0
TVB 736D0 THOMAS AFF6 E828 D24 0
TOTALS 1A0EC1 29AA6F 1BA243 C
Figure 23. Example of Output from the IPCS STORE Command
Automation table use count output

Figure 24 on page 94 shows an example of the automation table use count information you receive from
the CNMIPCS routine when you run IPCS with the following TBLUSECT command:
VERBX CNMIPCS 'TBLUSECT'
Instead, you can select Auto table usage on the main menu.

AUTOMATION TABLE
MESSAGE TABLE
SEQ# HIT COUNT COMPARE COUNT
PN10969 00000000 00000076
PN10969 00000000 00000076
04410IMS 00000000 00000076
PN10969 00000000 00000076
Figure 24. Example of Output from IPCS TBLUSECT Command
Trace output
The following symbols are set if the NetView internal trace is found:
TRACHEAD
Contains the address of the trace table header.
TRACETOP
Contains the address of the first trace table entry.
TRACENXT
Contains the address of the next available entry in the trace table.
TRACEBOT
Contains the address of the last trace table entry.
Figure 25 on page 94 shows an example of the output you receive from the CNMIPCS routine when you
run IPCS with a select option as in the following TRACE command, which can narrow your selection to a
specific TVB:
VERBX CNMIPCS 'TRACE trtvb(x"7F080")'
Instead, you can select NetView Internal Trace on the main menu. If you do that, the Trace Option
Selection panel is displayed where you must choose one or more trace options, and then the Task
Selection panel is displayed so that you can select the active TVBs or any subset of tasks.
Trace table is in data space : CNMTRACE

Address of trace table header : 1000
Address of TOP of trace table : 1040
Address of NEXT available entry : 6EC160
Address of BOTTOM of trace table: FA0FE0
Time of LAST ENTRY 16:41:00

Time of LAST WRAP 00:00:00
Time of PREVIOUS WRAP 00:00:00
Number of trace pages: 4000
00001040 GET RC00 DSIITMSG 09.093 +01E8 TIVNV63 RET=8DB0DE40 TVB=0007F080

STOR 0DE204B0 AMT 000000E6 SP 0 MQ
00001060 TIME DATE=April 10, 2009 Time=13:22:20.079933
00001080 GET RC00 DSIMOM 09.093 +1026 TIVNV63 RET=8D86A23E TVB=0007F080

STOR 0DB63850 AMT 000000C5 SP 0 M
000010A0 GET RC00 DSIMOM 09.093 +1D9C TIVNV63 RET=8D86AFB4 TVB=0007F080

STOR 0DB54DA8 AMT 00000100 SP 0 M
Figure 25. Example of Output from IPCS TRACE Command Using a Select Option
Figure 26 on page 95 shows the output from the CNMIPCS routine when you run IPCS with this TRACE
command using a trace option:
VERBX CNMIPCS 'TRACE (SUM)'

Trace table is in data space : CNMTRACE
Address of trace table header : 1000
Address of TOP of trace table : 1040
Address of NEXT available entry : 6EC160
Address of BOTTOM of trace table: FA0FE0
Time of LAST ENTRY 16:41:00

Time of LAST WRAP 00:00:00
Time of PREVIOUS WRAP 00:00:00
Number of trace pages: 4000
TVB ADDR COUNT OPID LU

1A6E0 2ED1 NTVD1PPT NTVD1PPT
24E00 673 DSIMONIT DSIMONIT
24C00 1EE2 DSITIMMT DSITIMMT
24A00 266 DSIDCBMT DSIDCBMT
6BCA0 BFC DSILOG DSILOG
7F080 194 OPER1 NTD1L702
Figure 26. Example of Output from IPCS TRACE Command Using a Trace Option
Identify storage output

The WHO command determines if a specified address is a module or control block. Figure 27 on page 95
shows an example of the IPCS output when you run the CNMIPCS routine with this WHO command:
VERBX CNMIPCS 'WHO(X''11A68'')'
Instead, you can select the Find module/control block name on the main menu.
a b c d e f g h
LMOD LMOD ENT LMOD END CSECT ADDRESS OFFSET DATE PTF LEVEL
DSIZVINT 00010E20 00018FFF DSIZVEDS 00011A60 +0008 09.102 TIVNV63
Figure 27. Example of Output from the WHO Command

Field
Description
a
Load module name
b
Starting address of load module
c
Ending address of load module
d
CSECT name
e
Starting address of CSECT
f
Offset of address entered into CSECT
g
Date in CSECT
h
PTF level in CSECT
Note: If no CSECT name is found in the load module, the CSECT column entry contains the load module
name, the ADDRESS column entry contains zeros, and the DATE column entry contains the abbreviation
LMOD.

Common global variables output
Figure 28 on page 96 shows an example of the IPCS output when you select Common global variables
on the main menu. This function, which displays all the common global variables and their values, is not
available with a command-line verb.
Variable name: CNMSTYLE.NLDM.SESSMAX

Variable value: 999
Variable name: CNMSTYLE.NLDM.SAWSIZE

Variable value: 4K
Variable name: CNMSTYLE.NLDM.SAWNUM

Variable value: 2
Variable name: DUIFHPRC

Variable value: CNMGMFHS
Variable name: CNMSTYLE.NLDM.MAXEND

Variable value: 5
Variable name: CNMSTYLE.LUC.PERSIST

Variable value: YES
…
Figure 28. Example of Common Global Variables Output
Task global variables output

Figure 29 on page 96 shows an example of the IPCS output when you select Task global variables on
the main menu. This selection, which displays all the global variables and their values for one or more
tasks, is not available with a command-line verb. When you select this item, the Task Selection panel is
displayed so that you can select the active TVBs or any subset of tasks. In the example, an operator ID of
AUTO1 was specified on the Task Selection panel.
Global variables for opid AUTO1 TVB=00079080
Variable name: EXCEPTOP.2

Variable value: AUTO1

Variable value: OPER1

Variable value: 2
Variable name: EXCEPTAUTO

Variable value: ALL
Variable name: CNMIDLETID

Variable value: IDLEOFF
Figure 29. Example of Task Global Variables Output
Network log with CMDMON, TASKUTIL or TASKMON command output

Except for some full-screen activities, the network log is a record of all operator station activity, including
commands entered and messages received. The network log can also record the output of the CMDMON,
TASKUTIL or TASKMON command. Use the network log to correlate operator console activities with other
events in the network. Figure 30 on page 97 is an example of the printed network log.

N E T V I E W PRINT LOG/TRACE UTILITY
08/18/19 1
******** 08/18/19 NTV90 N 13:11:54 * N E T V I E W DISK LOG
NETOP1 13:11:55 - DSI556I DSILOG : VSAM DATASET 'OPEN' COMPLETED, DDNAME = 'DSILOGS'
RETURN CODE = X'00', ACB ERROR FIELD = X'00'
13:11:55 - DSI547I DSILOG : SECONDARY VSAM DATA SET IS NOW ACTIVE
13:11:55 - DSI556I DSILOG : VSAM DATASET 'CLOSE' COMPLETED, DDNAME =
'DSILOGP'
13:11:55 - DWO520I DSILOG : VSAM DATASET 'CLOSE' COMPLETED, DDNAME =
'DSILOGP'
LU32706 13:12:20 DSI022A INVALID PASSWORD, REENTER
NETOP1 NTV90 % 13:12:20 - DSI029I INVALID LOGON ATTEMPT FROM TERMINAL LU32706, ERROR IN
THE 'PASSWORD' FIELD
LU32706 NTV90 13:12:25 DSI022A INVALID PASSWORD, REENTER
NETOP1 NTV90 % 13:12:25 - DSI029I INVALID LOGON ATTEMPT FROM TERMINAL LU32706, ERROR IN
THE 'PASSWORD' FIELD
OPER2 NTV90 13:12:34 - DSI020I OPERATOR OPER2 LOGGED ON FROM TERMINAL LU32706
USING PROFILE (DSIPROFA), HCL ( )
13:12:45 * AUTOWRAP
13:12:45 DSI082I AUTOWRAP STARTED
13:13:12 * TASKUTIL
13:13:14 ' DWO022I
13:13:14 ' TASKNAME TYPE DPR CPU-TIME N-CPU% S-CPU% MESSAGEQ STORAGE-K
CMD
13:13:14 ' -------- ---- --- ----------- ------ ------ -------- ---------
--------
13:13:14 ' OPER2 OST 251 0.04 66.83 0.13 0 73
**NONE**
13:13:14 ' DSITIMMT OPT 255 0.01 9.77 0.02 N/A
4 N/A
13:13:14 ' DSILOG DST 254 0.10 6.86 0.01 0
26 N/A
13:13:14 ' CNMCSSIR OPT 250 0.01 3.99 0.01 0
11 N/A
13:13:14 ' DSIDCBMT OPT 255 0.18 0.00 0.00 N/A
3 N/A
13:13:14 ' DSIHLLMT OPT 255 0.01 0.00 0.00 N/A
7 N/A
13:13:14 ' DSISTMMT OPT 255 0.00 0.00 0.00 N/A
7 N/A
13:13:14 ' SYSOP OPT 255 0.00 0.00 0.00 N/A
7 N/A
13:13:14 ' NTV90 OPT 255 0.01 0.00 0.00 N/A
9 N/A
13:13:14 ' DSILOGMT OPT 255 0.02 0.00 0.00 N/A
8 N/A
13:13:14 ' NTV90PPT PPT 255 0.05 0.00 0.00 0 122
**NONE**
13:13:14 ' DSICRTR DST 249 0.01 0.00 0.00 0
33 N/A
13:13:14 ' DSIMONIT OPT 255 0.02 0.00 0.00 N/A
4 N/A
13:13:14 ' CNMCALRT OPT 249 0.00 0.00 0.00 N/A
3 N/A
13:13:14 ' BNJDSERV DST 249 0.04 0.00 0.00 0
84 N/A
13:13:14 ' NTV90BRW OPT 250 0.00 0.00 0.00 0
11 N/A
13:13:14 ' NETOP1 OST 251 0.60 0.00 0.00 0 166
**NONE**
13:13:14 ' MNT MNT 255 0.00 0.00 0.00 0
4752 N/A
13:13:14 ' AUTO1 AUTO 250 0.02 0.00 0.00 0 39
**NONE**
13:13:14 ' AUTO2 AUTO 250 0.04 0.00 0.00 0 102
**NONE**
13:13:14 ' NETVIEW OTHR N/A N/A 0.00 0.00 N/A
N/A N/A
13:13:14 ' NETVIEW SRB N/A 0.45 12.56 0.02 N/A
N/A N/A
13:13:14 ' NETVIEW TOTL 33 2.75 100.00 0.20 0
5471 N/A
13:13:14 ' SYSTEM TOTL N/A N/A N/A 8.28 N/A
N/A N/A
13:13:14 ' END DISPLAY
13:13:17 * NPDA
13:13:19 " N E T V I E W SESSION DOMAIN: NTV90 OPER2 08/18/19
13:13:17
13:13:19 " NPDA-01A * MENU * HOST
DOMAIN: NTV90
13:13:19 " SEL# PRODUCES:
13:13:19 " ( 1) ALERTS-DYNAMIC DISPLAY
13:13:19 " ( 2) TOTAL EVENTS DISPLAY
13:13:19 " ( 3) TOTAL STATISTICAL DATA DISPLAY
Figure 30. Example of a Printed Network Log

Network log data format
Figure 31 on page 98 shows the format of the network log data in the DSILOGP or DSILOGS file.
Figure 31. Format of a Network Log in Storage

The CMDMON, TASKUTIL or TASKMON command IBM Z NetView Command Reference Volume 1 (A-N)
or NetView online help
Using MSGMODID to identify message origin

If additional diagnostic information is needed, the MSGMODID option enables you to gather additional
information from six messages:
• DSI000I
• DSI030I
• DSI064A
• DSI065I

• DSI121I
• DSI476I
Do not suppress these messages with NetView automation.
Turn on the MSGMODID option using the DEFAULTS command with MSGMODID=YES. The message
DSI799I is written to the network log using DSIWLS. This message provides the following:
• The original error message number
• The name of the module that issued the original message
• The occurrence within the module (necessary when the module issues a message more than once)
The following example shows the format of message DSI799I:
DSI799I DSI030I DSISHPCL 03

Message DSI799I Online message help
The DEFAULTS command NetView online help
Identifying message origin when printing Canzlog data

Many NetView messages carry information that identifies the code location where the message
originated. To see this information, add the detail ID MOD to a class statement in your NetView style
definitions. Detail classes are defined by a CZ.DETAIL statement. For more information about detail
classes, see the IBM Z NetView Administration Reference. For supported messages, this setting causes the
printed detail to include a module name and a number that is useful when a module issues messages
from multiple points.
SMF Log Record 38 Subtype 2 task utilization data

The NetView program writes these records when a task ends, at other events, and at user request (for
example, the LOGTSTAT command).
These records can be viewed using TASKURPT, or you can use a standard SMF reporting tool to format
the records. These records give you many NetView task resource usage statistics, such as CPU, I/O,
storage, message queueing rates, and amount of penalty time assessed. Use these statistics when a loop
condition, storage outage, or other performance problems are evident.
SMF Log Record 38 Subtype 4 command statistics data
Operators can enable the NetView program to write command statistics data into z/OS SMF records.
These records give you many resource usage statistics of each NetView command or procedure, such as
command name, CPU, storage, I/O, etc. These records contain SMF records type 38 subtype 4, and can
be viewed with a standard SMF reporting tool. Use these statistics when a loop condition, storage outage,
or other performance problems are evident. You can figure out how the resource is consumed by every
NetView command and procedure at time interval basis. Furthermore, you can check them along with
other SMF or RMF data to discover system activities with performance issues. For more information, see
IBM Z NetView Command Reference Volume 1 (A-N) and the CMDMON command in the IBM Z NetView
Administration Reference.

NetView trace
NetView trace captures the sequence of internal processing. The trace provides information you can use
in resolving NetView problems and user errors. The trace also provides records of key problem
determination data such as parameter values, addresses, return codes, and flag settings. Trace output
can be recorded internally in virtual storage, externally in the DSITRACE data sets, or to the generalized
trace facility (GTF).
Keep the NetView internal trace active at all times. This can slightly degrade system performance, but
having the trace on at all times is important in diagnosis. Use the default options as shown in the following
example:
OPTIONS=(DISP,PSS,QUE,STOR,UEXIT)
You can dynamically specify the events to be traced using the TRACE command. Use the trace with
available service aids, such as the network log and a memory dump, to assist in resolving a problem.
Using NetView trace

The TRACE command initiates a sequence trace that records a sequence of NetView processing steps,
either in virtual storage, on DSITRACE, or to GTF. This can help you solve problems you might encounter
using the NetView program.
Use NetView trace to identify the source of command facility problems or user errors, and to provide
information useful for resolving these problems.
You can also set up the trace function to pursue a specific problem. If you suspect trouble with an
installation exit, be sure to specify the UEXIT option in the TRACE command. If you suspect that you are
in a loop or a wait, or if an abend occurs, be sure to specify the MOD and DISP options in the TRACE
command.
The MOD option usually results in many trace entries. If you run the MOD trace option, use it only for a
short time to trap specific data.
• When you run the trace internally (MODE=INT), entries wrap quickly if you specify a small storage size.
INT is the default.
• When you run the trace externally (MODE=EXT), it can use additional storage. Also, the DSITRACE data
sets (primary and secondary) must be large enough to provide adequate storage.
• When you run the trace to the generalized trace facility (MODE=GTF), trace record formats might be
different.
You can restrict use of the TRACE command by limiting which operators can use it.

Defining command authorization IBM Z NetView Administration Reference
The NetView TRACE command NetView online help
The generalized trace facility (GTF) z/OS MVS Diagnosis: Tools and Service Aids
Location of GTF trace information “Generalized Trace Facility (GTF) Output Files” on
page 156
Locating the trace when MODE=INT is specified

Specifying MODE=INT on the TRACE command, TRACE.MODE=INT in the CNMSTYLE member, or having
trace start at early initialization means that the trace records are written in an internal trace table in a
dataspace named CNMTRACE. If the CNMTRACE dataspace was dumped, you can examine the records by
displaying or dumping the storage locations of the trace table from the dataspace.
You can use IPCS to view the internal trace table online.

The internal trace table is a wraparound table. The SIZE operand of the TRACE command specifies the
number of pages in storage to be allocated for the table. The default setting is SIZE=4000, although you
can increase this value to the maximum value of 524286, the limit for a dataspace.
Dump system data to locate the in-storage trace table. To locate the trace table in the memory dump, find
the command facility main vector table (MVT) control block. To locate the MVT in a memory dump, use
the following DISPMOD command to locate the entry point of load module DSIMNTEX:
DISPMOD DSIMNTEX
The entry point displayed is the MVT address.

The field MVTITDSI (at offset X'AA8' in the MVT) contains the address of a control block that contains
Internal Trace Dataspace Information (ITDSI). The ITDSI contains the name, token, and ALET of the
dataspace, as well as the size and starting address of the trace table in the dataspace. If this address is
zero (0), the NetView trace is not active or you specified something other than MODE=INT on the TRACE
command.

Using IPCS to view the internal trace table online “Interactive Problem Control System” on page 75
Describing NetView trace records (MODE=INT)

This section contains a description of the entries illustrated in Figure 32 on page 103. Match each of the
entries identified by a letter in the figure to the following corresponding explanations.
A
This is the ITDSI. You can locate it in the memory dump by the eye-catcher ITD.
B
This is the NetView trace table header. This must be the first non-zero area of storage in the
CNMTRACE dataspace. It must begin with the eye-catcher NIT, for the NetView internal trace table.
C
This is a module entry trace record. You can locate it in the memory dump by the eye-catcher MENT.
You obtain this trace record by specifying OPTION=MOD on the TRACE command.
D
This is a wait trace record. You can locate it in the memory dump by the eye-catcher WAT. You obtain
this trace record by specifying OPTION=DISP on the TRACE command.
E
This record traces the getting of storage. You can locate it in the memory dump by the eye-catcher
GET. You obtain this trace record by specifying OPTION=STOR on the TRACE command.
F
This is a module exit trace record. You can locate it in the memory dump by the eye-catcher MXIT.
G
This is an installation exit trace record. You can locate it in the memory dump by the eye-catcher UX.
You obtain this trace record by specifying OPTION=UEXIT on the TRACE command.
H
This record traces the freeing of storage. You can locate it in the memory dump by the eye-catcher
FRE. You obtain this trace record by specifying OPTION=STOR on the TRACE command.
I
This is a presentation services trace record. You can locate it in the memory dump by the eye-catcher
PSS. You obtain this trace record by specifying OPTION=PSS on the TRACE command.

J
This record traces the intertask queuing of buffers using DSIMQS. You can locate it in the memory
dump by the eye-catcher MQS. You obtain this trace record by specifying OPTION=QUE on the TRACE
command.
K
Indicates that DSIPOS was run to post an ECB. You can locate it in the memory dump by the eye-
catcher POS. You obtain this trace record by specifying OPTION=DISP on the TRACE command.

NetView trace records “Trace record descriptions” on page 108
NetView trace record example (MODE=INT)

Figure 32 on page 103 is an example of trace output printed from virtual storage.

0D8CBEA0 C9E3C400 0000002F 0101001E 00001000 | ITD............. | A
0D8CBEB0 80000B02 0000003D C3D5D4E3 D9C1C3C5 | ........CNMTRACE |
0D8CBEC0 00000FA0 04F4F0F0 F0404040 404040F0 | .....4000 0 |
00001000 D5C9E300 00FA0000 00000000 1558400C | NIT........... . | B

00001010 1450400C 1438590C 00000000 00DA05A0 | .&. ............ |
00001020 00FA0FE0 00000000 00000000 00000000 | .O. ............ |
00001030 D4E7C9E3 82A6D6F2 00037610 00000000 | MXITBWO2........ |
00001040 000AB924 8000E70E C4E2C9C5 D3E2D4C6 | .. ...X.DSIELSMF |
00001050 D4C5D5E3 8275F640 00037610 000A8764 | MENTB.6 ......G. | C
00001060 000A8774 8283CFAE C4E2C9C6 D4D54040 | ..G.BC. DSIFMN |
•
•
•
000020B0 D4C5D5E3 827493D0 000379B8 00064764 | MENTB.L .. .... |
000020C0 00064774 82834324 C4E2C9E6 C1C9E340 | ....BC..DSIWAIT |
000020D0 E6C1E340 82834324 000379B8 00099380 | WAT BC.... ..L. | D
000020E0 00000000 00000000 C4E2C9C1 D4D3E4E3 | ........DSIAMLUT |
000020F0 D4C5D5E3 82760208 00036C50 0001A6F4 | MENTB.....%&;.W4 |
00002100 0001A704 80051678 C4E2C9C7 D4D54040 | ..X.....DSIGMN |
00002110 C7C5E300 80051678 00036C50 00000000 | GET.......%&;... | E

00002120 02AF8080 00000064 00000000 C200D4D8 | . ..........B.MQ |
00002130 D4E7C9E3 82760614 00036C50 00000000 | MXITB.....%&;... | F
00002140 0001A704 80051678 C4E2C9C7 D4D54040 | ..X.....DSIGMN |
00002150 E4E7000B 827A9C26 00036C50 027E7E00 | UX..B: ...%&;==. | G
00002160 82AD94F8 02AF80C8 C3D5D4F1 F9D7D7E3 | B M8. .HCNM19PPT |
00002170 003E009C 007D0018 1450410C C3D5D4F1 | ... .'...&;.CNM1 |
00002180 F9404040 00400558 C9E2E3F6 F6F4C940 | 9 . ..IST664I |
00002190 40D9C5C1 D34040D6 D3E47ED5 C5E3C34B | REAL OLU=NETC. |
000021A0 C3D5D4F0 F1D3E4C3 40404040 404040D9 | CNM01LUC R |
000021B0 D4C5D5E3 82AD94F8 00036C50 02AF80C8 | MENTB M8..%&; .H |
000021C0 02AF8080 80051B12 C3D5D4E7 D2E5D4E2 | . ......CNMXKVMS |
000021D0 D4E7C9E3 82AD987A 00036C50 00000000 | MXITB Q:..%&;... |
000021E0 02AF8080 80051B12 C3D5D4E7 D2E5D4E2 | . ......CNMXKVMS |
000021F0 D4C5D5E3 8275F640 00036C50 0001A6F4 | MENTB.6 ..%&;.W4 |
00002200 0001A704 80051E30 C4E2C9C6 D4D54040 | ..X.....DSIFMN |
00002210 C6D9C500 80051E30 00036C50 00000000 | FRE.......%&;... | H
00002220 02AF8080 00000000 80051678 8000D4D8 | . ............MQ |
00002230 D4E7C9E3 8275FB26 00036C50 00000000 | MXITB.....%&;... |
00007240 0001A704 80051E30 C4E2C9C6 D4D54040 | ..X.....DSIFMN |
00007250 D7E2E240 827A9F78 00036C50 027E7E00 | PSS B: ...%&;==. | I
00007260 02000800 00000000 C3D5D4F1 F9D7D7E3 | ........CNM19PPT |
•
•
•
00002690 D4D8E240 82EE718A 00037748 02FB03A0 | MQS B.......... | J
000026A0 C4E2C9C1 D4D3E4E3 C1C1E4E3 E2D2D3D7 | DSIAMLUTAAUTSKLP |
000026B0 003800D0 00C90024 00000000 C3D5D4F1 | ... .I......CNM1 |
000026C0 F9404040 00000000 00000000 C1C1E4E3 | 9 ........AAUT |
000026D0 E2D2D3D7 0003C4E2 C9D3E4C9 E3C64040 | SKLP..DSILUITF |
000026E0 02010000 00000000 00000000 C9E2E3D7 | ............ISTP |
000026F0 D4C5D5E3 8276E098 00037748 02F14544 | MENTB. Q.....1.. |
00002700 02F1444C 82729DFC C4E2C9D7 D6E2E340 | .1.<B. .DSIPOST |
00002710 D7D6E240 82729DFC 00037748 000379D8 | POS B. ....... Q | K
00002720 00000000 00000000 C1C1E4E3 E2D2D3D7 | ........AAUTSKLP |
Figure 32. NetView Trace Records in memory dump output (MODE=INT)
Printing the trace when MODE=EXT is specified

NetView trace records can be recorded externally in the DSITRACE data sets (MODE=EXT). The trace
records written to the trace log contain the same information as records written in internal storage.
You can use the command facility utility program DSIPRT to print the trace data from the trace log. You
can also use CNMPRT, which contains the job control language (JCL), to print the trace log.
Description of NetView trace records (MODE=EXT)

This section contains a description of the entries illustrated in Figure 33 on page 105. Match each of the
entries identified by a letter in the figure to the following corresponding explanations.
L
This record traces the getting of storage. You can locate it in the memory dump by the eye-catcher
GET. You obtain this trace record by specifying OPTION=STOR on the TRACE command.

M
This record traces the intertask queuing of buffers using DSIMQS. You can locate it in the memory
dump by the eye-catcher MQS. You obtain this trace record by specifying OPTION=QUE on the TRACE
command. If the buffer entry represents a chain of buffers, the trace entry is repeated for each buffer
in the chain.
N
This is a module entry trace record. You can locate it in the memory dump by the eye-catcher MENT.
O
This record traces the freeing of storage. You can locate it in the memory dump by the eye-catcher
FRE. You obtain this trace record by specifying OPTION=STOR on the TRACE command.
P
This is a wait trace record. You can locate it in the memory dump by the eye-catcher WAT. You obtain
this trace record by specifying OPTION=DISP on the TRACE command.
Q
This is a module exit trace record. You can locate it in the memory dump by the eye-catcher MXIT.
R
This is a presentation services trace record. You can locate it in the memory dump by the eye-catcher
PSS. You obtain this trace record by specifying OPTION=PSS on the TRACE command. If the buffer
entry represents a chain of buffers, the trace entry is repeated for each buffer in the chain.
S
This is an installation exit trace record. You can locate it in the memory dump by the eye-catcher UX.
You obtain this trace record by specifying OPTION=UEXIT on the TRACE command. If the buffer entry
represents a chain of buffers, the trace entry is repeated for each buffer in the chain.
T
Indicates that DSIPOS was run to post an ECB. You can locate it in the memory dump by the eye-
catcher POS. You obtain this trace record by specifying OPTION=DISP on the TRACE command.

NetView trace records “Trace record descriptions” on page 108
NetView Trace record example (MODE=EXT)

Figure 33 on page 105 is an example of trace output printed in the trace log.

N E T V I E W PRINT LOG/TRACE UTILITY 08/18/19
MXITTA2.*...Q............DSIFMN
DSILOG 08/18/19 NCAB 12:48:55 L MENT D4C5D5E3 81F216C8 00069BD8 0009ED14 0009ED24 81F2B3FE C4E2C9C7
D4D54040
MENTA2.H...Q........A2..DSIGMN
L 12:48:55 L GET. C7C5E300 81F2B3FE 00069BD8 00000000 02297410 00000070 00000000
4100D440
GET.A2.........Q..............M
12:48:55 L MXIT D4E7C9E3 81F21CA4 00069BD8 00000000 0009ED24 81F2B3FE C4E2C9C7
D4D54040
MXITA2.U...Q........A2..DSIGMN
M 12:48:55 L MQS D4D8E240 81F04EEC 00069BD8 02297410 C4E2C9D3 D6C74040 E5C1D340
40404040
MQS A0+....Q....DSILOG VAL
004C0070 00C90024 1248550C D5C3C1C2 40404040 00000000 00000000
E5C1D340
.<...I......NCAP ........VAL
40404040 00100086 086F1248 550C0000 00000000 00000032 404ED5C3
C1C2F0F0
...F.?.............. +NCAB00
N 12:48:55 L MENT D4C5D5E3 81F32518 00069BD8 0009ED14 0009ED24 81F28FD8 C4E2C9D7
D6E2E340
MENTA3.....Q........A2.QDSIPOST
DSILOG 12:48:55 L DISP C4C9E2D7 82D80618 00067270 80067290 40000000 00000000 C4D2C9D3
D6C74040
DISPB........... .......DSILOG
12:48:55 L MXIT D4E7C9E3 81F49906 00067270 806D96D8 0001075C 82080618 C4E2C9E6
C1C9E340
MXITA4R0....._OQ..P*B...DSIWAIT
12:48:55 L MENT D4C5D5E3 81F21058 00067270 0001D74C 0001075C 80072EDE C4E2C9C6
D4054040
MENTA2........P<..P*....DSIFMN
O 12:48:55 L FRE. C6D9C500 80072EDE 00067270 00000000 0005F8B0 000000F4 8007299C
8000D4D8
FRE...............8....4......MQ
12:48:55 L MXIT D4E7C9E3 81F2165C 00067270 00000000 0001D75C 80072EDE C4E2C9C6
D4054040
MXITA2.*..........P*....DSIFMN
12:48:55 L MXIT D4E7C9E3 82084854 00067270 00000000 0001D40C 82080AB8 C4E2C9E6
D3D4D7E3
MXITB.............M.B...DSIWLMPT
12:48:55 L MENT D4C5D5E3 81F497B0 00067270 0001D74C 0001D75C 82080618 C4E2C9E6
C1C9E340
MENTA4P.......P<..P*B...DSIWAIT
P 12:48:55 L WAT E6C1E340 82080618 00067270 00016A70 00000000 00000000 C4E2C9D3
D6C74040
WAT B...................DSILOG
12:48:55 L DISP C4C9E2D7 82080618 00067270 000169D0 40000000 00000000 C4E2C9D3
D6C74040
DISP............ .......DSILOG
Q 12:48:55 L MXIT D4E7C9E3 81F49906 00067270 00019080 0001D75C 82080618 C4E2C9E6

C1C9E340
MXITA4R0..........P*B...DSIWAIT
12:48:55 L MENT D4C5D5E3 020848D8 00067270 01F6EA40 0001D40C 82080AA6 C4E2C9E6
D3D4C3E3
MENT...Q.....6. ..M.B..WDSIWLMCT
R 12:48:55 L PSS D7E2E240 81F585AA 00067D60 0225F9AC 02000000 00000000 D4C1D9D2
40404040
PSS A5E...'-..9........MARK
00500168 004E0068 1248550C D5C3C1C2 40404040 00000001 0208A080
0208A1E0
.&;..+......NCAB ............
00000000 00000000 0208A080 00021320 00067D60 00019080 00019C60
0225F9A8
..................'-.......-..9Y
12:48:55 L MENT D4C5D5E3 81F216C8 00067D60 000216DC 000216EC 8007299C C4E2C9C7
D4D54040
MENTA2.H..'-............DSIGMN
S 12:48:55 L UX.. E4E700EC 81F4C38C 00067270 0005F930 D5D6D5C5 0005F8F8 C4E2C4D3
D6C74040
UX..A4C.......9.NONE..88DSILOG
004A0070 004E0026 1248550C D5C3C1C2 40404040 00000000 00000000
D4C1D902
. ...+......NCAB ........MARK
40404040 00100086 086F1248 550C0000 01220000 00000032 404ED3F4
F4F14040
...F.?...............+L441
12:48:55 L MENT D4C5D5E3 81F21058 00067270 0001D74C 0001D75C 80072EDE C4E2C9C6
D4D54040
MENTA2........P<..P*....DSIFMN
MARK T 12:48:55 L POS D7D6E240 81F2BFD8 00067D60 00067290 00000000 00000000 D4C1D902
40404040
POS A2.Q..'-............MARK
Figure 33. NetView Trace Records in Trace Log (MODE=EXT)

Describing NetView trace records displayed with the TRACE command MONOPER
keyword
The TRACE command supports a MONOPER keyword that, when specified, directs the NetView program
to display the trace entries at the specified operator task in real time. Refer to the TRACE (NCCF)
description in NetView Command Reference Volume 1 for more information regarding the MONOPER
keyword. Specify the MONOPER keyword only when asked to do so by NetView Service. If used
incorrectly, the MONOPER keyword can cause the NetView program to run out of storage and end
because of too many messages being queued to the monitoring operator task. Therefore, use the
MONOPER keyword with extreme caution. It is a debugging aid, and even when used correctly, its use can
degrade performance.
This section describes some of the entries that can be displayed at the operator task when the MONOPER
keyword has been specified.
Module entry and exit trace entries

The following module entry and exit trace entries are shown as they are displayed at a MONOPER
monitoring operator task. The tokens displayed on each 2-line entry are described in Table 15 on page
113.
' NTVD5
DWO083I MENT BNJDSRBD R1 0EB008C8 TASK BNJDSERV TVB 000766D0 ENT 0D646160
DWO083I R13 0EB00748 R14 8D95C608
' NTVD5
DWO083I MXIT BNJDSRBD RC 00000000 TASK BNJDSERV TVB 000766D0 RET 8D6463CC
DWO083I R13 0EB00748 R14 8D95C608
For comparison, here are module entry and exit trace entries as they are displayed when formatted in a
memory dump by the NetView CNMIPCS IPCS verb exit routine.
0E5E4040 MENT DSIFMN 19.093 +0000 TIVNV63 RET=8D63B8C8 TVB=001410D0

R1/R15 0014355C R13 0014356C R14 8D4B860C DSIFMSGM 19.093
0E5E4080 MXIT DSIFMN 19.093 +03D6 TIVNV63 RET=8D63BC9E TVB=001410D0
R1/R15 00000000 R13 0014356C R14 8D4B860C DSIFMSGM 19.093
Comparison notes:
• The address preceding the MENT and MXIT in the CNMIPCS verb exit trace entries is the address of the
NetView internal trace entry in the internal trace table. The MONOPER tracing is independent of the
type of trace (MODE=INT, EXT, or GTF) that is active, so this address is not displayed in the MONOPER
trace entries.
• The CNMIPCS verb exit trace entries often display a module name, compilation date, and offset that are
not displayed in the MONOPER trace entries.
DSIGET and DSIFRE trace entries

The following DSIGET and DSIFRE trace entries are shown as they are displayed at a MONOPER
monitoring operator task. The tokens displayed on each 2-line entry are described in Table 17 on page
114.
' NTVD5
DWO083I GET RC 00 STOR 0EAFA3A8 AMT 00000169 SP 00 QUE N EXIT M
DWO083I TASK BNJDSERV TVB 000766D0 RET 8D968DA8
' NTVD5
DWO083I FRE RC 00 STOR 0EAFB8A8 AMT 00000128 SP 00 QUE N EXIT M
DWO083I TASK BNJDSERV TVB 000766D0 RET 8D69D782

DSIWAT/DSIPOS/DISPATCH trace entries
The following DSIWAT, DSIPOS, and DISPATCH trace entries are shown as they are displayed at a
MONOPER monitoring operator task. The tokens displayed on each 2-line entry are described in Table 18
on page 115.
' NTVD5
DWO083I POS ECB 000766F0 COMP 00000000 RET 8D59BD04 TVB 0007C080
DWO083I OPERATOR NETOP1
' NTVD5
DWO083I WAT ECB 0EF1D158 COMP 00000000 RET 8D5D0CD8 TVB 0007C080
DWO083I OPERATOR NETOP1
' NTVD5
DWO083I DISP ECB 800766F0 COMP 40000000 RET 8EB35292 TVB 000766D0
DWO083I OPERATOR BNJDSERV
Message Queuing Service (MQS) trace entries

The following MQS trace entry is shown as it is displayed at a MONOPER monitoring operator task. The
tokens displayed for the first two lines of the entry are described in Table 12 on page 111. The remaining
four lines are the first 64 bytes of the buffer being sent.
' NTVD5
DWO083I MQS RET 8D91C4EE TVB 0007C080 FROM NETOP1 TO BNJDSERV
DWO083I BFR 0DD38568 First 64 bytes of buffer:
DWO083I 0000 - 01010128 00C90024 1612280C D5E3E5C4 |**** I *****NTVD|
DWO083I 0010 - F5404040 00000000 00000000 D5C5E3D6 |5 NETO|
DWO083I 0020 - D7F14040 0003C2D5 D1E4D5E2 D6D34069 |P1 *BNJUNSOL |
DWO083I 0030 - 03003E26 D9E50000 0000C2D5 D1C3D5D7 |* **RV BNJCNP|
DSIPSS trace entries

The following DSIPSS trace entry is shown as it is displayed at a MONOPER monitoring operator task. The
tokens displayed for the first two lines of the entry are described in “DSIPSS trace record” on page 115.
The remaining four lines are the first 64 bytes of the buffer being sent.
NTVD5
DWO083I PSS BFR 0DA66268 TYPE 02000000 REPLY 000000 OPER NETOP1
DWO083I RET 8D773AD4 TVB 0007C080 First 64 bytes of buffer:
DWO083I 0000 - 00DC0100 00C90024 1613570C D5E3E5C4 | * I *** *NTVD|
DWO083I 0010 - F5404040 00000000 00000000 D5C5E3D6 |5 NETO|
DWO083I 0020 - D7F14040 00170000 00000000 00000000 |P1 * |
DWO083I 0030 - 00000000 0DA6B5C8 0DA6B5C8 00000000 | *w H*w H |
Installation Exit (UX) trace entries

The following installation exit trace entry is shown as it is displayed at a MONOPER monitoring operator
task. The tokens displayed for the first two lines of the entry are described in Table 14 on page 113. The
remaining four lines are the first 64 bytes of the buffer.
' NTVD5
DWO083I UX02 BFR 0DA6A6E8 XIT NONE DSIUSE 0EF15D68 OPER NETOP1
DWO083I RET 0D7A2108 TVB 0007C080 First 64 bytes of buffer:
DWO083I 0000 - 00540082 00D8002E 1623440C D5E3E5C4 | b Q *** *NTVD|
DWO083I 0010 - F5404040 0000000E 00000000 D5E3E5C4 |5 * NTVD|
DWO083I 0020 - F5D7D7E3 00000000 00000000 0000C9E2 |5PPT IS|
DWO083I 0030 - E3F5F2F6 C94040D9 D6E4E3C5 40C6C1C9 |T526I ROUTE FAI|
Trace entries not currently decoded

Not all trace records are currently recognized and formatted by the MONOPER processing. Trace entries
that are not currently recognized are displayed as shown in the following example:
' NTVD5
DWO089I TASL not currently decoded. The trace record follows:
DWO083I 0000 - E3C1E2D3 8D6A586C 000706D0 00000001 |TASL % **} *|
DWO083I 0010 - 00000000 0DDD396C 00000000 00000000 | * *% |
DWO083I 0020 - 00000000 00000000 00000000 00000000 | |
DWO083I 0030 - 00000000 00000000 00000000 00000000 | |

DWO083I 0040 - 00000000 00000000 00000000 00000000 | |
DWO083I 0050 - 00000000 00000000 00000000 00000000 | |
Trace record descriptions

The following sections contain tables describing the ITDSI, the NetView trace header, and each event
record. These tables show the trace record fields and their offsets. Each trace event entry is in the range
of 32–96 bytes. The trace records can have more than one buffer recorded for message queuing service
(MQS), installation exit (UX), and DSIPSS. Using PSS, QUE, or UEXIT options, you can trace command
buffers, data buffers, and the automation internal function request (AIFR).
The following table is a cross-reference to the various trace record descriptions:
Description: See:
DISPATCH trace record “DSIWAT/DSIPOS/DISPATCH trace record” on
page 114
DSIFRE trace record “DSIGET/DSIFRE trace record” on page 114
DSIGET trace record “DSIGET/DSIFRE trace record” on page 114
DSIMQS trace record “Message Queuing Service (MQS) trace record” on
page 111
DSIPOS trace record “DSIWAT/DSIPOS/DISPATCH trace record” on
page 114
DSIPSS trace record “DSIPSS trace record” on page 115
DSIWAT trace record “DSIWAT/DSIPOS/DISPATCH trace record” on
page 114
Installation exit trace record “Installation Exit (UX) trace record” on page 112
Internal trace dataspace information “Internal trace dataspace information” on page
109
LUC macro invocation trace record “LUC macro invocation trace record” on page 110
LUC receive exit trace record “LUC receive exit trace records” on page 110
Module entry trace record “Module entry and module exit trace record” on
page 113
Module exit trace record “Module entry and module exit trace record” on
page 113
NetView trace table header record “NetView trace table header record” on page 109
SAF trace record “Security Authorization Facility trace record” on
page 140
SNA topology storage request trace record “SNA Topology Manager NetView trace entries” on
page 148
Status monitor internal trace record “Status Monitor internal trace records” on page
138
TCP/IP related trace record “IP Services trace records” on page 117
TIME trace record “TIME trace record” on page 117
VPDTASK trace record “VPDTASK trace record” on page 112

Internal trace dataspace information
The main vector table (MVT) field MVTITDSI offset X'AA8' (decimal 2728) into the MVT points to the
Internal Trace Dataspace Information control block. This control block contains information about the
dataspace in which the trace resides.
Table 7. NetView Internal Trace Dataspace Information Control Block

Hexadecimal Offset Field Meaning
X'00' ITDSI control block eye-catcher = 'ITD'
X'03' Not used (1 byte)
X'04' Length of control block
X'08' ALET of dataspace (4 bytes)
X'0C' Starting address of trace table in dataspace
X'10' Dataspace token (8 bytes)
X'18' Dataspace name (8 bytes)
X'20' Numeric number of pages in trace table
X'24' Number of EBCDIC characters for size (1 byte)
X'25' Number of pages in table, left-aligned EBCDIC
NetView trace table header record

The ITDSI contains information about the name of the trace dataspace and the starting address of the
trace table in the dataspace. The Trace Table Header Record is the first record in the trace table.
The trace table header record contains status information about the trace records. The information
includes the time that the current record was entered, the last two times that the table wrapped, and the
addresses of the current and last entries in the table.
Table 8. NetView Trace Table Header Record

Hexadecimal Offset Trace Record Field
X'00' NetView trace table control block header = NIT
X'03' NetView trace table control block type = X'00'
X'04' Trace table length
X'08' Reserved
X'0C' Time stamp of most recent entry
X'10' Time stamp of most recent wrap
X'14' Time stamp of previous wrap
X'18' Reserved (4 bytes)
X'1C' Address of the next available entry; prior entry is latest entry
X'20' Address of the last entry in trace table
X'24' Reserved 12 characters

LUC macro invocation trace record
The trace record contains the Logical Unit Coverage (LUC) macro invocations. This record also contains
the trace points that are written by DSILCREQ for LUC macro invocations such as Allocate, Deallocate,
Send, or Receive.
Table 9. LUC Macro Invocation Trace Record

X'00' LUC macro trace record ID = "LUC"
X'03' LUC macro trace type:
"A"
= Allocate
"D"
= Deallocate
"S"
= Send
"R"
= Receive
X'04' Resource ID
X'08' Return address of invoking module
8-byte target transaction program name if request is ALLOCATE
X'0C' Request type

X'10' Send options
X'11' Deallocate options
X'12' Send buffer length
8-byte target LU name if request is ALLOCATE
X'14' Send buffer pointer

X'18' Receive buffer pointer
X'1C' Receive buffer length
X'20' First 30 bytes of send data
LUC receive exit trace records

These trace records contain the LUC receive exit invocations. This record also contains the records that
are generated when the LUC receive exit calls DSILCRAS with data that will be returned to an application.
Table 10. LUC VTAM Exit Completion Trace Record

X'00' LUC exit trace record ID = "LUCX"
X'04' Resource ID
X'08' Completion type flags
X'0B' Return code
X'0C' Completion sense codes
X'10' Resource allocation state flags

Table 10. LUC VTAM Exit Completion Trace Record (continued)
X'11' Resource conversation state flags
X'12' Allocation error RPL return code
X'14' Allocation RPL sense codes
X'18' Abend reason codes
X'1C' Receive data buffer length
X'1E' Length of received data
X'20' Receive data buffer pointer
X'24' Address of LUC session control block
X'30' First 24 bytes of data received
Table 11. LUC Receive Exit Trace Record

X'00' LUC receive exit trace record ID = "LUCZ"
X'04' Address of LUC session control block
X'08' Access method status flags in session control block
X'0A' DCF status flags in session control block
X'0C' Request/response header
X'0F' Not used
X'10' RPL record length
X'12' RPL buffer length
X'14' First 30 bytes of data received
Message Queuing Service (MQS) trace record

The Message Queuing Service trace record contains the intertask queuing of buffers using DSIMQS. You
obtain this trace record by specifying OPTION=QUE on the TRACE command. Refer to NetView online
help for information about the NetView TRACE command.
For hexadecimal offset X'20', if the buffer is an automation internal function request (AIFR), the trace
record field represents a chain of buffers and the trace entry is repeated for each DATA buffer in the
chain. In case of a nonzero return code, a trace entry is generated if the trace is on.
Table 12. Message Queuing Service (MQS) Trace Record

X'00' MQS trace table identifier = MQS return code
X'04' Return address to the DSIMQM caller
X'08' TVB address of DSIMQS issuer
X'0C' Address of buffer to be queued
X'10' Operator ID of the receiver of the buffer, which can also be SYSOP, SYSLOG,
or AUTH RCV

Table 12. Message Queuing Service (MQS) Trace Record (continued)
X'18' Operator ID of the sender of the buffer. Can also contain MQS FAIL if the
NetView program was unable to pass the buffer to the target task.
X'20' Buffer header, followed by first section of the buffer text starting at header
TDISP. Refer to IBM Z NetView Programming: Assembler for more information
about BUFHDR.
VPDTASK trace record

You obtain the VPDTASK trace record by specifying SNAP ON using the VPDCMD command. To collect
data, specify TRACE ON TASK=VPDTASK before turning the snap trace on.
Table 13. VPDTASK Snap Trace Record

X'00' VPDS
= First snap
VPDX
= Additional snaps
X'04' SRCD
= Receive async completed
SBSA
= Before sending
SSAF
= Send async failed
SRAF
= Receive async failed
SCSF
= Check for send failed
SCRF
= Check for receive failed
X'08' RPL
= An RPL is being snapped
RU
= An RU is being snapped
X'0C' Total length of the RU or RPL

X'0E' Number of bytes being snapped in this request
X'10' Trace data, up to X'50' bytes
Installation Exit (UX) trace record

This trace record shows the installation exit calls for various exit routines. You obtain this trace record by
specifying OPTION=UEXIT on the TRACE command. Refer to NetView online help for information about
the NetView TRACE command.
For hexadecimal offset X'20', if the buffer is an AIFR, the trace record field represents a chain of buffers
and the trace entry is repeated for each buffer in the chain.

Table 14. Installation Exit Trace Record
X'00' Installation exit record ID = UX Reserved Exit number in hexadecimal
X'04' Return address to installation exit caller
X'08' TVB address
X'0C' Message buffer address
X'10' Installation exit address None if installation exit not coded
X'14' DSIUSE address
X'18' TVB operator identifier
X'20' Buffer header, followed by first section of the buffer text starting at header
TDISP. Refer to IBM Z NetView Programming: Assembler for more information
about BUFHDR.
The exit number is designated in hexadecimal X'01' to X'15' for DSIEX01 through DSIEX21 (DSIEX02A is
traced with X'02'). For data services task (DST) exits, this field is designated in hexadecimal as follows:
• XITDI (DST initialization exit)=X'E9'
• XITVN (VSAM initialization exit)=X'EA'
• XITVI (VSAM input exit)=X'EB'
• XITVO (VSAM output exit)=X'EC'
• XITCI (CNM interface input exit)=X'ED'
• XITCO (CNM interface output exit)=X'EE'
• XITXL (External log exit)=X'F0'
• XITBN (Sequential log initialization installation exit)=X'F1'
• XITBO (Sequential log output installation exit)=X'F2'
Module entry and module exit trace record

This trace record shows module entry and exit for a subset of the NetView modules. You obtain this trace
record by specifying OPTION=MOD on the TRACE command. Refer to NetView online help for information
about the NetView TRACE command.
Table 15. Module Entry and Exit Trace Record

X'00' Module entry trace record ID = MENT Module exit trace record ID = MXIT
X'04' Module entry address or trace routine return address
X'08' TVB address
X'0C' Register 1 on entry or register 15 on exit
X'10' Register 13 on entry
X'14' Register 14 return address
X'18' Module name

Lost trace record
The lost trace record prevents the trace function from using an excessive amount of storage. A limited
number of trace records are queued to be printed. If the queue limit is exceeded, the records are replaced
with the lost trace record. This limits the amount of storage used by the trace function.
Table 16. Lost Trace Record

X'00' Lost trace record ID = LOST
X'04' Return address to caller of DSIITM
X'08' TVB address of caller
X'C' QUE LIMIT EXCEEDED OBTAINED BFR FAILED (this record field is 20 bytes
long)
DSIGET/DSIFRE trace record

The DSIGET/DSIFRE trace record shows the getting and freeing of storage. You obtain this trace record by
specifying OPTION=STOR on the TRACE command. Refer to NetView online help for information about
the NetView TRACE command.
In case of a nonzero return code, a trace entry is generated if the trace is on.
When this trace entry is for DSIFRE Q=YES, the length shown at offset X'14' in the trace entry is zero.
When the caller of DSIGET is a NetView common service routine, such as DSICLONE or DSIGTBUF, the
trace entry at offset X'04' contains the return address of program that called the common service routine
which called DSIGET on behalf of the program.
Table 17. DSIGET/DSIFRE Trace Record

X'00' DSIGET trace record ID = GET DSIFRE trace record ID = FRE Return code. See
Note.
X'04' Return address to caller of DSIGET or DSIFRE
X'08' TVB address
X'0C' Reserved
X'10' Address of storage obtained or freed
X'14' Length of storage obtained or freed. If DSIFRE Q=YES, value is zero.
X'18' DSIFRE only; address of module that got storage (Q=YES ONLY)
X'1C' Reserved Subpool value EXIT(async)=X EXIT(mainline)=M Q(YES)=Q
Q(NO)=" "
Note: The last byte in this group indicates the DSIGET or DSIFRE reason code. If the value is an odd
number greater than 100, it indicates an internal failure code for a DSIGET. If the value is an odd number
less than 100, it indicates an internal failure code for a DSIFRE.
DSIWAT/DSIPOS/DISPATCH trace record

This trace record shows dispatching of tasks including waiting, posting, and dispatching from a wait. You
obtain this trace record by specifying OPTION=DISP on the TRACE command. Refer to NetView online
help for information about the NetView TRACE command.

Table 18. DSIWAT/DSIPOS/DISPATCH Trace Record
X'00' DSIWAT trace record ID = WAT DSIPOS trace record ID = POS DISPATCH
trace record ID = DISP
X'04' Return address to caller of DSIWAT or DSIPOS
X'08' TVB address
X'0C' ECB/ECBLIST address
X'10' ECB completion code, POS/WAT=0 DISP=ECB itself
X'14' Reserved
DSIPSS trace record

This trace record shows presentation services that involve input from and output to the terminal screen
using DSIPSS. You obtain this trace record by specifying OPTION=PSS on the TRACE command. Refer to
NetView online help for information about the NetView TRACE command.
For hexadecimal offset X'20', if the buffer is an AIFR, the trace record field represents a chain of buffers
and the trace entry is repeated for each buffer in the chain.
For trace entries with a NetView buffer, the buffer has a NetView buffer header followed by the first
section of the buffer text starting at the offset given by HDRTDISP. Refer to IBM Z NetView Programming:
Assembler for more information about BUFHDR.
Constants for option bytes

Table 19 on page 115 and Table 20 on page 115 list the constants for option byte 1 and option byte 2 of
the DSIPSS trace record shown in Table 21 on page 115.
Table 19. Constants for Option Byte 1

Constants Hexadecimal Description
PSMSEGMT X'40' Data message segment has no message header
PSMNOOP X'00' Do not change ready message
PSMFRSTF X'06' Begin full-line mode
PSMMIDF X'04' Continue full-line mode
PSMLASTF X'05' End full-line mode
PSMONLYF X'07' One full-line message
Table 20. Constants for Option Byte 2

Constants Hexadecimal Description
PSMCMDLF X'80' Command-line option
Table 21. DSIPSS Trace Record

X'00' DSIPSS trace record ID = PSS
X'04' Return address to caller of DSIPSS

Table 21. DSIPSS Trace Record (continued)
X'08' TVB address
X'0C' Buffer address or PLIST address if ASYPANEL
X'10' Type code
X'01' = INPUT
X'02' = OUTPUT
X'05' = CMDLINE
X'05' = IMMEDIATE
X'0F' = ASYPANEL
X'10' = CANCEL
X'11' = PSSWAIT
X'15' = XSEND
X'17' = XINIT
X'11' Option byte 1 (See Table 19 on page 115 for description.)

X'12' Option byte 2 (See Table 20 on page 115 for description.)
X'13' Reserved
X'14' Reply ID | Reserved
Additional Data (64 bytes) that varies according to the type code:
Type Code
Additional Data Description
INPUT (X'01')
64 bytes of data formatted as follows:
X'20'
4-byte length of input area
X'24'
4-byte length of input received
X'28'
1-56 bytes of input data
OUTPUT (X'02')
First 64 bytes of NetView buffer.
CMDLINE (X'05')
IMMEDIATE (X'05')
ASYPANEL (X'0F')
64 bytes of data formatted as follows:
X'20'
First 20 bytes of ASYPANEL parameter list
X'34'
4 bytes of data that have no meaning
X'38'
0-40 bytes of the data to be sent to the terminal

CANCEL (X'10')
Non meaningful data
PSSWAIT (X'11')
Non-meaningful data
XSEND (X'15')
XINIT (X'17')
TIME trace record

When MODE=INT, the time trace record is written approximately each second, as long as other trace
records are being written.
Table 22. TIME Trace Record

X'00' TIME trace record ID = "TIME"
X'04' Julian date in packed decimal
X'08' Time in packed decimal
X'0C' Not used
X'10' Current® STCK value
IP Services trace records

The IP Services trace records are obtained by specifying OPTION=TCP on the NCCF TRACE command. IP
Services trace records can be generated for the CNMTAMEL, DSIRTTR, and DSIWBTSK tasks and for tasks
that issue the NCCF SOCKET command.
These are some, but not all, of the tasks for which the trace record is generated on completion of an IP
Service request:
CNMTAMEL
DSIIPLOG
DSIREXEC
DSIRSH
DSIRTTR
DSIUDST (when RMTCMD over IP is enabled)
DSIWBTSK
DUIDGHB
These trace records have eye-catchers of TCxx. Tasks issuing the NCCF SOCKET command might
generate two trace records. If the IP Service request is asynchronous, a trace record is generated
following the invocation of the IP Service request (eye-catcher TCxx) and a trace record is generated on
completion of the IP Service request (eye-catcher TAxx). If the NCCF SOCKET command request is
synchronous, only one trace record is generated (TCxx). In addition, these are some, but not all,
commands that use NetView IP services:
IPLOG
REXEC
RSH
TN3270
Note: For asynchronous IP Service requests, the TAxx completion records contain information returned
by TCP/IP. Consult the z/OS Communications Server: IP Sockets Application Programming Interface Guide
and Reference in the section "Using the Macro Application Programming Interface (API)" to identify the

corresponding EZASMI macro invocation. For example, TCGH and TAGH are described as being trace
entries for the GETHOSTNAME request, so the corresponding EZASMI macro invocation is EZASMI
TYPE=GETHOSTNAME.
The Field Type column indicates whether a particular field is input, output, or both. For the NCCF SOCKET
command trace entries, only input fields will be displayed in the trace entries. The Field Type is not
specified for the header section of each trace record (X'00'–X'17').
Note: This does not trace interfaces using the REXX SOCKET function.
Except for the Select Exit (SE) trace record, the record types correspond to the types of IP Services calls.
The SE trace record is generated to indicate SELECT request completion.
Refer to the z/OS Communications Server library for more information.
IP Services TCxx trace entries

Following are the TCxx trace entries:
Table 23. ACCEPT Trace Record

Hexadecimal Offset Field Type Trace Record Field
X'00' ACCEPT trace record ID = TCAC
X'04' Return address of caller
X'08' TVB address
X'0C' Return Code from IP Services
X'10' errno from IP Services
X'14' ECB address or REQAREA address
X'18' Input Socket descriptor
X'1A' Input New Socket Descriptor number
X'1C' Output Addressing Family
X'1E' Output Client's Port Number
X'20' Output Flow Info (IPv6 only)
X'24' Output Scope ID (IPv6 only)
X'28' Output IP address of client's host
computer
Table 24. BIND Trace Record

X'00' BIND trace record ID = TCBD
X'08' TVB address
X'1A' N/A 0

Table 24. BIND Trace Record (continued)
X'1C' Input Addressing family
X'1E' Input Client's Port Number
X'20' Input Flow Info (IPv6 only)
X'24' Input Scope ID (IPv6 only)
X'28' Input IP address of client's host
computer
Table 25. CANCEL Trace Record

X'00' CANCEL trace record ID = TCCL
X'08' TVB address
X'0C' Return code from IP Services
X'18' Input CALAREA
Table 26. CLOSE Trace Record

X'00' CLOSE trace record ID = TCCS
X'08' TVB address
Table 27. CONNECT Trace Record

X'00' CONNECT trace record ID = TCCN
X'08' TVB address
X'18' Input Socket Descriptor
X'1A' N/A 0

Table 27. CONNECT Trace Record (continued)
X'1C' Input/Output Addressing Family
X'1E' Input/Output Client's Port Number
X'28' Input/Output IP address of client's host
computer
Table 28. FREEADDRINFO Trace Record

X'00' FREEADDRINFO trace record ID =
TCFR
X'08' TVB address
X'14' N/A 0
X'18' Input ADDRINFO
Table 29. GETADDRINFO Trace Record

X'00' GETADDRINFO trace record ID =
TCAI
X'08' TVB address
X'14' N/A 0
X'18' Input NODE Length
X'1C' Input NODE
X'34' Input SERVICE Length
X'38' Input SERVICE
X'4A' Input Family
X'4C' Input Flags
X'50' Input Socket Type
X'54' Input Protocol
X'58' Output Canonical Name Length

Table 29. GETADDRINFO Trace Record (continued)
X'5C' Input Pointer to ADDRINFO structures
Table 30. GETADDRINFO Output Trace Record

X'00' GETADDRINFO output trace record
ID = TCIS
X'08' TVB address
X'14' N/A 0
X'18' Output AF
X'1C' Output Socket Type
X'20' Output Protocol
X'24' Output Address of returned socket address
structure
X'2C' Output Scope ID (IPv6 only)
X'30' Output IP address
X'40' Output Port
X'42' Output Length of Canonical Name
X'46' Output Canonical Name
Table 31. GETCLIENTID Trace Record

X'00' GETCLIENTID trace record ID =
TCGC
X'08' TVB address
X'18' Output Domain of the client
X'1C' Output Client address space identifier
X'24' Output Client task identifier

Table 32. GETHOSTBYADDR Trace Record
X'00' GETHOSTBYADDR trace record ID
= TCGA
X'08' TVB address
X'10' N/A 0
X'14' N/A 0
X'18' Input HOSTADR - IP address of the host
whose name you want to find
X'1C' Output HOSTENT structure address
Table 33. GETHOSTBYNAME Trace Record

X'00' GETHOSTBYNAME trace record ID
= TCGB
X'08' TVB address
X'10' N/A 0
X'14' N/A 0
X'18' Input Length of host name
X'1C' Output HOSTENT structure address
X'20' Input Host name, up to 24 bytes
Table 34. GETHOSTID Trace Record

X'00' GETHOSTID trace record ID = TCGI
X'08' TVB address
X'10' N/A 0
Table 35. GETHOSTNAME Trace Record

X'00' GETHOSTNAME trace record ID =
TCGH

Table 35. GETHOSTNAME Trace Record (continued)
X'08' TVB address
X'18' Input Length of host name
X'1C' N/A 0
X'20' Output Host name, up to 24 bytes
Table 36. GETNAMEINFO Trace Record

X'00' GETNAMEINFO trace record ID =
TCNI
X'08' TVB address
X'14' N/A 0
X'18' Input Flags
X'1C' Input Addressing Family
X'1E' Input Port
X'20' Input Flow Info (IPv6 only)
X'28' Input IP address
Table 37. GETNAMEINFO Output Trace Record

X'00' GETNAMEINFO Output trace record
ID = TCNO
X'08' TVB address
X'14' N/A 0
X'18' Output Host Length
X'1C' Output Host Name

Table 37. GETNAMEINFO Output Trace Record (continued)
X'34' Output Length of Service Storage
X'38' Output Service Name
Table 38. GETPEERNAME Trace Record

X'00' GETPEERNAME trace record ID =
TCGP
X'08' TVB address
X'1A' N/A 0
X'1C' Output Addressing Family
X'1E' Output Connection Peer Port Number
X'28' Output IP address of the connection peer
host
Table 39. GETSOCKNAME Trace Record

X'00' GETSOCKNAME trace record ID =
TCGN
X'08' TVB address
Table 40. GETSOCKOPT Trace Record

X'00' GETSOCKOPT trace record ID =
TCGO

Table 40. GETSOCKOPT Trace Record (continued)
X'08' TVB address
X'1C' Input Option Name
X'30' Input Option Length
Table 41. GIVESOCKET Trace Record

X'00' GIVESOCKET trace record ID =
TCGS
X'08' TVB address
X'18' Input Client domain
X'1C' Input Client address space identifier
X'24' Input Client task identifier
X'2C' Input Socket descriptor
Table 42. INITAPI, INITAPIX Trace Record

X'00' INITAPI trace record ID = TCIN
X'08' TVB address
X'14' N/A 0
X'18' Input ASYNC type
X'1C' Input Subtask
X'24' Input TCP/IP address space name
X'2C' Input Address space name of calling
program

Table 42. INITAPI, INITAPIX Trace Record (continued)
X'34' Output Largest socket descriptor number
assigned to application
X'38' Input Maximum number of sockets
supported by the application
Table 43. IOCTL Trace Record

X'00' IOCTL trace record ID = TCIO
X'08' TVB address
X'1A' Input REQARG
X'1E' Output RETARG
X'22' Input Command
X'34' Input REQARG Details
The following IOCTL REQARG tables map to the REQARG Details entry (offset X'34') in the IOCTL Trace
record.
Table 44 on page 126 is the REQARG mapping for SIOCGHOMEIF6:
Table 44. IOCTL REQARG Mapping 1

X'34' Input Buffer Length
X'38' Input Buffer Pointer
X'3C' Output Number of Entries Returned
Table 45 on page 126 is the REQARG mapping for FIONBIO:

X'34' Input Blocking Mode
Table 46 on page 126 is the REQARG mapping for SIOCGIFADDR, SIOCGIFBRDADDR, and
SIOCGIFDSTADDR:

X'34' Input Interface Name

Table 47 on page 127 is the REQARG mapping for SIOCGIFCONF:

X'34' Input Size of return buffer
Table 48 on page 127 is the REQARG mapping for SIOCGIFNAMEINDEX:

X'34' Input Size of return buffer
Table 49 on page 127 is the REQARG mapping for SIOCTTLSCTL:

X'34' Output TTLS version
X'35' Output Policy status
X'36' Output Connection status
X'37' Output Security type
X'38' Output Protocol (first byte is version,
second byte is modification)
Table 50. LISTEN Trace Record

X'00' LISTEN trace record ID = TCLN
X'08' TVB address
X'1A' Input Backlog
Table 51. RECV Trace Record

X'00' RECV trace record ID = TCRV
X'08' TVB address

Table 51. RECV Trace Record (continued)
X'1A' Input Buffer size
X'1E' Input Buffer address
X'22' Input Flags
Table 52. RECVFROM Trace Record

X'00' RECVFROM trace record ID = TCRF
X'08' TVB address
X'1A' Input Buffer size
X'22' Input Flags
X'26' Input Addressing Family
X'28' Input Port Number
X'2A' Filler 0
X'2C' Input Flow Info (IPv6 only)
X'34' Input IP address of the socket
Table 53. SELECT Trace Record

X'00' SELECT trace record ID = TCSL
X'08' TVB address
X'18' Input Largest socket descriptor to be
checked plus 1
X'1C' Input Timeout value

Table 54. SELECT Exit Trace Record
X'00' SELECT exit trace record ID = TCSE
X'08' TVB address
Table 55. SEND Trace Record

X'00' SEND trace record ID = TCSD
X'08' TVB address
X'1A' Input Number of bytes to send
X'22' Input Flags
Table 56. SENDTO Trace Record

X'00' SENDTO trace record ID = TCST
X'08' TVB address
X'18' Output Socket descriptor
X'1A' Input Number of bytes to send
X'1E' Input Buffer Address
X'22' Input Flags
X'28' Input Port Number
X'2A' Filler 0
X'2C' Input Flow Info (IPv6 only)
X'34' Input IP address of the socket

Table 57. SETSOCKOPT Trace Record
X'00' SETSOCKOPT trace record ID =
TCSS
X'08' TVB address
X'1A' Input Option Name
X'2E' Input Length of Option Value
X'32' Filler Filler
X'34' Input Option Value
The following SETSOCKOPT option value tables map to the option value entry (X'34') in the SETSOCKOPT
trace record.
The following SETSOCKOPT option value mapping is for the following options:
• IP_ADD_MEMBERSHIP
• IP_DROP_MEMBEFRSHIP
Table 58. SETSOCKOPT Option Value Mapping 1

X'34' Input IPv4 multicast address
X'38' Input IPv4 interface address
The following SETSOCKOPT Option Value Mapping is for the following options:
• IP_MULTICAST_IF
• IPV6_MULTICAST_IF

X'34' Input IPv4 interface address or IPv6
interface index number
• IP_MULTICAST_LOOP
• IPV6_MULTICAST_LOOP
• IPV6_V6ONLY
• SO_BROADCAST
• SO_KEEPALIVE
• SO_OOBINLINE
• SO_RCVBUF

• SO_REUSEADDR
• SO_SNDBUF
• TCP_KEEPALIVE
• TCP_NODELAY

X'34' Input Enable/Disable Field (see request
for details), Buffer Data size, or
timeout value
• IPV6_JOIN_GROUP
• IPV6_LEAVE_GROUP

X'34' Input IPv6 Multicast Address
X'44' Input IPv6 Interface Index
• IPV6_MULTICAST_HOPS
• IPV6_UNICAST_HOPS

X'34' Input Number of hops
• IP_MULTICAST_TTL

X'34' Input Time-to-live value
• SO_LINGER

X'34' Input Enabling Field
X'38' Input Seconds to Linger
Table 65. SHUTDOWN Trace Record

X'00' SHUTDOWN trace record ID = TCSH

Table 65. SHUTDOWN Trace Record (continued)
X'08' TVB address
X'1A' Input How to shut down
Table 66. SOCKET Trace Record

X'00' SOCKET trace record ID = TCSK
X'08' TVB address
X'1A' Input Socket Type(length of 6 except
when RW)
X'1C' Input Protocol (present only when socket
type is RW)
Table 67. TAKESOCKET Trace Record

X'00' TAKESOCKET trace record ID =
TCTS
X'08' TVB address
X'18' Input Client domain
X'1C' Input Client address space identifier
X'24' Input Client task identifier
X'2C' Input Socket descriptor assigned by
GIVESOCKET

Table 67. TAKESOCKET Trace Record (continued)
X'2E' Input Socket descriptor for new socket
Table 68. TERMAPI Trace Record

X'00' TERMAPI trace record ID = TCTM
X'08' TVB address
IP Services Asynchronous TAxx Trace Records

The following trace records are generated upon completion of a call to IP Services for an NCCF SOCKET
command asynchronous request.
Trace records are generated for IP Service requests of the following:
• BIND
• CANCEL
• CLOSE
• GIVESOCKET
• LISTEN
• RECV
• SELECT
• SEND
• SENDTO
• SETSOCKOPT
• SHUTDOWN
• SOCKET
• TAKESOCKET
Table 69. Common IP Service Asynchronous Trace Record - Type 1

X'00' Trace record ID - part one = TA
X'02' Trace record ID - part two =
BD,CL,CS,GS,LN,RV,SL,SD,SS,ST,SH,SK, or TS
X'08' TVB address
Trace records are generated for IP Service requests of the following:

• ACCEPT
• CONNECT

• GETPEERNAME
• GETSOCKNAME
• RECVFROM
Table 70. Common IP Service Asynchronous Trace Record - Type 2

Hex Offset Trace Record Field
X'00' Trace record ID - part one = TA
X'02' Trace record ID - part two = AC,CN,GP,GN, or RF
X'08' TVB address
X'18' Addressing Family
X'1A' Port Number
X'1C' Flow Info (IPv6 only)
X'20' Scope ID (IPv6 only)
X'24' IP address
Table 71. GETCLIENTID Trace Record

X'00' GETCLIENTID Trace record ID = TAGC
X'08' TVB address
X'18' Client domain
X'1C' Client address space identifier
X'20' Client task identifier
Table 72. GETHOSTID Trace Record

X'00' GETHOSTID trace record ID = TAGI
X'08' TVB address
X'10' N/A

Table 72. GETHOSTID Trace Record (continued)
Table 73. GETHOSTNAME Trace Record

X'00' GETHOSTNAME trace record ID = TAGH
X'08' TVB address
X'18' Host name, up to 24 bytes
Table 74. GETSOCKOPT Trace Record

X'00' GETSOCKOPT Trace record ID = TAGO
X'08' TVB address
X'18' Option value
The following GETSOCKOPT option value tables map to the Option Value entry (offset X'18') in the
GETSOCKOPT trace record.
The following GETSOCKOPT Option Value Mapping is for the following options:
• IP_MULTICAST_IF
• IPV6_MULTICAST_IF
Table 75. GETSOCKOPT Option Value Mapping 1

X'18' Output IPv4 interface address or IPv6
interface index number
• IP_MULTICAST_LOOP
• IPV6_MULTICAST_LOOP
• IPV6_V6ONLY
• SO_BROADCAST
• SO_KEEPALIVE

• SO_OOBINLINE
• SO_RCVBUF
• SO_REUSEADDR
• SO_SNDBUF
• TCP_NODELAY

X'18' Output Enable/Disable Field (see request
for details), Buffer Data size, or
timeout value
• IPV6_MULTICAST_HOPS
• IPV6_UNICAST_HOPS

X'18' Output Number of hops
• IP_MULTICAST_TTL

X'18' Output Time-to-live value
• SO_LINGER

X'18' Output Enabling Field
X'1C' Input Seconds to Linger
• SO_ERROR

X'18' Output Most recent errno for socket
• SO_TYPE

X'18' Output Socket Type
Table 82. IOCTL Trace Record

X'00' Trace record ID = TAIO
X'08' TVB address
X'18' RETARG
X'1C' RETARG Details
The following IOCTL RETARG tables map to the RETARG Details entry (offset X'1C') in the IOCTL trace
record.
The following table shows the RETARG Mapping for FIONREAD:
Table 83. IOCTL RETARG Mapping 1

X'1C' Output Number of characters available for
read
The following table shows the RETARG Mapping for SIOCGIFADDR, SIOCGIFBRDADDR, and
SIOCGIFDSTADDR:

X'1C' Output Family
X'1E' Output Port
X'20' Output IPv4 Address
The following table shows the RETARG mapping for SIOCGIFNAMEINDEX:

X'1C' Output Total Active Interfaces
X'20' Output Number of entries returned
X'24' Output Name Index entry table pointer
The following table shows the RETARG mapping for SIOCGHOMEIF6:

X'1C' Input Buffer Length
X'20' Input Buffer Pointer
X'24' Output Number of Entries Required
The following table shows the RETARG mapping for SIOCTTLSCTL:

X'1C' Zeros
X'22' Input IOCTL command name
(SIOCTTLSCTL padded with
trailing blanks)
X'34' Input IOCTL version (x'01')
X'35' Output TTLSi_Stat_Policy
X'36' Output TTLSi_Stat_Conn
X'37' Output TTLSi_Sec_Type
X'38' Output TTLSi_SSL_Prot
The output trace record field names for this mapping are the field names defined by the EZBZTLSP macro.
For more information, see the z/OS Communications Server library.
NetView IP trace exit record

This trace record is generated when a NetView module is driven as an exit for an IP-related service flow.
To obtain this trace, specify OPTION=TCP on the NCCF TRACE command.
Table 88. TCPX Trace Record

X'00' TCP exit trace record ID = TCPX
X'04' Base register of exit module
X'08' TVB address
X'0C' Parameter list address on entry to the exit
X'14' -X'1C' For Service Use Only
Status Monitor internal trace records

The module CNMTARCA issues trace records whenever any option of the NetView trace is turned on and
the VTAM status monitor optional subtask has not been excluded from tracing with the use of the TASK
keyword on the TRACE command. Refer to NetView online help for information about the NetView TRACE
command.
These records document certain internal flows in status monitor processing. They can be useful in solving
status monitor problems.
You can identify these records by a V, or an O, at hexadecimal offset X'0'. These records are 96 bytes long.

Operator Command (OC) trace record
This trace record shows an operator command that has been sent to the status monitor main task from
the OST.
Table 89. Operator Command (OC) Trace Record

X'00' Trace record ID = OC
X'02' Operator command
Activity (VY) trace record

When the status monitor receives information that a resource has gone inactive, it sends an activity
response back to the operator station task (OST). Several 96-byte trace records can be required.
Table 90. Activity (VY) Trace Record

X'00' Trace record ID = VY
X'02' Data passed back from CNMTARCA to the OST in response to an activity
request by the operator
MONIT (VMON) trace record

When the status monitor receives information that a resource has gone inactive, it attempts to put the
node and all its lower nodes into MONIT state. This trace record is issued when one of the nodes cannot
be put into MONIT state.
Table 91. MONIT (VMON) Trace Record

X'00' Trace record ID = VMON
X'04' CNMDRDAT entry of the lower node that cannot be monitored
Resource status change processed (CE) trace record

This trace record is produced after CNMTARCA processes an entry off the changed resource list (CRL)
chain. This chain contains a list of resources that have changed states.
Table 92. Resource Status Change Processed (CE) Trace Record

X'00' Trace record ID = CE
X'04' CNMDRDAT entry of the resource that was processed
Force INACT (FINA) trace record

The Force INACT trace record is issued when a failing resource does not enter the MONIT state. Normally,
a failing resource enters the MONIT state, but this might not be the case if an operator forced the
resource to an inactive state.
Table 93. Force INACT (FINA) Trace Record

X'00' Trace record ID = FINA
X'04' Resource name

Table 93. Force INACT (FINA) Trace Record (continued)
X'12' Because of FORCE INACT command
Correlation identifiers between VTAM messages and the status monitor

Correlation identifiers are used to identify each VTAM message processed by the status monitor.
Table 94. Correlation Identifiers

Hexadecimal Value VTAM Command Generating the VTAM Message If Applicable
X'0000' Unsolicited message
X'0001' D NET,APPLS
X'0002' D NET,PENDING
X'0003' D NET,ID=nodename
X'0004' D NET,ID=applname,E
X'0006' D NET,ID=linename,E
X'0007' V NET,ACT,SCOPE=ONLY,ID=nodename
X'0014' Solicited message
X'1388' to X'176F' D NET,ID=NODENAME,E
Security Authorization Facility trace record

The SAF trace record is an audit of calls made to your security authorization facility (SAF) product, such as
RACF (Resource Access Control Facility), by the NetView program. You can obtain this trace record by
specifying OPTION=SAF on the NetView TRACE command. When OPTION=SAF is used with the SAFA
keyword, all calls to SAF cause an entry to be generated. When OPTION=SAF is used with the SAF
keyword, only SAF failures (non-zero return codes) cause an entry to be generated.
The SAF trace record is generated if the NetView program is using an SAF product for operator
verification, command authorization, or span authority checking.
For more information about the SAF return and reason codes for RACF, see the z/OS Security Server
RACROUTE Macro Reference .
SAF trace record descriptions

Each SAF trace record is described here. The following list shows the SAF trace records with examples of
when they are generated:
• AUTH record
– During NetView operator logon when an SAF product is used for passwords or password phrases,
logon attributes, or both
– Starting optional (OPT) tasks
– Starting spans
– When the NetView RMTCMD command is received
– Starting autotasks
– For commands that involve operators, such as ASSIGN, QOS, QRS, LIST, REFRESH, and AUTOTBL
– For any command when FASTAUTH is not available and GLOBAL=YES is not active for the NETCMDS
class

– Each time an attempt to run a command audited by RACF for a specific condition meets that
condition
– Signing on to an NetView management console operator
– Issuing ENDTASK of the RMTCMD session for another task
• EXTRACT record
– During NetView operator logon when an SAF product is used for both passwords or password
phrases and logon attributes, such as when OPERSEC=SAFDEF
• FASTAUTH record
– When command authorization checking is done through an SAF product and GLOBAL=YES is active
for the NETCMDS class
• STAT record
– Issuing the NetView REFRESH command
- OPSPAN from NETV to SAF
- CMDAUTH from the TABLE to SAF
• TOKENMAP record
– Issuing a NetView command from an MVS console
– When a UTOKEN is decrypted for a FASTAUTH, AUTH or EXTRACT trace record
• TOKENXTR record
• VERIFY record
– When a NetView operator station task (OST) abends or logs off
– Starting or stopping the DSIUDST task when RMTCMD security is in SAF
– Signing on to an NetView management console operator
– Starting or stopping the CNMCSSIR and PPT tasks
Trace record for SAF REQUEST = AUTH
Table 95. Security Authorization Facility AUTH Trace Record - Type 1

X'00' SAF AUTH Trace Record ID = "ATH1"
X'08' TVB address
X'0C' PRE RACROUTE trace record ID = "PRE" POST RACROUTE trace record ID =
"POST"
X'10' TIME (first 4 bytes of STCK)
X'14' SAF return code
X'18' RACF return code
X'1C' RACF reason code
X'20' User ID
X'28' Class name

Table 95. Security Authorization Facility AUTH Trace Record - Type 1 (continued)
X'30' ACEE address (value of zero is normal)
X'34' Authority level requested
X'3C' Return address of callers caller (if available)
X'40' SAF parameter list pointer
Note: Multiple type-3 records might be required if the value is greater than 80 bytes. For the RMTOPS
class, the POST record does not contain profile information.

X'08' TVB address
"POST"
X'10' UTOKEN

X'08' TVB address
"POST"
X'10' For PRE, the resource to be checked. For POST, the profile that protects the
resource.
Trace record for SAF REQUEST = EXTRACT
Table 98. Security Authorization Facility EXTRACT Trace Record - Type 1

X'00' SAF EXTRACT Trace Record ID = "EXT1"
X'08' TVB address
"POST"

Table 98. Security Authorization Facility EXTRACT Trace Record - Type 1 (continued)
X'20' Class name
X'28' Segment name
X'30' Return address of caller's caller (if available)
Note: Multiple type-2 records might be required if the value is greater than 80 bytes.

X'08' TVB address
"POST"
X'10' Resource for which information is extracted

X'08' TVB address
"POST"
X'10' For PRE, the list of field names whose values are to be extracted
For POST, this value contains pairs of 4-byte length fields followed by their
related data. If the length field is zero, the next field is a subfield length.
Subfield
Data
IC
initial command name
CTL
X'00'=specific, X'40'=general, X'80'=global
MSGRECVR
X'00'=no, X'80'=yes
DOMAINS
domain name
CONSNAME
console name
NGMFADMN
X'00'=no, X'80'=yes

Trace record for SAF REQUEST = FASTAUTH
Table 101. Security Authorization Facility FASTAUTH Trace Record - Type 1

X'00' SAF FASTAUTH Trace Record ID = "FST1"
X'08' TVB address
"POST"
X'20' User ID
X'28' Class name
X'34' Authority level requested
X'3C' Authority request type used
X'44' Return address of callers caller (if available)

X'08' TVB address
"POST"
X'10' UTOKEN

X'08' TVB address
"POST"
X'10' For PRE only, the resource to be checked

Trace record for SAF REQUEST = LIST
Table 104. Security Authorization Facility LIST Trace Record

X'00' SAF STAT Trace Record ID = "LIST"
X'08' TVB address
"POST"
X'20' Class name
X'2C' SAF Global flag
X'30' SAF environment
X'3C' SAF parameter list pointer
Trace record for SAF REQUEST = STAT
Table 105. Security Authorization Facility STAT Trace Record

X'00' SAF STAT Trace Record ID = "STAT"
X'08' TVB address
"POST"
X'20' Class name
X'2C' SAF parameter list pointer

Trace record for SAF REQUEST = TOKENMAP
Table 106. Security Authorization Facility TOKENMAP Trace Record - Type 1

X'00' SAF TOKENMAP Trace Record ID = "TKM1"
X'08' TVB address
"POST"
X'20' Format of UTOKEN (external or internal)
X'28' Address of input token
X'2C' Address of output token
Table 107. Security Authorization Facility TOKENMAP Trace Record - Type 2

X'00' SAF TOKENMAP Trace Record ID = "TKM2"
X'08' TVB address
"POST"
X'10' UTOKEN
Trace record for SAF REQUEST = TOKENXTR
Table 108. Security Authorization Facility TOKENXTR Trace Record - Type 1

X'00' SAF TOKENXTR Trace Record ID = "TKX1"
X'08' TVB address
"POST"

Table 108. Security Authorization Facility TOKENXTR Trace Record - Type 1 (continued)
Table 109. Security Authorization Facility TOKENXTR Trace Record - Type 2

X'00' SAF TOKENXTR Trace Record ID = "TKX2"
X'08' TVB address
"POST"
X'10' UTOKEN
Trace record for SAF REQUEST = VERIFY

Note: The ACEE address is usually zero.
Table 110. Security Authorization Facility VERIFY Trace Record

X'00' SAF VERIFY Trace Record ID = "VRFY"
X'08' TVB address
"POST"
X'20' Environment
X'28' User ID
X'30' APPL name
X'38' Terminal ID
X'40' ACEE address (Normal value is zero.)
X'44' Password or password phrase check requested
X'48' New password or password phrase requested
X'4C' Return address of callers caller (if available)

SNA Topology Manager NetView trace entries
The following description shows the NetView trace entries written for storage requests by the SNA
topology manager. These trace entries are written whenever a module in the topology manager requests
storage while the NetView trace is active for the task. The trace entries are written for each of the
following z/OS storage requests:
• Allocate storage
• Allocate storage for an array
• Reallocate storage
• Free storage
Allocate storage request

The following sample trace entry is written for an allocate storage request. The fields of this trace sample
are described in Table 111 on page 148.
C6D3C2D4 83E5E7BE 00025080 046D5538 | FLBMcVX...&;._.. |

000001F4 00000000 00000000 00000000 | ...4............ |
Table 111. Allocate Storage Request

X'00' Record identifier = "FLBM"
X'04' Return address to requestor of storage
X'08' TVB address
X'0C' Address of storage obtained for caller or 0, if the request failed
X'10' Length of storage caller requested
X'14' Reserved
X'18' Reserved
X'1C' Reserved
Allocate storage for an array request

The following sample trace entry is written for an allocate storage for an array request. The fields of this
trace sample are described in Table 112 on page 148.
C6D3C2C3 83E5E880 00025080 03E50038 | FLBCcVY...&;.V.. |

00000032 00000010 00000000 00000000 | ................ |
Table 112. Allocate Storage for an Array Request

X'00' Record identifier = "FLBC"
X'08' TVB address
X'0C' Address of storage obtained for caller or 0, if the request failed
X'10' Number of elements in the array for which storage was requested
X'14' Length of an element in the array for which storage was requested
X'18' Reserved

Table 112. Allocate Storage for an Array Request (continued)
X'1C' Reserved
Reallocate storage request

The following sample trace entry is written for a reallocate storage request. The fields of this trace sample
are described in Table 113 on page 149.
C6D3C2D9 83E5E936 00025080 046D3858 | FLBRcVZ...&;._.. |

00000064 046D3858 83E5E834 00000000 | . ..._..cVY..... |
Table 113. Reallocate Storage Request

X'00' Record identifier = "FLBR"
X'08' TVB address
X'0C' Address of a new storage area obtained for caller, or zero if the request failed
X'10' Length of the new storage area requested by the caller
X'14' Address of an old storage area to be reallocated, or zero if there was no old
storage area
X'18' Return address to module that obtained the old storage area, or zero if there
was no old storage area
X'1C' Reserved
Free storage request

The following sample trace entry is written for a free storage request. The fields of this trace sample are
described in Table 114 on page 149.
C6D3C2C6 83E5EA22 00025080 03E50038 | FLBFcV....&;.V.. |

83E5E880 00000000 00000000 00000000 | cVY............. |
Table 114. Free Storage Request

X'00' Record identifier = "FLBF"
X'04' Return address to module that wanted storage freed
X'08' TVB address
X'0C' Address of storage to be freed
X'10' Return address to the module that obtained the storage area originally or zero
if the address of the storage area to be freed was zero
X'14' Reserved
X'18' Reserved
X'1C' Reserved

First failure data capture trace
First failure data capture stores problem determination data to help determine the cause of an abend in
an HLL command processor or installation exit.
The NetView HLL application programming interface (API) always stores debugging information in the HLL
trace area, which wraps continuously. This trace area holds information recorded at key points in HLL API
code. This HLL trace area can help you determine what happened before an abend.
The HLL trace area has eight entries, each of which is 6 bytes, for a total 48 bytes. Each trace point is
identified by a unique 16-bit ID. The first 12 bits of each trace entry represent the module ID. The next 4
bits are the location ID within the module. By convention, X'0' is the location ID value for the module
entry and X'F' is the location ID value for the module exit. The module ID value corresponds to the HLL
service routine. See Table 115 on page 151 for module ID values.
The next 4 bytes of each trace entry contain useful diagnostic information captured at a diagnostic point.
Use the trace entries that are recorded at entry to and exit from HLL service routines to determine the
location of the error. The diagnostic information recorded at entry is the return address of the caller of the
service, from register 14 of the caller. The information recorded at exit is the return code from the HLL
service routine. The information recorded at other location IDs is only for use by IBM Software Support.
For example, consider the HLL command procedure TEST, which consists of four subroutines: SR01,
SR02, SR03, and SR04. The command procedure records a 4-character subroutine name entry in
HLBFFDCA at entry to, and exit from, these routines. SRE1 is the value at the entry of the first subroutine
(SR01) and SRX1 is the value at the exit of SR01. If the TEST command procedure abends, a panel similar
to the panel in Figure 34 on page 150 is displayed at the NetView operator console.
NCCF NetView CNM01 OPER1 08/18/19 12:14:59

, CNM01
CNM998E ABEND/LOGOFF WHILE RUNNING COMMAND PROCEDURE TEST EP=02522BA8
CNM983E 0000 E2D9C5F1 E2D9E7F1 E2D9C5F3 00000000 SRE1SRX1SRE3
CNM983E 0010 00000000 00000000 00000000 00000000
CNM983E 0020 00000000 00000000 00000000 00000000
CNM999E 0010 8252284A 001F 00000000 0020 82522F4E 002F 00000000
CNM999E 0010 82522954 001F 00000000 0010 82522F4E 0000 00000000
_______________________________________________________________________________
???
Figure 34. Example of HLL API Trace Area Output on Abend
In Figure 34 on page 150, message CNM998E indicates that the abend occurred in the command
procedure TEST that has an entry point address 02522BA8. Message CNM983E indicates that the
command procedure successfully entered and exited subroutine SR01 and then entered subroutine
SR03, but did not exit it. This indicates that the abend occurred in subroutine SR03.
Message CNM999E indicates that the ID of the last HLL service routine entered is X'001'. The final entry
in the last CNM999E message is only for use by IBM Software Support. See Table 115 on page 151 to
correlate the ID (X'001') with the service routine CNMCMD. This is the service routine that the TEST
command procedure was running at the time of the abend. The return address from the service routine is
82522F4E. From the return address, you can compute the offset in the user code from which the service
was run.

Table 115. Module ID Used by FFDC Trace
Module ID HLL Service Routines Module ID HLL Service Routines
001 CNMCMD 015 CNMALTD
002 CNMSMSG 016 CNMCELL
003 CNMNAMS 019 CNMC2T
004 CNMGETD 020 CNMSMU
005 TIMEP (see note) 021 CNMRGS
006 WAIT command 022 CNMAUTO
007 CNMINFC 023 CNMQAPI
008 CNMINFI 024 CNMPMDB
009 CNMGETA 026 CNMIPXL
00A CNMVARS 051 CNMETIN
00B CNMMEMO 052 CNMETRM
00C CNMMEMR 053 CNMEWAT
00D CNMMEMC 054 CNMEGTP
00E CNMSCAN 055 CNMENTR
00F CNMCNMI 056 CNMETQU
010 CNMKEYIO 057 CNMERTR
011 CNMSCOP 058 CNMESTR
012 CNMCPYS 059 CNMHREGS
013 CNMLK 05A CNMHSMU
014 CNMPOOL
Note: HLL service routine TIMEP is for IBM Software Support use only.
Program-to-Program Interface (PPI) trace facility

You can use the program-to-program interface (PPI) trace facility to diagnose problems in applications
that use the PPI by generating trace records that can be interpreted. The records are stored in the PPI
trace table or, when using the generalized trace facility (GTF), the records are logged in an external data
set.
The PPI trace table and the GTF trace record chain are anchored by the PPI trace anchor block.
Understanding the PPI Trace Anchor Block and the PPI Trace Table
The PPI trace table resides in the subsystem interface (SSI) address space and is anchored by the PPI
trace anchor block. The PPI trace anchor block:
• Resides in the common storage area in MVS
• Contains the following pointers:
– The first pointer points to the address of the PPI trace table.
– The second pointer points to the last PPI trace record written to the trace table.
• Contains information about the status of the PPI trace

The PPI trace table:
• Resides in the SSI address space in MVS
• Contains a 12-byte header followed by the trace entries (shown in Figure 35 on page 152). The header
contains:
– A 4-byte eye-catcher (PITT)
– A 4-byte pointer to the last PPI trace record written to the trace table
– A 4-byte field containing the length of the PPI trace table
The PPI trace records follow the 12-byte header. The trace records are variable length and are linked with
backward and forward pointers. If a trace record is longer than the space available after the most current
record in the trace table, the new entry is written at the beginning of the table, overwriting any records
that are already there. Figure 35 on page 152 shows the format of each trace record.
Figure 35. Data Structure: Program-to-Program Interface Trace Record
Understanding the Program-to-Program Interface Trace Record

A PPI trace record is created for PPI request types 4, 9, 10, 12, 14, 22, and 23. Request types 1, 2, 3, and
24 run in the user address space. As a result, it is not possible for the PPI to trace these request types. To
trace these request types, implement your own trace. The request types that are traced are grouped
under various eye-catchers, including:
INIT
Request type 4 is traced under the INIT eye-catcher. The following fields are written for this trace
record:
• The eye-catcher (INIT)
• The backward and forward pointers
• The length of the trace record
• A time stamp that indicates the time of the request
• The receiver ID, including:
– Receiver name
– ASID
– Address space control block (ASCB) address
– TCB address
DISC
Request type 9 is traced under the DISC eye-catcher. The following fields are written for this trace
record:
• The eye-catcher (DISC)

– Receiver name
– ASID
– ASCB address
– TCB address
ABND
The ABND eye-catcher indicates an abnormal end (abend) of a receiver with respect to the PPI. That
is, the receiver disconnected from the PPI without issuing a request type 9 or 10. This can occur for
several reasons. For example, this can happen if a user abended, the task ended without issuing a
request type 9 or 10, or the SSI ended. The following fields are written for this trace record:
• The eye-catcher (ABND)
• A time stamp that indicates the time when the abend occurred
– Receiver name
– ASID
– ASCB address
– TCB address
DELT
Request type 10 is traced under the DELT eye-catcher. The following fields are written for this trace
record:
• The eye-catcher (DELT)
• A time stamp that indicates the time the abend occurred
– Receiver name
– ASID
– ASCB address
– TCB address
SEND
Request types 12 and 14 are traced under the SEND eye-catcher. The following fields are written for
this trace record:
• The eye-catcher (SEND)
• The receiver ID, Including:
– Receiver name
– ASID
– ASCB address
– TCB address
• Sender ID, including
– Sender name

– ASID
– ASCB address
– TCB address
• Frame Number
• The length of the buffer that was sent
The amount of buffer data copied from the buffer and sent is determined by the receiver's trace buffer
size value.
RECV
Request type 22 is traced under the RECV eye-catcher. The following fields are written for this trace
record:
• The eye-catcher (RECV)
– Receiver name
– ASID
– ASCB address
– TCB address
• Sender ID, including:
– Sender name
– ASID
– ASCB address
– TCB address
• Frame Number
• The length of the buffer that was received
The frame number matches the frame number of the SEND trace record created when the buffer is
sent. The amount of buffer data copied from the buffer received is determined by the receiver's trace
buffer size value.
PURG
Request type 23 is traced under the PURG eye-catcher. The following fields are written for this trace
record:
• The eye-catcher (PURG)
– Receiver name
– ASID
– ASCB address
– TCB address
• Sender ID, including:
– Sender name
– ASID

– ASCB address
– TCB address
• Frame Number
• The length of the buffer that was purged
The frame number matches the frame number of the SEND trace record that is created when the
buffer is sent. The amount of buffer data copied from the buffer that is purged is determined by the
receiver's trace buffer size value.
ERR
This PPI trace record is written only when an error occurs while the PPI is allocating a trace record for
a GTF trace or, if the GTF becomes disabled. The following fields are written for this trace record:
• The eye-catcher (ERR)
• A time stamp that indicates the time of the error
• The frame number
The frame number contains the number of trace records lost.
Locating the Program-to-Program Interface (PPI) Trace Table

You can find the trace table by using one of the following methods:
• Search the memory dump for the PITT eye-catcher.
• Use the address supplied by the DISPPI command processor.
To find the trace table:
1. Dump the common storage area and the subsystem interface address area.
2. Find the pointer to the communication vector table (CVT) in X'10'.
3. Find the CVT. Offset X'128' of the CVT contains the CVTJESCT field which points to the JES Control
Table (IEFJESCT).
4. Find the IEFJESCT field. Offset X'18' in the IEFJESCT field contains the JESSSCT field. JESSSCT points
to the head of the subsystem communication vector table (IEFJSCVT) chain.
5. In the IEFJSCVT chain, search for the pointer to the NetView subsystem DSISST.
a. In offset X'1C' of the IEFJSCVT pointing to the NetView subsystem DSISST, there is a 4 byte eye-
catcher, NETV.
b. If the eye-catcher in the IEFJSCVT is not NETV, locate the next IEFJSCVT. In offset X'04' of the
IEFJSCVT there is a pointer to the next IEFJSCVT.
c. If the eye-catcher is NETV, then in offset X'14' of the IEFJSCVT is the pointer to the NetView
subsystem DSISST.
6. After you find DSISST, locate offset X'F0'. This field is SSTTABPT, the pointer to the PPI trace anchor
block.
7. In offset X'2C' of the trace anchor block there is a pointer to the PPI trace table. In offset X'30' is a
pointer to the most current PPI trace record written to the trace table. The pointer points into the SSI
address space.
Locating the Oldest Program-to-Program Interface Trace Record

To locate the oldest trace record in the PPI trace table:
1. Use the pointer in the PPI trace anchor block or the pointer in the 12 byte header of the PPI trace table
to locate the most-current record written.
2. Scan backwards through the trace table, using the pointer field in the PPI trace record.

3. Stop when you find a record that does not point to the beginning of the previous trace record or that
points to a trace record that has a time stamp that is newer than the trace record at which you are
currently looking.
Generalized Trace Facility (GTF) Output Files

When you start GTF with an external option, the PPI trace records are written to a data set. The data set is
defined by the IEFRDER DD statement in the cataloged procedure that starts GTF. If IEFRDER is not
defined, the default output data set is SYS1.TRACE. Allocate the output data set before you start GTF. If
you create a new data set to be used by GTF, that data set must have a record length of at least 4096
bytes.
When using the Interactive Problem Control System (IPCS) to read the GTF trace records, you can use the
CNMS4501 sample supplied with the NetView product to format the PPI trace records. Sample
CNMS4501 can be run either as an IPCS GTF filter exit or an IPCS GTF formatter exit. To run CNMS4501
as an IPCS GTF filter exit, go to the IPCS command line and enter the following command:
GTF EXIT(CNMS4501) DSNAME(gtf_data_set_name)
To run CNMS4501 as an IPCS GTF formatter exit, link edit the CNMS4501 sample as IMDUSRDB into the
system link library, then go to the IPCS command line and enter the following command:
GTF DSNAME(gtf_data_set_name)
Figure 36 on page 156 is an example of the output from the CNMS4501 installation exit.
EYE CATCHER: ERR TIME STAMP: 11:12:10.290249

NUMBER OF BUFFERS LOST: 00000003
EYE CATCHER: INIT TIME STAMP: 14:12:10.290249

RECEIVER ID: RECVR001 ASID: 001A ASCB: 00FA1880 TCB: 007B1BE0
EYE CATCHER: SEND TIME STAMP: 14:12:27.886879

SENDER ID: RECVR002 ASID: 0019 ASCB: 00FB7180 TCB: 007B8270
BUFFER LENGTH: 00000018 FRAME NUMBER: 00000042
BUFFER DATA:
C4C1E3C1 40C2E4C6 C6406040 C4C1E3C1 | DATA BUFF - DATA |
40C2E4C6 C6 | BUFF........... |
EYE CATCHER: RECV TIME STAMP: 14:12:28.018974

BUFFER DATA:
40C2E4C6 C6 | BUFF........... |
EYE CATCHER: PURG TIME STAMP: 14:12:37.886801

BUFFER DATA:
40C2E4C6 C6 | BUFF........... |
EYE CATCHER: DELT TIME STAMP: 14:12:46.363692

EYE CATCHER: DISC TIME STAMP: 14:12:47.324700

RECEIVER ID: RECVR002 ASID: 0019 ASCB: 00FB7180 TCB: 007B8270
EYE CATCHER: ABND TIME STAMP: 14:12:49.365699

RECEIVER ID: RECVR003 ASID: 001B ASCB: 00FA1990 TCB: 007A2BE0
Figure 36. Example of the Output from the CNMS4501 Installation Exit

IP Management
Use Table 116 on page 157 to locate examples of problems you might encounter in the sysplex. To use
the table, do the following steps:
• Problem Category
Arranged alphabetically
• Problem Scenario
– Arranged (first) according to where the symptom shows
– (Then) arranged alphabetically
problem.
If you are unable to solve your problem by using the examples, follow the instructions in Chapter 2,
“Classifying problems,” on page 13 and Chapter 3, “Documenting and reporting problems,” on page 23
before contacting IBM Software Support.
Table 116. Sysplex Problem Scenarios

Problem
Category Problem Scenario Page
DVIPA No DVIPA configuration changes received “No DVIPA configuration changes
management received” on page 158
DVIPA No DVIPA statistics recorded “No distributed DVIPA statistics
management recorded” on page 159
DVIPA No data is returned from a DVIPA 3270 “No data is returned from a DVIPA
management command or its associated sample 3270 command or its associated
sample” on page 159
DVIPA A command issued with DOMAIN=ALL from a “A command issued with
management master NetView program returns incomplete DOMAIN=ALL from a sysplex master
data NetView program returns incomplete
data” on page 159
DVIPA Distributed DVIPA Connection Routing data is “Distributed DVIPA Connection
management incomplete in the workspace Routing data is incomplete in the
workspace” on page 159
OSA or OSA or HiperSockets data is not returned at a “OSA or HiperSockets data is not
HiperSockets NetView management console client. returned” on page 160
management
Stack and Data is not returned “IP interface data is not returned” on
Interface page 160
Management
Telnet The Telnet server port active connections “The Telnet server port active
management count is 0 connections count is 0” on page 160

Table 116. Sysplex Problem Scenarios (continued)
Problem
TCP/IP Expected zERT data is missing in the TEP or “Expected zERT data is missing in the
management not returned on the CONNSEC QUERY TEP or not returned on the CONNSEC
commands QUERY commands” on page 161
XCF services No data returned using LIST “No data returned using LIST
STATUS=XCFGRPS command STATUS=XCFGRPS command” on
page 161
XCF services BNH638I message issued per stack for “BNH638I message issued per stack
Discovery Manager Resource for Discovery Manager Resource” on
page 162
XCF services BNH587I message is received “BNH587I message is received
during NetView initialization” on page
161
XCF services PLEXCTL command fails “PLEXCTL command fails” on page
162
XCF services START XCFGROUP problems “START XCFGROUP problems” on
page 162
XCF services Discovery commands fail “Discovery commands fail” on page
162
XCF services BNH067I message is received; unexpected “BNH067I message is received;
switch of master NetView program unexpected switch of master
NetView” on page 162
XCF services BNH558E message is received; master “BNH558E message is received;
NetView program unable to contact enterprise master NetView unable to contact
system enterprise system” on page 163
No DVIPA configuration changes received

The NetView program can receive DVIPA configuration updates from z/OS Communication Server when
the TCP/IP profile is changed and when real-time sysplex updates occur.
If you do not receive DVIPA configuration changes from the z/OS Communications Server, do the
following steps:
1. If profile updates are not being received, check the following configuration statements:
• Make sure the z/OS Communications Server NETMONITOR SMFSERVICE PROFILE statement is
configured in the TCP/IP profile.
• Make sure CNMSTYLE is configured for automating z/OS Communications Server profile updates
using the following statement:
function.autotask.TCPSM.stackname=AUTOTCPS
Make sure that the z/OS Communications Server profile includes the NETMONITOR statement so that
profile updates are sent to the NetView program.
2. If real-time sysplex updates are not being received, make sure the z/OS Communications Server
NETMONITOR SMFSERVICE DVIPA statement is configured in the TCP/IP profile.
For information about configuring the NetView program to receive and process configuration updates
from the z/OS Communications Server, see IBM Z NetView Installation: Configuring Additional

Components. For more information about the NETMONITOR TCP/IP profile statement, see the z/OS
Communications Server IP Configuration Reference.
No distributed DVIPA statistics recorded

If no distributed DVIPA (DDVIPA) statistics are recorded, make sure that the NetView program is
configured to record statistics. Confirm the following:
• The CNMDVIPP and CNMDVIPS datasets are allocated (see the CNMSJ002 sample).
• The NetView startup procedure has the CNMDVIPP and CNMDVIPS DD statements coded (see the
CNMSJ009 sample).
• The NetView DVIPA tower and DVIPA.DVTAD subtower are enabled.
• DDVIPA statistics have been started using one of the following methods:
– Coding the Init.DVIPASTATS=Yes CNMSTYLE statement
– Issuing the DVIPALOG START command
For information about configuring the NetView program to record DDVIPA statistics, see IBM Z NetView
Installation: Configuring Additional Components.
No data is returned from a DVIPA 3270 command or its associated sample

If a particular DVIPA 3270 command (DVIPSTAT, DVIPPLEX, DVIPTARG, DVIPHLTH, DVIPCONN,
DVIPDDCR, or VIPAROUT) or its associated sample does not return data, first look for any error messages
returned for reasons for the failure. If there are no error messages, or if they do not suggest a resolution,
perform the following steps:
1. Make sure that the DVIPA tower and applicable subtower are active.
2. Use the applicable MVS D TCPIP,tcpip,NETSTAT command to verify that data is present.
A command issued with DOMAIN=ALL from a sysplex master NetView

program returns incomplete data
If a discovery manager or DVIPA command is issued with DOMAIN=ALL from a sysplex master NetView
program, and data is not returned from one or more domains that are not the sysplex master NetView
domain, perform these steps:
1. Issue a LIST STATUS=XCFGRPS command and make sure that the other systems in the sysplex are
active.
2. Issue a RMTCMD QUERY LCLAUTOS command from the NetView program for which no data is
returned.
3. Check the logs on both the master NetView program and the target NetView programs for error
messages and timeouts (by default a timeout can be as long as 5 minutes).
Distributed DVIPA Connection Routing data is incomplete in the workspace

If Distributed DVIPA Connection Routing data is incomplete in the Z NetView Enterprise Management
Agent (NetView agent) workspace, note these items:
• Identifying a connection as a sysplex distributor is dependent on the DVTAD subtower; therefore, make
sure that this tower is active and that sysplex distributor data is present. You can use a DVIPPLEX
command to help verify this.
• Some connections might not be identified until after the next data collection interval. Issue a COLLCTL
LISTINFO command and note the status of the DVIPA Connections and Distributed DVIPAs functions.
Chapter 7. Troubleshooting and initial diagnosis for IP Management 159

If possible, wait until after the next interval to see if the problem still exists. If it does, or if it is not
possible to wait, recycle both functions. Recycle Distributed DVIPAs before DVIPA Connections, with a
few seconds interval between the recycling of the Distributed DVIPAs and the recycling of the DVIPA
Connections.
OSA or HiperSockets data is not returned

If OSA data is not returned after you issue the OSAPORT command or the CNMSOSAP sample or if
HiperSockets data is not returned after you issue the HIPERSOC command or the CNMSHIPR sample,
check the following items:
• Verify that RODM is started.
• Ensure that the SNMP agent is configured and running.
• For OSA data, ensure that the OSA SNMP subagent is configured and running.
• Ensure that DISCOVERY.SNMP=YES is specified in CNMSTYLE.
• Look for the CNM249E or DSI047E message in the NetView log.
– If the CNM249E message is present, check the command to make sure that valid parameters and
values are specified.
– If the DSI047E message is present, ensure that the appropriate towers and subtowers are enabled in
the CNMSTYLE member. For more information about the towers and subtowers, see IBM Z NetView
• Issue the IFSTAT command or run the CNMSIFST sample and check to see if your OSA or HiperSockets
interface is displayed.
IP interface data is not returned

If data is not returned for the IFSTAT command or the CNMSIFST sample, check the following items:
• If you do not receive interface data or stack data:
– Ensure that the SNMP Agent is started
– Ensure that DISCOVERY.SNMP=YES is specified in CNMSTYLE.
– Look for the CNM249E message or the DSI047E message in the NetView log. If the CMM249E
message is present, check the command to make sure that valid parameters and values are
specified. If the DSI047E message is present, ensure that the appropriate towers and subtowers are
enabled in the CNMSTYLE member. For more information about towers and subtowers, see IBM Z
NetView Administration Reference.
The Telnet server port active connections count is 0

If your Telnet server port active connections count is 0, perform these actions:
• Verify that the port is not quiesced. If the port is quiesced, restart it.
• If the port was previously quiesced and then resumed, verify that the new connections were
established. If applicable, establish new connections.
• Issue a z/OS Communications Server DISPLAY TCP,tnproc,TELNET command to see all the
connections for the port. If applicable, enable any connections that were not established.
For more information about this DISPLAY command, see z/OS Communications Server IP System
Administrator’s Commands.

Expected zERT data is missing in the TEP or not returned on the CONNSEC
QUERY commands
If expected z/OS Encryption Readiness Technology (zERT) data is missing in the Tivoli Enterprise Portal
(TEP) or not returned on the CONNSEC QUERY commands, there are several possible problems.
The first check should be the status of data collection for the zERT function. It can be checked by issuing
LIST CONNSEC and examining the returned status. If the status is INACTIVE, there are several possible
reasons:
• Ensure that the CONNSEC subtower under TCPIPCOLLECT is enabled.
• Ensure that the CONNSEC-related statements in the CNMSTYLE concatenation that require a TCP/IP
stack name are using the correct stack name. The major statements are CONNSEC.KEEP and the
function.autotask.CONNSEC statements. By default, NetView program supports one TCP/IP stack with a
name of TCPIP. The default statements must be updated with the correct TCPIP name and additional
statements added for additional stacks.
• A CONNSEC START command has not been issued. Unless INIT.CONNSEC = YES is specified in the
CNMSTYLE statement or an included member, the CONNSEC command must be issued manually.
• CONNSEC START is failing. A common reason for this failure is misconfiguration in the TCPIP profile. If
the NETMONITOR and GLOBALCONFIG statement do not specify zERT support, the CONNSEC
command will fail with messages BNH601 and DSI416 indicating an AF/UNIX socket connection failure.
If this occurs, correct the TCPIP profile configuration and refresh TCPIP.
• The autotask needed for zERT may not be defined. The default autotask is AUTOCSEC for zERT.
If zERT data collection is active but data is missing, make sure that CONNSEC.KEEP statements are coded
that will collect the desired data. LIST CONNSEC will display the KEEP values in effect.
If zERT data collection is active, but data is not showing up in the TEP:
• Make sure that the required CONNSEC subtower under the TEMA tower is active.
• zERT data in the TEP also requires TCP connection data. Make sure that active TCP connection data
collection is enabled and active.
• Make sure NetView has an active connection with the TEMA.
No data returned using LIST STATUS=XCFGRPS command

If you do not receive any data when you issue the LIST STATUS=XCFGRPS command, or if the local
NetView is not listed as a member of a DSIPLXnn group, do the following steps:
1. Check the status of the DSIXCFMT task.
2. Issue the following command:
START XCFGROUP=DSIPLXnn,MEM=member_name
3. Check the log during NetView initialization for errors relating to the DSIXCFMT task or the START
XCFGROUP command.
4. Make sure the XCF.RANK CNMSTYLE statement is set to a value other than -1.
BNH587I message is received during NetView initialization

If you receive the BNH587I message when NetView initializes, do the following steps:
1. Check the XCF.RANK settings in the other group members.
2. Check the logs for errors relating to the existing master NetView program.

3. Operator intervention (the PLEXCTL command) can be used to change the master NetView program.
BNH638I message issued per stack for Discovery Manager Resource

If you have enabled TEMA subtowers SYSPLEX, TELNET, OSA, or HIPERSOCKETS and
• The Z NetView Enterprise Management Agent is not active
• There is a problem writing to the Z NetView Enterprise Management Agent data space
You receive the BNH638I message and the corresponding DWO050E message per stack per interval.
Note: This is not the case with DVIPA discovery. You receive message BNH638I and the corresponding
DWO050E message once per interval.
There is a problem writing to the Z NetView Enterprise Management Agent data space.
PLEXCTL command fails

If the PLEXCTL command fails, do the following:
1. Review the message help for BNH559E , checking the reason code values.
2. Check the XCF.RANK settings in the other group members.
3. Check the logs for errors relating to the existing master NetView program.
START XCFGROUP problems

If the START XCFGROUP command is hanging during NetView initialization, do the following steps:
1. Check the log for error messages about any GETADDRINFO failures.
2. Check the TCP/IP configuration.
3. Check for any TCP requests to obtain local IP address information, which can take a long time to
complete if the TCP configuration is in error.
4. Check for any DSIXCFMT issues.
Discovery commands fail

If discovery commands are not flowing to sysplex members after a master NetView changes, use the
QRYGLOBL command to check that the master NetView has dynamically defined the required RMTCMD
synonyms and aliases for the other sysplex members. The synonyms have the form
CNMSTYLE.RMTSYN.domain$$P.domain. The aliases have the form CNMSTYLE.RMTALIAS.domainP$X,
where domain is the NetView domain name at the non-Master sysplex member. If the variables are not
present, check the netlog at the master NetView program for DWO050E error messages for the XCF
component and DSIXCFPM module. Also check the netlogs on the remote system for DWO025I and
BNH167I error messages.
BNH067I message is received; unexpected switch of master NetView

If you received the BNH067I message, do the following steps:
1. Check the XCF.RANK statement for the sysplex members.
2. Check the logs on the NetView system of the new master to see if a PLEXCTL command was issued.
3. Issue LIST STATUS=XCFGRPS to find the Master.

BNH558E message is received; master NetView unable to contact enterprise
system
In an enterprise environment, the master NetView program attempts to contact the systems defined in
ENT.SYSTEMS statements in CNMSTYLE. If there is a connectivity problem, the BNH558E message is
issued. There should be related messages in the log pertaining to the underlying TCP/IP and SNA failure.
By default, the master NetView program attempts to contact the member periodically, so there might be a
number of these messages and any associated messages. (The default check interval is 1 minute; you can
configure this interval using the ENT.CONNCHECK.INT CNMSTYLE statement.) When the problem is
corrected, RESTYLE ENT can be issued to contact the system immediately.

Chapter 8. Diagnostic tools for IP Management
This chapter provides information about the various tools and commands available to assist the diagnosis
and debugging of problems with sysplex and IP management commands and functions.
CNMTRACE
CNMTRACE provides tracing information for host commands that are related to Z NetView Enterprise
Management Agent (NetView agent) functions, for 3270 DVIPA commands, and for some sysplex data
processing execs.
To see the DVIPA event (z/OS Communications Server DVIPA SNMP trap, DVIPA TCP/IP profile update, or
sysplex monitoring message) that you received and for which the NetView program is to rediscover DVIPA
information, enable the CNMTRACE.DVIPEVNT or CNMTRACE.DVIPEVNT.opid DEBUG option.
The following REXX exec can be used to control the CNMTRACE function:
/*
rexx
*/
/* This exec starts debug tracing for EMA-related and DVIPA host
commands. */
/* Input is as
follows: */
/* command , option,
opid */
/* The following commands are currently
supported: */
/* NACMD, DVIPSTAT, DVIPPLEX, DVIPTARG, DVIPCONN,
DVIPHLTH, */
/* DVIPDDCR, VIPAROUT, DVIPEVNT, COLLCTL, and
DVIPA. */
/* The following options are
valid: */
/* YES or ON : provides information upon entry and exit of the
exec */
/* DEBUG : provides YES-level information plus additional
debugging */
/* information such as data returned from data collector
execs. */
/* OFF or NO : turns off
tracing */
/* The opid parameter is optional; if omitted, all operator IDs will be traced.
If */
/* provided, only the opid provided will be
traced. */
arg input
parse var input cmd ‘,’ debugopt ‘,’ operid
if operid <> ‘’ then
operid = ‘.’||strip(operid)
'pipe lit /’debugopt’/ | var (common) cnmtrace.’cmd||operid
exit 0
RXTRACE
RXTRACE provides entry/exit and program trace capability for REXX execs and command lists. This
support is shipped in most IP management commands, as well as in other base NetView commands.
Tracing can be set for a single operator, all operators, or for a series of operators.

Use the RXTRACE command for control; note that by default this function is shipped with a setting of
NONE. To use the trace, a user must first choose option 3 on the RXTRACE panel to change the setting.
RXTRACE sends its output to the netlog using EZL260I messages.
Workspace issues
There are log and trace functions available on the workstation for issues related to the workspace.
For additional diagnostic commands, see Appendix A, “Diagnostic command summary,” on page 539.

Chapter 9. Diagnosing NetView problems related to
the GDPS Active/Active Continuous Availability
solution
This section provides information that you can use to diagnose and debug problems related to the GDPS
Continuous Availability solution.
Troubleshooting and initial diagnosis for the GDPS Continuous Availability

solution
Use Table 117 on page 167 to locate examples of problems when using the GDPS Continuous Availability
solution. To use the table, do these steps:
1. Locate your problem scenario in the first column and go to the indicated page for a description of the
problem and resolution steps for correcting the problem.
Table 117. Z NetView Enterprise Management Agent Problem Scenarios

Problem Scenario Page
Workspace problems Chapter 31, “Troubleshooting and initial
diagnosis for the Z NetView Enterprise
Management Agent,” on page 507
Event receiver task (EVENTRCV) problems “Multi-site Workload Lifeline product not
receiving EIF updates” on page 167
Enterprise master processing problems “Enterprise master processing problems”
on page 168
Problems related to automation “Problems related to automation” on page
169
Multi-site Workload Lifeline product not receiving EIF updates

If the Multi-site Workload Lifeline product is not receiving EIF updates from the NetView program, follow
these steps:
1. Verify that the Event/Automation Service (E/AS) event receiver task (EVENTRCV) is running and has
completed initialization.
• The program to program interface (PPI) and E/AS must be active. See the CNMSJ010 sample for an
example of the PPI procedure. See the IHSAEVNT sample for an example of the E/AS procedure.
• On a z/OS operator console, enter the MODIFY xxx,DISPLAY STATUS command, where xxx is the
job identifier assigned to E/AS.
• Review the IHS0143I message. Make sure that the status of the EVENTRCV task is UP and that a
NetView alert receiver and a port number are specified.
• If there are problems with the EVENTRCV task, see Part 9, “Diagnosing Event/Automation Service
problems,” on page 459.
2. Verify that the hardware monitor (NPDA tower) is active.

From the NetView operator command line, enter the LIST BNJDSERV command and make sure that
the status for the BNJDSERV task is active.
3. Verify that the NetView alert receiver task is active.
From a NetView operator command line, enter the DISPPI command. Verify that there is a DWO951I
message for the NetView alert receiver and that the status is ACTIVE. The default receiver name in the
IHSAECFG sample is NETVALRT. For information on configuring the NetView alert receiver, see the
CNMSTYLE member (Alert Receiver Name section).
4. Verify that the AQNCDS sample class definition statement member is included before any other class
definition statements defined for the EVENTRCV task.
• From a z/OS operator console, enter the MODIFY xxx, SETTINGS TASK=EVENTRCV command,
where xxx is the job identifier assigned to E/AS.
• Review the IHS0185I message and find the value of the AdapterCdsFile keyword. In the file
indicated by the IHS0185I message, make sure that the %INCLUDE AQNCDS statement is not
commented out. Make sure that the AQNCDS statement is located before any other class definition
statements. If not, then other class definition statements might be catching the EIF events and
discarding them, or mapping them to alert or resolve NMVTs that differ from those expected by the
NetView Active/Active functions.
5. Verify that the NetView MSU automation is correct for the NMVT alerts that the EVENTRCV task
produces.
Make sure that the applicable automation table statement or statements are present (see the
DSITBL01 sample and its included members). Then make sure that no automation table statement
coded or included before the statement or statements shown match the MSU and specify (or default
to) CONTINUE(N).
6. Verify that the autotask defined for the function name coded in the automation table statement or
statements is active. The default autotask name is AUTOAEVT, and the function name is ACTTSKEV.
For more information, see the function.autotask.ACTTSKEV statement in the CNMSTLIF
CNMSTYLE member.
7. Verify that the AQN047I message is not present in the Canzlog log.
8. Enable the CNMTRACE.ACTVEVNT option to see what information, if any, was sent to the Multi-Site
Workload Lifeline product. For more information, see “Diagnostic tools to use with the GDPS
Continuous Availability solution” on page 169.
Enterprise master processing problems

You might encounter problems when the enterprise master function used by the NetView program acts as
a controller system NetView program in the GDPS Continuous Availability solution. The NetView program
might be unable to become the enterprise master, or it might be unable to connect to all of the systems
that need to forward data to it.
If the NetView program is unable to become the enterprise master for Active/Active data, it logs message
AQN015E. This problem is typically caused by configuration errors, but can also occur when the NetView
program is not in the master role in its XCF group, or when another NetView instance has taken over as
enterprise master. These errors occur during NetView initialization or processing of a RESTYLE ENT
command.
To verify that the NetView program is in the master role, issue the LIST STATUS=XCFGRPS command, and
confirm that the ROLE column in the command output specifies M or EM.
If another NetView program is the enterprise master, BNH907I messages appear in the log.
The AQN015E message is typically caused by configuration errors. If the ACTIVEACTIVE tower and the
ACTIVEACTIVE.LIFELINE subtower are not enabled, the DSI047E message appears in the log.
Configuration errors can occur when the ACTIVEACTIVE tower and ACTIVEACTIVE.LIFELINE are coded,
but the required ENT statements are not valid or are missing.

Conversely, configuration errors can result if the ENT statements used by the GDPS Continuous
Availability solution are coded, but the ACTIVEACTIVE tower and ACTIVEACTIVE.LIFELINE subtower are
not enabled. In this situation, the possible configuration errors include the following:
• Missing or invalid ENT.TYPE statement
• Missing or invalid ENT.ACTIVEACTIVE.ROLE statement
• Missing ENT.ALT.CONTROLLER statement
• Missing ENT.SYSTEMS statements
Connectivity problems can generate messages in the log. Common messages related to RMTCMD include
the following:
• BNH604I
• BNH695I
• BNH719E
• BNH741I
If there are problems communicating with a system specified on an ENT.SYSTEMS statement, BNH558 is
also generated. Use troubleshooting procedures for TCP and RMTCMD to resolve these problems,
including investigation on the remote system if necessary.
You can use the output of the LIST STATUS=XCFGRPS command to identify the remote systems that are
forwarding data to the NetView program. In the case of severe connectivity problems, there might be no
systems forwarding data. If the NetView program is configured correctly and cannot detect another
enterprise master, the LIST STATUS=XCFGRPS output shows the NetView program as enterprise master.
Problems related to automation

Some functions for the GDPS Continuous Availability solution can fail if the automation provided by the
NetView program is not enabled.
Affected functions include the following:
• Automatic data collection for the Multi-Site Workload Lifeline product and replication products.
• Forwarding of replication EIF event information to the Multi-Site Workload Lifeline product and the
GDPS component.
• Monitoring of production system information.
• Automatic starting of the Tivoli Enterprise Monitoring server and NetView agent.
• Enterprise master remote communication between controller and production systems.
If a function related to automation is failing, verify the following:
• The DWO093W message has not been issued.
• The DSITBL01 automation sample is specified in the AUTOCMD list in CNMSTYLE.
• The NetView automation sample statements in the AQNSACTA sample are included in the automation
table.
• Cross-domain messages are allowed to flow from the production systems to the controller system.
Diagnostic tools to use with the GDPS Continuous Availability solution

You can use the CNMTRACE command to display information about alert automation processing of EIF
events that are received by the GDPS Continuous Availability solution. To enable or disable tracing, issue
the following PIPE command:
'PIPE LIT /option/ | VAR (COMMON) CNMTRACE.ACTVEVNT'
where option can be one of the following keywords:
Chapter 9. Diagnosing NetView problems related to the GDPS Active/Active Continuous Availability solution 169
DEBUG_1
Displays information that was sent to the Multi-site Workload Lifeline product from an EIF event. The
EIF event was sent from a replication product.
DEBUG_2
Displays information that was sent to the Multi-site Workload Lifeline product and to the GDPS
product from an EIF event. The EIF event was sent from a replication product.
OFF
Turns off debug tracing

Part 3. Diagnosing NetView Management Console and
GMFHS problems

Chapter 10. NetView Management Console problem
worksheet
Use the worksheet in this chapter to collect the information required to determine the cause of failures
within the NetView management console topology server and console.
If more information is required, an IBM Software Support representative can assist you in gathering it.
Copying these data sheets is permitted without payment of royalty if each reproduction is done without
alteration.
General information
The following information is required for all problems:
1. Date:
2. Problem Number:
3. Host
• Component ID:
• Recommended service update (RSU) level:
4. Workstation Service Level:
Note:
a. To determine the service level for NetView management console, see Environment Information in
the NetView management console online help.
b. To determine the service level for the topology console, refer to file TDS\client\bin
\duimnt01.gen
c. To determine the service level for the topology server, refer to file TDS\server\bin
\duimnt02.gen
1. The platform and level you are using:
2. The personal computer you are using:
3. How much memory is installed on your personal computer?
4. How many bytes of free disk space do you have for each drive being used?
5. Have you recently changed the system? If so, have you:
• Changed or added hardware?
• Applied software maintenance?
• Added user written code (plug-ins or Java™ applications)?
• Other changes?
6. The speed of the computer you are using:
Rename and save available workstation log files for later diagnosis.

Problem description
6. If you have more than one workstation, does the problem occur consistently on all workstations?
This section addresses the following problem classifications:
• Processor traps
• Message problems
• Loop problems
• Wait problems
• Incorrect output problems
• Performance problems
• Documentation problems
Look at the problem classification that matches the symptoms associated with your problem.
Processor traps
For abends or processor exception problems, respond to the following questions or tasks and, if
appropriate, record the answers:
1. What is the trap code?
2. What processes were taking place at the time of the abend or trap?
3. For the topology console, what is the Java stack trace for exceptions? Recreate the problem by setting
the TCONSOLE_JAVAOPTS environment variable to -Djava.compiler=NONE.
Message problems
For message problems, respond to the following questions and, if appropriate, record the answers:
• Message ID:
• Error codes:
2. Review the message in the NetView management console online help to determine user action.
• What processes were taking place when the message occurred?
– Commands:
– Other:
• If the message was unexpected and cannot be corrected by following the actions in the NetView
management console online help, collect the following documentation before calling IBM Software
Support:
– A copy of the appropriate workstation error logs. For the server, these files are in the %BINDIR
%/TDS/Server/log directory.

– The message ID:
– The exact text of the message as it is written in the log:
– A completed NetView management console problem worksheet
3. Did you follow the actions in the NetView management console online help? If so, document the
following information:
• What occurred?
management console online help, collect the following documentation before calling IBM Software
Support:
• A copy of the appropriate workstation error logs.
For the server, these files are in the %BINDIR%/TDS/Server/log directory.
• The message ID:
• The exact text of the message as it is written in the log:
• A completed NetView management console problem worksheet.
If so, has an update been made to the system that might have changed the message?
Loop problems (hang/lockup)

For loop or wait problems, respond to the following questions and, if appropriate, record the answers:
• The scenario leading to the problem.
5. If something hangs, proceed as follows:
• Topology console
For a topology console hang, obtain a Java Virtual Machine (JVM) thread memory dump.
• Windows
If Windows hangs, press CTRL-Break at a command prompt.
• UNIX
If UNIX hangs, issue kill -3 processid at a command prompt.
• Topology server
For a topology server hang, issue the following command:
tserver utility -f
6. What tasks were involved in the loop?
Wait problems
For wait problems, respond to the following questions and, if appropriate, record the answers:
Chapter 10. NetView Management Console problem worksheet 175

4. Collect the following documentation before calling IBM Software Support:
• A copy of the appropriate workstation error logs
• A completed NetView management console problem worksheet
5. What task was running when the wait occurred?
Incorrect Output problems

For incorrect output problems, respond to the following questions and, if appropriate, record the answers:
For performance problems, respond to the following questions and, if appropriate, record the answers:
4. Obtain a copy of the appropriate workstation error logs.
For documentation problems, respond to the following questions and, if appropriate, record the answers:
1. Identify the order number, revision level, and title of the manual.
2. Identify the location (chapter and section name) of the error in the manual.
For help panel problems, perform the following tasks:
1. Identify the location of the panel.
3. If the problem affects the operation or use of the NetView management console, call IBM Software
Support.

Chapter 11. Graphic Monitor Facility Host Subsystem
problem worksheet
This chapter contains the worksheet you can use to collect the information required to determine the
cause of failures within the Graphic Monitor Facility host subsystem (GMFHS).
alteration.
General information
1. Date:
2. Problem Number:
3. Component ID:
3. Other products and their maintenance level:
GMFHS information
1. Did the GMFHS data model load successfully?
2. Have you modified the GMFHS data model? If so, what was added or changed?
3. Did you receive a GMFHS message at the system console?
GMFHS messages are in the range between DUI3900-DUI4099 and DUI4200-DUI4499.
RODM applications
1. Are you running any other RODM applications?
2. Can you remove one or more RODM applications and re-create the problem?
RODM methods
1. Are you running any user-written methods with RODM? If so, which ones?

Problem description
• Changed or added hardware:
• Applied software maintenance:
• Other:
7. Can you recreate the problem with GMFHS tracing enabled?
• Abend problems (processor exception/trap/fault)
• Message Problems
• Loop Problems
• Wait Problems
• Incorrect Output Problems
• Performance Problems
• Documentation Problems
Look at the problem classification that matches the symptoms associated with your problem:
Abend problems (processor exception/trap/fault)

3. Collect the following documentation before contacting IBM Software Support:
• The first unformatted memory dump of the abend
• A completed GMFHS problem worksheet
• A copy of the GMFHS job output
• The GMFHS initialization member (DSIPARM member DUIGINIT)
• A copy of the RODM log
• The RODM checkpoint data sets (if applicable)
• The RODM loader input data sets and output listing (if applicable)
• The customization member (EKGCUST)
• The GMFHS data model and resource definition files
4. Collect the following information from the memory dump:
a. What was the program status word (PSW) at the time of the abend?

c. What date was the module compiled?
Message problems
• Message ID:
• Does the message contain any return codes, reason codes, feedback codes, error codes, or sense
information? List the codes or information.
2. Check the message in the online help to determine user action.
• Methods:
• RODM Load Utility:
• Other:
4. If the message was unexpected and cannot be corrected by following the actions in the online help,
collect the following documentation before calling IBM Software Support:
• A hardcopy of the network log
• The message ID:
• The exact text of the message on the log
• What occurred?
Loop problems
4. If this is a method loop (see “Documenting LOOP problems” on page 35), obtain the following
documentation:
Chapter 11. Graphic Monitor Facility Host Subsystem problem worksheet 179
• A document describing the scenario leading to the problem
• A hardcopy of the system log
• The addresses of instructions within the loop:
• A memory dump obtained by using the CPU RESTART function
Wait problems
• A copy of the system console log
• A copy of the system console memory dump
• A copy of any GMFHS trace output

2. What data (for example, a message or panel) is in error?
• A description of the events leading to the failure

• A copy of any GMFHS trace output
6. If expected messages do not display, have messages been filtered out:
• From MVS?
• A copy of the RODM trace
• A copy of the RODM log containing log record type 8 lock and storage statistics
• Information describing your RODM operating environment
• Descriptions of any modifications to your system
panel involved.
name.
Chapter 11. Graphic Monitor Facility Host Subsystem problem worksheet 181
NetView management console and GMFHS
This section provides problem scenarios and resolutions that you can use to locate examples of problems
you might encounter when using the NetView management console.
To use Table 118 on page 183, perform the following steps:
1. Locate your problem scenario by using the first two columns.
• Problem Category – Arranged alphabetically
• Problem Scenario – Arranged (first) according to where the symptom shows (then) arranged
alphabetically
problem.
Table 118. NetView management console and GMFHS Problem Scenarios

Problem
Alerts Alerts are not listed in the Event “Alerts are not listed in the Event Viewer at the
Viewer at the NetView management NetView Management Console Workstation” on page
console workstation. 186
Alerts are not listed in the hardware “Alerts are not listed in the Hardware Monitor Alerts
monitor alerts history panel. History panel” on page 186
Alerts do not change status. “Alerts do not change status” on page 186
Commands Cannot initiate an IP session when “Cannot initiate an IP Session using NETCONV” on
using the NETCONV command. page 188
Cannot initiate an LU 6.2 session “Cannot initiate an LU 6.2 Session using NETCONV”
when using the NETCONV command. on page 189
Command results are unexpected. “Command results are unexpected from Network
Management Gateways” on page 190
Commands failed to run because of “Commands failed to run because of COS Gateway
common operation services (COS) errors” on page 190
gateway errors.
Commands failed to run because of “Commands failed to run because of OST errors” on
operator station task (OST) errors. page 191
Commands failed to run because of “Commands failed to run because of PPI Gateway
program-to-program interface (PPI) errors” on page 191
errors.
Commands failed to run because of “Commands failed to run because of RODM Attribute
RODM attribute errors. errors” on page 191

Table 118. NetView management console and GMFHS Problem Scenarios (continued)
Problem
Commands failed to run because of “Commands failed to run because of Service Point
service point errors. errors” on page 191
Commands failed to run because of “Commands failed to run because of Time-out
time-out errors. errors” on page 191
GMFHS Errors are received during GMFHS “Errors are received during GMFHS Configuration
configuration initialization. initialization” on page 193
GMFHS Status solicitation fails. “GMFHS Status Solicitation fails” on page 193
Instrumentatio Component or connection status is “Component or Connection Status is not properly
n (z/OS-based not properly reflected on the topology reflected on the Topology Console” on page 194
only) console.
Events are not received from z/OS “Events are not received from z/OS Instrumentation”
instrumentation when using the on page 194
NETCONV.
Status Resource Status is incorrect. “Resource status is incorrect” on page 194
The resource exists but the status is “ The resource exists but the status is not updated”
not updated. on page 195
Multiple Init_Accept flows were “ Multiple Init_Accept Flows received” on page 196
received.
Status update performance “ Status Update performance decreases” on page
decreases. 196
Status Changes to Resources Are Not “ Status changes to resources are not reflected in
Reflected in Views. views” on page 196
Alerts Do Not Change Status. “Alerts do not change status” on page 186
GMFHS Status Solicitation Fails. “GMFHS Status Solicitation fails” on page 193
Topology Cannot open the topology console on “Unable to connect to the Topology Server from the
Console the Tivoli desktop or operating system Topology Console” on page 197
desktop.
Cannot navigate between correlated “Cannot navigate between Correlated Aggregate
aggregate object and contained object and Contained Resources” on page 212
resources.
Connectivity is not correct. “View does not show correct connectivity” on page
207
Duplicate GMFHS resource. “There Is a duplicate GMFHS resource on the
Topology Console” on page 198
Information displayed for correlated “Information displayed for Correlated Aggregate
aggregate object changes. object changes” on page 211
Missing resource. “View does not contain resource” on page 208
Missing resource icon. “Resource icon is missing from view” on page 204
Multiple correlated aggregate objects “Multiple correlated aggregate objects contain the
contain the same object. same object” on page 210

Problem
Pop-up menu in business tree is not “Pop-up Menu in the Business Tree is not displayed
displayed on AIX®. on AIX platform” on page 213
Problems occur with minimized “Problems occur with minimized Windows” on page
windows. 198
Property changes are lost. “Property changes are lost” on page 199
Real resource is not shown as a “Real resource is not shown as a member of a
member of a correlated aggregate Correlated Aggregate object” on page 211
object.
Topology console hangs during sign- “Topology Console hangs during Sign-on” on page
on. 198
Topology console hangs when “Topology Console hangs when accessing a view” on
accessing a view. page 198
Unable to connect to the topology “Unable to connect to the Topology Server from the
server from the topology console. Topology Console” on page 197
Unable to monitor views of your “Unable to monitor views of your network” on page
network. 207
Topology Server Incorrect timestamps when the “Incorrect timestamps if the Topology Server is on
topology server is on Windows. the Windows platform” on page 200
Topology server does not complete “Topology Server does not complete initialization on
initialization on AIX. AIX” on page 200
Topology server windows disappear “Server windows disappear on AIX platform” on
on AIX. page 200
View If your problem does not show in this
section, see the Topology Console
problem category.
Expected configuration or more Detail “Expected configuration or more detail view is
View does not exist. missing” on page 202
Resource icon is missing from view. “Resource icon is missing from view” on page 204
Tree view list is incorrect. “Tree View list is incorrect” on page 204
View layout is incorrect. “View Layout is incorrect” on page 205
Unable to open view. “Unable to open view” on page 206
Unable to monitor views of your “Unable to monitor views of your network” on page
network. 207
View does not show correct “View does not show correct connectivity” on page
connectivity. 207
View does not contain resource. “View does not contain resource” on page 208
Multiple correlated aggregate objects “Multiple correlated aggregate objects contain the
contain the same object. same object” on page 210
Real resource is not shown as a “Real resource is not shown as a member of a
member of a correlated aggregate Correlated Aggregate object” on page 211
object.
Chapter 12. Troubleshooting and initial diagnosis for NetView management console and GMFHS 185
Problem
Information displayed for correlated “Information displayed for Correlated Aggregate
aggregate object changes. object changes” on page 211
Cannot navigate between correlated “Cannot navigate between Correlated Aggregate
aggregate object and contained object and Contained Resources” on page 212
resources.
Alert and Alert History problems

The following sections describe problem scenarios and their resolutions for alert and alert history
problems. These are some potential problems:
• “Alerts are not listed in the Event Viewer at the NetView Management Console Workstation” on page
186
• “Alerts are not listed in the Hardware Monitor Alerts History panel” on page 186
• “Alerts do not change status” on page 186
Alerts are not listed in the Event Viewer at the NetView Management Console
Workstation
If alerts are not listed in the Event Viewer at the NetView management console workstation, perform the
following steps:
1. Check the hardware monitor Alerts History panel to determine whether the alerts are logged.
If the alerts are logged, verify that the resource hierarchy correctly maps to an ObjectID in RODM.
2. If the alerts correctly map to an ObjectID in RODM:
• Look to see if alerts might have been lost because of a high volume of alert traffic.
See “Alerts do not change status” on page 186.
• Look at the GMFALERT wrap count in the BNJMBDST DSIPARM member.
3. Ensure that the scope checker (DUIFSSCO) and hardware monitor (BNJDSERV) tasks are active.
Check the NetView log for messages related to these tasks.
Alerts are not listed in the Hardware Monitor Alerts History panel
Alerts are not listed in hardware monitor Alerts History panel.
1. Use the DFILTER (DF) command to display the hardware monitor alert recording filters. Alerts might
be filtered from being saved in the standard alert database. The alert filter table probably contains this
group of alerts.
2. Examine these filters to determine which alerts are being blocked. If necessary, you can use the
SRFILTER command to change the alert recording filters.

The DFILTER (DF) and SRFILTER commands NetView online help
Alerts do not change status

If the alerts that are displayed do not change status, one of the following conditions might be present:
• The alert does not properly identify the domain containing the alerted resource.

A domain in GMFHS is any valid combination of a service point, transaction program, and element
management system. The domain in GMFHS functions as the interface between the NetView program
and the network.
• The alert does not properly identify the resource.
• The alert processor module defined for the domain does not properly identify the resource in the alert.
The name of the alert processor module defined for the domain is in the AlertProc attribute of the RODM
Non_SNA_Domain_Class.
• Translation tables DUIFEIBM and DUIFEUSR were not loaded into GMFHS correctly, or they did not
contain a translation value corresponding to the alert type.
• The time stamp on the alert is earlier than the last reported update for a previous status change.
This situation can happen if the clock on the network management gateway is not synchronized with the
clock on the mainframe server. Console message DUI4218E or DUI4225E is generated indicating that a
status change has been rejected for a particular resource or RODM object identifier. Additional
information relating to this message is also sent to the active GMFHS output logs.
• The GMFHS component that manages status changes (VSTATMGR) cannot deliver the status update,
but the alert is available through an alert history request.
This situation is possible because these two processes are asynchronous.
• The system is receiving a high volume of alert traffic that exceeds the maximum number of messages
that are valid for a subtask queue.
If a high volume of alert traffic exceeds the valid maximum number of messages on a subtask queue,
GMFHS discards the excess messages to keep the queue from growing indefinitely. The discarding of
alerts by GMFHS is controlled by several GMFHS initialization parameters described in the resolution
steps. You can use these parameters to place limits on the size of the input queue on all GMFHS
subtasks.
• If the interprocess communications (IPC) component of GMFHS is unable to read the alerts from the
program-to-program interface (PPI) for the NetView program as quickly as the hardware monitor alert
automation command processor sends alerts to the PPI, the buffer queue in the PPI might become full.
If the PPI buffer queue is full, the command processor issues message DUI378I and does not attempt
to resend the alert, causing the status information in the alert to be lost.
To solve this problem, perform the following steps:
1. Check for message DUI4220E at the operator console.
This message indicates that the element manager cannot resolve the alert type to a status.
2. Determine whether there is an internal error or message for the VIEWMGR.
3. Ensure that the clock for the network management gateway (NMG) sending the alert is synchronized
with the mainframe server clock.
4. Verify that your RODM objects are named to correspond with the names in alerts.
5. If the domain is non-SNA, verify that you specified the correct alert processor modules for the domain.
6. Check for message DUI4253E at the operator console.
This message is generated when GMFHS discards messages because of the volume of traffic on the
system. The maximum volume GMFHS can handle is defined by the following initialization parameters:
• LCON-MAX-QUEUE-DBSERVER
• LCON-MAX-QUEUE-EVENTMGR
• LCON-MAX-QUEUE-IPC
• LCON-MAX-QUEUE-IRMGR
• LCON-MAX-QUEUE-MAINTASK
• LCON-MAX-QUEUE-NETCMD
• LCON-MAX-QUEUE-NETCON
• LCON-MAX-QUEUE-RCMGR
• LCON-MAX-QUEUE-RTMGR
• LCON-MAX-QUEUE-OPERIF
• LCON-MAX-QUEUE-VIEWMGR
• LCON-MAX-QUEUE-VSTATMGR
Use the GMFHS TASK command to determine which GMFHS task is causing the problem (the one with
the high queue depth). Use the GMFHS LISTINIT command to determine the current maximum queue
value for that task. Adjust the corresponding DUIGINIT parameter and recycle GMFHS.
7. Verify that dispatching priorities for the NetView program, GMFHS, and RODM address spaces are
defined so that the GMFHS address space has adequate processor cycles.

The DomainCharacteristics field IBM Z NetView Data Model Reference
Remote operations services Service Point Application Router and Remote
Operations Service Guide
How GMFHS identifies RODM objects using alerts IBM Z NetView Resource Object Data Manager and
How GMFHS identifies RODM objects using the IBM Z NetView Resource Object Data Manager and
alert processor module GMFHS Programmer's Guide
The GMFHS initialization parameters IBM Z NetView Administration Reference
Setting dispatching priorities z/OS MVS Initialization and Tuning Guide
The RUNCMD and GMFHS TASK commands NetView online help
Command problems
The following sections describe problem scenarios and their resolutions for command problems.
Potential problems can include the following:
• “Cannot initiate an IP Session using NETCONV” on page 188
• “Cannot initiate an LU 6.2 Session using NETCONV” on page 189
• “Command results are unexpected from Network Management Gateways” on page 190
• “Commands failed to run because of Service Point errors” on page 191
• “Commands failed to run because of RODM Attribute errors” on page 191
• “Commands failed to run because of COS Gateway errors” on page 190
• “Commands failed to run because of OST errors” on page 191
• “Commands failed to run because of PPI Gateway errors” on page 191
• “Commands failed to run because of Time-out errors” on page 191
Cannot initiate an IP Session using NETCONV

If you are unable to initiate an IP session with the NetView management console server workstation using
the NETCONV command, do the following:
1. Use NetView online help to determine the meaning of messages received after you issued the
NETCONV command. Follow the corrective action listed.
2. Verify that the ipid address or TCP host name entered on the NETCONV command or on the TAMEL
statement in the CNMSTYLE member is that of an attached server workstation.

3. If you specified the STARTCON keyword on the NETCONV command, verify that the ip_sysdef is
properly defined in the CNMSTYLE member.
4. Verify that the portnum on the PORT keyword entered in the NETCONV command is accurate.
5. Verify that all necessary tasks are active.
6. Verify that all physical and logical connections are established.
7. Verify that NetView management console communication server (for the workstation) is operational.
8. Verify that there is no problem with the IP connection between the workstation and the mainframe.
To verify, issue the PING command to the mainframe IP address or host name.
9. On the mainframe, verify these items:
• The DSIPARM member DUIFPMEM has the statement USETCPIP=YES
• In the CNMSTYLE member, the TAMEL.TCPANAME and GHB.TCPANAME definitions are set to the
MVS job name or identifier of the TCP/IP job
• The DSIPARM member DUIIGHB has TCPANAME= set to the MVS job name or to the identifier of
the TCP/IP job
10. Verify that the DSIPARM member DUIFPMEM statement PORT= matches the port number on the
tserver_390 statement in /etc/services on the workstation. Refer to the IBM Z NetView User's Guide:
NetView Management Console for more information.
11. Verify that the port number coded in DUIFPMEM is not within the range of ports described by the
INADDRANYPORT and INADDRANYCOUNT parameters in the BPXPRMxx member of SYS1.PARMLIB.
The typical symptom (when the port number coded in DUIFPMEM is within that range) is a bind
failure with error=48 for the CNMTAMEL in the network log.

The NETCONV and START commands NetView online help
Configuring TCP/IP z/OS Communications Server IP Configuration
Guide
z/OS Communications Server IP Configuration
Reference
Cannot initiate an LU 6.2 Session using NETCONV

If you are unable to initiate an LU 6.2 session with the server workstation using the NETCONV command,
1. Use NetView online help to determine the meaning of messages received after you issued the
NETCONV command. Follow the corrective action listed.
2. Verify that the luname entered in the NETCONV command is that of an attached server workstation.
To create dynamic logical units, specify DYNLU=YES in the start options member for this mainframe
server or on the START command for VTAM.
3. If you specified the STARTCON keyword on the NETCONV command, verify that the lu_sysdef is
properly defined in the CNMSTYLE member.
4. Verify that all necessary tasks are active.
5. Verify that all physical and logical connections are established.
6. Ensure that the connection to the mainframe server can support type 2.1.
7. Verify that the workstation topology communication server is operational.
8. Verify that there is no problem with the SNA Communications Server or SNA services configuration
and that an LU 6.2 session can be established with the mainframe server.
9. Verify that the logmode table in VTAM was updated or replaced to include support for LU 6.2
sessions.
If you replace the logmode table, replace it on the mainframe server that owns the physical unit. The
mainframe server that owns the physical unit is not necessarily the mainframe server issuing the
NETCONV command. If you updated the logmode table, ensure that VTAM has been restarted to
include the changes that were made.
10. If you are using an NCP to establish an LU 6.2 session, verify that you have a sufficient number of
independent logical units defined in the logical unit pool.
To define the number of independent logical units, use the NUMILU keyword on the LUDRPOOL
macro.
To create an LU 6.2 session, you might need to change the VTAM and NCP definitions. Verify that
these changes were made correctly.
11. See “INCORROUT” on page 15.

Updating the logmode table IBM Z NetView Installation: Configuring Additional
Components
The NETCONV and START commands NetView online help
Command results are unexpected from Network Management Gateways

If you issue a command or if a command is sent that is not effective, perform the following steps:
1. Verify the NMG and domain definitions for the service point.
2. Verify that the NMG and the domain are active by issuing the following GMFHS commands:
• SHOW NMG
• SHOW DOMAIN
3. Verify definitions for the command profile editor.
4. If the domain uses presentation protocol DOMP020, verify that the command text is written.
The command text can be written on the real resource object or the domain object.
5. Ensure that the transport protocol is consistent with presentation and session protocols.
6. Verify the scope and span of the resource.

The SHOW NMG and SHOW DOMAIN commands NetView online help
Commands failed to run because of COS Gateway errors

You receive a message indicating that there are common operation service (COS) errors.
1. Verify that the COS gateway autotask is active and DUIFCSGW is appropriately initialized on each
NetView the command passes through.
2. Verify that the RUNCMD processor DSIGDS task is active on each mainframe server that has an NMG
that the command goes through.
3. Verify that the COS gateway has not received errors from the DSIGDS task and that the DSIGDS task
can correspond with the service point application on the NMG.
4. Verify that the PU and LU are active on the destination NetView where the service point application
resides.

Commands failed to run because of OST errors
If you receive a message indicating that there are operator station task (OST) errors, perform the
following steps:
1. Verify that the operator is logged on to the NetView program.
2. Verify that the NetView operator console is active and available.
Commands failed to run because of PPI Gateway errors

If you receive a message indicating that there are NetView program-to-program interface (PPI) errors,
1. Verify that the PPI is active and available.
2. Verify that the address space in which the PPI gateway runs is active.
3. Ensure that the PPI gateway is activated as a PPI receiver with the name of the NMG_Class in RODM.
4. Use the GMFHS STATUS command to ensure that the PPI gateway is activated.

The GMFHS STATUS command NetView online help
Commands failed to run because of RODM Attribute errors

If you receive a message indicating that there are RODM attribute errors, perform the following steps:
1. Verify that RODM is started and the definition files loaded into RODM without errors.
2. Verify that GMFHS started without configuration errors.
If there are configuration errors, message DUI4004E is displayed at the operator console. Additional
information describing these errors is sent to the active GMFHS output logs.
3. Verify that the NMG and domain are correctly initialized for the command that was issued.
See the help panel for the message you received.
Commands failed to run because of Service Point errors

If you receive an error message because of a service point error, perform the following steps:
1. Verify that:
• The service point application is active.
• The service point has the same name specified under the TransactionProgram attribute of the object
of the Non_SNA_Domain_Class in RODM.
2. Determine that a session is established for the network management gateway (NMG) and domain
where that service point application resides.
Commands failed to run because of Time-out errors

If you receive a message that commands have timed out and are not being issued, perform the following
steps:
1. Verify that the time-out value specified in SERVER.PROPERTIES at the workstation is correct.
2. Verify that the CommandTimeoutInterval in RODM for the domain which the command was issued to,
is correct. If the CommandTimeoutInterval is not specified, the default is sent to the COS gateway (if
the COS gateway is the transport protocol) and used internally in the network command manager.
3. Verify that the service point application time-out value is correct (if it exists).
Timeout values specified in SERVER.PROPERTIES IBM Z NetView User's Guide: NetView Management
Console
Commands failed with IHS2069W message, Command Exit not installed

If you right click a command in the context menu on the NetView management console console and the
NetView management console console log window shows that the command fails with a message similar
to the following:
IHS2069W: An error has occurred while processing a command request.

The command exit was not installed.
Command: NetView390 Command Line...
Resource: None
Exit RC: X'8001'
Exit Parms: command_name=NetView390 Command Line...;
command_string=list khbude;
exit_name=IHSXTHCE;
exit_executable_name=;
exit_timeout=60;
wait_for_cmd_response=0;
want_corr_of_cmd_rsps=0;
correlation_id=0 1 14;
client_handle=X'050018';
client_ip_addr=X'FFFFFFFFFFFFFFF5';
server_ip_addr=X'2A2A2A2A2A2A2A2A';
signon_username=khbude;
op_id=KHBUDE ;
user_data_length=0;
user_ctrl_data_length=0;
IBM_menu_id=X'12';
extended_reason_code=X'00';
nv390_hostname=mvs1.ulm.tc;
nv390_ip_addr=10.62.40.247;
IBM_data_length=0
Perform the following steps:

• Verify that the NetView management console server was installed correctly and that the NetView
management console server is running.
• The problem might be that the NetView management console server is running on a workstation that
has multiple IP addresses. This can be because of Network Address Translation (NAT) or that you have
multiple network adapter cards installed on the NetView management console server workstation.
– When the NetView management console server is started, verify that the IP address is correct for this
workstation. You can do this by checking the first line in the command prompt window for the
NetView management console topology communications server. The first line contains the IP
address that the NetView management console server associates with the workstation.
– Check if there is another IP address associated with this workstation. If there is another IP address,
use the NetView management console server command tserver config -f x.x.x.x to notify the
NetView management console server of this alternate IP address. After executing this command,
recycle your NetView management console server. This enables the NetView management console
server to route the commands within the same NetView management console server workstation.
GMFHS problems
• “Errors are received during GMFHS Configuration initialization” on page 193
• “GMFHS Status Solicitation fails” on page 193

Errors are received during GMFHS Configuration initialization
Errors received during GMFHS configuration initialization might be an indication that you have unusable
RODM attributes defined for GMFHS. Error messages and additional error information are logged to one or
more GMFHS output logs, depending on which logs have been enabled. The GMFHS internal trace log is
the default GMFHS output log.
Misconceptions about which RODM attribute values are being loaded for GMFHS can occur if attributes
are defined at both the class level and object level.
If the attributes are defined at the class level, the values are used in GMFHS only if no object is defined for
that specific attribute. For example, the definitions shown in Figure 37 on page 193 are coded correctly.
Class level definition:
OP 'NMG_Class'..'TransportProtocolName' HAS_VALUE 'COS'
Object level definition:
OP 'NMG_Class'.'NMG_INST'.'TransportProtocolName' HAS_VALUE 'COS'
Figure 37. Examples for Correctly Defining RODM Attributes
Verify that RODM attributes are defined correctly.

Coding attribute options IBM Z NetView Data Model Reference
GMFHS Status Solicitation fails

If you receive message DUI4023E, which indicates a status solicitation failure for a particular domain, the
reason can be one of the following:
• The network management gateway (NMG) is not accessible.
• The domain capabilities, as defined in the RODM object representing the domain, do not match with the
real domain capabilities.
For example, the object is coded as having a session protocol of PASSTHRU and the real domain
supports protocol DOMS010.
• The RODM CommandTimeoutInterval field for the domain has a value that is too small to enable the
status solicitation response to be received before timing out.
1. Verify that the NMG managing the domain is active and capable of receiving GMFHS commands.
Even though a session might have been established with the domain (in the case of a DOMS010
session protocol), the domain might not have become inactive before the status solicitation was
completed.
2. Verify that the RODM definition for the domain entity correctly matches the actual domain.
3. If the preceding steps have been verified and the problem persists, increase the value of the
CommandTimeoutInterval field.
Instrumentation (z/OS-based only) problems

• “Events are not received from z/OS Instrumentation” on page 194
• “Component or Connection Status is not properly reflected on the Topology Console” on page 194
Events are not received from z/OS Instrumentation
The topology server does not receive events from instrumentation forwarded through the NETCONV
connection for the Topology Display Subsystem view. This can happen when the NETCONV connection is
not active or the Event/Automation Service is not configured.
To resolve this problem:
1. Verify that the NETCONV connection is active. Enter the following command at the NetView command
prompt:
NETCONV ACTION=LIST,OPID=ALL
Refer to the NetView online help for more information.

2. Verify that the correct automation table is active. Automation table DSIAMIAT must include member
DSIAMIN and member CNMSTDAT.
3. Verify the %INCLUDE DSIAMIN statement that is acting as the focal point.
To include the DSIAMIN member, uncomment the %INCLUDE DSIAMIN statement.
Component or Connection Status is not properly reflected on the Topology Console

The topology console does not properly reflect the component or connection status in the Topology
Display Subsystem view. This can occur if:
• The event connection between NetView and the topology server is not active.
• The APM_THRESHOLD event was not issued.
• The APM_THRESHOLD event did not match the business system definition.
1. Look in the netlog for message BNH352I (component monitor) or BNH353I (connection monitor) that
contains monitor name, subsource, origin, and suborigin values for the appropriate component
instance.
2. If the message is in the netlog, verify that the server is receiving the APM_THRESHOLD event. To do
this, see the ihsmessage.log for one of the following:
• The server is not receiving the APM_THRESHOLD event.
• The server is receiving the APM_THRESHOLD event.
• Either Message BNH352I or BNH353I is not in the netlog.
Status problems
The following sections describe problem scenarios and their resolutions for status problems:
• “Resource status is incorrect” on page 194
• “ The resource exists but the status is not updated” on page 195
• “ Multiple Init_Accept Flows received” on page 196
• “ Status Update performance decreases” on page 196
• “ Status changes to resources are not reflected in views” on page 196
• “Alerts do not change status” on page 186
• “GMFHS Status Solicitation fails” on page 193
Resource status is incorrect

If the status is incorrect, perform one of more of the following steps:
1. Where is the status coming from?

a. Verify that the resource is not a generic null link or generic null node.
These resources always have a status of unknown in a view.
b. Determine the origin of the status.
• If the status comes from alerts, ensure that the hardware monitor is active.
• If a GMFHS-managed real resource has an incorrect status, verify that the hardware monitor is
active on the focal point.
The hardware monitor must be active on every distributed system that supports service points
used to collect status for GMFHS-managed real resources.
• If the status comes from commands, perform one or more of the following steps:
1) Check the command response window to determine that command responses were received.
2) Ensure that the domain definitions for the service point are coded to accept
DisplayAbnormalStatus or DisplayStatus.
3) Check the RODM definitions file.
– Verify that you coded the initial status for the requested resources.
– Verify that the resource hierarchy of the alert received matches the RODM definitions.
2. Verify that applications that change fields used by GMFHS to determine status and parent
relationships are modified at the field level.
If these fields are modified at the subfield level, status changes or parent ownerships changes are not
known to GMFHS.
3. Verify that the following are active:
• Graphics task (CNMTAMEL)
• GMFHS
• RODM
4. Verify that a short-of-storage condition has not occurred at any of the central or distributed mainframe
servers involved for this resource.
5. Look at the NetView management console status area to verify that there was no communication
failure between the NetView program and the NetView management console server.
6. See “INCORROUT” on page 15 for information about classifying this problem.

The fields used by GMFHS IBM Z NetView Resource Object Data Manager and
The resource exists but the status is not updated

If a resource is displayed in a view, but its status is not updated, perform one of more of the following
steps:
1. Does this resource get its status from alerts?
If so, verify that the hardware monitor is active.
2. Check the NetView management console status area and verify that there was no communication
failure between the NetView program and the NetView management console server.
3. If a message is received that indicates GMFHS has discarded internal message buffers, it is possible
that the affected task queue is too small for the number of resources that must be processed.
4. Is the aggregation suspended?
5. See “INCORROUT” on page 15 for information about classifying this problem.
Adjusting subtask queue sizes IBM Z NetView Administration Reference
Multiple Init_Accept Flows received

It is possible for multiple Init_Alert flows to be queued at an NMG for a particular domain. This can
happen if the session protocol is DOMS010 and the domain has not received a focal point alert
authorization command from the mainframe server NetView program.
Alerts cannot flow to the NetView program (and through to GMFHS) until the domain receives this
authorization, but GMFHS continues (based on a timer) to attempt to establish a session with any domain
under the NMG. The alerts generated as a result of these requests stack up and flow to the mainframe
server when the domain receives the focal point alert authorization.
Although GMFHS ignores an Init_Alert flow for a particular domain if it is attempting to establish a session
with that domain, it is possible that Init_Alert flows are still arriving after the session is established. This
results in repeated attempts to establish a session, until there are no more Init_Alert flows to process.
This is not an error, but you can avoid the situation by following these steps:
1. Initialize the NMG.
2. Before you start GMFHS, issue a NetView FOCALPT authorization command for all domains that have a
DOMS010 session protocol.

The DOMS010 session protocol IBM Z NetView Resource Object Data Manager and
The FOCALPT command NetView online help
Status Update performance decreases

If the status is not being updated often enough with GMFHS-managed resources, the LCON-STATUS-
DELAY-TIME and the LCON-STATUS-DELAY-MAX initialization parameters are set too low or too high.
Use the LCON-STATUS-DELAY-TIME initialization parameter to control how often status updates are sent
to servers, and use the LCON-STATUS-DELAY-MAX initialization parameter to control the number of
status intervals a status update can be delayed for a resource whose status is changing multiple times.
These parameters are specified in DSIPARM member DUIGINIT.
1. If the status of resources is changing frequently, reduce the value of the LCON-STATUS-DELAY-MAX
parameter. This enables updates to occur more often.
Note: Recycle GMFHS for the change to take effect.
2. Monitor system performance and adjust these values as needed. This reduces the amount of time the
status updates are delayed.

GMFHS initialization parameters IBM Z NetView Administration Reference
Status changes to resources are not reflected in views

If you activate a resource using the right-click context menu, the console's log window shows that the
resource is now active; however, the object representing that resource in the view from which it was
selected does not show the status change.
This error can occur if the time in the command response received by GMFHS is earlier than the time kept
by the mainframe server on which GMFHS is running.

GMFHS initializes the DisplayStatus of the objects in RODM that represent resources using the mainframe
server time. If an alert or command response is received with an earlier time, the attempt to change the
DisplayStatus of the object to reflect the status reported in the command response or alert is rejected.
To solve this problem, ensure that the workstation clock corresponds to the focal point mainframe server
clock, not including the Greenwich Mean Time (GMT) offset.

Setting the GMTOFFSET statement in DUIGINIT. IBM Z NetView
Administration
Reference
Topology Console problems

• “Unable to connect to the Topology Server from the Topology Console” on page 197
• “Topology Console hangs during Sign-on” on page 198
• “Topology Console hangs when accessing a view” on page 198
• “There Is a duplicate GMFHS resource on the Topology Console” on page 198
• “Problems occur with minimized Windows” on page 198
• “Property changes are lost” on page 199
Unable to connect to the Topology Server from the Topology Console

The following message is received:
IHS1000W: Unable to connect to the server at host hostname
This message indicates one of the following problems:

• Incorrect host name
• No named server
• Named server is down
• IP socket port numbers for TCP/IP used by the topology server conflict with values specified in
hostname.
1. Ensure that you entered the correct host name and port number for the topology server to which you
are connecting.
2. Ensure that you can ping the topology server by host name.
3. Verify that the topology server started successfully.
Look in the ihsmessage.log file on the topology server for the following message:
The topology server version.release.point_release.fixlevel is initialized.
4. Verify the server port used for topology console communication. Look in the services file in one of the
following directories:
• Windows: %windir%\system32\drivers\etc
• UNIX: /etc
If the port number for topology console communication has been changed from the default setting,
4000, you must specify the port number on the NetView management console Sign On window each
time you sign on. Refer to the IBM Z NetView User's Guide: NetView Management Console for more
information.
Topology Console hangs during Sign-on

The topology console hangs when you attempt to sign on. This can happen when downloading files that
are greater than the maximum packets size of the token ring adapter. To resolve the problem change the
file packet size to 4096K.
Topology Console hangs when accessing a view

The console hangs when you attempt to open a view. This can happen if animated .gif files are used.
Verify that animated .gif files were not added to the ../client/icons directory. The topology console does
not support the use of animated .gif icons.
There Is a duplicate GMFHS resource on the Topology Console

A duplicate Graphic Monitor Facility host subsystem (GMFHS) resource named CNM01 is shown on the
topology console. If the topology server is connected to NetView through a NETCONV connection, the
Topology Display Subsystem view of the Systems Management Business System contains a resource
representing GMFHS.
If you did not perform the following steps, an additional GMFHS resource is shown:
1. Code a NetView domain name in the DUIGINIT initialization file.
2. Select the GMFHS resource.
3. Select Start GMFHS.
This occurs because GMFHS does not know the NetView domain name, so a default value of CNM01 is
used. Therefore, this resource has a different name from the original GMFHS resource.
1. Stop GMFHS on the MVS console and then restart it using the appropriate value for the DOMAIN=
keyword.
2. Modify the NetView Application Management interface initialization member DSIAMII to include the
appropriate NetView domain name. This is the value used by the NetView CLIST CNMETDTK.
CNMETDTK is invoked when GMFHS is started by the Start GMFHS menu option, for example:
INIT=CNMETDIN(GPARM,DOMAIN=domain_name)
where domain_name is the NetView domain name.

3. To remove the extra GMFHS resource from the Topology Display Subsystem view, right-click the
CNM01 version of GMFHS and RODM, and select Delete From All Views.
Problems occur with minimized Windows

The following problems occur when minimizing windows:
• Minimized windows are not restored when you click the window title in the Windows menu.
• Space is reserved for the windows when they are tiled or cascaded, but the minimized windows are not
restored to full size. This creates spaces in tiling or cascading.
• Minimizing the topology console window can make the system hang if something occurs that causes a
message to display.
These problems occur because of problems with the Java environment. Avoid minimizing the topology
console window for extended periods of time. Secondary windows that are minimized can be restored by
using the operating system mechanism for doing so. For example, in Windows, use the task bar.

Property changes are lost
If you close the topology console when Properties windows are open, property changes are lost. This is a
topology console limitation. Close all Properties windows before closing the topology console.
Topology Server problems

• “Server does not start and setup_env.sh is not found” on page 199
• “Setup_sh.cmd is found but BINDIR is not set” on page 199
• “Topology Server starts but then closes (Windows) ” on page 199
• “Topology Server does not complete initialization on AIX” on page 200
• “Server windows disappear on AIX platform” on page 200
• “Incorrect timestamps if the Topology Server is on the Windows platform” on page 200
Server does not start and setup_env.sh is not found

If the setup_env.sh file is not found, you see the following message and no updates are placed into the
ihsmessage.log:
rc(5902) setup_env_sh not found
To resolve this problem, perform the following steps:

1. Copy the setup_sh files from the \bin or /bin directory to the correct location for Windows, Linux, or
AIX:
• Windows: %WINDIR%\system32\drivers\etc\Tivoli
• Linux or AIX: /etc/Tivoli
2. Edit the file to ensure that the correct information is in place for the BINDIR environment variable.
$BINDIR\TDS\server\bin
3. If steps 1 and 2 do not resolve the problem, reinstall the server.
Setup_sh.cmd is found but BINDIR is not set

If the setup_sh file is found but the BINDIR is not set, the following conditions occur:
• The following messages are issued:
Tivoli environment variables configured.
The system cannot find the path specified.
• Neither of the server DOS, AIX, or Linux command prompt boxes is displayed
• No updates are placed into ihsmessage.log
To resolve this problem, make sure that the path is correct in the BINDIR variable
Topology Server starts but then closes (Windows)

If the "Act as part of the operating system" user rights are not set correctly, the following conditions
occur:
• The Communications Server starts.
• The topology server starts and then closes.
• The following message is placed in the ihsmessage.log file:
IHS2133I: The server must be run under a user ID that has 'Act as
part of the operating system' user right. The server is ending.
To resolve this problem, set the user rights correctly.
Topology Server starts but then closes (all platforms)

If the IHSX topology server process starts and then ends almost immediately, and no messages in the
ihsmessage.log file identify a problem, then the cause might be because of corrupted NetView
management console server databases. See the section about corrupted topology server databases in the
IBM Z NetView User's Guide: NetView Management Console for information about recovering from this
situation. If the problem persists, contact IBM Software Support.
Topology Server does not complete initialization on AIX

The following message is displayed in the server window, but the server does not start:
IHS2105I: Topology Server Starting
This can happen if interprocess communications (IPC) resources have not been cleaned up.
1. Stop the server processes.
Enter the following in a command prompt in the $BINDIR\TDS\server\bin directory:
tserver stop
2. Clean up any remaining IPC resources.

Enter the following sequence of commands:
tserver stop -f
tserver stop -f
3. Start the server.

Enter the following:
tserver start
4. If the server still fails to complete initialization, stop the server processes.
Enter the following:
tserver stop
5. Restart your workstation.
Server windows disappear on AIX platform

The server windows disappear right after starting the topology server. This can happen if you have an
incorrect level of the C runtime environment.
Incorrect timestamps if the Topology Server is on the Windows platform

If you are using Windows, and are in a timezone other than Eastern Standard Time (US), and the
timestamps that originate from RODM (such as the status timestamp) are incorrect, set the TZ
environment variable. This ensures that the timestamps are converted to the topology server's timezone.
This overrides the timezone to which Windows system is set.
To set the TZ environment variable, define the TZ environment variable:

• Select System from the control panel on the topology server workstation
• Select the Environment tab
The syntax of the time zone parameter is as follows:
SET TZ
SET TZ = xxxyyzzz
Where:
xxx
Is any three-letter time zone acronym (for example, EST for Eastern Standard Time, CST for Central
Standard Time, or PST for Pacific Standard Time).
yy
Is a one- or two-digit number that is the difference in hours between Greenwich Mean Time (GMT)
and the local time. If the local time is west of GMT, this number is unsigned. For example, the
following statement sets the time zone variable, TZ, for central standard time (CST), which is 6 hours
west of GMT.
Example for setting TZ to central standard time:
SET TZ=CST6
If the local time is east of GMT, this number has a preceding minus (-) sign. For example, the following
statement sets the time zone variable, TZ, for Germany, 1 hour east of GMT.
Example for setting the TZ variable for Germany:
SET TZ=CET-1
Use a negative (-) sign for the negative numbers, but do not use a positive (+) sign for the positive
numbers.
When you set this field, remember to take into account the setting of the time and time zone offset on
your NetView host. If you run your NetView host using the local time (instead of GMT) and a time zone
offset of 0, code a 0 for the offset on the workstation. If you do not code 0, the status timestamps are
correct. Set this value to the offset from GMT on your workstation only if you use GMT and a time zone
offset on your host.
To check the GMT setting on your host (and whether the local time is different) enter the MVS display
time command from a NetView operator screen, as shown below.
Example for checking the GMT setting on the host:
MVS D T
You receive a response similar to the following example.

Example of response from issuing the display time command:
IEE136I LOCAL: TIME=07.39.14 DATE=2009.181 GMT: TIME=12.39.14

DATE=2009.181
In the preceding example, the host is set for local time and the GMT time is 5 hours ahead of the local
time. You are on the East Coast of the United States and have your host set to local time with a time
zone offset of 0 (instead of using GMT with a time zone offset of 5). If you enter SET TZ=EST5 on the
workstation, to match GMT, your status timestamps are off by 5 hours because your host is set to
local time.
zzz
Is any 3-letter daylight saving time acronym. For example, Pacific Daylight Time is PDT. This is an
optional parameter. If you enter zzz, daylight saving time is calculated. If you are in a location that
does not have daylight saving time, do not use this parameter.
Note: When you set this field, remember to take into account whether your NetView host is always set
to the local time (with a time zone offset of 0), or if you are using GMT. If you do not use GMT (with a
time zone offset) on your host, do not use the daylight saving time acronym (if you adjust your host
time to take into account daylight saving time). For example, you are on the East Coast of the United
States and have your host set to local time with a time zone offset of 0 (instead of using GMT with a
time zone offset of 5). If you use SET TZ=EST0EDT, the status timestamps are off by 1 hour during
daylight saving time because the EDT setting causes an additional adjustment for daylight saving
time. In this situation, use SET TZ=EST0.
View problems
The following sections describe problem scenarios and their resolutions for problems with views:
• “Expected configuration or more detail view is missing” on page 202
• “Resource icon is missing from view” on page 204
• “Tree View list is incorrect” on page 204
• “View Layout is incorrect” on page 205
• “Unable to open view” on page 206
• “Unable to monitor views of your network” on page 207
• “View does not show correct connectivity” on page 207
• “View does not contain resource” on page 208
• “Multiple correlated aggregate objects contain the same object” on page 210
• “Real resource is not shown as a member of a Correlated Aggregate object” on page 211
• “Information displayed for Correlated Aggregate object changes” on page 211
• “Cannot navigate between Correlated Aggregate object and Contained Resources” on page 212
• “Pop-up Menu in the Business Tree is not displayed on AIX platform” on page 213
• “View problems” on page 202
• “The Topology Display Subsystem view is not complete” on page 213
The status area can indicate a change in the view without an actual change occurring. This can occur for
one of the following reasons:
• A customized view in the NetView management console server is customized and saved without any
actual changes occurring.
All consoles monitoring this view receive a message in their status area indicating the view definition
has changed.
• A change is made in RODM to alter a view followed by a change which restores the view to its previous
state.
If this occurs, the status area indicates that multiple changes have been made to the view. The view
remains the same when refreshed.
• A session between the mainframe and NetView management console server is temporarily
disconnected while non-customized views are opened.
When the session is restored, the status area of each non-customized view indicates a change whether
the view has changed.
• A change is made in RODM to a GMFHS presentation data model attribute which changes the definition
of a view without modifying the view display.
Expected configuration or more detail view is missing

The requested configuration or more detail view is missing. To determine if this might occur, ask the
following questions:

• Was this view generated by GMFHS? If so, one of the following conditions might exist:
– You have not correctly defined the view in the RODM view definition file.
– The RODM view definition file did not load with a return code of 0.
– The operator is not authorized to display the view.
In this case, the operator receives an error message.
• Was the view created in RODM by a topology manager? If so, one of the following conditions might
exist:
– SNA topology manager
- The SNA topology manager autotask named FLBTOPO is not started.
- The SNA topology manager is not monitoring sufficient topology in your network.
- The following monitoring problems occurred:
• The SNA topology manager was previously monitoring the relevant topology in your network.
• The monitoring was stopped.
• A TOPOSNA PURGE command was run that deleted the relevant resources from RODM.
- The operator is not authorized to display the view. In this case, the operator receives an error
message.
– MultiSystem Manager
The following monitoring problems occurred:
- The MultiSystem Manager was previously monitoring the relevant topology in your network.
- The monitoring was stopped.
- Because monitoring stopped, updates to resources in your network did not occur.
The operator is not authorized to display the view. In this case, the operator receives an error
message.
These are the steps for all views:
Ensure that the span-of-control definitions for NetView management console views are correctly defined
by reviewing the following items:
1. Does the SPANAUTH keyword specify to use the NetView span table?
2. Does the CTL attribute for the operator give the operator authority to control resources and views?
3. Does the NGMFVSPN attribute for the operator specify to apply span-of-control for view names,
resource names, or both?
4. Do the spans that are active for the operator include the view names, the resource names, or both?
View and resource names are specified with SPANDEF statements.

Using the SPANAUTH keyword, the SPANDEF IBM Z NetView Security Reference
statement, and the CTL and NGMFVSPN attributes
These are the resolution steps for views generated by GMFHS:

1. Ensure that the RODM definition file loaded with a return code of 0.
2. Determine that you have correctly defined the view in the RODM definition file. Review the following
fields in the RODM definition file:
• For more detail views:
– ComposedOfLogical
– ComposedOfPhysical
• For configuration views:
– ParentAccess
– ChildAccess
– PhysicalConnPP
– PhysicalConnUpstream
– PhysicalConnDownstream
– LogicalConnPP
– LogicalConnUpstream
– LogicalConnDownstream
Finding the exact field to check depends on the exact view type requested. However, you must define at
least one of these fields for the resource. These are the resolution steps for views created in RODM by the
SNA topology manager:
1. Verify that the SNA topology manager autotask named FLBTOPO has started.
2. Verify that the SNA topology manager is monitoring the relevant topology in your network.

Tuning procedures IBM Z NetView Tuning Guide.
Loading RODM view definitions IBM Z NetView Resource Object Data Manager and
Resource icon is missing from view

The resource icon is missing from the view but is represented by a red X icon. This can happen when you
specify an unusable DisplayResourceType for a resource of a particular class.
Ensure that the RODM definition file loaded with a return code of 0. If RODM view definitions did not load
with a return code of 0, refer to the IBM Z NetView Resource Object Data Manager and GMFHS
Programmer's Guide.

Tree View list is incorrect

The tree view list can be incorrect because:
• RODM is not loaded properly.
• Span-of-control limits the view list of the operator.
• GMFHS is not available.
• There is a problem with a network view collection definition object that you created for use by the
RODM Collection Manager facility of GMFHS.
1. Ensure that the RODM view definitions are correct and loaded with a return code of 0.
If RODM view definitions did not load with a return code of 0, refer to the IBM Z NetView Resource
Object Data Manager and GMFHS Programmer's Guide.
2. Ensure that all of the following are true:
• The NetView management console session is active
• GMFHS is available
• Any manager you are communicating with is still available

3. Ensure that the span-of-control definitions for NetView management console views are correctly
defined by checking the following:
a. Does the SPANAUTH keyword specify to use the NetView span table?
b. Does the CTL attribute for the operator give the operator authority to control resources and views?
c. Does the NGMFVSPN attribute for the operator specify to apply span-of-control for view names,
d. Do the spans that are active for the operator include the view names, the resource names, or both?
4. Verify that the view name (MyName field of the view object) of the missing view is not greater than 32
characters.
If the view name is greater than 32 characters, it is omitted from the tree view. An entry is written to
the RODM log that specifies which view or views were omitted from the tree view and why they were
omitted.
5. For Exception Views, look for duplicate ExceptionViewNames.
If more than one view object has the same ExceptionViewName, only one of the views is displayed in
the graphical list. An entry, which specifies the view or views that were omitted from the tree view, is
written to the RODM log. If the view was omitted because of a duplicate ExceptionViewName, an entry
is written to the RODM log indicating the value of the ExceptionViewName field of the view omitted
from the tree view.
6. For network view collection-definition objects, look for the following situations and take action if
appropriate:
• If the collection definition object was loaded after GMFHS was started, the Trigger field of the object
must be set to any value in order for GMFHS to process the object.
This is not a problem if the object was created by the RODM Collection Manager wizard of the
NetView management console.
• Check for errors that the RODM Collection Manager facility might have encountered while processing
the collection definition object.
If there is an error that prevents the network view from being created, system console messages are
logged. If the collection definition object was created by the RODM Collection Manager wizard of the
NetView management console, a pop-up message displays if there is a problem creating the network
view.
• If the collection definition object was created by the RODM Collection Manager wizard of the
NetView management console and saved to a file for use by the RODM loader, make sure that the
RODM loader was used to load the object definition into RODM.
This is a problem only if RODM was recycled after the collection definition object was created by
NetView management console wizard.

View Layout is incorrect

If the requested view layout is incorrect, you receive error messages at the NetView management console
console informing you that you omitted or incorrectly specified layout parameters.
For example, you might have specified a layout parameter list that contains the correct layout parameters
for the resource in question, but you might have linked the layout parameter list to the wrong view object.
If this happens, RODM loads with a return code of 0, but the layout parameters apply to the wrong view.
Note: A displayable object might be linked to several layout objects.
GMFHS uses only the one layout object that is common between the layout object list associated with the
displayable object and the layout object list associated with the view. In general, a displayable object
might link to any layout object as long as only one of the layout objects are linked to any given view
object. Default layout parameters are used if more than one layout object is found.
If you follow the resolution steps and both of the following statements are true, you might have
incorrectly specified optional layout parameters:
• The view still does not lay out correctly.
• There are no additional error messages.
To resolve the situation,
1. Perform the action specified by the error panels.
2. Ensure that the layout parameters are coded correctly.
3. Ensure that layout parameters are correctly linked to the view object.

Optional layout parameters IBM Z NetView Resource Object Data Manager and
Unable to open view

If NetView management console issues an error message (for example: GC_BAD_HEADER_VIEWSIZE)
when you attempt to open a view, the view cannot be displayed. This can happen if any of the following
conditions exist:
• Your view is too complex to be displayed by NetView management console.
• You are not authorized to display the view.
• You are not authorized to display any of the resources in the view.
• You selected the Locate Resource option for a resource you are not authorized to display.
• You selected the More Detail option for a resource you are not authorized to display.
To resolve the problem, perform the following steps:
1. Use the message to determine the cause of the error.
2. If the view is too large for your screen, perform the following steps:
a. Reduce the number of nodes in your view.
b. Reopen the view.
defined by looking for the following situations:
4. If the problem persists, call IBM Software Support for programming assistance.

Unable to monitor views of your network

If you are unable to monitor views of your network, perform the following steps:
1. Ensure that GMFHS is active.
2. Ensure that RODM is active.
3. Ensure that the RODM definition file was loaded into RODM without errors.
defined by checking the following:

To resolve problems with views generated by GMFHS, perform the following steps:
1. Did the RODM definition file load with a return code of 0?
2. See “Incorrect output problems” on page 48.

View does not show correct connectivity

The view displayed does not contain a resource that is part of your network.
by checking the following:

To resolve problems with views generated by GMFHS, perform the following steps:
2. See “Incorrect output problems” on page 48.

View does not contain resource

The view displayed does not contain a resource that is part of your network.
by checking the following items:

To solve problems with GMFHS views, including views that were created with the RODM Collection
Manager facility of GMFHS, follow these steps:
1. Verify that all required tasks are active.
If RODM view definitions did not load with a return code of 0, refer to the IBM Z NetView Resource
3. Determine whether you have correctly defined the view in the RODM definition file.
Look at the following fields in the RODM definition file:
• For More Detail views, review the following:
– ComposedOfLogical
– ComposedOfPhysical
• For configuration views, review the following:
– ParentAccess
– ChildAccess
– PhysicalConnPP
– PhysicalConnUpstream
– PhysicalConnDownstream
– LogicalConnPP

– LogicalConnUpstream
– LogicalConnDownstream
• For network views, perform one of more of the following steps:
– Determine whether the view object is defined.
– Ensure that the ContainsObjects field is present with the list of resources in the view.
4. Check the RODM log for error messages.
5. For network view collection-definition objects, look for the following situations:
• Check the collection specification that you gave for the collection definition object.
The collection specification was either created from information that you selected from the RODM
Collection Manager wizard of the NetView management console or if you specified it directly (if you
did not use the NetView management console wizard).
• The object in question might not have been created in RODM or it has been deleted from RODM.
6. If the object that is missing is a GMFHS_Aggregate_Objects_Class that was created from a collection
definition object, look for the following situations and perform any of these actions::
• If the collection definition object was loaded after GMFHS was started, the Trigger field of the object
must be set to any value in order for GMFHS to process the object.
This is not a problem if the object was created by the RODM Collection Manager wizard of the
NetView management console.
• Check for errors that the RODM Collection Manager facility might have encountered while processing
the collection definition object.
If there is an error that prevents the network view from being created, system console messages are
logged. If the collection definition object was created by the RODM Collection Manager wizard of the
NetView management console, a pop-up message displays if there is a problem creating the network
view.
• If the collection definition object was created by the RODM Collection Manager wizard of the
NetView management console and saved to a file for use by the RODM loader, make sure that the
RODM loader was used to load the object definition into RODM.
This is a problem only if RODM was recycled after the collection definition object was created by
NetView management console wizard.
• The aggregate object can be part of an aggregation hierarchy loop. This error might not be detected
until after the aggregate object has been successfully created and is dependent on collection
specification. Messages are placed in the RODM log if a hierarchy loop error is encountered on any
aggregate object.
To resolve problems with SNA Topology Manager views:
1. Verify that the SNA topology manager autotask named FLBTOPO is started.
2. Verify that the SNA topology manager is monitoring the relevant topology in your network. See Chapter
21, “Troubleshooting and initial diagnosis for the SNA Topology Manager,” on page 323 for additional
diagnostic information relative to SNA topology manager resource monitoring.

Loading RODM view definitions or fields in the IBM Z NetView Resource Object Data Manager and
RODM view definition file GMFHS Programmer's Guide
To solve problems with Exception views, perform the following steps:

1. Verify that the view is current.
If necessary, refresh the view.
2. Ensure that the NetView management console session is active.
If communicating with a topology manager, ensure that the manager is available.
3. Look for the following conditions:
• The ExceptionViewList field on the resource object matches the ExceptionViewName field on the
view object.
• The ResourceTraits field on the resource object contains values that map to the ExceptionViewFilter
field on the view object.
To determine if either the ExceptionViewList or the ExceptionViewFilter field is incorrect, change the
ExceptionViewFilter field on the view object to X'0000'.
• If the resource object is now displayed in the view, your previous ExceptionViewFilter field was
filtering the object out of the view.
Ensure that the DisplayStatus, UserStatus, and ResourceTraits fields of the resource object are as
you expected.
• If the resource object is still not displayed in the view, compare the values in the ExceptionViewList
field on the resource object to the ExceptionViewName field on the view object.
Most likely, there is not a match.
4. Changing the ExceptionViewList at the class level does not trigger updates to exception views, even
though the change is made.
A message is written to the RODM log to inform you of this situation. Close and reopen the view to see
if a class level change caused any updates.
5. Ensure that the DisplayResourceType field for this resource object is defined correctly.
If the DisplayResourceType field is incorrect, the resource object cannot be displayed in the view.
Different results are received, depending on the view being open or closed.
For example, assume that you have an exception view with an ExceptionViewName value of FAILURE.
You create a resource object and change the ExceptionViewList field of the resource object to
FAILURE, but the DisplayResourceType of this resource object is defined incorrectly and cannot be
displayed in the view:
• If the exception view is open, a message is written to the RODM log indicating the failure of the
update.
• If the exception view is closed when the view is opened, a message is written to the RODM log and
the workstation issues message DUI1700I stating the view is not complete.
Multiple correlated aggregate objects contain the same object

Multiple correlated aggregate objects contain the same object. The most common cause is that non-
unique or incomplete data was sent from the agent and, depending upon the causes of the multiple
aggregate, you might be able to change the sequence of topology reporting or topology acquisition
(GETTOPO and TOPOSNA commands) to eliminate this situation, which might be caused by the following
conditions:
1. Multiple agents monitoring the same resource
This can be resolved if the correlated aggregate was created by the Tivoli management region in the
MultiSystem Manager components. See the IBM Z NetView User's Guide: NetView Management Console
This problem can be resolved by making changes at a distributed topology agent (for example, an IBM
Tivoli Network Manager agent).
2. A managed resource that contains multiple LAN adapter cards (multiple MAC addresses) or multiple IP
addresses.
To prevent these conditions, ensure that every distributed manager specifies the same primary MAC
address and IP address for a managed resource.

3. A situation where some agents report incomplete information about network addresses for a real
object.
You might be able to reduce the number of correlated aggregates for the same object by changing the
sequence of topology acquisition. See the IBM Z NetView User's Guide: NetView Management Console
for more information about this process.
Real resource is not shown as a member of a Correlated Aggregate object

A real resource is not shown as a member of a correlated aggregate object in which it is installed.
This problem is usually encountered when the agent provided a limited set of network addresses for the
real resource.
To display the resource, perform the following steps:
1. Ensure that the topology correlation function is running.
This can be accomplished by ensuring that the FLCSDM8 file is loaded during the RODM structure load.
If the topology correlation function is not running, real resources are not contained in the correlated
aggregate objects
.
2. Determine if the real resource was correlated to a different aggregate by performing the following
steps:
• Select the real resource.
• Select Configuration -> Parents.
• Examine Resource Properties, Data2 fields for the correlated aggregate.
• If a network address is displayed that matches a network address (that was displayed in the original
correlated aggregate), you might be able to contain the real resource in the correlated aggregate
where you want it to show.
To do this, change the sequence in which GETTOPO and TOPOSNA commands are issued. See the
IBM Z NetView User's Guide: NetView Management Console for more information about the topology
correlation function.
3. Determine whether the agent provides a network address for the real resource by performing the
following steps:
• Select the real resource
• Select Resource Properties
• Examine the Data2 fields.
If no MAC address or IP address is shown, the agent probably did not provide sufficient information
for the real resource to be correlated.
• If a MAC address or IP address is shown and the Configuration-Parents navigation did not display a
correlated aggregate, report the problem to IBM Software Support.
Note: The correlation is not based in the Data2 field (DisplayResourceOtherData) in RODM. It is based
upon the aIndMACaddress and the IP address fields in RODM. If the feature that discovered the real
resource did not fill in either of those two fields, but it did fill in the Data2 field, topology correlation does
not work on the real resource.
This situation might occur when you are using a custom application, such as an application provided by a
Tivoli partner. If so, ask the application developer to enable support for the topology correlation function
as described in the IBM Z NetView Resource Object Data Manager and GMFHS Programmer's Guide.
Information displayed for Correlated Aggregate object changes

The name, type, or Data2 (DisplayResourceOtherData) for correlated aggregate object changes after the
object is created. If another resource object is correlated to the aggregate, information displayed for
correlated aggregate objects can change. The aggregate object learns more about its contained resources
and connectivity with each additional correlation.
This new or learned information can add to the information displayed in the Data2 field. Based upon
default settings, it can also change the name or type of the aggregate objects. You can change some of
these defaults.
Refer to the IBM Z NetView Resource Object Data Manager and GMFHS Programmer's Guide for more
information.
Changes to this data occur in the following manner:
1. New information is appended as it is discovered.
The displayed Data2 does not lose information. Even if a newly correlated resource provides a
different value, initial values for a text field (for example, Address=2.78.326.73) do not change.
Note: The only way to alter the displayed additional information in Data2 is to have your systems
administrator stop loading the topology correlation function.
2. The Resource Type of the correlated aggregate can change, based upon the field used to correlate
objects to the aggregate.
• If the first field used for correlation is LAN MAC address, the initial Type is LAN workstation
aggregate.
• If the field used is IP address, the initial Type is IP System Aggregate.
• If correlation is by the (free-form) Correlator field, the Type is Open System Aggregate.
• If resources that are monitored by different agents are correlated (a cross-correlation), the Type is
Open System Aggregate.
• To alter the Resource Type displayed, change the sequence in which GETTOPO or TOPOSNA
commands are issued. For more information, see IBM Z NetView Installation: Configuring Graphical
Components.
3. The Resource Name (on-screen name) of the correlated aggregate can change as new objects are
correlated to it.
Name changes are determined in one of the following ways:
• Based upon naming preference
• Defined by your systems administrator
• Left to the default preferences
This behavior can be customized to meet your needs.
Refer to the IBM Z NetView Resource Object Data Manager and GMFHS Programmer's Guide or the
FLCSDM8 customization file for more information.
Cannot navigate between Correlated Aggregate object and Contained Resources

Resource Information for the aggregate shows more resources than are displayed as you navigate
through More Detail or Configuration Child views. This problem can occur if multiple objects have
correlated to an aggregate.
To solve the problem, perform the following steps:
1. If More Detail navigation from the aggregate does not show all expected resources, use Configuration
Child navigation instead.
2. If Configuration Child navigation from the aggregate does not show all expected resources, use More
Detail navigation instead.
3. If neither of these solutions meets your needs, ensure that all PTFs that affect Topology correlation
have been applied.
4. If step 3 does not meet your needs, report the problem to IBM Software Support.

Be sure to indicate the following information:
• The view navigation that was missing
• Resource types related to this problem
• The SEQUENCE of GETTOPO or TOPOSNA commands issued
Note: For more information about topology correlation operations and how you can customize them,
see the IBM Z NetView User's Guide: NetView Management Console and the IBM Z NetView Resource
Pop-up Menu in the Business Tree is not displayed on AIX platform

The business tree is displayed in white text on a white background. This can occur if the color scheme is
set to white on the desktop. To correct this, select a color scheme other than white.
Preview Image partially painted in View Properties Notebook

When selecting a background image from the View Properties notebook, the preview area paints only half
of the image. This is a topology console limitation. To paint the full image, select another background
image and then return to the original one.
The Topology Display Subsystem view is not complete

The topology display subsystem view does not show the NETCONV connection, GMFHS, RODM, and the
RODM managers. This can happen when the instrumentation on IBM Z NetView has not been enabled. To
resolve this problem, enable the instrumentation on IBM Z NetView that populates this view. For more
information, refer to the IBM Z NetView Customization Guide.
Chapter 13. Diagnostic tools for NetView
Management Console and GMFHS
Diagnostic tools for the NetView Management Console

The NetView management console provides various log files that capture processing information and can
help you identify where a problem occurred. Other sources of information, such as the Environment
Information window on the topology console can also help you determine the cause of a problem. This
chapter summarizes these problem determination aids.
Log files
The following table lists where to look for messages related to the:
• Topology server
• Topology console
Table 119. Network Management Console Log Files

Problem Area Where to Look
topology server The ihserror.log, ihsmessage.log, and the ihsecped.log files are located in one of
the following directories:
• For Windows: %BINDIR%\TDS\server\log
• For UNIX: $BINDIR/TDS/server/log
The ihserror.log file contains messages that provide diagnostic information. If you
want to contact IBM Software Support for help, you might need to provide the
ihserror.log file. The ihsecped.log file contains messages from the CPEBATCH
utility.
Start the topology server with the -b option to write additional information to the
ihsmessage.log file. You can obtain help for messages logged in the
ihsmessage.log file.
To interactively control the logging of additional instrumentation information, use
the TSERVER utility from a command prompt on the topology server workstation
(enter -b on|off). Refer to the IBM Z NetView User's Guide: NetView Management
Console.
Note: You might find it useful to delete the ihsmessage.log before logging
additional information so that you look only at the most current messages
pertaining to the topology server.
topology console The topology console log displays the messages received, the commands that
have been entered, and the responses to the commands. To display the log in the
topology console window, from the topology console menu bar, select Options —
Show Log. The log can be saved in a file at the server or on the console. For more
information, refer to the online help or to the IBM Z NetView User's Guide: NetView
Management Console.
Access to Online Help without the console

You are experiencing a problem with the NetView management console Console and must access the
online help for a message, but one of the following situations occurs:

• The NetView management console Console does not start.
• The NetView management console Console cannot sign on to an NetView management console Server.
Because most of the NetView management console online help is in HTML, you can use any browser to
view NetView management console help.
Note: The online help for the Command Profile Editor (CPE) is not available as HTML.
1. Go to the appropriate directory on the NetView management console Console workstation to locate
the message:
• For Windows: \usr\local\Tivoli\bin\generic_unix\TDS\client\help
• For UNIX: /usr/local/Tivoli/bin/generic_unix/TDS/client/help
2. Use a tool such as grep to locate the message number.
• For Windows: Type grep IHS1006 *.html
• For UNIX: Type cat *.html | grep IHS006
3. Use a browser to display the located file.
Topology Console Environment Information Window

The Environment Information window displays useful diagnostic information for the topology console.
When you select Help —> Environment Information from the topology console, you can view
environment information, such as the NetView management console version, Java version, Java path, and
the version of the operating system.
Select Log to place all information in the log window. The log can be saved in a file on the topology server.
Select Print to print all the information to STDOUT. This is usually a separate command prompt window.
Message help for the Topology Server

To obtain message help for the topology server, select Help —> Help Index from the topology console
menu bar. Then select server, messages or messages, topology server from the list of help topics.
Diagnostic tools for GMFHS

This chapter describes the diagnostic tools that are used to isolate and identify the source of a problem
for the NetView Graphic Monitor Facility host subsystem (GMFHS). This chapter also describes how to
access error logs and run traces using the following tools:
• “GMFHS message logs” on page 216
• Online help support
• Command Response window
• GMFHS trace
GMFHS message logs

Both the mainframe server and the workstation environments produce messages for errors, warnings,
and information. Error messages and other types of messages are written to several log files. The
message files provide information that is helpful in resolving problems.
The following log files provide information about messages:
• GMFHS output logs
GMFHS output logs

GMFHS can log information to the following types of output logs:

• Internal trace log
• Output data sets
• GTF trace facility
GMFHS logs information to these output logs in the form of protocol data units (PDUs). The only PDU
logged by GMFHS is a PDU38, which is also referred to as a system error synopsis PDU. This PDU carries
error message and trace information if tracing has been enabled. Note that trace information can be
optionally logged, but error information is always logged. By default, trace information is not logged.
Remember this distinction when you determine which type of output log to use.
Determining which GMFHS output log to use

By default, GMFHS sends all PDU38 information to the internal trace log. GMFHS can be configured to
send PDU38 information to any type of output log. Any combination of output logs can be active at the
same time, but at least one must be active at all times. If GMFHS is configured to disable all output logs,
or one of the active logs cannot be reached because of system or log definition problems, GMFHS logs
PDU38 information to the internal trace log.
GMFHS PDU38 logging is controlled by the PRINTPDU38 parameter in DUIGINIT, and by the TRACE
command.
If you want information about: Refer to:

The PRINTPDU38 parameter in the IBM Z NetView Graphic Monitor Facility Host Subsystem (GMFHS)
Administration Reference Statements
The TRACE command NetView online help
Internal Trace Log

By default, PDU38 information is sent to the internal trace log. Logging of data to this output log can be
disabled by specifying the FILE, YES, or GTF option of the PRINTPDU38 parameter and not additionally
specifying the NO or INTERNAL option of this statement. Similarly, it can be disabled by specifying the
FILE, YES, or GTF option of the PRINT keyword on the TRACE command and not additionally specifying
the NO or INTERNAL option.
If the logging of PDU38 information to the internal trace log is disabled, it is temporarily enabled,
automatically, if none of the other output logs are enabled because of system or definition errors. The
internal trace log is automatically disabled again when at least one of the other output logs are reenabled.
The internal trace log is a wrapping log. This means that if the log is full, additional entries overwrite the
oldest entries in the log and the log has wrapped. The internal trace log has a default size of 100 pages of
storage, where a page is 4 KB of data.
You can control both the overall size of this log and the number of bytes for each entry written to the log.
The TRACEPAGES initialization parameter controls the number of 4 KB pages in the log; the default value
is 100. The TRACEBYTES initialization parameter controls the number of bytes for each entry logged.
When GMFHS is stopped, the data in the internal trace log is automatically flushed to an output data set
(unless the TRACEPAGES value is set to a value other than the default of 100). The output data set is
defined by the CNMT DD statement in the GMFHS startup procedure (sample CNMSJH10). By default, this
data set is the job SYSOUT data set CNMT.
To flush the internal trace log before GMFHS stops, use the FLUSH option of the GMFHS TRACE
command. This command flushes the data to the output data set defined by the CNMT DD statement and
clears the PDU38 information from the internal trace log.

TRACEPAGES and TRACEBYTES parameters IBM Z NetView Administration Reference
FLUSH option of the TRACE command NetView online help
Chapter 13. Diagnostic tools for NetView Management Console and GMFHS 217
Output Data Sets
Logging of PDU38 data to an output data set can be enabled by specifying the FILE or YES option on the
PRINTPDU38 parameter, or by specifying the FILE or YES option on the PRINT keyword on the TRACE
command. The log data sets used with this type of logging are defined by DD statements in the GMFHS
startup procedure (CNMSJH10). Each GMFHS component uses its own DD statement to specify the data
set. The GMFHS components and corresponding DD statements are as follows:
CNMC
Network command manager (NETCMD)
CNMD
Database server (DBSERVER)
CNME
Event manager (EVENTMGR)
CNMF
Network configuration manager (NETCON)
CNMI
Inter-processor communication (IPC)
CNMM
GMFHS main (control) task (MAINTASK)
CNMN
RODM Collection Manager (RCMGR)
CNMO
Operator interface manager (OPERIF)
CNMP
IPC-RODM event manager (IRMGR)
CNMR
Resource traits manager (RTMGR)
CNMS
View status manager (VSTATMGR)
CNMT
CNMT trace data set
CNMV
View manager (VIEWMGR)
By default, each of these DD statements uses a job SYSOUT data set. Unlike the internal trace log, output
data sets are not wrapped. They continue to grow until GMFHS is stopped. When GMFHS is started, the
output data sets are cleared of previous data and logging begins at the beginning of the data set.
If you are using this type of output logging to the default SYSOUT data set, be aware that you are using
spool space for each of the PDU38s logged. PDU38 error information cannot be disabled, and over an
extended period of execution GMFHS can log many error messages (including informational messages). If
tracing is enabled, the amount of PDU38 information that is logged in a short amount of time can be large.
In general, do not enable output data set logging to SYSOUT data sets with tracing enabled.
The internal trace log uses the SYSOUT data set CNMT, and the GMFHS automatically flushes data to this
data set when stopping. The TRACEPAGES value is set to a default of 100. If you do not have tracing
enabled, the internal trace log does not fill up unless many console messages are issued by GMFHS. Only
console messages are sent to the internal trace log if tracing is not enabled. To keep GMFHS from
automatically flushing the internal trace log to the CNMT data set when GMFHS stops, set the
TRACEPAGES value to a value other than 100.
Instead of changing the component DD statements in the GMFHS startup procedure to point to data sets
other than the job SYSOUT data set, you can substitute sequential data set names for any combination of
the GMFHS components. If you do specify a sequential data set name for any component, ensure that it is
being used only by that component. Do not specify the same sequential data set name for more than one

GMFHS component. In general, specify only a sequential data set name if requested to do so by a Tivoli
Service representative.
If a sequential data set fills up with PDU38 information, output logging for that component switches to the
internal trace log if the internal trace log was not previously enabled.
This type of output logging enables PDU38 information to be organized by GMFHS component, rather
than being intermixed in a single log with all components. This is especially useful for tracing, which you
should not enable unless requested to do so by a Tivoli service representative.
If you are using the SYSOUT data sets and are using JES2, you can view output data while GMFHS is
executing with ISPF as follows:
1. From ISPF, select System Display and Search Facility (SDSF).
2. Select the Display Active (DA) jobs option to display active jobs on your system. Find your GMFHS job.
3. Type a question mark (?) next to the GMFHS job. The panel displays the active SYSOUT files for that
job.
Note: This methodology works only with JES2; it does not work with JES3.
Generalized Trace Facility

The Generalized Trace Facility (GTF) can be used as an output log for PDU38 data. To enable logging of
PDU38 data to GTF, specify the GTF option on the PRINTPDU38 parameter in member DUIGINIT, or
specify the GTF option on the TRACE command (PRINT parameter).
GMFHS uses GTF event ID X'5E2' for logging PDU38 data. If GTF output logging is enabled, the GTF must
be started. If it is not started, GMFHS issues error messages DUI3985I and DUI3986E and routes any
succeeding PDU38 information to the internal trace log (if no other logging facility is active). When the
GTF starts, GMFHS issues error message DUI3987I and begins logging PDU38 information to the GTF.

Sending information to the GTF NetView online help
Console log window

Use the Console Log window to verify that commands, which you issued, were successful. If the
commands failed, use the Console Log window to obtain help.
The Console Log window contains responses to commands. All responses are displayed at the NetView
operator console.
The Console Log window can hold only 500 lines; so if many commands are sent, some responses
eventually wrap off the top of the Console Log window. This number can be customized on the Console
Properties window.
The Console Log window does not have to be active or visible for responses to be inserted. All command
responses are kept in a repository as they are received, and are visible when you invoke the Console Log
window from the NetView management console Console.
GMFHS Trace
The GMFHS TRACE command controls the type and level of tracing done by GMFHS subtasks. Trace
entries are written to the task trace-print data sets or to the generalized trace facility (GTF), depending on
the setting of the PRINTPDU38 parameter in DUIGINIT.
If trace entries are being issued to the task trace-print data sets, they are written to each subtask output
DD member. The entries are written in time sequence within each DD member.
If trace entries are being issued to the GTF, the trace entries are written in time sequence.
Use the GMFHS TRACE command PRINT parameter to control whether trace entries are made to the
internal trace log, the task trace-print data sets, or to the generalized trace facility (GTF). Although the
PRINT parameter is listed as a trace parameter, it also controls where error information is written for a
specific subtask, regardless of whether tracing for the subtask is enabled. Both error and trace
information flows to the location indicated by the PRINT parameter. The difference is that you cannot
stop the flow of error messages, but you can stop the tracing.
For example, if you set tracing off for the interprocess communication (IPC) subtask and specify
PRINT=FILE, and if console message DUI4024A is issued for the IPC subtask, the error information
associated with that message is written to the task trace-print data set. Specify PRINT=GTF to send the
error information to the GTF, if it is active. To see the output, browse the GTF data set. You can also
format the GTF data set with the event identifier (EID) X'5E2'. Specify PRINT=INTERNAL to send the
information to the internal trace log.
See “Viewing the GMFHS trace online” on page 221 for more information about the GMFHS TRACE
command PRINT parameter and subtask output DD member names.
Starting and stopping the GMFHS trace

The GMFHS TRACE command initiates a sequence trace that records the steps of any given flow. You can
use the GMFHS TRACE command to control the level and content of the tracing performed by GMFHS
tasks as follows:
• To set the parameters for tracing the NETCMD and IPC tasks, and to start tracing, enter the commands:
GMFHS TRACE ON TASK=(NETCMD,IPC),LEVEL=30

GMFHS TRACE ON
The LEVEL parameter specifies the level of tracing detail to be performed on the specified tasks. A valid
level is in the range of 0–99, where 99 provides the highest and most-detailed trace.
• To stop tracing of all tasks, enter the command:
GMFHS TRACE OFF
• To display current trace settings, enter the command:
GMFHS TRACE
Figure 38 on page 221 is an example of the output produced if you enter the GMFHS TRACE command.
Note: Tracing the view manager task (VIEWMGR) with a LEVEL value greater than 50 generates large
amounts of data and can severely degrade system performance.

DUI4060I CURRENT TRACE SETTINGS
DUI4090I TRACING IS ON
DUI4091I MAIN 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
IPCAPI = (PDU,SCO,PPI,GDS,CNMTAMEL,NOTIFY)
DUI4091I IPC 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I OPERIF 1 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I VIEWMGR 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I VSTATMGR 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I RTMGR 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I IRMGR 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I DBSERVER 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I EVENTMGR 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I NETCMD 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I NETCON 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4091I RCMGR 0 LEVEL 99 PRINT F RODM 1 IPC 1 PPI 1 STORAGE 0
DUI4037I END
Figure 38. Example of Current Trace Settings Displayed by the GMFHS TRACE Command

The GMFHS TRACE command and GMFHS TRACE NetView online help
levels
Viewing the GMFHS trace online

If you issue the GMFHS TRACE command with PRINT=FILE specified, you can use the interactive system
productivity facility (ISPF) to view trace information while GMFHS is running online. Specify PRINT=GTF
to write the trace data to GTF, and then use IPCS to view or print it.
Note: If you want to save the trace information internally to the in-storage trace table, see “Using the
GMFHS internal trace” on page 222.
To view the trace online with ISPF, do the following:
Note: This methodology works only with JES2; it does not work with JES3.
1. From ISPF, select System Display and Search Facility (SDSF).
2. Select the Display Active (DA) jobs option to display the active jobs on your system. You are looking for
your GMFHS job.
3. Enter a question mark (?) next to the GMFHS job. The panel displays the active SYSOUT files for that
job.
• If you are tracing GMFHS with PRINT=YES or PRINT=FILE, depending on which components you are
tracing, GMFHS puts the component traces in the following DD statements that are defined in the
GMFHS JCL or PROC:
CNMC
Network command manager (NETCMD)
CNMD
Database server (DBSERVER)
CNME
Event manager (EVENTMGR)
CNMF
Network configuration manager (NETCON)
CNMI
Interprocess communication (IPC)
CNMM
Main task (MAINTASK)
CNMN
RODM Collection Manager (RCMGR)
CNMO
Operator interface (OPERIF)
CNMP
IPC-RODM manager subtask (IRMGR)
CNMR
Resource traits manager
CNMS
CNMS status manager (VSTATMGR)
CNMT
CNMT trace data set
CNMV
View manager (VIEWMGR)
For example, if you are tracing NETCON and NETCMD, and CNMC and CNMF are displayed after you
enter a question mark next to the GMFHS job, you can browse the CNMC and CNMF files.

The GMFHS TRACE command PRINT parameter NetView online help
Sending trace information to the GTF NetView online help
Using the GMFHS internal trace

You can trace information to the internal trace log. The TRACEPAGES and TRACEBYTES parameters in the
GMFHS initialization member DUIGINIT control the size of the internal trace and the size of a trace
record. The default values are:
TRACEPAGES=100
TRACEBYTES=64
The TRACEPAGES parameter indicates the number of 4 KB pages to be allocated for the in-storage trace
table. The TRACEBYTES parameter indicates the number of bytes from each trace entry that is to be
written to the in-storage trace table.
The number of TRACEPAGES allocated depends on the amount of tracing you expect to do. If you are
tracing at high levels, the in-storage trace table fills up more quickly and the entries eventually wrap.
To dump the contents of the in-storage trace table, issue the GMFHS TRACE FLUSH command. The
GMFHS TRACE FLUSH command writes the contents of the trace table in the data set specified in the
CNMT DDNAME in the GMFHS JCL and reinitializes the in-storage trace table. To prevent data loss when
you issue a GMFHS TRACE FLUSH command, a new in-storage trace table of n pages is allocated before
printing and releasing the current table.

TRACEPAGES and TRACEBYTES IBM Z NetView Administration Reference
The GMFHS TRACE FLUSH command NetView online help

IPC task tracing
If tracing is enabled, set tracing of the IPC task to active, because all messages exchanged between
GMFHS and other address spaces, excluding calls to the RODM user API, flow through the IPC API. To
start IPC task tracing, issue one of the following commands:
• GMFHS TRACE ON,API=IPC,TASK=IPC,LEVEL=20
• GMFHS TRACE ON,API=ALL,TASK=IPC,LEVEL=20
You can also include the corresponding parameters in the GMFHS initialization member DUIGINIT and
recycle GMFHS, for example:
API=IPC
TASK=IPC...
LEVEL=20
TRACE=ON
Event Manager task tracing

Set tracing of the event manager to active when you are testing alerts, generic commands, session
establishment with non-SNA domains, or NMG PU status changes. To start event manager task tracing,
issue one of the following commands:
• GMFHS TRACE ON,API=RODM,IPC,TASK=EVENTMGR,LEVEL=90
• GMFHS TRACE ON,API=ALL,TASK=EVENTMGR,LEVEL=90
You can also include the corresponding parameters in the GMFHS initialization member DUIGINIT and
recycle GMFHS, for example:
API=ALL
TASK=EVENTMGR...
LEVEL=90
TRACE=ON
Part 4. Diagnosing NetView REST Server problems

Chapter 14. NetView REST Server problem
worksheet
cause of failures within the NetView REST Server.
alteration.
General information

1. Date:
2. Problem Number:
3. Component ID:
4. NetView Version and Release:
6. API Version:
Note: You can find the API version at the top of the Swagger Documentation. The Swagger
documentation can be reached at:
https://[server domain]:[NetView Server Port]/swagger-ui.html

Problem description


• Other
7. Can you re-create the problem with the server running DEBUG mode for logging? This is configurable
in the server's application.yml file.

• Message problems
• Loop problems
• HTTP Status Code problems
• Incorrect output problems
• Performance problems
• Documentation problems
Look at the problem classification that matches the symptoms associated with your problem.
Message problems
For message problems, respond to the following questions and, if appropriate, record the answers:
• Message ID:
• Error codes:
2. Review the Swagger Documentation to determine user action.
• What processes were taking place when the message occurred?
– Commands:
– Other:
• If the message was unexpected and cannot be corrected by following the actions in the
troubleshooting guide, collect the following documentation before contacting IBM Software Support:
– A copy of the appropriate workstation error logs. For the server, these files are in the
$NVRESTCONFIG directory.
– The message ID:
– The exact text of the message as it is written in the log:
– A completed NetView REST Server problem worksheet.
3. Did you follow the actions in the NetView REST Server online help? If so, document the following
information:
• What occurred?

If so, has an update been made to the system that might have changed the message?
Loop problems (hang/lockup)
For loop or wait problems, respond to the following questions and, if appropriate, record the answers:
• The scenario leading to the problem.
5. If something hangs, stop and restart the rest server, if the loop can be recreated please report steps
and avoid those steps after the next restart.
HTTP Status Code problems
For HTTP Status Code problems, respond to the following questions and, if appropriate, record the
answers:
1. Which API is in error?
2. What is the expected HTTP Status Code?
3. What is the HTTP Status Code that is being retrieved?
4. What data is being supplied to the API?
5. What data (if any) is being returned?
6. Obtain a copy of the appropriate server logs from the server while it is running in DEBUG mode.
For incorrect output problems, respond to the following questions and, if appropriate, record the answers:
For performance problems, respond to the following questions and, if appropriate, record the answers:
4. Obtain a copy of the appropriate workstation error logs.
For documentation problems, respond to the following questions and, if appropriate, record the answers:
1. Identify the order number, revision level, and title of the manual.
Chapter 14. NetView REST Server problem worksheet 229

2. Identify the location (chapter and section name) of the error in the manual.

NetView REST Server
Use Table 120 on page 231 to locate examples of problems you might encounter when using the NetView
program.
To use the table, perform the following steps:
problem.
3. Follow the resolution steps to correct your problem. If you cannot solve your problem by using the
examples, follow the instructions in Chapter 2, “Classifying problems,” on page 13 and Chapter 3,
“Documenting and reporting problems,” on page 23 before contacting IBM Software Support.
Table 120. Problems and their indicated pages

Problem Category Problem Scenario Page
HTTP Status Code is unexpected Status code 400 is received “Status code 400” on page 232
Status code 401 is received “Status code 401” on page 232
Keytool Keytool fails on startup “Keytool fails” on page 232
Security Browser does not trust the “Browser does not trust the
website's certificate website's certificate” on page
232
NetView REST Server fails to “NetView REST Server fails to
authenticate credentials authenticate valid credentials”
on page 232
Startup NetView REST Server can’t start “NetView REST Server can't
start” on page 233
Debugging methods
If the NetView REST Server is encountering an error, these are the steps you should follow:
1. Verify that the steps that you are taking to encounter the error are reproduceable.
2. Shut the REST Server down, modify the application.yml file to set the logging level to DEBUG.
3. Restart the REST Server and run through the steps that you verified previously.
4. Inspect the server log located in the $NVRESTCONFIG/logs directory for a better idea of what the
server is retrieving from the NetView program and where the error is occurring.
5. Modify your request to determine whether the error is with the request or with the REST Server itself.

Status code 400
This status represents an error in the JSON that you are sending with your request. The easiest method to
debug this is to plug your JSON into an online JSON Parser with a which can tell you where the syntax
error is occurring.
Status code 401
This status means that you need to authenticate with the server using valid NetView credentials.
Status code 424
This status represents an error or unexpected result from the NetView program, see the Swagger
Documentation for further details based on the API. Swagger documentation can be reached at:
https://[server domain]:[NetView Server Port]/swagger-ui.html
Status code 500
This status represents an internal server error and should not occur. Contact NetView support with error
details.
Keytool fails
If keytool fails, make sure Java is configured. You can add the following 2 lines to the /etc/profile
directory to configure your Java:
JAVA_HOME=/usr/lpp/java/J8.0_64
PATH=$PATH:/usr/lpp/java/J8.0_64/bin
Browser does not trust the website's certificate
Follow your browser’s instructions for adding a certificate to its truststore.
NetView REST Server fails to authenticate valid credentials
Check the server log that mentions any directories that are not program-controlled, and then make them
program-controlled. For more information, see Java Security on z/OS

NetView REST Server can't start
Check to ensure the port that the server is starting under is not already in use by using the NETSTAT
command from Unix System Services. Check the application.yml file to make sure the keystore
information is correct for both the keystore and truststore. If starting from the NetView program,
additional logs can be found in the job log in ISPF as well as in the server log if the job was able to reach
the startup procedure.
Chapter 15. Troubleshooting and initial diagnosis for NetView REST Server 233
Chapter 16. Diagnostic tools for NetView REST Server
This chapter describes how to use the NetView REST Server log to diagnose problems with the NetView
REST Server, which includes the following procedure:
1. Setting the log to the DEBUG mode.
2. Reading the log to determine what is causing a problem with the Server.
The NetView REST Server log
The NetView REST Server provides a log of all server activity located in the $NVRESTCONFIG/logs
directory. If the server is started from the NetView program, you can find the log in the
ejnerest.stdout file. If you wish to maximize the information you receive in your log, you can set the
log to the DEBUG mode instead of the INFO mode.
Setting the log to DEBUG mode
From Interactive System Productivity Facility (ISPF), go to 2. Edit, under the name field enter
<NVRESTCONFIG>/application.yml (where <NVRESTCONFIG> is the directory you’ve put your
application.yml file), and select 1. Under Data Encoding for ASCII. This should open up your
application.yml file. Once you have it open, scroll to the bottom of the file where you should see
something similar to:
logging:
level:
root: INFO
file: ${NVRESTCONFIG}/logs/debug.log
To change your mode to DEBUG, replace the word “INFO” with “DEBUG” as follows:
logging:
level:
root: DEBUG
file: ${NVRESTCONFIG}/logs/debug.log
This will enable the server to log details and exactly what is being sent to and received from the NetView
program. Note that while the INFO mode does not send back DEBUG-level messages, INFO-level
messages are still sent when the server is in the DEBUG mode.
Reading the log to determine what is causing a problem with the Server
There is a lot of data in the log to sort through, which can make searching for specific information a
difficult task. There are a few key steps that can make searching easier.
About this task

To complete this task, perform the following key steps:
Procedure
1. Open the log right after running and receiving a response from the API that you are attempting to
debug.
2. Scroll to the bottom of the file.

3. Scroll right until you are past the log's identifiers and into the text that is being sent across the log,
which is signified by a colon.
Here is an example:
2019-11-21 13:46:38.512 DEBUG 16777377 --- [nio-3275-exec-2]

com.netview.NetViewCommandRunner : Line from command output: …
From this example, you can see the following information:

• The time when the message was issued
• The level of the message (DEBUG here)
• The process ID
• The --- separator
• The thread name in square brackets
• The Logger Name that sent the message
• The : separator which prefixes the actual message text
• The actual message
4. From the DEBUG perspective, key messages will start with the message text "Running Command" to
signify what is being sent to the NetView program, and "Line from command output" to signify what is
being received back from the NetView program, one message for each line coming back.
Note: In the INFO and DEBUG mode, the "Line from Command output" messages are also condensed
into one very long message that starts with "Response from NetView".
5. Other messages will be present dependent on the API which should provide some context on what
operations the server is performing when it encounters an error.

Part 5. Diagnosing RODM problems

Chapter 17. RODM problem worksheet
cause of failures within the Resource Object Data Manager (RODM).
alteration.
General information
1. Date:
2. Problem Number:
3. Component ID:
3. Other products and their maintenance level:
RODM applications
Record the following information:
1. Are you running GMFHS with RODM?
2. Are you running any other RODM applications?
3. Can you remove one or more RODM applications and re-create the problem?
RODM methods
1. Are you running any user-written methods with RODM? If so, which ones?
Problem description

• Other:
7. Can you re-create the problem with the NetView trace running default options?
8. Can you re-create the problem with the RODM internal trace running with the ALL option?
Complete the following problem category that matches the symptoms associated with your problem:
Abend problems
• A copy of the network log
• A copy of the trace log
• A completed RODM problem worksheet
Message problems
• Message ID:
2. Use NetView online help for the message to determine user action.
• Methods:

• RODM Load Utility:
• Other:
4. If the message was unexpected and cannot be corrected by following the actions in NetView online
help, gather the following documentation before calling IBM Software Support:
• The message ID
• The exact text of the message as it is written in the log
5. Did you follow the actions in NetView online help? If so:
• What occurred?
Loop problems
4. If this is a method loop (see “Documenting LOOP problems” on page 35), obtain the following
documentation:
• A document describing the scenario leading to the problem
• A hardcopy of the system log
• A hardcopy of the trace log
• The addresses of instructions within the loop
• A memory dump obtained by using the processor RESTART function
Wait problems
Chapter 17. RODM problem worksheet 241

• A copy of the system console log
• A copy of the system console memory dump

• A description of the events leading to the failure
6. If expected messages do not show, have messages been filtered out:
• From MVS?

• A copy of the RODM trace
• A copy of the RODM log containing log record type 8 lock and storage statistics
• Information describing your RODM operating environment
• Descriptions of any modifications to your system
panel involved.
name.
Chapter 17. RODM problem worksheet 243

RODM
Before proceeding with Resource Object Data Manager (RODM) tasks, ensure that you have applied all
authorized problem analysis report (APAR) fixes and all program temporary fixes (PTFs) that are listed in
the program directory.
If RODM or one of its components abends, or if an application fails, RODM sends a return code with the
reason code to the application. This return code with the reason code can also be written to the RODM
log, depending on log-level settings. You might not see an external symptom of the failure, unless the
application that receives the error displays the return code and reason code, the application displays an
appropriate error message, or the application reacts unexpectedly.
The return code with the reason codes that are described in this chapter are provided on the assumption
that you know that the application failed and at least one of the following problems has occurred:
• The application issues an error message.
• You receive incorrect output.
• The application abends.
• You discover a return code with reason code in the RODM log.
• The application reacts unexpectedly.
Note: The method return/reason codes (set using EKG_SETRETURNCODE) might not display the success
or failure of the API call initiated by the application program. Usually, the success or failure of the
processing performed by the methods triggered as a result of that call is displayed. For example, if
multiple notification methods exist for a specific field, the method return/reason codes display the
highest return code, and the corresponding reason code, that was set by all of the methods that were
triggered.
If you cannot solve an abend problem, or if your abend code is not addressed in this chapter, follow the
general abends guideline for system abends.
To use Table 121 on page 246 to locate examples of problems you might encounter when using RODM,
take the following steps:
problem. These steps might include the use of specific RODM diagnostic tools or might refer you to
other documentation.
before contacting IBM Software Support .
Use the following table to locate examples of problems:

Table 121. RODM Problem Scenarios
Category
Abend A user-written method abends. “Return Code 12 with Reason Code 194 received” on
page 252
Abend 0C1 or 0C4 is received “Return Code 12 with Reason Code 194 received” on
(indicated by the type 7 log record). page 252
Abend 0C8 is received at RODM “Abend 0C8 is received at RODM initialization” on
initialization. page 255
Abend 9C5 is received. “Abend 9C5 is received” on page 256
Abnormal reaction is received from “Abnormal reaction from RODM” on page 259
RODM.
All transactions abend. “Abnormal reaction from RODM” on page 259
Application abends. “Application failure” on page 249
Return code 12, reason code 20 “Return Code 12 with Reason Code 20 received” on
received because of an abend. page 250
Return code 12, reason code 213 “Return Code 12 with Reason Code 213 received” on
received because of an abend. page 254
RODM abends when SNA topology “RODM abends when SNA Topology Manager is
manager is starting. starting” on page 256
Checkpoint A checkpoint was requested, but the “RODM fails to complete Checkpoint Processing” on
processing checkpoint data sets cannot write all page 258
windows.
RODM fails to complete checkpoint “RODM fails to complete Checkpoint Processing” on
processing. page 258
Processor Processor utilization for a RODM “Asynchronous method looping” on page 257
utilization application is very high, regardless of
transaction activity.
Processor utilization for a user “User application looping” on page 257
application is very high; transactions
are not completing.
Ending RODM RODM does not end. “Abnormal reaction from RODM” on page 259
Incorrect Incorrect data is returned from RODM. “Abnormal reaction from RODM” on page 259
output
Incorrect output is in the EKGPRINT “Incorrect output is in the EKGPRINT Data Set” on
data set (message is present, but text page 258
is not meaningful).
Incorrect output is received from an “Application failure” on page 249
application.
Looping An asynchronous method is looping. “Asynchronous method looping” on page 257
User application is looping. “User application looping” on page 257
Messages An application error message is “Application failure” on page 249
received.

Table 121. RODM Problem Scenarios (continued)
Category
EKG1101E “Return Code 12 with Reason Code 121 received” on
page 251
EKG1104E, EKG1105E, or EKG1106E “RODM fails to complete Checkpoint Processing” on
page 258
EKG1111I “Return Code 12 with Reason Code 122 received” on
page 251
EKG1112E “RODM fails to complete Checkpoint Processing” on
page 258
EKG1113I is received at RODM “RODM fails to complete Checkpoint Processing” on
initialization. page 258
EKG1116I or EKG1117I “Slow response from RODM” on page 260
MVS issues message IEC340I when “RODM fails to complete Checkpoint Processing” on
RODM is stopped. page 258
MVS message IEC161I 203-204 “Return Code 12 with Reason Code 122 received” on
page 251
Language Language Environment for z/OS “Return Code 12 with Reason Code 211 received” on
Environment® storage is exhausted. page 254
for z/OS
storage
Storage fragmentation limit is reached “Return Code 12 with Reason Code 212 received” on
for Language Environment for z/OS page 254
storage.
Return code, Return code 8 with reason code 202. “RODM fails to complete Checkpoint Processing” on
application page 258
failure
Return code 12 with reason code 20. “Return Code 12 with Reason Code 20 received” on
page 250
page 251
page 251
page 252
page 254
page 254
page 254
Slow RODM is stopped and warm-started; “Slow response from RODM” on page 260
processing RODM runs slowly.
Slow response from RODM. “Slow response from RODM” on page 260
Chapter 18. Troubleshooting and initial diagnosis for RODM 247

Table 121. RODM Problem Scenarios (continued)
Category
Transactions process slowly. “Slow response from RODM” on page 260
Storage Language Environment for z/OS “Return Code 12 with Reason Code 211 received” on
storage is exhausted. page 254
RODM frequently runs out of window “Slow response from RODM” on page 260
storage.
Storage fragmentation limit is reached “Return Code 12 with Reason Code 212 received” on
for Language Environment for z/OS. page 254
User written Debugging procedure for methods. “Debugging methods” on page 248
method
Wait User API does not return from “User API does not return from EKGWAIT” on page
EKGWAIT. 257

General abends guideline for system abends MVS library
Information about RODM diagnostic tools Chapter 19, “Diagnostic tools for the Resource
Object Data Manager (RODM),” on page 261
Information about setting log levels to write return “Log-Level values” on page 262
codes with reason codes to the RODM log
For more information about RODM IBM Z NetView Resource Object Data Manager and
Debugging methods
If you know that you have a problem with a user-written method, follow these steps:
1. Unit-test the method. Create a dummy PL/I or C main procedure to call the method and a dummy
EKGMAPI module to dump all of the data that is passed to RODM. Verify that the data you received or
passed is correct.
2. If the method is intended to run synchronously, ensure that it does not violate MVS cross-memory
restrictions by issuing supervisor calls (SVCs).
3. If the method is intended to run asynchronously, use WTO instructions by way of an assembler routine
to examine program flow in the method.
4. Use the Output to Log (2008) MAPI function to write user-provided data to the RODM log file. You can
use log record types 1, 9, and 10 in the RODM log file to trace your method execution.
5. Enable method tracing by setting log-level values as described under “Log-Level values” on page 262.
6. Code the method to set return and reason codes that indicate the execution result.
If you receive messages that indicate a method (that you know is installed correctly) is not installed,
ensure that all methods, that the indicated method invokes, are also installed.

Cross-memory restriction (SVCs) MVS library
The RODM log and log record types “The RODM log” on page 261
Setting log-level values “Log-Level values” on page 262

Application failure
Use this section for troubleshooting when you are running an application and the application fails. For
example, if you receive an error message or incorrect output, or the application abends, RODM writes a
return code and reason code to the RODM log.
To solve this problem, follow these steps:
1. Take corrective action provided by the error message (if any).
2. Check the RODM log file for records with non-zero return codes with reason codes. If the transaction
ID (transID) of the failing transaction is known, locate those log records containing that transaction ID.
If there is a return code with the reason code written to the RODM log record, use Table 122 on page
249 to locate the appropriate scenario and follow the resolution steps provided.
3. If you cannot solve your problem, follow the instructions in Chapter 2, “Classifying problems,” on page
13 and Chapter 3, “Documenting and reporting problems,” on page 23 before contacting IBM Software
Support .
Table 122. RODM Return Codes with Reason Codes Troubleshooting Reference
Return code with reason code Page
Return code 12 with reason code 20 “Return Code
12 with
Reason Code
20 received”
on page 250
12 with
Reason Code
121
received” on
page 251
12 with
Reason Code
122
received” on
page 251
12 with
Reason Code
194
received” on
page 252
12 with
Reason Code
211
received” on
page 254

Table 122. RODM Return Codes with Reason Codes Troubleshooting Reference (continued)
Return code with reason code Page
12 with
Reason Code
212
received” on
page 254
12 with
Reason Code
213
received” on
page 254

Reading the RODM log record “The RODM log” on page 261
Return Code 12 with Reason Code 20 received

If the RODM log indicates a return code 12 with reason code 20 because of an abend, do the following:
1. Obtain the RODM log listing and format it using the RODM log formatter.
2. Note the transaction ID from the RODM log record. The transaction ID is shown as an 8-byte
hexadecimal field.
If you discovered the return code 12 with reason code 20 in more than one type of log record for the
same transaction ID, use the type 7 log record, if it is available, for problem determination. Log
record type 7 contains specific information about the conditions under which RODM issued the return
code 12 with reason code 20.
3. Ensure that you have used a valid interface block for API calls, because one of the pointers in the
interface control blocks might not be valid.
4. Ensure that your event control block (ECB) addresses are valid.
5. Ensure that the AMODE for EKGUAPI is the same as the AMODE for your application program.
6. If the RODM type 5 or type 7 log record indicates a storage macro failure, ensure that you have
sufficient main storage:
a. Increase the region size for the RODM program.
b. Decrease the total number for the concurrent users and asynchronous tasks specified in the
customization member (EKGCUST).
7. If the entry point is not specified correctly for your method, ensure that you have specified the PL/I
method name on the ENTRY and NAME link-edit statements in the link JCL.
8. If the method calls EKGMAPI, ensure that you have properly linked EKGMAPI with the method.
9. For PL/I methods, ensure that:
a. The PL/I method was compiled without the MAIN option.
b. The method name is less than or equal to 7 bytes.
c. The method calls EKGMAPI with the correct parameters.
d. EKGMAPI was declared with the correct attributes. You can use EKG1IEEP to declare EKGMAPI
correctly.
10. For C methods, ensure that:
a. The method is declared as an external function and is not declared as a main routine.

b. The method calls EKGMAPI with the correct parameters.
c. EKGMAPI was declared with the correct attributes. You can use EKG3CEEP to declare EKGMAPI
correctly.
11. If you cannot solve your problem, follow the instructions in Chapter 2, “Classifying problems,” on
page 13 and Chapter 3, “Documenting and reporting problems,” on page 23 before contacting IBM
Software Support.

The RODM log formatter “The RODM log formatter” on page 265
RODM log record type 7 “Formatted Log Record Type 7” on page 286

You receive a RODM return code 12 with reason code 121 because the system rejected a request
because of a lack of translation window storage. All of the following symptoms occur with this condition:
• MVS issues message IEC161I 203-204.
• RODM issues message EKG1101E.
• A type 2 log record is written if the value of EKG_LogLevel in customization member EKGCUST is less
than or equal to 12.
This problem can occur if the translation-window, checkpoint data set is too small. To solve the problem,
do the following:
1. If you have defined checkpoint data sets:
a. Take a checkpoint of RODM and end RODM.
b. Copy the data in the existing translation-window data set to a larger data set and warm start RODM
using the new translation-window data set.
2. If the checkpoint data sets you have defined are NOT large enough, or if you have not defined
checkpoint data sets, use the IBM Z NetView Tuning Guide to compute the size of the translation-
window data set.
3. Warm start RODM.
Support .

You receive a RODM return code 12 with reason code 122 because the system rejected a request
because of a lack of data-window storage. All of the following symptoms are associated with this
problem:
• User applications or methods issue RODM requests and RODM issues return code 12 with reason code
122.
• MVS issues one or more messages IEC161I 203-204.
• RODM issues message EKG1111I before the last IEC161I message.
• A type 2 log record is written if the value of EKG_LogLevel in the customization member EKGCUST is
less than or equal to 12.
This problem can occur if the total size of the data-window checkpoint data set is too small.
1. If you have defined checkpoint data sets:
a. Take a checkpoint of RODM and end RODM.
b. Add an additional checkpoint data set to the RODM start JCL and warm start RODM using the new
data-window data set.

2. If the checkpoint data sets you have defined are not large enough, use the IBM Z NetView Tuning Guide
to compute the size of the data-window data set.
3. If you have not defined checkpoint data sets, use the IBM Z NetView Installation: Configuring Graphical
Components to size the data-window data set.
4. Add data-window data sets (to a maximum of 512) and warm start RODM.
Support .

You receive return code 12 with reason code 194 from RODM because a method has abended.
1. Obtain the RODM log listing and format it using the RODM log formatter.
hexadecimal field.
same transaction ID, use the type 7 log record, if it is available, for problem determination. Log
record type 7 contains specific information about the conditions under which RODM issued the return
code 12 with reason code 194. See “Formatted Log Record Type 7” on page 286 for more
information.
3. Determine the name of the method that abended, as follows:
• Search the log file for a log record type 2 that contains the same transaction ID that you recorded in
step 2. Locate the following in the type 2 log record:
– The return code
– The reason code
– The API function being run
– The name of the method being invoked
• If a type 2 log record has not been written to the RODM log, check one of the following for the
method name:
– The RODM memory dump.
You can find the method name by going to the area where the base register points and searching
backwards in the memory dump until you find the eye-catcher (method name) with a date and
time stamp.
– The type 9 or type 10 log record that has the same transaction ID you recorded in Step 2.
4. Verify that your method code is running correctly.
Use the information under “Debugging methods” on page 248 to troubleshoot your method code.
5. Ensure that you have used a valid interface block for EKGMAPI calls.
6. Verify that you have link-edited the method with the latest maintenance level of the module
EKGMAPI.
7. Verify that you do not call EKGUAPI from within the method.
8. Verify that you have used the correct compiler and link options to create the method load module.
9. Verify that the method does not use any C, PL/I, or Language Environment for z/OS functions that are
restricted from within RODM methods.
10. Search the log file output for a log record type 7 that contains the same transaction ID that you
recorded in Step 2. Locate the following in the type 7 log record:
• The abend return code
• The abend reason code

• The system diagnostic work area (SDWA). Locate the following information in the SDWA:
– The program status word (PSW) at the time of the error
– The registers at the time of the error
Note: You can also find this information in the RODM memory dump.
11. If the type 7 log record indicates the following abends, perform the steps listed:
Abend 0C1
a. Subtract the value in the base register from the value in register 14 to find the offset of the
instruction following the branch and link register (BALR) instruction.
b. Add this to the offset of the control section (CSECT) entry point as determined from the compiled
listing to determine the effective offset of the instruction following the BALR instruction.
c. Locate the BALR offset in the compiled listing to find the location of the abend.
d. Determine whether register 15 is set to zero (BALR 14,15).
If register 15 is set to zero, the method is trying to call a procedure that has not been link-edited
with the method object module.
e. Determine the cause of the abend by analyzing the failing instruction, and correct the problem.
f. If a user-written method is causing the problem, follow the steps for troubleshooting a method as
shown in “Debugging methods” on page 248.
g. If these steps do not correct your problem, refer to the MVS library for more information.
12. Abend 0C4 or any other abend
a. Subtract the value in the base register from the PSW.
b. Add this to the offset of the control section (CSECT) within the load module to determine the
effective offset of the failing instruction.
The failing instruction is the instruction at the offset or the instruction that immediately precedes
the offset. You can use the instruction length code (ILC) to help determine if the failing instruction
is the one at or preceding the offset.
c. Locate the effe0ctive offset in the compiled listing to find the location of the failing instruction.
d. Determine the cause of the abend by analyzing the abending instruction.
13. Verify that the method does not violate cross-memory restrictions by issuing SVCs.
14. Verify that the method does not use restricted functions such as the built-in TIME or DATE functions.
15. If you cannot solve your problem, follow the instructions in Chapter 2, “Classifying problems,” on
page 13 and Chapter 3, “Documenting and reporting problems,” on page 23 before contacting IBM
Software Support .

The RODM log formatter “The RODM log formatter” on page 265
Troubleshooting method code “Debugging methods” on page 248
Conditions under which RODM issues return code “Formatted Log Record Type 7” on page 286
12 with reason code 194
Verifying that you are using the correct compiler IBM Z NetView Resource Object Data Manager and
and link options to create the method load module GMFHS Programmer's Guide
Verifying that the method does not use any C, PL/I, IBM Z NetView Resource Object Data Manager and
Language Environment for z/OS functions that are GMFHS Programmer's Guide
restricted from within RODM methods
Using a memory dump to diagnose abends MVS library
Cross-memory restriction (SVCs) MVS library

RODM issues return code 12 with reason code 211 when Language Environment for z/OS storage is
exhausted. RODM does not write a log record type 2 because it can cause the STACK storage area size to
be extended.
To solve this problem, do the following:
1. Prevent methods from repeatedly getting large amounts of storage.
2. Reduce the number of nested method calls.
3. Increase the size of the ISA specified in RODM customization member EKGCUST.
(EKGCUST is a file of customer parameters for RODM.)

Coding member EKGCUST IBM Z NetView Administration Reference

RODM issues return code 12 with reason code 212 when the Language Environment for z/OS storage
fragmentation limit is reached. RODM writes a log record type 2 to the RODM log.
1. See “Formatted Log Record Type 2” on page 275 for information about the transaction that abended.
2. Reduce the vertical depth of the classes by removing descendant subclasses.
You can use the Delete Class API function to delete classes or loader primitives. Reduce the depth in
increments of 10% until the problem is solved.
3. Reduce the number of nested method calls.
4. Increase the size of the initial storage area (ISA) specified in member EKGCUST.
Support .

Class hierarchy structures IBM Z NetView Resource Object Data Manager and
Coding member EKGCUST IBM Z NetView Administration Reference

If you receive return code 12 and reason code 213 because an abend occurred when RODM accessed the
interface blocks of the application or method, do the following:
hexadecimal field.
same transaction ID, use the type 7 log record, if it is available, for problem determination. Log record
type 7 contains specific information about the conditions under which RODM issued the return code
12 with reason code 213.
See “Formatted Log Record Type 7” on page 286 for additional information.
2. Ensure that you used a correctly set interface block for EKGMAPI calls.
3. Determine whether a restricted function was called in the C method.
Remove restricted functions from the method.

4. The application might have passed a pointer that is not valid or an incorrect data length to RODM,
causing the abend.
Note:
If you pass an FAIB, EAIB, FIELD NAME, CLASS NAME, or OBJECT NAME pointer that is not valid, the
pointer that is not valid is often logged as X'FFFFFFFF', and the API receives a return/reason code of
12/213. If this occurs, subsequent pointers are also logged as X'FFFFFFFF' because RODM
discontinues validating pointers.
If you receive a return/reason code of 12/213, look for the first pointer that was logged as
X'FFFFFFFF', or look for an address that is not valid.
5. Correct your application using the corrective action information listed for that return code and reason
code.
6. Review the RODM log listing for error records associated with the transaction in error.
Depending on the severity of the error, you might need to modify the value of the EKG_LogLevel
parameter to ensure that all transactions get logged.
Support.

Restricted functions IBM Z NetView Resource Object Data Manager and
RODM return codes and reason codes IBM Z NetView Resource Object Data Manager and
Log-level values “Log-Level values” on page 262
Conditions under which RODM issued a return code “Formatted Log Record Type 7” on page 286
12 with reason code 213
Abend 0C8 is received at RODM initialization

Abend 0C8 is issued if the storage you specify using parameters in member EKGCUST exceeds the region
size. Other abend codes can be issued for this reason, but usually, you receive abend 0C8.
1. Verify that you have not specified more storage than is valid for the region.
You can calculate the amount of storage used as follows:
((ASYNC_TASKS + CONCURRENT_USERS) * PLI_ISA)
2. If you have specified more than the valid amount of storage, specify a larger region size.
3. If you must reduce the amount of storage specified in member EKGCUST, reduce the PLI_ISA value
first.
4. If you cannot solve your problem, go to “Documenting ABEND problems” on page 27.

Coding EKGCUST IBM Z NetView Administration Reference

Abend 9C5 is received
A RODM X'9C5' abend can result from different error conditions. Check the reason code to determine
which error it represents.
Abend 9C5 with Reason Code 0

If you receive an X'9C5' abend with a reason code of 0, one of the following might have occurred:
• RODM canceled a transaction based on the reply from message EKG1326D.
The task control block (TCB) might be:
– A user TCB for an application connected to RODM
– A TCB representing one of the user defined asynchronous tasks in RODM (these tasks are defined in
EKGCUST - RODM customization)
• The transaction has exhausted all Language Environment for z/OS storage (stack or heap).
To solve this problem, replace the method that is exhausting the Language Environment for z/OS storage.
Abend 9C5 with Reason Code 33

A X'9C5' abend with a reason code of 33 is a RODM internal abend. RODM has detected an error, and has
stopped.
To solve this problem, gather the dump (and all other associated problem information) and contact IBM
Software Support .
RODM abends when SNA Topology Manager is starting

If you end RODM when the SNA topology manager is in the process of starting, the following messages
are sent:
EKG1325I jobname: THE WAIT PERIOD HAS EXPIRED FOR THE TERMINATE REQUEST,
BUT THERE ARE STILL ACTIVE TRANSACTIONS.
EKG1326D jobname: ENTER '1' TO PERFORM WAIT AGAIN,

'2' TO END TRANSACTIONS AND PROCEED,
'3' TO CANCEL REQUEST.
Even though you choose '3' to cancel the request, RODM and possibly the SNA topology manager and
GMFHS abend.
If an application triggers RODM methods supplied by the NetView product, these methods might access
storage in the GMFHS address space. It is important that you do not end GMFHS or RODM while these
methods are running. If GMFHS or RODM is ended while the methods are accessing this storage,
unpredictable results might occur, such as an abend.
As an example, during a SNA topology manager warm start, the ExceptionViewList field is changed, which
triggers a NetView RODM change method. If GMFHS is active, the change method attempts to access
storage in the GMFHS address space. If GMFHS has ended, the access is no longer valid.
1. Check the RODM log for errors.
2. Start RODM again if necessary.
3. Start GMFHS again if necessary.

The RODM log “The RODM log” on page 261

User application looping
A user application is looping. You might have a looping problem when the CPU utilization for a user
application is high, but your transactions are not completing, or if the displayed panel is in a continuous
wait state. This can happen when the user application invokes a synchronous method and the method
code becomes caught in a loop.
1. Check the method code. See “Debugging methods” on page 248.
2. Ensure that you have applied all PTFs and APAR fixes that are listed in the program directory.
3. If you suspect that a transaction is in a loop and it is a user application, end the transaction.
For example, if a time sharing option (TSO) session initiated the transaction, end the TSO session.
Support .

Debugging method code “Debugging methods” on page 248
Asynchronous method looping

An asynchronous method is looping because a RODM application is using a large amount of the processor
regardless of user application transaction activity.
1. Initiate a checkpoint to force a quiesce that ends all transactions, including asynchronous transactions
and methods.
2. Correct the method code. See “Debugging methods” on page 248.
3. Ensure that you have applied all PTFs and APAR fixes that are listed in the RODM program directory.
Support .

User API does not return from EKGWAIT

The user API invokes EKGWAIT to wait on an event and does not regain control from EKGWAIT. This
problem occurs if any of the following conditions are true:
• You did not specify the correct event control block (ECB) address when you invoked EKGWAIT.
• The user application did not update the ECB address associated with a notification queue when the user
application reconnected to RODM.
• Your application was linked with the wrong version of EKGWAIT.
Processor utilization does not change, except for the task in the wait state, which does not use the
processor.
1. Cancel the user application.
2. Verify that the correct ECB address was passed to EKGWAIT.

3. When reconnecting to RODM, always update the notification queue ECB addresses owned by your user
application.
4. Link your user application program with the correct version of EKGWAIT.
Support .
Incorrect output is in the EKGPRINT Data Set

If incorrect output is written in the RODM load function EKGPRINT data set, a message is received, but
the text output is not meaningful.
1. If there is an error in EKGLMENU of the EKGLANG DD statement in the loader JCL, correct EKGLMENU
using one of the following:
• If a message is missing from EKGLMENU, restore the missing message.
• If the text of the message is not meaningful, correct the message or restore the message file shipped
with NetView program.
Support .
RODM fails to complete Checkpoint Processing

Three different sets of symptoms are associated with RODM failing to complete checkpoint processing:
• Symptom set one:
– Message EKG1113I is displayed on the console at RODM initialization.
– MVS issues message IEC161I 227-229 or IEC161I 052-084.
– RODM issues return code 8 with reason code 202.
The EKG_LastCheckpointID field of object EKG_System is set to zero if the checkpoint fails. When the
value of the EKG_LastCheckpointID field is set to zero, a user application program that subscribes to
the EKG_LastCheckpointID field in the EKG_System object is notified that the checkpoint has failed.
The user application can then take appropriate action.
– Message EKG1112E is displayed on the console.
• Symptom set two:
– RODM issues return code 12 with reason code 211 to a user application.
– MVS issues message IEC340I.
• Symptom set three:
– A checkpoint was requested, but the checkpoint data sets cannot write all windows as indicated by
message EKG1104E, EKG1105E, or EKG1106E.
These symptoms can occur if:
• You did not specify the DD names of the checkpoint data sets.
• Some of the data sets were used by another user.
• No storage was available for the VSAM catalog work area.
• The checkpoint data sets are damaged.
The following resolution steps apply to all of the symptom sets described above.

1. End RODM.
Note: All data is lost because the checkpoint function is disabled because of the checkpoint error.
2. Correctly specify all DD names and data set names of the checkpoint data sets in the start JCL.
3. Change the suspect checkpoint data sets in the start JCL, or ensure that all checkpoint data sets
specified in the start JCL are error-free.
4. Increase the region size of the RODM program.
5. Replace the damaged checkpoint data sets.
6. If a set of checkpoint data sets from a previous successful checkpoint exists, warm start RODM using
those checkpoint data sets.
Otherwise, cold-start RODM.
Attention: When you cold-start RODM, the checkpoint data sets are reinitialized and RODM
starts with an empty data cache.
Support .
Abnormal reaction from RODM

You might receive one of the following abnormal reactions from RODM:
• Data that is not valid is returned to a user application program or method.
• All transactions abend.
• RODM does not end when the operator enters a terminate request.
This can occur if VSAM is very active. RODM does not end until VSAM completes this activity.
Before taking the resolution steps in this section, determine if there is any further VSAM activity for the
current RODM log. If there is VSAM activity, wait until the activity finishes before trying to end RODM.
• RODM ends with an abend.
These reactions can happen if a method destroys RODM control blocks by using incorrect pointers or by
passing function blocks that are not valid.
Attention: Methods that run in the RODM address space are APF-authorized.

1. If possible, take a checkpoint of RODM.
2. Use the MVS FORCE jobname,ARM command to end RODM if it does not end normally.
Refer to the caution for using the MVS FORCE jobname,ARM command in the IBM z/OS library.
3. Check the RODM log for any method abend.
4. Verify the method code that abended.
5. If a set of checkpoint data sets from a previous successful checkpoint exists, warm start RODM using
those checkpoint data sets.
Otherwise, cold-start RODM. Whether you warm-start or cold-start RODM, be sure to specify
CLRSSB=YES in the start JCL.
Attention: When you cold-start RODM, the checkpoint data sets are reinitialized and RODM
starts with an empty data cache.
Support.

The RODM log “The RODM log” on page 261
Slow response from RODM

RODM processes transactions slowly, frequently runs out of window storage (you received messages
EKG1116I or EKG1117I), or if you end and warm start, RODM runs slowly. The degraded performance is
because of the large amount of paging that occurs.
This problem can occur if the following conditions are true:
• Cell size and pool size are specified too large or too small.
• Too many notification queue objects were created.
• The log level in the customization member is too low, causing excessive logging.
• The ISA size in the customization member is too small.
• The lock parameters in the customization member are not specified optimally.
• The vertical class depth is too deep.
• You are invoking the RODM load function with a PL/I or C module (entry point EKGLJOB) and the ISA
size or heap size of application program is too small.
Allow enough time for paging to complete before doing the following:
1. Reduce the number of notification queues, as follows:
a. Remove all notification subscriptions that reference the notification queue you want to delete.
b. Delete these queues using the Delete Object API function.
2. Increase the log level.
3. Adjust the lock parameters and reload the customization member using the RELOAD command.
4. Use API calls at run time to reduce the depth of the vertical classes using the Delete Class API function
to delete classes.
Support .

Class hierarchy structures IBM Z NetView Resource Object Data Manager and
Setting log levels “Log-Level values” on page 262
The RELOAD command NetView online help

Chapter 19. Diagnostic tools for the Resource Object
Data Manager (RODM)
This chapter describes the following tools you can use to diagnose problems with the Resource Object
Data Manager (RODM):
• The RODM log, including:
– Components that output data to RODM log files
– Log-level values
– The RODM log formatter
– Individual log records including unformatted and formatted log records and their field descriptions
• The RODM internal trace
• Dumping dataspaces allocated by RODM
• The memory dump utility, including sample reports and their field descriptions
• The RODM load function listing

Information about RODM IBM Z NetView Resource Object Data Manager and
The RODM log

RODM writes 11 types of log records (types 0-10). You can use the data contained in these logs to assist
in problem determination and diagnosis. For example, you can use log record types 9 and 10 for method
debugging.
User-supplied information can be written to the RODM log through the Output to Log Method Application
Programming Interface (MAPI) function.
You can customize member EKGCUST to specify which log records to write to the RODM log, or you can
start an MAPI call from a RODM method to write records to the RODM log. After customizing EKGCUST,
you can use the MVS MODIFY command to reload member EKGCUST or to query the current RODM log
file.

Starting an MAPI call from a RODM method to write IBM Z NetView Resource Object Data Manager and
records to the RODM log GMFHS Programmer's Guide
Customizing member EKGCUST IBM Z NetView Administration Reference
Defining the RODM log (EKGSI101)

The RODM VSAM clusters are allocated in the NetView job CNMSJ004. Job CNMSJ004 calls access
method services, passing the EKGSI101 member as input for defining the VSAM clusters for the RODM
log. Within CNMSJ004, access method services are started with the input from other samples for defining
other VSAM clusters for NetView program.
If you need to allocate VSAM clusters for a second RODM, you can edit CNMSJ004 and run EKGSI101 to
allocate the data sets used for the RODM logs as defined in EKGSI101.
Note: Use SHAREOPTIONS(2) for performance reasons.

Read integrity is not guaranteed when using VSAM SHAREOPTIONS 2, 3, and 4 during cross-region
sharing. The control interval you receive might be updated and written back to the data set without
updating your copy.
To provide integrity when reading an entry-sequenced data set, do not allow secondary allocation without
an explicit communication mechanism to the read-only task when extents are increased.
Also, loss of read integrity results in down-level records and erroneous "no record found" conditions.
The MVS MODIFY command with the LOGF option clears the local buffers and forces a CLOSE TYPE=T.
This provides read integrity that is current up to the time the MODIFY command is issued.
The MVS MODIFY command enables you to specify RODM logging options.
Components that output data to RODM log files

RODM log files can be appended by components as follows:
• User application programs that use User Application Program Interface (UAPI) functions cannot
explicitly write data to the RODM log. User APIs issued by the applications might be implicitly logged by
RODM depending on the return code of that UAPI and the setting of the EKG_LogLevel field.
• A user method can write data through an MAPI function request by issuing an Output to Log (2008)
MAPI function from within a method.
Note: Numbers enclosed in parentheses signify the function number of the named function.
• You can use the MAPI log tracing capability to trace methods and API calls to the RODM log. The MAPI
log tracing capability writes to log record types 9 and 10 to the RODM log.

RODM functions, including the Output to Log MAPI IBM Z NetView Resource Object Data Manager and
function GMFHS Programmer's Guide
The MAPI log tracing capability IBM Z NetView Resource Object Data Manager and
Data contained in the log records “Log Record formats” on page 270
Log-Level values
When an error occurs within RODM, you can review the RODM log for records associated with the
transaction in error. Depending on the severity of the error, you might need to modify the value of the log-
level parameters in the RODM customization member EKGCUST to specify when RODM is to generate a
log record.
Note: If you pass a FAIB, EAIB, FIELD NAME, CLASS NAME, or OBJECT NAME pointer that is not valid, the
pointer that is not valid is often logged as X'FFFFFFFF' and the API receives a return/reason code of
12/213.
If this occurs, subsequent pointers are also logged as X'FFFFFFFF' because RODM discontinues validating
pointers.
If you receive a return/reason code of 12/213, look for the first pointer that was logged as X'FFFFFFFF', or
look for an address that is not valid.
Your application can also update log-level values. The default values are the values of the log-level
parameters specified in RODM customization member EKGCUST.
If the transaction return code is greater than or equal to the value of a log-level parameter, RODM writes a
log record. You can specify the following values:
Log Level
Log Record Written for Transaction Codes

0–3
All
4–7
Warning, error, or severe
8–11
Error or severe
12–999
Severe only
The default value is 8.
Note: Do not use a log-level of zero (0). Log-level zero (0) logs all RODM API requests. There is a potential
for an auxiliary storage shortage to occur if log-level zero (0) is used in a high-stress environment.
The rules for method tracing also determine which log records are written to the RODM log and when they
are output. The following fields are used as input to RODM method tracing:
• EKG_MLogLevel in the associated user object initially set from MLOG_LEVEL in customization member
EKGCUST
• EKG_MTraceFlag in each method object
• EKG_MTraceType in the associated user object initially set from MTRACE_TYPE in customization
member EKGCUST
• EKG_LogLevel in the associated user object initially set from LOG_LEVEL in customization member
EKGCUST
Use these parameters with the type of method that is triggered, as well as the type of API request, to
determine the log record that is to be written to the RODM log.
The following log records are sent to the RODM log regardless of log-level settings:
• Log record type 0 (Log Version Record) is the log version record.
This is the first record written to the log file when you start RODM.
• Log record type 1 (Output to Log MAPI request) is sent to the RODM log when a method starts the
Output to Log (2008) MAPI request.
• Log record type 5 (RODM system services failure) is sent to the RODM log when RODM encounters a
system services error.
• Log record type 6 (operator request) is sent to the RODM log when you enter specific RODM MODIFY
commands.
• Log record type 7 (abend) is sent to the RODM log when a method or RODM abend is detected.
• Log record type 8 (statistics) is sent to the RODM log when you request RODM statistics using the RODM
MODIFY command.
The following log records are sent to the RODM log based on the value of EKG_LogLevel:
• Log record type 2 (UAPI transaction request) is sent to the RODM log when the return code from a UAPI
function is greater than or equal to EKG_LogLevel
• Log record type 3 (object-specific method) and log record type 4 (object-independent method) are sent
to the RODM log when the following conditions exist:
– The Set Return/Reason Code (2006) API function is called from an object-specific or object-
independent method.
– The return code is successfully set in the MAPI function call.
– The return code is greater than or equal to EKG_LogLevel.
Log record type 9 (MAPI transaction request) is sent to the RODM log based on EKG_MLogLevel. Log
record type 9 is sent to the RODM log when the return code from a method MAPI request is greater than
or equal to EKG_MLogLevel and one of the following conditions exists:
Chapter 19. Diagnostic tools for the Resource Object Data Manager (RODM) 263
• EKG_MTraceFlag in the associated method object is ON.
• One of the following bits corresponding to the method type is ON in EKG_MTraceType:
Bit
Method Type
24
Object-deletion
25
Object-independent
26
Named
27
Notification
28
Change
29
Query
Note: For the EKG_MTraceType field, bits are numbered 0-31 from left to right, where bit 0 is the leftmost
bit and bit 31 is the rightmost bit.
EKG_MTraceType is a field on each user object. Its default value is the value of the MTRACE_TYPE
parameter specified in the RODM customization member EKGCUST. EKG_MTraceFlag is a field on each
method object. Its default is 0 (method tracing disabled).
Log record type 10 (method entry and exit) is sent to the RODM log when a method is entered, the entry
trace bit (bit 31) in EKG_MTraceType is ON, and one of the following conditions exists:
Bit
Method Type
25
Object-independent
26
Named
27
Notification
28
Change
29
Query
Log record type 10 (method entry and exit) is also sent to the RODM log when a method is exited, the exit
trace bit (bit 30) in EKG_MTraceType is ON, and one of the following conditions exists:
Bit
Method Type
25
Object-independent
26
Named

27
Notification
28
Change
29
Query
The RODM log formatter

Use the RODM log formatter to format the RODM log data set. The RODM log formatter produces
formatted log records that contain a header with common data, log-type specific data, and a hexadecimal
memory dump of any additional log data. Except for hexadecimal memory dumps, an x follows
hexadecimal data that is produced by the RODM log formatter.
All examples of formatted log record entries are shown in uppercase letters, but MVS output for the
RODM program is originally in mixed case.
Using the RODM log formatter

The RODM log formatter program is supplied as sample EKGLG000, and is started using sample job
EKGRLOG. See “Starting the RODM log formatter” on page 267 for more information.
Samples EKGLG000 and EKGRLOG are installed with RODM through SMP/E.
Two versions of sample EKGLG000 are provided:
• A compiled C program. See “Customizing the RODM log formatter output” on page 265 and “Starting
the RODM log formatter” on page 267 for more information.
• As source code. To enable its use, perform the following tasks:
1. Compile sample EKGLG000.
2. Pre-link and link-edit EKGLG000, and save as EKGLG000 with entry point CEESTART.
3. Ensure that the appropriate runtime- library is installed.
4. Customize sample EKGRLOG to create the type of output you want. See “Customizing the RODM log
formatter output” on page 265 for more information.
Customizing the RODM log formatter output

Use the PARM keyword in the EXEC statement of the EKGRLOG JCL to customize the output that the
RODM log formatter produces. See Figure 39 on page 267 for an example of coding the PARM keyword.
If you specify any values on the PARM keyword, only those log types are formatted and output. If you do
not specify any values, the default is to format all log types.
You can use the following operands with the PARM keyword:
TYPE
Specifies the entry types that are to be printed.
You can specify any digits in the range of 1–10. You cannot specify TYPE 0 because type 0 is always
printed. If you omit this operand, all entries are printed.
METHODN
Specifies the name of the method for which type 1 log entries are printed.
Only the entries for the specified methods are printed. The asterisk (*) wildcard character is valid only
at the start and end of the string. The exclamation mark (!) wildcard character is not valid. You can
specify a maximum of 10 names.
If you specify METHODN and TYPE without specifying type 1 for TYPE, type 1 printing is assumed.
NOHEADER
Specifies that the log entry headers are not included in the formatted log output.
STIME
Specifies the start date and time of log records.
Records logged at and after this time are included in the formatted log output. The time the records
are logged is local time.
The operands of the STIME keyword are specified using the following format:
%STIME MM/DD/YYYY HH:MM:SS
where:
MM
Starting month
DD
Starting day
YYYY
Starting year. The short form of YY is also supported.
HH
Starting hour
MM
Starting minute
SS
Starting second
If the STIME keyword is not specified, all log records are formatted based on the keywords that are
specified.
Some operands of the STIME keyword can be omitted. See Table 123 on page 267 for a list of
operands that can be omitted and the default value used.
ETIME
Specifies the end date and time of log records.
Records logged at and before this time are included in the formatted log output. The time the records
are logged is local time.
The operands of the ETIME keyword are specified using the following format:
%ETIME MM/DD/YYYY HH:MM:SS
where:
MM
Ending month
DD
Ending day
YYYY
Starting year. The short form of YY is also supported.
HH
Ending hour
MM
Ending minute
SS
Ending second
If the ETIME keyword is omitted, all log records are formatted based on the keywords that are specified.
Some operands of the ETIME keyword can be omitted. Table 123 on page 267 lists the operands that can
be omitted and the default values:

Table 123. Default Values for STIME and ETIME Keyword Operands
Operand Default Value Used
MM/DD/YYYY The current date
YYYY The current year
YY The current year
HH:MM:SS (for STIME) 00:00:00
HH:MM:SS (for ETIME) 23:59:59
SS 00
Example of coding the PARM keyword

For this example of coding the PARM keyword, assume that you want log records that meet the following
criteria:
• Type 1, 3, and 9
• Method ABCDE and all methods that begin with FGH
• Entries from 1 P.M. on 05/02/2019 to 5 P.M. on 05/05/2019
Based on this criteria, code the PARM keyword as follows:
PARM='%TYPE 1 3 9 %METHODN ABCDE FGH* STIME 05/02/2019 13:00

ETIME 05/05/2019 17:00'
Figure 39. PARM Keyword Example
Starting the RODM log formatter

You can start the RODM log formatter using a sample job, EKGRLOG, that starts EKGLG000 as shown in
Figure 40 on page 267.
//STEP1 EXEC PGM=EKGLG000,PARM='/%TYPE 1 2 3 4 5 6 7 8 9 10'

//STEPLIB DD DSN=NETVIEW.V6R3M0.CNMLINK,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
//EKGLOG DD DSN=NETVIEW.CNM01.EKGLOGP,AMP=AMORG,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSDUMP DD SYSOUT=*
* * * End of file * * *
Figure 40. Example of JCL for EKGRLOG
EKGLG000 is the load module for the log formatter program. The STEPLIB data sets contain EKGLG000
and the necessary runtime libraries that are related to Language Environment for z/OS. The EKGLOG data
set contains the unformatted RODM log used as input to this program.
The SYSPRINT data set contains the formatted log along with the program output (messages, return
codes, and so on). This data set defaults to the DCB operands of LRECL=132 and RECFM=FBA.
When you have the required data sets, do the following steps:
1. Specify your input parameters under the STEP1 EXEC statement.
2. Specify the input log file under the EKGLOG DD name in the JCL.
3. Specify the output file under the SYSPRINT DD name in the JCL.
RODM Log Formatter return codes and messages

The return code from the log formatter job step indicates the success or failure of the formatting
operation. If a VSAM error occurs in which VSAM is able to issue a return code, the program output
contains error messages that might contain VSAM return and reason codes, C runtime messages, or both.
For some errors, MVS issues a system message to the console.
The log formatter issues the following return codes:
Return Code
Meaning
0
Format was successful.
4
No log records printed that match the PARMs specified.
Log type 0 is still printed out in this case.
8
Closing of the RODM log failed.
The following messages are issued. (_amrc is defined at the bottom of the section.)
Close error for EKGLOG

_amrc._code._feedback._rc = RETURN CODE
_amrc._code._feedback._fdbk = FEEDBACK
12
Opening of the RODM log failed.
Open error for EKGLOG

16
Reading of the RODM log failed.
Read error for EKGLOG

32
The specified PARM is not valid.
36
The date or time specified by the ETIME operand is earlier than the date or time specified by the
STIME operand.
When failing return codes are received from VSAM I/O functions, the _amrc structure is accessed to help
diagnose these errors. The _amrc structure, defined in the C standard I/O header file, contains diagnostic
information returned by VSAM. Some important fields are _amrc._code._rc and
_amrc._code._feedback. The _rc field contains the VSAM R15, and the _fdbk field contains the VSAM
error code or reason code.
The following messages are issued when an unrecognized log type is encountered:
UNKNOWN TYPE OF LOG RECORD

CANNOT FORMAT LOG SPECIFIC DATA
The following messages are issued when an unrecognized Log_type_flag in log type 8 is encountered:
CANNOT FORMAT LOG DATA

UNKNOWN TYPE OF STATISTICS RECORD

Return code and reason code definitions VSAM Administration Macro Instruction Reference
and Debugging and Run-Time Messages Guide
IECxxxx messages issued to the MVS console MVS System Messages
The formatted Log Record header

Figure 41 on page 269 is an example of a formatted log record header. The fields in this header are
common to all of the formatted log records described in this chapter.
You can prevent this header from printing by specifying the NOHEADER parameter on the PARM keyword
in the EXEC statement:
PARM='%NOHEADER'
RECORD NUMBER : 1 RBA : 0

LOG_TYPE : 0 (LOG VERSION RECORD) RECORD LENGTH : 120
TRANSACTION ID: 0000000000000000x TIMESTAMP : TUE APR 13 17:15:44 2009
USER APPL ID :
API VERSION : 1
Figure 41. Formatted Log Record Header
Following are descriptions of the fields in the formatted log record header:
RECORD NUMBER
Specifies the record number in the log file.
RECORD NUMBER is generated by the RODM log formatter and does not map to an unformatted log
record.
RBA
Specifies the relative byte address (RBA) of the unformatted log type in VSAM.
RBA is generated by the RODM log formatter and does not map to an unformatted log record.
LOG_TYPE
Specifies the log record type, as follows:
Log Type
Log Record Name
0
Log version record
1
Write-to-log MAPI log record
2
UAPI trace log record
3
Object-specific method log record
4
Object-independent method log record
5
RODM system services (SS) log record
6
Operator request log record
7
Abend log record
8
Statistics log record
9
MAPI trace log record
10
Method entry and exit log record
RECORD LENGTH
Specifies the length of the log entry.
TRANSACTION ID
Specifies the hexadecimal transaction ID generating this log record.
TIMESTAMP
Specifies when the log record was written to the RODM log.
USER APPL ID
Specifies the user application ID used to connect to RODM.
This field can be blank for log record types 0, 6, and 8.
API VERSION
Specifies the RODM application programming interface (API) version level.
If the log type record is generated on behalf of a transaction, the API version in log type records 1, 2,
3, 4, 6, 9, and 10 is set by the application. For log records type 0, 5, 7, and 8, RODM provides the
highest valid API version.
Log Record formats

The following sections describe each log record written by RODM. The unformatted log record sections
contain examples of each log record and tables that describe the primary fields in each log record.
The Data Type field in the tables contains RODM abstract data types (for example, Integer, Smallint, and
TimeStamp).
The formatted log record sections contain examples of each log record after they are formatted by the
RODM log formatter. Each formatted log record contains a primary header with data that is common to all
of the log records. The log-type specific fields are described following each example of the formatted log
record.

Abstract data types IBM Z NetView Resource Object Data Manager and
The fields in the common header “The formatted Log Record header” on page 269
Unformatted Log Record Type 0

Log record type 0 is the log version record. This is the first record written to the log file when you start
RODM. Log-level values do not determine when RODM generates this log record.
Figure 42 on page 270 is an example of an unformatted log record type 0.
RBA OF RECORD -
0
000000 00000078 00000000 4BC40028 70168000 00000000 00000000 40404040 40404040
*.........D.............. *
000020 00000001 00000000 D9D6C4D4 D5C1D4C5 00000006 00000002 00000000 C5D2C7D3
*........RODMNAME............EKGL*
000040 D6C7E240 E5E2C1D4 C3F6F1F0 4BC5D2C7 D3D6C7E2 00000000 00000000 00000000 *OGS
VSAMC610.EKGLOGS............*
000060 00000000 00000000 00000000 00000000 FFFFFFFC FFFFC7C0
*......................G{ *
Figure 42. Unformatted RODM Log Record Type 0

An example of a log record type 0 that has been “Formatted Log Record Type 0” on page 271
formatted by the RODM log formatter
Table 124 on page 271 provides descriptions of the fields, data types, and offsets in log record type 0.
Table 124. Information in Unformatted Log Record Type 0

Field Description Data Type Decimal Offset
Offset
Primary Header:
Total record length Integer 000 X'0'

Log type Smallint 004 X'4'
Reserved Smallint 006 X'6'
Time stamp TimeStamp 008 X'8'
Transaction ID TransID 016 X'10'
User application ID ApplicationID 024 X'18'
API version Integer 032 X'20'
Reserved Integer 036 X'24'
RODM name Char(8) 040 X'28'

RODM version level Integer 048 X'30'
RODM release level Integer 052 X'34'
RODM point release level Integer 056 X'38'
Log file DD name Char(8) 060 X'3C'
Name of data set containing log file Char(44) 068 X'44'
Time conversion in hours Integer 112 X'70'
Time conversion in seconds Integer 116 X'74'
Note:
1. The time stamp is in modified Lilian time format. It is a 64-bit floating point number that is the number
of milliseconds since midnight October 14, 1582.
2. The time conversion fields indicate the time difference between local time and Greenwich Mean Time
(GMT). For example, for a time zone 4 hours west of GMT, the time conversion in hours value is
X'FFFFFFFC' and the time conversion in seconds value is X'FFFFC7C0'
Each time field is a 4-byte signed integer. A positive value indicates a local time zone east of
Greenwich Mean Time (GMT), while a negative value indicates a local time zone west of GMT.
Formatted Log Record Type 0

Log record type 0 is the log version record. This is the first record written to the log file when you start
RODM.
Figure 43 on page 272 shows an example of log record type 0 that has been formatted by the RODM log
formatter.
DATE: 08/07/2019 N e t V i e w
TIME: 17:31 Resource Object Data Manager
Log Print Utility
Log_type : 0 (Log Version Record) RBA : 0
Record number : 1 Record Length : 120
Transaction ID: 0000000000000000x Timestamp : Fri Aug 08 17:30:42 2014
User Appl ID :
API Version : 1
RODM Name : RODMNAME
RODM Version : 6
RODM Release : 2
RODM Point Rel: 1
RODM Log DD : EKGLOGS
RODM Log DSN : VSAMC610.EKGLOGS
RODM GMT Value: -4
Figure 43. Formatted RODM Log Record Type 0
The following are descriptions of the fields in log record type 0:

RODM NAME
Specifies the RODM name.
RODM VERSION
Specifies the RODM version level.
RODM RELEASE
Specifies the RODM release level.
RODM POINT REL
Specifies the RODM point release level.
RODM LOG DD
Specifies the member DDNAME in the VSAM log data set.
For example, the primary DDNAME is EKGLOGP. The secondary DDNAME is EKGLOGS.
RODM LOG DSN
Specifies the VSAM data set name of the log file.
RODM GMT VALUE
Specifies the RODM GMT value.
This field is the difference between local time and GMT. The unit of this field is hours and, if
applicable, minutes and seconds. A positive value indicates a time zone east of GMT and a negative
value indicates a time zone west of GMT.

Log record type 1 is the write-to-log MAPI log record. It records information about RODM that you can use
to help debug methods. To debug methods, you can issue an MAPI call to send the output from the
method to the RODM log. Ensure that enough information is provided in this type of log record so that
problems in methods can be isolated and diagnosed.
Log record types 9 and 10 also have information for diagnosing methods.
Log-level values do not determine when RODM generates this log record.
Figure 44 on page 272 is an example of an unformatted log record type 1:
RBA OF RECORD - 3827
000000 0000005A 00010000 4BBC358E 1EB4B000 00000000 0000001B E4E2C5D9 F4404040
*........................USER4 *
000020 00000001 00000000 D4E3C8C4 C3F0F0F1 00000026 F1F4F0F2 406040E2 D3D78199
*........MTHDC001....1402 - SLP..*
000040 94A24DF1 5DD4E3C8 C4C3F0F0 F1406040 D3D3D781 9994A24D F15D *..(1)MTHDC001 - LLP....
(1) *

Information about log record types 9 and 10 “Unformatted Log Record Type 9” on page 296 and
“Unformatted Log Record Type 10” on page 298
An example of a log record type 1 that has been “Formatted Log Record Type 1” on page 273
Table 125 on page 273 provides descriptions of the fields, data types, and offsets in log record type 1:

Offset
Primary Header:

Method name MethodName 040 X'28'

Message CCSID Smallint 048 X'30'
User supplied data AnonymousVar 050 X'32'
Note: The time stamp is in modified Lilian time format. It is a 64-bit floating point number that is the
number of milliseconds since midnight October 14, 1582.

Log record type 1 is the write-to-log MAPI log record. It records information about RODM that you can use
to help debug methods.
Log record type 1 also records GMFHS non-console error messages. Each message describes the
following items:
• Message number
• The message text
• An explanation of the message
• Whether a memory dump was taken:
None
No memory dump was taken.
RODM
A memory dump of the RODM address space was taken.
GMFHS
A memory dump of GMFHS was taken.
Both
A memory dump of the RODM address space and GMFHS was taken.
• The type of message issued, as follows:
– Informational
– Internal error
– User error
Figure 45 on page 274 is an example of log record type 1 that has been formatted by the RODM log
formatter:
LOG_TYPE : 1 (WRITE TO LOG API) RBA : 3827

RECORD NUMBER : 30 RECORD LENGTH : 90
TRANSACTION ID: 000000000000001Bx TIMESTAMP : WED APR 15 17:07:49 2009
USER APPL ID : USER4
API VERSION : 1
METHOD NAME : MTHDC001
CCSID : 0
USER SUPPLIED DATA
0000 | 0026F1F4 F0F24060 40E2D3D7 819994A2 4DF15DD4 E3C8C4C3 F0F0F140 6040D3D3 * ..1402 -
SLPARMS(1)MTHDC001 - LL *
0020 | D7819994 A24DF15D *
PARMS(1) *

METHOD NAME
Specifies the name of the method issuing the Output to Log API function.
CCSID
Specifies the coded character set ID (CCSID) that identifies the code page and character set definition
used for the string that processes the RODM log data set.
USER SUPPLIED DATA
Specifies a user-supplied varying character string. This data is specified in the method code using an
MAPI call. The preceding example is a message in hexadecimal format, followed by the text of the
message, as follows:
*..1402 - SLPARMS(1)MTHDC001 - LL *

Debugging a method “Debugging methods” on page 248
CCSID Character Data Representation Architecture
Reference

Log record type 2 is the UAPI trace log record. You can use log record type 2 to help debug applications. If
the return code of a UAPI transaction is greater than or equal to EKG_LogLevel, the related information is
written to the RODM log file.
After you set the proper log-level (the default for EKG_LogLevel is 8), the selected type 2 log records
(output from RODM) are written to the RODM log after each transaction. You can check the return code,
the reason code, and the function block contents in the log record.
The Function_Block portion of the RODM log record is dependent on the type of function being run. Any
data being pointed to is resolved if RODM already knows the value of the data. If the length value for data
being pointed to is zero or if a field pointer is zero, no field data is contained in the log record. The
following restrictions also apply:
• The maximum length of SelfDefiningData shown in the log record is 256 bytes.
• The maximum length of Class_Name shown in the log record is 64 bytes.
• The maximum length of Object_Name shown in the log record is 254 bytes.
• The maximum length of Field_Name shown in the log record is 64 bytes.
• For an EKG_ExecuteFunctionList API request (1600), each single list request is treated as a single user
API request.

RBA OF RECORD - 402
000000 0000009D 00020000 4BBC358B 44690000 00000000 00000003 C5D2C7F6 F1404040
*........................EKG61 *
000020 00000001 00000000 00000000 0000008F 000005DD 00063618 00063640 00000000
*........................... ....*
000040 00000000 00000000 00000002 00000005 0000000A 0001720B 00010005 3B5A14D2
*...............................K*
000060 0000000A 0001720B C5D2C76D E2A8A2A3 8594C5D2 C76DE2A8 A2A38594 00000000
*........EKG_S.....EKG_S.........*
000080 00000001 00000017 0000000D 000171F2 C5D2C76D D9859385 81A285C9 C4
*...............2EKG_R......ID *

Field Description Data Type Decimal Hex Offset
Offset
Primary Header:

Secondary Header:
Return code Integer 040 X'28'
Reason code Integer 044 X'2C'
Function block Anonymous 048 X'30'

Information about RODM return codes and reason IBM Z NetView Resource Object Data Manager and
codes GMFHS Programmer's Guide
Information about the formatting of each function IBM Z NetView Resource Object Data Manager and
block GMFHS Programmer's Guide
An example of a log record type 2 that has been Figure 47 on page 276

Log record type 2 is the UAPI trace log record. You can use log record type 2 to help debug applications.
formatter.
LOG_TYPE : 2 (UAPI TRACE) RBA : 402
TRANSACTION ID: 0000000000000003x TIMESTAMP : WED APR 14 16:17:57 2009
USER APPL ID : EKG41
API VERSION : 1
RETURN CODE : 0
REASON CODE : 143
FUNCTION_BLOCK
FUNCTION ID: 1501 (QUERY A FIELD)
DATA :
0000 | 00063618 00063640 00000000 00000000 00000000 00000002 00000005 0000000A
* ................................ *
0020 | 0001720B 00010005 3B5A14D2 0000000A 0001720B C5D2C76D E2A8A2A3 8594C5D2
* ...........K........EKG_SYSTEMEK *
0040 | C76DE2A8 A2A38594 00000000 00000001 00000017 0000000D 000171F2 C5D2C76D *
G_SYSTEM...................2EKG_ *
0060 | D9859385 81A285C9 C4 *
RELEASEID *

RETURN CODE
Specifies the return code for the transaction generating this log record.
REASON CODE
Specifies the reason code for the transaction generating this log record.
FUNCTION_BLOCK
Specifies the function block information of the transaction generating this log record. Function block
information includes the function ID and data for the function.
The output for the function block is based on the expansion of the function block. Initially, the
function block contains
:
• Function block ID
• Entity access information block (EAIB) pointer and an EAIB
• Field access information block (FAIB) pointer and an FAIB. If FAIB is X'FFFFFFFF', see step “4” on
page 255 for “Return Code 12 with Reason Code 213 received” on page 254.
• Other data
The EAIB pointer points to the EAIB which contains pointers to data such as class name and object
name. The EAIB can also contain pointers to other data.
When RODM formats the output for a function block, it expands the function block by adding the data
(for example, class name and object name) pointed to.
The same process occurs for the FAIB. The FAIB pointer points to the FAIB which contains a pointer
to the field ID and pointers to other data. The function block is then expanded to include this data.
See Figure 48 on page 277 for a description of the expanded data in the function block.
The data for the function is dependent on the function for which RODM created this log record.

Figure 48. Expanded Function Block

The format of each function block IBM Z NetView Resource Object Data Manager and

Log Record Type 3 is the object-specific method log record. You can use log record type 3 to trace an
object-specific method.
An object-specific method can issue a MAPI call to set return and reason codes. This causes the program
to pass the return and reason codes back to the caller. If the specified return code is greater than or equal
to the value of EKG_LogLevel, a record is placed in the RODM Log.
000000 00000082 00030000 4BBC3630 8E292000 00000000 0000001B E4E2C5D9 F4404040
*........................USER4 *
000020 00000001 00000000 00000000 0000C3DE 000007D6 00000009 00010009 A342FCAD
*..............C....O............*
000040 00000028 0003D4E3 C8C4C3F0 F0F10016 00040011 F1F4F0F2 406040E2 D3D78199
*......MTHDC001......1402 - SLP..*
000060 94A24DF1 5D00001A 00040015 D4E3C8C4 C3F0F0F1 406040D3 D3D78199 94A24DF1 *..(1).......MTHDC001 -
LLP....(1*
000080 5D00
*). *
Figure 49. Unformatted Log Record Type 3

Offset
Primary Header:


Function Integer 048 X'30'
Class ClassID 052 X'34'
Object ObjectID 056 X'38'
Field FieldID 064 X'40'
Subfield Smallint 068 X'44'
Short lived parm SelfDefining 078 X'4E'
Long lived parm SelfDefining 078+n X'4E'+n


Log Record Type 3 is the object-specific method log record. You can use log record type 3 to trace an
object-specific method. Figure 50 on page 279 is an example of log record type 3 that has been formatted
by the RODM log formatter:

LOG_TYPE : 3 (OBJECT SPECIFIC METHOD) RBA : 3697
TRANSACTION ID: 000000000000001Bx TIMESTAMP : FRI APR 16 16:26:34 2009
USER APPL ID : USER4
API VERSION : 1
RETURN CODE : 0
REASON CODE : 50142
FUNCTION ID : 2006 (SET RETURN/REASON CODE)
CLASS : 00000009
OBJECT : 00010009A342FCADx
FIELD : 00000028
SUBFIELD : 3
METHOD_NAME : MTHDC001
SHORT LIVED PARM
DATA LENGTH : 22
DATA :
0000 | 00040011 F1F4F0F2 406040E2 D3D78199 94A24DF1 5D00 * ....1402 - SLPARMS(1). *
LONG LIVED PARM

DATA LENGTH : 26
DATA :
0000 | 00040015 D4E3C8C4 C3F0F0F1 406040D3 D3D78199 94A24DF1 5D00 * ....MTHDC001 - LLPARMS(1). *

RETURN CODE
Specifies the return code set by an object-specific method.
REASON CODE
Specifies the reason code set by an object-specific method.
FUNCTION ID
Specifies the function ID of the transaction causing this object-specific method to be started.
CLASS
Specifies the hexadecimal class ID associated by the object-specific method.
OBJECT
Specifies the hexadecimal object ID associated by the object-specific method.
FIELD
Specifies the hexadecimal field ID associated by the object-specific method.
SUBFIELD
Specifies the subfield ID to indicate the type of object-specific method.
METHOD_NAME
Specifies the object-specific method name.
SHORT LIVED PARM
Specifies the self-defining, short-lived parameters passed to the object-specific method.
DATA LENGTH
Specifies the size of the short-lived parameter text.
DATA
Specifies the short-lived parameter text.
LONG LIVED PARM
Specifies the self-defining, long-lived parameters passed to the object-specific method.
DATA LENGTH
Specifies the size of the long-lived parameter text.
DATA
Specifies the long-lived parameter text.

Log Record Type 4 is the object-independent method log record. You can use log record type 4 to trace an
object-independent method.
An object-independent method can issue an MAPI call to set return and reason codes. This causes the
program to pass the return and reason codes back to the caller. If the specified return code is greater
than or equal to EKG_LogLevel, a record is placed in the RODM Log.

000000 0000003E 00040000 4BBC3622 A8580000 00000000 00000007 C5D2C7F6 F1404040
*........................EKG61 ****
000020 00000001 00000000 00000008 00000063 000007D6 C5D9C6C3 D3D6D6D7 0000
*...................OERFCLOOP..*

Offset
Primary Header:


Function Integer 048 X'30'
Short lived parm SelfDefining 060 X'3C'

A description of log-level settings “Log-Level values” on page 262

Log Record Type 4 is the object-independent method log record. You can use log record type 4 to trace an
object-independent method.
formatter.

LOG_TYPE : 4 (OBJECT INDEPENDENT METHOD) RBA : 1069
TRANSACTION ID: 0000000000000007x TIMESTAMP : FRI APR 14 12:23:42 2009
API VERSION : 1
RETURN CODE : 8
REASON CODE : 99
FUNCTION ID : 2006 (SET RETURN/REASON CODE)
METHOD NAME : ERFCLOOP
SHORT LIVED PARM
DATA LENGTH : 0
DATA CONTENT:

RETURN CODE
Specifies the return code set by an object-independent method.
REASON CODE
Specifies the reason code set by an object-independent method.
FUNCTION ID
Specifies the function ID of the function causing this object-independent method to be started.
METHOD NAME
Specifies the object-independent method name.
SHORT LIVED PARM
Specifies the self-defining short-lived parameters passed to the object-independent method.
DATA LENGTH
Specifies the size of the short-lived parameter data.
DATA CONTENT

Log record type 5 is the RODM system services (SS) log record. You can use log record RODM type 5 to
track operating system macros.
If an operating system macro fails to complete a request, log record type 5 is written in the log file to
record the error condition. Log-level values do not determine when RODM generates this log record.
Log record type 5 contains information for the operating system macros that fail during the transactions
shown in the Transaction ID field.
RBA OF RECORD - 672

000000 0000004C 00050000 4BBC3583 B357E000 00000000 00000005 C5D2C7F6 F1404040
*...<......................EKG61 *
000020 00000001 00000000 D3D6C1C4 40404040 C5D7D3D6 C3404040 00000008 00000008 *........LOAD
EPLOC ........ *
000040 C5D2C7D4 D2F1F0F6 00000001
*EKGMK106.... *
Offset
Primary Header:

Operating system macro name Char(8) 040 X'28'

Operating system macro parameter Char(8) 048 X'30'
(keyword)
Operating system return code Integer 056 X'38'
Operating system reason code Integer 060 X'3C'
SS caller module name Char(8) 064 X'40'
Location ID Integer 072 X'48'


Log record type 5 is the RODM system services (SS) log record. You can use log record type 5 to track
operating system macros.
formatter:
LOG_TYPE : 5 (RODM SYSTEM SERVICES) RBA : 672
TRANSACTION ID: 0000000000000005x TIMESTAMP : THU APR 16 14:05:43 2009
API VERSION : 1
O/S MACRO NAME: LOAD
O/S MACRO PARM: EPLOC
RETURN CODE : 8
REASON CODE : 8
SYS SRV CALLER: EKGMK106
LOCATION ID : 1

O/S MACRO NAME
Specifies the name of the failed operating system macro. For example, the macro is LOAD.
O/S MACRO PARM
Specifies the major parameter of the failed operating system macro.

RETURN CODE
Specifies the return code from the failed macro.
REASON CODE
Specifies the reason code from the failed macro.
SYS SRV CALLER
Specifies the name of the RODM module that called the failing macro.
LOCATION ID
Specifies the location ID within the calling module. You can use the location ID to search the calling
module for a specific location.

Log Record Type 6 is the operator request log record. It is written to the log file after the operator has
completed a successful action, such as starting RODM or using the MVS MODIFY command.
A bit setting for the type of operator action is on if the condition is true.
Figure 55 on page 283 shows an example of an unformatted log record type 6.
Log-level values do not determine when RODM generates this log record.
RBA OF RECORD - 120

000000 00000031 00060000 4BBC358B 3FF9A000 00000000 00000000 40404040 40404040
*.............9........... *
000020 00000001 00000000 00000000 00000000 40
*................ *
Field Description Data Type Decimal Hex
Offset Offset
Primary Header:
Last checkpoint transaction ID TransID 040 X'28'

Bit settings: Char(1) 048 X'30'
• MVS START command warm start: X'80'
• MVS START command cold start: X'40'
• MVS MODIFY command checkpoint request: X'20'
• MVS MODIFY command termination request: X'10'
The lower 4 bits are reserved

Log Record Type 6 is the operator request log record. It is written to the log file after the operator has
completed a successful action, such as starting RODM or using the MODIFY command.
formatter:
LOG_TYPE : 6 (OPERATOR REQUEST) RBA : 120

TRANSACTION ID: 0000000000000000x TIMESTAMP : WED APR 12 16:17:39 2009
USER APPL ID :
API VERSION : 1
LAST CHECKPT : 0000000000000000X
STATE INFO : BIT VALUE -> 0100XXXX TRANSACTION -> COLD START

LAST CHECKPT
Specifies the hexadecimal transaction ID issuing the last checkpoint request.
STATE INFO
Specifies the bit flags to indicate which requests were issued. Bits are numbered 0–7 from left to
right, where bit 0 is the leftmost bit and bit 7 is the rightmost bit.
Bit
Meaning
0
Warm start using the MVS START command
1
Cold-start using the MVS START command
2
Checkpoint for RODM using the MVS MODIFY command
3
Terminate RODM using the MVS MODIFY command
4-7
Reserved

Log record type 7 is the abend log record.
During operation, RODM might encounter error conditions that are recorded. If an abend condition occurs,
a type 7 log record (abend log record) is written to the RODM log. The type 7 log record indicates the
name of the abend module and system diagnostic work area (SDWA) information.
Note: Only the first 56 bytes of data are described in the log record header.

000000 000002D0 00070000 4BBC3625 B3DD7000 00000000 0000000C 40404040 40404040
*........................ *
000020 00000001 00000000 000C9000 00000009 C5D9C6C3 D3D6D6D7 0338BD54 840C9000
*................ERFCLOOP........*
000040 FF840009 00000000 FF840009 00000000 000B2978 000B2848 00000001 833CAFEA
*................................*
000060 000B2750 00000000 00000000 000B2750 000B2598 000B2614 00000000 00000000
*...&;..........&;...............*
000080 000B1010 000B2880 82A94162 000B1608 009F7A68 00000000 00000000 00000000
*..................:.............*
0000A0 078C2400 833CB00E 00020009 02A03828 078C2400 833CB00E 00020009 02A03828
*................................*
0000C0 000B2978 000B2848 00000001 833CAFEA 000B2750 00000000 00000000 000B2750
*...................&;..........&*
0000E0 000B2598 000B2614 00000000 00000000 000B1010 000B2880 82A94162 000B1608
*................................*
000100 FA0006C8 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*...H............................*
000120 40040001 00001000 00000000 0338BAB0 00000000 00000000 00000000 00000000
* ...............................*
000140 00000000 00000000 00000000 00000000 00000000 00000000 002B0000 00000000
*................................*
000160 00000000 00000000 00000000 00000000 00000000 0338BA60 00000000 00000000
*.......................-........*
000180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0001A0 00000000 FFFF0005 0338BD98 FFFF002B 0001002A 00000000 00000000 00000000
*................................*
0001C0 00000000 00000000 00FF0000 00000000 00000000 00000000 00000000 00000000
*................................*
0001E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000220 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000240 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000260 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000280 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0002A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0002C0 00000000 00000000 000000E2 C4E6C140
*...........SDWA *

Offset
Primary Header:

Return code set by MVS at abend Integer 040 X'28'

Reason code set by MVS at abend Integer 044 X'2C'
Abend module name Char(8) 048 X'30'
SDWA INFO DATAAREA 056 X'38'


Log record type 7 is the abend log record.
During operation, RODM might encounter error conditions that are recorded. If an abend condition occurs,
a type 7 log record (abend log record) is written to the RODM log.
formatter:
LOG_TYPE : 7 (ABEND) RBA : 1692

TRANSACTION ID: 000000000000000Cx TIMESTAMP : FRI APR 14 13:16:55 2009
USER APPL ID :
API VERSION : 1
RETURN CODE : 000C9000
REASON CODE : 00000009
MODULE NAME : ERFCLOOP
SDWA DATA
0000 | 0338BD54 840C9000 FF840009 00000000 FF840009 00000000 000B2978 000B2848 * .. .D....D.......D.............. *
0020 | 00000001 833CAFEA 000B2750 00000000 00000000 000B2750 000B2598 000B2614 * ....C......&;..........&;..Q.... *
0040 | 00000000 00000000 000B1010 000B2880 82A94162 000B1608 009F7A68 00000000 * ................BZ........:..... *
0060 | 00000000 00000000 078C2400 833CB00E 00020009 02A03828 078C2400 833CB00E * ............C...............C... *
0080 | 00020009 02A03828 000B2978 000B2848 00000001 833CAFEA 000B2750 00000000 * ....................C......&;... *
00A0 | 00000000 000B2750 000B2598 000B2614 00000000 00000000 000B1010 000B2880 * .......&;..Q.................... *
00C0 | 82A94162 000B1608 FA0006C8 00000000 00000000 00000000 00000000 00000000 * BZ.........H.................... *
00E0 | 00000000 00000000 40040001 00001000 00000000 0338BAB0 00000000 00000000 * ................................ *
0100 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
0120 | 002B0000 00000000 00000000 00000000 00000000 00000000 00000000 0338BA60 * ...............................- *
0140 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
0160 | 00000000 00000000 00000000 FFFF0005 0338BD98 FFFF002B 0001002A 00000000 * .................. Q............ *
0180 | 00000000 00000000 00000000 00000000 00FF0000 00000000 00000000 00000000 * ................................ *
01A0 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
01C0 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
01E0 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
0200 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
0220 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
0240 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
0260 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * ................................ *
0280 | 00000000 00000000 00000000 00000000 000000E2 C4E6C140 * ...................SDWA *
PSW : 078C2400 833CB00E

REGISTERS :
REG 0 - 000B2978 REG 1 - 0B297800 REG 2 - 2978000B REG 3 - 78000B28
REG 4 - 000B2848 REG 5 - 0B284800 REG 6 - 28480000 REG 7 - 48000000
REG 8 - 00000001 REG 9 - 00000183 REG 10 - 0001833C REG 11 - 01833CAF
REG 12 - 833CAFEA REG 13 - 3CAFEA00 REG 14 - AFEA000B REG 15 - EA000B27

RETURN CODE
Specifies the return code from an abend.
REASON CODE
Specifies the reason code from an abend.
MODULE NAME
Specifies the name of the module where the abend was detected.
SDWA INFO
Specifies the MVS control block information about the abend.
PSW
Specifies the program status word (PSW) that points to the instruction that caused the abend. The
PSW starts at X'78' in the SDWA field.
REGISTERS
Specifies the registers in the SDWA field. The registers start at X'88' in the SDWA field.

MVS control block data for the abend z/OS MVS Data Areas

Log record type 8 is the statistics log record. The type 8 log record is a table with statistical information
about each RODM cell pool stored as an entry in that table. The table can have multiple RODM cell pool
entries.
This log record is written to the RODM log when you issue the MVS MODIFY command with the STATCELL
parameter. Log-level values do not determine when RODM generates this log record.
The table header contains:
• Current pocket count
• Available pocket active count
• Number of entries
The statistics log record lists the status of cell pool usage for segments or windows, and the lock word
usage. The format of the log record is different for each log_type_flag as follows:
Flag
Meaning
0
For cell pool usage information for segments. Table 133 on page 289 describes the cell pool usage
information for segments.
1
For cell pool usage information for windows. Table 133 on page 289 describes the cell pool usage
information for windows.
5
For API statistics. Table 134 on page 290 describes API statistics.
RBA OF RECORD -
120
000000 00000D58 00080000 4BC40028 72F4F000 00000000 00000000 40404040 40404040
*.........D...40......... *
000020 00000001 00000000 00000000 00000001 00000001 00000038 00000008 00000001
*................................*
000040 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000060 00000000 00000000 00000000 00000000 00000000 0000000C 00000001 00000000
*................................*
000080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0000A0 00000000 00000000 00000000 00000000 00000010 00000001 00000000 00000000
*................................*
0000C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0000E0 00000000 00000000 00000000 00000014 00000001 00000000 00000000 00000000
*................................*
000100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000120 00000000 00000000 00000018 00000001 00000000 00000000 00000000 00000000
*................................*
000140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000160 00000000 0000001C 00000001 00000000 00000000 00000000 00000000 00000000
*................................*
000180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0001A0 00000020 00000001 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0001C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000024
*................................*
0001E0 00000002 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000200 00000000 00000000 00000000 00000000 00000000 00000000 00000028 00000002
*................................*
000220 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000240 00000000 00000000 00000000 00000000 00000000 00000030 00000002 00000000
*................................*
000260 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000280 00000000 00000000 00000000 00000000 00000034 00000002 00000000 00000000
*................................*
0002A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0002C0 00000000 00000000 00000000 00000038 00000002 00000000 00000000 00000000
*................................*
0002E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000300 00000000 00000000 0000003C 00000002 00000000 00000000 00000000 00000000
*................................*
000320 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000340 00000000 00000040 00000002 00000000 00000000 00000000 00000000 00000000
*....... ........................*
000360 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000380 00000044 00000003 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0003A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000048
*................................*
0003C0 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
0003E0 00000000 00000000 00000000 00000000 00000000 00000000 00000050 00000003
*...........................&....*
000400 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000420 00000000 00000000 00000000 00000000 00000000 00000058 00000003 00000000
*................................*
000440 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000460 00000000 00000000 00000000 00000000 00000064 00000003 00000015 00000000
*................................*
000480 00000000 00000000 00000000 00000000 00000000 00000000 00000002 00000002
*................................*
0004A0 00000008 00000003 00000006 00000068 00000003 00000030 00000000 00000002
*................................*
0004C0 00000001 00000000 00000000 00000002 00000000 00000004 00000000 00000017
*................................*
0004E0 00000000 00000013 00000070 00000003 000001B2 00000000 00000012 0000000E
*................................*
000500 00000000 0000000A 00000012 00000029 00000027 00000021 00000072 0000005F
*...............................¬*
⋮
⋮
⋮
000C00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
000C20 00000000 00000000 00000000 00004000 00000080 00000004 00000000 00000000
*.............. .................*
000C40 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
*................................*
288 IBM Z NetView:
000C60 Troubleshooting
00000000 Guide
00000004 00006000 000000C0 00000000 00000000 00000000 00000000 *..........-....
{................*
000C80 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Offset
Primary Header:
Log type flag Integer: 040 X'28'

044… X'2C'…
The log type flags follow:

0 = Cell pool usage information for segments. Table 133 on page 289 provides descriptions of cell pool
usage information for segments.
1 = Cell pool usage information for windows. Table 133 on page 289 provides descriptions of cell pool
usage information for windows found in log record type 8.
5 = API statistics. Table 134 on page 290 describes information for API statistics.
The number of entries in log record type 8 specifies how many cell pools are printed in the type 8 log
record. Statistical information for each cell pool contains:
• Cell size
• Pool size
• Number of cells in use
• High water mark
• Percentage of cells in use
• Total percentage of cells in use
• Percentage of high water
• Segment histogram counter (eight integer fields)
Table 133. Log_type_flag=0 or 1: Cell Pool Usage Information for Segments and Windows
Field Description Data Type Decimal Offset Hex Offset
Current pocket count Integer 044 X'2C'
Available pocket active count Integer 048 X'30'
Table 133. Log_type_flag=0 or 1: Cell Pool Usage Information for Segments and Windows (continued)
Number of entries
Cell pool array Integer 052 X'34'

Cell size Integer 056 X'38'
Pool size Integer 060 X'3C'
Number of cells in use Integer 064 X'40'
High water mark Integer 068 X'44'
Percentage of cells in use Integer 072 X'48'
Total percent of cells in use Integer 076 X'4C'
Percentage of high water Integer 080 X'50'
Segment histogram counter(8) Integer 084 X'54'
Table 134 on page 290 provides descriptions of API statistics found in the unformatted log record type 8.
Table 134. Log_type_flag=5: API Statistics

Last Clear Time stamp TimeStamp 044 X'2C'
Output Time stamp TimeStamp 052 X'34'
Number of query methods triggered Integer 056 X'38'
Number of change methods triggered Integer 060 X'3C'
Number of notification methods triggered Integer 064 X'40'
Number of object deletion methods triggered Integer 068 X'44'
Number of permanent entries (N1) Integer 072 X'48'
Number of regular entries (N2) Integer 076 X'4C'
Permanent function call identifier Integer 20*(N 1-1)+4+76 (See note See note 2
1)
Total successful calls for permanent function ID Floating 20*(N1-1)+12+76 (See See note 2
through user API note 1)
Total successful calls for permanent function ID Floating 20*(N1-1)+20+76=x (See See note 2
through method API note 1)
Regular function call identifier Integer 20*(N2-1)+4+x (See note See note 2
1)
Total successful calls for regular function ID through Integer 20*(N2-1)+8+x (See note See note 2
user API 1)
Total unsuccessful calls for regular function ID Integer 20*(N2-1)+12+x (See note See note 2
through user API 1)
Total successful calls for regular function ID through Integer 20*(N2-1)+16+x (See note See note 2
method API 1)
Total unsuccessful calls for regular function ID Integer 20*(N2-1)+20+x (See note See note 2
through method API 1)
Note:
1. Calculating Decimal Offsets for API Statistics:

N1 is equal to the value of the Number of Permanent Entries field. N2 is equal to the value of the
Number of Regular Entries field. x is equal to the value of the Total Successful calls for the permanent
function ID through the user API field.
For example, to determine the decimal offset for the Permanent function call identifier field where the
value of N1 is 4, calculate:
20*(4-1)+4+72=136
To determine the value of the Regular function call identifier field (and other regular function ID fields
with the N2 and x values):
a. Calculate the decimal offset of the Successful calls for the permanent function ID through the user
API field. This value is x in the equation.
b. If N2 is 4 and x is 152, calculate the decimal offset as shown in this example:
20*(4-1)+4+152=216.
2. To determine the hexadecimal offset for this field, calculate the decimal offset and convert the value
to hexadecimal.

Log record type 8 is the statistics log record. The type 8 log record is a table with statistical information
about each RODM cell pool stored as an entry in that table. It supplies segment and window statistics as
well as lock level statistics.

Formatted log record type 8 for segment and “Segment and Window Statistics” on page 291
window statistics
Formatted log record type 8 for API statistics “API Statistics” on page 293
Segment and Window Statistics

Figure 60 on page 292 is an example of the output from the RODM log formatter for log record type 8
segment and window statistics:
Log_type : 8 (Statistics) RBA :
120
Record number : 2 Record Length :
3416
Transaction ID: 0000000000000000x Timestamp : Fri Aug 07 17:30:54
2009
User Appl
ID :
API Version :
1
Stat Type : 0 (Segment
Statistics)
Current pocket:
1
Avail. pocket :
1
No. of Entries:
56
Cell Size ( 0): 8 Pool Size :
1
No. in Use : 0 High Water Mrk:
0
In Use Percent: 0 Total Inuse % :
0
High Water % :
0
Histogram
Data :
( 0) 0 ( 1) 0 ( 2) 0 ( 3)
0
( 4) 0 ( 5) 0 ( 6) 0 ( 7)
0
Cell Size ( 1): 12 Pool Size :
1
No. in Use : 0 High Water Mrk:
0
In Use Percent: 0 Total Inuse % :
0
High Water % :
0
Histogram Data :
( 0) 0 ( 1) 0 ( 2) 0 ( 3)
0
( 4) 0 ( 5) 0 ( 6) 0 ( 7)
0
⋮
⋮
⋮
Figure 60. Formatted RODM Log Record Type 8 for Segment and Window Statistics

STAT TYPE
Specifies the type of statistics gathered:
Entry
Meaning
0
Segment statistics
1
Window statistics
CURRENT POCKET
Specifies the current number of dedicated reserved windows. This is the number of windows that you
want to maintain in reserve for use as needed.
The initial value for this field is specified in member EKGCUST but the RODM can increase the value if
needed.

AVAIL. POCKET
Specifies the current number of available reserved windows. This is the number of windows that are
available.
NO. OF ENTRIES
Specifies the number of entries in the cell pool array.
CELL SIZE
Specifies the cell size in bytes as defined in member EKGCUST.
POOL SIZE
Specifies the pool size in multiples of 4 K pages as defined in member EKGCUST.
NO. IN USE
Specifies the number of cells that are unavailable.
HIGH WATER MRK
Specifies the maximum number of retries to obtain a lock.
IN USE PERCENT
Specifies the percentage of in-use cells.
TOTAL INUSE %
Specifies the percentage of total cells in use.
HIGH WATER %
Specifies the percentage for the high water mark.
HISTOGRAM DATA
Specifies the counter for histograms. The histogram is the frequency of counts of data ranges over
a time. The histogram data field provides a count of the number of occurrences in a given range.
API Statistics
Figure 61 on page 294 is an example of the output from the RODM log formatter for log record type 8 API
statistics:
DATE: 04/12/2019 N E T V I E W PAGE: 1
TIME: 17:55 RESOURCE OBJECT DATA MANAGER
LOG PRINT UTILITY
LOG_TYPE : 8 (STATISTICS) RBA : 299
TRANSACTION ID: 0000000000000000X TIMESTAMP : WED APR 12 17:50:28 2009
USER APPL ID :
API VERSION : 1
STAT TYPE : 5 (API STATISTICS )
LAST CLEAR TIMESTAMP : WED APR 12 17:49:28 2009
OUTPUT TIMESTAMP : WED APR 12 17:50:28 2009
NO. OF QUERY TRIGGERED : 0
NO. OF CHANGE TRIGGERED : 99
NO. OF NOTIFY TRIGGERED : 0
NO. OF OBJDEL TRIGGERED : 0
NO. OF PERMANENT ENTRIES: 14
PERMANENT COUNT DATA :
FUNCTION ID : 1302 (CREATE A CLASS)
PERM UAPI COUNT : 000000000000001EX
FUNCTION ID : 1304 (CREATE A FIELD)
PERM UAPI COUNT : 0000000000000078X
FUNCTION ID : 1306 (CREATE A SUBFIELD)
PERM UAPI COUNT : 000000000000020BX
FUNCTION ID : 1406 (LINK 2 OBJECTS - METHODS NOT TRIGGERED)
PERM UAPI COUNT : 0000000000000C78X
FUNCTION ID : 1409 (CREATE AN OBJECT)
PERM UAPI COUNT : 0000000000000205X
NO. OF REGULAR ENTRIES : 46
REGULAR COUNT DATA :
FUNCTION ID : 1101 (CONNECT TO RODM)
SUCCESS UAPI COUNT: 1
FAIL UAPI COUNT : 1
FUNCTION ID : 1102 (DISCONNECT FROM RODM)
FUNCTION ID : 1302 (CREATE A CLASS)
FUNCTION ID : 1304 (CREATE A FIELD)
FUNCTION ID : 1306 (CREATE A SUBFIELD)
FUNCTION ID : 1401 (CHANGE A FIELD)
FUNCTION ID : 1403 (CHANGE A SUBFIELD)
SUCCESS MAPI COUNT: 99
FUNCTION ID : 1406 (LINK 2 OBJECTS - METHODS NOT TRIGGERED)
FUNCTION ID : 1409 (CREATE AN OBJECT)
FUNCTION ID : 1416 (TRIGGER AN OBJECT INDEPENDENT METHOD)
FUNCTION ID : 1417 (ADD OBJECT DELETION NOTIFICATION SUBS)
FAIL UAPI COUNT : 2
FUNCTION ID : 1418 (DELETE OBJECT DELETION NOTIFICATION SUBS)
FUNCTION ID : 1501 (QUERY A FIELD)
FUNCTION ID : 1502 (QUERY A SUBFIELD)
FUNCTION ID : 2009 (MESSAGE TRIGGERED ACTION)
TOTAL RECORDS READ : 4

TOTAL RECORDS PRINTED: 4
Figure 61. Formatted RODM Log Record Type 8 for API Statistics

STAT TYPE
Specifies that API statistics be gathered.
LAST CLEAR TIMESTAMP
Specifies the time when the regular data was cleared. The time displayed in this field is one of the
following times:
• The last time the MODIFY STATAPI CLEAR command was issued
• The last time RODM was cold-started
• The last time a checkpoint was taken, if that checkpoint was followed by a warm start

OUTPUT TIMESTAMP
Specifies the time when the API statistics were output.
NO. OF QUERY TRIGGERED
Specifies the number of calls for query the methods triggered.
NO. OF CHANGE TRIGGERED
Specifies the number of calls for change the methods triggered.
NO. OF NOTIFY TRIGGERED
Specifies the number of calls for notification the methods triggered.
NO. OF PERMANENT ENTRIES
Specifies the number of different function identifiers that RODM tracks and reports in the "Permanent
Count Data" section of the formatted log record.
All the function identifiers and their counts are listed in the unformatted log record.
However, in the formatted log record, any function identifiers that have a total count of zero are not
displayed.
PERMANENT COUNT DATA
Array of permanent data kept by RODM.
FUNCTION ID
Specifies the function ID of permanent data.
PERM UAPI COUNT
Specifies the number of calls through the user API with a return code of zero (0) for the function
ID.
PERM MAPI COUNT
Specifies the number of calls through the method API with a return code of 0 for the function ID.
NO. OF REGULAR ENTRIES
Specifies the number of function identifiers that RODMtracks and reports on in the "Regular Count
Data" section of the formatted log record.
All the function identifiers and their counts are listed in the unformatted log record.
However, in the formatted log record, any function identifiers that have a total count of zero are not
displayed.
REGULAR COUNT DATA
Array of regular data kept by RODM.
The data counters for the regular entries are cleared when:
• The MODIFY STATAPI CLEAR command is issued.
• RODM is cold-started.
Note: After a warm start, the counters for the API statistics are restored from the last checkpoint
before the warm start.
To ensure that the counters are correct, either perform a checkpoint immediately before a warm start
or use the MODIFY STATAPI CLEAR command to clear the counters after a warm start.
Overflow for API statistics counters is possible but can be avoided using the MODIFY STATAPI CLEAR
command. Multiple overflows can occur over long periods of time and can cause peaks and valleys of
activity to be lost. Therefore, rates over long periods of time might not be meaningful.
FUNCTION ID
Specifies the function ID of regular data.
SUCCESS UAPI COUNT
Specifies the number of calls through the user API with a return code of zero (0) for the function
ID.
FAIL UAPI COUNT
Specifies the number of calls through the user API with a return code greater than zero (0) for the
function ID. Unauthorized calls to functions are not counted.
SUCCESSFUL MAPI COUNT
Specifies the number of calls through the method API with a return code of zero (0) for the
function ID.
FAIL MAPI COUNT
Specifies the number of calls through the method API with a return code greater than zero (0) for
the function ID. Unauthorized calls to functions are not counted.

Log record type 9 is the MAPI trace log record. You can use this log record to help debug a method.
If one of the two fields (EKG_MTraceType or EKG_MTraceFlag) indicates the method is traced, a type 9
log record is written to the RODM log.
• EKG_MTraceType is a field on each user object. Its default value is the value of the EKG_MTraceType
parameter specified in the RODM customization member EKGCUST.
• EKG_MTraceFlag is a field on each method object. Its default is 0 (method tracing disabled).
Log record type 9 is written to the RODM log only if the return code of the method API function is greater
than or equal to EKG_MLogLevel.
After you set the proper EKG_LogLevel, EKG_MTracetype, and EKG_MTraceflag, the selected type 9 log
records are written to the RODM log after each method API function in the selected methods.

000000 00000046 00090000 4BBC358B 448DA000 00000000 0000000C C5D2C7F6 F1404040
*........................EKG61 *
000020 00000001 00000000 C5D9C6C3 D3D6D6D7 00000008 00000017 D5000002 000007D8
*........ERFCLOOP........N......Q*
000040 FFFFFFFF 01F4
*.....4 *

Offset
Primary Header:

Reason code Integer 052 X'34'

Table 135. Information in Unformatted Log Record Type 9 (continued)
Offset
Method type 056 X'38'
Char:
C, I, N, O, Q, or X
C
Specifies change
method
I
Specifies object-
independent method
N
Specifies named method
O
Specifies object-deletion
method
Q
Specifies query method
X
Specifies notification
method
* Three reserved bytes Three bytes 057 X'39'

Function block 060 X'3C'

Information about the MAPI tracing capability IBM Z NetView Resource Object Data Manager and

Log record type 9 is the MAPI trace log record. You can use this log record to help debug a method. Figure
63 on page 297 is an example of log record type 9 that was formatted by the RODM log formatter:
LOG_TYPE : 9 (MAPI TRACE) RBA : 1692

TRANSACTION ID: 000000000000000Cx TIMESTAMP : WED APR 12 16:17:58 2009
API VERSION : 1
RETURN CODE : 8
REASON CODE : 23
METHOD TYPE : N (NAMED METHOD)
FUNCTION_BLOCK
FUNCTION ID : 2008 (OUTPUT TO LOG)
DATA :
0000 | FFFFFFFF 01F4 * .....4 *
METHOD NAME
Specifies the name of the method issuing the MAPI call.
RETURN CODE
Specifies the return code of the MAPI call.
REASON CODE
Specifies the reason code of the MAPI call.
METHOD TYPE
Specifies the type of method, as follows:
Entry
Meaning
C
Change method
I
Object-independent method
N
Named method
O
Object-deletion method
Q
Query method
X
Notification method
FUNCTION BLOCK
Specifies the function block information of the transaction generating this log record. Function block
information includes the function ID and data for the function.
The output for the function block is based on the expansion of the function block. Figure 48 on page
277 shows how the data in the function block is expanded.
The data for the function is dependent on the function for which RODM created this log record.

The format of each function block IBM Z NetView Resource Object Data Manager and

Log record type 10 is the method entry and exit log record. You can use this log record to diagnose a
method.
If one of the two fields (EKG_MTraceType or EKG_MTraceFlag) indicates the method is traced, a type 10
log record is written to the RODM log. This entry is written to the RODM log according to the method entry
and exit bit in EKG_MTraceType.
Note:
1. EKG_MTraceType is a field on each user object. Its default value is the value of the EKG_MTraceType
parameter specified in the RODM customization member EKGCUST.
2. EKG_MTraceFlag is a field on each method object. Its default is 0 (method tracing disabled).

000000 00000042 000A0000 4BBC358B 448DA000 00000000 0000000C C5D2C7F6 F1404040
*........................EKG61 *
000020 00000001 00000000 C5D9C6C3 D3D6D6D7 00000000 00000000 D5000000 00000001
*........ERFCLOOP........N.......*
000040 0000
*.. *

Offset
Primary Header:

Reason code Integer 052 X'34'
Method type 056 X'38'
Char:
C, I, N, Q, or X
C
Specifies change
method
I
Specifies object-
independent method
N
Specifies named method
Q
Specifies query method
X
Specifies notification
method
* Three reserved bytes Three bytes 057 X'39'

Entry/Exit Integer: 1 or 2 1=Entry log 060 X'3C'
record 2=Exit log record
Short lived parm SelfDefining 064 X'40'
Setting log-levels, EKG_MTraceType, and “Log-Level values” on page 262
EKG_MTraceFlag

Log record type 10 is the method entry and exit log record. You can use this log record to help debug a
method.
formatter.
LOG_TYPE : 10 (METHOD ENTRY/EXIT TRACE) RBA : 1626

TRANSACTION ID: 000000000000000Cx TIMESTAMP : WED APR 12 16:17:58 2009
API VERSION : 1
RETURN CODE : 0
REASON CODE : 0
METHOD TYPE : N (NAMED METHOD)
ENTRY_EXIT : 1 (ENTRY)
SHORT LIVED PARM
0000 | 0000
* ..*
METHOD NAME
Specifies the name of the method issuing the MAPI.
RETURN CODE
Specifies the return code of the MAPI.
REASON CODE
Specifies the reason code of the MAPI.
METHOD TYPE
Specifies the type of method, as follows:
Entry
Meaning
C
Change method
I
Object-independent method
N
Named method
Q
Query method
X
Notification method
ENTRY EXIT
For entry and exit, this record was written when the method entered or exited. You can use this field
to determine when the method began and when it completed.
For storage, this record indicates that a method acquired storage, but did not release the storage
when the method ended.

Possible values for this record are:
Type
Meaning
1
Specifies entry
2
Specifies exit
3
Specifies method storage
For type 1 or 2, the SHORT LIVED PARM field is included in the formatted log record type 10.
SHORT LIVED PARM
Specifies the self-defining, short-lived parameters passed to the method.
DATA LENGTH
Specifies the size of short-lived parameter text.
DATA CONTENT

The RODM Internal Trace

The RODM internal trace can be activated to provide more detailed documentation of internal RODM
activity. The trace data is used by IBM Software Support to assist in diagnosis of RODM problems.
This internal trace uses the MVS Component Trace facility and is controlled by the MVS TRACE command.
The trace is written to a wrap around table in a trace dataspace (EKGTRDSP).
The general syntax of the TRACE command is:
TRACE CT,ON,COMP=rodmname
Where rodmname is the name of the RODM to be traced, as determined by the PARM string in the RODM
JCL procedure.
By default, the amount of virtual storage which is used to contain the trace data is 256K. More storage
can be allocated (up to 1 gigabyte) by specifying the size on the TRACE command in place of the ON
operand. For example, to allocate one megabyte for the trace data, enter:
TRACE CT,1M,COMP=rodmname
The size of the trace area cannot be altered when the trace has been started. You must stop and restart
the trace in order to change the size of the trace area.
After issuing the TRACE command to start the RODM internal trace, MVS will issue a write-to-operator
with reply (WTOR) message ITT006A to solicit trace parameters:
*nn ITT006A SPECIFY OPERAND(S) FOR TRACE CT COMMAND.
Where: nn is the WTOR number to use when replying to the message.

Use the OPTIONS operand to designate which of several RODM trace events are to be recorded. The
events and their codes are:
Code
Event
CC
Console communications (commands received from the console and messages issued to the console)
CF
RODM module flow
ALL
All implemented trace events
For example, if all trace events are to be enabled, enter:
R nn,OPTIONS=(ALL),END
Note: The CF trace option has a severe performance impact on RODM and RODM applications. Avoid
activating a CF trace on a production RODM unless necessary for problem diagnosis.
To deactivate the RODM internal trace, use the TRACE command with the OFF operand:
TRACE CT,OFF,COMP=rodmname
When the trace is stopped, all recorded trace data is discarded. The trace is automatically stopped when
RODM ends.
The trace dataspace (EKGTRDSP) is automatically included in any memory dumps which are taken by
RODM, providing the trace is active at the time of the memory dump.
If the MVS DUMP command is used to dump RODM and the trace data is required, you must include the
name of the trace dataspace in the list of dataspaces to be dumped. You can spool the trace data to a
data set.

MVS TRACE command MVS library
Spooling component trace data MVS library
Dumping RODM dataspaces “Dumping dataspaces allocated by RODM” on page
302
Dumping dataspaces allocated by RODM

Use the following steps if you must dump the dataspaces allocated by RODM:
1. Use the MVS DISPLAY command to determine the names of the dataspaces to be dumped.
The listing from the MVS DISPLAY command shows the dataspace name in the DSPNAME field. The
dataspace name always begins with 00000RDM and is incremented by one when RODM allocates a
new dataspace, for example: 00000RDM, 00001RDM
If the RODM internal trace is active, the trace dataspace (EKGTRDSP) is also in the dataspace list.
2. Use the names of the dataspaces with the MVS DUMP command to take a memory dump of the
dataspaces in use by RODM.

Using the MVS DISPLAY and DUMP commands MVS library
RODM memory dump utility

The RODM memory dump utility is a service program that enables you to print data that resides in the
RODM data cache. The memory dump utility provides multiple formats for printing this information.

You can use the RODM dump utility to generate five types of reports to print the contents and structure of
classes and objects. The reports include the following items:
• Class listing
• Class index
• Object listing
• Object index
• Statistical report
The contents of the output depend on the input parameters. The input parameters follow the SYSIN DD *
control statement. You can provide the SYSIN DD statement as instream values or in a data set.
If you provide a class name, the reports begin at the requested class. Otherwise, the reports begin at the
highest class level, which is the universal class. If you enter an object name, only the object and class are
printed. It is implied that the requested object belongs to the requested class. If the requested object
does not belong to the requested class, an error is indicated.
If you do not enter an object name, the utility prints all objects and classes subordinate to the requested
or default class. The statistical report is generated to show the types and numbers of user API queries
issued against RODM when running the memory dump utility.
If you do not specify a particular RODM entity, the system default is to output the information of all RODM
classes and their associated fields.
Starting the memory dump utility

You start the memory dump utility using a submit JCL, EKGRDUMP, that starts EKGDUMP. Figure 66 on
page 303 is an example of instream JCL for generating a Charts report.
//EKGRDUMP JOB 'DUMP UTILITY',CLASS=A,

// MSGCLASS=A,MSGLEVEL=(1,1),REGION=2048K
//STEP1 EXEC PGM=EKGDUMP
//STEPLIB DD DSN=NETVIEW.V6R3M0.CNMLINK,DISP=SHR
//SYSIN DD *
RODM(rodmname)
CLASS(classid)
APPLID(applid)
PASSWORD(password)
REPORT(yes/no)
//CLASSES DD SYSOUT=*
//CLASSNDX DD SYSOUT=*
//OBJECTS DD SYSOUT=*
//OBJECNDX DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSDUMP DD SYSOUT=*
//
Figure 66. Example of Instream JCL for Generating a Charts Report.
EKGDUMP is the compiled and link-edited memory dump utility program. The STEPLIB data set contains
the load modules of the RODM memory dump utility and the EKGUAPI module. The SYSIN data set
contains the control statement input.
The CLASSES, CLASSNDX, OBJECTS, and OBJECNDX data sets are the reports produced by the utility.
These data sets contain the DCB operands of LRECL=133 and RECFM=FBA. BLKSIZE can be provided on
the DD statements or in the SYSOUT data sets and is handled by JES.
The SYSPRINT data set contains a statistical report indicating the number and type of user API calls made
while the memory dump utility is running. This data set contains the DCB operands of LRECL=80 and
RECFM=FBA.
When you have the required data sets, do the following actions:
• Specify your input parameters under the SYSIN DD * in the JCL.
• Specify the output report files.
• Specify your message output file under the SYSPRINT DD name in the JCL.
– If you do not specify this DD name, the messages are written to the JES log in your MVS system.
– If you use a SYSOUT file under this DD name, the SYSOUT file is kept in the held output queue in the
MVS system where RODM is active.
Coding the control parameters

This section contains information for coding the control parameters for the memory dump utility. You can
code the SYSIN DD as instream values or as a data set.
You can also use the following formats to enter control parameters:
• PARAMETER(value)
• PARAMETER=value
The control parameters are:
RODM=rodmname
Indicates the name of the RODM. This is a required parameter.
If you code a name greater than 8 characters, an error results and the memory dump utility ends.
APPLID=applid
Indicates the application ID the utility assumes when connecting to RODM. This parameter is required
if the system on which RODM is running has no security system installed, and optional if the system
has a security system installed.
If you code an application ID greater than 8 characters, an error results and the memory dump utility
ends.
PASSWORD=password
Indicates the password the utility must use to gain access to the RODM. This parameter is optional
unless you specified the APPLID parameter.
CLASS=classname
Indicates the starting class for the utility.
Note:
1. If you do not specify this parameter, the memory dump utility starts at the UniversalClass.
classname is limited to 1 line. CLASS is an optional parameter.
2. You can specify only one classname each time you run the memory dump utility.
OBJECT=objectname
Indicates that only the specified object is to be printed.
If the requested object is not part of the indicated class, or if you do not specify CLASS, you receive an
error. objectname is limited to 1 line.
REPORT=YES|NO
Indicates whether to print the individual reports written to the CLASSES, CLASSNDX, OBJECTS, and
OBJECNDX output files.
REPORT=NO suppresses the printing of the reports. However, the statistical summary is generated.
REPORT=YES is the default and generates only the statistical summary.
Usage : You can enter control parameters in any of the following formats:
• PARAMETER=value PARAMETER(value) PARAMETER value
• Blanks, equal signs, and parentheses are delimiters. The first non-delimiter is the parameter and the
next non-delimiter after the parameter is the value. Anything after the delimiter ending the value is
ignored.

• Each of the control parameters is intended to be entered one time. If you enter any parameter more
than once, the last occurrence is used.
Figure 67 on page 305 is an example of writing the control parameters in a SYSIN data set. Comments
can be added between /* and */.
/* control file example */
RODMNAME=RODM1
APPLID=USER1
PASSWORD=USERPW
CLASS=CLASS1
OBJECT=OBJ
REPORT=NO
Figure 67. Coding Control Parameters in a SYSIN Data Set
Class listing report

The Class Listing report provides information about the fields and subfields in classes. Figure 68 on page
305 is the expected output from the RODM dump utility when you request a Class Listing report:
YYDDD CLASS LISTING PAGE 1

HH:MM:SS
00000001 UNIVERSAL CLASS (class name)
FIELD NAME: 0011D4A8 D7998994 8199A8D7 81998595 A3C9C4
* ..MYPRIMARYPARENTID *
FIELD ID: 00000001
FLAGS: 0000
INHERITANCE STATE: 0001 SUBFIELD MAP: C0000000 LOCAL COPY MAP: C0000000
VALUE: 0001 00000000
QUERY: 000D 00010003 BC221196 0000
* .......O.. *
PREV_VALUE
NOTIFY: 0019 00000000
* .... *
TIMESTAMP: 001B 4BBC2F18 9EA29000 (15:31:48.393)
FIELD NAME: 0013D4A8 D7998994 8199A8D7 81998595 A3D58194 85
* ..MYPRIMARYPARENTNAME *
FIELD ID: 00000002
FLAGS: 0000
Figure 68. Class Listing Report
Following each of the subfield types is a 2-byte value. This value specifies the data type in a hexadecimal
format. To determine the data type, convert the hexadecimal value to decimal.
Following are descriptions of the fields in the Class Listing report:
YYDDD
Specifies the year and the day of the year, where YY is the last two digits of the year and DDD is a
count of the number of days past.
HH:MM:SS
Specifies the time the report was generated, where:
HH
Specifies the hour
MM
Specifies minutes
SS
Specifies seconds
CLASS ID
Specifies the class identification number.
CLASS NAME
Specifies the class name (for example, UniversalClass).
FIELD NAME
Specifies the name of the field. This user-supplied name is provided in the name field for create name.
FIELD ID
Specifies the field identifier. The ID is assigned by RODM and returned in the response block on a
create field (X'1304').
FLAGS
Specifies a 2-byte Smallint to indicate whether the field is public or private and whether locally
defined or inherited. Only the first two high-order bits are used. The remaining 14 bits are reserved.
The first bit is the private/public flag and indicates the following information:
Bit Value
Meaning
0
Specifies that the field is public
1
Specifies that the field is private
The second bit is the local/inherited flag and indicates the following information:
Bit Value
Meaning
0
Specifies that the field is locally defined
1
Specifies that the field is inherited
INHERITANCE STATE
Specifies a 2-byte field to indicate whether a value is defined locally or inherited from a parent class.
The only valid value is X'0001', indicating that the field is inherited from a parent class.
SUBFIELD MAP
Specifies a bitmap of subfields that are created for this field. Valid values for the bitmap are as
follows:
Bit
Meaning
0
Specifies the value subfield
1
Specifies the query subfield
2
Specifies the change subfield
3
Specifies the notification subfield
4
Specifies the previous value subfield
5
Specifies the TimeStamp subfield
6-31
Not used
Only the first 6 bits of the subfield map are used.
LOCAL COPY MAP
Specifies a bitmap that indicates which of the subfields in the SUBFIELD bitmap have been locally
defined and which have not.
RODM sets a local copy map bit in an output block to 1. This indicates that the corresponding subfield
contains locally defined data.

Bits that do not have a value of 0 indicate subfields that have values or contents inherited from a
parent class.
Valid values for the bitmap are:
Bit
Meaning
0
Specifies the value subfield
1
Specifies the query subfield
2
Specifies the change subfield
3
Specifies the notification subfield
4
Specifies the previous value subfield
5
Specifies the TimeStamp subfield
6-31
Not used
VALUE
A subfield that specifies the actual data associated with the field. The value is defined as RODM
abstract data types such as Integer, CharVar, or Floating.
QUERY
A subfield that specifies a method specification for a query method. This field contains the name of a
method that is started before the field contents are returned to the caller in response to a field query.
PREV_VAL
A subfield that specifies data that, when defined, is a copy of the previous contents of the VALUE
subfield.
CHANGE
A subfield that specifies a method specification for a changed method. The change subfield is a
method that is started to change the contents of a field when requested by a user outside of RODM. If
this subfield has value, changing a field starts a change method.
NOTIFY
A subfield that specifies a method specification for a notification or a list of notifications. This subfield
contains a list of methods and associated parameters. Each method in the list is started after every
change in the value of a field as requested by a user.
TIMESTAMP
A subfield that specifies the local time at which the VALUE subfield was last changed. This field
specifies local time in the following format:
HH:MM:SS.SSS
Where:
HH
Specifies the hour.
MM
Specifies the minutes.
SS.SSS
Specifies the number of seconds followed by decimal fractions of a second.
This field is converted from modified Lilian time by the RODM log formatter.
Decimal values, the corresponding data types, and IBM Z NetView Resource Object Data Manager and
their descriptions GMFHS Programmer's Guide
Class Index report

The Class Index report provides a reference to the class IDs described in the Class Listing report. The
report provides the class ID, the class name, and the Class Listing report page number on which the class
is reported. Figure 69 on page 308 shows the expected output from the RODM dump utility when you
request a Class Index report.
YYDDD CLASS INDEX PAGE 1

HH:MM:SS
(Class ID) (Class name)
00000001 UNIVERSALCLASS 1
00000002 EKG_SYSTEMDATAPARENT 3
00000006 EKG_USER 5
00000005 EKG_SYSTEM 9
00000004 EKG_NOTIFICATIONQUEUE 14
00000003 EKG_METHOD 18
• • •
• • •
• • •
Figure 69. Class Index Report
Following are descriptions of the fields in the Class Index report:

YYDDD
HH:MM:SS
HH
Specifies the hour
MM
Specifies minutes
SS
Specifies seconds
(Class ID)
Specifies the class identification number.
(Class name)
Specifies the class name (for example, UniversalClass).
PAGE
Specifies the Class Listing report page number where this class is described.
Object Listing report

The Object Listing report describes the values in the fields and subfields for objects. Figure 70 on page
309 shows the expected output from the RODM dump utility when you request an Object Listing report.

YYDDD OBJECT LISTING PAGE 1
HH:MM:SS
00020006 F007B9B9 USER1

FIELD NAME: 000CC5D2 C76DD396 87D385A5 8593
* ..EKG_LOGLEVEL *
FIELD ID: 00000021
FLAGS: 4000
INHERITANCE STATE: 0001 SUBFIELD MAP: 80000000 LOCAL COPY MAP: 00000000
VALUE: 000A 00000008
FIELD NAME: 0011D4A8 D7998994 8199A8D7 81998595 A3C9C4
* ..MYPRIMARYPARENTID *
FIELD ID: 00000001
FLAGS: 4000
INHERITANCE STATE: 0001 SUBFIELD MAP: C0000000 LOCAL COPY MAP: 80000000
VALUE: 0001 00000006
QUERY: 000D 00010003 BC221196 0000
* .......O.. *
FIELD NAME: 000AC5D2 C76DE2A3 81A3A4A2
* ..EKG_STATUS *
FIELD ID: 0000000C
FLAGS: 4000
VALUE: 000A 00000001
NOTIFY: 0019 00000000
* .... *
TIMESTAMP: 001B 4BBC2F61 A3580000 (12:47:53.728)
FIELD NAME: 000CC5D2 C76DE2A3 9697D496 8485
* ..EKG_STOPMODE *
FIELD ID: 00000022
FLAGS: 4000
VALUE: 000A 00000001
NOTIFY: 0019 00000000
* .... *
FIELD NAME: 0013D4A8 D7998994 8199A8D7 81998595 A3D58194 85
* ..MYPRIMARYPARENTNAME *
•
•
•
Figure 70. Object Listing Report

Fields in the Object Listing Report “Class listing report” on page 305
Object Index report

The Object Index report provides a reference to the objects described in the Object Listing report. The
report provides the object ID, the object name, and the Object Listing report page number on which the
object is reported. Figure 71 on page 309 shows the expected output from the RODM dump utility when
you request an Object Index report.
YYDDD OBJECT INDEX PAGE 1

HH:MM:SS
(Object ID) (Object Name)
00020006 F007B9B9 USER1 1
00010005 3B5A14D2 EKG_SYSTEM 4
00010003 BC221196 NULLMETH 8
• • •
• • •
• • •
Figure 71. Object Index Report
Following are descriptions of the fields in the Object Index Report:

YYDDD
HH:MM:SS
HH
Specifies the hour
MM
Specifies minutes
SS
Specifies seconds
(Object ID)
Specifies the object identification number.
(Object Name)
Specifies the object name (for example, EKG_SYSTEM).
PAGE
Specifies the Object Listing report page number where this object is described.
Statistical report
The statistical report describes the types and number of user API queries issued against RODM during
execution of the memory dump utility. Figure 72 on page 310 is the expected output from the RODM
memory dump utility each time you request a report:
YYDDD API CALLS

HH:MM:SS
CONNECT................................1
DISCONNECT.............................1
QUERY FIELD...........................22
QUERY SUBFIELD.......................222
QUERY STRUCTURE OF AN ENTITY...........9
QUERY STRUCTURE OF A FIELD...........113
NUMBER OF CLASSES PROCESSED............6
NUMBER OF OBJECTS PROCESSED............3
Figure 72. Statistical Report
Following are descriptions of the fields in the Statistical Report:

YYDDD
HH:MM:SS
HH
Specifies the hour
MM
Specifies minutes
SS
Specifies seconds
CONNECT
Specifies the number of times the user connected to RODM.
DISCONNECT
Specifies the number of times the user disconnected from RODM.
QUERY FIELD
Specifies the number of times a field has been queried.
QUERY SUBFIELD
Specifies the number of times a subfield has been queried.
QUERY STRUCTURE OF AN ENTITY
Specifies the number of times a structure of an entity was queried.
QUERY STRUCTURE OF A FIELD
Specifies the number of times a structure of a field was queried.

NUMBER OF CLASSES PROCESSED
Specifies the number of classes processed.
NUMBER OF OBJECTS PROCESSED
Specifies the number of objects processed.
Informational messages for the RODM memory dump utility

EKGDP001 REQUIRED PARAMETER APPLID MISSING
The APPLID parameter is required to connect to RODM. APPLID is entered as a parameter after the SYSIN
DD * statement.
This message is issued from module EKGDP000.
EKGDP002 REQUIRED PARAMETER PASSWORD MISSING
If you are using RACF, you need to use the PASSWORD parameter with the APPLID.
EKGDP003 REQUIRED PARAMETER RODM MISSING
The rodmname parameter is required to specify the particular RODM from which the data cache is to be
dumped.
EKGDP004 UNRECOGNIZED INPUT RECORD
Check the input specified after the SYSIN DD * statement for parameters or values that are not valid.
EKGDP006 ERROR ON CONNECT TO RODM
An error was detected by RODM on the connect request from the memory dump utility. This message is
followed by message EKGDP009 which reflects the return and reason codes from RODM.
EKGDP007 DISCONNECT FROM RODM FAILED
An error was detected by RODM on the disconnect request from the memory dump utility. This message
is followed by message EKGDP009 which reflects the return and reason codes from RODM.
EKGDP008 REQUIRED MODULE NOT AVAILABLE
The memory dump utility attempted to dynamically load another memory dump utility module and the
load failed. Verify that the module is available in the LOADLIB that you specified in the STEPLIB of the
start JCL and that the name of the module has not been changed.
EKGDP009 RETURN/REASON CODE
This message supplies return and reason codes from RODM to further identify an error when running the
memory dump utility.
This message is issued from module EKGDP000, EKGDP110, or EKGDP120.
EKGDP010 REQUESTED CLASS NOT AVAILABLE
The memory dump utility attempted to find, through a RODM API request, a class that was specified on
the input parameter. Message EKGDP009 follows this message with the return and reason codes from
RODM.
EKGDP111 REQUESTED OBJECT NOT AVAILABLE
The memory dump utility attempted to find, through a RODM API request, an object you specified on the
input parameter. EKGDP009 follows this message with the return and reason codes from RODM.
EKGDP112 QUERY STRUCTURE OF AN ENTITY FAILED
The memory dump utility attempted a RODM API Query Structure of Entity request and failed. Message
EKGDP009 follows this message with the return and reason codes from RODM.
EKGDP113 QUERY FIELD FOR CLASS CHILDREN FAILED
The memory dump utility attempted a RODM API Query Field for Class Children request and failed.
EKGDP114 QUERY FIELD FOR OBJECT CHILDREN FAILED
The memory dump utility attempted a RODM API Query Field for Object Children request and failed.
Message EKGDP009 follows this message with the return and reason codes from RODM.
EKGDP215 QUERY FIELD FOR NAME OF ENTITY FAILED
The memory dump utility attempted a RODM API Query Field for Name of Entity request and failed.
Message EKGDP009 follows this message with the return and reason codes from RODM.
EKGDP216 QUERY STRUCTURE OF A FIELD FAILED
The memory dump utility attempted a RODM API Query Structure of a Field request and failed. Message
EKGDP217 QUERY SUBFIELD FAILED
The memory dump utility attempted a RODM API Query Subfield request and failed. Message EKGDP009
follows this message with the return and reason codes from RODM.

RODM return codes and reason codes IBM Z NetView Resource Object Data Manager and
RODM load function error listing

The data set that contains the error list is identified by the EKGPRINT DD statement in the JCL that starts
the RODM load function. This is a list of the errors the load function detected when it ran.
The error list contains the following information:
• The name of the utility and its current level.
• The date and time the utility was run.
• A list of the options used on the invocation.
• Messages that indicate informational, warning, or error conditions detected by the load function.
• The syntax entered. The LISTLEVEL parameter specifies whether the list contains all lines that were
entered, or just those lines that are in error, as follows:
– If LISTLEVEL=ALLSYNTAX, all syntax is shown.

– If LISTLEVEL=ERRORSYNTAX, only syntax in error is shown.
• Additional messages, including the following messages:
– Messages indicating the success or failure of each primitive processed.
– Error messages interleaved with the syntax, indicating that there is a syntax error.
– An END OF JOB message and overall return code, indicating the success of processing.
Online help is available for each message through the NetView program.
Figure 73 on page 313 shows a sample error listing.
RODM LOAD FUNCTION LEVEL NetView V6R3 05/06/19 10:47:15

OPTIONS USED
------------
OPERATION:LOAD
NAME:RODMA
SEVERITY:WARNING
LISTLEVEL:ALLSYNTAX
CODEPAGE:EKGCP500
LOAD:STRUCTURE
ROUTECODE:1
STRUCTURE ELEMENTS PROCESSED
----------------------------
EKG8568W - METHOD EKGNOTF WAS NOT INSTALLED AS IT ALREADY EXISTS.
OP SUPERCLASS_2 HAS_PARENT UNIVERSALCLASS;
EKG8258I - RODM LOAD FUNCTION PRIMITIVE HAS_PARENT EXECUTED SUCCESSFULLY.
OP SUPERCLASS_2 HAS_FIELD (CHARVAR) FIELD_CHARVAR;
EKG8258I - RODM LOAD FUNCTION PRIMITIVE HAS_FIELD EXECUTED SUCCESSFULLY.
OP SUPERCLASS_2..FIELD_CHARVAR HAS_s.VALUE (CHARVAR) 'xyz';
EKG8258I - RODM LOAD FUNCTION PRIMITIVE HAS_VALUE EXECUTED SUCCESSFULLY.
OP SUPERCLASS_2..FIELD_CHARVAR HAS_VALUE (CHARVAR) X'ABCD';
EKG8253E - RODM LOAD FUNCTION PRIMITIVE HAS_VALUE CONTAINS SYNTAX ERROR(s).
EKG8253E - SEE ASSOCIATED MESSAGES FOR DETAILS.
EKG8256W - VALUE X'ABCD' IS NOT VALID FOR DATA TYPE CHARVAR.
OP !!!CLASS_1 HAS_PARENT SUPERCLASS;
EKG8253E - RODM LOAD FUNCTION PRIMITIVE HAS_PARENT CONTAINS SYNTAX ERROR(s).
EKG8253E - SEE ASSOCIATED MESSAGES FOR DETAILS.
EKG8254W - !!!CLASS_ IS NOT VALID FOR A TOKEN OF TYPE CLASS NAME.
EKG8356E - CLOSE FAILURE ON DATASET EKGIN1.
END OF JOB OVERALL RETURN CODE: 08 10:50:11
Figure 73. Sample RODM Load Function Error Listing

The syntax and delimiters displayed in Figure 73 on IBM Z NetView Resource Object Data Manager and
page 313 GMFHS Programmer's Guide
Part 6. Diagnosing SNA Topology Manager problems

Chapter 20. SNA Topology Manager problem
worksheet
This section contains information that you can use in determining the cause of failures within the SNA
topology manager.
easier to report problems and find solutions. Some SNA topology manager problems can be caused by
communications problems. Use the diagnosis procedures described in the VTAM library to gather
information about problems with VTAM CMIP services.
alteration.
General information
1. Date:
2. Problem Number:
3. Component ID:
6. NetView function modifier ID (FMID):
Installation exits and command lists

1. Are you running any installation exits with the NetView program? If so, which ones?
2. Can you remove or bypass the exit and create the problem again?
environment?
4. Can you bypass the user-written code and successfully run the function you are attempting?
Problem description

• Other:
Problem information
Gather the following documentation before contacting IBM Software Support. Use the diagnosis
procedures described in the z/OS Communications Server SNA Diagnosis manuals to gather information
about problems with VTAM CMIP services. For information about VTAM CMIP services, see the z/OS
Communications Server CMIP Services and Topology Agent Guide.
commands. See Chapter 6, “Diagnostic tools for the NetView program,” on page 75.
• A copy of the system log.
• A copy of the NetView HLL remote interactive debugger (RID) trace logs. See the IBM Z NetView
Programming: PL/I and C for more information about using RID.
• A completed SNA topology manager problem worksheet.
• The RODM START job control language.
• The customization file used to start RODM.
• The GMFHS data model and resource definition files. Refer to the IBM Z NetView Resource Object Data
Manager and GMFHS Programmer's Guide for information about the definitions and their associated
files.
• The SNA topology manager data model and resource definition files. Refer to the IBM Z NetView SNA
Topology Manager Implementation Guide for information about the definitions and their associated files.
• The customization file used to start the SNA topology manager.
• The IHSERROR.LOG and IHSERROR.BAK files. See Chapter 13, “Diagnostic tools for NetView
Management Console and GMFHS,” on page 215.
• The application trace log.
• RODM log records. See Chapter 19, “Diagnostic tools for the Resource Object Data Manager (RODM),”
on page 261 on how to capture this data.
• A memory dump of the RODM dataspaces. See Chapter 19, “Diagnostic tools for the Resource Object
Data Manager (RODM),” on page 261 for information about capturing this data.
• The GMFHS output log and trace print data set. See Chapter 12, “Troubleshooting and initial diagnosis
for NetView management console and GMFHS,” on page 183.
• Copy of any trace information created using the TOPOSNA TRACE command. See “SNA topology
manager traces” on page 415 for more information about the trace information provided by the SNA
topology manager.
For many SNA topology manager problems, especially problems related to incorrect output, gathering
NetView management console, GMFHS, and RODM information helps in locating and resolving problems.
Some of this information is already listed on this worksheet. You might want to fill out the problem
worksheets for these components and provide the information requested by the worksheets.

Check one of the following appropriate problem categories that matches the symptoms associated with
your problem.
Abend problems
For abends or processor exception problems, complete the following questions:
3. The user abend codes are described in the online help facility (type HELP ABEND and use the scroll
function to locate the abend code). The system abend codes are documented in the IBM z/OS library.
b. In which module did the abend occur? See “SNA Topology Manager” on page 15.
c. When was the module compiled?
Message problems
For message problems, complete the following items:
• Message ID:
• Commands:
• NetView management console commands:
• Other:
• What occurred?
Loop problems
For loop problems, complete the following questions:
Chapter 20. SNA Topology Manager problem worksheet 319

4. If this is an enabled loop, collect the information discussed in “Documenting LOOP problems” on page
35.
• After obtaining a console memory dump, close the NetView program with a dump (use the NetView
CLOSE DUMP command).
Note: If the loop is still occurring after the NetView program has been canceled, this is not an SNA
topology manager problem.
5. If this is a disabled loop, collect the information discussed in “Documenting LOOP problems” on page
35.
• A scenario describing the events leading to the problem.
• A memory dump obtained by using the processor RESTART function.
Wait problems
For wait problems, complete the following questions:
• A copy of your VTAM resource definitions. Refer to the z/OS Communications Server SNA Resource
Definition Reference for information about where these definitions are located.

For incorrect output problems, complete the following questions:
Definition Reference for information about the location of these definitions.
• Copies of the agent node configurations.
• Copies of the agent node topology data.
• Copies of related views from the NetView management console workstation.

For performance problems, complete the following questions:
Definition Reference for information about the location of these definitions.
• Copies of the agent node configurations.
• Copies of the agent node topology data.
• Descriptions of any modifications to your system.
For documentation problems, complete the following items:
panel involved.
name.
4. If the problem affects the operation or use of the SNA topology manager, call IBM Software Support
Chapter 20. SNA Topology Manager problem worksheet 321

the SNA Topology Manager
Use Table 137 on page 323 to locate examples of problems you might encounter when using the SNA
topology manager. To use the table:
problem.
If you are unable to solve your problem by using the examples in this chapter, refer to the examples in the
following documents:
• For the NetView program, some examples are described in Chapter 5, “Troubleshooting and initial
diagnosis for the NetView program,” on page 51.
• For the Graphic Monitor Facility host subsystem (GMFHS), some examples are described in Chapter 12,
“Troubleshooting and initial diagnosis for NetView management console and GMFHS,” on page 183.
• For the Resource Object Data Manager (RODM), some examples are described in Chapter 18,
“Troubleshooting and initial diagnosis for RODM,” on page 245.
For additional reference information about topology manager, see the IBM Z NetView SNA Topology
Manager Implementation Guide.
If you are still unable to solve your problem by using the references previously listed, follow the
instructions in Chapter 2, “Classifying problems,” on page 13 and Chapter 3, “Documenting and reporting
problems,” on page 23 before contacting IBM Software Support.
Table 137. SNA Topology Manager Problem Scenarios

Abend FLBTOPO task abends (message DSI819I). “FLBTOPO task abends” on page
331
Hang Topology manager seems to be suspended (message “Topology Manager seems to be
FLB486I). suspended” on page 335
Initialization Cannot connect to RODM (messages FLB482E, “Cannot connect to RODM” on
FLB483W, and FLB485E). page 329
Cannot connect to VTAM CMIP services (message “Cannot connect to VTAM CMIP
FLB677E or FLB678E). services” on page 328
Error reading or processing customization table “Error reading customization
FLBOSIDS, FLBSRT, or FLBEXV. table FLBOSIDS, FLBSRT, or
FLBEXV” on page 327
Topology manager reinitializes unexpectedly. “Topology Manager reinitializes
unexpectedly” on page 335

Table 137. SNA Topology Manager Problem Scenarios (continued)
Error reading or processing initialization file FLBSYSD. “Error reading initialization file
FLBSYSD” on page 326
Not enough storage (message FLB480E). “Insufficient storage for Topology
Manager initialization” on page
326
Wrong autotask (message FLB446E). “Wrong autotask error” on page
326
Monitor Automatic monitoring does not work. “Automatic Monitoring is failing”
on page 336
Cannot obtain topology data from agent node. “SNA Topology Manager cannot
receive Agent Node Topology
Data” on page 337
Monitor operation stops. “Topology Manager or VTAM
CMIP Services was ended by an
operator” on page 345
Monitor operation unexpectedly stops (message “Monitor Operation unexpectedly
FLB404I, FLB405W, FLB408W, FLB421I, FLB422W, or ends” on page 342
FLB425W).
Resources are not shown in the views. “Resources are not shown in the
Views” on page 340
RODM object is missing some attribute values “RODM Object missing some
(attributes missing or log entry 78-25 is created). attribute values” on page 339
Purge Objects are not purged. “Objects are not purged” on page
347
Objects are unexpectedly purged. “Objects unexpectedly purged”
on page 350
Cannot activate, deactivate, or recycle a resource. “Cannot activate, deactivate, or
recycle a resource” on page 347
Locate resource with Discover SNA LU checked does “A Locate Resource request does
not find resource. not find the resource” on page
346
Shutdown Topology manager unexpectedly shuts down “Topology Manager unexpectedly
(message FLB442E). shuts down” on page 333
Status Aggregate resource status is incorrect or not being “Aggregate resource status
updated. incorrect or not being updated”
on page 361
Blank status history for a topology manager resource. “Blank status history for a
Topology Manager resource” on
page 346
Resource has unknown status. “The resource status is unknown”
on page 354
Resource status is incorrect or not being updated. “Resource status incorrect or not
being updated” on page 357

Table 137. SNA Topology Manager Problem Scenarios (continued)
Views Class of node object does not match actual node type. “Class of Node Object does not
match node type” on page 367
Exception view resource displays are incorrect. “Exception view resource
displays are incorrect” on page
372
Subnetworks are shown in the same “Subnetworks shown in the same
nnDomainNetwork view. nnDomainNetwork view” on page
366
Unexpected resources are displayed in views. “Unexpected resources are
displayed” on page 368
Views of topology manager objects no longer display. “View of Topology Objects is not
available for display” on page 362
Problems during initialization

This section contains descriptions and resolution steps for problems that might occur during SNA
topology manager initialization. The following are reasons for initialization failure:
Table 138. Topology Manager Problems

Initialization Problem Page
Wrong autotask error “Wrong
autotask error”
on page 326
Not enough storage “Insufficient
storage for
Topology
Manager
initialization”
on page 326
Error reading initialization file FLBSYSD “Error reading
initialization file
FLBSYSD” on
page 326
Error reading customization table FLBOSIDS, FLBSRT, or FLBEXV “Error reading
customization
table
FLBOSIDS,
FLBSRT, or
FLBEXV” on
page 327
Cannot connect to VTAM CMIP services “Cannot
connect to
VTAM CMIP
services” on
page 328
Chapter 21. Troubleshooting and initial diagnosis for the SNA Topology Manager 325
Table 138. Topology Manager Problems (continued)
Initialization Problem Page
Cannot connect to RODM “Cannot
connect to
RODM” on page
329
Wrong autotask error

If the topology manager autotask is not started using the FLBTOPO task name, the following message is
sent to the operator that started the FLBTOPO task:
FLB446E SNA TOPOLOGY MANAGER CANNOT BE EXECUTED UNDER TASK taskname
To solve the problem, correct the autotask start-up procedure, or if initializing the autotask from the
command line, re-specify the commands using the required name of FLBTOPO.
Insufficient storage for Topology Manager initialization

If the topology manager cannot obtain enough storage to connect to RODM during initialization, the SNA
topology manager shuts down, and the following message is sent to the operator that started the
FLBTOPO task:
FLB480E SNA TOPOLOGY MANAGER FAILED TO CONNECT TO RODM rodmname

BECAUSE OF A LACK OF STORAGE
Followed by the messages:
FLB442E SNA TOPOLOGY MANAGER IS SHUTTING DOWN BECAUSE OF AN ERROR

FLB443I SNA TOPOLOGY MANAGER SHUTDOWN IS COMPLETE
To solve the problem, do the following steps:

1. Use the NetView online help facility for this message and correct the problem.
2. Restart the FLBTOPO task.
Error reading initialization file FLBSYSD

If an error occurs when reading or processing the FLBSYSD initialization file, one of the following
messages is issued:
FLB413E SNA TOPOLOGY MANAGER CANNOT PROCESS OR

READ INITIALIZATION MEMBER 'FLBSYSD'
FLB416E SNA TOPOLOGY MANAGER INITIALIZATION FILE CONTAINS A KEYWORD

'keyword' WITH A NULL VALUE
FLB417E SNA TOPOLOGY MANAGER INITIALIZATION FILE CONTAINS KEYWORDS

'keyword1' AND 'keyword2'
WITH PREFIX VALUES THAT ARE EQUAL
FLB427E SNA TOPOLOGY MANAGER INITIALIZATION FILE CONTAINS A KEYWORD

'keyword' WITH AN INCORRECT VALUE
Followed by messages:

If a keyword is missing, a log entry is created with a major code of 78 and a minor code of 36. A common
reason for this is that FLBSYSD is down-level and therefore can be missing new required keywords.

1. Use the NetView online help facility for the message or the help for the log entry to determine how to
correct the initialization file error.
2. Correct the initialization file error.
3. Restart the SNA topology manager autotask.
Error reading customization table FLBOSIDS, FLBSRT, or FLBEXV

There are two types of errors: severe and warning. The SNA topology manager ends with a severe error,
but continues initialization with a warning error.
Type of Error Page

Severe error “Severe Error: Topology Manager
ends” on page 327
Warning error “Warning Error: Topology
Manager initialization completes”
on page 327
Severe Error: Topology Manager ends

If an error occurs when attempting to read the customization table, one of the following messages is
issued:
FLB681E SNA TOPOLOGY MANAGER ENCOUNTERED AN ERROR 'code'

READING A RECORD FROM CUSTOMIZATION TABLE table
FLB682E SNA TOPOLOGY MANAGER ENCOUNTERED AN ERROR 'code'

ATTEMPTING TO OPEN CUSTOMIZATION TABLE table
Followed by messages:


1. Use the NetView online help facility for the message to find information about what to correct in the
customization table.
2. Correct the customization table error.
3. Restart the SNA topology manager autotask.
Warning Error: Topology Manager initialization completes

If a syntax error, keyword, or data error is discovered when processing customization tables, warning
messages are issued but SNA topology manager completes initialization.
One or more of the following messages are issued:
FLB660W SNA TOPOLOGY MANAGER ENCOUNTERED AN INCLUDE ERROR

'code' IN CUSTOMIZATION TABLE table
WITH ENTRY 'record'
FLB661W SNA TOPOLOGY MANAGER CUSTOMIZATION TABLE membername

CONTAINS A KEYWORD 'keyword' WITH A NULL VALUE

CONTAINS A KEYWORD 'keyword' WITH AN INCORRECT
VALUE 'value'

CONTAINS THE KEYWORD 'keyword' MULTIPLE
TIMES WITH THE SAME VALUE 'value'
FOR OBJECT CLASS class

CONTAINS A SYNTAX ERROR, DATA 'entry'
CONTAINS AN INVALID KEYWORD 'keyword'

DOES NOT CONTAIN ALL REQUIRED OBJECT CLASSES

DOES NOT SPECIFY A DEFAULT SET OF OSI/DISPLAY STATUS MAPPINGS FOR
OBJECT CLASS class
FLB668W AN OSI STATUS OF 'status' WAS RECEIVED FOR

RESOURCE resource CLASS class BUT WAS NOT
FOUND IN THE CUSTOMIZATION TABLE membername
(statesIn-statesOut)

DOES NOT SPECIFY A DEFAULT STATUS HIERARCHY FOR OBJECT CLASS
class

DOES NOT SPECIFY A DEFAULT EXCEPTION VIEW NAME FOR OBJECT
CLASS class
FLB679W SNA TOPOLOGY MANAGER CUSTOMIZATION TABLE table

SPECIFIES EXVWNAME name WHICH WAS NOT FOUND IN RODM

SPECIFIES EXVWNAME name WHICH CONTAINS AN INVALID
VALUE IN RODM FOR FIELD ExceptionViewName
'viewname:'

1. Use the NetView online help facility for the message to find information about what to correct in the
customization table.
2. Correct the customization table.
3. Issue the TOPOSNA REFRESH command to re-create the customization table without terminating SNA
topology manager.
For information about the command and the correct syntax, refer to the NetView online help facility.
Cannot connect to VTAM CMIP services

The SNA topology manager must be able to use VTAM CMIP services to exchange messages with its
agents in the network. The SNA topology manager attempts to establish a connection with VTAM CMIP
services during initialization. VTAM CMIP services connection retry attempts are according to the
CMIP_RETRY_INTERVAL and the CMIP_RETRY_LIMIT keyword values set in the FLBSYSD initialization
file. When initialized, the SNA topology manager uses the TOPOSNA SETDEFS,CMPRETRY values for retry
attempts when VTAM CMIP services end.
If CMIP_RETRY_INTERVAL is set to zero (0) or NORETRY, the following messages are logged when the
VTAM CMIP services are not active:
FLB678E SNA TOPOLOGY MANAGER FAILED TO CONNECT TO CMIP SERVICES,

CMIP SERVICES IS NOT ACTIVE
The following messages are logged when the VTAM CMIP services are active, but the attempt to connect
fails:
FLB677E SNA TOPOLOGY MANAGER FAILED TO CONNECT TO CMIP SERVICES retcode retflag
Where: retcode = The return code from a call to MIBConnect

retflag = The return flag from a call to MIBConnect

Log entries are also created that provide more information about the exact error.

When message FLB677E is received, do the following steps:
1. Verify that the specifications in the FLBSYSD initialization file match the TOPOMGR VTAM APPL
definition statement.
The FLBSYSD specification for APPLNAME and APPLPASS must match the TOPOMGR VTAM APPL
specifications for ACBNAME and PRTCT, respectively. For example:
TOPOMGR VTAM APPL statement:

TOPOMGR APPL ACBNAME=TOPOMGR,PRTCT=TOPOPASS
FLBSYSD VTAM specifications:

VTAM: APPLNAME="TOPOMGR"
APPLPASS="TOPOPASS"
2. Correct specifications to match (if required).

3. Restart the SNA topology manager.
Refer to the z/OS Communications Server library for more information about diagnosing VTAM CMIP
services problems.
Cannot connect to RODM

The SNA topology manager must be able to use RODM to store the topology information it receives from
the agents in the network. The SNA topology manager attempts to establish a connection with RODM
during initialization.
During initialization, retry attempts are made according to the RODM_RETRY_INTERVAL and the
RODM_RETRY_LIMIT keyword values set in the FLBSYSD initialization file. When initialized, the SNA
topology manager uses the TOPOSNA SETDEFS, RDMRETRY values for retry attempts when RODM ends.
The following messages are logged when the attempt fails:
FLB483W SNA TOPOLOGY MANAGER FAILED TO CONNECT TO RODM

'rodmname' AND WILL RETRY
FLB485E SNA TOPOLOGY MANAGER FAILED ALL RETRIES WHEN CONNECTING TO OR
CALLING RODM 'rodmname'
FLB482E SNA TOPOLOGY MANAGER ENCOUNTERED AN UNRECOVERABLE ERROR ON
A CALL TO RODM 'rodmname'
FLB610I TASK FLBTOPO IS STARTING LOGOFF PROCESSING
FLB611I TASK FLBTOPO HAS COMPLETED ITS LOGOFF PROCESSING
Log entries are also created that provide more detail on the exact error.
1. Verify that RODM is started and is active as follows:
• Use TSO ISPF to check the system log to determine whether RODM was started, successfully.
For example, if RODM was started using the job EKGXRODM and the name RODMNAME, the
following message is issued:
EKG1900I EKGXRODM : RODM RODMNAME INITIALIZATION IS COMPLETE WITH LE/370
• Use TSO ISPF to determine whether the RODM job (address space) is still active. For example, if
RODM was started using the job EKGXRODM and the name RODMNAME, you see the following
message:
NP JOBNAME STEPNAME PROCSTEP JOBID OWNER C POS DP ...

EKGXRODM EKGXRODM START STC00256 !!!!!!!! N/S 21 ...
• Use the MVS D command to verify that RODM is active.

If RODM is active, proceed to step “3” on page 330, if not continue to step 2.
2. Start RODM.
The sample procedure, which is supplied with NetView, that starts RODM is EKGXRODM.
• If you cold-start RODM, proceed to step “3” on page 330 to verify that the SNA topology manager
has authorization to use RODM, and then proceed to step “4” on page 330.
• If you warm-start RODM using a checkpoint data set that does not include GMFHS class definitions,
proceed to step “3” on page 330 to verify that the SNA topology manager has authorization to use
RODM, and then proceed to step “4” on page 330.
• If you warm-start RODM using a checkpoint data set that includes GMFHS class definitions, but not
the SNA topology data model, proceed to step “3” on page 330 to verify that the SNA topology
manager has authorization to use RODM, and then proceed to step “5” on page 330.
• If you warm-start RODM using a checkpoint data set that includes GMFHS class definitions and the
SNA topology data model, proceed to step “3” on page 330 to verify that the SNA topology manager
has authorization to use RODM, and then proceed to step “6” on page 330.
3. Verify that you have authorized the SNA topology manager to use RODM.
If you have a software security system, such as RACF, active on your system you must define the
topology manager user ID APPNTM and authorize that ID to use RODM with an access authority level
of 5.
If the SNA topology manager is not authorized to use RODM, issue the commands necessary to
authorize access to RODM and restart the topology manager.
4. Verify that the GMFHS data model has been loaded into the RODM data cache.
The sample procedure, which is supplied with NetView, that loads the data model is EKGLOADP.
If you cold-started RODM, or warm-started RODM using a checkpoint data set that does not include
GMFHS class definitions, load the GMFHS data model. After loading the GMFHS data model, proceed
to step “5” on page 330 to load the SNA topology data model.
5. Verify that the SNA topology data model has been loaded into the RODM data cache.
• If the entire data model has not been loaded, the SNA topology manager goes into retry and the
following messages are issued:
FLB686I SNA TOPOLOGY MANAGER DATA MODEL IS NOT COMPLETELY LOADED

The SNA topology manager checks for the existence of the Topology_Manager class in the RODM
data cache to determine whether the entire data model has been loaded. This class is defined in
loader file FLBTRDMZ, which is loaded last.
When the entire data model has been loaded, the topology manager continues with its initialization.
• If you started RODM and reloaded the GMFHS data model, you must load the SNA topology data
model.
In addition, if you warm-started RODM using a checkpoint data set that included GMFHS class
definitions, but not the SNA topology data model, load the SNA topology data model.
The sample procedure, which is supplied with the SNA topology manager, that loads the SNA
topology data model is CNMSJH12.
6. Verify that the name of the Network_View_Class object is correct.
This object is created in the RODM data cache by the SNA topology manager loader file FLBTRDMA.
The default name is SuperclusterView. The SNA topology manager uses the name defined by the
SUPER_CLUSTER_VIEW_NAME keyword in the FLBSYSD initialization file to reference this object.
The name in the FLBSYSD file must match the name of the object in the RODM data cache.
If the names do not match, change the names defined in files FLBTRDMA and FLBSYSD so that they
match.

• To use the Network_View_Class object that is already defined in the RODM data cache, verify that
the name used in both files matches this name and proceed to step “7” on page 331.
• If you do not want to use the object that is already defined in the RODM data cache, perform the
following steps:
a. Create the object in the RODM data cache again using the new name.
b. Stop RODM and proceed to step “2” on page 329 to restart RODM and reload the data models.
c. Cold-start RODM to delete the existing Network_View_Class object, or warm-start RODM using a
checkpoint file that does not have a definition for the object.
You can use the RODMView tool to verify that an object of the class Network_View_Class object exists
in the RODM data cache with the name defined in the FLBSYSD file. Defining and customizing these
values is described in the IBM Z NetView SNA Topology Manager Implementation Guide.
7. Restart the SNA topology manager.
FLBTOPO task abends

If the SNA topology manager abends, the following message is issued:
DSI819I NETVIEW IS DUMPING FOR TASK FLBTOPO. COMPLETION CODE= X'hhhhhh',

DOMAIN=domainid
An abend occurred in the SNA topology manager. The NetView program performs an SVC memory dump.
Usually, this indicates a software problem within the SNA topology manager or an interface problem
between the SNA topology manager and another task.
There can be incorrect (or incomplete) objects in the RODM data cache. The SNA topology manager is
dependent on the objects that it references in the RODM data cache and related objects being created
correctly.
Abends Page
Abend during initialization “Abend during
initialization”
on page 331
Abend after initialization “Abend after
initialization”
on page 332
User abend “User abend”
on page 332
Abend error conditions “Abend error
conditions” on
page 332
Abend during initialization

If the FLBTOPO task abend occurred while the SNA topology manager was reading the objects in the
RODM data cache during the SNA topology manager warm-start processing, data in the RODM data cache
can violate the SNA topology data model rules.
These rules and restrictions are described in the IBM Z NetView Data Model Reference.
To determine whether the abend occurred during warm-start processing, check the network log and
determine whether message DSI819I follows message FLB402I, and that message FLB440I is not
logged. The following messages are issued, in the order shown, if the abend occurred while working with
the objects in the RODM data cache:
FLB402I SNA TOPOLOGY MANAGER HAS BEGUN WARM-START PROCESSING
DOMAIN=domainid
Abend after initialization

If the FLBTOPO task abend occurs after the SNA topology manager initializes, the customer-defined SNA
topology manager objects added to the RODM data cache violate the SNA topology data model rules.
These rules and restrictions are described in the IBM Z NetView Data Model Reference.
To determine whether the abend occurred after the SNA topology manager initialized, check the network
log and determine whether message DSI819I follows message FLB440I. The following messages are
issued, in the order shown, if the abend occurred after the SNA topology manager was initialized:
FLB440I SNA TOPOLOGY MANAGER INITIALIZATION IS COMPLETE

DOMAIN=domainid
User abend
For enhanced serviceability of the SNA topology manager, a user abend can be initiated to dump the
FLBTOPO autotask for diagnostic purposes. Whether this user abend is taken depends on the setting of
the ABEND_AND_DUMP parameter in the FLBSYSD initialization file. The default setting is YES.
When the SNA topology manager detects a severe processing error condition, it checks the setting of the
ABEND_AND_DUMP parameter in FLBSYSD:
• If it is set to YES, the following message is issued:
FLB694E SNA TOPOLOGY MANAGER DETECTED A SEVERE ERROR CONDITION,

ABEND X'abendcode' TAKEN FOR FLBTOPO TASK, PROBE probeid
The NetView address space is dumped and the SNA topology manager abends with a user abend. Use
the online help facility (type HELP ABEND and use the scroll function to locate the abend code).
• If set to NO, the following message is issued:
FLB693E SNA TOPOLOGY MANAGER DETECTED A SEVERE ERROR CONDITION,

BUT A STORAGE DUMP WAS NOT REQUESTED, PROBE probeid
ABEND CODE X'abendcode'
The user abend is not initiated; the SNA topology manager initiates shutdown and logoff.
Abend error conditions

Most incorrect object data, such as incorrect attribute values, do not cause the SNA topology manager to
abend. However, if SNA topology manager objects are linked to incorrect objects, or if some of the objects
and links required by an object are not created, the SNA topology manager can abend, depending on the
severity of the problem. These error conditions can be caused by the following conditions:
• The SNA topology manager abended while it was creating an object in the RODM data cache, and the
SNA topology manager was restarted without restarting RODM.
• The SNA topology manager was stopped by an operator issuing a command other than TOPOSNA
STOPMGR, while the SNA topology manager was creating an object in the RODM data cache, and the
SNA topology manager was restarted without restarting RODM.
• An operator took a checkpoint of RODM while the SNA topology manager was creating an object in the
RODM data cache, and the SNA topology manager was warm-started after warm-starting RODM with
the checkpoint data.
• A user created a SNA topology manager object in the RODM data cache without setting the correct links
to other objects or without creating the other required objects.
To solve the problem, do the following

1. Save the memory dump data set and the RODM dataspaces.
2. Try to determine if the cause of the SNA topology manager failure might be incorrect data within the
RODM data cache.
The following procedures can be tried:
• Restart RODM with previous checkpoint data.
Any changes made since the data was captured are lost.
Try to warm-start the SNA topology manager. If the SNA topology manager successfully starts,
restart any required monitor operations that were not automatically started by the SNA topology
manager.
• Try to cold-start the SNA topology manager.
If the SNA topology manager successfully starts, restart any required monitor operations.
Attention: Cold-starting the SNA topology manager purges all data in the RODM data cache
created by the SNA topology manager. If you want to keep this data, checkpoint the existing
data in the RODM data cache before restarting the SNA topology manager.
3. Perform the following actions:
• Cold-start RODM
Attention: Cold-starting RODM purges all data in the RODM data cache. If you want to keep
this data, checkpoint the existing data in the RODM data cache before cold-starting RODM.
• Reload the GMFHS and SNA topology data models
• Restart the SNA topology manager
If the SNA topology manager successfully starts, restart any required monitor operations.
4. If the abend does not occur again, the abend might have been caused by incorrect data stored in the
RODM data cache.
Report the abend to IBM Software Support. Provide the RODM dataspaces when reporting the
problem. Continue by performing all required operations to rebuild your topology information within
the RODM data cache.
Note: The most nondisruptive recovery mechanism is to warm-start RODM with a valid copy of checkpoint
data and then warm-start the SNA topology manager.
When you have verified that the topology data is valid, it is a good idea to archive previous versions of your
checkpoint data sets.
If the SNA topology manager is not processing updates that require the creation or deletion of objects
within the RODM data cache, try to checkpoint the RODM data cache. Updates that only change the status
of an object do not usually cause problems.
Wait until the network is stable (no other resources are being added to, or removed from, the network) or
temporarily stop all monitor operations.
Topology Manager unexpectedly shuts down

When the SNA topology manager detects an unrecoverable error, it begins an orderly shutdown, as if a
TOPOSNA STOPMGR command was issued. It ends all active monitor operations, sets the status of all
SNA topology manager resources to unknown, releases its associations with RODM and VTAM CMIP
services, and frees all resources.
1. Determine the reason the SNA topology manager stopped.
One or more messages or log entries describing the error are placed in the network log. Scan the
network log, searching for SNA topology manager or VTAM CMIP services messages and log entries
directly preceding or following message FLB442E. These messages and log entries describe the error.
• One probable cause is that the SNA topology manager encountered an unrecoverable error while
trying to send or receive data using VTAM CMIP services.
For example, if the VTAM CMIP services tasks unexpectedly end while the SNA topology manager is
active, the following messages are logged:
FLB684E SNA TOPOLOGY MANAGER DISCOVERED THAT CMIP SERVICES IS TERMINATING

In this case, VTAM CMIP services logged a message indicating that it had ended. The SNA topology
manager also ended when it detected that VTAM CMIP services was no longer available. Refer to the
z/OS Communications Server SNA Diagnosis manuals for more information about diagnosing VTAM
CMIP services problems. For information about VTAM CMIP services, see the z/OS Communications
Server CMIP Services and Topology Agent Guide.
• Another probable cause is RODM termination.
When the SNA topology manager discovers that RODM is terminating, the SNA topology manager
task logs the following messages and ends:
FLB481E SNA TOPOLOGY MANAGER DISCOVERED THAT RODM

'rodmname' IS TERMINATING/QUIESCING
Review the NetView and system log. If an operator has ended the RODM task, warm-start the RODM
again and then start the SNA topology manager FLBTOPO task to resume the previous SNA topology
manager state.
• Another probable cause is that the SNA topology manager encountered an unrecoverable error while
referring to data in the RODM data cache.
Usually, the SNA topology manager creates one or more log entries describing the error and logs the
following messages:
FLB482E SNA TOPOLOGY MANAGER ENCOUNTERED AN UNRECOVERABLE ERROR ON

A CALL TO RODM 'rodmname'
Use the information in the associated log entries to diagnose and correct the problem. Log entries
are described in “SNA Topology Manager log record formats” on page 376.
• A fourth probable cause is the SNA topology manager cannot allocate enough storage.
In this case, the SNA topology manager creates a log entry (78-0) indicating the storage allocation
problem:

Use the information in the associated log entries to diagnose and correct the problem. The log
entries are described in “SNA Topology Manager log record formats” on page 376.
If the cause is not one of the above, the information provided in the log entry, along with the
description of the log entries, enables you to determine the cause of the error and provide solutions.
The log entries are described in “SNA Topology Manager log record formats” on page 376.

2. After solving the problem, restart the SNA topology manager.
Topology Manager reinitializes unexpectedly

When the SNA topology manager detects that CMIP Services or RODM have ended, it reinitializes if the
following conditions are true:
• The CMIP Services retry interval value has not been set to zero (0) or NORETRY.
The TOPOSNA SETDEFS,CMPRETRY command sets this value. The value can be queried by issuing the
TOPOSNA QUERYDEF command. The value is then given in message FLB528I.
• The RODM connect retry interval value has not been set to zero (0) or NORETRY
The TOPOSNA SETDEFS,RDMRETRY command sets this value. The value can be queried by issuing the
TOPOSNA QUERYDEF command. The value is then given in message FLB520I.
The SNA topology manager goes through the following steps during reinitialization:
1. Performs termination processing as if the TOPOSNA STOPMGR command had been issued.
2. Initializes again instead of ending. This includes reading all the initialization files again.
3. Attempts to connect to RODM and VTAM CMIP Services. If the retry limits for RODM or CMIP Services
connection are exceeded, the SNA topology manager ends.
The SNA topology manager reinitializes because of RODM termination or CMIP Services termination. One
or more messages or log entries describing the error that caused the reinitialization are recorded in the
network log.
1. Scan the network log, searching for SNA topology manager or VTAM CMIP services messages and log
entries directly preceding or following message FLB300W. These messages and log entries describe
the error.
a. If CMIP services ended, the following message sequence is received:

FLB300W SNA TOPOLOGY MANAGER IS RE-INITIALIZING
FLB678W SNA TOPOLOGY MANAGER FAILED TO CONNECT TO CMIP SERVICES
AND WILL RETRY, CMIP SERVICES INACTIVE
In this case, VTAM CMIP services logged a message indicating that it ended. When the SNA
topology manager detected that VTAM CMIP services were no longer available, it reinitialized and
attempted to connect to VTAM CMIP services. The connect failed and retries began. Refer to the
z/OS Communications Server SNA Diagnosis manuals for more information about diagnosing VTAM
CMIP services problems. For information about VTAM CMIP services, see the z/OS Communications
b. If RODM has ended, the following message sequence is received:
FLB481E SNA TOPOLOGY MANAGER DISCOVERED THAT RODM

'rodmname' IS TERMINATING/QUIESCING
FLB300W SNA TOPOLOGY MANAGER IS RE-INITIALIZING
Use the information in the associated log entries to determine why RODM ended and correct the
problem. The log entries are described in “SNA Topology Manager log record formats” on page 376.
Topology Manager seems to be suspended

The only time the SNA topology manager suspends processing is during a checkpoint of the RODM data
cache. RODM does not process updates while a checkpoint is in progress.
The SNA topology manager, if it detects a checkpoint operation in progress, continues to retry updating
the RODM data cache. It does not process new commands or updates until the checkpoint operation is
complete and it finishes processing the existing update.
The SNA topology manager logs the following message when it begins the wait for the RODM checkpoint
to complete:
FLB486I SNA TOPOLOGY MANAGER CALLED RODM 'rodmname'

DURING A RODM CHECKPOINT AND WILL RETRY

1. Determine whether a RODM checkpoint is in progress.
• If a RODM checkpoint is in progress, wait for it to complete. The SNA topology manager accepts new
commands and updates as soon as RODM resumes accepting updates. If the RODM checkpoint
hangs, the SNA topology manager:
– Does not process any new commands or updates
– Seems to be suspended
Correct the RODM hang condition, and the SNA topology manager resumes processing new
commands and updates. The diagnostic procedures for RODM are described in Chapter 18,
“Troubleshooting and initial diagnosis for RODM,” on page 245.
• If a RODM checkpoint is not in progress, see “Documenting WAIT problems” on page 38.
The SNA topology manager does not process commands, including the TOPOSNA STOPMGR
command, while it is waiting for RODM to complete a checkpoint. RODM checkpoints can take a
significant amount of time, depending on the amount of data in RODM.
2. Determine whether the SNA topology manager is collecting initial topology data for a network, local or
LU collection request.
If the SNA topology manager is collecting initial topology data for a network topology, local topology,
or LU collection (LUCOL) request from a VTAM topology agent, the SNA topology manager might seem
to be suspended.
After one or more of these topology requests, the topology agent sends multiple buffers to the SNA
topology manager. These buffers are queued until the last initial transfer complete signal is sent by the
topology agent. The SNA topology manager starts processing these buffers and creates the objects in
the RODM data cache.
Upon completion, an initial transfer complete message is issued. The time required for completion of
this process depends on the number of objects reported by the agent.
Verify that the SNA topology manager is actively processing topology data by using the TASKUTIL
FLBTOPO command to check the number of messages queued to the FLBTOPO task.
If the number of messages queued is high but changing, it is an indication that the SNA topology
manager is processing data.
If the number of messages queued has not changed for a long time, it is a good indication that the SNA
topology manager is suspended.
The TASKMON command can be used to check all performance statistics for FLBTOPO. The CPU usage
and message queueing statistics might also be indicators of task activity or task suspension
conditions.
Automatic Monitoring is failing

There are several reasons why automatic monitoring might fail.

1. Check the NetView log for following message:
FLB464I SNA TOPOLOGY MANAGER INITIALIZATION FILE CONTAINS A KEYWORD

'SNA_NETID' WITH A NULL VALUE AS FIRST ENTRY
• If message FLB464I has been logged, the automatic topology function is not active because a null
value as the first entry in the SNA_NETID list cancels the automatic collection of topology
information.
• If message FLB464I has not been logged, do the following steps:
a. Verify that the NetID for the node for which automatic topology is expected has been specified in
the SNA_NETID list in the FLBSYSD initialization file.
Refer to the IBM Z NetView SNA Topology Manager Implementation Guide for more information
about the FLBSYSD initialization file.
b. Verify that the TOPOSNA SETDEFS,AUTOMON command was correct.
Refer to the NetView online help facility for information about the command and the correct
syntax.
2. Correct the problem.
3. If the SNA_NETID list in FLBSYSD has been updated, stop and restart the SNA topology manager.
SNA Topology Manager cannot receive Agent Node Topology Data

There are a number of reasons why the SNA topology manager cannot receive topology data from an
agent node. Most of them are related to communications problems or setup problems at the agent node.
Refer to the IBM Z NetView SNA Topology Manager Implementation Guide for a description of a monitor
operation.
The following messages are issued when the SNA topology manager cannot monitor the network or local
topology of a node:
• For network topology:
FLB403I REQUESTED MONITORING OF SNA NETWORK TOPOLOGY FROM

NODE nodename
FLB409W MONITORING OF SNA NETWORK TOPOLOGY FROM NODE nodename WILL
BE RETRIED
FLB685W NO ACTIVE PATH TO NODE nodename OR CMIP SERVICES NOT
ACTIVE ON THIS NODE OR INCORRECT NODE NAME
• For local topology:
FLB420I REQUESTED MONITORING OF SNA LOCAL TOPOLOGY FROM

NODE nodename
FLB426W MONITORING OF SNA LOCAL TOPOLOGY FROM NODE nodename WILL
BE RETRIED
• For LU collection:
FLB540I REQUESTED MONITORING OF LU COLLECTION FROM nodename

FLB544W MONITORING OF THE LU COLLECTION FROM NODE nodename
WILL BE RETRIED
Most of these problems result in associated VTAM CMIP services log entries being created or SNA
topology manager messages being issued. Refer to the z/OS Communications Server SNA Diagnosis
manuals for more information about diagnosing VTAM CMIP services problems. For information about
VTAM CMIP services, see the z/OS Communications Server CMIP Services and Topology Agent Guide.
To solve the problem, take the following actions:
1. Verify that you specified the correct node name when you issued the TOPOSNA MONITOR command.
The SNA topology manager retries monitor operations to unknown nodes. The retry procedures are the
same as those for communication problems.
If the wrong node name was specified, issue a TOPOSNA STOP command for the unknown node, and
issue the TOPOSNA MONITOR command again using a valid node name.
2. Verify that the VTAM topology agent is installed on this node and that the VTAM CMIP services are
active on this node.
Refer to the z/OS Communications Server CMIP Services and Topology Agent Guide for information
about installing the VTAM topology agent.
From VTAM you can enter the following commands:
D NET,VTAMOPS,OPT=OSIMGMT
or
D NET,VTAMOPS,OPTION=OSIMGMT
The expected message is IST1189I, indicating that the OSIMGMT option is YES or NO. If NO, you can
turn it on by entering:
F NET,VTAMOPTS,OSIMGMT=YES
For more information about VTAMOPTS, refer to z/OS Communications Server SNA Operation.
3. Verify that the topology agent is active.
If not active, start the topology agent and CMIP services, and then proceed to step “7” on page 339.
Refer to the z/OS Communications Server CMIP Services and Topology Agent Guide for information
about starting the VTAM topology agent.
4. Verify that the mainframe server can establish a session with the agent node.
If you are using the APPN function of VTAM, verify that the agent node can be located by VTAM. This
means:
• The agent node must be in the same APPN subnetwork as your VTAM node.
• The agent node must be in a subnetwork adjacent to the VTAM subnetwork and the two
subnetworks are connected by peripheral border nodes or extended border nodes.
• The agent node must be in a subnetwork that is not adjacent to the VTAM subnetwork and the
subnetworks between the agent node subnetworks and the VTAM subnetwork are connected by
extended border nodes.
If the APPN function of VTAM is enabled and the agent node is explicitly defined to VTAM, the
definition requirements are the same as those in effect when not using the APPN function of VTAM.
The SNA topology manager logs the sense code returned from VTAM when a session cannot be
established with the agent node. Refer to the z/OS Communications Server SNA Diagnosis manuals for
more information about diagnosing VTAM problems. Also, see the z/OS Communications Server CMIP
Services and Topology Agent Guide.
Solve the network problem and proceed to step “7” on page 339.
5. Verify that you are not trying to obtain network topology data from an APPN end node.
The topology agent at an end node rejects requests for network topology. If network topology
information was requested from an end node, issue a TOPOSNA STOP,NETWORK command for the
end node.
If local topology data from an APPN end node has been collected, the SNA topology manager has
information about the type of this node. When the network topology request is issued for this APPN
end node, the SNA topology manager cancels the network topology request and issues the following
error message:

FLB691E NODE nodename IS AN END NODE, NETWORK MONITORING IS NOT
SUPPORTED FOR END NODES
6. If all of the previous conditions are satisfied, a network failure can be preventing the delivery of the
request to the agent node.
The SNA topology manager logs the sense code returned from VTAM when a session cannot be
established with the agent node. Locate and correct the network error.
Refer to the z/OS Communications Server CMIP Services and Topology Agent Guide for more
information.
Solve the communications problem and proceed to step “7” on page 339.
7. Issue the TOPOSNA MONITOR command again.
If the SNA topology manager is still retrying the command, it sends the request to the agent node
immediately, without waiting for the retry interval to expire.
RODM Object missing some attribute values

The most probable cause of this problem is that the agent node is not reporting the missing attributes.
Other possible causes are:
• The SNA topology manager is not monitoring the agent node.
• The SNA topology manager is not monitoring the correct type of topology. Many attributes for a
resource are only obtained by monitoring local topology.
• An active path does not exist between the agent node and the SNA topology manager; the more recent
updates cannot be delivered.
• The SNA topology manager does not support the attribute.
To solve the problem:
1. Verify that the SNA topology manager is monitoring the topology of the agent node.
Use the TOPOSNA LISTREQS command to determine which nodes are being monitored and the type of
topology being monitored for each node.
Refer to the IBM Z NetView SNA Topology Manager Implementation Guide and to the NetView online
help facility for more information.
2. Verify that the SNA topology manager is monitoring the correct type of topology. Many attributes are
reported only when the local topology of the owning node of a resource is monitored:
• The resources and attributes reported by network and local topology are described in the IBM
SystemView library.
• The resources and attributes supported by the SNA topology manager are described in the IBM Z
NetView Data Model Reference.
3. Verify that an active path exists between the node owning the resource and a node being monitored by
the SNA topology manager.
The SNA topology manager ignores updates for a resource if an active path does not exist between the
node and any of the nodes being monitored by the SNA topology manager. “The resource status is
unknown” on page 354 describes how the SNA topology manager determines if an active path exists
for each class of resource.
Refer to the IBM Z NetView SNA Topology Manager Implementation Guide for more information.
4. Verify that the SNA topology manager supports the missing attribute.
The resources and attributes supported by the SNA topology manager are described in the IBM Z
The SNA topology manager discards all attributes it does not support. The first time the SNA topology
manager receives an unsupported attribute from an agent, it creates an informational log entry in the
network log, with a major code of 78 and a minor code of 25.
See “SNA Topology Manager log record formats” on page 376 for more information about this log
entry.
5. Verify that the topology agent reports the missing attribute.
All topology agents must report all mandatory attributes; otherwise, VTAM CMIP services rejects the
data received from the agent node and creates a log entry identifying the data being discarded.
Some of the attributes supported by the SNA topology manager are optional, and might not be
reported by the installed topology agent. Refer to the documentation for the topology agent installed
at the agent node to determine what attributes it reports.
The VTAM topology agent is described in the z/OS Communications Server CMIP Services and Topology
Agent Guide.
Another way to determine whether the topology agent is reporting the attribute is to trace the
information being received by the SNA topology manager from the agent node. To trace the
information, perform the following steps:
a. Enable the CMIP trace category, using the TOPOSNA TRACE command, to trace all CMIP data
received by the SNA topology manager.
b. Locate the replies received from the node reporting the resource with the missing attribute to
determine whether the attribute is being reported by the agent node.
The NetView online help facility describes how to use the TOPOSNA TRACE command. The format of
the trace records is described in “GTF trace record format” on page 415. The format of the CMIP-
linked replies received by the SNA topology manager is described in the IBM SystemView library.
Resources are not shown in the Views

The most probable cause of this problem is that the agent node is not reporting the missing resource.
Other possible causes are:
• The SNA topology manager is not monitoring the agent node.
• The SNA topology manager is not monitoring the correct type of topology. Some resources are only
obtained by monitoring local topology.
• An active path does not exist between the agent node and the SNA topology manager; the more recent
updates cannot be delivered.
• The resource was purged by the SNA topology manager. Probable causes are:
– The resource was purged by a TOPOSNA PURGE command.
– The topology agent sent an update deleting the missing resource.
– The class of the object has been changed (as the result of updates from the topology agents), and the
object has been removed from the view.
– The SNA topology manager was cold-started, which purges all SNA topology manager objects.
– The SNA topology manager was warm-started, and it purged the resource.
See “Objects unexpectedly purged” on page 350 for more information about purging resources.
If the missing resource is a node resource, another possibility is that the node might not be in any views
to which the NetView management console operator can navigate.
1. Verify that the SNA topology manager is monitoring the topology of the agent node that is reporting the
missing resource.

Use the TOPOSNA LISTREQS command to determine which nodes are being monitored and the type of
topology being monitored for each node.
Refer to the IBM Z NetView SNA Topology Manager Implementation Guide and to the NetView online
help facility for more information about using the TOPOSNA LISTREQS command.
2. Verify that the SNA topology manager is monitoring the correct type of topology. Many resources are
reported only when the local topology of the owning node of a resource is monitored:
• The resources and attributes reported by network and local topology are described in the IBM
SystemView library.
• The resources and attributes supported by the SNA topology manager are described in the IBM Z
3. Verify that an active path exists between the node owning the resource and a node being monitored by
the SNA topology manager.
The SNA topology manager ignores updates for a resource if an active path does not exist between the
node and any of the nodes being monitored by the SNA topology manager. The resource still exists,
but the attribute values are out-of-date (see “RODM Object missing some attribute values” on page
339) and the status of the resource is set to unknown (see “The resource status is unknown” on page
354).
The resource is not created by the SNA topology manager if the following conditions are true:
• The resource is not reported by the local topology of any node.
• An active path of CP-CP sessions does not exist between any nodes adjacent to the node owning the
resource and any of the nodes whose network topology is being monitored by the SNA topology
manager.
“The resource status is unknown” on page 354 describes how the SNA topology manager determines
if an active path exists for each class of resource.
4. Verify that the object was not purged by the SNA topology manager. See “Objects unexpectedly
purged” on page 350.
5. Verify that the topology agent reported the missing resource.
All topology agents must report all mandatory attributes; otherwise, VTAM CMIP services rejects the
data received from the agent node and creates a log entry identifying the data being discarded.
Some of the attributes supported by the SNA topology manager are optional, and might not be
reported by the installed topology agent. Refer to the documentation for the topology agent installed
at the agent node to determine what resources it reports.
The VTAM topology agent is described in the z/OS Communications Server CMIP Services and Topology
Agent Guide.
Another way to determine whether the topology agent is reporting the attribute is to trace the
information being received (by the SNA topology manager from the agent node). To trace the
information, perform the following steps:
a. Using the TOPOSNA TRACE command, enable the CMIP trace category to trace all CMIP data
received by the SNA topology manager.
b. Locate the replies received from the node to determine whether the resource is being reported by
the agent node.
The IBM Z NetView SNA Topology Manager Implementation Guide describes how to use the TOPOSNA
TRACE command.
The format of the trace records is described in “GTF trace record format” on page 415. The format of
the CMIP-linked replies received by the SNA topology manager are described in the IBM SystemView
library.
Note: VTAM CMIP traces can be used to collect the same information. Refer to the z/OS
Communications Server CMIP Services and Topology Agent Guide for more information.
6. Resources obtained from monitoring the local topology of a node might not be displayed in any views
to which the NetView management console operator can navigate.
The navigation views display all network nodes obtained from monitoring network topology, along with
all nodes adjacent to the network nodes. When a node can be displayed, all resources owned by that
node can also be displayed.
A problem results when the node owning the resource (including the node itself) is not displayed. The
resource might not be displayed if you request the local topology of a node and you are not monitoring
the network topology of the subnetwork the node belongs to, or if the node is not adjacent to a
network node reported by the network topology. In either case, the node is created in the RODM data
cache, and can be found and displayed by using the locate resource function.
To locate a resource, specify the DisplayResourceName of the resource. Use the configuration parents
option. The Any View with the Resource option does not find the resource because it does not search
the SNA topology manager views.
Using the locate resource function and formatting of the display resource names for all resources
(objects) created by the SNA topology manager are described in the IBM Z NetView SNA Topology
Manager Implementation Guide. Also, refer to the IBM Z NetView Data Model Reference for more
information about display resource names.
Monitor Operation unexpectedly ends

The SNA topology manager tries to restart the monitor operation if a network problem occurred.
The monitor operation stopped because Page

Operation ended normally because an operator “Monitor Operation ended normally” on page 345
issued the TOPOSNA STOP command.
Operation ended normally because it was timed and “Monitor Operation ended normally” on page 345
the specified amount of time had elapsed.
The SNA topology manager was shut down by “Topology Manager or VTAM CMIP Services was ended
operator request. by an operator” on page 345
VTAM CMIP services were ended by operator “Topology Manager or VTAM CMIP Services was ended
request. by an operator” on page 345
The SNA topology manager was shut down because “Topology Manager or VTAM CMIP Services
of an unrecoverable error. unexpectedly ended” on page 345
VTAM CMIP services were ended because of an “Topology Manager or VTAM CMIP Services
unrecoverable error. unexpectedly ended” on page 345
An active VTAM path or session became inactive. “An active VTAM path or session became inactive” on
page 345
A network problem caused the LU 6.2 session being “Monitor operation stopped because of a Network
used by the monitor operation to end. Problem” on page 345
The topology agent, agent CMIP services, or agent “Monitor operation stopped because of a Network
communications support was ended, either by Problem” on page 345
operator request or because of an unrecoverable
error.
To determine why the monitor operation stopped, do the following steps:

1. If the monitor operation stopped because an operator issued the TOPOSNA STOP command, the
operator that issued the TOPOSNA MONITOR command receives the following message (this message
is also sent to the network log):

FLB405W OPERATOR 'operatorid' STOPPED MONITORING SNA NETWORK TOPOLOGY

FROM NODE nodename
FLB422W OPERATOR 'operatorid' STOPPED MONITORING SNA LOCAL TOPOLOGY

FROM NODE nodename
FLB541W OPERATOR operatorid STOPPED MONITORING LU COLLECTION

FROM nodename
See “Monitor Operation ended normally” on page 345 to solve the problem.
2. If the monitor operation stopped because the time specified in the MONTIME parameter on the
TOPOSNA MONITOR command expired, the operator who issued the TOPOSNA MONITOR command
receives the following message (this message is also placed in the network log):
FLB404I COMPLETED MONITORING SNA NETWORK TOPOLOGY FROM NODE nodename
FLB421I COMPLETED MONITORING SNA LOCAL TOPOLOGY FROM NODE nodename
FLB584I COMPLETED MONITORING LU COLLECTION DATA FROM NODE nodename
See “Monitor Operation ended normally” on page 345 to solve the problem.
3. If the monitor operation stopped because the SNA topology manager ended, the network log contains
messages indicating that the SNA topology manager has stopped.
• If an operator request ended the SNA topology manager, see “Topology Manager or VTAM CMIP
Services was ended by an operator” on page 345 to solve the problem.
• If an unrecoverable error caused the SNA topology manager to unexpectedly end, see “Topology
Manager or VTAM CMIP Services unexpectedly ended” on page 345 to solve the problem.
4. If the monitor operation stopped because VTAM CMIP services ended, the network log contains
messages indicating that VTAM CMIP services has stopped.
The SNA topology manager also ends, placing messages in the network log indicating it has also
stopped.
• If an operator request ended VTAM CMIP services, see “Topology Manager or VTAM CMIP Services
was ended by an operator” on page 345 to solve the problem.
• If an unrecoverable error caused VTAM CMIP services to unexpectedly end, see “Topology Manager
or VTAM CMIP Services unexpectedly ended” on page 345 to solve the problem.
5. If the monitor operation stopped because an active VTAM path or session became inactive, the
operator who issued the TOPOSNA MONITOR command receives the following message (this can
happen if the monitor request is to a remote VTAM):

See “An active VTAM path or session became inactive” on page 345 to solve the problem.
6. If the monitor operation stopped because of a network error, the SNA topology manager sends the
following messages to the operator that started the monitor operation (the message is also placed in
the network log):
7. • For network topology:

FLB408W MONITORING OF SNA NETWORK TOPOLOGY FROM NODE nodename IS
BEING RETRIED
If the error is an unrecoverable error:
FLB407E MONITORING OF SNA NETWORK TOPOLOGY FROM NODE nodename FAILED

FLB425W MONITORING OF SNA LOCAL TOPOLOGY FROM NODE nodename IS
BEING RETRIED
FLB424E MONITORING OF SNA LOCAL TOPOLOGY FROM NODE nodename FAILED
FLB544W MONITORING OF THE LU COLLECTION FROM NODE nodename

WILL BE RETRIED
FLB542E MONITORING OF THE LU COLLECTION FROM NODE nodename FAILED
See “Monitor operation stopped because of a Network Problem” on page 345 to solve the problem.
8. If the monitor operation stopped because the topology agent, the agent CMIP services, or the agent
communications support ended, the SNA topology manager sends a message to the operator that
started the monitor operation.
The message is also placed in the network log. The messages used are the same as those used when a
network error is detected.
Also, the following message might be logged:
FLB692W SNA TOPOLOGY MANAGER ENCOUNTERED A CMIP SERVICES ERROR.

TARGET NAME 'targetname'.
SERVICE ERROR CODE 'serviceErrorCode'.
ERROR VALUE 'errorValue'.
GENERIC VALUE 'genericValue'.
SENSE CODE X'senseCode'.
Where:
targetname
Is the name of the resource that was the target of the request.
serviceErrorCode
Is the return code provided by CMIP services.
errorValue
Is the internal indicator used to map the CMIP error.
genericValue
Is the processing failure error code.

senseCode
Is the SNA sense code.
See “Monitor operation stopped because of a Network Problem” on page 345 to solve the problem.
Monitor Operation ended normally

The monitor operation ended because an operator stopped the operation or because the time specified
by the MONTIME parameter elapsed.
To solve the problem, check with the other operators to determine whether the monitor operation must
be restarted.
Topology Manager or VTAM CMIP Services was ended by an operator

The monitor operation stopped because either the SNA topology manager or VTAM CMIP services was
ended by an operator.
Check with the operator who stopped the task as to the reason for ending the task. Restart the SNA
topology manager, and VTAM CMIP services if necessary, and restart the monitor operation.
Topology Manager or VTAM CMIP Services unexpectedly ended

The monitor operation stopped because the SNA topology manager or VTAM CMIP services unexpectedly
ended. Use the messages and log entries in the network log to determine why the SNA topology manager
or VTAM CMIP services ended.
When the VTAM CMIP services ends, the following message is issued:
Use the descriptions of the messages and log entries to diagnose and correct the problem. Restart the
SNA topology manager, and VTAM CMIP services if necessary, and restart the monitor operation.
An active VTAM path or session became inactive

The monitor operation stopped because of an active path or session to this node became inactive.
For example, an active CDRM to the remote VTAM became inactive or was deactivated by an operator, or
if this remote VTAM had a session through an NCP-NCP connection, the link between two NCPs became
inactive or was deactivated by an operator.
To solve the problem, determine whether the CDRM and the link to this node are active. If not, activate
the CDRM, the link to this node, or both. When the session is active, the SNA topology manager resumes
the monitor operation providing the monitor request retry is still in effect.
Monitor operation stopped because of a Network Problem

The SNA topology manager begins retrying the monitor operation, using the retry values specified by the
TOPOSNA SETDEFS command. If it is a temporary network problem, the SNA topology manage is
probably able to restart the monitor operation. Some network problems can require operator intervention
to solve.
Refer to the z/OS Communications Server SNA Diagnosis manuals for more information about diagnosing
VTAM CMIP services problems. For information about VTAM CMIP services, see the z/OS Communications
If you solve the problem before the SNA topology manager exhausts its retries, the monitor operation is
restarted the next time the SNA topology manager tries to restart the monitor operation.
The amount of time until the next retry can be long, depending on the values specified by the TOPOSNA
SETDEFS command. To determine the amount of time until the SNA topology manager retries the
operation, use the TOPOSNA LISTREQS command. If the time period until the next retry is too long, issue
the TOPOSNA MONITOR command again; the SNA topology manager retries the operation immediately.
If the SNA topology manager has exhausted its retries before the problem is solved, the monitor
operation is ended. Issue the TOPOSNA MONITOR command again to restart the monitor operation. The
SNA topology manager sends the following message to the operator that started the monitor operation,
and logs it in the network log, when the retries for a monitor operation are exhausted:
FLB462E MONITORING OF SNA NETWORK TOPOLOGY FROM NODE nodename

FAILED ALL RETRIES
FLB463E MONITORING OF SNA LOCAL TOPOLOGY FROM NODE nodename

FAILED ALL RETRIES
FLB545E MONITORING OF THE LU COLLECTION FROM NODE nodename

FAILED ALL RETRIES
If the error is an unrecoverable error, the SNA topology manager does not retry the operation and the
monitor operation is ended. Issue the TOPOSNA MONITOR command again to restart the monitor
operation.
The SNA topology manager commands are described in the NetView online help facility. Refer to the IBM
Z NetView SNA Topology Manager Implementation Guide for more information about monitoring topology
information.
Blank status history for a Topology Manager resource

You selected an SNA topology manager resource, and issued the Event Viewer request. The view that is
presented does not contain status history.
2. Verify that the SNA topology manager is monitoring the relevant topology in your network.
3. Overall system performance can be degraded such that the SNA topology manager is so busy trying to
process topology updates, that a timer expires without NetView management console obtaining the
necessary data to present the status history.
A Locate Resource request does not find the resource

You entered the name of an LU in the locate resource window and checked the Extended Search check
box. However, a view of the resource in RODM is not found.
2. Verify that the resource name entered is a valid LU name.
3. Overall system performance can be degraded because the SNA topology manager is so busy (trying to
process topology updates) that a timer expires without the SNA topology manager creating the LU in
RODM in time for NetView management console to present a view of the resource.
Specify a value for the VTAM IOPURGE timer that is less than twenty percent of the value specified for
the GMFHS LCON-SNATM-TIMEOUT timer.
4. Overall system performance can be degraded such that the SNA topology manager request to the
agents cannot complete in time for NetView management console to present a view of the resource.

Include the agent name (snaNetID.SSCP_name) when you specify the name of the LU that enables the
topology manager to send the request directly to the agent at the specified node.
Cannot activate, deactivate, or recycle a resource

There are a number of reasons why the SNA topology manager cannot activate, deactivate, or recycle a
resource at an agent node. Refer to the IBM Z NetView SNA Topology Manager Implementation Guide for a
description of these resource control operations. Use the VTAM V NET command for agent-owned
resources.
Network problems
Most of the problems are related to communications problems or setup problems at the agent node.
Refer to the z/OS Communications Server SNA Diagnosis manuals for more information about diagnosing
VTAM CMIP services problems. For information about VTAM CMIP services, see the z/OS Communications
Generic commands fail

You select a resource and execute the generic activate, deactivate, or recycle command from an NetView
management console workstation command pull-down menu, but the wrong command is issued.
To solve the problem, check the CommandIndicator field as defined in the SNA topology data model to
ensure it has the correct value for the resource selected. Refer to the IBM Z NetView Data Model Reference
for more information about the CommandIndicator field and the valid values for each object.
If the wrong value is filled in by the SNA topology manager, contact IBM Software Support and provide
the value, the object name, and the object class.
Incorrect NetView Management Console command profiles

SNA topology manager resources can be controlled using the following features at the NetView
management console workstation:
• NetView management console generic resource commands
• A customized NetView management console command profile editor resp file
• The NetView command line
Most of these options require customization of the NetView management console workstation to use.
The steps needed to modify the NetView management console command profiles, and add customized
commands are described in the IBM Z NetView User's Guide: NetView Management Console.
Objects are not purged

An operator can purge an object from the RODM data cache by:
• Issuing a TOPOSNA PURGE command
• Cold-starting the SNA topology manager
• Warm-starting the SNA topology manager
The SNA topology manager can purge an object from the RODM data cache when any of the following is
true:
• An update is received from a topology agent indicating that the object no longer exists.
• An update is received that indicates that a link is now associated with another TG.
• An update is received for a node that specifies a new node type (class) for a node. The old node in the
RODM data cache is deleted and replaced with a new node object in the correct class.
1. Verify that the object was created by the SNA topology manager.
The SNA topology manager deletes only those objects that it creates. All other objects must be
explicitly deleted by an operator or program.
The SNA topology manager sets the FLB_CREATOR attribute in every object it creates to FLB. Objects
that do not have this attribute or have the attribute set to a different value are not deleted by the SNA
topology manager, unless the object is a node object and the SNA topology manager learns that the
class of the object does not match the type of the node in the network.
2. Verify that the status of the object is unknown.
If the status of the object is not unknown, the object is being updated by one or more existing monitor
operations.
The SNA topology manager does not purge objects that are still being reported by topology agents.
To purge these objects, the monitor operations that are providing updates for the resource must be
stopped.
“The resource status is unknown” on page 354 describes which monitor operations provide
information about a resource.
For more information about how the status of resources is reported, when the SNA topology manager
considers the information reliable, and when objects are purged, refer to the IBM Z NetView SNA
Topology Manager Implementation Guide.
After stopping the appropriate monitor operations, the status of the resource changes to unknown.
Issue a TOPOSNA PURGE,PURGDAYS=0 command to purge the resource. Zero is specified for
PURGDAYS because the status of the resource was just updated to unknown.
After purging the resource, restart any desired monitor operations. If the resource is created again, it
still exists in the network and must not be purged.
Note: When a TOPOSNA PURGE command is issued, the SNA topology manager purges all objects that
have not been updated within the specified time period and are not currently being monitored. A
TOPOSNA PURGE,PURGDAYS=0 command purges all resources that are not currently being
monitored. These resources are created again when the appropriate monitor operations are started, if
the resources still exist.
Objects are purged during initialization of the SNA topology manager regardless of their displayed
status. No monitors are active; therefore, the SNA topology manager does not check the status of each
object before purging it. In fact, after initialization the status of all objects not purged is set to
unknown.
If the SNA topology manager is warm-started, this status might be changed by the SNA topology
manager soon after because of updates received from the monitor operations it auto-started.
3. Verify that object is not being monitored, even though status of the object is unknown.
Examples of objects to verify include:
• The SNA topology manager might still be monitoring the status of the object, even though its status
is unknown.
In addition to when the resource is not being monitored, the SNA topology manager marks the status
of resources as unknown when an active path does not exist between the resource and the nodes
being monitored. (If an active path does not exist, the topology agent cannot report reliable
information about the resource and the SNA topology manager sets the status of the object to
unknown).

For more information about the following topics, refer to the IBM Z NetView SNA Topology Manager
Implementation Guide.
– Reporting resource status
– When the SNA topology manager considers the information reliable
– When objects are purged
Determine whether any existing monitor operations might still be reporting the resource, even
though the status of the resource is unknown. Proceed with the actions described in step “2” on
page 348.
• Local topology
For local topology, adjacent nodes are marked unknown if the link between the adjacent node and
the node being monitored is inactive.
• Network topology
For network topology, network nodes and the TGs owned by the network nodes are marked
unknown if an active path of CP-CP sessions does not exist between the nodes and the network
nodes being monitored. “The resource status is unknown” on page 354 describes what monitor
operations provide information about a resource.
4. Verify that the resource has not been updated within the specified time period.
Verify again that the resource is not being reported by any active monitor operations. See steps “2” on
page 348 and “3” on page 348.
If the resource is not being monitored and is not being purged, the status of the object has probably
been updated within the time period specified by the purge operation. The PURGDAYS parameter of
the TOPOSNA PURGE command and the PURGDAYS keyword in the FLBSYSD file (used during SNA
topology manager initialization) specify the maximum age for resources.
Any resource that has not been updated within the specified time period is purged (if it is not being
monitored). Objects are not purged if the SNA topology manager has received an update for the
resource within the specified time period.
To determine when a resource was last updated, query the TIMESTAMP subfield of the states field of
the object. Query the RODM data cache directly or query the information by requesting more
information about the object from an NetView management console workstation. If the time stamp is
within the time specified by the purge operation, the object is not purged.
Either decrease the time period and issue the purge operation again, or issue the purge operation
again with the same values when the object is old enough to be purged.
Note: When a TOPOSNA PURGE command is issued or the SNA topology manager is started, the SNA
topology manager purges all objects that have not been updated within the specified time period and
are not currently being monitored. Decreasing the time period for the purge operation might purge
resources that you do not want purged. These resources can be created again by starting the
appropriate monitor operations, if the resources still exist.
For more information about reporting resource status, when the SNA topology manager considers the
information reliable, when objects are purged, refer to the IBM Z NetView SNA Topology Manager
5. Verify that an error did not occur when the SNA topology manager tried to purge the resource.
The SNA topology manager might have encountered an unrecoverable RODM error when it tried to
purge an object. If this occurs, the SNA topology manager creates the log entry 78-71 and possibly
shuts down.
Refer to “SNA Topology Manager log record formats” on page 376 for a description of this log entry,
along with possible resolutions to the problem.
The SNA topology manager rarely encounters errors that it cannot recover from when purging an
object.
If the definition of the SNA topology manager object class definitions in the SNA topology data model
is modified to include extra OBJECTLINK or OBJECTLINKLIST attributes, the SNA topology manager is
not able to delete any of the objects of that class.
Modifying the object class definitions of the SNA topology manager objects will probably cause other
problems and is not supported by the SNA topology manager. If the class definitions have been
modified, do the following steps:
a. Stop the SNA topology manager and RODM.
b. Restore the NetView SNA topology manager object class definitions.
c. Cold-start RODM, or warm-start with a version of checkpoint data that does not include the SNA
topology data model.
d. Reload the GMFHS data model (if necessary) and the SNA topology data model into the RODM data
cache.
e. Start the SNA topology manager and start all required monitor operations.
Objects unexpectedly purged

The SNA topology manager purges an object from the RODM data cache when any of the following is true:
• An operator issues a TOPOSNA PURGE command.
• The SNA topology manager was warm-started.
• The SNA topology manager was cold-started, which purges all SNA topology manager objects.
• The class of the object has been changed (as the result of updates from the topology agents), and the
object has been replaced by an object of a different class.
• The name of the object has been changed (as the result of updates from the topology agents), and the
object has been replaced by an object of a different name.
• The topology agent sent an update deleting the missing resource.
To determine why the resource was purged, do the following steps:
• Check the network log. If a TOPOSNA PURGE command was recently issued, the resource was probably
purged by the command. Proceed to step “1” on page 351.
• If the SNA topology manager was recently started, the resource was probably purged during
initialization of the SNA topology manager.
If the SNA topology manager was warm-started, proceed to step “2” on page 351.
Otherwise the SNA topology manager was cold-started. Proceed to step “3” on page 351.
During SNA topology manager initialization, one of the following messages is issued, identifying how the
SNA topology manager was started:
FLB402I SNA TOPOLOGY MANAGER HAS BEGUN WARM-START PROCESSING

FLB418I SNA TOPOLOGY MANAGER HAS BEGUN COLD-START PROCESSING
• If the missing resource is a node, it might have been deleted because the SNA topology manager
received an update from a topology agent that changed the class of the object.
The SNA topology manager deletes the existing object and creates a new object, under the new class, to
represent the node. The new object might need to be removed from certain views it is in because it is
incorrect for an object of the new class to be in that view. Proceed to step “4” on page 352.
• If the missing resource is a node, it might have been deleted because the SNA topology manager
received an update from the topology agent that changed the name of the object.
This might happen for t4Nodes and t5Nodes.

• The missing resource might have been deleted because the topology agent sent an update informing
the SNA topology manager that the resource no longer exists.
Proceed to step “6” on page 353.
• If none of the above scenarios describe the problem, the SNA topology manager did not delete the
resource.
Determine whether one of the previous scenarios explains why the resource was purged. If none of
them are applicable, check for GMFHS errors or problems at the NetView management console
workstation.
To resolve the problem, do the following steps:
1. The resource was purged by a TOPOSNA PURGE command.
The TOPOSNA PURGE command purges resources (the objects used to represent the resources) from
the RODM data cache. When the object is removed from the RODM data cache, it is also deleted from
any NetView management console views it is in.
To determine whether an object was purged, look to see if it still exists in the RODM data cache. You
can use the RODMView function to check the existence of the object.
The object is purged by the TOPOSNA PURGE command because it is not being monitored and the
number of days since its last update exceeds the number of days specified by the PURGDAYS
parameter. Refer to the IBM Z NetView SNA Topology Manager Implementation Guide for more
information about purging objects.
If the object still exists in the network and if you want to restore it to your NetView management
console views, proceed to step “7” on page 353. Otherwise, no action is required.
2. The resource was purged when the SNA topology manager was warm-started.
The SNA topology manager purges all resources that have not received updates within the amount of
time specified by the PURGDAYS keyword in the FLBSYSD file.
The processing is similar to that performed when a TOPOSNA PURGE command is issued:
• The resources (the objects used to represent the resources) are removed from the RODM data
cache.
• When the object is removed from the RODM data cache, it is also deleted from any NetView
management console views where it appears.
Refer to the IBM Z NetView SNA Topology Manager Implementation Guide for more information about
purging objects.
To determine whether an object was purged, verify whether it still exists in the RODM data cache. You
can use the RODMView function to check the existence of the object.
If the object still exists in the network and you want to restore it to your NetView management console
views, proceed to step “7” on page 353. Otherwise, no action is required.
3. The resource was purged when the SNA topology manager was cold-started.
The SNA topology manager purges all resources that have not received updates within the amount of
time specified by the PURGDAYS keyword in the FLBSYSD file.
The SNA topology manager is cold-started when this value is set to zero; in other words, all objects
created by the SNA topology manager are purged.
The processing is similar to that performed when a TOPOSNA PURGE command is issued:
• The resources (the objects used to represent the resources) are removed from the RODM data
cache.
• When the object is removed from the RODM data cache, it is also deleted from any NetView
management console views where it appears.
purging objects.
If the SNA topology manager was cold-started, all objects created by the SNA topology manager are
deleted. The only SNA topology manager objects left in the RODM data cache are those created by
other means (such as customer-created objects using the RODM loader files).
If the object still exists in the network and if you want to restore it to your NetView management
console views, proceed to step “7” on page 353. Otherwise, no action is required.
4. A node was deleted by the SNA topology manager and created again using a different node class.
One of the following messages is issued:
FLB430I NODE nodename OF CLASS class1 IS

UPGRADED TO CLASS class2
WITH NEW RODM OBJECT ID rodmobjectid
FLB431I NODE nodename OF CLASS class1 IS

REPLACED WITH SAME NODE OF CLASS class2
WITH NEW RODM OBJECT ID rodmobjectid
• The SNA topology manager changes the class of node objects as more accurate information is
learned about the type of the node.
The SNA topology manager tries to maintain the object in all its existing views, but sometimes the
new object is not valid in a view. For example, if a node was changed from an end node to a network
node, the node is no longer displayed in the network node domain view (the nnDomain object) of the
previously serving network node.
Likewise, if a node is changed from a network node to an end node, the nnDomain object associated
with the network node is deleted.
See the IBM Z NetView SNA Topology Manager Implementation Guide for more information about
how and why the class of node objects is also changed in the IBM Z NetView Data Model Reference.
• The resource still exists in the RODM data cache, but is defined under a different object class.
Open the NetView management console views containing the resource or use Locate Resource pull-
down menu selection to display the resource.
To locate the new node, specify the DisplayResourceName of the resource (the network-qualified
name of the node).
Use the Configuration Parents option. The Any View with the Resource option does not find the
resource because it does not search the SNA topology manager views.
Information about how to use the Locate Resource function and format the display resource names for
all resources (objects) created by the SNA topology manager is described in the IBM Z NetView SNA
Topology Manager Implementation Guide. Also, refer to the IBM Z NetView Data Model Reference for
more information about displaying resource names.
5. A node was deleted by the SNA topology manager and created again using a different node name.
If the missing resource is a node, it might have been deleted because the SNA topology manager
received an update from a topology agent that changed the name of the object. This might happen for
t4Nodes and t5Nodes.
The following message is issued:
FLB690I NODE nodename1 OF CLASS class IS REPLACED

WITH THE NODE nodename2 WITH RODM OBJECT ID rodmobjectid
This happens when a back-level NCP (t4Node) is known to a VTAM host contact only, meaning the NCP
has never been activated but VTAM knows about the NCP.
VTAM reports this NCP by its subarea number (NETA.00000097), and the SNA topology manager
creates this t4Node in RODM as NETA.00000097.

When the NCP is activated, VTAM reports this NCP by name (NETA.NCP1) and also reports its subarea
information.
This indicates to the SNA topology manager that NETA.00000097 is really NETA.NCP1; therefore, the
SNA topology manager deletes node NETA.00000097 from RODM and creates node NETA.NCP1 and
message FLB690I is logged.
The same scenario is possible for a t5Node.
6. A topology agent sent an update deleting a resource.
Transmission groups (TGs) associated with dynamically created links are deleted when the underlying
link is deactivated. TGs are also deleted when the link associated with the TG is assigned to another
TG.
Objects that are members of a VTAM topology agent's definition group are deleted when the definition
group is deactivated.
If the resource is still defined at the agent node, it was not deleted. If the object still exists in the
network and you want to restore it to your NetView management console views, proceed to step “7”
on page 353. Otherwise, no action is required.
7. If the object still exists, restore it to the views by monitoring the correct topology.
Do one of the following to create an object again that has been deleted in the RODM data cache and in
the NetView management console views:
• For any resource, monitor the local topology of the node owning the resource.
If the local topology of the node is already being monitored or the resource is not restored when the
monitor operation is started, the resource is no longer defined at that node.
• If the resource is a node, monitor the local topology of a node adjacent to the missing node.
If the local topology of the node is already being monitored or the resource is not restored when the
monitor operation is started, the missing node is not connected to the node being monitored or the
connection is inactive.
• If the resource is a network node or a TG between two network nodes, monitor the network topology
of any network node in the same subnetwork.
If the network topology of the subnetwork is already being monitored or the resource is not restored
when the monitor operation is started, one of the following is true:
– The resource no longer exists.
– The resource is no longer a part of the network topology of the subnetwork.
A network node might have been changed to an end node, removing the node and any TGs to the
node from the network topology of the subnetwork.
– An active path of CP-CP sessions does not exist between the network nodes being monitored and
any of the network nodes adjacent to the missing node.
Try monitoring the network topology of the missing node (or for TGs the node owning the TG) or
one of the nodes adjacent to the missing node.
For more information about how resources are reported by the agent node, refer to the IBM Z
NetView SNA Topology Manager Implementation Guide.
• If the resource is not restored by any of the other steps, the resource probably no longer exists.
To restore the resource to your NetView management console views, do one of the following steps:
– Explicitly, create the resource definition in the RODM data cache (define the resource to RODM by
way of a loader file).
– Stop the SNA topology manager and RODM.
Restart RODM using a copy of checkpoint data that contains a definition of the resource; warm-
start the SNA topology manager.
Attention: Starting RODM with checkpoint data removes all data created by the SNA topology
manager since the checkpoint data set was created from the RODM data cache. To rebuild
this data, issue monitor operations for all missing resources. User-created objects and
objects that no longer exist in the network that are not in the checkpoint data cannot be
restored without the objects being explicitly created by the user.
The resource status is unknown

The SNA topology manager shows the status of a resource as unknown when it cannot reliably determine
the status of the resource. The following are reasons the SNA topology manager cannot determine the
status of a resource:
• The SNA topology manager is not monitoring the network or local topology of the nodes that report the
status of the resource.
• The SNA topology manager is currently monitoring a node that can report the status of a resource, but
no path exists between the node being monitored and the node owning the resource.
• The resource no longer exists.
• Only an LUCOL topology is requested for the node listed in the NODE parameter of the TOPOSNA
MONITOR command.
• An LUCOL topology is requested for the logicalLink listed in the LCLNAME parameter of the TOPOSNA
MONITOR command and the logicalLink has not been reported by a LOCAL topology monitor.
• A locate resource is requested for a logicalUnit and the logicalUnit is associated with a logicalLink that
has not been reported by a LOCAL topology monitor.
For more information about reporting the status of resources, refer to the IBM Z NetView SNA Topology
Manager Implementation Guide.
To quickly find information in this section, see the following table:
Table 139. Resource Status Is Unknown

A resource has a status of unknown because it is Page
A node other than an APPN network node “The Resource Is a node other than an APPN
network node” on page 354
An APPN network node “Resource is an APPN network node” on page
355
A TG that does not connect two network nodes “Resource is a TG that does not connect two
network nodes” on page 355
A TG that connects two network nodes “Resource is a TG that connects two network
nodes” on page 355
A TG circuit “Resource is a TG circuit” on page 356
A link “Resource is a link” on page 356
A port “Resource is a port” on page 356
An interchange node or a migration data host “Resource is an interchange node or a migration
data host” on page 356
A t5Node “Resource is a t5Node” on page 357
The Resource Is a node other than an APPN network node

Nodes other than APPN network nodes are reported by:
• Monitoring the local topology of the node

• Monitoring the local topology of a node adjacent to the node and an active link exists between the two
nodes
To solve the problem, monitor the local topology of the node or the local topology of one or more of its
adjacent nodes. The status of the node remains unknown if the local topology of the node is not
monitored, and there are no links active between the node and any of the adjacent nodes being
monitored.
Resource is an APPN network node

APPN Network nodes are reported by:
• Monitoring the local topology of the node
• Monitoring the local topology of a node adjacent to the node and an active link exists between the two
nodes
• Monitoring the network topology of any network node in the subnetwork containing the node (as long as
an active path of CP-CP sessions exists between the node and the network node being monitored).
The local topology conditions are the same as any other node in the network.
APPN network nodes can also be reported by monitoring the network topology of any other network node
in the subnetwork because APPN propagates the status of all network nodes in a subnetwork to all other
network nodes in that subnetwork.
An active path of CP-CP sessions must exist between the node and the network node reporting the status
of the node using network topology because the network nodes use CP-CP sessions to propagate the
status of the network nodes throughout the network.
If an active path does not exist, the information being reported for the node is not considered reliable
because more recent updates are not being received by the network node reporting the status.
To solve the problem, monitor one of these:
• The local topology of the node
• The local topology of one or more of its adjacent nodes
• The network topology of one or more network nodes in the same subnetwork as the node
The status of the node remains unknown if all of the following are true:
• The local topology of the node is not monitored.
• No links are active between the node and any of the adjacent nodes being monitored.
• A path of active CP-CP sessions does not exist between the node and any of the network nodes in the
subnetwork whose network topology is being monitored.
Resource is a TG that does not connect two network nodes

TGs that are not between network nodes are reported only by monitoring the local topology of the node
owning the TG.
To solve this problem, monitor the local topology of the node owning the TG.
Resource is a TG that connects two network nodes

TGs between network nodes are reported by:
• Monitoring the local topology of the node owning the TG.
• Monitoring the network topology of any network node in the subnetwork containing the node (as long as
an active path of CP-CP sessions exists between the node owning the TG and the network node being
monitored)
The local topology conditions are the same as any other TG in the network.
TGs between network nodes can also be reported by monitoring the network topology of any other
network node in the subnetwork because APPN propagates the status of all TGs between network nodes
in a subnetwork to all other network nodes in that subnetwork.
An active path of CP-CP sessions must exist between the node owning the TG and the network node being
monitored because the network nodes use CP-CP sessions to propagate the status of the TGs throughout
the network.
If an active path does not exist, the information being reported for the TG is not considered reliable
because more recent updates are not being received by the network node reporting the status.
To solve the problem, monitor the local topology of the node owning the TG or the network topology of
one or more network nodes in the same subnetwork as the node owning the TG.
The status of the TG remains unknown if all of the following are true:
• The local topology of the node owning the TG is not monitored.
• A path of active CP-CP sessions does not exist between the node owning the TG and any of the network
nodes in the subnetwork whose network topology is being monitored.
Note: All TGs between network nodes are placed in the network topology database. This includes TGs
that do not support CP-CP sessions. Some TGs that are defined to connect two network nodes might not
be defined in the network topology database until the link associated with the TG is activated.
Resource is a TG circuit
The status of TG circuits is derived from the status of the underlying TGs. If the status of both TGs is
unknown, the status of the TG circuit is also unknown.
If the SNA topology manager knows only about one of the TGs associated with the TG circuit, the status of
the TG circuit matches the status of the TG.
Refer to “Resource is a TG that does not connect two network nodes” on page 355 and “Resource is a TG
that connects two network nodes” on page 355 for information about obtaining the status of the TGs
associated with the TG circuit. Obtaining the status of a TG associated with a TG circuit updates the status
of the circuit.
Resource is a link
Links are reported only by monitoring the local topology of the node owning the link.
To solve the problem, monitor the local topology of the node owning the link.
Resource is a port
Ports are reported only by monitoring the local topology of the node owning the port.
To solve this problem, monitor the local topology of the node owning the port.
Resource is an interchange node or a migration data host

If network or local topology data is not being actively collected from an interchange node or a migration
data host node, the SNA topology manager derives the status of the node based on the
COMBINE_STATUS specifications (BEST or WORST) in the FLBSYSD initialization file.
The following example specifies a status of BEST in the FLBSYSD file:
COMBINE_STATUS:
COMBINE_IC_APPN_AND_SUBAREA_STATUS=BEST
COMBINE_MDH_APPN_AND_SUBAREA_STATUS=BEST
When combining the subarea status and APPN status of an interchangeNode or migrationDataHost object
and BEST status is specified, the status of the node is satisfactory if either the subarea or APPN side of
the node is active.

The subarea side is considered active when there is an active CDRM to this node from the reporting VTAM
agent. The APPN side is considered active when the node is reachable or there is an active APPN
connection from the reporting VTAM agent.
If WORST is specified and one side (subarea or APPN) is not active, the status of the node is unknown.
Use the WORST status specification to determine whether either side (APPN or subarea) of a node is not
active.
When only LUCOL topology is requested, the node is created as an snaNode, and the status is set to
unknown.
To solve the problem, change the specification in the FLBSYSD file and restart the SNA topology manager
or actively monitor the node from both sides (subarea and APPN).
Resource is a t5Node
When only network topology is collected from a VTAM topology agent, only CDRM information is reported
by the VTAM topology agent. When an active CDRM is reported with a realSSCPname, the SNA topology
manager:
• Creates the CDRM in the RODM data cache
• Creates a t5Node object in the RODM data cache with the realSSCPname
• Sets the t5Node object status to satisfactory
If this active CDRM is deactivated or becomes inactive because of a network problem, the VTAM topology
agent reports this CDRM as an inactive node. The SNA topology manager updates the status of this CDRM
to inactive and the status of the t5Node object created with the realSSCPname to unknown.
When only LUCOL topology is requested, the node is created as an snaNode, and the status is set to
unknown.
1. Activate the CDRM, if deactivated by an operator, or investigate why the CDRM became inactive,
2. If a network problem caused this condition, correct the problem.
Resource status incorrect or not being updated

The status of a resource is updated by the SNA topology manager when an update is received from a
topology agent for the resource. There are instances where the displayed status of a resource might not
be what the NetView management console operator expects.
The status of resources can be customized:
• You can modify the DisplayStatus of a resource by mapping the OSI status to DisplayStatus using the
FLBOSIDS customization table.
• You can modify the resolved status for a resource by using the FLBSRT customization table.
• You can make a resource part of an exception view by using the FLBEXV customization table.
Refer to the IBM Z NetView SNA Topology Manager Implementation Guide for more information.
The most common reasons why the status of the resource is not set to the expected value are:
• The SNA topology manager or agent node encounters a problem while processing the resource control
command.
See “Cannot activate, deactivate, or recycle a resource” on page 347 for a description of the failures
that can occur, along with suggested solutions.
• The status of the resource is not changed by resource control commands.
• The SNA topology manager is not receiving the status update for the resource.
• The SNA topology manager is not aware of a configuration change in the network.
• Mapping of the OSI status and states to the DisplayStatus of a resource is incorrect in the FLBOSIDS
table.
• Mapping of OSI status for the resolved status of a multiply-owned resource is incorrect in FLBSRT table.
For more information about processing updates and the interpretation of the status of resources, refer to
the IBM Z NetView SNA Topology Manager Implementation Guide.
The following are resolutions to various status inconsistencies:
1. The status of the resource is shown as unknown.
• If the status of the resource is unknown, the SNA topology manager is not receiving status updates
for the resource.
The SNA topology manager does not receive status updates for resources it is not currently
monitoring. It also does not receive status updates when network conditions prevent the receipt of
the update by an agent node or the delivery of the update to the SNA topology manager.
See “The resource status is unknown” on page 354 for more information about these possible
problems and suggested resolutions.
• When the OSI status received cannot be mapped using the FLBOSIDS or FLBSRT customization
tables, the SNA topology manager defaults the status of the resource to unknown and the following
message is issued:

If the status was not found in the FLBOSIDS table, the DisplayStatus is set to unknown. If the status
was not found in the FLBSRT table, the resolved status that was calculated might not be the correct
status. See the NetView online help facility for more information.
2. The status of the transmission group or TG circuit is satisfactory or intermediate and the status of the
underlying link is unsatisfactory.
Transmission groups might not change status, even when their underlying link is deactivated, if the
underlying link is demand-activated. In addition, transmission group circuits do not change status if
their underlying transmission groups do not change status.
Transmission groups with underlying demand-activated links remain active (in APPN terms) because
they are still available for use. Therefore, the topology agents do not generate updates for these
transmission groups when their underlying links are inactive.
The SNA topology manager attempts to reflect a status change by changing the status of the
transmission group to intermediate if it is active but its underlying link is inactive.
If you are not monitoring the local topology of the node owning the transmission group, the SNA
topology manager cannot determine the status of the underlying link. The status of the transmission
group remains satisfactory.
Ignore the perceived status inconsistency. For more information, refer to the IBM Z NetView SNA
3. The status of the transmission group is unknown and the status of the underlying link is unsatisfactory.
The configuration of the node was changed so that the link is now associated with another
transmission group (for example, the link is adjusted to connect to a different adjacent node).
If you stop monitoring the local topology of the node, and then start it again, the status of the old
transmission group (the one previously associated with the link) might be shown as unknown although
the underlying link is shown as unsatisfactory.
The reason this inconsistency exists is that the topology agent does not report the transmission group
status when the new copy of local topology is obtained; therefore, the SNA topology manager leaves
its status marked as unknown.

The SNA topology manager shows the old transmission group associated with the link because it does
not know that the link has been assigned to another TG. The old transmission group is deleted by the
SNA topology manager as soon as the SNA topology manager determines that the link is associated
with another transmission group. Until the link is successfully activated again, the link is still
associated by the SNA topology manager with the old TG.
Ignore the status inconsistency or activate the link.
4. The status of the transmission group is unsatisfactory, the status of the underlying link is unknown,
and the status is not being updated.
The network topology of the subnetwork is being monitored, but the local topology of the nodes is not
being monitored.
The transmission group connects two network nodes. One of the nodes is changed and is no longer a
network node; therefore, updates for the transmission group are not reflected in the network topology
of the subnetwork.
Changes in the status of the link are not sent to the SNA topology manager because the local topology
of the node is not being monitored. Changes in the status of the transmission group are not sent to the
SNA topology manager because the node is not updating the status of the transmission group in the
network topology database, and local topology of the node is not being monitored. The status of the
TG matches its status in the network topology database (inactive).
If the local topology of the node owning the TG is not monitored, the TG is eventually purged from the
topology databases in the network.
Issue the TOPOSNA PURGE command to delete the TG from the NetView management console views.
purging resources.
Monitor the local topology of the node owning the TG and link to obtain the status of the TG and link.
The TG is eventually purged from the topology databases in the network.
After that, if the local topology of the node owning the TG is not monitored, the status of the TG will be
unknown.
5. The status of a transmission group or TG circuit is inconsistent with the status of the underlying link.
The SNA topology manager shows the link associated with a TG using the information last received for
that link and TG.
In some cases, the link shown might not be associated with the TG any more. If this happens, the
status of transmission groups (and their associated transmission group circuits) might not be
consistent with the status of the underlying link (as shown by the SNA topology manager). This
scenario is similar to the previous scenario in that it involves a transmission group between two
network nodes, but in this case the TG no longer exists.
The configuration of the node changed so that the link is now associated with another transmission
group (for example, the link is adjusted to connect to a different adjacent node). The old transmission
group (the one previously associated with the TG) no longer exists.
APPN does not delete resources from the network topology, explicitly. It deletes resources if an
update is not received for the resource within a set period of time (usually 15 days). Even after the
time limit, the resource can still be in the network topology database (see “Unexpected resources are
displayed” on page 368).
Therefore, the status of the TG reflects its status in the network topology database (probably unknown
or unsatisfactory). The status of the link reflects the status received from the topology agent. As soon
as the link is activated, the SNA topology manager determines that the link is associated with a new
TG, and no longer shows the link as being associated with the old TG.
Eventually the old TG is purged from the topology databases in the network. Issue the TOPOSNA
PURGE command to delete the old TG from the NetView management console views. The
transmission group is deleted when the TOPOSNA PURGE command is issued, but only if APPN has
purged the TG from the network topology databases in the network.
purging resources.
6. The customized status of a resource is incorrect.
Check the NetView log for the following messages:

WITH ENTRY 'record'


VALUE 'value'





OBJECT CLASS class


class

CLASS class
FLB673W SNA TOPOLOGY MANAGER ENCOUNTERED AN ERROR WHILE PROCESSING THE

OSI STATUS OBJECT-INDEPENDENT METHOD name

DISPLAY STATUS OBJECT-INDEPENDENT METHOD name

STATUS RESOLUTION OBJECT-INDEPENDENT METHOD name

EXCEPTION VIEW OBJECT-INDEPENDENT METHOD name


'viewname:'
If any of these messages are found in the log, use the NetView online help facility for the message to
find more information about how to correct the problem.
If the status is other than unknown, determine whether the OSI to DisplayStatus mapping specified in
the FLBOSIDS and FLBSRT tables is correct for the resource or the class of the resource.

If the OSI to DisplayStatus mapping is not what is expected, correct the problem and refresh the table
using the TOPOSNA REFRESH command.
For more information about status mapping and the TOPOSNA REFRESH command, refer to the IBM Z
NetView SNA Topology Manager Implementation Guide and to the NetView online help facility.
Aggregate resource status incorrect or not being updated

The status of aggregate resources is computed using the status of all resources that aggregate into that
resource. For SNA topology manager, the aggregate resources and the resources that contribute to their
aggregation status are:
• nnDomain objects (APPN domain of a network node)
The nnDomain object is used to represent the status of the network node and the resources in its
domain. The resources that contribute to the aggregation status of the nnDomain object are:
– The network node whose domain is represented by the nnDomain object.
– All TG circuits that support CP-CP sessions used to connect the network node to its served end
nodes.
– All end nodes for which the network node provides network node services.
• interDomain Circuits (all TG circuits between two network nodes)
The interDomain circuit object is used to represent the status of the connection between network nodes
as it relates to the calculation of session routes. The resources that contribute to the aggregation status
of the interDomain Circuit object are the TG circuits that support CP-CP sessions used to connect the
two network nodes. The network nodes can be in the same subnetwork or different subnetworks.
• nnDomainNetwork objects (APPN subnetwork)
The nnDomainNetwork object is used to represent the status of the session routing capability of the
APPN subnetwork. The aggregate objects that contribute to the aggregation status of the
nnDomainNetwork object are as follows:
– All nnDomain objects in the APPN subnetwork
– All interDomain Circuit objects used to connect the nnDomain objects in the subnetwork
• interDomainNetwork Circuits (all inter-subnetwork links between two subnetworks)
Intersubnetwork links are TG circuits used to connect border nodes in one subnetwork to a network
node or border node in another subnetwork. They are used to route session requests between
subnetworks. They are not TG circuits that are used to provide APPN casual connections between a
network node in one subnetwork and an end node in another subnetwork. Also, they are not TG circuits
used for LEN connections between nodes in two subnetworks.
The resources that contribute to the aggregation status of the interDomainNetwork Circuit object are all
the interDomain Circuit objects that connect nnDomain objects in different subnetworks.
• nnDomainNetworkCluster object (APPN network)
The nnDomainNetworkCluster object is used to represent the status of the session routing capability of
the entire APPN network. The aggregate objects that contribute to the aggregation status of the
nnDomainNetworkCluster object are:
– All nnDomainNetwork objects
– All interDomainNetwork Circuit objects
These objects are only aggregated into the status of the nnDomainNetworkCluster object if the
AGGREGATE_TO_CLUSTER=YES is specified in the FLBSYSD file.
Table 140. Aggregate Resource Status
Aggregate resource status is not being updated because Page
Status of the aggregate resource is unknown. “Status of the Aggregate Resource Is unknown” on
page 362
Status of the aggregate resource is known, but incorrect. “Status of the Aggregate Resource Is known but
incorrect” on page 362
Status of the Aggregate Resource Is unknown

Investigate the status of the real resources that contribute to the status of the aggregation objects. If
some of the status values for these resources is unknown, issue the monitor commands needed to obtain
the required status.
Some of the resources displayed when you request more detail of an aggregate object with unknown
status might have a status value other than unknown. Some of the resources shown in the generated view
might not aggregate their status into the status of the aggregate object.
For example, an interDomain Circuit object displays all TG circuits between two network nodes. If none of
the TG circuits support CP-CP sessions, the status of the interDomain Circuit object is unknown, even
though the status of the TG circuits might be different.
Another example is the status of the nnDomainNetworkCluster object will be unknown unless you change
the settings in the FLBSYSD file.
Status of the Aggregate Resource Is known but incorrect

Investigate the status of the real resources that contribute to the status of the aggregation objects.
Some of the resources displayed when you request that more detail of an aggregate object might not
aggregate their status into the status of the aggregate object. The aggregate status of the aggregate
object is set using only the status of the objects that contribute to the aggregation of that object.
The setting of the status of the aggregate object also depends on the settings of the aggregation
thresholds for that object.
If you suspect the status to be incorrect, investigate the settings of the aggregate thresholds for the
object in question. You might have set the aggregation thresholds to values that conflict with one another.
For example, the unknown aggregation threshold level is set to 100%. This means that the status of the
aggregate threshold is set only to unknown when the status of all aggregated objects is unknown. The
degraded aggregation threshold is set to 2, which means the status of the aggregate threshold is set to
degraded when the status of two or more of the aggregated resources is unsatisfactory. If two resources
aggregate to a resource, one with unknown status and the other with unsatisfactory status, a conflict
arises, because the current values for the underlying resources do not fit any of the aggregation
thresholds defined for the object.
NetView management console sets the status of aggregate resources to satisfactory when conflicts such
as these are detected.
NetView management console indicates to the NetView management console operators that it suspects a
threshold inconsistency, such as the one described or when not enough resources contribute their status
to the aggregation resource, by the representation of the object at the NetView management console
workstation. NetView management console link resources (resources that connect other resources) are
shown as dashed lines, and NetView management console node resources are shown with a
crosshatched symbol.
View of Topology Objects is not available for display

Views of topology objects expected to be available are no longer available for display.

Views of topology objects are created when you request more detail for a SNA topology manager object.
In most cases, the object is an aggregate resource. The objects shown include all objects represented by
the aggregate object, including those that do not aggregate their status. The object can represent a real
resource also, such as a node or TG circuit object.
The views generated by the SNA topology manager, and the objects they contain, are described in the
IBM Z NetView SNA Topology Manager Implementation Guide.
NetView management console views stay open until one of the following occurs:
• The NetView management console operator closes the view.
• The object used to generate the view is purged from the RODM data cache.
• All of the objects in the view are purged.
See “Objects unexpectedly purged” on page 350 for more information about purging and recovering
objects.
Table 141. Displaying Topology Objects

Type of View Page
InterDomainNetworkCircuit “InterDomainNetworkCircuit view” on page 363
NnDomainNetwork “NnDomainNetwork view” on page 363
InterDomainCircuit View “InterDomainCircuit view” on page 364
NnDomain “NnDomain view” on page 364
SnaLocalTopology “SnaLocalTopology view” on page 365
Link-Port “Link-Port view” on page 365
Real Resource View “Real resource views” on page 365
InterDomainNetworkCircuit view
An interDomainNetworkCircuit view is generated by requesting more detail of an
interDomainNetworkCircuit object. The interDomainNetworkCircuit object is used to represent an
intersubnetwork link between two APPN subnetworks.
Intersubnetwork links are TG circuits used to connect border nodes in one subnetwork to a network node
or border node in another subnetwork. They are used to route session requests between subnetworks.
They are not TG circuits used to provide APPN casual connections between a network node in one
subnetwork and an end node in another subnetwork. Also, they are not TG circuits used for LEN
connections between nodes in two subnetworks.
The resources that are shown in this view are all the interDomainCircuit objects that connect nnDomain
objects in different subnetworks.
This view is not displayed if all the interDomainCircuit objects shown in the view are purged. See “Objects
unexpectedly purged” on page 350 for more information about purging and recovering objects.
NnDomainNetwork view
An nnDomainNetwork view is generated by requesting more detail of an nnDomainNetwork object. The
nnDomainNetwork object is used to represent the status of the session routing capability of the APPN
subnetwork. The resources that are shown in its view are:
• All nnDomain objects in the APPN subnetwork
• All interDomainCircuit objects used to connect the nnDomain objects in the subnetwork
The view might no longer be displayed for one of the following reasons.
• All the resources shown in the view are purged.
To create the view again, monitor the network topology of the subnetwork and request more detail of
the nnDomainNetwork object.
objects.
• The SNA topology manager detected that it was using two nnDomainNetwork objects to represent the
same subnetwork and merged the resources contained in the views into a single view.
As the SNA topology manager monitors the network topology of network nodes, it assumes each
network node being monitored is in a unique subnetwork and creates an nnDomainNetwork object to
represent the subnetwork. When the SNA topology manager discovers that two network nodes being
monitored are a part of the same subnetwork, it merges the nnDomainNetwork objects into a single
nnDomainNetwork object containing all the resources that were contained in both views. It might take
the SNA topology manager a noticeable amount of time to recognize the connection. The links providing
the connection might be inactive, or other links in the subnetwork might be inactive such that the
connected node information is considered unreliable by the SNA topology manager.
Locate the nnDomainNetwork object containing the merged network information and request more
detail to build the view if the view is not already open. The network ID in the DisplayResourceName
attribute of the merged nnDomainNetwork object is the same as the network ID of the deleted
nnDomainNetwork object.
InterDomainCircuit view
The interDomainCircuit view is generated by requesting more detail of an interDomainCircuit object. The
interDomainCircuit object is used to represent the status of the connection between network nodes. The
resources that are shown in an interDomainCircuit view are all the TG circuits used to connect the two
network nodes. The network nodes can be in the same subnetwork or different subnetworks.
The interDomainCircuit view is no longer displayed if all TG circuits shown in the view are purged or if the
class of any network node connected by the TG circuits was changed from a network node to another
node type.
Unless a connection between the two network nodes no longer exists or one of the nodes is no longer a
network node, monitoring the network topology of the subnetwork containing the network node and
requesting more detail of the interDomain Circuit object will create the view again. See “Objects
unexpectedly purged” on page 350 for more information about purging and recovering objects.
NnDomain view
An nnDomain view is generated by requesting more detail of an nnDomain object. The nnDomain object is
used to represent the status of the network node and the resources in its domain. The resources that are
shown in an nnDomain view are:
• The network node whose domain is represented by the nnDomain object
• All TG circuits that support CP-CP sessions used to connect the network node to its served end nodes
• All end nodes for which the network node provides network node services
The nnDomain view is no longer displayed if one of the following is true:
• All resources shown in the view are purged.
• The network node is purged.
• The class of the network node was changed from a network node to another node type.
See “Objects unexpectedly purged” on page 350 for more information purging and recovering objects.
Unless the node no longer exists or is no longer a network node, monitoring the network topology of the
subnetwork containing the network node and requesting more detail of the nnDomain object creates the
view again.

SnaLocalTopology view
An snaLocalTopology view is generated by requesting more detail of a node object. The snaLocalTopology
object is used to represent all resources owned by the node and all resources the node is aware of (the
local topology of the node). Requesting more detail of a node displays a view containing an
snaLocalTopology object.
Requesting more detail of this object shows the resources associated with the node. The intermediate
view is generated to circumvent the NetView management console restriction that a more detail view
cannot contain the parent resource used to build the view. To show a node as part of its local topology,
the intermediate view is used.
The following resources are shown:
• The node
• All TG circuits connected to the node (the circuits that contain the TGs owned by the node)
• All adjacent nodes connected to the node
The links and ports owned by the node are shown in the Link-Port view. Requesting more detail of a node
creates both these views.
This view is not displayed if all resources shown in the view are purged or if the node is purged. Also, this
view might to be displayed if the class of the node was changed.
Usually, monitoring the local topology of the node and requesting more detail of the node object creates
the view again. See “Objects unexpectedly purged” on page 350 for more information about purging and
recovering objects.
Link-Port view
A Link-Port view is generated by requesting more detail of a node object. The Link-Port view shows all
links and ports owned by the node (obtained from the local topology of the node).
The resources that are shown in its view are:
• All ports owned by the node
• All links owned by the node
The node, its associated TG circuits, and adjacent nodes are shown in the snaLocalTopology view.
Requesting more detail of a node creates both these views.
This view is not displayed if all links and ports associated with the node are purged or if the node is
purged. Also, this view might not be displayed if the class of the node was changed.
objects. Usually, monitoring the local topology of the node and requesting more detail of the node object
creates the view again.
Real resource views

Other views can be obtained by requesting more detail of a real object other than the snaLocalTopology
and Link-Port views (obtained from the node object) as follows:
View Name
Description
TG circuit
A TG circuit view is generated by requesting more detail of a TG circuit. The TG circuit view shows the
TGs that make up the TG circuit. This view is no longer displayed if the TGs that make up the TG circuit
are purged.
TG
A TG view is generated by requesting more detail of a TG. The TG view shows the link associated with
the TG. This view is no longer displayed if the link associated with the TG is purged, if the TG is
purged, or if the link is associated with another TG and this TG is purged.
Link
A link view is generated by requesting more detail of a link. The link view shows the port associated
with the link. This view is no longer displayed if the port associated with the link is purged or if the link
is purged.
objects.
Subnetworks shown in the same nnDomainNetwork view

The SNA topology manager represents a subnetwork with an nnDomainNetwork object. The SNA topology
manager links all network nodes (represented as nnDomain objects) in the subnetwork and all TGs in the
subnetwork used to connect network nodes (by interDomainCircuit objects) to this nnDomainNetwork
object.
The view generated by requesting more detail of an nnDomainNetwork object includes all these
resources.
As the SNA topology manager monitors the network topology of network nodes, it assumes that each
network node being monitored is in a unique subnetwork and creates an nnDomainNetwork object to
represent the subnetwork.
When the SNA topology manager discovers that two network nodes being monitored are a part of the
same subnetwork, it merges the nnDomainNetwork objects into a single nnDomainNetwork object
containing all the resources contained in both views. The SNA topology manager merges the
nnDomainNetwork objects when it detects an active link connecting network nodes in each subnetwork
that supports CP-CP sessions.
This link enables the two subnetworks to exchange topology information between the network nodes in
each subnetwork, effectively creating a single subnetwork.
When the SNA topology manager has merged two subnetworks, it does not split them into separate
subnetworks. Even though the links that connected the subnetworks are deactivated or purged, the SNA
topology manager assumes the resources form disjointed parts of the same subnetwork.
Therefore, as soon as two subnetworks are connected by a CP-CP session, they are merged and remain
merged until all resources in the subnetworks are purged.
1. Verify that the subnetworks are separate subnetworks.
Network conditions can make a subnetwork seem to be two or more separate subnetworks,
depending on which links are inactive. This might be a temporary condition causing the subnetwork to
be shown as several disjointed pieces.
2. Decide if you want to separate the subnetworks into separate views.
Correcting the problem involves purging all resources, which make up the subnetworks, from the
RODM data cache and then using monitor operations to enable the SNA topology manager to discover
or learn the subnetwork information again. This can be a disruptive procedure.
3. If you decide to separate the subnetworks, stop all monitor operations.
All resources in the nnDomainNetwork views must be purged. Before purging the resources, all
monitor operations that report any of the resources must be stopped. That includes these:
• The network topology of all network nodes in the subnetwork
• The local topology of all network nodes in the subnetwork
• The local topology of all nodes connected to the network nodes, including all served end nodes
The status of all network nodes (and the nnDomain objects) must be unknown. Until then, there are
monitor operations that must be stopped.
Note:

a. Instead of stopping all monitor operations, it might be easier to stop and cold-start the SNA
topology manager and then reissue all monitor operations to learn the network again. Cold-starting
the SNA topology manager purges all resources. The entire network must be monitored again to
rebuild the NetView management console views.
b. Depending on the network, this might be easier than stopping all monitors and explicitly purging all
resources related to the subnetwork.
• If you cold-start the SNA topology manager, skip step “4” on page 367.
Attention: Cold-starting the SNA topology manager purges all data in the RODM data cache
created by the SNA topology manager. All resources created by the SNA topology manager
are removed from the NetView management console views and must be discovered or
learned again.
4. Purge all resources in the subnetwork.
Issue a TOPOSNA PURGE,PURGDAYS=0 command to purge the resources. Zero is specified for
PURGDAYS because the status of the resources was just updated to unknown. The nnDomainNetwork
object representing the subnetwork must be deleted as a result of the command. If the object has not
purged, not all of the required monitor operations have been stopped.
Return to step “3” on page 366 and stop the required monitor operations.
Note:
a. When a TOPOSNA PURGE command is issued, the SNA topology manager purges all objects that
have not been updated within the specified time period and are not currently being monitored.
b. A TOPOSNA PURGE,PURGDAYS=0 command purges all resources that are not currently being
monitored, including resources in other subnetworks. These resources are created again when the
appropriate monitor operations are started, if the resources still exist.
5. Issue the monitor operations required to relearn the topology of the network.
After purging the nnDomainNetwork, issue the appropriate TOPOSNA MONITOR commands to
rediscover or learn all the resources that were purged. The SNA topology manager builds separate
nnDomainNetwork objects to represent the separate subnetworks. If the SNA topology manager
builds a single subnetwork again, the disjointed sections are part of the same subnetwork.
Class of Node Object does not match node type

The class of the node objects created by the SNA topology manager are based on the node types
contained in the updates received from the network for the nodes. The topology agents report the type of
nodes based on the information the monitored node has about the nodes.
In some cases, this information does not specify the type of the node being reported for example:
• Local topology reports for adjacent nodes where the link between the nodes is not active
The reported adjacent node information is the representation of the node from the perspective of the
local node and might not be correct.
• Local topology reports for adjacent network nodes or end nodes where the link indicates a LEN-level
connection
Even after the link to an adjacent node is activated, the reported node type might still be inaccurate.
Nodes can define that a link to an adjacent node is to be treated as a LEN-level connection (no CP-CP
sessions or APPN network services). The node reports the adjacent node as a LEN node because that is
how the node appears to the node being monitored.
• Border nodes are reported as end nodes by the network nodes in the adjacent subnetwork (to which the
border nodes are connected). This disparity is a result of APPN protocols, where border nodes appear to
the adjacent network node as casually-connected end nodes.
• The SNA topology manager has out-of-date information about a node
The SNA topology manager displays a node using the last reliable information it received about the
node. If the configuration of the node was changed, the node must be monitored (either directly or
indirectly) for the SNA topology manager to learn of the change
.
• The network topology of a subnetwork is erroneously reporting a node as a network node.
Even after a node has been changed from a network node to another node type, the network topology
databases of the network nodes in the subnetwork might still represent the node as a network node and
report the node as a network node in the network topology of the node.
See “Status of a nonexistent resource is not unknown” on page 371 for more information.
• The network topology from a migrationDataHost node created as a t5Node object
The VTAM agent on the migrationDataHost node reports only the CDRMs during network topology, and
does not report the type of this node. The SNA topology manager creates this node as a t5Node object.
The SNA topology manager also creates a t5Node for each active CDRM reported with a realSSCPname,
the class of these nodes might not be accurate.
Collect the local topology to reflect the correct class of these nodes.
• The LUCOL monitor from a VTAM agent is created as an snaNode
The SNA topology manager creates a snaNode for the VTAM agent during the monitoring of the LU
collection if it is not monitoring local or network topology from this VTAM agent.
Collect the local topology to reflect the correct class of this node.
To correct this problem, perform the following steps:
1. Monitor the local topology of the node that is incorrect.
This local topology monitor updates the class of the node to the correct node type.
Of course, if the node does not have the topology agent installed, the SNA topology manager cannot
monitor the local topology of the node. For most incorrect node type problems, when the correct node
type is learned, the local topology monitor can be stopped.
2. Monitor the local topology of a node adjacent to the incorrect node.
This local topology monitor might solve the problem, depending on how the node is defined by the
node being monitored.
In addition, a link between the node being monitored and the incorrect node must be active so that the
monitored node receives the most up-to-date information about the node. As with monitoring the
node, when the correct node type is known, the local topology monitor can be stopped.
3. Remove the erroneous node definition from the network topology databases of the network nodes in
the subnetwork.
Perform this step only if the node is being shown as a network node because it is being reported as
such in the network topology of one or more of the network nodes in the subnetwork.
First, attempt to correct the problem using the previous steps. If those steps do not solve the problem,
see “Status of a nonexistent resource is not unknown” on page 371.
Unexpected resources are displayed

Resources are added to the RODM data cache and shown in the NetView management console views
when the SNA topology manager receives an update identifying the new resource. The SNA topology
manager creates and displays all resources received from the topology agents, with the following
exceptions:
• Network topology resources might not be created if an active path does not exist between any of the
nodes adjacent to the node owning the resource and the node being monitored (see “Resources are not
shown in the Views” on page 340).

• The SNA topology manager automatically creates node objects when it receives a TG or link update
identifying the adjacent node.
After the SNA topology manager creates a resource, the resource remains in the RODM data cache (and is
displayed) until it is purged using the TOPOSNA PURGE command or the topology agent informs the SNA
topology manager that the resource is deleted. Any resource can be purged by the TOPOSNA PURGE
command, as long as the resource is not currently being monitored.
A topology agent sends updates to delete dynamically created links and their associated TGs when the
link is deactivated. These updates are only sent as a part of the local topology of the node.
For more information about updating and interpreting resource status, refer to the IBM Z NetView SNA
To quickly find information in this section, see the following table:
Table 142. Displaying Unexpected Resources

Unexpected resources are displayed in views because Page
Status of a resource is shown as unknown. “Status of the resource Is shown as unknown” on
page 370
Status of an existing resource is not unknown. “Status of an existing resource is not unknown” on
page 370
Status of a nonexistent resource is not unknown. “Status of a nonexistent resource is not unknown”
on page 371
Unexpected aggregate resources are in views. “Unexpected aggregate resources in views” on
page 371
Resources reported by the agent nodes

For local topology, the resources reported by the agent node are those that are defined and owned by the
node. It is likely that all of the resources reported in the local topology of a node do exist.
Some of the reported resources might no longer be used, but as long as a definition exists for them, the
node reports them to the SNA topology manager.
These resources include:
• The node being monitored
• All links owned by the node being monitored
• All ports owned by the node being monitored
• All TGs owned by the node being monitored
• Nodes adjacent to the node being monitored
For network topology, the topology agent reports all resources in the network topology database. Some of
the resources that are reported by the node probably are not owned by that node, but are contained in the
network topology database of the node.
APPN propagates the status of all network nodes, and the TGs between network nodes to all other
network nodes in the same subnetwork.
These resources include:
• All network nodes in the subnetwork
• All TGs between the network nodes
• For LU topology, the VTAM topology agents report the collection of LUs associated with specific nodes,
including:
– logical units
– cross domain resources
– LU groups
To summarize:
• Links and ports are reported only as part of the local topology of the owning node.
• All nodes are reported as part of their local topology and as part of the local topology of any of their
adjacent nodes. Network nodes are also reported in the network topology of any network node in the
same subnetwork.
• All TGs are reported as part of the local topology of the owning node. TGs between network nodes are
also reported in the network topology of any network node in the same subnetwork.
• LU topology can only be collected from VTAM topology agents.
Status of the resource Is shown as unknown

If the status of the resource is unknown, the SNA topology manager is not receiving status updates for the
resource. The SNA topology manager does not receive status updates for resources it is not currently
monitoring. It also does not receive status updates when the status updates are not delivered because
network conditions prevent the receipt of the update by an agent node or the delivery of the update to the
SNA topology manager.
To solve this problem, issue the TOPOSNA PURGE command to delete the resource from the RODM data
cache and the NetView management console views. If the resource is not purged, see “Objects are not
purged” on page 347.
Status of an existing resource is not unknown

Display the local topology of the node owning the resource. The resource is still defined if the status of
the resource is not unknown. Exceptions are:
• Network nodes adjacent to the owning node can be reported by the network topology of any network
node.
• TGs between the node and any network node can also be reported by network topology if the node is a
network node.
For the adjacent network nodes and TGs between network nodes, the resource is defined if the network
topology is not being monitored. If the network topology is being monitored, use the following methods to
determine whether the resource is defined:
• Stop monitoring the network topology of the subnetwork.
The resource is defined if the status of the resource is not changed to unknown.
• Stop monitoring the local topology of the subnetwork.
The resource is defined if the status of the resource changes to unknown. If the status of the resource
does not change, the resource is being reported either:
– By the network topology of the subnetwork, which means it might or might not be defined
– by the local topology of another node, which means it is defined
• Query the local topology of the node using a local command.
If the resource is not defined, proceed to “Status of a nonexistent resource is not unknown” on page 371.
The resource is defined in the network; it is shown in the NetView management console views. To remove
the resource, do the following steps:
1. Check with your network administrator to ensure that the resource is no longer being used.
2. Modify the configuration of the agent node owning the resource by removing the definition of the
resource.
3. Stop and start the communications support at the agent node if the configuration update cannot be
made dynamically.
4. If the local topology of the node is being monitored, stop and start the monitor operation.

This enables the SNA topology manager to learn that the resource no longer exists.
5. If the status of the resource is unknown, the resource was successfully deleted and the SNA topology
manager is no longer receiving updates for the resource.
Issue the TOPOSNA PURGE command to delete the resource from the RODM data cache and the
NetView management console views. If the resource is not purged, see “Objects are not purged” on
page 347.
Status of a nonexistent resource is not unknown

This problem was probably caused by the resource being reported in the network topology of one or more
of the network nodes in the subnetwork.
APPN does not send commands to remove resources from the APPN network node topology databases
when a resource is deleted. Each APPN network node removes a resource from its topology database if an
update is not received for the resource within a set period (usually 15 days). Until this time period expires,
the resource remains in the APPN network topology database of the node and is reported to the SNA
topology manager, even though the resource no longer exists.
Nonexistent resources can remain in the network topology database of a network node for much longer.
When an APPN network node activates a CP-CP session with an adjacent node, the network node
compares its topology information to that of the adjacent node. If the network node determines that its
topology information is more recent, that information is sent to the adjacent node.
The entire content of the database is sent, including resources that no longer exist in the network but
have not yet been aged out of the network node database. Depending on the content of the information,
some of these updates might be propagated throughout the network, updating the time stamps of the
resources within the database of each node. Updates for nonexistent resources can be propagated in this
way, extending the amount of time required to age the resource out of the network topology database.
In some networks, the resources are not removed from the databases, because new network nodes are
being added to the network or network nodes relearn their topology databases.
1. Ask your network administrator to remove the resource definition from the network topology
databases of the network nodes.
It is usually difficult to remove the resource definition from all the network nodes. APPN propagates
the contents of the network topology databases, so the network topology databases of every network
node in the subnetwork must be updated at the same time.
2. Stop all network topology monitor operations, and restart the monitor operations after all monitors
have been stopped.
This enables the SNA topology manager to learn the resource no longer exists.
3. If the status of the resource is not unknown, the resource either exists in the network, or it was not
successfully removed from all network topology databases.
“Status of an existing resource is not unknown” on page 370 suggests procedures that can be used to
remove existing resources.
4. If the status of the resource is unknown, the resource was successfully deleted and the SNA topology
manager is no longer receiving updates for it.
Issue the TOPOSNA PURGE command to delete the resource from the RODM data cache and the
NetView management console views. If the resource is not purged, see “Objects are not purged” on
page 347.
Unexpected aggregate resources in views

Aggregate resources are created to represent a collection of real resources. To determine why an
aggregate resource is being displayed, investigate the underlying real resources.
A common problem is that unexpected nnDomainNetwork objects are displayed. These objects are
created to represent the objects obtained by monitoring the network topology of the nodes in a
subnetwork. Network topology can report resources that no longer exist, which can cause the creation of
extraneous nnDomainNetwork objects.
See “Status of a nonexistent resource is not unknown” on page 371 for information about network
topology that contains incorrect data.
Network topology can also report old information for resources. For example, if a network node was
changed to an end node, the network topology databases of the network nodes in the subnetwork will
probably continue to represent the node as a network node. The SNA topology manager shows the node
as a network node unless it discovers that the node is really an end node (by monitoring the local
topology of the node). The SNA topology manager might create extraneous nnDomainNetwork objects to
represent a separate subnetwork containing the incorrectly represented node. The node is not a network
node, so the network topology does not contain any active connections to the node with active CP-CP
sessions; the SNA topology manager assumes that the node is in a separate subnetwork.
1. See “Status of a nonexistent resource is not unknown” on page 371 for suggested ways to eliminate
extraneous information from the network topology databases of the network nodes in the subnetwork.
2. If a node is incorrectly being shown as a network node, monitor the local topology of the node or the
serving network node of the node.
The SNA topology manager detects that the node is no longer a network node and updates the node in
the RODM data cache. It deletes the extraneous nnDomain and nnDomainNetwork objects if they do
not contain any other resources.
See “Class of Node Object does not match node type” on page 367 for more information.
Exception view resource displays are incorrect

The exception view might be incorrect because of a customization table error. Check the log for one or
more of the following messages:

WITH ENTRY 'record'


VALUE 'value'





OBJECT CLASS class


class

CLASS class

OSI STATUS OBJECT-INDEPENDENT METHOD name

DISPLAY STATUS OBJECT-INDEPENDENT METHOD name

STATUS RESOLUTION OBJECT-INDEPENDENT METHOD name

EXCEPTION VIEW OBJECT-INDEPENDENT METHOD name


'viewname:'
If any of these messages are found in the log, use the NetView online help facility for the message to find
more information about how to correct the problem. Refer to the IBM Z NetView SNA Topology Manager
Implementation Guide for information.
Chapter 22. Diagnostic tools for the SNA Topology
Manager
This chapter describes the diagnostic tools that can be used to isolate and identify problems detected
and possibly caused by the SNA topology manager. The following is a list of the diagnostic tools described
in this chapter. These diagnostic tools are specific to the topology manager or have special usage
considerations:
• Messages
• Log Entries
• Traces
• TOPOSNA LISTxxxx requests
Other diagnostic tools that can be used to help diagnose problems with the topology manager include:
• The interactive problem control system (IPCS)
• The network log
• The TASKMON command
• The TASKUTIL command
• The NetView internal trace
• VTAM CMIP traces
• The program-to-program interface (PPI) trace facility for NetView
These tools are described in Chapter 6, “Diagnostic tools for the NetView program,” on page 75.

Topology manager IBM Z NetView SNA Topology Manager
Implementation Guide
SNA Topology Manager messages

All of the topology manager tasks and command processors can log messages. The messages are sent to
the operator who initiated the action that generated the message, and logged in the NetView network log.
Messages that are not related to an operator request are also logged. This includes messages generated
while processing inbound data from the network, activation, initialization, and deactivation messages, and
asynchronous errors. Some of these messages, such as the activation and deactivation messages, and
specific error messages, are also sent to the authorized receiver.
All messages issued by the topology manager use the prefix FLB. All existing message utilities, such as
automation, the ASSIGN command, and the network log browse utility (BROWSE command) can be used
with topology manager messages. The identity of the component that generated the message is usually
within the message text, but the message numbers can also be used to determine the component.
The message numbers have been assigned so that each component uses a specific range. The topology
manager is assigned 400 through 599 and 620 through 700. The topology manager can also issue
message numbers 600 through 619.
Messages are issued whenever events occur that might require operator attention, including useful
informational messages. Many of the messages are not related to a particular operator request because
most of the time the topology manager is processing inbound data and performing automatically
generated operations. Operators can check the network log when they suspect a problem might exist or
when they see unexpected results.

Online help exists for all topology manager messages. To view this help information, issue the HELP
command followed by the message number (including the FLB prefix) at a NetView operator console. The
help information for the message is displayed as one or more panels. The help information includes:
• A copy of the message text
• An explanation of why the message was generated
• An explanation of any message variables (variable data provided in the message to clarify the event and
its source)
• An explanation of any significant actions the topology manager performs as a result of the event
• Any recommended responses (by the operator or others)
SNA Topology Manager log entries

The topology manager does not necessarily issue a message every time an event occurs. For example, if
the topology manager retries a monitor operation 10 times, it issues only one message indicating that it is
retrying the operation. In many cases, the topology manager creates a log entry to describe the event.
Log entries identify the specific event, along with all related information. In addition, the topology
manager creates log entries whenever an error is detected, even if a message is also generated. These log
entries contain detailed information that describes the error in greater detail, and provide any related
information that can be used to diagnose the problem. For example, in the case where the topology
manager retries a monitor operation 10 times, one retry message is issued, but 10 log entries are created,
each one containing information about why a particular attempt failed.
The topology manager log entries are actually messages containing the log information. There are three
messages used to indicate the creation of a log entry. They correspond to the type of event being logged
(an Error, Warning, or Informational event). The message numbers used are the same for each type of log
entry as follows:
• FLB600E for logging errors, including retry errors, along with any related error information
• FLB601W for logging warning events that might require operator attention, along with any related
information
• FLB602I for logging informational events
In addition to these messages, the data associated with a log entry is provided using messages FLB603I
and FLB604I. These messages are placed in the network log. They are also sent to the operator
associated with the topology manager task that created the log entry. These messages are not intended
to be viewed by operators, but are issued so that automation table entries can be created to interpret
them, or an ASSIGN command can be used to route them.
You can route all of these messages to an operator station that is set up specifically to track the events
logged by the topology manager components. The sample automation table entries in the FLBAUT file
provided with topology manager includes entries to disable the display of these messages. Use the
automation table entries that are supplied in the sample, or else create a set of equivalent automation
table entries.
SNA Topology Manager log record formats
NOTICE
For any topology manager log entry containing a major-minor code that is not described in this
section, contact IBM Software Support.
Each log entry contains a probe ID, major code, minor code, and log data size as follows:
Probe ID
This identifies which specific section of code created the log entry. This ID is used mostly by IBM
Software Support when diagnosing problems with the topology manager program. It can also be used
by customers to identify and correlate multiple occurrences of the same event. The same event can

be logged in several different sections of a program, with each event having a different probe ID, and
the same major and minor codes.
Major code
This code identifies the component that detected the event (which is probably an error). This can be
one of the topology manager components, a NetView program system call issued by one of the
topology manager components, or one of the utility functions used by the topology manager
components. The following major codes are used by the topology manager components:
Code
Description
22
The event was reported by one of the NetView program system calls invoked by a component of
the topology manager.
78
The event was detected by the topology manager task or command processor.
79
The event was detected by one of the topology manager utility functions (such as the interface to
the NetView program message facilities).
This code, when combined with the minor code, uniquely identifies the event being logged.
Minor code
This code identifies the type of event being logged. Each component has its own set of events, so this
code, when combined with the major code, identifies the event being logged.
A notation convention is used to identify log entries in this book. The major and minor codes are
combined, separated by a hyphen (-) or a slash (/). For example, the log entry with major code 78 and
minor code 25 is identified as log entry 78-25 or as log entry 78/25.
Log data size
The amount of additional information if it is related to the event.
The topology manager components can include up to 4096 bytes of log data within a log entry. Log
entries with data are placed in the network log using a multiple-line message, with each message
containing up to 32 bytes of log data (64 hexadecimal characters). All of the messages associated with a
log entry (all parts of the multiline message) use the same probe ID. Specifically:
• Log entries with no additional data are created using one message (either FLB600E, FLB601W, or
FLB602I):
FLB600E PROBEID 0B510511 MAJOR CODE 78 MINOR CODE 59 LOG DATA SIZE : 0 BYTES
• Log entries with 1–32 bytes of additional data are created using two messages. The first message
(FLB600E, FLB601W, or FLB602I), identifies the event being logged, and the amount of additional data.
The last message (FLB604I) provides the additional data. Both messages use the same probe ID:
FLB604I PROBEID 0B520247 DATA 0000: 0001005340B90EA0000700B3
• Log entries with greater than 32 bytes of additional data are created using multiple messages, with the
number of messages dependent on the amount of additional data. The first message (FLB600E,
FLB601W, or FLB602I), identifies the event being logged, and the amount of additional data. This
message is followed by one or more FLB603I messages, which provide 32 bytes of additional data
each. As many FLB603I messages are logged as needed to provide all but the last 1–32 bytes of
additional data associated with the log entry. The last message (FLB604I) provides the last 1–32 bytes
of additional data, and signifies the end of messages associated with the log entry. All messages use the
same probe ID. Following is an example of a log entry:
FLB603I PROBEID 0B510514 DATA 0000: 00000005D5C5E3C14BC1F5F7D4000000
FLB603I PROBEID 0B510514 DATA 0010: 00000000000000000000000000000000
Chapter 22. Diagnostic tools for the SNA Topology Manager 377
FLB603I PROBEID 0B510514 DATA 0020: 00000000000000000000000000000000
FLB604I PROBEID 0B510514 DATA 0030: 00000005046BD50020000000
The messages FLB603I and FLB604I contain the following information:

Probe ID
This identifies which specific section of code created the log entry. This ID is also used to correlate
the message with all other messages associated with a particular event.
Offset
Specifies the position of the data provided by this message within the overall additional data area
associated with the log entry. This value is a hexadecimal value providing the offset (in bytes) within
the overall additional data area where the data provided by this message is inserted.
Log data
Any additional information that is related to the event. For errors, the log data includes any
information available that helps diagnose why the problem occurred, such as error codes and
parameter values. The format of the log data is specific to each type of event (indicated by the
combination of major and minor codes).
This data is usually shown in hexadecimal, but data that can be easily read (such as node names), is
shown in character format. The character data and hexadecimal data can be interspersed in the log
data. The description of the format of the fields in the log data indicates whether the field contains
character data. If not explicitly stated, the format of the fields in the log data is hexadecimal.
Sometimes the character data does not contain an even number of characters. To make reading of
any subsequent hexadecimal data easier, fields containing an odd number of characters are padded
with periods (.). Remember, the offsets into the data are calculated as hexadecimal data. Two
characters, whether it be hexadecimal or character data, make up one byte of data.
The log data can contain numeric data, such as topology manager error codes. This data is shown in
hexadecimal, except in a few cases where the numbers are shown in decimal format. The descriptions
of the fields indicate when numeric data is shown in decimal.
The example below demonstrates the interspersing of character data with hexadecimal data, and the
representation of numeric data in hexadecimal. The first 16 characters form the node name. The following
data is shown in hexadecimal format, including the last 4 bytes (8 characters), which shows the number
817 in hexadecimal (00000331). The size of the data is shown in bytes, where the size of the 16
character node name is 8 bytes:
FLB600E PROBEID 0B51C0CD MAJOR CODE 78 MINOR CODE 34 LOG DATA SIZE : 20 BYTES
FLB604I PROBEID 0B51C0CD DATA 0000: USIBMNT.NT81I046000000000000000000000331
The example below demonstrates padding character data with a period to align to a byte boundary.
Although no other data follows the character data in the log data, the period is added to make the total
number of characters in the field even (18). The size of the data is shown in bytes, where the size of the
18 character string data is 9 bytes.
FLB604I PROBEID 0B300701 DATA 0000: (result-code 817).
System Interface log entries-Major Code 22
NOTICE
chapter, contact IBM Software Support.
These log entries are created whenever a component of the topology manager receives an unexpected
result from a system function. A system function is a function provided by the NetView program or the
MVS system (for example the generalized trace facility (GTF)). These log entries can be created by any
component of the topology manager. Usually, there are associated log entries that describe the
consequences of the failure. In most cases, the task that detects the problem ends.

22-22 User response
Check for related log entries or messages that provide
Explanation more information about the consequences of this
An unexpected return code was received from the failure. In most cases, the task that called this function
NetView high-level language (HLL) function CNMINFC. ends. Use the return code description and the data
The additional data contains the return code from the contained in the additional data associated with this
CNMINFC function. These return codes are described log entry to determine the cause of the problem. Use
in IBM Z NetView Programming: PL/I and C. this information and the information from related log
entries to correct the problem.
The CNMINFC function reads the contents of a
NetView global variable. The additional data identifies Trace Data
the name of the variable being read.
The format of the additional data provided in the log
User response entry. The offsets are specified in hexadecimal and are
based from the beginning of the log data. The lengths
Check for related log entries or messages that provide are specified in decimal.
more information about the consequences of this
failure. In most cases, the task that called this function Hex Decim Description
ends. Use the return code description and the data Offset al
contained in the additional data associated with this Length
log entry to determine the cause of the problem. Use 0000 4 Return code from the CNMNAMS
this information, and the information from related log
function
entries, to correct the problem.
0004 n For IBM Software Support use
Trace Data
22-24
entry. The offsets are specified in hexadecimal and are
based from the beginning of the log data. The lengths Explanation
are specified in decimal. An unexpected return code was received from the
NetView high-level language (HLL) function
Hex Decim Description CNMSMSG. The additional data contains the return
Offset al code from the CNMSMSG function. These return codes
Length are described in IBM Z NetView Programming: PL/I and
0000 4 Return code from the CNMINFC C.
function The CNMSMSG function is used to send messages, and
0004 8 Name of the NetView variable read send data between the tasks that make up the
topology manager. The additional data identifies the
000C n For IBM Software Support use destination of the data or message, the type of data or
message, and the contents of the data or message that
22-23 cannot be sent.
Explanation User response

An unexpected return code was received from the Check for related log entries or messages that provide
NetView high-level language (HLL) function more information about the consequences of this
CNMNAMS. The additional data contains the return failure. In most cases, the task that called this function
code from the CNMNAMS function. These return codes ends. Use the return code description and the data
are described in IBM Z NetView Programming: PL/I and contained in the additional data associated with this
C. log entry to determine the cause of the problem. Use
The CNMNAMS function allocates, frees, locates, and this information, and the information from related log
reallocates named areas of virtual storage. The entries, to correct the problem.
additional data identifies the actual function, as well
as the name of the virtual storage area. Trace Data
based from the beginning of the log data. The lengths Hex Decim Description
are specified in decimal. Offset al
Length
Hex Decim Description
Offset al log entry and contact IBM
Length Software Support.
0000 4 Return code from the CNMSMSG 0014+ m For IBM Software Support use
function n
22-26
22-25
Explanation
Explanation An unexpected return code was received from the
NetView high-level language (HLL) function CNMGETD.
An unexpected return code was received from the
The additional data contains the return code from the
NetView high-level language (HLL) function CNMVARS.
CNMGETD function. These return codes are described
in IBM Z NetView Programming: PL/I and C.
CNMVARS function. These return codes are described
in IBM Z NetView Programming: PL/I and C. The CNMGETD function is used to read and manipulate
the data on the inbound data queues of the task. The
The CNMVARS function is used to set or retrieve the
data on these queues is sent to the receiving task by
value of a global variable. Global variables are used by
other topology manager tasks and command
the topology manager to preserve information when a
processors. The additional data identifies the type of
task ends, and to exchange information between
operation. It might also identify the origin of the data
tasks. The additional data identifies the global variable
and the contents of the data, depending on the error.
being read, or set, and the type of operation.
User response
User response
failure. In most cases, the task that called this function
ends. Use the return code description and the data
contained in the additional data associated with this
log entry to determine the cause of the problem. Use
this information and the information from related log
Trace Data
Trace Data
are specified in decimal.
Offset al
Offset al
Length
Length
0000 4 Return code from the CNMGETD
0000 4 Return code from the CNMVARS
function
function
0004 16 For IBM Software Support use
0014 n The name of the variable. The 22-27
name is formatted as a NetView
high-level language (HLL) varying Explanation
length field. Record the
information associated with this An unexpected return code was received from the
NetView high-level language (HLL) function CNMSMU.

The additional data contains the return code from the log entry to determine the cause of the problem. Use
CNMSMU function. These return codes are described this information, and the information from related log
in IBM Z NetView Programming: PL/I and C. entries, to correct the problem.
The CNMSMU function is used to send multiple domain
support message units (MDS-MUs) to agent nodes. Trace Data
These MDS-MUs are used to send CMIP requests to The format of the additional data provided in the log
the agent nodes. The additional data identifies the entry. The offsets are specified in hexadecimal and are
data to be sent, the destination of the MDS-MU, and based from the beginning of the log data. The lengths
any other parameters required by the NetView are specified in decimal.
program to send the MDS-MU.
User response Offset al
Length
more information about the consequences of this 0000 4 Return code from the CNMSCOP
failure. In most cases, the task that called this function function
ends. Use the return code description and the data 0004 n For IBM Software Support use
log entry to determine the cause of the problem. Use 22-30
Explanation
Trace Data An unexpected return code was received from the
NetView high-level language (HLL) function CNMCMD.
CNMCMD function. These return codes are described
The CNMCMD function is used to issue a NetView
Hex Decim Description command.
Offset al
Length User response
0000 4 Return code from the CNMSMU Check for related log entries or messages that provide
function more information about the consequences of this
0004 n For IBM Software Support use failure. In most cases, the task that called this function
22-29 contained in the additional data associated with this
Explanation
NetView high-level language (HLL) function CNMSCOP. Trace Data
CNMSCOP function. These return codes are described The format of the additional data provided in the log
in IBM Z NetView Programming: PL/I and C. entry. The offsets are specified in hexadecimal and are
The CNMSCOP function is used to determine whether are specified in decimal.
an operator is authorized to issue a command, specify
a command keyword, or use a particular value for a Hex Decim Description
command keyword. Offset al
Length
User response 0000 4 Return code from the CNMCMD
Check for related log entries or messages that provide function
more information about the consequences of this 0004 n For IBM Software Support use
22-31
Explanation User response
An unexpected return code was received from the Check for related log entries or messages that provide
NetView high-level language (HLL) function CNMLK. more information about the consequences of this
The additional data contains the return code from the failure. In most cases, the task that called this function
CNMLK function. These return codes are described in ends. Use the return code description and the data
IBM Z NetView Programming: PL/I and C. contained in the additional data associated with this
The CNMLK function is used to request, release, or
this information, and information from related log
query the status of a named lock.
User response
Trace Data
log entry to determine the cause of the problem. Use Hex Decim
this information, and the information from related log Offset al
entries, to correct the problem. Length Description
0000 4 Return code from the CNMSUBS
Trace Data
function.
0004 n Data passed to CNMSUBS for
substitution of system symbolics.
22-37
Offset al Explanation
Length
A failure occurred while attempting to issue a NetView
0000 4 Return code from the CNMLK command.
function
0004 8 For IBM Software Support use User response
000C 8 The name of the lock. The name is Record the information associated with this log entry
formatted as a NetView high-level and contact IBM Software Support.
language (HLL) varying length field.
A varying length field consists of a Trace Data
two-byte integer containing the
size of the data in the field, The format of the additional data provided in the log
followed by the data within the entry. The offsets are specified in hexadecimal and are
field. based from the beginning of the log data. The lengths
22-32 Offset al
Length
Explanation 0000 4 An error code used to identify the
problem.
NetView high-level language (HLL) function CNMSUBS.
CNMSUBS function. These return codes are described
The CNMSUBS function is used to request substitution
of symbolics in a data string.

Hex Decim Description The DSIPUSH macro is used to establish recovery
Offset al procedures for the topology manager tasks.
Length
User response
0004 8 A buffer containing the command
to be issued. The buffer is Check for related log entries or messages that provide
formatted as a NetView high-level more information about the consequences of this
language (HLL) varying length field. failure. In most cases, the task that issued this macro
A varying length field consists of a ends. Use the return code description and the data
two-byte integer containing the contained in the additional data associated with this
size of the data in the field, log entry to determine the cause of the problem. Use
followed by the data within the this information, and the information from related log
field. entries, to correct the problem.
22-38 Trace Data

Explanation entry. The offsets are specified in hexadecimal and are
A problem occurred while a topology manager task based from the beginning of the log data. The lengths
was trying to access a global data variable. are specified in decimal.

Record the information associated with this log entry Length
and contact IBM Software Support. 0000 4 Return code from the DSIPUSH
22-39 function
Explanation
An unexpected return code was received from the 22-47
assembler macro DSIWAT. The additional data
contains the return code from the DSIWAT macro. Explanation
These return codes are described in IBM Z NetView An unexpected return code was received invoking a
Programming: Assembler. RODM function using the RODM user application
The DSIWAT macro is used to wait for the completion program interface. The additional data contains the
of an event. return code from the EKGUAPI function. These return
codes are described in the IBM Z NetView Resource
User response Object Data Manager and GMFHS Programmer's Guide.
Check for related log entries or messages that provide The EKGUAPI function is used to access the RODM
more information about the consequences of this data cache.
failure. In most cases, the task that issued this macro
ends. Use the return code description and the data User response
contained in the additional data associated with this Check for related log entries or messages that provide
log entry to determine the cause of the problem. Use more information about the consequences of this
this information, and the information from related log failure. In most cases, the task that called this function
entries, to correct the problem. ends. Use the return code description and the data
22-40 contained in the additional data associated with this
Explanation
assembler macro DSIPUSH. The additional data Trace Data
contains the return code from the DSIPUSH macro.
These return codes are described in IBM Z NetView The format of the additional data provided in the log
Programming: Assembler. entry. The offsets are specified in hexadecimal and are
based from the beginning of the log data. The lengths Code
are specified in decimal. Description
X'00000077'
Offset al Software problem with a component of the
Length topology manager. Record the information
associated with this log entry and contact IBM
0000 4 The RODM function ID. This Software Support.
identifies the RODM function being X'00000088'
invoked. The required GTF trace category is not active.
0004 4 Return code from the EKGUAPI Either the GTF or the indicated GTF trace category
function was stopped after the topology manager traces
were started. The task that created this log entry
0008 4 Reason code from the EKGUAPI continues to try to trace information, but does not
function create another of these log entries until it
successfully stores some trace information. To
22-56 resolve the problem, stop the topology manager
traces or restart the indicated GTF trace category.
Explanation X'00000099'
An unexpected error occurred while attempting to Software problem with the topology manager;
store a topology manager trace record in GTF. The record the information associated with this log
additional data contains the GTF category of the trace entry and contact IBM Software Support.
record, and an internal error code. All others
Message FLB637E is also logged. An internal GTF error occurred. The error code
provided is the one received from the MVS GTRACE
DATA macro. Refer to the MVS library for more
User response information about the macro and its return codes.
The information in the trace record is lost. Use the Following is a list of the most frequently received
error code description and the data contained in the return codes:
additional data associated with this log entry to 0
determine the cause of the problem. Use this The data was recorded in GTF trace buffers.
information to correct the problem.
4
Note: This minor code might not provide sufficient GTF is not active. No data was recorded.
information to resolve the problem. It is anticipated Activate GTF and enable the appropriate GTF
that some additional initial problem determination and event IDs.
diagnosis will be done by the user. If the problem
8
cannot be resolved, record the information associated
Incorrect parameter. Record the information
with this log entry and contact IBM Software Support.
Software Support.
Trace Data
12
The format of the additional data provided in the log Incorrect parameter. Record the information
entry. The offsets are specified in hexadecimal and are associated with this log entry and contact IBM
based from the beginning of the log data. The lengths Software Support.
are specified in decimal. 16
Hex Decim Description Incorrect parameter. Record the information
Offset al associated with this log entry and contact IBM
Length Software Support.
24
0000 2 The GTF event ID of the trace
All GTF buffers are full. No data was recorded.
record. The GTF event ID used by
The topology manager traces are overflowing
the topology manager is X'05E8'.
the GTF trace buffers. Increase the size of the
0002 4 An internal error code. trace buffers or decrease the amount of data
being captured by turning off some of the
Internal error codes are as follows: topology manager trace categories.

28
Incorrect parameter. Record the information
Software Support.
SNA Topology Manager log entries—Major Code 78

These log entries are created whenever the topology manager detects an error or unexpected event.
NOTICE
Contact IBM Software Support for any SNA topology manager log entry containing a major-minor
code that is not described in this chapter.
78-0 Trace Data
Explanation entry. The offsets are specified in hexadecimal and are
The topology manager cannot allocate enough based from the beginning of the log data. The lengths
memory to successfully complete a function. are specified in decimal.
If this probe is issued by the TOPOSNA command Hex Decim Description

processor, the command is not processed. If this Offset al
probe is issued by the FLBTOPO task during Length
initialization, the topology manager ends; otherwise, 0000 4 The size of the storage area that
the command that caused the probe ends and is not cannot be allocated.
retried.
78-20
User response
Release any allocated memory that is not in use within Explanation
the NetView program address space. Some
The topology manager cannot allocate enough
suggestions are to stop any unneeded tasks or to
memory to successfully complete a function.
release any data storage not in use. If this problem
persists, restart the NetView program in a larger If this probe is issued by the FLBTOPO task during
address space. If you suspect that the memory initialization, the topology manager ends; otherwise,
shortage is caused by a software problem, such as a the command that caused the probe ends and is not
NetView task not freeing unused memory, dump the retried.
NetView address space, and follow the instructions in
Chapter 2, “Classifying problems,” on page 13 and User response
Chapter 3, “Documenting and reporting problems,” on
page 23 before contacting IBM Software Support. Release any allocated memory that is not in use within
Use the TOPOSNA LISTSTOR and TOPOSNA suggestions are to stop any unneeded tasks or to
LISTRODM commands to examine storage usage for release any data storage not in use. If this problem
the topology manager. Include the output of these persists, restart the NetView program in a larger
commands with any other information associated with address space. If you suspect that the memory
this log entry when reporting the problem to IBM shortage is caused by a software problem, such as a
Software Support. NetView task not freeing unused memory, dump the
The storage estimates for the topology manager are NetView address space, and follow the instructions in
described in the IBM Z NetView SNA Topology Manager Chapter 2, “Classifying problems,” on page 13 and
Implementation Guide. Chapter 3, “Documenting and reporting problems,” on
page 23 before contacting IBM Software Support.
Note: This minor code might not provide sufficient
information to resolve the problem. It is anticipated Use the TOPOSNA LISTSTOR and TOPOSNA
that some additional initial problem determination and LISTRODM commands to examine storage usage for
diagnosis will be done by the user. If the problem the topology manager. Include the output of these
cannot be resolved, record the information associated commands with any other information associated with
with this log entry and contact IBM Software Support. this log entry when reporting the problem to IBM
Software Support.
The storage estimates for the topology manager are Explanation
described in the IBM Z NetView SNA Topology Manager
The topology manager received an incorrectly
formatted message from VTAM CMIP services. The
78-23 header portion of the message contains incorrect data.
The topology manager discards the message and
Explanation continues processing.
An error occurred when the topology manager tried to User response

establish its association with VTAM CMIP services.
Initialization of the topology manager does not Refer to the z/OS Communications Server CMIP
complete until the association with VTAM CMIP Services and Topology Agent Guide for more
services is established. The topology manager information. In most cases, there is a software
attempts to reconnect to VTAM CMIP services based problem in the interface between the topology
upon the CMPRETRY settings. If this error is manager and VTAM CMIP services. Record the
encountered after topology manager has successfully information associated with this log entry and contact
initialized, the topology manager reinitializes. Message IBM Software Support.
FLB684E is also logged.
Trace Data
User response The format of the additional data provided in the log
Use the VTAM CMIP services error code to determine entry. The offsets are specified in hexadecimal and are
the cause of the error. Refer to the z/OS based from the beginning of the log data. The lengths
Communications Server CMIP Services and Topology are specified in decimal.
Agent Guide for more information. The most probable
cause of this error is VTAM CMIP services has been Hex Decim Description
started but has not completed initializing. Offset al
Length
If the topology manager ends, restart the topology
manager using the AUTOTASK OPID=FLBTOPO 0000 4 The VTAM CMIP services error
command. If necessary, you can use the TOPOSNA code. Refer to the z/OS
SETDEFS, CMPRETRY command to change the VTAM Communications Server SNA
CMIP services connect retry values. Diagnosis manuals for more
information about diagnosing
Note: This minor code might not provide sufficient VTAM CMIP services problems. For
information to resolve the problem. It is anticipated information about VTAM CMIP
that some additional initial problem determination and services, see the z/OS
diagnosis will be done by the user. If the problem Communications Server CMIP
cannot be resolved, record the information associated Services and Topology Agent Guide.
Trace Data 000E 1 Size of the header information (k).
The format of the additional data provided in the log 000F 1 For IBM Software Support use
0010 k The message header information
received from VTAM CMIP
services.
Hex Decim Description 0010+ 2 Size of the message. The message
Offset al k is shown in character format (not
Length hexadecimal format). This is the
0000 4 The VTAM CMIP services error number of characters in the
code. Refer to the z/OS message.
Communications Server CMIP 0012+ l The message received from VTAM
Services and Topology Agent Guide k CMIP services. The message is
for more information. shown in character (not
hexadecimal) format.
78-25
78-26

Explanation Hex Decim Description
The topology manager received an incorrectly Offset al
formatted message from VTAM CMIP services. The Length
topology manager cannot parse the contents of the 0012+ l The message received from VTAM
message. The topology manager discards the message k CMIP services. The message is
and continues processing. shown in character (not
User response
The message received from VTAM CMIP services 78-27
contained data that the topology manager did not
recognize. In most cases, there is a software problem Explanation
in the interface between the topology manager and An error occurred when the topology manager tried to
VTAM CMIP services. Record the information end its association with VTAM CMIP services. This
associated with this log entry and contact IBM error occurred while the topology manager was
Software Support. ending. The topology manager continues shutdown
It is also possible that the agent node sent incorrect processing by releasing all allocated resources and
topology information. If the message was received then ending.
from the agent node, verify that the contents of the
message are correct. User response
For more information about the format of the Use the VTAM CMIP services error code to determine
information, refer to: the cause of the error. Refer to the z/OS
• IBM SystemView library Communications Server CMIP Services and Topology
Agent Guide for more information. The most probable
• CCITT Rec.X.710 | ISO/IEC 9595:1991 (ISO/IEC cause of this error is that VTAM CMIP services are not
9595:1991, Information technology - Open Systems active. In most cases, this error can be ignored
Interconnection - Common management information because the topology manager is already ending.
service definition)
• CCITT Rec.X.711 | ISO/IEC 9596-1:1991 (ISO/IEC
information to resolve the problem. It is anticipated
9596-1:1991, Information technology - Open
that some additional initial problem determination and
Systems Interconnection - Common management
information protocol - Part 1: Specification)
Trace Data
The format of the additional data provided in the log Trace Data
Hex Decim Description are specified in decimal.
Offset al
Length
Offset al
0000 14 For IBM Software Support use Length
000E 1 Size of the header information (k). 0000 4 The VTAM CMIP services error
code. Refer to the z/OS
000F 1 For IBM Software Support use
Communications Server CMIP
0010 k The message header information Services and Topology Agent Guide
received from VTAM CMIP for more information.
services.
0010+ 2 Size of the message. The message 78-28
k is shown in character format (not
hexadecimal format). This is the Explanation
number of characters in the An error occurred when the topology manager tried to
message. end its association with VTAM CMIP services. This
error occurred while the topology manager was manager continues to process other requests. If the
ending. The topology manager continues shutdown function was initiated by an operator command, the
processing by releasing all allocated resources and operator receives an error message.
then ending.
User response
User response
Use the VTAM CMIP services error code to determine
Use the VTAM CMIP services error code to determine the cause of the error. Refer to the z/OS
the cause of the error. Refer to the z/OS Communications Server CMIP Services and Topology
Communications Server CMIP Services and Topology Agent Guide for more information. Correct the problem
Agent Guide for more information. The most probable and retry the operation.
cause of this error is that VTAM CMIP services are not
active. In most cases, this error can be ignored
because the topology manager is already ending.
Note: This minor code might not provide sufficient diagnosis will be done by the user. If the problem
information to resolve the problem. It is anticipated cannot be resolved, record the information associated
that some additional initial problem determination and with this log entry and contact IBM Software Support.
cannot be resolved, record the information associated Trace Data
Trace Data
The format of the additional data provided in the log are specified in decimal.
based from the beginning of the log data. The lengths Hex Decim Description
are specified in decimal. Offset al
Length
0000 4 The VTAM CMIP services error
Offset al
Length
0000 4 The VTAM CMIP services error Services and Topology Agent Guide
code. Refer to the z/OS for more information.
Communications Server SNA
0004 4 Size of the message data. The
Diagnosis manuals for more
message data is shown in
information about diagnosing
character format (not hexadecimal
VTAM CMIP services problems. For
format). This is the number of
information about VTAM CMIP
characters in the message.
services, see the z/OS
Communications Server CMIP 0008 k The message being sent. The
Services and Topology Agent Guide. message is shown in character (not
hexadecimal) format. The entire
message is shown, including the
field value. Refer to the z/OS
routing information at the
beginning of the message (the
Services and Topology Agent Guide
message starts with src-type, dest-
type, or msg).
78-30
78-31
Explanation
Explanation
An unexpected error occurred when the topology
An unexpected error occurred when the topology
manager attempted to send a CMIP message to an
manager attempted to receive a CMIP message from
agent node. The topology manager sends CMIP
the agent node or VTAM CMIP services. The topology
messages to begin a monitor operation, end a monitor
manager receives CMIP messages containing the
operation, or activate, deactivate, or recycle a
results of monitor operations or resource control
resource. The requested function fails. The topology

requests. It also receives special messages from Hex Decim
VTAM CMIP services to inform it of error conditions Offset al
and other operation results. The topology manager Length Description
reinitializes. Message FLB684E, FLB677E, or FLB678E
might also be logged. indicated by the offset information
in the previous field.
User response
78-32
the cause of the error. Refer to the z/OS Explanation
Communications Server library for more information.
The most probable cause of this error is that VTAM The topology manager received an incorrectly
CMIP services ended unexpectedly. If VTAM CMIP formatted message from VTAM CMIP services. The
services are not active, start them. If the topology topology manager cannot parse the contents of the
manager ends, restart the topology manager (using message. The difference between this log entry and
the AUTOTASK OPID=FLBTOPO command). If the log entry with minor code 26 is the topology
necessary, you can use the TOPOSNA SETDEFS, manager recognizes the message, but cannot parse
CMPRETRY command to change the VTAM CMIP the topology data or error information within the
services connection retry values. message. The topology manager discards the message
and continues processing.
Trace Data This log entry is also created when the topology
The format of the additional data provided in the log manager receives an unexpected message from VTAM
entry. The offsets are specified in hexadecimal and are CMIP services. Examples of unexpected messages are
based from the beginning of the log data. The lengths CMIP responses before any CMIP requests were sent
are specified in decimal. out, or internal completion messages when the
corresponding operation is not outstanding. The
Hex Decim topology manager discards the message and
Offset al continues processing.
Length Description The message data helps indicate which error occurred.
0000 4 The VTAM CMIP services error For message syntax errors, the message data contains
code. Refer to the z/OS the portion of the data where the syntax error was
Communications Server CMIP found. For unexpected messages, the entire message
Services and Topology Agent Guide is shown, including the routing information at the
for more information. beginning of the message (the message starts with
src-type, dest-type, or msg).
0004 4 The ID of the association between
the topology manager and VTAM
CMIP services. A value of zero User response
indicates that the error occurred The message received from VTAM CMIP services
before the association was contained data that the topology manager did not
completed. recognize. In most cases, the agent node sent
0008 4 Extended error information from incorrect topology information. If the message was
VTAM CMIP services. Refer to the received from the agent node, verify that the contents
z/OS Communications Server CMIP of the message are correct.
Services and Topology Agent Guide For more information about the format of the
for more information. information, refer to:
000C 2 Offset within the message • IBM SystemView library
information where the actual
• CCITT Rec.X.710 | ISO/IEC 9595:1991 (ISO/IEC
message received from VTAM
9595:1991, Information technology - Open Systems
CMIP services begins.
Interconnection - Common management information
000E k The message received from VTAM service definition)
CMIP services. The first part of the • CCITT Rec.X.711 | ISO/IEC 9596-1:1991 (ISO/IEC
message is the routing 9596-1:1991, Information technology - Open
information. The beginning of the Systems Interconnection - Common management
actual message within this data is information protocol - Part 1: Specification)
The message might be formatted correctly but out of Hex Decim Description
sequence. In this case, there is a software problem in Offset al
the interface between the topology manager and Length
VTAM CMIP services. Record the information
associated with this log entry and contact IBM 0000 k Name of the initialization file
Software Support. (FLBSYSD). This name is shown in
character, not hexadecimal,
format.
Trace Data
The format of the additional data provided in the log 78-36
based from the beginning of the log data. The lengths Explanation
The topology manager encountered an error while
Hex Decim Description reading the initialization file FLBSYSD. Initialization of
Offset al the topology manager fails.
Length
0000 4 Size of the message data. The User response
message data is shown in Use the internal error indicator supplied in the log
character format (not hexadecimal entry to determine the cause of the problem.
format). This is the number of Disregarding I/O errors, the problem is caused by an
characters in the message. incorrectly formatted FLBSYSD file. Correct the syntax
0004 k The message received from VTAM error, and restart the topology manager. Modifying the
CMIP services. The message is initialization file is described in the IBM Z NetView SNA
shown in character (not Topology Manager Implementation Guide.
hexadecimal) format. Note: This minor code might not provide sufficient
78-35 that some additional initial problem determination and
Explanation cannot be resolved, record the information associated
The topology manager cannot open the initialization
file FLBSYSD. Initialization of the topology manager
fails. Trace Data
User response entry. The offsets are specified in hexadecimal and are
Determine why the topology manager cannot open the
initialization file. The file is installed in the data set
NETVIEW.V6R3M0.DSIPARM. A modified copy might
be in a user DSIPARM data set. Place the file in the
correct data set, and restart the topology manager.
Trace Data

Hex Decim Description The attribute received is an optional attribute, For
Offset al more information about the mandatory and optional
Length attributes for APPN topology, refer to the IBM
SystemView library.
0000 4 An integer indicating the cause of
the problem.
User response
Value
The topology manager ignores the unknown attribute
Problem
and continues processing the other data in the
1 received update. This log entry is created the first time
The indicated section identifier the topology manager receives each unknown
is missing. The FLBSYSD file is attribute during a monitor operation. The topology
divided into sections, identified manager continues to ignore the attribute in all other
by unique identifiers followed updates, but the problem is not logged.
by a colon (:).
The attribute and its value are not stored in the RODM
2 data cache by the topology manager. You can choose
The indicated keyword was not to ignore this log entry, because the topology manager
found in the indicated section. continues to process the received updates. This does
The FLBSYSD file is divided warn you that some of the data being reported by a
into sections, with one or more topology agent is not stored in the RODM data cache.
keywords in each section.
3
The value for a keyword
exceeds the maximum value
allowed for a keyword.
4 with this log entry and contact IBM Software Support.
The value for a keyword is
incorrectly formatted. The
Trace Data
value contains a double
quotation mark (") with no The format of the additional data provided in the log
ending double quotation mark. entry. The offsets are specified in hexadecimal and are
0004 2 The number of characters in the are specified in decimal.
section identifier.
0006 k Name of the section identifier
Offset al
being referenced when the error
Length
was detected. The name is shown
in character, not hexadecimal, 0000 2 Number of characters in the object
format. identifier.
0006+ 2 The number of characters in the 0002 k The object identifier of the
k keyword identifier. unknown attribute. The identifier is
shown in character (not
0008+ l Name of the keyword identifier
k being referenced when the error
was detected. The name is shown
in character, not hexadecimal, 78-38
format.
Explanation
78-37 The topology manager received a topology update
from an agent node containing unsupported
Explanation management extensions. Management extensions can
be added to the update by the agent nodes to indicate
The topology manager received a topology update
optional information. The topology manager does not
from an agent node containing an object attribute that
support any management extensions in the update
it does not support. The attributes supported by the
information. It usually ignores this data without
topology manager are described in the IBM Z NetView
logging any information. The log entry is created when
Data Model Reference.
the update indicates that the management extension Trace Data
information is significant (the significance attribute is
TRUE).
User response are specified in decimal.
The topology manager ignores the data in the
management extension and continues processing the
Offset al
other data in the update.
Length
The data contained in the management extension is
0000 4 The RODM return code
not stored in the RODM data cache by the topology
manager. You can choose to ignore this log entry,
because the topology manager continues to process 78-41
the received updates. This does warn you that some of
the data being reported by the agent node is not Explanation
stored in the RODM data cache. RODM indicated that the response block used by
Note: This minor code might not provide sufficient RODM was not large enough to hold all of the data
information to resolve the problem. It is anticipated related to a query function issued by the topology
that some additional initial problem determination and manager. The topology manager allocates a RODM
diagnosis will be done by the user. If the problem response block large enough to hold the data and
cannot be resolved, record the information associated issues the RODM function again. After the RODM
with this log entry and contact IBM Software Support. function is completed, the topology manager releases
the allocated response block.
Trace Data
User response
entry. The offsets are specified in hexadecimal and are This log entry is for information only. No action is
based from the beginning of the log data. The lengths required.
Trace Data
Offset al The format of the additional data provided in the log
Length entry. The offsets are specified in hexadecimal and are
0000 2 Number of characters in the object are specified in decimal.
identifier.
0002 k The object identifier of the Hex Decim Description
attribute in the management Offset al
extension marked as significant. Length
The identifier is shown in character 0000 4 The size of the existing RODM
(not hexadecimal) format. response block.
0004 4 The size of the RODM response
78-40
block needed to hold the data.
Explanation
78-42
A software problem has been detected by the topology
manager. A RODM function completed with an Explanation
unknown RODM return code. The topology manager
expects the RODM return code to be 0, 4, 8, or 12. The The topology manager encountered an unexpected
topology manager ends. RODM error while trying to access the topology
manager defaults object. The topology manager
defaults object (class FLB_DEFAULTS, object name
User response FLBDEF) is used to store the default settings defined
Record the information associated with this log entry using the TOPOSNA SETDEFS command.
and contact IBM Software Support. The provided RODM error code indicator is an internal
indicator used to map the error codes received from

RODM into a contiguous set of values. See the showing the mapping of the RODM return codes and
“Internal RODM Error Code Indicator” on page 408 for reason codes to this internal error indication.
the table showing the mapping of the RODM return
The object that cannot be created is identified by its
codes and reason codes to this internal error
name and its graph type. These objects are created
indication.
when topology information is received from the agent
nodes. Depending upon the severity of the error, the
User response topology manager ends or retries the related monitor
Use the mapping of the internal error indicator and the operation based on the ERRLIMIT setting. The
RODM function ID to determine the probable RODM ERRLIMIT value can be changed by the TOPOSNA
return and reason codes. If the internal error indicator SETDEFS,ERRLIMIT command.
is an unrecoverable error, two other log entries are
created. The first (22-47) provides the actual RODM User response
return code and reason code. The second (78-76 or
Use the mapping of the internal error indicator and the
78-77) identifies the targeted object (and possibly the
RODM function ID to determine the probable RODM
field) within the RODM data cache.
return and reason codes. If the internal error indicator
The RODM return codes, reason codes, function IDs, is an unrecoverable error, two other log entries are
and other API information are described in the IBM Z created. The first (22-47) provides the actual RODM
NetView Resource Object Data Manager and GMFHS return code and reason code. The second (78-76 or
Programmer's Guide. Refer to the topology data model, 78-77) identifies the targeted object (and possibly the
which describes the topology manager RODM objects field) within the RODM data cache.
in the IBM Z NetView Data Model Reference. Use this
The RODM return codes, reason codes, function IDs,
information to diagnose and correct the problem.
and other API information are described in the IBM Z
If the internal RODM error code indicates an NetView Resource Object Data Manager and GMFHS
unrecoverable error, the topology manager stops and Programmer's Guide. Refer to the topology data model,
must be restarted. Retry the command that failed which describes the topology manager RODM objects
(TOPOSNA QUERYDEF or TOPOSNA SETDEFS). in the IBM Z NetView Data Model Reference. Use this
Trace Data
Trace Data
entry. The offsets are specified in hexadecimal and are The format of the additional data provided in the log
based from the beginning of the log data. The lengths entry. The offsets are specified in hexadecimal and are
are specified in decimal. based from the beginning of the log data. The lengths
Offset al
Length
0002 2 The RODM function ID.
0004 2 The internal RODM error code
indicator used by the topology
manager to map the RODM return
and reason codes.
78-43
Explanation
The topology manager encountered an unexpected
RODM error while trying to create an aggregate object.
The RODM error code indicator provided is an internal
indicator used to map the error codes received from
RODM into a contiguous set of values. See “Internal
RODM Error Code Indicator” on page 408 for the table
Hex Decim Description Hex Decim Description
Offset al Offset al
Length Length
0000 2 The type of aggregate object: 12
Value NN domain (for virtual nodes).
Description RODM class
aggregateGraph2, ASN.1
1 object identifier and RODM
NN domain. RODM class class name
aggregateGraph2, ASN.1 (1.3.18.0.0.6708), graph
object identifier and RODM type nnDomain.
class name
(1.3.18.0.0.6708), graph 0002 2 The internal RODM error code
type nnDomain. indicator used by the topology
2 manager to map the RODM return
NN domain network. RODM and reason codes.
class aggregateGraph2, 0004 k The name of the aggregate object
ASN.1 object identifier and that cannot be created. This is the
RODM class name value of the MyName field for the
(1.3.18.0.0.6708), graph object in the RODM data cache.
type nnDomain. The format of this name for the
3 topology manager RODM objects is
NN domain network cluster. described in the IBM Z NetView
RODM class Data Model Reference. The name is
aggregateGraph2, ASN.1 shown in character (not
object identifier and RODM hexadecimal) format.
class name
(1.3.18.0.0.6708), graph 78-44
type nnDomain.
4 Explanation
SNA local topology. RODM
class snaLocalTopo, ASN.1
RODM error while trying to initialize the attributes of
object identifier and RODM
an aggregate object. The RODM error code indicator
class name
provided is an internal indicator used to map the error
(1.3.18.0.0.2152), graph ID
codes received from RODM into a contiguous set of
SnaLocalTopo.
values. See “Internal RODM Error Code Indicator” on
5 page 408 for the table showing the mapping of the
Super cluster view. RODM RODM return codes and reason codes to this internal
class Network_View_Class error indication.
RODM class name
(Network_View_Class). The object that cannot be initialized is identified by its
RODM object ID and its graph type. These objects are
6 created and initialized when topology information is
Interdomain circuit. RODM received from the agent nodes. The topology manager
class circuit2, ASN.1 object ends when this error occurs.
identifier and RODM class
name (1.3.18.0.0.2186).
User response
7
Interdomain network circuit. Use the mapping of the internal error indicator and the
RODM class circuit2, ASN.1 RODM function ID to determine the probable RODM
object identifier and RODM return and reason codes. If the internal error indicator
class name is an unrecoverable error, two other log entries are
(1.3.18.0.0.2186). created. The first (22-47) provides the actual RODM

The RODM return codes, reason codes, function IDs, Hex Decim Description
and other API information are described in the IBM Z Offset al
NetView Resource Object Data Manager and GMFHS Length
Programmer's Guide. Refer to the topology data model,
which describes the topology manager RODM objects 5
in the IBM Z NetView Data Model Reference. Use this Super cluster view. RODM
information to diagnose and correct the problem. class Network_View_Class
RODM class name
Restart the topology manager, and restart the monitor (Network_View_Class).
operations for the agent nodes. If you warm-start the
topology manager, the existing monitor operations are 6
restarted by the topology manager. Interdomain circuit. RODM
class circuit2, ASN.1 object
identifier and RODM class
Trace Data
name (1.3.18.0.0.2186).
The format of the additional data provided in the log 7
entry. The offsets are specified in hexadecimal and are Interdomain network circuit.
based from the beginning of the log data. The lengths RODM class circuit2, ASN.1
are specified in decimal. object identifier and RODM
class name
(1.3.18.0.0.2186).
Offset al
Length 12
NN domain (for virtual nodes).
0000 2 The type of aggregate object. RODM class
Value aggregateGraph2, ASN.1
Description object identifier and RODM
1 class name
NN domain. RODM class (1.3.18.0.0.6708), graph
aggregateGraph2, ASN.1 type nnDomain.
object identifier and RODM 0002 8 The RODM object ID of the
class name aggregate object.
(1.3.18.0.0.6708), graph
type nnDomain. 000A 2 The internal RODM error code
2
NN domain network. RODM
and reason codes.
class aggregateGraph2,
ASN.1 object identifier and
RODM class name 78-46
(1.3.18.0.0.6708), graph
type nnDomain. Explanation
3 The topology manager encountered an unexpected
NN domain network cluster. RODM error while trying to set or reset the view links
RODM class for an object. These links are used to specify how the
aggregateGraph2, ASN.1 object is displayed at the workstation. The RODM error
object identifier and RODM code indicator provided is an internal indicator used to
class name map the error codes received from RODM into a
(1.3.18.0.0.6708), graph contiguous set of values. See “Internal RODM Error
type nnDomain. Code Indicator” on page 408 for the table showing the
4 mapping of the RODM return codes and reason codes
SNA local topology. RODM to this internal error indication.
class snaLocalTopo, ASN.1 The objects being linked or unlinked are identified by
object identifier and RODM their RODM object IDs. The view links for these objects
class name are set or reset when topology information is received
(1.3.18.0.0.2152), graph ID from the agent nodes and when the objects are
SnaLocalTopo. purged. Depending upon the severity of the error, the
topology manager ends or retries the related monitor
operation based on the ERRLIMIT value. The showing the mapping of the RODM return codes and
ERRLIMIT value can be changed by the TOPOSNA reason codes to this internal error indication.
SETDEFS,ERRLIMIT command.
The aggregate object and the object it was being
linked to or unlinked from are identified by their RODM
User response object IDs. The aggregation links for these objects are
Use the mapping of the internal error indicator and the set or reset when topology information is received
RODM function ID to determine the probable RODM from the agent nodes and when the objects are
return and reason codes. If the internal error indicator purged. Depending upon the severity of the error, the
is an unrecoverable error, two other log entries are topology manager ends or retries the related monitor
created. The first (22-47) provides the actual RODM operation based on the ERRLIMIT value. The
return code and reason code. The second (78-76 or ERRLIMIT value can be changed by the TOPOSNA
78-77) identifies the targeted object (and possibly the SETDEFS,ERRLIMIT command.
User response
and other API information are described in the IBM Z Use the mapping of the internal error indicator and the
NetView Resource Object Data Manager and GMFHS RODM function ID to determine the probable RODM
Programmer's Guide. Refer to the topology data model, return and reason codes. If the internal error indicator
which describes the topology manager RODM objects is an unrecoverable error, two other log entries are
in the IBM Z NetView Data Model Reference. Use this created. The first (22-47) provides the actual RODM
information to diagnose and correct the problem. return code and reason code. The second (78-76 or
Trace Data field) within the RODM data cache.
The format of the additional data provided in the log The RODM return codes, reason codes, function IDs,
entry. The offsets are specified in hexadecimal and are and other API information are described in the IBM Z
based from the beginning of the log data. The lengths NetView Resource Object Data Manager and GMFHS
are specified in decimal. Programmer's Guide. Refer to the topology data model,
which describes the topology manager RODM objects
Hex Decim Description in the IBM Z NetView Data Model Reference. Use this
Offset al information to diagnose and correct the problem.
Length
0000 2 The RODM function ID. This Trace Data
identifies the RODM function being The format of the additional data provided in the log
invoked. entry. The offsets are specified in hexadecimal and are
0002 8 The RODM object ID of the first based from the beginning of the log data. The lengths
object. are specified in decimal.
000A 8 The RODM object ID of the second Hex Decim Description

object. Offset al
Length
indicator used by the topology 0000 2 An indicator identifying the RODM
manager to map the RODM return function ID.
and reason codes. Value
RODM function
78-47
1
Link objects (DUIFCUAP)
Explanation
2
The topology manager encountered an unexpected Unlink objects (DUIFCUAP)
RODM error while trying to set or reset the aggregation
links for an aggregate object. These links are used to 0002 8 The RODM object ID of the
control the aggregation of the status of the object. The aggregate object.
RODM error code indicator provided is an internal 000A 8 The RODM object ID of the object
indicator used to map the error codes received from the aggregate object was being
RODM into a contiguous set of values. See “Internal linked to or unlinked from.
RODM Error Code Indicator” on page 408 for the table

Offset al
Length
and reason codes.
78-48
Explanation
RODM error while trying to read or update the
DisplayResourceOtherData attribute of an
aggregate object. The RODM error code indicator
provided is an internal indicator used to map the error
codes received from RODM into a contiguous set of
values. See “Internal RODM Error Code Indicator” on
page 408 for the table showing the mapping of the
RODM return codes and reason codes to this internal
error indication.
The object that cannot be read or updated is identified
by its RODM object ID and its graph type. These
objects are updated when topology information is
received from the agent nodes. Depending upon the
severity of the error, the topology manager ends or
retries the related monitor operation based on the
ERRLIMIT value. The ERRLIMIT value can be changed
by the TOPOSNA SETDEFS,ERRLIMIT command.
User response
created. The first (22-47) provides the actual RODM
NetView Resource Object Data Manager and GMFHS
Trace Data
Offset al Offset al
Length Length
0000 2 The type of aggregate object. 12
class name
(1.3.18.0.0.6708), graph 0002 8 The RODM object ID of the
type nnDomain. aggregate object.
2 000A 2 The internal RODM error code
NN domain network. RODM indicator used by the topology
class aggregateGraph2, manager to map the RODM return
ASN.1 object identifier and and reason codes.
RODM class name
(1.3.18.0.0.6708), graph 000C k The data to be added or removed
type nnDomain. from the
DisplayResourceOtherData
3 attribute. The format of this
NN domain network cluster. attribute for the topology manager
RODM class
RODM objects is described in the
IBM Z NetView Data Model
Reference. The data is shown in
class name
character (not hexadecimal)
(1.3.18.0.0.6708), graph
format.
type nnDomain.
4 78-56
Explanation
class name A problem occurred while creating and initializing the
(1.3.18.0.0.2152), graph ID topology manager aggregate objects. The topology
SnaLocalTopo. manager, during initialization, attempts to locate the
5 Network_View_Class object identified in the
Super cluster view. RODM FLBSYSD initialization file by the label
class Network_View_Class SUPER_CLUSTER_VIEW_NAME. The value of that label
RODM class name is used as the MyName attribute of the
(Network_View_Class). Network_View_Class object used by the topology
manager.
6
Interdomain circuit. RODM The topology manager also tries to locate the
class circuit2, ASN.1 object aggregateGraph2 object identified in the FLBSYSD
identifier and RODM class initialization file by the label
name (1.3.18.0.0.2186). NN_DOMAIN_NETWORK_CLUSTER_DRN. The value of
that label is used as the DisplayResourceName
7
attribute of the nnDomainNetworkCluster object used
Interdomain network circuit.
by the topology manager. If the object exists in the
RODM class circuit2, ASN.1
RODM data cache, the topology manager uses the
existing object. When the object is located or created,
class name
the object is linked to the Network_View_Class
(1.3.18.0.0.2186).
object.
If any of these operations fail, initialization of the
topology manager fails.

User response Explanation
The log entry contains an error indicator that identifies The topology manager cannot allocate enough
the error encountered while initializing these objects. memory to successfully complete a function. The
In addition, there are additional log entries created to topology manager ends.
further define the problem. Use this information to
determine the cause of the problem. Correct the User response
problem and restart the topology manager.
A corresponding log entry (79-0) is also created,
The most probable error is that the information in the describing the memory allocation failure in more
FLBSYSD initialization file is incorrect. For example, detail. Use the information and description of that log
the name of the Network_View_Class object must entry to resolve the problem. Restart the topology
match the name of the object created by the topology manager.
data model. The format of the initialization file is
described in the IBM Z NetView SNA Topology Manager 78-59
Explanation
Trace Data The topology manager encountered an error
The format of the additional data provided in the log processing an update for a resource. The most
entry. The offsets are specified in hexadecimal and are common problems are:
based from the beginning of the log data. The lengths • An unexpected RODM error occurred while the
are specified in decimal. topology manager was trying to update or query a
RODM object. Depending on the error, the topology
manager might be able to recover.
Offset al
Length • A software problem has been detected by the
topology manager while processing the update. A
0000 2 The type of error. problem occurred in the internal interfaces within
Value the topology manager.
Description
The topology manager either ends, ends the related
1 monitor operation, retries the related monitor
Storage cannot be allocated operation, or continues processing. Associated log
within the topology manager to entries are created to identify the specific cause of the
represent the objects. error. Refer to the description of these log entries to
2 determine what actions the topology manager takes
Storage cannot be allocated when this error occurs.
within the topology manager
for the tables needed to User response
manage the other aggregate
Use the error information in the associated log entry to
objects.
resolve the problem.
3
The Network_View_Class If a RODM error occurred, a corresponding log entry
object cannot be located. with minor code 76 or 77 is created, identifying the
objects that failed. Another log entry is created, major
4 code 22, minor code 47 containing the RODM error
The nnDomainNetworkCluster codes. Use the information and description of these
object cannot be located or log entries to resolve the problem.
created.
If a software error occurred, record the information
5
The nnDomainNetworkCluster
Software Support.
object cannot be linked to the
Network_View_Class If the topology manager ended, restart the topology
object. manager and the monitor operations for the agent
nodes. If you warm-start the topology manager, the
78-58 existing monitor operations are restarted by the
topology manager. If the topology manager ended a
monitor operation, restart the monitor operation that
ended. Otherwise, the topology manager recovered User response
and no further action is required.
78-65 RODM function ID to determine the probable RODM
Explanation is an unrecoverable error, two other log entries are
The topology manager encountered a problem trying return code and reason code. The second (78-76 or
to link the nnDomainNetwork and 78-77) identifies the targeted object (and possibly the
nnDomainNetworkCluster objects to create the views field) within the RODM data cache.
seen at the workstation. Depending upon the severity
of the error, the topology manager ends or retries the The RODM return codes, reason codes, function IDs,
related monitor operation based on the ERRLIMIT and other API information are described in the IBM Z
value. The ERRLIMIT value can be changed by the NetView Resource Object Data Manager and GMFHS
TOPOSNA SETDEFS,ERRLIMIT command. Programmer's Guide. Refer to the topology data model,
User response information to diagnose and correct the problem.
Other log entries are created describing the error in Restart the topology manager.
more detail. Use the information and description of
these log entries to resolve the problem.
Trace Data
78-66
Explanation based from the beginning of the log data. The lengths
The number used to uniquely identify each are specified in decimal.
nnDomainNetwork object has wrapped. This probably
should not happen because the number is a very large
number and is recalculated when the topology Offset al
manager is started. The topology manager ends. Length
User response indicator used by the topology
This number is combined with the SNA network ID to and reason codes.
form the DisplayResourceName of the
nnDomainNetwork objects in the RODM data cache. 0002 2 The RODM function ID.
This number is set during topology manager 0004 2 The internal class indicator used
initialization to the highest existing value currently in by the topology manager to
the RODM data cache, and is incremented each time a represent the RODM object
new nnDomainNetwork object is created. The classes. See “Internal RODM Class
maximum value is 231-1. Purge or renumber the Indicator” on page 411 for the
nnDomainNetwork objects in the RODM data cache, table showing the mapping of the
and then restart the topology manager. RODM object classes to this
78-69 internal indication.
Explanation 78-71
The topology manager encountered an unexpected Explanation

RODM error while trying to read the list of objects for a
class during warm-start processing. The RODM error The topology manager encountered an unexpected
code indicator provided is an internal indicator used to RODM error while trying to read the attributes of an
map the error codes received from RODM into a object during warm-start processing, while creating a
contiguous set of values. See “Internal RODM Error graph object, or while deleting an object. If the error
Code Indicator” on page 408 for the table showing the occurred while attempting to create a graph object, an
mapping of the RODM return codes and reason codes associated log entry is created with minor code 81. If
to this internal error indication. the error occurred while attempting to delete an
object, an associated log entry is created with minor
The object class that cannot be read is identified by an code 84. The RODM error code indicator provided is an
internal indicator representing the RODM class.

internal indicator used to map the error codes received within the topology manager. Initialization of the
from RODM into a contiguous set of values. See topology manager fails.
“Internal RODM Error Code Indicator” on page 408 for
the table showing the mapping of the RODM return User response
codes and reason codes to this internal error
indication. If there is a corresponding storage allocation failure
log entry, use the information in that log entry to
The object is identified by its RODM object ID. correct the problem. Otherwise, record the
information associated with this log entry and contact
User response IBM Software Support.
RODM function ID to determine the probable RODM Trace Data
return and reason codes. If the internal error indicator For IBM Software Support use only.
created. The first (22-47) provides the actual RODM 78-73
78-77) identifies the targeted object (and possibly the Explanation
A RODM object was read during warm-start processing
The RODM return codes, reason codes, function IDs, that has an incorrectly formatted MyName attribute.
and other API information are described in the IBM Z The format of this attribute for the topology manager
NetView Resource Object Data Manager and GMFHS objects is described in the IBM Z NetView Data Model
Programmer's Guide. Refer to the topology data model, Reference. Initialization of the topology manager fails.
in the IBM Z NetView Data Model Reference. Use this User response
The RODM object ID of the incorrectly formatted
Restart the topology manager. object is provided, along with the value of the MyName
attribute. Correct the value for the attribute, or delete
Trace Data the object. Restart the topology manager.
entry. The offsets are specified in hexadecimal and are Trace Data
based from the beginning of the log data. The lengths The format of the additional data provided in the log
are specified in decimal. entry. The offsets are specified in hexadecimal and are
Offset al
Length Hex Decim Description
0000 2 The internal RODM error code Offset al
indicator used by the topology Length
manager to map the RODM return 0000 8 The RODM object ID of the object.
and reason codes.
0008 k The name of the object (the
0002 2 The RODM function ID. contents of the MyName attribute).
0004 8 The RODM object ID of the object.
78-74
78-72
Explanation
Explanation A RODM object was read during warm-start processing
This log entry is created for two different error that has an incorrectly formatted MyName attribute.
conditions. The first is a storage allocation error. If this The format of this attribute for the topology manager
occurs, a corresponding log entry is created (minor objects is described in the IBM Z NetView Data Model
code = 0). If the error is not a storage allocation error, Reference. Initialization of the topology manager fails.
a software problem has been detected by the topology
manager. A problem occurred in the internal interfaces
User response Trace Data
The incorrectly formatted object is identified by the The format of the additional data provided in the log
value of the MyName attribute. Correct the value for the entry. The offsets are specified in hexadecimal and are
attribute, or delete the object. Restart the topology based from the beginning of the log data. The lengths
manager. are specified in decimal.

Trace Data
Offset al
The format of the additional data provided in the log Length
are specified in decimal. 0008 k The data that was truncated from
the
Hex Decim Description DisplayResourceOtherData
Offset al attribute. The format of this
Length attribute for the topology manager
0000 k The name of the object (the RODM objects is described in the
contents of the MyName attribute). IBM Z NetView Data Model
This name has been converted Reference. The data is shown in
from the RODM format to the character (not hexadecimal)
SystemView format. In most format.
cases, the formats are the same.
See the IBM Z NetView Data Model 78-76
Reference for details on the
required conversions between Explanation
RODM names and SystemView
names. The topology manager encountered an unrecoverable
RODM error. Another log entry is created (major code
22, minor code 47) that provides the actual RODM
78-75
return code and reason code. Other log entries might
be created that provide more information about the
Explanation error, such as the operation that failed when the error
The topology manager had to truncate the value of the occurred. This log entry is used to identify what RODM
DisplayResourceOtherData attribute of an object. object was being referenced when the failure
The size of this attribute is limited to 255 characters, occurred.
and the received values exceed that size. The topology The log entry provides the RODM class ID of the
manager truncates the value. This attribute is updated object, the RODM object ID of the object if the error is
when topology information is received from the agent related to a specific object in that class, and the RODM
nodes for the object. field ID of the attribute if the error is related to a
specific object attribute. The format of these
User response identifiers is described in the IBM Z NetView Resource
The topology manager truncates the value and
continues processing. This log entry serves as a
warning to indicate that the value of the User response
DisplayResourceOtherData attribute for an object Use the information in this log entry along with the
cannot be updated with all the data related to that information in the related log entries to diagnose and
attribute. correct the problem.
information to resolve the problem. It is anticipated Trace Data

Offset al Offset al
Length Length
0000 4 The RODM class ID of the object. 0008+k l The name of the object. The name
is shown in character, not
hexadecimal, format.
000C 4 The RODM field ID of the object
0008+k 4 The number of characters in the
attribute.
+l attribute name.
78-77 000C+k m The name of the object attribute.

+l The name is shown in character,
not hexadecimal, format.
Explanation
The topology manager encountered an unrecoverable 78-78
RODM error. Another log entry is created (major code
22, minor code 47) that provides the actual RODM
Explanation
return code and reason code. Other log entries might
be created that provide more information about the The topology manager encountered an unexpected
error, such as the operation that failed when the error RODM error while trying to initialize the attributes of a
occurred. This log entry is used to identify what RODM logical link or port object. The RODM error code
object was being referenced when the failure indicator provided is an internal indicator used to map
occurred. the error codes received from RODM into a contiguous
set of values. See “Internal RODM Error Code
The log entry provides the RODM class name of the
Indicator” on page 408 for the table showing the
object, the RODM name of the object if the error is
mapping of the RODM return codes and reason codes
related to a specific object in that class, and the RODM
to this internal error indication.
name of the attribute if the error is related to a specific
object attribute. The name of an object is the same as The object that cannot be initialized is identified by its
the value of the MyName attribute of the object. The RODM object ID. These objects are created and
class names, attribute names, and format of the object initialized when topology information is received from
names for the topology manager objects are described the agent nodes. Depending upon the severity of the
in the IBM Z NetView Data Model Reference. error, the topology manager ends or retries the related
monitor operation based on the ERRLIMIT value. The
User response ERRLIMIT value can be changed by the TOPOSNA
SETDEFS,ERRLIMIT command.
Use the information in this log entry along with the
information in the related log entries to diagnose and
User response
correct the problem.
Trace Data RODM function ID to determine the probable RODM
The format of the additional data provided in the log is an unrecoverable error, two other log entries are
entry. The offsets are specified in hexadecimal and are created. The first (22-47) provides the actual RODM
based from the beginning of the log data. The lengths return code and reason code. The second (78-76 or
are specified in decimal. 78-77) identifies the targeted object (and possibly the
Offset al The RODM return codes, reason codes, function IDs,
Length and other API information are described in the IBM Z
0000 4 The number of characters in the
class name.
0004 k The name of object class. The in the IBM Z NetView Data Model Reference. Use this
name is shown in character, not information to diagnose and correct the problem.
hexadecimal, format.
If the topology manager ended, restart the topology
0004+k 4 The number of characters in the manager and the monitor operations for the agent
object name. nodes. If you warm-start the topology manager, the
existing monitor operations are restarted by the
topology manager. Otherwise, restart the monitor The RODM return codes, reason codes, function IDs,
operation that ended. and other API information are described in the IBM Z
Trace Data Programmer's Guide. Refer to the topology data model,
The format of the additional data provided in the log in the IBM Z NetView Data Model Reference. Use this
entry. The offsets are specified in hexadecimal and are information to diagnose and correct the problem.
are specified in decimal. If the topology manager ended, restart the topology
manager and the monitor operations for the agent
Hex Decim Description nodes. If you warm-start the topology manager, the
Offset al existing monitor operations are restarted by the
Length topology manager. Otherwise, restart the monitor
operation that ended.
0000 8 The RODM object ID of the link or
port object.
Trace Data
indicator used by the topology The format of the additional data provided in the log
manager to map the RODM return entry. The offsets are specified in hexadecimal and are
and reason codes. based from the beginning of the log data. The lengths
78-79 Hex Decim Description
Offset al
Explanation Length
The topology manager encountered an unexpected 0000 2 The internal RODM error code
RODM error while trying to create an object. The indicator used by the topology
failure occurred while the topology manager was manager to map the RODM return
creating the object in the RODM data cache, updating and reason codes.
the DisplayResourceOtherData field, or setting
the initial values of the object attributes. The RODM 0002 k The name of the object that cannot
error code indicator provided is an internal indicator be created. This is the value of the
used to map the error codes received from RODM into MyName field in the RODM data
a contiguous set of values. See “Internal RODM Error cache. The format of this name for
Code Indicator” on page 408 for the table showing the the topology manager RODM
mapping of the RODM return codes and reason codes objects is described in the IBM Z
to this internal error indication. NetView Data Model Reference. The
name is shown in character (not
The object that cannot be created is identified by its hexadecimal) format.
name. These objects are created when topology
information is received from the agent nodes. 78-80
Depending upon the severity of the error, the topology
manager ends or retries the related monitor operation
Explanation
based on the ERRLIMIT value. The ERRLIMIT value
can be changed by the TOPOSNA SETDEFS,ERRLIMIT The topology manager encountered an unexpected
command. RODM error while trying to update the
DisplayResourceOtherData attribute of a logical
User response link or port object.
Use the mapping of the internal error indicator and the The object that cannot be read or updated is identified
RODM function ID to determine the probable RODM by its RODM object ID. These objects are updated
return and reason codes. If the internal error indicator when topology information is received from the agent
is an unrecoverable error, two other log entries are nodes. Depending upon the severity of the error, the
created. The first (22-47) provides the actual RODM topology manager ends or retries the related monitor
return code and reason code. The second (78-76 or operation based on the ERRLIMIT value. The
78-77) identifies the targeted object (and possibly the ERRLIMIT value can be changed by the TOPOSNA
field) within the RODM data cache. SETDEFS,ERRLIMIT command.

User response attribute of a graph (aggregate) object. An associated
log entry is created with minor code 71. This
associated log entry contains the RODM error
indicator.
is an unrecoverable error, two other log entries are The object that cannot be read is identified by its name
created. The first (22-47) provides the actual RODM and its graph type. These objects are created when
return code and reason code. The second (78-76 or topology information is received from the agent nodes.
78-77) identifies the targeted object (and possibly the Depending upon the severity of the error, the topology
field) within the RODM data cache. manager ends or retries the related monitor operation
based on the ERRLIMIT value. The ERRLIMIT value
can be changed by the TOPOSNA SETDEFS,ERRLIMIT
command.
which describes the topology manager RODM objects User response
in the IBM Z NetView Data Model Reference. Use this Use the error information in the associated log entry to
information to diagnose and correct the problem. resolve the problem.
If the topology manager ended, restart the topology If the topology manager ended, restart the topology
manager and the monitor operations for the agent manager and the monitor operations for the agent
nodes. If you warm-start the topology manager, the nodes. If you warm-start the topology manager, the
existing monitor operations are restarted by the existing monitor operations are restarted by the
topology manager. Otherwise, restart the monitor topology manager. Otherwise, restart the monitor
operation that ended. operation that ended.
Trace Data Trace Data

The format of the additional data provided in the log The format of the additional data provided in the log
entry. The offsets are specified in hexadecimal and are entry. The offsets are specified in hexadecimal and are
based from the beginning of the log data. The lengths based from the beginning of the log data. The lengths
are specified in decimal. are specified in decimal.
Offset al
Length
0000 8 The RODM object ID of the
aggregate object.
and reason codes.
000A k The value of the
DisplayResourceOtherData
attribute that cannot be stored.
The format of this attribute for the
topology manager RODM objects is
described in the IBM Z NetView
Data Model Reference. The data is
shown in character (not
78-81
Explanation
RODM error while trying to read the FLB_Creator
Offset al Offset al
Length Length
0000 2 The type of aggregate object. 12
class name
(1.3.18.0.0.6708), graph 0002 k The name of the aggregate object
type nnDomain. that cannot be created. This is the
2 value of the MyName field in the
NN domain network. RODM RODM data cache. The format of
class aggregateGraph2, this name for the topology
ASN.1 object identifier and manager RODM objects is
RODM class name described in the IBM Z NetView
(1.3.18.0.0.6708), graph Data Model Reference. The name is
type nnDomain. shown in character (not
3
NN domain network cluster.
RODM class 78-82
object identifier and RODM Explanation
class name The topology manager encountered an error
(1.3.18.0.0.6708), graph processing an update for an intersubnetwork TG.
type nnDomain. Possible causes are as follows:
4
• The network IDs of the nodes connected by the
intersubnetwork TG are the same. APPN enables a
network to be divided into subnetworks based on
network IDs. APPN also enables the network to be
class name
divided into subnetworks where the nodes in the
(1.3.18.0.0.2152), graph ID
subnetworks have the same network ID. This feature
SnaLocalTopo.
is called clustering. Clusters are connected by
5 extended border nodes, and do not share topology
Super cluster view. RODM information. The topology manager supports this
class Network_View_Class feature of APPN, but requires topology agents on the
RODM class name extended border node nodes to actually divide the
(Network_View_Class). network. The topology manager does not provide
6 agents for any nodes that can be extended border
Interdomain circuit. RODM nodes.
class circuit2, ASN.1 object • The topology manager encountered an internal error
identifier and RODM class while processing the update for the intersubnetwork
name (1.3.18.0.0.2186). TG.
7 • The topology manager encountered a RODM error
Interdomain network circuit. while processing the update for the intersubnetwork
RODM class circuit2, ASN.1 TG.
class name Associated log entries are created to identify the
(1.3.18.0.0.2186). specific cause of the error. Refer to the description of
these log entries to determine what actions the
topology manager takes when this error occurs.

User response Hex Decim Description
Use the error information in the associated log entry to Offset al
resolve the problem. Length
78-83 0000 8 The RODM object ID of the object.

Explanation indicator used by the topology
The topology manager encountered an unexpected and reason codes.
RODM error while trying to update or query an object
in the RODM data cache. Depending upon the severity
78-84
of the error, the topology manager ends or retries the
related monitor operation based on the ERRLIMIT
value. The ERRLIMIT value can be changed by the Explanation
TOPOSNA SETDEFS,ERRLIMIT command. The topology manager encountered an unexpected
The RODM error code indicator that is provided is an RODM error while trying to delete a node object in the
internal indicator used to map the error codes received RODM data cache. An associated log entry is created
from RODM into a contiguous set of values. See the with minor code 71. This associated log entry contains
“Internal RODM Error Code Indicator” on page 408 for the RODM error indicator.
the table showing the mapping of the RODM return The object that cannot be deleted is identified by its
codes and reason codes to this internal error name and RODM object ID. The topology manager
indication. attempted to delete the object because an update was
received that changed the node type (class) of the
User response node. The topology manager cannot process the
update because the new node object (in the new class)
cannot be created while the old object still exists in
the RODM data cache. Depending upon the severity of
the error, the topology manager ends or retries the
related monitor operation based on the ERRLIMIT
value. The ERRLIMIT value can be changed by the
TOPOSNA SETDEFS,ERRLIMIT command.
User response
and other API information are described in the IBM Z Use the error information in the associated log entry to
NetView Resource Object Data Manager and GMFHS resolve the problem. This error, along with possible
Programmer's Guide. Refer to the topology data model, resolution actions, is also described in “Objects are
which describes the topology manager RODM objects not purged” on page 347.
in the IBM Z NetView Data Model Reference. Use this If the topology manager ended, restart the topology
information to diagnose and correct the problem. manager and the monitor operations for the agent
If the topology manager ended, restart the topology nodes. If you warm-start the topology manager, the
manager and the monitor operations for the agent existing monitor operations are restarted by the
nodes. If you warm-start the topology manager, the topology manager. Otherwise, restart the monitor
existing monitor operations are restarted by the operation that ended.
topology manager. Otherwise, restart the monitor
operation that ended. Trace Data
Trace Data entry. The offsets are specified in hexadecimal and are
The format of the additional data provided in the log based from the beginning of the log data. The lengths
entry. The offsets are specified in hexadecimal and are are specified in decimal.
are specified in decimal. Hex Decim Description
Offset al
Length
Hex Decim Description 78-191
Offset al
Length Explanation
0008 k The name of the node object that During initialization, the SNA topology manager was
cannot be deleted. This is the unable to read a required class or field from RODM
value of the MyName field in the (this implies that the data model is not entirely
RODM data cache. The format of loaded). The name of the class or field is logged.
this name for the topology
manager RODM objects is User response
described in the IBM Z NetView
Data Model Reference. The name is Load the GMFHS data model, then load the SNA
shown in character (not topology data model or wait until the data model is
hexadecimal) format. entirely loaded before starting the SNA topology
manager. When this error is detected, message
78-173 FLB686E is also issued, and the SNA topology
manager tries to read the RODM data model based on
the RODM retry and the retry limit values specified in
Explanation FLBSYSD or with the SETDEFS command.
When creating an object in RODM, the topology
manager discovered more than one object in RODM Trace Data
with the same DisplayResourceName. This condition
occurs if a user-created object in RODM has the same The format of the additional data provided in the log
DisplayResourceName as the topology manager entry. The offsets are specified in hexadecimal and are
created object. The RODM object identifier is logged based from the beginning of the log data. The lengths
with this log entry. are specified in decimal.

If the object was created by user, delete the object Length
and create it with a different DisplayResourceName. If 0000 4 A value of 0 indicates a class, a
the object was not user-created, contact IBM Software value of 1 indicates a field.
Support. The monitor action trying to create this object
might fail. 0004 Variabl The name of the missing class or
e field.
Trace Data

Offset al
Length
0000 16 The object identifier of the RODM
object which has the duplicate
DisplayResourceName.
Internal RODM Error Code Indicator

Many of the log entries provide an internal error code indicator that is used to represent the actual return
code and reason code received from RODM. Use the following table to map the internal value to its
corresponding RODM reason codes.
Value
RODM reason codes

0
Successful. Set when the RODM return code is zero (0), or when the following reason codes are
returned:
Code
RODM function
0
All functions
24
EKG_ChangeField, EKG_LinkTrigger, EKG_UnlinkTrigger, EKG_CreateObject, EKG_DeleteObject
26
EKG_ChangeField EKG_TriggerOIMethod, EKG_TriggerNamedMethod
30
EKG_Connect
142
EKG_LinkTrigger
143
EKG_QueryField, EKG_QuerySubfield
178
EKG_Connect
180
EKG_Disconnect
32769
32770
45081
NetView GMFHS methods DUIFCLRT and DUIFCUAP
1
Delete failed. Set when the following reason codes are returned:
Code
RODM function
75
EKG_UnlinkTrigger
111
EKG_DeleteObject
45057
NetView GMFHS method DUIFCUAP
2
Object or object link does not exist. Set when the following reason codes are returned:
Code
RODM function
54
EKG_ChangeField EKG_LinkTrigger, EKG_UnlinkTrigger, EKG_QueryField, EKG_QuerySubfield
EKG_DeleteObject, EKG_TriggerNamedMethod
57
EKG_ChangeField EKG_LinkTrigger, EKG_UnlinkTrigger, EKG_QueryField, EKG_QuerySubfield
EKG_DeleteObject, EKG_TriggerNamedMethod
3
Object class does not exist. Set when the following reason codes are returned:
Code
RODM function
52
4
Object or object link exists. Set when the following reason codes are returned:
Code
RODM function
72
EKG_LinkTrigger
110
EKG_CreateObject
45058
NetView GMFHS method DUIFCUAP
5
Retryable error. Set when the RODM return code is 4, or when the following reason codes are
returned:
Code
RODM function
2
EKG_Connect
3
EKG_Connect
5
EKG_Connect
6
EKG_Connect
7
All functions
11
EKG_TriggerOIMethod
13
EKG_Connect
15
All functions
16
EKG_Connect
68
EKG_ChangeField
108
EKG_DeleteObject
121
EKG_CreateObject
122
EKG_ChangeField, EKG_LinkTrigger, EKG_CreateObject
123
EKG_CreateObject
133
EKG_ChangeField, EKG_LinkTrigger, EKG_UnlinkTrigger

134
EKG_ChangeField
156
EKG_CreateObject
179
EKG_Connect
188
EKG_CreateObject
198
EKG_Connect, EKG_Disconnect
199
EKG_Connect
200
EKG_Connect
216
EKG_DeleteObject
45061
NetView GMFHS methods DUIFCLRT and DUIFCUAP
6
Checkpoint in progress. Set when the following reason codes are returned:
Code
RODM function
1
All functions
23
All functions
7
Unrecoverable error. Set when the RODM return code is 8, 12, or any reason code other than the ones
listed for the other internal codes. When this error is set, the topology manager ends. The actual
RODM return code and reason code are logged using a log entry with major code 22 and minor code
47. Might cause FLBTOPO user abend (X'185') to help IBM Software Support in debugging the
problem.
8
Data truncated. Set when the following reason codes are returned:
Code
RODM function
208
Internal RODM Class Indicator

Some of the log entries and trace records include an indicator used to represent the class of the objects in
RODM. Use the following table to map the internal value to its corresponding RODM class.
Value
RODM class name
1
UniversalClass
2
EKG_SystemDataParent
3
EKG_System
4
EKG_User
5
EKG_NotificationQueue
6
EKG_Method
7
Network_View_Class
8
FLB_Defaults
9
1.3.18.0.2.6.3 (netIDSubNetwork)
10
2.9.3.2.3.13 (system)
11
1.3.18.0.0.2155 (managerApplication)
12
1.3.18.0.0.1839 (snaNode)
13
1.3.18.0.0.1843 (t2_1Node)
14
1.3.18.0.0.1821 (appnEN)
15
1.3.18.0.0.1822 (appnNN)
16
1.3.18.0.0.1827 (lenNode)
17
1.3.18.0.0.1826 (interchangeNode)
18
1.3.18.0.0.1833 (migrationDataHost)
19
1.3.18.0.0.1849 (virtualRoutingNode)
20
1.3.18.0.0.6708 (aggregateGraph2)
21
1.3.18.0.0.2152 (snaLocalTopo)
22
1.3.18.0.0.1823 (appnTransmissionGroup)
23
1.3.18.0.0.2058 (appnTransmissionGroupCircuit)
24
1.3.18.0.0.2186 (circuit2)
25
1.3.18.0.0.2085 (logicalLink)
26
1.3.18.0.0.2089 (port)
27
1.3.18.0.0.1845 (t5Node)
28
1.3.18.0.0.1844 (t4Node)

29
1.3.18.0.0.2267 (definitionGroup)
30
1.3.18.0.0.2278 (crossDomainResourceManager)
32
1.3.18.0.0.2281 (crossDomainResource)
33
1.3.18.0.0.1829 (logicalUnit)
38
1.3.18.0.0.2240 (subareaTransmissionGroupCircuit)
The RODM error code indicator provided is an internal indicator used to map the error codes received
from RODM into a contiguous set of values. See “Internal RODM Error Code Indicator” on page 408 for
the table showing the mapping of the RODM return codes and reason codes to this internal error
indication.
Common log entries-Major Code 79
NOTICE
chapter, contact IBM Software Support.
These log entries are created whenever a component of the topology manager detects an error. These log
entries can be created by any of the components of the topology manager. Usually, there are associated
log entries or messages that describe the consequences of the failure. In most cases the task that
detected the problem ends.
79-0 Explanation
An unexpected error occurred using the C Program
Explanation library functions.
The task cannot allocate enough memory to
successfully complete a function. The task stops User response
processing the current request, and possibly ends. Record the information associated with this log entry
and contact IBM Software Support.
User response
79-2
Release any allocated memory that is not in use within
Explanation
suggestions are to stop any unneeded tasks or to
release any data storage not in use. If this problem A software problem has been detected in one of the
persists, restart the NetView program in a larger components of the topology manager.
address space. If you suspect that the memory
shortage is caused by a software problem, such as a User response
NetView task not freeing unused memory, dump the
NetView address space, and follow the instructions in Record the information associated with this log entry
Chapter 2, “Classifying problems,” on page 13 and and contact IBM Software Support.
Chapter 3, “Documenting and reporting problems,” on 79-3
page 23 before contacting IBM Software Support. The
storage estimates for the components of the topology
manager are described in the IBM Z NetView SNA Explanation
Topology Manager Implementation Guide. A software problem has been detected in one of the
components of the topology manager.
79-1
User response Hex Decim Description
Record the information associated with this log entry Offset al
and contact IBM Software Support. Length
79-64 0004 8 For IBM Software Support use
79-66
Explanation
A software problem has been detected in one of the Explanation
components of the topology manager.
An unexpected error occurred when a topology
manager task attempted to send the CMIP message to
User response
an agent node. The CMIP message that failed was
Record the information associated with this log entry being sent to cancel an existing CMIP operation. This
and contact IBM Software Support. error occurred while the task was ending. The task
continues shutdown processing by releasing all
79-65
allocated resources and then ending.
Explanation
User response
An error occurred when a topology manager task tried
to end its association with VTAM CMIP services. This
the cause of the error. Refer to the z/OS
error occurred while the task was ending. The task
Communications Server CMIP Services and Topology
continues shutdown processing by releasing all
Agent Guide for more information.
allocated resources and then ending.
The most probable cause of this error is that VTAM
User response CMIP services are not active. In most cases, this error
can be ignored because the task is already ending.
the cause of the error. Refer to the z/OS
Trace Data
Communications Server CMIP Services and Topology
Agent Guide for more information. The most probable The format of the additional data provided in the log
cause of this error is VTAM CMIP services are not entry. The offsets are specified in hexadecimal and are
active. In most cases, this error can be ignored based from the beginning of the log data. The lengths
because the task is already ending. are specified in decimal.
The task might have a problem establishing an Hex Decim Description
association with VTAM CMIP services when the task is Offset al
restarted and VTAM CMIP services remains active. Length
When this happens, stop and restart VTAM CMIP
services. Record the information associated with this 0000 4 The VTAM CMIP services error
log entry and contact IBM Software Support. code. Refer to the z/OS
Trace Data
0004 k For IBM Software Support use

Offset al
Length

SNA topology manager traces
The topology manager has various traces that are used by IBM Software Support to diagnose problems.
The operator can control the events and types of data to be traced by using the TOPOSNA TRACE
command. This data can be traced externally or internally by using the TOPOSNA TRACE,MODE=xxx
command, where xxx is EXT or INT (the default).
The TOPOSNA TRACE command can be issued at any time, even when the topology manager is not active.
This enables you to turn on traces before starting the topology manager so that initialization events can
be traced. The trace settings are not changed by the starting or stopping of the topology manager.
The types of events that are traced, along with the format of the trace records, is unique for the topology
manager. The trace information is used by IBM Software Support to diagnose problems reported by
customers. The availability of trace information significantly helps when IBM Software Support is
diagnosing a problem.
The trace events are grouped into trace categories. These trace categories are turned on or off by the
commands. A topology manager trace record is created when an event occurs, its associated trace
category is turned on. For external tracing (TOPOSNA TRACE,MODE=EXT), the topology manager GTF
event ID (X'05E8') must be enabled in GTF. The TOPOSNA TRACE command is fully described in NetView
online help.
The description of the command describes the trace categories available for the topology manager. Most
trace categories cause significant amounts of trace data to be captured, possibly affecting performance of
the topology manager and overflowing the GTF trace buffer. The amount of data captured by the trace
categories can be limited by the use of the CLASS parameter.
These trace categories, along with any data that can be gathered with a VTAM CMIP services trace,
capture the trace information most useful when reporting problems to IBM Software Support.
External tracing (GTF)

The topology manager has been assigned GTF event ID (X'05E8'). The GTF uses this ID to identify trace
data created by the topology manager task and command processor.
All external trace records created by the topology manager use GTF format ID (X'D8'). For the topology
manager to store external trace data, GTF must be enabled and the topology manager GTF event ID
(X'05E8') must be enabled. For information about using GTF, refer to the MVS library.
GTF trace record format

The topology manager trace header consists of some GTF information followed by information inserted by
the topology manager. The format of the GTF information is the same for all trace records. The format of
the topology manager information is the same for all trace records in the same trace category. The format
is dependent on the trace category.
Each GTF trace record contains the following information:
GTF information
Information common to all GTF trace records, such as time stamps, the associated GTF event ID, and
the GTF format ID.
Header information
Information common to all trace records created by the topology manager. This information is unique
for the topology manager. The format of this information is identified by the GTF event ID.
Event ID
The number used to identify the event being traced. The event ID, when combined with its associated
trace category, uniquely identifies each event traced by the topology manager. Do not confuse this
value with the unrelated GTF event ID.
Trace category
The trace categories are used to identify a set of trace events. The trace categories are turned on or
off by the trace commands. A topology manager trace record is created when an event occurs, its
associated trace category is turned on, and the topology manager GTF event ID (X'05E8') is enabled
within GTF.
Trace data
The data associated with the event being traced. The format of this data is unique for each event
traced (see “Trace events” on page 420). The GTF record format of the data is identified by the
combination of the trace category with the event ID. All GTF trace data is shown in hexadecimal as
well as character format, providing the hexadecimal value represents a valid EBCDIC character.
The topology manager and VTAM CMIP services cooperate when setting the trace event number. Each
traced event has a unique trace event number, unless the number wraps.
GTF trace record examples

Following are examples of the trace records created by the topology manager, formatted using common
GTF format options. The topology manager can capture more data than GTF might allow in a trace record.
If the data is too large to fit into one trace record, the topology manager splits the trace data across
several GTF trace records.
The example shows the following information:
• A trace record where all of the trace data fits into one GTF trace record.
• A multiple record trace event, where more than one record are needed to hold the data associated with
the traced event. Only the first two records of a ten record event are shown in the example.
• The fields that make up the trace records.
A single record trace event
1 2
GMT-01/14/2019 15:58:11.341367 LOC-01/14/2019 10:58:11.341367
3 4
HEXFORMAT AID FF FID D8 EID E5E8
5 6
+0000 00FB6B80 E2F5F4F0 C5C5D5E5 0000003D | ..,.S540EENV.... |
7 8 9 10
+0010 00010001 4003000E E2D5C160 E3D44040 | .... ...SNA-TM |
11 12
+0020 E3C4D4D5 40404040 00000399 00100F90 | TDMN ...r.... |
+0030 0000 | .. |
A multi-record trace event
record 1 of 10
1 2
GMT-01/14/2019 15:58:12.530275 LOC-01/14/2019 10:58:12.530275
3 4
5 6
+0000 00FB6B80 E2F5F4F0 C5C5D5E5 0000003E | ..,.S540EENV.... |
7 8 9 10
+0010 0001000A 4003000E E2D5C160 E3D44040 | .... ...SNA-TM |
11 12
+0020 E3C4D4D5 40404040 00000000 00100F90 | TDMN ........ |
+0030 00200000 00000006 00070000 00060000 | ................ |
+0040 00013C43 00130000 00000000 00000ED8 | ...............Q |
+0050 9384A299 8360A3A8 978540F1 6B40A299 | ldsrc-type 1, sr |
+0060 834081F1 6B4094A2 8740C3D4 C9D760F1 | c a1, msg CMIP-1 |
+0070 4BD9D6C9 E5819784 A4404D89 95A59692 | .ROIVapdu (invok |
+0080 85C9C440 F1F3F1F1 F7F26B40 93899592 | eID 131172, link |
+0090 858460C9 C440F3F9 F3F2F2F3 6B409697 | ed-ID 393223, op |
+00A0 859981A3 89969560 A58193A4 8540F26B | eration-value 2, |
+00B0 40819987 A4948595 A3404D81 83A38996 | argument (actio |
+00C0 95D985A2 A493A340 4D948195 81878584 | nResult (managed |
+00D0 D6829185 83A3C393 81A2A240 F14BF34B | ObjectClass 1.3. |
+00E0 F1F84BF0 4BF04BF2 F2F9F16B 40948195 | 18.0.0.2291, man |
+00F0 81878584 D6829185 83A3C995 A2A38195 | agedObjectInstan |
+0100 8385404D 8489A2A3 899587A4 | ce (distingu |
record 2 of 10
1 2
GMT-01/14/2019 15:58:12.530743 LOC-01/14/2019 10:58:12.530743

3 4
5 6
+0000 00FB6B80 E2F5F4F0 C5C5D5E5 0000003E | ..,.S540EENV.... |
7 12
+0010 0002000A 89A28885 84D58194 85404DD9 | ....ishedName (R |
+0020 859381A3 89A585C4 89A2A389 9587A489 | elativeDistingui |
+0030 A2888584 D5819485 404DC1A3 A3998982 | shedName (Attrib |
+0040 A4A385E5 8193A485 C1A2A285 99A38996 | uteValueAssertio |
+0050 95404D81 A3A39989 82A4A385 E3A89785 | n (attributeType |
+0060 40F14BF3 4BF1F84B F04BF24B F44BF66B | 1.3.18.0.2.4.6, |
+0070 4081A3A3 998982A4 A385E581 93A48540 | attributeValue |
+0080 7FE4E2C9 C2D4D5E3 7F5D5D6B 40D98593 | "USIBMNT")), Rel |
+0090 81A389A5 85C489A2 A3899587 A489A288 | ativeDistinguish |
+00A0 8584D581 9485404D C1A3A399 8982A4A3 | edName (Attribut |
+00B0 85E58193 A485C1A2 A28599A3 89969540 | eValueAssertion |
+00C0 4D81A3A3 998982A4 A385E3A8 978540F1 | (attributeType 1 |
+00D0 4BF34BF1 F84BF04B F04BF2F0 F3F26B40 | .3.18.0.0.2032, |
+00E0 81A3A399 8982A4A3 85E58193 A485407F | attributeValue " |
+00F0 D5E3C4F5 D4E5E27F 5D5D6B40 D9859381 | NTD5MVS")), Rela |
+0100 A389A585 C489A2A3 899587A4 | tiveDistingu |
1
When the event occurred, in Greenwich Mean Time (GMT).
2
When the event occurred, in local time.
3
The GTF format ID of the record.
4
The GTF event ID of the record. This specifies the format of the data in the trace record. Ignore the
high-order nibble (half-byte).
5
Twelve bytes of GTF information.
6
The trace event number. All the trace records used to capture the trace data for an event have the
same record number. Each event traced is assigned a unique trace event number.
7
The multiple record trace data information. The first two bytes are the record number (x) within a
traced event and the next two bytes are the total number of records (y) used to capture the data
associated with the event. The value can be read as record x of y. The beginning of the data for a
traced event is indicated by a value of one for the record number (x) and the end of the data is
reached when the record number equals the total number of records (x=y).
8
The trace category of the traced event. Only present in the first trace record of a multiple record
event.
9
The event ID of the traced event. Only present in the first trace record of a multiple record event.
10
The 8-character name of the component within topology manager that generated the record:
SNA-TM
Only present in the first trace record of a multiple record event.

11
The 8-character name of the internal topology manager subcomponent that generated the record. For
use by IBM Software Support.
Only present in the first trace record of a multiple record event.
12
The data associated with the traced event. The format depends on the event, identified by the
combination of the trace category and event ID. The beginning of the trace data within a record varies.
The trace data starts at X'28' within the first trace record created for an event. The data starts at X'14'
in all other records.
Tracing internally
The topology manager can trace events to an internal wrap-buffer by using the TOPOSNA
TRACE,MODE=INT command. A SIZE parameter is also available to specify the size of this buffer in 4096-
byte page increments. Although the traced event contains the same data, the internal trace format differs
from the external (GTF) trace.
Internal trace buffer format

The internal trace buffer is easily identified by its eye-catcher, INTTRACE. Table 143 on page 418 maps
the format of the internal trace buffer header.
Table 143. SNA Topology Manager Internal Trace Buffer Header Format
Hexadecimal Description
Offset
0000 Topology manager internal trace table identifier 'INTTRACE'
0008 The number of 4096-byte pages allocated to the topology manager internal trace table
(values range 10 - 999)
000C Current size of table (in bytes) not including this header
0010 Maximum size in bytes that the internal trace table has reached
0014 Timestamp of most recent wrap
0018 Timestamp of previous wrap
001C Pointer to start of next trace entry to be written
0020 Reserved 16 characters
0030 Start of first internal trace record
Internal trace record header

Each internal trace record starts with an internal trace record header as shown in Table 144 on page 419.

Table 144. SNA Topology Manager Internal Trace Record Header
Offset
0000 One of the following 4-byte eye-catchers:
CBEG
Topology manager command started
CEND
Topology manager command ended
CENT
Topology manager call signal entry
CEXT
Topology manager call signal exit
CMIP
CMIP record
DEL
Topology manager object deleted
FREE
Topology manager storage pool or storage heap FREE
FSM
FSM state change
GET
Topology manager storage pool or storage heap GET
LOGS
Probe logged
MSGS
Message logged
NEW
Topology manager object created
RARY
RODM array
RATR
RODM Attribute information
RCLS
RODM class information
ROBJ
RODM Objectid only information
RON
RODM Objectid and name information
RTIB
RODM function call result
UPDT
Object updates
XMOG
Node transformation
0004 The length of the internal trace record, including this header
0008 The 4-byte subcomponent ID
000C Start of trace event data for this record
Trace events
These are the events that are traced by the topology manager and can be used to diagnose problems. The
events are identified by the associated trace category and event ID, followed by the internal trace eye-
catcher that is enclosed in parenthesis.
The trace data offsets are specified in hexadecimal from the start of the trace event data. An offset of zero
actually starts at X'0028' in the GTF trace record and at X'000C' in the internal buffer trace record.
4000-0002 (CENT)
Event Description
Traces processing signals between internal topology manager objects. Traces the entry point for a
particular signal.
If you trace using the TOPOSNA ON=SIGNALS command, you trace a large amount of data. You can
specify the CLASS keyword on the TOPOSNA TRACE command to control the object classes that are
traced.
Table 145. Trace Data for Event 4000-0002 (CENT)

Offset
0000 Class of target object
0004 Address of target object
0008 Name of target object
0038 Type of signal
003C Size of variable length parameter list
0040 Start of variable length parameter list
4000-0003 (CEXT)
Event Description
Traces processing signals between internal topology manager objects. Traces the exit point for a
particular signal.
If you trace using the TOPOSNA ON=SIGNALS command, you trace a large amount of data. You can
specify the CLASS keyword on the TOPOSNA TRACE command to control the object classes that are
traced.
Table 146. Trace Data for Event 4000-0003 (CEXT)

Offset
0004 Address of target object
0038 Type of signal
003C Return code
0040 Size of variable length parameter list
0044 Start of variable length parameter list

4000-0008 (LOGS)
Event Description
Traces topology manager log entries. This event is traced using the TOPOSNA TRACE,ON=LOG command.
Table 147. Trace Data for Event 4001-0008 (LOGS)

Offset
0000 Log entry major code
0004 Log entry minor code
0008 ProbeID
000C Length of first data area
000E Length of second data area
0010 Length of third data area
0012 Length of fourth data area
0014 Length of fifth data area
0016 Length of sixth data area
0018 Length of seventh data area
001A Length of eighth data area
001C Length of ninth data area
001E Data areas according to above lengths
4002-0007 (MSGS)
Event Description
Traces topology manager messages. This event is traced using the TOPOSNA TRACE,ON=MESSAGES
command.
Table 148. Trace Data for Event 4002-0007 (MSGS)

Offset
0000 Message number
0004 Message type
0005 Was message displayed (0 = yes, 1 = no)
0006 Operator ID
000E Probe ID of message invoker
0012 Length of first message insert
0014 Length of second message insert
0016 Length of third message insert
0018 Length of fourth message insert
001A Length of fifth message insert
Table 148. Trace Data for Event 4002-0007 (MSGS) (continued)
Offset
001C Length of sixth message insert
001E Length of seventh message insert
0020 Length of eighth message insert
0022 Length of ninth message insert
0024 Message inserts according to above lengths
4003-000E (CMIP)
Event Description
The topology manager received data from VTAM CMIP services or received a command from the topology
manager command processor. This event is also triggered when the time period expires for a pending
operation. The topology manager processes the received data and any pending operations that have
timed out. This event is traced using TOPOSNA TRACE,ON=CMIP.
This trace record shows the received data, which can be:
• A TOPOSNA command to be processed.
The first byte of the received data is X'7F'. The issued command is converted into the internal command
buffer shown in this trace record by the topology manager command processor. The command buffer is
reserved for the use of IBM Software Support. The occurrence of these records indicates the occurrence
of a command. The network log contains the actual command issued.
• An inbound CMIP message.
The entire message is shown, including the internal routing information at the beginning of the string.
The actual CMIP message begins:
RORSapdu
The message is a response to a previous request sent by the topology manager. The invokeID field
in the message identifies the invoke ID of the transaction. This is the final response for the
transaction.
ROIVapdu
The message is a linked reply to a previous request sent by the topology manager. The linked-ID
field in the message identifies the invoke ID of the transaction started by the request. Other
responses will be forthcoming.
• A VTAM CMIP services message.
The entire message is shown, including the internal routing information at the beginning of the string.
The actual message begins with:
Service-accept
A requested operation successfully completed.
Service-reject
VTAM CMIP services encountered an error processing a topology manager request.
Table 149. Trace Data for Event 4003-000E (CMIP)

Offset
0000 The VTAM CMIP services error code. Refer to the z/OS Communications Server CMIP
Services and Topology Agent Guide for more information.

Table 149. Trace Data for Event 4003-000E (CMIP) (continued)
Offset
0004 Internal routing information. For IBM Software Support use
0008 If the received data is a CMIP message from VTAM CMIP services, this value is the
Hexadecimal Offset of the start of the CMIP message in the data area. If the received
data is not a CMIP message, this value is not defined.
0010 The received data.
Response
If the received data is a CMIP message, the offset of the start of the message in the received data is
specified by the preceding field in the trace data. The format of the CMIP response is described in the IBM
SystemView library.
The response is an ASN.1 string. The received ASN.1 string is EBCDIC character data. The trace record
shows the hexadecimal representation of this data. The actual character information is usually also
shown in the formatted trace information.
4004-0019 (RTIB)
Event Description
The results from a RODM function invoked by the topology manager. This event is traced using the
TOPOSNA TRACE,ON=RODM command.
The RODM function IDs, return codes, and reason codes are described in the IBM Z NetView Resource
Object Data Manager and GMFHS Programmer's Guide. The RODM return codes and reason codes are also
described in NetView online help.
Table 150. Trace Data for Event 4004-0019 (RTIB)

Offset
0000 The RODM function ID. This identifies the invoked RODM function.
0004 The RODM return code.
0008 The RODM reason code.
000C The size of the response buffer.
0010 Up to the first 100 bytes of the response buffer. No data is present if the size of the
response buffer is zero (0).
4004-001A (RARY)
Event Description
The topology manager invoked to perform a number of functions in a RODM ExecuteFunctionList.
This trace record, which is traced using the TOPOSNA TRACE, ON=RODM command, contains the results
from one of the functions in the list. All functions in the list are traced by creating multiple trace entries.
The RODM function IDs, return codes, and reason codes are described in the IBM Z NetView Resource
Object Data Manager and GMFHS Programmer's Guide . The RODM return codes and reason codes are also
described in the NetView online help.
Table 151. Trace Data for Event 4004-001A (RARY)
Offset
0000 The RODM function ID. This identifies the invoked RODM function.
0002 The RODM return code.
0006 The RODM reason code.
4005-0015 (RCLS)
Event Description
The topology manager is preparing to invoke a RODM function. This trace event, along with the
corresponding events 4005-0016, 4005-0017, and 4005-0018, identify the RODM object class, object
instances, and object attributes specified in the function. This trace record, which is traced using the
TOPOSNA TRACE,ON=RODMDUMP command, identifies the class of the objects.
The RODM function IDs are described in the IBM Z NetView Resource Object Data Manager and GMFHS
Programmer's Guide.
Table 152. Trace Data for Event 4005-0015 (RCLS)

Offset
0000 The RODM function ID. This identifies the RODM function to be invoked.
0002 Some RODM functions operate on two objects (such as LinkTrigger and UnlinkTrigger).
This field identifies which object class is being traced. A value of one indicates this
trace record is related to the first object and a value of two indicates information about
the second object is being traced.
0004 The internal class indicator used by the topology manager to represent the RODM
object classes. See “Internal RODM Class Indicator” on page 411 for the table showing
the mapping of the RODM object classes to this internal indication.
0006 A 4-byte value that indicates the RODM class ID. Every class in RODM is assigned an
ID after RODM is started and the class is defined. This value can change if a class is
added or deleted.
4005-0016 (RON)
Event Description
instances, and object attributes specified in the function. This trace record which is traced using the
TOPOSNA TRACE,ON=RODMDUMP command, along with 4005-0017, identifies the object instances. This
record is created when the topology manager specifies the object using the name of the object (the
contents of the MyName field).
Programmer's Guide.
Table 153. Trace Data for Event 4005-0016 (RON)

Offset

Table 153. Trace Data for Event 4005-0016 (RON) (continued)
Offset
0004 The RODM object ID of the object. This value might not be defined.
000C The name of the RODM object.
4005-0017 (ROBJ)
Event Description
TOPOSNA TRACE,ON=RODMDUMP command, along with 4005-0016, identifies the object instances. This
record is created when the topology manager specifies the object using the RODM object ID of the object.
Programmer's Guide.
Table 154. Trace Data for Event 4005-0017 (ROBJ)

Offset
0004 The RODM object ID of the object.
4005-0018 (RATR)
Event Description
TOPOSNA TRACE,ON=RODMDUMP command identifies the object attributes.
Programmer's Guide.
Table 155. Trace Data for Event 4005-0018 (RATR)

Offset
Table 155. Trace Data for Event 4005-0018 (RATR) (continued)
Offset
0004 An internal indicator used by the topology manager to identify the object attribute. For
IBM Software Support use
0006 A 4-byte value that indicates the RODM field ID (also called the RODM attribute ID).
Every attribute in RODM is assigned an ID after RODM is started and the attribute is
defined. This value can change if an attribute is added or deleted.
4007-001E (UPDT)
Event Description
Traces a status flow. This event is traced using the TOPOSNA TRACE,ON=UPDATE command. Note that
the update tracing can be limited to particular classes using the CLASS keyword of the TOPOSNA TRACE
command.
Table 156. Trace Data for Event 4007-001E (UPDT)

Offset
0000 ProbeID of invoker
0004 Timestamp
0038 Update attributes in the following format:
X'00'
Attribute Identifier
X'02'
Size of the attribute value
X'04'
Varying length attribute value
More than one set of update attributes can be present.
4008-0000 (GET)
Event Description
An internal topology manager storage allocation request directed to the C runtime heap or the topology
manager internal storage pool manager. This trace event is traced using the TOPOSNA
TRACE,ON=STORAGE command.
Table 157. Trace Data for Event 4008-0000 (GET)

Offset
0000 ProbeID of storage owner (invoker)

Table 157. Trace Data for Event 4008-0000 (GET) (continued)
Offset
0004 Requested size
0008 Address of allocated storage or zero if storage request failed
000C A 4-byte storage identifier. A value of X'FFFF' indicates the request was for heap
storage, all other values indicate storage pool requests.
4008-0001 (FREE)
Event Description
An internal topology manager storage free request directed to the C runtime heap or the topology
manager internal storage pool manager. Trace using TOPOSNA TRACE,ON=STORAGE.
Table 158. Trace Data for Event 4008-0001 (FREE)

Offset
0000 ProbeID of storage owner (invoker)
0004 Address of storage to be freed
0008 A 4-byte storage identifier. A value of X'FFFF' indicates the request was for heap
storage, all other values indicate storage pool requests.
4009-0006 (FSM)
Event Description
Traces Finite State Machine state changes of internal topology manager objects. This event is traced using
the TOPOSNA TRACE,ON=FSM command.
Table 159. Trace Data for Event 4009-0006 (FSM)

Offset
0000 Class of object
0004 Address of object
0008 FSM name
0010 FSM input value
0014 FSM original state
0018 FSM new state
001C A 4-byte FSM output value
400A-0004 (NEW)
Event Description
Traces the allocation of an internal topology manager object. This event is always traced.
Table 160. Trace Data for Event 400A-0004 (NEW)
Offset
0004 Timestamp
0008 Name of allocated object
0036 Class identifier
0038 48 bytes of reserved data
0068 Address of allocated object
006C Variable-length parameter list
400A-0005 (DEL)
Event Description
Traces the deletion of an internal topology manager object. This event is always traced.
Table 161. Trace Data for Event 400A-0005 (DEL)

Offset
0004 Timestamp
0008 Name of deleted object
0036 Class identifier
0038 Address of the deleted object
400A-001B (CBEG)
Event Description
Traces the start of a topology manager command. This event is always traced.
Table 162. Trace Data for Event 400A-001B (CBEG)

Offset
0000 Timestamp
0008 Variable-length parameter list
400A-001C (CEND)
Event Description
Traces the end of a topology manager command. This event is always traced.

Table 163. Trace Data for Event 400A-001C (CEND)
Offset
0000 Timestamp
0028 Variable-length parameter list
400A-001D (XMOG)
Event Description
Traces the transformation of a node from one class to another. This event is always traced.
Table 164. Trace Data for Event 4008-0000 (GET)

Offset
0004 Timestamp
0008 Name of node being transformed
0036 Class of node being transformed
0038 Name of object performing the transformation
0066 New class of the node being transformed
0068 A 4-byte return code
VTAM CMIP Traces

VTAM CMIP traces are required for debugging topology manager problems. Refer to the z/OS
Communications Server CMIP Services and Topology Agent Guide for more information.
Recovery from Trace Errors

There are two types of trace errors you usually see. The first is when you try to start trace categories, and
the associated GTF event IDs are not enabled. The trace categories you requested to be turned on are not
started, and the following message is issued:
FLB636W THE TRACE REQUEST SPECIFIES THAT TRACING BE TURNED ON BUT

THE GTF TRACE CATEGORY tracecat IS NOT ACTIVE
Enable the indicated GTF event IDs, and then issue the trace command again.
The second error is that a problem occurs while you are collecting trace data. A failure occurs while a
topology manager task is storing data in GTF. The following message is issued:
FLB637E TASK taskname FAILED TO WRITE TRACE DATA USING GTF BECAUSE
OF AN ERROR
A log entry is created when this message is issued. Use the information in this log entry (major code 22,
minor code 56) to resolve the problem. The task continues to trace information, but does not display this
message again until it has successfully stored trace information.
TOPOSNA LISTxxxx Requests

The LISTxxxx requests of the TOPOSNA command provide valuable diagnostic information. The LISTxxxx
requests are:
LISTREQS
Using the TOPOSNA LISTREQS, you can determine:
• All nodes being monitored for network topology
• All nodes being monitored for local topology
• All nodes being monitored for LU topology.
LISTRODM
The TOPOSNA LISTRODM command lists RODM activity and object counts, including the number of
calls issued against an object type for:
• CREATE
• DELETE
• UPDATE
• QUERY
• LINK/UNLINK
Also listed is the number of times the FLBTRST method was invoked for the object type (status
change), and a count of the current number of object instances of the object type currently or
previously known to the topology manager.
LISTSTOR
The TOPOSNA LISTSTOR command lists internal topology manager storage usage by resource type,
including the total amount of storage currently used by the resource type and the maximum amount
of storage that the resource type has used (the high-water mark).
These TOPOSNA LISTxxxx commands have no optional keywords or parameters. Refer to NetView online
help for the command syntax, complete description, and output example of each of these TOPOSNA
LISTxxxx requests.

Part 7. Diagnosing MultiSystem Manager problems

Chapter 23. MultiSystem Manager worksheet
This section contains information that you can use in determining the cause of failures within the
MultiSystem Manager.
alteration.
General information
1. Date:
2. Problem Number:
3. Component ID:
6. NetView function modifier ID (FMID):
7. What MultiSystem Manager features are being run:
8. On which MultiSystem Manager features does the problem occur:

environment?
2. Can you bypass the user-written code and successfully run the function you are attempting?
Problem description

• Other:
Check one of the following appropriate problem categories that matches the symptoms associated with
your problem.
Message problems
• Message ID:
• Commands:
• NetView management console commands:
• Other:
• What occurred?
Wait problems
For wait problems, complete the following questions:

For incorrect output problems, complete the following questions:

For performance problems, complete the following questions:
panel involved.
name.
4. If the problem affects the operation or use of the MultiSystem Manager, call IBM Software Support.
Chapter 23. MultiSystem Manager worksheet 435

the MultiSystem Manager program
Use Table 165 on page 437 to locate examples of problems you might encounter when using the
MultiSystem Manager. To use the table, do the following steps:
problem.
Table 165. MultiSystem Manager Problem Scenarios

Problem
Messages Routing messages “Routing messages” on page 438
Processing Improving processing time “Improving INITTOPO processing”
on page 438
RODM Errors FLC070E and FLC076E “RODM errors - FLC070E and
FLC076E” on page 439
Errors Return Code 12, Reason Code 122 “RODM errors - Return Code 12 and
Reason Code 122” on page 439
Commands Case-sensitive text “Issuing commands that contain
case-sensitive text” on page 439
Graphical display command support problems “Command support failures” on
page 439
GETTOPO failure “GETTOPO command failures” on
page 440
Views Object status update failure “Object status update failures” on
page 442
Missing IP object “Missing IP Objects from NetView
Management Console Views” on
page 443
Aggregate object contains identical real objects “Aggregate Object contains
identical Real Objects” on page 443

The following names are used in the examples in this chapter:
NTB7I045
The SNA network address of the SNA service point
USIBMNT
The name of an SNA network
NTVB3
The name of the NetView logical unit (LU)
Routing messages
Before beginning problem determination, ensure that all messages are routed from the autotask that is
processing the GETTOPO command to your operator station task (OST). Most MultiSystem Manager
processing, by default, is done under an autotask. This works well under normal operating conditions, but
when problems occur, the resulting messages are useful for problem determination. If you route all
messages from the autotask that is processing the GETTOPO command to your OST, you can use the
messages to identify the problem.
To route all messages issued by the AUTOMSM and AUTOIPA tasks to another OST, add the following
statement to your automation table, and ensure that the operator ID for that OST has been added to the
+GRPNAME group:
IF (MSGID ¬= '') &

(OPID = 'AUTOMSM' | OPID = 'AUTOIPA') THEN
EXEC(ROUTE(ONE +GRPNAME));
This example statement routes all messages issued under tasks AUTOMSM and AUTOIPA to the first
logged on operator in the specified group of operators. Modify the example automation statement by
providing values for OPID that are specific to your environment.
If the automated actions are not working, the AUTOMSM or AUTOIPA autotask is not active. A log
message is generated, for example:
DWO032E AUTOMATION ACTION COULD NOT BE ROUTED TO TASK(S) task.
Explanation: The NetView automation process attempted to route an automation action to the task or
tasks listed in the message. The task or tasks specified were not active.
For more information, see the IBM Z NetView Automation Guide.
Improving INITTOPO processing

If the AUTOTASK parameter is specified on a GETTOPO command or initialization statement and the
specified autotask is not started before issuing the GETTOPO command, MultiSystem Manager attempts
to start the autotask and continue processing. If the started autotask is not ready for work within five
seconds, the GETTOPO command processing is done on the default autotask. This scenario might occur if
there is excessive processing in NetView while the GETTOPO command is being processed.
Therefore, if the AUTOTASK parameter is specified on multiple GETTOPO statements, starting the
autotasks before the INITTOPO command is issued can decrease the amount of time it takes to process
all of the GETTOPO statements in the initialization file. This also decreases the possibility that the
GETTOPO command is processed by the default autotask.

RODM errors - FLC070E and FLC076E
The first problem you might encounter during MultiSystem Manager initialization is a RODM error. You can
encounter the following error messages during MultiSystem Manager initialization:
FLC070E RODM PROCESSING ERROR. command ENDED IN MODULE module_name

WITH RETURN CODE return_code.
FLC076E FLCARODM:2000,x,y
Where:
2000 means RODM error
x is the RODM return code
y is the RODM reason code
RODM return codes and reason codes can be found in the IBM Z NetView Resource Object Data Manager
and GMFHS Programmer's Guide. If the problem is a class, attribute, or link type unknown to RODM, this
can indicate an error occurred while loading the MultiSystem Manager data model. Ensure that the
MultiSystem Manager data model has been loaded correctly.
The message
FLC076E FLCARODM:2000,8,13
can mean that the currently active RODM name is not the name specified in the
COMMON.FLC_RODMNAME statement in the CNMSTYLE member. However, if the value specified for
RODM name in CNMSTYLE is correct, then the RODM name specified in the procedure is not active.
If you receive an FLCARODM return code other than 2000, contact IBM Software Support.
RODM errors - Return Code 12 and Reason Code 122

If you get a RODM return code of 12 and reason code 122, increase your checkpoint data set size.
Issuing commands that contain case-sensitive text

When entering a command from the NetView command line or command list, the NetView program
converts lowercase characters to uppercase before processing. For commands that contain values that
are case-sensitive, such as resource names, the uppercase value causes processing errors and
unexpected results. Prefixing your commands with NETVASIS prevents this conversion and enables you
to enter commands that contain mixed case values.
This applies only to commands that are issued from the NetView command line or from a NetView
command list. GETTOPO statements coded in the MultiSystem Manager initialization file are processed by
MultiSystem Manager and are not subject to the NetView conversion from lowercase to uppercase. Do not
preface MultiSystem Manager initialization statements with NETVASIS.
Refer to IBM Z NetView Installation: Configuring Graphical Components or to online help for additional
details concerning the NetView NETVASIS command.
Command support failures

If you experience intermittent failures when issuing commands using NetView management console
command support, and the errors indicate that the destination address is not known, the problem might
be caused by the service point network address that is specified on the GETTOPO commands. These
Chapter 24. Troubleshooting and initial diagnosis for the MultiSystem Manager program 439
problems can occur if you use common NetView domain names across your networks. For example, a
problem can arise if the following GETTOPO commands are issued:
GETTOPO ITNMRES,SP=NETA.DOM1.LU2,......
GETTOPO OPENRES,SP=NETB.DOM1.LU2,......
In the preceding examples, both service points have the same domain name (DOM1) even though they
reside in different networks (NETA and NETB). If you want to use the NetView management console to
issue commands to your service points, use unique domain names across all your networks.
GETTOPO command failures

MultiSystem Manager uses its GETTOPO command to gather topology and status information from the
service points in your network. If you code your GETTOPO commands in your MultiSystem Manager
initialization file, the GETTOPO commands are issued during initialization.
Tracing GETTOPO command processing

If you receive an error message because of a failed GETTOPO command or if GETTOPO command
processing is not completing, you can trace GETTOPO command processing to determine the location of
the problem.
To start the trace option for GETTOPO processing, specify TRACE=YES on the GETTOPO command.
Specifying TRACE=YES generates an FLC003I message for each RUNCMD that is issued during GETTOPO
command processing. See the GETTOPO commands in the IBM Z NetView command help or online help
for more information on the TRACE parameter.
GMFHS is unavailable during GETTOPO command processing

If you find that you cannot use GMFHS while GETTOPO commands are being processed, you might want
to stop the CNMTAMEL task and restart it with a higher priority. For example, if you previously ran with
CNMTAMEL at a priority of five, you might want to raise the priority to three. To determine the priority of
the CNMTAMEL task, use the NCCF LIST PRIORITY command. To dynamically change the priority of the
task, for example to three, issue:
NCCF STOP TASK=CNMTAMEL
Then issue:
NCCF START TASK=CNMTAMEL PRI=3
Failures in the IP environment

Errors occur if TCP/IP connectivity between the NetView host and the service point does not exist. These
include:
• Alerts not arriving at the host
• GETTOPO command failures
To test TCP/IP connectivity from the service point to the NetView host, use the PING and TRACERTE
commands to ensure that the path is active and available.
To test TCP/IP connectivity from the NetView host to your service point, use the FLCACTIP command to
issue commands to the service point. For example, to test connectivity to the IBM Tivoli Network Manager
agent, you can use the info command, as in this example:
flcactip host=hostname.domain.com port=3333 cmd=info
If TCP/IP connectivity exists between your NetView host and the service point, but alerts are not being
received, check the following items:

• Use the hardware monitor to verify that the alerts are not arriving at the NetView host.
• If you are using the MultiSystem Manager for IBM Tivoli Network Manager, ensure that an SNMP trap
automation task is active and listening on the expected port. The LIST taskname command (where
taskname is the SNMP trap automation task expected to receive SNMP traps from ITNM), can be used
to view the status of the task receiver and to verify on which ports and protocols it is active.
• Verify that the service point is configured to send alerts to the NetView host.
Refer to IBM Z NetView Installation: Configuring Graphical Components for information about
configuring your service point to send alerts to the NetView host.
If TCP/IP connectivity exists between your NetView host and the service point, and alerts are being
received, but messages DSI435I and FLC077E are received after issuing GETTOPO or FLCACTIP
commands, increase your NetView COSTIME to allow the commands enough time to complete before
timing out.
Command failures in the SNA environment

This section describes the failures that can occur when GETTOPO uses the NetView RMTCMD and
RUNCMD commands.
Failures caused by RMTCMD errors

GETTOPO uses NetView RMTCMD commands to communicate with service points in remote domains
(domains other than the one where MultiSystem Manager resides). If the RMTCMD commands fail, the
GETTOPO command fails. To minimize RMTCMD errors:
1. Ensure that the REMOTE keyword is specified correctly in the GETTOPO command or in the
initialization file.
2. Ensure that RMTCMD commands can be issued to the specified NetView cross-domain. You can do
this by issuing your own RMTCMD to the NetView cross-domain from your NetView console and by
looking for a successful completion. For example, issue:
RMTCMD LU=NTVB3,OPERID=*,LIST ' '
Failures caused by RUNCMD errors

GETTOPO command processing uses NetView RUNCMD commands to communicate with service points.
If the RUNCMD commands fail because of an unknown or inactive service point, the GETTOPO command
fails. To minimize RUNCMD errors:
1. Ensure that the SP keyword is specified correctly in the GETTOPO command or in the initialization file.
2. Ensure that the service point is active and can respond to RUNCMD commands by issuing your own
RUNCMD to the service point from your NetView console. For example, issue:
RUNCMD SP=NTB7I045 APPL=REMOTEOP OP=*; DIR
Failures caused by timeouts

If the RUNCMD fails to complete or times out before a response is received, you can get the following
message:
DSI435I RUNCMD COMMAND ENDED DUE TO TIMEOUT
This message might indicate that your RUNCMD timeout value is too small.
Refer to the Command Reference Volume 2 (O-Z) or online help for more information about setting the
RUNCMD timeout value.
Object status update failures
If you have objects in your views for which the status is not being updated:
1. Verify that expected alerts are being sent to the NetView program. If the alerts are not being sent and
IP is being used to communicate, verify the following conditions:
a. Verify that the MultiSystem Manager IBM Tivoli Network Manager agent was run in Configure mode.
This is done by starting that agent with the -Configure option. For example, on Linux, issue
./FLCP_StartAgent.pl -Configure
b. Verify that the SNMP trap gateway files were updated on the workstation. Three files control the
nco_g_snmp processes that are created during the agent configuration:
MSM_snmp.conf
MSM_snmp.map
MSM_snmp_tbl_rep.def
c. Verify that the nco_g_snmp task is active and started using the MSM_GATE.conf configuration file.
d. Verify that an SNMP gateway, nco_g_snmp, is active and listening on the expected port.
e. Ensure that an SNMP trap automation task is configured and active.
2. Verify that the expected alerts show in the hardware monitor:
a. Determine whether the alerts from the topology agent are being processed by the automation
table.
• Examine the automation table to see if it has been correctly modified with the statements from
sample FLCSTBL.
Uncomment the existing statement in the automation table that processes alerts and resolutions
for GMFHS if it has not already been uncommented.
• Determine if the alerts are being filtered from being logged in GMFHS.
Comment out the filtering statements if you want these alerts to be logged in the NetView
hardware monitor and the alert history file.
Refer to the IBM Z NetView Automation Guide for more information about the automation table.
b. Determine whether the alerts are being logged in the alert history file in the NetView management
console.
c. Display alert history for the topology agent object.
If alerts are being forwarded to NetView and are being logged in the hardware monitor but they do
not show in alert history and do not change the status of the object, check to see if NetView task
DUIFEAUT is active.
d. Check the alert forwarding path. The NetView where MultiSystem Manager resides must be either
the alert focal point for the service point where the topology agent resides, or be configured to
receive forwarded alerts from the NetView which is the focal point.
3. Verify that topology alerts are causing the appropriate GETTOPO commands to be run. Some alerts
provide information regarding topology changes.
These types of alerts cause GETTOPO commands to be issued. If these commands are not being
driven, it might indicate that the autotask you have assigned for such commands is not active or that
the command to be driven is not a valid NetView command. Verify that the task listed for the ROUTE
keyword in the automation table for the MultiSystem Manager statements is active (you can do this by
issuing the LIST autotask command).
4. Verify that MultiSystem Manager has not lost contact with the service point.
Contact can be lost, for example, if the service point loses power and disappears from the network
without the opportunity to send an alert.

The HEARTBEAT parameter on the GETTOPO command provides a means for checking the connection
between the service point and MultiSystem Manager.
By setting the HEARTBEAT parameter in the GETTOPO command for a specified time interval,
MultiSystem Manager detects the lost service point and notifies the NetView management console
operator by changing the status of the agent object to either unsatisfactory or unknown.
You must use the HEARTBEAT parameter only for critical service points or for service points that are
causing problems because of the increase in network traffic that results from the additional RUNCMDs
being issued.
5. Verify that all NetView prerequisite PTFs have been installed correctly.
Missing IP Objects from NetView Management Console Views

Some IP objects might show in your IBM Tivoli Network Manager submap but not in a corresponding
NetView management console view. If you specify UNMANAGED=NO on the GETTOPO command,
unmanaged objects do not show in your views.
The MultiSystem Manager IBM Tivoli Network Manager agent is intended to retrieve only a subset of the
views and information that is discovered and displayed in the Tivoli Integrated Portal by IBM Tivoli
Network Manager. As a result, certain views might not contain expected information, or objects might not
have expected linkages. See the agent README file for more details about the restrictions.
Aggregate Object contains identical Real Objects

You might have an aggregate object that appears to contain identical real objects. This sometimes occurs
when the systems administrators have defined multiple agents to monitor the same real resource.
Select one of the identical objects and select Configuration- Parent. Select another identical object and
select Configuration- Parent. After comparing the results of the two views, you see that two or more
objects were discovered by different agents. Although their display names can be the same, the objects
have different object names in RODM. You can determine that the objects are different by comparing the
Resource Information displays for those objects.
NetView identifies instances where you define two or more agents that manage the same resource. This
can be corrected by changing the set of resources managed at the appropriate distributed manager
consoles.
If a network resource has more than one LAN adapter card (MAC address) or IP address, correlation
occurs on the first MAC address and the first IP address provided by the agent. If another agent later
provides a different MAC address or IP address for that managed resource, it might not correlate to the
original aggregate. This condition can also be caused when a systems administrator provides an alias at
the distributed agent console, such as a 'local' MAC address. To prevent these conditions, ensure that
every distributed manager specifies the same primary MAC address and IP address for a managed
resource.
Note: A correlated aggregate is displayed with a resource type of 'LAN workstation aggregate,' 'IP system
aggregate,' or 'Open system aggregate.'
Part 8. Diagnosing Automated Operations Network
problems

Chapter 25. AON problem worksheet
cause of failures within the Automated Operations Network (AON).
alteration.
The following information is required for all problems.
General information
1. Date:
2. Problem Number:
3. Component ID:
5. Installation Option:

1. Are you running any installation exits with AON? If so, which ones?
2. Can you remove or bypass the exit and re-create the problem?
environment?
Problem description

• Other:
7. Can you re-create the problem with the AON Entry/Exit trace running?
Check one of the appropriate problem categories below that matches the symptoms associated with your
problem:
Abend problems
For abends or processor exception problems, complete the following items:
3. Use the online help facility (type HELP ABEND and use the scroll function to locate the abend code).
96.
• A completed AON problem worksheet.
c. What was the module compiled?
Message problems
• Message ID:
• Commands:
• Other:
• A hardcopy of the network log containing the message.

• The message ID:
• What occurred?
Loop problems
For loop problems, complete the following items:
4. If this is an enabled loop (see “Documenting LOOP problems” on page 35), obtain the following
documentation:
• After obtaining a console memory dump, cancel AON with a memory dump.
Note: If the loop is still occurring after AON has been canceled, look for a problem other than AON.
5. If this is a disabled loop (see “Documenting LOOP problems” on page 35), obtain the following
documentation:
• A document describing the scenario leading to the problem.
• A hardcopy of the system log.
96.
• A hardcopy of the trace log. See “NetView trace” on page 100.
• A memory dump obtained by using the processor RESTART function.
Note: If ABEND071 does not occur in AON and normal processing resumes, this is not an AON
problem.
Wait problems
For wait problems, complete the following items:
• A copy of the system console log.
Chapter 25. AON problem worksheet 449

96.

For incorrect output problems, complete the following items:
• A copy of the network log containing the AON Entry/Exit trace.
For performance problems, complete the following items:
96.
• A copy of the AON Entry/Exit trace.
• Information describing your operating environment:
• Descriptions of any modifications to your system:
panel involved.
name.

4. If the problem affects the operation or use of AON, call IBM Software Support.
Chapter 25. AON problem worksheet 451

AON
This chapter describes how the Automated Operations Network (AON) automates network tasks. AON
automation focuses on the following tasks:
• AON initialization
• AON recovery of automated resources
The following sections explain AON initialization and recovery to help you in diagnosing and solving
network problems. Extensions to AON automation are described in the IBM Z NetView User's Guide:
Automated Operations Network.
AON and NetView initialization

This section gives an overview of the processes of NetView and AON initialization, and the steps that you
can use to load alternate control files and automation tables.
During NetView initialization, the DSITBL01 automation table is loaded, the AUTOAON autotask is logged
on, and the DSILOG task is started (generating a DSI240I message). When AUTOAON is logged on, Clist
EZLEANTL is driven. EZLEANTL loads the Policy Repository and attempt to initialize AON.
To change which automation table gets loaded, copy the AUTOCMD statements from the CNMSTYLE
member to the CNMSTUSR or CxxSTGEN member, and make the appropriate changes. For more
information about this process, refer to IBM Z NetView Administration Reference.
To change which policy files get loaded, copy the POLICY statements from the CNMSTYLE member to the
CNMSTUSR or CxxSTGEN member, and make the appropriate changes. For more information about this
process, refer to IBM Z NetView Administration Reference.
To initialize AON, copy the TOWER statement from the CNMSTYLE member to the CNMSTUSR or
CxxSTGEN member, and remove the asterisk (*) before AON.
When the policy repository is loaded, an EZL110I message is issued. The policy repository can be loaded
with policy definitions for AON, GRAPHICS, or the policy for your own application. If AON is uncommented
on the TOWER statement in the CNMSTYLE member, AON continues initialization by running command
list EZLEAINT, when the EZL110I occurs. If not, AON does not continue initialization, but the policy
repository is loaded with policy definitions for your other applications, such as GRAPHICS.
The EZLEAINT routine performs the following functions:
1. Calls the EZLEACGL program to update the common global variables (CGLOBALS) from information
contained in the control file. These CGLOBALS are used extensively for automation.
2. Initializes the environment for handling the automation workload by calling the EZLEASAO program.
The AON workload is divided among several automated operators to increase the speed of AON
functions and system availability. The EZLEASAO program retrieves information from the AUTOOPS
definition statements to find which automated operators to start and which messages to assign to
each of them. The EZLEASAO program then performs the message assignments to each of the
automated operators by issuing the NetView ASSIGN command. The ASSIGN command starts the
automated operators.
3. Starts NLOG and DDF according to control file definitions and the information in the status file.
AON automation routines

There are two primary automation routines:

• EZLEFAIL for resource failure
• EZLERECV for resource recovery
These routines perform basic, common automation functions as well as any resource type or message-
specific automation activities. The programs that the routines call are defined in the option definition
tables and resource type definition tables. For more information about definition tables, refer to the IBM Z
NetView User's Guide: Automated Operations Network.
The call to the routine dictates whether any of the steps in the routine are omitted, and which keywords to
use to look up the applicable programs in the definition tables.
EZLEFAIL routine
AON calls the EZLEFAIL routine when it receives a message or MSU indicating that a resource has failed
(using the NetView automation table), or from any program run by an operator or timer. The EZLEFAIL
routine does the following actions:
• Confirms that the resource is to be recovered
• Issues a message indicating the resource is unavailable
• Issues a notification describing the failure
• Runs any failure-specific programs
• Initiates recovery for the resource
• Marks the resource with Automation in Progress (AIP) status
You can omit any of these steps by specifying the appropriate value in the SKIP parameter of the
EZLEFAIL routine. For more information about the syntax and parameters for the EZLEFAIL routine, refer
to the IBM Z NetView User's Guide: Automated Operations Network.
Initialization
The EZLEFAIL routine retrieves resource information by running the RESINFO program defined in the
option definition tables. This program returns all required data in keyword=value list format. The
EZLEFAIL routine assigns values to keyword variables for use by messages and other programs called by
the routine.
Next, the EZLEFAIL routine gets any optional processing values from the TBLKEY parameter. If you do not
specify the TBLKEY parameter for the EZLEFAIL routine, no optional processing or notification occurs. The
values on the TBLKEY parameter specify keywords found in the option definition tables. In the option
definition table, the keywords define the actual processing values used for optional processing. AON
saves the TBLKEY values in the outmsgid and spec_function variables. Message EZL509I is the default
outmsgid. The value of TBLKEY is in the following format:
tblkey_value=(outmsgid,spec_function_call)
For example, if the EZLEFAIL routine is called with:
EZLEFAIL OPTION=SA MSGPRMS=(OPID) TBLKEY=IST105I RESNAME=resname
The EZLEFAIL routine gets the values specified on the IST105I keyword in the option definition table. In
the option definition table, you can see the values on the IST105I keyword as follows:
IST105I=(EZL531,FKVEAIDA(resname restype))
In this example, the EZLEFAIL routine issues the EZL531I message and runs FKVEAIDA as a function
sending the current value of resname (resource name) and restype (resource type) for optional
processing. An optional processing program performs any automation or processing unique to the
resource or failure. No optional processing is done and no message is issued if SKIP=(0) is specified on
the EZLEFAIL call.

Issue availability message
The EZLEFAIL routine issues message EZL509I to all logs. The message does not go to the DDF because a
more detailed message that describes the failure is issued later and update DDF. Operators do not receive
this message, it is used by the AON reporting facility. This message is not issued if SKIP=(A) is specified
on the EZLEFAIL call.
Check recovery settings in the control file

After issuing the availability message, the EZLEFAIL routine checks the recovery settings in the AON
control file. It first checks the options ENABLE flag in the option definition table. If the value has a first
character of Y, the option is enabled and processing continues. If not, the EZLEFAIL routine exits with a
return code of 11. The EZLEFAIL routine omits this step if SKIP=(C) is specified.
The availability of the immediate higher node of the resource is checked. The EZLEFAIL routine runs the
CHKHIGH program from the option definition table. If the return code from this program is greater than
zero (0), the resource's immediate higher node is assumed to be unavailable, and the EZLEFAIL routine
stops processing with a return code of 12. If the connecting higher nodes are available, recovery
processing for the higher nodes reactivates or reconnects all the subordinate nodes. The EZLEFAIL
routine omits this step if SKIP=(H) is specified.
Automation flags defined in the RECOVERY control file statement are analyzed to see if automation
continues for this resource. Automation can be turned off for this resource or it can be in a NOAUTO
window. The EZLEFAIL routine runs the CHKAUTO program from the option definition table. If the return
code from this program is greater than 0, automated recovery for the resource is assumed to be
undesirable and the EZLEFAIL routine stops with a return code of 13.
The EZLEFAIL routine next checks the status of the resource. Because this is a failure processor, the
assumption is that if the resource is in an active (available) status, further processing (recovery) is not
necessary. If the status of the resource is ACTive, CONCTable, NORMal, or ENABLEd, the EZLEFAIL
routine stops with a return code of 14.
The EZLEFAIL routine then determines whether automated recovery for this resource is already in
progress. The timer ID for the recovery timer is found in the EZLTIMR.resname variable. If a timer exists
to run the RECOVMON program from the option definition table, the EZLEFAIL routine stops with a return
code of 15. If it does not find a timer ID, it looks for the resource name as a valid timer ID.
Error thresholding
The EZLEFAIL routine runs the CHKTHR program from the option definition table to determine whether
error thresholds for this resource have been exceeded. The EZLEFAIL routine omits this step if SKIP=(T) is
specified.
The EZLEFAIL routine returns one of the following return codes from this check:
0
EZLEFAIL processing continues.
1
An infrequent error threshold has been exceeded. The INFRACT program from the option definition
table is run. If the return code from this program is not zero (0), EZLEFAIL stops with a return code of
21.
2
A frequent error threshold has been exceeded. The FREQACT program from the option definition table
is run. If the return code from this program is not 0, EZLEFAIL stops with a return code of 22.
3
A critical error threshold has been exceeded. The CRITACT program from the option definition table is
run. If the return code from this program is not 0, EZLEFAIL stops with a return code of 23.
Optional processing
This step enables the unique processing requirements of different resource types and network types to
be met. For example, LAN bridge recovery has different information gathering requirements than TCP/IP
Chapter 26. Troubleshooting and initial diagnosis for AON 455

node recovery. This routine gathers the additional data and uses it to decide whether recovery of the
resource continues. The EZLEFAIL routine omits this step if SKIP=(O) is specified.
The EZLEFAIL routine next runs the program specified in the second parameter of the TBLKEY parameter.
If the return code from this program is not 0, EZLEFAIL stops with a return code of 30. For example, if
TBLKEY=REPLYU, the REPLYU definition from the option definition table is accessed. The format of this
variable is REPLYU=(msgid,prog_name parm1 parm2). In this case, prog_name is run and the values of
parm1 and parm2 are passed as arguments.
Recover the resource

The EZLEFAIL routine runs the RECOVMON program specified in the option definition table. The return
code of this program is not checked because it is usually run on a different automated operator to provide
work distribution (RECOVOP). The EZLEFAIL routine omits this step if SKIP=(R) is specified. If recovery is
warranted and the AIP function is enabled, the resource is marked with the AIP operator status.
Send failure notification to operators

The EZLEFAIL routine issues a failure notification message to the notification operators, DDF, status file,
NLOG, and Netlog. The message ID specified in the first TBLKEY parameter is issued. If no message ID is
specified, message EZL509I is issued if it was not already issued as the resource availability message.
The values specified in the MSGPRMS parameter are passed to message processing for insertion into the
message text. The EZLEFAIL routine omits this step if SKIP=(M) is specified.
For detailed information about the syntax and parameters for EZLEFAIL, refer to the IBM Z NetView User's
Guide: Automated Operations Network.
EZLERECV routine
The EZLERECV routine is called as a result of a message or MSU indicating that a resource has become
active (automation table) or from a program run by an operator or timer. The EZLERECV routine does the
following actions:
• Confirms that the resource is to be tracked
• Issues a message indicating the resource is available
• Issues a notification describing the recovery
• Runs any event-specific programs
• Stops any recovery processing for the resource
• Starts active monitoring, if it has been defined in the control file
• Unmarks the resource by resetting the AIP operator status
Any of these steps can be omitted by specifying the appropriate value in the SKIP parameter of the
EZLEFAIL routine.
Initialization
When the EZLERECV routine initializes, it checks the ENABLE flag for the specified option. If the ENABLE
flag is not set to Y, the EZLERECV routine stops with a return code of 11. If ENABLE is set to Y, the
EZLERECV routine gets the resource information by starting the RESINFO program from the option
definition table. The EZLERECV routine then gets the optional processing values from the TBLKEY field of
the option definition table. If TBLKEY is not specified, no optional processing or notification is performed.
The TBLKEY values are saved in the outmsgid and spec_function variables. Message EZL504I is the
default outmsgid.
Issue availability message

The EZLERECV routine issues message EZL504I to all logs and to the DDF. This message, with a status of
ACTIV, clears the DDF entry for the resource. Operators do not receive this message, it is used by the AON
reporting facility. The EZLERECV routine omits this step if SKIP=(A) is specified. If the AIP function is
enabled, the AIP status for this resource is cleared.

Stop recovery
The EZLERECV routine checks the value of the EZLTIMR.resname variable. If EZLTIMR.resname contains a
timer ID, the EZLERECV routine determines whether the timer ID still exists. If the timer does exist, the
EZLERECV routine purges the timer and clears the variable to stop any recovery activity on the resource.
If it does not have a timer ID, EZLTIMR uses the resource name as the timer ID. The EZLERECV routine
omits this step if SKIP=(R) is specified.
Start active monitoring

The EZLERECV routine determines whether the EZLTIMA.resname variable has a timer ID value, and also
determines whether that timer exists. If the timer does not exist, the EZLERECV routine runs the active
monitoring program as defined in the option definition table (ACTMON). The return code is not evaluated
because it is on a different automated operator (ACTMONOP). The EZLERECV routine omits this step if
SKIP=(S) is specified.
Update the AON status file

The EZLERECV routine updates the status file entry for the resource with STATUS=ACTIVE.
Optional processing
The EZLERECV routine starts the program specified in the second TBLKEY parameter, if one is defined. If
the return code from this program is not 0, the EZLERECV routine stops with a return code of 30. The
EZLERECV routine omits this step if SKIP=(O) is specified.
Send messages to operators

The EZLERECV routine issues a message to the notification operators, DDF, status file, NLOG, and Netlog.
The message ID defined in the first parameter is issued. If no message is defined, message EZL504I is
issued, if it was not already issued as the availability message. The values specified in the MSGPRMS
parameter are passed to message processing for insertion into the message text. The EZLERECV routine
omits this step if SKIP=(M) is specified.
For more information about the syntax and parameters for EZLERECV, refer to the IBM Z NetView User's
Guide: Automated Operations Network.
Chapter 26. Troubleshooting and initial diagnosis for AON 457

Part 9. Diagnosing Event/Automation Service
problems

Chapter 27. Event/Automation Service problem
worksheet
cause of failures within the Event/Automation Service (E/AS).
alteration.
General information
1. Date:
2. Problem Number:
3. Component ID:
System-Related information
3. TCP/IP stack and maintenance level:
4. Event server level (if applicable):
5. Portmapper service level (if applicable; not necessary if you are using the Portmapper service that was
provided with your TCP/IP stack):
Alert adapter service information

If you are using the alert adapter service, collect the following information:
1. Is TCP/IP running?
2. Is the NetView subsystem running?
3. Is the SYSTCPD statement in the E/AS procedure coded correctly?
4. Did you specify the ServerLocation in the alert adapter configuration file?
5. Did you override any of the default settings for the alert adapter in any of the alert adapter
configuration files or on the E/AS start-up procedure? If so, what statements were overridden, and
what are the new values?
6. Is the event server that is referenced by the ServerLocation statement active? Can you use the TCP/IP
PING function to get a response from the name or address specified in the ServerLocation statement?

7. If you are using the Portmapper on the designated event server to resolve the server program port, is
the Portmapper program active on the designated event server? The ServerPort statement has a value
of 0 (which is the default).
8. Have you enabled the TECROUTE, AREC, and ESREC filters from the hardware monitor?
9. Are you using automation table statements to forward the alert to the alert adapter?
Confirmed alert adapter service information

If you are using the confirmed alert adapter service, collect the following information:
4. Did you specify the ServerLocation in the confirmed alert adapter configuration file?
5. Did you override any of the default settings for the confirmed alert adapter in any of the confirmed
alert adapter configuration files or on the E/AS start-up procedure? If so, what statements were
overridden, and what are the new values?
7. Have you enabled the TECROUTE, AREC, and ESREC filters from the hardware monitor?
8. Are you using automation table statements to forward the alert to the confirmed alert adapter?
Message adapter service information

If you are using the message adapter service, collect the following information:
4. Did you specify the ServerLocation in the message adapter configuration file?
5. Did you override any of the default settings for the message adapter in any of the message adapter
6. Is the designated event server that is referenced by the ServerLocation statement active? Can you use
the TCP/IP PING function to get a response from the name or address specified in the ServerLocation
statement?
7. If you are using the Portmapper on the designated event server to resolve the server program port, is
the Portmapper program active on the designated event server? The ServerPort statement has a value
of 0, which is the default.
8. Are you attempting to add additional data to the message that is forwarded to the message adapter?
Confirmed message adapter service information

If you are using the confirmed message adapter service, collect the following information:
4. Did you specify the ServerLocation in the confirmed message adapter configuration file?

5. Did you override any of the default settings for the confirmed message adapter in any of the confirmed
message adapter configuration files or on the E/AS start-up procedure? If so, what statements were
overridden, and what are the new values?
7. Are you attempting to add additional data to the message that is forwarded to the confirmed message
adapter?
Event receiver service information

If you are using the event receiver service, collect the following information::
4. Did you override any of the default settings for the event receiver in any of the event receiver
5. If you are using the Portmapper to register the event receiver port, is the portmapper program active
on the local host?
6. If you are starting more than one event receiver service, have you ensured that only one event receiver
is using a ServerPort with a value of 0?
Alert-to-trap service information

If you are using the alert-to-trap service, collect the following information
4. Did you override any of the default settings for the alert-to-trap service in any of the alert-to-trap
service configuration files or on the E/AS start-up procedure? If so, what statements were overridden,
and what are the new values?
5. Is the SNMP agent that is referenced by the Hostname statement active?
6. Have you enabled the TRAPROUT, AREC, and ESREC filters from the hardware monitor?
7. Are you using automation table statements to forward the alert to the alert-to-trap service?
8. Are you attempting to add additional data to the alert that is forwarded to the alert-to-trap service?
Trap-to-alert service information

If you are using the trap-to-alert service, collect the following information:
4. Did you override any of the default settings for the trap-to-alert service in any of the trap-to-alert
service configuration files or on the E/AS start-up procedure? If so, what statements were overridden,
and what are the new values?
5. Is any other service running that is using the same port as that coded on the PortNumber statement?
By default, this port is 162.
Chapter 27. Event/Automation Service problem worksheet 463

Problem description
• Other:
7. Can you re-create the problem with the NetView trace running default options and the E/AS running
VERBOSE tracing on the services that are failing?
Complete the problem category below that matches the symptoms associated with your problem:
Abend problems
For abends or processor exception problems, complete the following items:
• A completed E/AS problem worksheet
• A copy of any E/AS trace output
• A copy of the E/AS output log
• A copy of the MVS system log
• The configuration files for the services that are failing. Include your start-up procedure and global
initialization file (IHSAINIT).
Message problems

• Message ID:
• The message ID:
• The exact text of the message in the MVS system log
• What occurred?
• Have local modifications been made to change the message text?
Loop problems
For loop problems, complete the following items:
1. Are TECROUTE and TRAPROUT filters set to PASS?
• A copy of the NetView trace log
• A copy of any E/AS trace output
Wait problems

• A copy of the NetView network log

• A copy of the NetView network log

panel involved.
name.

the Event/Automation Service
Use Table 166 on page 469 to locate examples of problems you might encounter when using the Event/
Automation Service. To use the table, do the following steps:
– Then arranged alphabetically
problem.
Table 166. Event/Automation Service Problem Scenarios

Abend Event/Automation Service abends “Event/
Automation
Service
abends” on
page 474
Suspended task Event/Automation Service Task might be suspended “Event/
Automation
Service
task might
be
suspended
” on page
475
START, STOP, or RECYCLE commands do not function properly “START,
STOP, or
RECYCLE
commands
do not
function
properly”
on page
475

Table 166. Event/Automation Service Problem Scenarios (continued)
Initialization A Service does not complete initialization “A service
does not
complete
initializatio
n” on page
475
Event/Automation Service fails to initialize “Event/
Automation
Service
fails to
initialize”
on page
475
Alert Adapter fails to initialize “Alert
adapter
fails to
initialize”
on page
476
Confirmed Alert Adapter fails to initialize “Confirmed
alert
adapter
fails to
initialize”
on page
476
Message Adapter fails to initialize “Message
adapter
fails to
initialize”
on page
477
Confirmed Message Adapter fails to initialize “Confirmed
message
adapter
fails to
initialize”
on page
477
Event Receiver fails to initialize “Event
Receiver
fails to
initialize”
on page
478

Trap-to-Alert Service fails to initialize “Trap-to-
Alert
service
fails to
initialize”
on page
478
Alert-to-Trap Service fails to initialize “Alert-to-
trap service
fails to
initialize”
on page
479
Unwanted Services are starting “Unwanted
services
are
starting” on
page 479
Alert Problems Alerts are not forwarded to the expected event server “Alerts are
not
forwarded
to the
expected
event
server” on
page 480
Alerts are not converted to the expected Event Integration “Alerts are
Facility events not
converted
to the
expected
Event
Integration
Facility
events” on
page 481
An alert is forwarded continuously “An Alert is
continuousl
y
forwarded”
on page
482
An alert is not cached correctly “An Alert is
incorrectly
cached” on
page 483
Chapter 28. Troubleshooting and initial diagnosis for the Event/Automation Service 471
Message Problems Messages are not forwarded to the designated event server “Messages
are not
forwarded
to the
designated
event
server” on
page 483
Messages are not converted to Event Integration Facility events “Messages
are not
converted
to Event
Integration
Facility
events” on
page 485
A Message Is Not Cached Correctly “A
message is
incorrectly
cached” on
page 485
Event Problems Event Integration Facility events are not forwarded to the “Event
hardware monitor Integration
Facility
events are
not
forwarded
to the
hardware
monitor”
on page
486
Event Integration Facility events are not converted to alerts “Event
Integration
Facility
events are
not
converted
to alerts”
on page
487

No reply from an event server to which an Event Integration “No reply
Facility event was sent from an
event
server to
which an
Event
Integration
Facility
event was
sent” on
page 487
Negative response from an event server to which an Event “Negative
Integration Facility event was sent response
from an
event
server to
which an
Event
Integration
Facility
event was
sent” on
page 488
SNMP trap problems SNMP traps are not forwarded to the Hardware Monitor “SNMP
traps are
not
forwarded
to the
Hardware
Monitor”
on page
488
SNMP traps are not converted to alerts “SNMP
traps are
not
converted
to Alerts”
on page
489
Connectivity problems Recycling the NetView PPI “Recycling
the
NetView
PPI” on
page 490
Recycling the Event Receiver “Recycling
the Event
Receiver
for IP
Connectivit
y
problems”
on page
490
Recycling the Trap-to-Alert service “Recycling
the Trap-
to-alert
service for
IP
Connectivit
y
problems”
on page
490
Event/Automation Service abends

If any task within the Event/Automation Service abends, the following messages are issued:
• IHS0008I EVENT ADAPTER IS DUMPING FOR TASK task, COMPLETION CODE = compcode
• IHS0009I EVENT ADAPTER SDUMP FOR TASK task COMPLETED, RETURN CODE = returncode, REASON
CODE = reasoncode
where:
task
The identifier for the Event/Automation Service task that abended. Task identifiers are:
• IHSAALRN - The non-secure alert adapter task
• IHSAALRC - The confirmed alert adapter task
• IHSAALTT - The alert-to-trap task
• IHSACONT - The main or control task
• IHSAEVNT - The event receiver task
• IHSAMSGC - The confirmed message adapter task
• IHSAMSGN - The non-secure message adapter task
• IHSATRPA - The trap-to-alert task
compcode
The abend completion code. The returncode and reasoncode specify the return and reason codes for
the SDUMP macro. These codes indicate the status of the attempted SVC memory dump.
An abend usually indicates a software problem within the Event/Automation Service. Follow the steps
outlined in “Abend problems” on page 464 to resolve the cause of the abend.

Event/Automation Service task might be suspended
Any service within the Event/Automation Service might seem to be suspended if there are TCP/IP
connectivity problems or, for those services that use the Portmapper service, if there are problems
accessing the Portmapper service.
For the alert or message adapter services, connectivity problems can occur if the designated event server
to which data is being forwarded becomes unavailable. If the ConnectionMode statement indicates a
ConnectionOriented connection, timed recovery scenarios related to the RetryInterval statement value
can suspend the service if a current connection is lost. Calls to some TCP/IP functions also have timeouts
that cause the service to become suspended while it is waiting for the return from these functions. These
timeouts can be anywhere from 1 to 3 minutes in length.
If multiple event servers are specified on the ServerLocation statement, and there are connectivity
problems to each of the servers specified by the statement, the recovery time is additive. As a connection
is attempted to each event server (in order), the suspended interval for the service seems to be longer for
each server that cannot be connected.
The message, confirmed message, alert, and confirmed alert adapter services provide TCP/IP state
information with the DISPLAY STATUS command. This information is helpful in determining if and where a
service is suspended. See Chapter 29, “Diagnostic tools for the Event/Automation Service,” on page 491
for more information about using the DISPLAY STATUS command.
For the event receiver service, problems accessing the local Portmapper can cause the Portmapper
access function calls to hang up. This is based on a timer determined within the Portmapper access
functions. This problem does not occur if the UsePortMapper statement is set to NO. These problems
usually occur as a result of the Portmapper service not being active, or the service is terminating while the
Event Receiver service is active.
START, STOP, or RECYCLE commands do not function properly

Attempting to stop, start, or recycle a service that is suspended might not have the effect that is wanted if
the service is suspended. The service might be suspended if a started service is stopped or recycled and
message IHS0118I is not immediately displayed. This message eventually displays when the timeouts
that have caused the service to be suspended have completed. Likewise, the service might be suspended
if a stopped service is started and message IHS0124I is not immediately displayed.
A service does not complete initialization

If a service has started and an IP connectivity problem exists that causes the service to be suspended,
the message indicating that the service has started do not display until the suspension ends. Allow a
reasonable amount of time for any retry timeouts to occur; the service initialization completion message
displays.
Event/Automation Service fails to initialize

If the Event/Automation Service main dispatcher (control task) fails to initialize correctly, the entire
Event/Automation Service address space ends.
The Event/Automation Service issues a console message indicating the reason for the failure. The Event/
Automation Service can fail to initialize for the following reasons:
• The global configuration file (IHSAINIT is the default) cannot be found. If you are providing a
customized configuration file, make sure that you specified it correctly in the startup procedure. Also
ensure that the IHSSMP3 DD statement in the IHSAEVNT start-up procedure is correct.
• The global configuration file contains incorrect statements. If you are providing a customized
configuration file, make sure that all of the statements in the file are correct.
• The PPI mailbox identifier used by the Event/Automation Service is in use. The likely cause is that there
is another copy of the Event/Automation Service that has been started with the same PPI mailbox
identifier.
Alert adapter fails to initialize

If the alert adapter fails to initialize correctly, it ends. The Event/Automation Service DISPLAY STATUS
command displays a status of DOWN for the alert adapter.
The alert adapter issues a console message indicating the reason for the failure. The alert adapter can fail
to initialize for the following reasons:
• The alert adapter configuration file cannot be found.
IHSAACFG is the default. If you are providing a customized configuration file, verify that you specified it
correctly either on the start-up procedure or in the global initialization file ALRTCFG statement.
Also ensure that the IHSSMP3 DD statement in the IHSAEVNT start-up procedure is correct.
• The alert adapter configuration file contains incorrect statements.
If you are providing a customized configuration file, make sure that all of the statements in the file are
correct.
• The alert adapter CDS file cannot be found.
IHSAACDS is the default. If you are providing a customized CDS file, verify that you specified it correctly
on the AdapterCdsFile statement in the configuration file.
• The alert adapter CDS file contains incorrect statements.
If you are providing a customized CDS file, verify that all of the statements in the file are correct.
Additional information in the alert adapter output log provides the line number and line character
position where the error was detected.
Note: The first character position is position 0. The actual error can be ahead of the character position
referenced; the character position is the first place on the line that was found to be syntactically
incorrect.
Confirmed alert adapter fails to initialize

If the confirmed alert adapter fails to initialize correctly, it ends. The Event/Automation Service DISPLAY
STATUS command contains a status of DOWN for the confirmed alert adapter.
The confirmed alert adapter issues a console message indicating the reason for the failure. The confirmed
alert adapter can fail to initialize for the following reasons:
• The confirmed alert adapter configuration file cannot be found.
IHSABCFG is the default. If you are providing a customized configuration file, verify that you specified it
correctly either on the start-up procedure or in the global initialization file CALRTCFG statement.
• The confirmed alert adapter configuration file contains incorrect statements.
correct.
• The confirmed alert adapter CDS file cannot be found.
IHSABCDS is the default. If you are providing a customized CDS file, verify that you specified it correctly
on the AdapterCdsFile statement in the configuration file.

• The confirmed alert adapter CDS file contains incorrect statements.
If you are providing a customized CDS file, verify that all of the statements in the file are correct.
Additional information in the alert adapter output log provides the line number and line character
incorrect.
Message adapter fails to initialize

If the message adapter fails to initialize correctly, it ends. The Event/Automation Service DISPLAY
STATUS command displays the status of the message adapter as DOWN.
The message adapter issues a console message indicating the reason for the failure. The message
adapter can fail to initialize for the following reasons:
• The message adapter configuration file cannot be found.
The default is IHSAMCFG. If you are providing a customized configuration file, verify that you specified it
correctly either on the start-up procedure or in the global initialization file MSGCFG statement.
• The message adapter configuration file contains incorrect statements.
correct.
• The message adapter FMT file cannot be found.
The default is IHSAMFMT. If you are providing a customized FMT file, verify that you specified it
correctly on the AdapterFmtFile statement in the configuration file.
The message adapter FMT file contains incorrect statements. If you are providing a customized FMT
file, make sure that all of the statements in the file are correct. Additional information in the message
adapter output log indicates the line number and line character position where the error was detected.
referenced. The character position is the first place on the line that was found to be syntactically
incorrect.
Confirmed message adapter fails to initialize

If the confirmed message adapter fails to initialize correctly, it ends. The Event/Automation Service
DISPLAY STATUS command displays the status of the message adapter as DOWN.
The confirmed message adapter issues a console message indicating the reason for the failure. The
confirmed message adapter can fail to initialize for the following reasons:
• The confirmed message adapter configuration file cannot be found.
The default is IHSANCFG. If you are providing a customized configuration file, verify that you specified it
correctly either on the start-up procedure or in the global initialization file CMSGCFG statement.
• The confirmed message adapter configuration file contains incorrect statements.
correct.
• The confirmed message adapter FMT file cannot be found.
The default is IHSANFMT. If you are providing a customized FMT file, verify that you specified it
correctly on the AdapterFmtFile statement in the configuration file.
The confirmed message adapter FMT file contains incorrect statements. If you are providing a
customized FMT file, make sure that all of the statements in the file are correct. Additional information
in the message adapter output log will indicate the line number and line character position where the
error was detected.
referenced. The character position is the first place on the line that was found to be syntactically
incorrect.
Event Receiver fails to initialize

If the event receiver fails to initialize correctly, it will end. The Event/Automation Service DISPLAY
STATUS command will display the status of the event receiver as DOWN.
The event receiver will issue a console message indicating the reason for the failure. The event receiver
can fail to initialize for the following reasons:
• The event receiver configuration file cannot be found.
The default file is IHSAECFG. If you are providing a customized configuration file, verify that you
specified it correctly either in the start-up procedure or in the global initialization file ERCVCFG
statement.
• The event receiver configuration file contains incorrect statements.
correct.
• The event receiver CDS file cannot be found. The default file is IHSAECDS.
If you are providing a customized CDS file, verify that you specified it correctly on the AdapterCdsFile
statement in the configuration file.
• The event receiver CDS file contains incorrect statements.
If you are providing a customized CDS file, make sure that all of the statements in the file are correct.
Additional information in the event receiver output log will indicate the line number and line character
incorrect.
Trap-to-Alert service fails to initialize

If the trap-to-alert service fails to initialize correctly, it ends. The Event/Automation Service DISPLAY
STATUS command displays the status of the trap-to-alert service as DOWN.
The trap-to-alert service issues a console message indicating the reason for the failure. The trap-to-alert
service can fail to initialize for the following reasons:
• The trap-to-alert service configuration file cannot be found.
The default file is IHSATCFG. If you are providing a customized configuration file, verify that you
specified it correctly either in the start-up procedure or in the global initialization file TALRTCFG
statement.
• The trap-to-alert service configuration file contains incorrect statements.

correct.
• The trap-to-alert service CDS file cannot be found.
The default file is IHSATCDS. If you are providing a customized CDS file, verify that you specified it
correctly on the AdapterCdsFile statement in the configuration file.
The trap-to-alert service CDS file contains incorrect statements. If you are providing a customized CDS
file, make sure that all of the statements in the file are correct. Additional information in the trap-to-
alert service output log indicates the line number and line character position where the error was
detected.
incorrect.
Alert-to-trap service fails to initialize

If the alert-to-trap service fails to initialize correctly, it ends. The Event/Automation Service DISPLAY
STATUS command displays the status of the alert-to-trap service as DOWN.
The alert-to-trap service issues a console message indicating the reason for the failure. The alert-to-trap
service can fail to initialize for the following reasons:
• The alert-to-trap service configuration file cannot be found.
The default file is IHSAATCF. If you are providing a customized configuration file, verify that you
specified it correctly either in the start-up procedure or in the global initialization file ALRTTCFG
statement.
• The alert-to-trap service configuration file contains incorrect statements.
correct.
• The alert-to-trap service CDS file cannot be found.
The default file is IHSALCDS. If you are providing a customized CDS file, verify that you specified it
correctly on the AdapterCdsFile statement in the configuration file.
• The alert-to-trap service CDS file contains incorrect statements.
If you are providing a customized CDS file, make sure that all of the statements in the file are correct.
Additional information in the alert-to-trap service output log indicates the line number and line
character position where the error was detected.
incorrect.
• The alert-to-trap service is not authorized to get the DPI port number from the SNMP agent.
The view access defined for the community name provided to the alert-to-trap service does not allow
the alert-to-trap service to retrieve the DPI port number from the SNMP agent. Ensure that the SNMP
agent configuration file allows access to dpiPort for the community name defined to the alert-to-trap
service. For information about configuring an SNMP agent, see the z/OS Communications Server IP
Configuration Reference.
Unwanted services are starting

All services attempt to start automatically. The NOSTART statement in the global initialization file
(IHSAINIT) allows you to specify which services you do not want to start.
The sample global initialization file contains NOSTART statements for the alert-to-trap service and the
trap-to-alert service. If you do not plan to use one or more of the alert adapter, message adapter, or event
receiver services, add NOSTART statements for these services to the global initialization file. You can
receive unexpected error message if you allow a service to start without correctly configuring the service.
You can start a service after the Event/Automation Service has started without affecting the operation of
currently running services using the Event/Automation Service START command.
Alerts are not forwarded to the expected event server

Use the following steps to determine why an Event Integration Facility (EIF) event that was created from
an alert did not arrive at an event server. As an example, this could have been an EIF event that was built
from alert information by the alert adapter and sent to an event server, yet the EIF event did not arrive at
the server or could not be displayed there.
1. Has the alert been recorded in the NetView hardware monitor database? Refer to the Recording
category in Table 4 on page 51 for more information about determining why an alert has not been
recorded.
2. Is the TECROUTE filter set to PASS? Use the NPDA DFILTER command to verify that the TECROUTE
filter is set to PASS DEFAULT. If you are using automation to forward alerts and have not set the
TECROUTE filter to PASS DEFAULT using the NPDA SRFILTER command, ensure that you have
specified an SRF action in the automation table statement to enable the TECROUTE filter for that
specific action.
3. Is the NetView PPI active? Issue the DISPPI command to determine whether the PPI is active.
4. Is the PPI mailbox for the Event/Automation Service defined to the PPI? Issue the DISPPI command
to verify that the expected PPI receiver name is defined and active. Issue the DISPLAY STATUS
command to the Event/Automation Service and review the PPI service information to verify the name
of the PPI receiver that is being used by the Event/Automation Service.
5. Is the alert being forwarded to the correct PPI mailbox? Check the NPDA.TECROUTE statement in the
CNMSTYLE member. By default, this mailbox is IHSATEC. If you are using automation table
statements to forward the alert, ensure that the correct PPI receiver is provided to the PPI stage of
PIPE. Also, if the alert data is to be processed by the alert adapter, ensure that the TECROUTE
keyword is coded for the PPI stage of PIPE. If the alert data is to be processed by the confirmed alert
adapter, ensure that the TECRTCFM keyword is coded for the PPI stage of PIPE. Use the DISPPI
command to display the number of buffers received by the Event/Automation Service PPI mailbox.
Verify that the number of buffers received increments by one each time an alert is forwarded to the
Event/Automation Service.
6. Is the alert adapter service or the confirmed alert adapter service active? Use the DISPLAY STATUS
command to verify that the service is active. If so, use the DISPLAY QSTATS command to examine
the TOTAL RCVD count. It increments by one if the alert was received by the adapter. Issue the
DISPLAY QSTATS command to obtain a baseline count, then issue it again after the alert has been
forwarded.
7. Has the alert been discarded by the CDS file processing? CDS file processing converts the alert to an
EIF event, and can result in the alert being discarded if the alert matching criteria is not met. This
should not happen unless you have customized the CDS file. The default CDS file will not discard an
alert.
To determine if an alert has been discarded, enable tracing for the alert adapter service or the
confirmed alert adapter service with LEVEL=NORMAL. After sending the alert, examine the adapter
output log for the message:
date ALERTA :IHSAKERN:line NORMAL: Default action is <*DISCARD*>
Where date is the date string trace header and line is a number. Note that if the confirmed alert
adapter service had been used, the message would contain ALERTC.

If the alert has been discarded, verify the changes that were made to the adapter CDS file. Also, verify
any changes that you might have made to the data before it was sent from the hardware monitor;
check if you added any variable bindings to the data that are also referenced in the CDS file. If you
have incorrectly specified a variable binding within the NetView address space, and are matching on
that variable binding in the CDS file, the alert is discarded if it does not meet the match criteria.
8. Has the converted alert been discarded because of a Filter/FilterMode statement setting? The default
configuration file does not contain any filter statements, so the alert is not filtered unless you added
these statements to the adapter configuration file. If you have added one or more of these
statements, you can determine whether an event has passed the filtering conditions by turning on the
IP trace option for the adapter service and generating the alert. Examine the alert adapter output log
for the message:
date ALERTA :IHSAACOM:line IP: The event was discarded due to filtering;
filtering mode is mode
Where date is the date string trace header, line is a number, and mode is either IN or OUT. Note that if
the confirmed alert adapter service had been used, the message would contain ALERTC. Check the
filter statements and the corresponding FilterMode setting to verify that you have specified the
correct filter criteria.
9. Has the converted alert been discarded or cached because of event server connection problems? The
IHS0192I message IHS0192I Alert Adapter: Server connections are suspended is
sent to the system console whenever an event cannot be sent to any of the event servers listed on
the ServerLocation statement. Any event sent after IHS0192I (including the event that caused the
message) is displayed , and before the IHS0193I Alert Adapter: Server connections
have been resumed message is received, is either discarded or cached. Note that if the confirmed
alert adapter service issued messages IHS0192I and IHS0193I, the Confirmed Alert Adapter would
be indicated in the message text.
Use the IP trace option of the adapter service to determine why a connection cannot be made to an
event server. These are some possible causes of connection problems:
• TCP/IP is not active on the local host or at the event server.
• The portmapper is not active at the designated event server. This is required only if the ServerPort
that corresponds to the designated event server on the ServerLocation statement is zero (0). The
confirmed alert adapter does not interact with the portmapper.
• The location on the ServerLocation statement or the port on the ServerPort statement is incorrect.
• The event server application is not running.
10. The converted alert was sent to one of the event servers specified on the ServerLocation statement.
If the event is not showing at the expected event server, check the following items:
• If you have more than one event server specified on the ServerLocation statement, is the order
correct? The alert adapter service or the confirmed alert adapter service forwards a converted alert
to the first event server to which it can connect.
• Have you installed and activated the .baroc and .rls files at the designated event server that are
required for the server to recognize converted alert events?
Note: This item applies only to the alert adapter service.
• Does your event server user logon have access to the event group that contains the NetView alert
events?
Alerts are not converted to the expected Event Integration Facility events
Use the following steps to determine why an Event Integration Facility (EIF) event, which was created
from an alert and sent to an event server, did not contain the correct information. As an example, this
could be an EIF event that is displayed at the designated event server, but the EIF event contains
incorrect information.
1. Are you using a customized CDS file? If so, verify the following items:
• Have you specified the correct criteria in the SELECT segment of the class definition statement that
you expect to match the incoming alert data?
• Are the slot and value pairs correct in the MAP segment of the class definition statement?
• Before the class definition statement that you expect to match, is there another class definition
statement that matches the criteria in the SELECT segment? Matches are searched in order from the
first statement in the CDS file until the first SELECT segment is matched.
• Have you changed the designated event server .baroc file to match the customization in the CDS file?
The designated event server discards events that have slot and value pairs that cannot be associated
with the class of event that it receives. It also discards events that have class names that are not
defined in the .baroc file.
Note: The user1 through user5 slots are preconfigured into the alert adapters .baroc file for all
events that are subclasses of the SNA_Event class. All classes defined in the default CDS file for the
alert adapter are subclasses of the SNA_Event class. If you changed the CDS file to use these slots
with the predefined classes in the CDS file, or with any newly defined class that is a subclass of the
SNA_Event class, no modifications are necessary to the .baroc file for these slots.
2. Have you bound additional names and values to the alert data using the NetView automation table
which are not showing in the EIF event? If so, check the following in addition to the suggestions in the
previous step:
• Make sure the command list that performs the name bindings is being called from the automation
table when the alert is driven.
• If possible, dump the alert buffer from the PPI PIPE stage with the TECROUTE keyword (used to
route message data to the message adapter) or the TECRTCFM keyword (used to route message
data to the confirmed adapter), whichever applies.
An Alert is continuously forwarded

The forwarding of an alert to the Event/Automation Service can result in a continuous loop of alerts if the
services are configured to allow a conversion loop. A conversion loop occurs when an event of one type
(an alert) is converted by the service to another event type, such as an Event Integration Facility (EIF)
event or an SNMP trap, and forwarded to the original event manager of the converted event. If that event
manager forwards the event back to the service (event receiver service, for example), the event is
converted back into an alert and is then forwarded to the NetView hardware monitor. When the hardware
monitor receives the new alert, which is actually a twice converted instance of the original alert, it
forwards it back to the alert adapter service. This alert loop continues indefinitely.
The NetView hardware monitor prevents certain instances of conversion loops. Any alert forwarded to the
hardware monitor from the event receiver service is not forwarded back to the alert adapter service using
the TECROUTE filter. Likewise, an alert that is forwarded to the hardware monitor from the trap-to-alert
service is not forwarded back to the alert-to-trap service using the TRAPROUT filter. As a result, an alert
that originates from the NetView hardware monitor can be looped back to the hardware monitor, but the
new alert is not sent back to the alert adapter or alert-to-trap service using the same filter on which it
originated.
The NetView hardware monitor does not prevent a conversion loop that involves both the TECROUTE and
TRAPROUT filters together. The NetView hardware monitor does not prevent an alert that came from the
event receiver service from being forwarded back to the alert-to-trap service using the TRAPROUT filter.
It also does not prevent an alert that came from the trap-to-alert service from being forwarded back to
the alert adapter service using the TECROUTE filter. If you are using both the TECROUTE and TRAPROUT
filters together, you can prevent a conversion loop from occurring by:
• Not using the event receiver service or the trap-to-alert service.
• Ensuring that an EIF event that is created by the alert adapter service is not returned to the event
receiver.

• Ensuring that an SNMP trap created by the alert-to-trap service is not returned to the trap-to-alert
service.
An Alert is incorrectly cached

You can determine whether an event has been cached by turning on the IP trace option for the alert
adapter service or the confirmed alert adapter service and generating the alert. If the alert has been
cached, the adapter service output log contains the message:
date ALERTA :IHSAACOM:line IP: The event was buffered.
Where date is the date string trace header and line is a number. If the event was discarded because of
event buffer filtering, the adapter service output log contains the message:
date ALERTA :IHSAACOM:line IP: The event was discarded.
Note that if the confirmed alert adapter service issued the message, then ALERTC would be indicated in
the message text. You see either of these messages if the alert was processed by the adapter service and
cannot be sent to any of the event servers from the ServerLocation statement. Use the IP trace output to
verify that the alert was processed and not sent.
To determine why the event is either cached or not cached, check the following items:
• Is the BufferEvents statement set to the correct value?
• Is the BufEvtPath statement set to the correct value?
• If you have FilterCache statements, are they correctly specified?
• Is the FilterMode statement set to the correct value?
• Did you see any console messages that indicated a problem with accessing the cache file?
Messages are not forwarded to the designated event server

Use the following steps to determine why a message is not being forwarded to an event server:
1. Is there an automation table statement in an active table that selects the message and sends it
through the PPI PIPE stage? Is the PPI name of the Event/Automation Service specified correctly on
the PIPE stage? Was the TECROUTE keyword (for the message adapter) or TECRTCFM keyword (for
the confirmed message adapter) supplied with the PPI PIPE stage for routing of message data?
3. Is the PPI mailbox for the Event/Automation Service defined to the PPI? Issue the DISPPI command to
verify that the expected PPI receiver name is defined and active. Issue the DISPLAY STATUS
command to the Event/Automation Service and browse the PPI service information to verify the name
of the PPI receiver that is being used by the Event/Automation Service.
4. Is the message being forwarded to the correct PPI mailbox? Ensure that the PIPE PPI stage is
forwarding the alert to the correct PPI mailbox. Was the TECROUTE keyword (used to route message
data to the message adapter) or TECRTCFM keyword (used to route message data to the confirmed
message adapter) supplied with the PPI PIPE stage for the routing of message data? Use the DISPPI
command to display the number of buffers received by the Event/Automation Service PPI mailbox.
Verify that the number of buffers received increments by one each time a message is forwarded to the
Event/Automation Service.
5. Is the message adapter service or the confirmed message adapter service active? Use the DISPLAY
STATUS command to verify that the service is UP. If so, use the DISPLAY QSTATS command to view
the TOTAL RCVD count. It increments by one if the message was received by the adapter. Issue the
DISPLAY QSTATS command to get a baseline count, then reissue the command after the message has
been forwarded.
6. Has the message been discarded by the FMT file processing?
FMT file processing converts the message to an Event Integration Facility (EIF) event. If none of the
message matching criteria is met, the message can be discarded. This should not happen unless you
have customized the FMT file. The default FMT file does not discard the message.
To determine whether a message has been discarded, enable tracing for the message adapter service
or the confirmed message adapter service with LEVEL=NORMAL. After sending the message, examine
the output log for the adapter for the following message:
date MESSAGEA:IHSAKERN:line NORMAL: Default action is <*DISCARD*>
Where date is the date string trace header and line is a number. Note that if the confirmed message
adapter service issued the message, then MESSAGEC would be indicated in the message text.
If the message has been discarded, verify the changes that were made to the message adapter FMT
file.
7. Has the converted message been discarded because of a Filter or FilterMode statement setting? The
default configuration file does not contain any filter statements, so the message is not filtered unless
you added these statements to the message adapter or the confirmed message adapter configuration
file. If you have added one or more of these statements, you can determine whether an event has
passed the filtering conditions by turning on the IP trace option for the adapter service and generating
the message. Examine the adapter output log for the message:
date MESSAGEA:IHSAACOM:line IP: The event was discarded due to filtering;

filtering mode is mode
Where date is the date string trace header, line is a number, and mode is either IN or OUT. Note that if
the confirmed message adapter service issued the message, then MESSAGEC would be indicated in the
message text.
Check the Filter statements and the corresponding FilterMode setting to verify that you specified the
correct filter criteria.
8. Has the converted message been discarded or cached because of event server connection problems?
Message IHS0192I Message Adapter: Server connections are suspended is sent to the
system console whenever an event cannot be sent to any of the event servers listed on the
ServerLocation statement. Any event sent after IHS0192I shows (including the event that caused the
message), and before message IHS0193I Message Adapter: Server connections have
been resumed is received, is either discarded or cached. Note that if the confirmed message adapter
service issued the message, then Confirmed Message Adapter would be indicated in the message
text.
Use the IP trace option of the adapter service to determine why a connection cannot be made to an
event server. These are some possible causes of connection problems:
• TCP/IP is not active on the local host or at the event server.
• The portmapper is not active at the designated event server. This is only required if the ServerPort
that corresponds to the designated event server on the ServerLocation statement is zero (0). The
portmapper function is not used by the confirmed message adapter.
• The location on the ServerLocation statement or the port on the ServerPort statement is incorrect.
• The Event Server application is not running.
9. The converted message was sent to one of the event servers specified on the ServerLocation
statement. If the event is not showing at the expected event server, check the following items:
• If you have more than one event server specified on the ServerLocation statement, is the order
correct? The message adapter service or the confirmed message adapter service forwards a
converted message to the first event server to which it can connect.
• Have you installed and activated the .baroc and .rls files at the designated event server that are
required for the server to recognize converted message events?
Note: This item applies only to the message adapter service.

• Does your event server user logon have access to the event group that contains the NetView
message events?
Messages are not converted to Event Integration Facility events

Use the following steps to determine why an Event Integration Facility (EIF) event that was created from a
message arrived at an event server but did not contain the correct data.
1. Are you using a customized FMT file? If so, check the following items:
• Have you specified the correct criteria in the FORMAT statement? This criteria must match the
incoming message data.
• Are you mapping the slot and value pairs correctly in the FORMAT statement?
• Is there another FORMAT statement that follows the FORMAT statement that you expect to match
(which also matches the message)? Matches are searched for in order from the last statement in the
FMT file until the first FORMAT statement selection criteria is matched.
Note: This is not the same as the CDS file matching order, which starts with the first statement in the
file.
• Have you changed the designated event server .baroc file to match the customization in the FMT file?
Note: This item applies only to the message adapter service.
The designated event server discards events that have slot and value pairs that cannot be associated
with the class of event that was received. It also discards events that have class names that are not
defined in the .baroc file.
Note: The user1 through user5 slots are preconfigured in the message adapter .baroc file for all
events that are subclasses of the NV390MSG_Event class. All classes defined in the default FMT file
for the message adapter are subclasses of the NV390MSG_Event class. If you have changed the FMT
file to use these slots with the predefined classes in the FMT file, or with any newly defined class
that is a subclass of the NV390MSG_Event class, then no modifications are necessary to the .baroc
file for these slots.
2. Have you bound additional names and values to the alert data using the NetView automation table
which are not showing in the EIF event? If so, check the following items:
• Make sure that the command list that performs the name bindings is being driven from the
automation table when the message is driven.
• If possible, dump the message buffer from the PPI pipe stage (with either the TECROUTE or
TECRTCFM keyword) to the NetView console. The variable binding data is displayed in the EBCDIC
translation of the hexadecimal data. Verify that the binding is present in this data.
A message is incorrectly cached

You can determine whether an event has been cached by turning on the IP trace option for the message
adapter or confirmed message adapter service and generating the message. If the message has been
cached, the adapter service output log contains the message:
date MESSAGEA :IHSAACOM:line IP: The event was buffered.
Where date is the date string trace header and line is a number. If the event was discarded because of
event buffer filtering, the adapter service output log contains the message:
date MESSAGEA :IHSAACOM:line IP: The event was discarded.
Note that if the confirmed message adapter service issued the message, then MESSAGEC would be
indicated in the message text.
You see either of these messages if the message was processed by the message adapter or confirmed
message adapter service and cannot be sent to any of the event servers from the ServerLocation
statement. Use the IP trace output to verify that the message was processed and not sent.
To determine why the event is either cached or not cached, check the following items:
• Is the BufferEvents statement set to the correct value?
• Is the BufEvtPath statement set to the correct value?
• If you have FilterCache statements, are they correctly specified?
• Is the FilterMode statement set to the correct value?
• Did you see any console messages that indicated a problem with accessing the cache file?
• For a confirmed alert adapter or confirmed message adapter, did the IP trace show that a complete
response Event Integration Facility (EIF) event was received? Was it a positive or negative response or
was the data not valid?
Event Integration Facility events are not forwarded to the hardware monitor
Use the following steps to determine why an Event Integration Facility (EIF) event that you expect to be
forwarded to the hardware monitor is not showing there.
1. Is the event sender that generates the event set up to forward the event to the event receiver? For
example, the event sender might not be a designated event server or a user of the EIF tool kit code
that emits EIF events.
Note: The event receiver receives events in a similar manner to the designated event server.
2. Is the event receiver service active?
Use the DISPLAY STATUS command to verify that the service is UP.
3. If the event sender must resolve the event receiver port using the Portmapper, is the UsePortMapper
statement value set to YES?
If not, the event sender is unable to determine the port to use to connect to the event receiver.
4. Is TCP/IP active on the local host? Use the DISPLAY STATUS command to check the status of TCP/IP
(UP or DOWN).
5. If the Portmapper service is required, is it active on the local host?
6. If the event sender specifies a fixed port for the event receiver, is that same port specified on the
ServerPort statement?
Use the DISPLAY STATUS command to verify the setting of the event receiver port.
7. Has the event been received by the event receiver?
Temporarily turn tracing on for the event receiver at the LOW level and then turn tracing on for the
EIF event. Browse the event receiver output log to verify that trace entries have been added to the
output log.
Note: After the event receiver initializes, it does not create trace entries unless it has received an EIF
event.
8. Has the event been discarded by CDS file processing?
CDS file processing converts the EIF event into an alert. If none of the event matching criteria is met,
the event is discarded. This should not happen unless the CDS file has been customized. The default
CDS file does not discard the event.
To determine whether an EIF event has been discarded, turn tracing on for the event receiver service
at the NORMAL level. After sending the event, browse the event receiver output log for the following
message:
date EVENTRCV:IHSAKERN:0332 NORMAL:Default action is <*DISCARD*>

where date is the date string header.
If the event has been discarded, verify any changes to the event receiver CDS file.
9. Have you received any error messages that indicate CDS file processing failed?
Some CDS file errors cannot be detected until after the class definition statement is applied to an
existing event. Use the error message and any accompanying messages in the event receiver output
log to correct the class definition statement and recycle the event receiver to activate any updates.
10. Is the NetView PPI active?
Issue the DISPPI command to determine whether the PPI is active.
11. Is the converted event being forwarded to the correct PPI mailbox?
The converted event is forwarded to the NetView alert receiver task (CNMCALRT). By default, the PPI
mailbox identifier defined by this task is NETVALRT. Use the DISPPI command to verify the mailbox
that the NetView alert receiver task is using is defined and active. The CNMCALRT or ALERTC task
might not be active if it has not defined the PPI mailbox identifier.
Use the Event/Automation Service DISPLAY STATUS command to verify that the PPI mailbox (to
which the event receiver is forwarding converted events) is correct.
12. Are the hardware monitor AREC and ESREC filters set to PASS for the alert type being forwarded?
Event Integration Facility events are not converted to alerts

Use the following steps to determine why an Event Integration Facility (EIF) event is not being forwarded
to the hardware monitor. If you using a customized CDS file, check the following items:
• Have you specified the correct criteria in the SELECT segment of the class definition statement to match
the incoming EIF event data?
• Are you mapping the slot and value pairs correctly in the MAP segment of the class definition
statement?
• Is there another class definition statement in front of the class definition statement? If so, does it also
match the criteria in the SELECT segment of the class definition statement? Matches are searched in
order from the first statement in the CDS file to the first SELECT segment that is matched.
• Are you using the $CDS_GROUP keyword to transition through the statements in the CDS file in the
correct order?
• Do all slot mappings that carry subvector information start with the characters SV?
• Are you using the character translation escape characters (#< and #>) correctly?
No reply from an event server to which an Event Integration Facility event

was sent
Note: This is applicable only for confirmed adapters.
If there was no reply from an event server to which an Event Integration Facility (EIF) event was sent,
check the location on the ServerLocation statement. It might be that the location exists but is not an
event server that can issue a reply. There might also be other problems at the event server or in the
network.
The confirmed message adapter and confirmed alert adapter add an IHSeventID=value; slot (where value
is character data chosen by the adapter) to each EIF event that was sent. To confirm the event and
prevent the sending adapter from caching it any longer, the event server responds with a positive
response EIF event with the following format:
Note: All offsets are in hexadecimal. Note also that the Msg. length value includes the length of everything
after the header, meaning from offset x'24' to the end of the event, including the x'0A01' sequence.
0 <START>>
8 Msg. ID (0)
C Msg. from (0)
10 Msg. to (0)
14 Msg. type (0)
18 IPC msg. type (0)
1C Msg. length (x'26')
20 Header data length (specify any value, because the confirmed adapter
ignores this specification)
24 Class name (IHS+;)
29 IHSeventID=C45902AB73920A58;
45 END
48 x'0A01'
If the event server wants the sending adapter to immediately enter retry processing for or caching of an
EIF event, the event server can send a negative response EIF event with this format:
Note: All offsets are in hexadecimal. Note also that the Msg. length value includes the length of everything
after the header, meaning from offset x'24' to the end of the event, including the X'0A01' sequence.
0 <START>>
8 Msg. ID (0)
C Msg. from (0)
10 Msg. to (0)
14 Msg. type (0)
18 IPC msg. type (0)
1C Msg. length (x'26'
20 Header data length (specify any value, because the confirmed adapter
ignores this specification)
24 Class name (IHS-;)
29 IHSeventID=C45902AB73920A58;
45 END
48 x'0A01'
In either case, the character data in the response EIF event (the <START>>, END, class name, and the
IHSeventID=value; slot should be ASCII.
Negative response from an event server to which an Event Integration

Facility event was sent
Note: This is applicable only for confirmed adapters.
A negative response can be sent by an event server when the following conditions occur:
• The event server successfully parses an Event Integration Facility (EIF) event such that the IHSeventID
slot can be isolated or extracted from the EIF event.
• While processing the event, a condition occurs for which the event server needs to communicate with
the Event/Automation Service to try another event server or cache the event.
SNMP traps are not forwarded to the Hardware Monitor

Use the following steps to determine why an SNMP trap is not being forwarded to the hardware monitor.
1. Is the SNMP agent that generates the trap set up to forward the event to the trap-to-alert service?
For information about how to forward events to SNMP managers, refer to the SNMP agent
documentation.
2. Is the trap-to-alert service active? Use the DISPLAY STATUS command to verify that the service is
UP.

3. Is TCP/IP active on the local host? Use the DISPLAY STATUS command to check the status of TCP/IP
(UP or DOWN).
4. Is the port specified on the PortNumber statement the same port to which the SNMP agent is
forwarding traps? Use the DISPLAY STATUS command to verify the setting of the event receiver port.
5. Has the trap been received by the trap-to-alert service? Turn tracing on (LOW level) for the trap-to-
alert service. Then, issue the trap. Browse the trap-to-alert service output log and verify that trace
entries have been added to the output log.
Note: After the trap-to-alert service initializes, it will not create trace entries unless it has received an
SNMP trap.
6. Has the event been discarded by CDS file processing? CDS file processing converts the SNMP trap
into an alert. If none of the trap matching criteria is met, the event can be discarded This should not
happen unless the CDS file was customized. The default CDS file noes not the event.
To determine whether an SNMP trap has been discarded, set tracing on (NORMAL level) for the trap-
to-alert service. After sending the event, browse the trap-to-alert output log for the following
message:
date TRAPALRT :IHSAKERN:0332 NORMAL: Default action is <*DISCARD*>
where date is the date string header.

If the event was discarded, verify the changes in the trap-to-alert service CDS file.
7. Have you received any error messages that indicate CDS file processing has failed? Some CDS file
errors cannot be detected until the class definition statement is applied to an active event. Use the
error message and accompanying messages in the trap-to-alert output log to correct the class
definition statement. Then, recycle the trap-to-alert service to activate the updates.
9. Is the converted event being forwarded to the correct PPI mailbox? The converted event is forwarded
to the NetView alert receiver task (CNMCALRT). The default PPI mailbox identifier defined by this
task is NETVALRT. Use the DISPPI command to verify that the mailbox, which the NetView alert
receiver task is using, is defined and active. The CNMCALRT task might not be active if it has not
defined the PPI mailbox identifier. Use the Event/Automation Service DISPLAY STATUS command to
verify that the PPI mailbox is correct. This information is located under Additional Info.
10. Are the hardware monitor AREC and ESREC filters set to PASS for the alert type being forwarded?
SNMP traps are not converted to Alerts

Use the following steps to determine why an SNMP trap is not being converted to an alert. If you are using
a customized CDS file, check the following items:
• Have you specified the correct criteria in the SELECT segment of the class definition statement. The
criteria matches the incoming SNMP trap data.
• Are you mapping the slot and value pairs correctly in the MAP segment of the class definition
statement?
• Is there another class definition statement in front of the class definition statement? If so, does it also
match the criteria in the SELECT segment of the class definition statement? Matches are searched in
order from the first statement in the CDS file to the first SELECT segment that is matched.
• Are you using the $CDS_GROUP keyword to move through the statements in the CDS file in the correct
order?
• Do all slot mappings that carry subvector information start with the letters SV?
• Are you using the character translation escape characters (#< and #>) correctly?
• Are you using the octet string translation escape characters (#[ and #]) correctly?
Recycling the NetView PPI
The Event/Automation Service detects when the NetView PPI is inactive and enters a recycle loop to re-
register with the PPI when the PPI becomes active. The following message appears at the system console
every 30 seconds while the Event/Automation Service attempts to re-register with the PPI :
IHS0088A PPI inaccessible; timeout of 30 seconds in progress.
If the PPI is inactive when the Event/Automation Service is started, none of the requested services will be
started until the PPI becomes active.
If the PPI becomes inactive after the Event/Automation Service has started, the started services will
remain active. However, any data forwarded to the PPI from the event receiver and trap-to-alert services
is discarded.
Recycling the Event Receiver for IP Connectivity problems

The event receiver enters an internal recycle mode if it cannot define its IP socket. This can occur as a
result of the following conditions:
• TCP/IP being inactive
• The Portmapper service being inactive (if the UsePortMapper configuration statement has a value of
YES).
The event receiver issues an error message indicating the cause for entering the recycle mode, and then
issue the following error message:
IHS0181E The Event Receiver will continue recycling until

it can successfully define a socket.
This is the last console message that the event receiver issues until the socket can be defined. Further
messages are sent only to the event receiver output log. The recycle period is 60 seconds.
Note: Although the recycle period is 60 seconds, the recycle period might be longer if the problem is
because of the Portmapper service. The Portmapper functions are blocking functions that can have time-
out periods up to 2 to 3 minutes. This time is in addition to the 60 second recycle period.
To determine whether the event receiver is recycling after the initial console message is issued, issue the
DISPLAY STATUS command. While the event receiver is recycling, the status of the event receiver is
IPCYCLE.
Recycling the Trap-to-alert service for IP Connectivity problems

The trap-to-alert service enters an internal recycle mode if it cannot define its IP socket. This can occur if
TCP/IP is not active.
The trap-to-alert service issues an error message indicating the cause for entering the recycle mode, and
then issue the following error message:
IHS0181E The Trap-to-Alert Conversion will continue recycling until

it can successfully define a socket.
This is the last console message that the trap-to-alert service issues until the socket can be defined.
Further messages are sent only to the trap-to-alert service output log. The recycle period is 60 seconds.
To determine whether the trap-to-alert service is recycling after the initial console message is issued,
issue the DISPLAY STATUS command. While the trap-to-alert service is recycling, the status of the trap-
to-alert service is IPCYCLE.

Chapter 29. Diagnostic tools for the Event/
Automation Service
This chapter describes the diagnostic tools that are used to isolate and identify the source of a problem
for the Event/Automation Service. This chapter also describes how to access error logs and run traces
using the following resources:
• Output log files
• Trace files
• Online help support
This chapter also provides information for using diagnostic tools to collect problem determination
information such as the following information:
• Event/Automation Service output logs
• Online help for Event/Automation Service commands and error messages
• Event/Automation Service DISPLAY STATUS and DISPLAY QSTATS command
• Event/Automation Service TRACE command
• GENALERT command
• RPCINFO command (TCP/IP services)
• TestMode statement
• Looping the alert adapter and message adapter directly into the event receiver
• Looping the alert-to-trap service directly into the trap-to-alert service
Output log
The Event/Automation Service produces messages for errors, warnings, and information. Error messages
and other types of messages are written to the output log. The output log provides information that is
helpful in resolving problems.
For information about the format of the output log, refer to the IBM Z NetView Customization Guide.
Using online help

To receive help for any Event/Automation Service command, enter the following from the command line:
HELP EAS command name
Using commands
The following Event/Automation Service commands are helpful for diagnosing Event/Automation Service
problems.
DISPLAY STATUS
Use the Event/Automation Service DISPLAY STATUS command to help determine:
• Whether a service is active, inactive, or recycling
• Whether the alert adapter, confirmed alert adapter, message adapter, or confirmed message adapter
services are experiencing delays using TCP/IP connection services

• If the local TCP/IP service is active
• If the NetView PPI is active
• The list of designated event server IP addresses that the alert adapter and message adapter services
are using
• The list of IP addresses of event servers that the confirmed alert adapter and confirmed message
adapter are using
• The SNMP agent IP address that the alert-to-trap service is using
• The PPI mailbox identifier that the E/AS uses
• The PPI mailbox that the event receiver and trap-to-alert services use to forward their alerts
• The ports that the event receiver and trap-to-alert service use
Using DISPLAY STATUS for TCP/IP Connection Delays

If the alert adapter, confirmed alert adapter, message adapter, or confirmed message adapter services
seem to be experiencing delays when an event is processed, use the DISPLAY STATUS command to
determine whether the service is processing an event or the service is idle.
A status of UP, DOWN, or CO-IDLE for the service is an idle status. This indicates that the service is not
processing an event.
• If the service ConnectionMode is connection-oriented, a status of UP indicates that there is no current
connection to a designated event server from the ServerLocation statement. This status is normal if an
alert or message has not yet been sent to the service, and indicates a connectivity problem if at least
one alert or message has been sent. If the service ConnectionMode has no connection, this status is
normal regardless of how many alerts or messages have been sent to the service.
• A status of CO-IDLE occurs if the service is connection-oriented. This status indicates that a connection
exists to the designated event server.
• A status of DOWN indicates that the service is not active.
A status of GETPORT, SOCKET, CONNECT, SHUTDWN, CLOSE, RETRY, or FL-IDLE is an event processing
status. This can indicate that there is some type of delay while attempting to process an event. These
statuses can occur normally during event processing, but their duration is brief. If the status persists
across two invocations of the DISPLAY STATUS command, the service is experiencing a processing delay.
• The GETPORT status indicates that there is a problem attempting to resolve the port of a designated
event server. Delays in retrieving a port can be caused by the following items
– An inactive portmapper at the designated event server
– An incorrect server name or address on the ServerLocation statement
Delays in resolving the designated event server port for a single server can last for up to 120 seconds. If
there are multiple servers listed on the ServerLocation statement, the overall delay for resolving a port
for any one of the servers can be up to 120 seconds multiplied by the number of servers where the port
cannot be resolved.
Note: The GETPORT status does not apply to the confirmed message or confirmed alert adapter.
• The SOCKET status indicates that there is a problem attempting to retrieve a socket from TCP/IP which
is used to connect to a designated event server. The service should not experience any delays in
retrieving a socket.
• The CONNECT status indicates that there is a problem attempting to connect to an event server. Delays
in connecting to a server can be caused by the following:
– An incorrect server name or address on the ServerLocation statement.
– A network delay.
Delays in connecting to an event server can last for up to 3 minutes. If there are multiple servers listed
on the ServerLocation statement, the overall delay for connecting to any one of the servers can be up to
3 minutes multiplied by the number of servers where the connection cannot be established.

• The SHUTDWN status indicates that there is a problem attempting to shut down a connection with an
event server. The service should not experience any delays in shutting down a connection.
• The CLOSE status indicates that there is a problem attempting to close a connection with an event
server. The service should not experience any delays in closing a connection.
• The RETRY status indicates that an existing connection-oriented connection has been closed. The
connection might have been closed by the event server, or by the alert adapter, confirmed alert adapter,
message adapter, or confirmed message adapter service if it was not the primary connection and the
maximum number of events to send on a secondary connection has been reached. This status indicates
that a 60 second timeout is in progress. An attempt to connect to one of the servers in the
ServerLocation statement list begins after the RETRY timeout.
• The FL-IDLE status indicates that the number of events allowed per minute during a flush of the event
cache has been reached. This number is specified on the BufferFlushRate statement. The timeout can
be anywhere from nearly 0 seconds to 60 seconds, depending on how quickly the events were sent
before the BufferFlushRate was met.
DISPLAY QSTATS
Use the Event/Automation Service DISPLAY QSTATS command to help determine whether an event, such
as an alert, message, SNMP trap, or Event Integration Facility (EIF) event, was received and forwarded
within the E/AS. These events are counted as follows:
• The TOTAL SENT count for the CONTROL task represents the total of all alerts and messages delivered
across the PPI for the alert adapter, confirmed alert adapter, alert-to-trap, message adapter, and
confirmed message adapter services.
• The TOTAL RCVD count for the CONTROL task represents the total of all converted EIF events and
SNMP traps forwarded from the trap-to-alert service and the event receiver to the NetView alert
receiver task.
• The TOTAL RCVD count for the alert adapter or confirmed alert adapter represents the number of alerts
that have been forwarded for translation to EIF events.
• The TOTAL RCVD count for the alert-to-trap service represents the number of alerts that have been
forwarded for translation to SNMP traps.
• The TOTAL RCVD count for the message adapter or confirmed message adapter represents the number
of messages that have been forwarded for translation to EIF events.
• The TOTAL SENT count for the trap-to-alert service represents the number of SNMP traps that have
been translated and forwarded to the NetView alert receiver task.
• The TOTAL SENT count for the event receiver represents the number of EIF events that have been
translated and forwarded to the NetView alert receiver task.
• All other counts will remain at zero (0).
Trace
General tracing for the Event/Automation Service is not described in detail in this document. Tracing the
Event/Automation Service using the LEVEL parameter provides diagnostic information that is to be used
by an IBM Software Support representative to resolve problems that cannot be diagnosed using other
methods.
The IP tracing option for the alert adapter, confirmed alert adapter, message adapter, and confirmed
message adapter services is described in the following section. Although this option is not described in
detail, you can use it to provide more information about why an event might not have been sent to its
expected destination.
This option generates a much smaller amount of tracing output per event as compared to the amount of
tracing output generated using the LEVEL parameter for the same event. IP tracing output for an event
begins when the event is ready to be sent through TCP/IP (in the case of the alert adapter, message
Chapter 29. Diagnostic tools for the Event/Automation Service 493

adapter, or alert-to-trap services) or received from TCP/IP (in the case of the event receiver and trap-to-
alert services). The output ends for that event when the event is either sent, cached, or discarded.
The IP trace option

Use the IP trace option for the alert adapter, confirmed alert adapter, message adapter, or confirmed
message adapter services to assist in debugging problems with sending data to a designated event
server. To enable this option, use the TRACE command or the TRACE statement in the Event/Automation
Service global initialization file. Specify the following:
TRACE TASK=taskname IP=ON
Where taskname is the name of the service task. To disable tracing, issue the command with IP=OFF.
Note: This tracing option does not provide any output if the event is discarded by filtering before it is
ready to be sent.
The output log sample in Figure 74 on page 494 displays the result of IP tracing for the alert adapter
service. For the format of messages sent to the Event/Automation Service output log, refer to the IBM Z
NetView Customization Guide. The messages presented here refer to the specific data portion of the
output message. The message type (msgtype) is IP for all IP trace messages.
1 Thu May 14 22:14:05 2009 ALERTA :IHSAACOM:1075 IP: Resolving all

ServerLocation IP addresses
2 Thu May 14 22:14:05 2009 ALERTA :IHSAACOM:1731 IP: ServerLocation nmpipl06 is
not an IP address; resolving the name
3 Thu May 14 22:14:07 2009 ALERTA :IHSAACOM:1761 IP: Name resolved to address
1.2.3.4
4 Thu May 14 22:14:07 2009 ALERTA :IHSAMAIN:0208 CONSMSG: IHS0124I Alert Adapter task
initialization complete.
5 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1140 IP: Attempting to send event:
SNA_Performance_Degraded;source=NV390ALT;origin='
B3088P2/SP,NAP/TP,DECNET/TERM,RALV4/DEV,TX12/DEV';sub_origin=TX12/DEV;hostname=USIBMNT.NTVED;
adapter_host=NMPIPL06;date='May 14 22:1
6:44';severity=WARNING;msg='PERFORMANCE DEGRADED:CONTROLLER';adapter_host_snanode=USIBMNT.NTVED;
event_type=NOTIFICATION;arch_type=GE
NERIC_ALERT;product_id=3745;alert_id=00000009;block_id='';action_code='';alert_cdpt=4000;
self_def_msg=[ALRTTXT2];event_correl=[N/A];
incident_correl=[N/A];adapter_correl=E7735935C;END
6 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1172 IP: The event was saved due to
filtering on statement 1.
7 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1698 IP: TEC port at server 1.2.3.4 is
1028
8 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1800 IP: Getting a socket for
ServerLocation 1
9 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1826 IP: Getting a connection for
ServerLocation 1
10 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1855 IP: Connection completed for
ServerLocation 1, IP address 1.2.3.4, Port 1028
11 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1989 IP: Attempt to send 497 bytes of
data (533 including data header).
12 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:2056 IP: Data sent successfully
13 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1627 IP: The event was sent to
location nmpipl06, IP address 1.2.3.4
Figure 74. Example output of IP tracing for the alert adapter service
Note: The numbers preceding each line are not a part of the output log. They are inserted for reference
purposes. The module line numbers following the module name in this example might be different on
your system.
In Figure 74 on page 494, a single alert was sent through the alert adapter service. The configuration file
for the alert adapter service contains the following statements:
ServerLocation=nmpipl06
ServerPort=0
ConnectionMode=CO
FilterMode=IN
Filter:Class=SNA_Performance_Degraded;adapter_host=NMPIPL06
Following are descriptions of the lines in Figure 74 on page 494:

1–3
During the alert adapter service initialization, all locations on the ServerLocation statement are
resolved to IP addresses if they are not already specified as IP addresses. The first 3 lines of the IP
trace show the address resolution. Lines 2 and 3 are repeated for each location on the ServerLocation
statement; in this example there is a single location. If the location on the ServerLocation statement
was specified as 1.2.3.4, the following line shows in place of lines 2 and 3:
2 Thu May 14 22:14:07 2009 ALERTA :IHSAACOM:1769

IP: ServerLocation 1.2.3.4 is an IP address.
4
Is a system console message that is issued by the alert adapter service when it has completed
initialization. All console messages issued by any service of the Event/Automation Service are sent to
the output log.
5
Displays the event that is to be sent. This is the full Event Integration Facility (EIF) event. The newline
character and the event separator which end every event have been replaced by the text <NL> and
<SEP>, respectively, so they can display properly in the output log. If this line shows in your output
log, then the alert has been successfully converted to an event by CDS processing and is sent to a
designated event server. This line also signifies the beginning of IP tracing for this event. All IP trace
entries that follow this entry relate to this event.
6
Indicates that the event passed the event filtering described by the Filter and FilterMode statements.
In this example, the FilterMode is IN. This FilterMode indicates that events are only passed if they
match one of the Filter statements in the service configuration file. The single Filter statement in the
configuration file in this example does match the event and the event passes event filtering.
If the FilterMode had been OUT, this line states that the event was discarded and is the last line of
output for this event. If there were no Filter statements in the service configuration file, or if the event
did not match any of the Filter statements, the statement number is 0 (zero). Use the SETTINGS
command to display the Filter statements from the service configuration file.
7
Indicates that the designated event server port has been discovered. The ServerPort statement in the
service configuration file contains a port of 0, which indicates that the actual server port is discovered
using the portmapper program of the server. This is the port in which the designated event server is
listening to receive events. If the portmapper is not active or there is any other problem in discovering
the port, an output similar to the following is displayed:
7 Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1698

IP: Could not retrieve the TEC port at server 1.2.3.4.: EZA4339E
RPC: Port mapper failure - EZA4339E RPC: Timed out
7a Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1731
IP: ServerLocation nmpipl06 is not an IP address; resolving the name
7b Thu May 14 22:16:44 2009 ALERTA :IHSAACOM:1761
IP: Name resolved to address 1.2.3.4
7c Thu May 14 22:17:44 2009 ALERTA :IHSAACOM:1698
IP: Could not retrieve the TEC port at server 1.2.3.4.: EZA4339E
RPC: Port mapper failure - EZA4339E RPC: Timed out
7
Indicates that the remote port cannot be retrieved. The message that follows the IP address is
variable, and is based on the actual error that occurred while retrieving the port. In this example,
the error was a portmapper failure because of a portmapper timeout. A portmapper timeout
usually indicates that the remote portmapper is not active.
7a-7c
Indicate that the ServerLocation resolves to an IP address. This occurs only if the location was not
already in the form of an address. This is done to account for the possibility that the IP address
associated with the name might have changed since the last time the alert adapter service
resolved the location to an IP address. After resolving the IP address, another attempt is made to

retrieve the port. Since the IP address did not change, the output on line 7c is the same as the
output on line 7.
The process of resolving the server port might occur for more than one server. The resolution occurs
for each location on the ServerLocation statement that has a corresponding ServerPort of 0 (zero),
until one of the ports can be resolved. The sequence of output messages shown in 7 through 7c can
be repeated multiple times until either a port is resolved or the ServerLocation list has been
exhausted.
8–10
Indicate that the connection to the remote server is complete. Line 8 indicates that a local socket is
being retrieved from TCP/IP. Line 9 indicates that the connection to the remote socket is in progress.
Line 10 indicates that the connection was successful. If either the socket or connection fails, an
output line indicating the failure shows in place of the line corresponding to the socket or connection
request.
11
Is output before sending the event to the server. The data header is an internal header used by the
server and is not part of the event data.
12
Indicates that the data was successfully sent to the server. If a failure occurs while sending data to
the server, an output line indicating the failure shows instead.
13
Indicates that the event was successfully sent to the server but does not guarantee that the data is
delivered to the server. TCP/IP has accepted the data and attempts to deliver it. If the connection is
broken for any reason before TCP/IP can deliver the data to the server, there is no indication that the
data was not delivered.
The IP trace statements used by the message adapter service are similar to those used by the alert
adapter. The IP tracing output by the other services varies based on the information that is relevant to
that service.
NCCF GENALERT
Use the GENALERT command to drive test alerts through the hardware monitor to the Event/Automation
Service. You can verify that the path from the hardware monitor to the designated event server and the
SNMP agent is active using these test alerts.
RPCINFO
RPCINFO is a TCP/IP services command that enables you to query information about active portmappers.
Use this command to help you determine the following:
• Whether the portmapper is active on a host anywhere in your IP network.
• The ports that have been defined to the portmapper, and which program number and program version is
associated with each port.
The alert adapter and message adapter expect designated event servers to be registered as program
number 100033057. The designated event servers are registered with version number 1. Likewise, the
event receiver attempts to register with portmapper with the same program number and version number
to emulate a designated event server.
For information about using the RPCINFO command, see the TCP/IP library.

Using the TestMode statement
Use the TestMode statement to indicate that converted alerts from the alert adapter or converted
messages from the message adapter are to be sent to a debugging file rather than forwarded to a
designated event server. Use the value YES in the TestMode statement to place the Event Integration
Facility (EIF) events into the debugging file.
You can also use the TestMode statement to indicate that converted alerts from the confirmed alert
adapter or converted messages from the confirmed message adapter are to be sent to a debugging file
rather than forwarded to an event server. Use the value YES in the TestMode statement to place the EIF
events into the debugging file. At that time, confirmations are not expected because the EIF events are
not being sent to an event server that can confirm them.
Sending EIF events to a debugging file is useful for validating the format of your events before forwarding
them to an active event server. It can also be used to verify the forwarding of alerts and messages
through the Event/Automation Service to the point where it is forwarded across the IP network. The
debugging file to which the data is sent is specified on the ServerLocation statement.
For more information about the TestMode and ServerLocation statements, refer to the IBM Z NetView
Looping the Alert or Message Adapter to the Event Receiver

Another useful problem determination tool is to forward alert or message adapter to the event receiver.
Using this function, you can verify that each of these services are functioning correctly without having to
use the designated event server to receive or forward Event Integration Facility (EIF) events.
To loop either adapter back to the event receiver, specify the local host name or IP address on the
ServerLocation statement. If the event receiver is not configured to use the portmapper, specify the event
receivers ServerPort value on the adapters ServerPort statement.
If you use the GENALERT command to generate an alert, notice that two alerts are displayed on the NPDA
Alerts-Dynamic panel: one for the alert originated with the GENALERT command and another for the
same alert after it has been converted into an EIF event and then converted back into an alert and
forwarded to the NetView hardware monitor. The resource name for all alerts generated by the event
receiver is NV390ALT.
Using this loopback method, you can verify the following:
• TCP/IP is active on the local host, and the Event/Automation Service can forward event data to and
receive event data from an IP socket.
• If required, the portmapper on the local host is active.
• The alert or message has been translated to the expected EIF event; likewise, the event has been
translated to the correct alert. You can verify that the alert or message was translated correctly because
the alert that was forwarded from the event receiver contains the original EIF event in the SV 31s. This
original event was created by the alert or message adapter.
Looping the alert-to-trap service to the trap-to-alert service

The alert-to-trap service can be looped to the trap-to-alert service. This function enables you to verify
that each of these services are functioning correctly without having to use a remote SNMP manager and
agent to receive or forward SNMP traps.
To loop either service, configure the SNMP agent that receives the SNMP trap generated by the alert-to-
trap service to forward the trap to the trap-to-alert service, which is an SNMP manager. If your SNMP
agent provides the capability of specifying a port, use the same port that is specified in the PortNumber
statement in the trap-to-alert configuration file.

If you use the GENALERT command to generate an alert, notice that two alerts are displayed on the NPDA
Alerts-Dynamic panel: one for the alert originated with the GENALERT command and another for the
same alert after it has been converted into an SNMP trap and then converted back into an alert and
forwarded back to the NetView hardware monitor. The resource name for all alerts generated by the trap-
to-alert service is the first 8 characters of the IP address that originated the trap.
Using this loopback method, you can verify that:
• TCP/IP is active on the local host, and the Event/Automation Service can forward event data to and
receive event data from an IP socket.
• The SNMP agent is active and forwarding the trap data correctly.
• The alert has been translated to the expected SNMP trap; likewise, the SNMP trap has been translated
to the correct alert. You can verify that the alert was translated correctly because the alert that was
forwarded from the trap-to-alert service contains the original SNMP trap in the SV 31s. This original
SNMP trap is what was created by the alert-to-trap service.

Part 10. Diagnosing Z NetView Enterprise
Management Agent problems

Chapter 30. Z NetView Enterprise Management Agent
worksheet
This chapter contains information that you can use to help determine the cause of failures within the Z
NetView Enterprise Management Agent (NetView agent).
alteration.
General information
1. Date:
2. Problem Number:
3. Host:
• Component ID
• IBM Z NetView operating system and level
• Recommended service update (RSU) level
• NetView agent build level. This can be found in RKLVLOG. The KLVST045 BASIC SERVICES DRIVER:
message (for example, KLVST045 BASIC SERVICES DRIVER: tms_ctbs630fp3:d4191a) should be
recorded, and the level of the KDS component. The KDS component level can be found by searching
for Component: kds in the log. The line below this line contains the driver level. For example:
Component: kds
Driver: tms630fp3:d4204a/4455505.5
4. The NetView agent data files version, located in the following locations:
Windows:
<install_dir>\InstallITM\ver\KNAWICMS.ver
UNIX:
Version information about UNIX/Linux is stored in the $install_dir/registry directory:
• The nat*.ver files are the application support version files
– The natms.ver file is for the Tivoli Enterprise Monitoring Server
– The natps.ver file is for the Tivoli Enterprise Portal
– The natpw.ver file is for the Tivoli Enterprise Portal browser client
– The natpd.ver file is for the Tivoli Enterprise Portal desktop client
• Host

– The operating system and RSU level.
– Other products and their maintenance levels.
Include information about any OMEGAMON® XE products if you are using the links between the
OMEGAMON XE product and the NetView agent.
• Tivoli Management Services components:
– The operating system and level you are using for the Tivoli Enterprise Monitoring Server:
- Is the Tivoli Enterprise Monitoring Server a Hub or Remote?
– The operating system and level you are using for the Tivoli Enterprise Portal Server
– The operating system and level you are using for the Tivoli Enterprise Portal
- How much memory is installed on each workstation involved with the Tivoli Management Services
components and the NetView agent data files?
- Have you recently changed any of the systems where the NetView agent data files or Tivoli
Management Services components are running?
- Have you recently changed anything on the system where NetView is running?
– Have you changed or added any hardware?
– Have you applied software maintenance?
– Have you customized workspaces?
– Have you made any other changes?
– Do you know whether the speed of the computer that you are using is sufficient for the Tivoli
Management Services components?
Problem description
6. Other?
7. If the problem seems to be at the NetView host, can you recreate the problem with the NetView trace
running default options?
8. If you have more than one Tivoli Enterprise Portal workstation, does the problem occur consistently on
all workstations?
Check the appropriate problem category that matches the symptoms associated with your problem.
Abend problems
For abend problems or processor exception problems, complete the following items:
3. If a NetView user abend occurred, use the online help facility (type HELP ABEND and use the scroll
function to locate the abend code).

• NetView abend
– A copy of the network log
– The first unformatted memory dump of the abend, which includes the CNMTRACE data space, if
tracing is enabled.
– A completed NetView problem worksheet.
• NetView agent abends
– A copy of RKLVLOG, RKLVSNAP, and RKPDLOG
– The first unformatted memory dump of the abend
– A memory dump of the NetView agent data space or data spaces. You must manually dump this
after the abend. The Tivoli agent data space is titled CNMEMnnn, where nnn is a number.
– A completed NetView problem worksheet.
• Gather the following information from the memory dump:
c. When was the module compiled?
Processor Traps
For processor exception problems, respond to the following questions:
1. What is the trap code?
2. Is there any other information related to the exception that can be provided?
3. What processes were occurring at the time of the abend or trap?
4. Gather the logs for the components that failed. See the IBM Tivoli Monitoring Problem Determination
Guide, GC32-8458, for information about where logs are located for Tivoli Management Services
components.
Message problems
• Message ID.
• Commands
• Other
4. Did you follow the actions prescribed in the NetView online help? If so:
• What occurred?
Chapter 30. Z NetView Enterprise Management Agent worksheet 503

Loop, hang, or lockup problems

For loop, hang, or lockup problems, complete the following items:
4. If the loop appears to be in the NetView address space, follow the problem classification instructions
for loop problems in Chapter 4, “NetView program problem worksheet,” on page 45.
5. If the loop appears to be in the NetView agent address space, obtain the following documentation:
• The scenario leading to the problem
• A system log
• NetView agent RKLVLOG
• A memory dump of the NetView agent address space and the NetView agent data space or data
spaces. The NetView agent data space is titled CNMEMnnn, where nnn is a number.
Wait problems
1. What events led up to the wait?
4. If the wait appears to be in the NetView address space, follow the problem classification instructions
for wait problems in Chapter 4, “NetView program problem worksheet,” on page 45.
5. If the wait appears to be in the NetView agent address space, obtain the following documentation:
• The scenario leading to the problem
• A system log
• NetView agent RKLVLOG
• A memory dump of the NetView agent address space and the NetView agent data space or data
spaces. The NetView agent data space is titled CNMEMnnn, where nnn is a number.


5. If the output is incorrect on the Tivoli Enterprise Portal, issue the same command from a NetView
3270 command line. Are the results similar?
Note: Note that 3270 commands are real-time commands, while the data on the Tivoli Enterprise
Portal is a combination of sampled and real-time data.
• Using the message revision table (MRT)?
• A copy of the NetView log containing the output of several TASKMON, TASKUTIL, or TASKURPT
96.
• The NetView agent RKLVLOG.
• Screen captures if the data on the Tivoli Enterprise Portal is incorrect.
• OBEY files
Verifying TCP/IP stack or DVIPA Information

If information related to TCP/IP stacks or DVIPA appears to be incorrect, you can issue DISPLAY
TCPIP,,NETSTAT commands to verify if NetView information is correct. The table below maps the NetView
program data type to the appropriate DISPLAY TCPIP,,NETSTAT command.
Table 167. NetView program data type and DISPLAY TCPIP,,NETSTAT commands
NetView Data Type DISPLAY TCPIP,,NETSTAT parameter
TCP/IP Stack CONFIG
IP Interface DEVLINKS
DVIPA Definition and Status VIPADCFG
Distributed DVIPA VDPT
Distributed DVIPA Connection Routing VCRT
VIPA Routes VIPADYN,VIPAROUT
For more information about the DISPLAY TCPIP,,NETSTAT command, see the z/OS Communications
Server: IP System Administrator’s Commands manual.
4. What are the data collection intervals for the enabled TEMA subtowers?
5. What are the row values for the enabled TEMA subtowers?
6. How many Tivoli Enterprise Portal users are sending commands to the same NetView host?
Chapter 30. Z NetView Enterprise Management Agent worksheet 505

• A copy of the NetView log containing the output of several TASKMON, TASKUTIL, or TASKURPT
commands. The log should also contain the output of several NACTL LISTINFO commands. See
“Network log with CMDMON, TASKUTIL or TASKMON command output ” on page 96.
• The NetView trace. See “NetView trace” on page 100.
• Information describing your NetView operating environment.
• Information describing your Tivoli Management Services environment.
• Descriptions of any modifications to your system.
• The NetView agent RKLVLOG.
1. Identify the order number, revision level, title of the manual, the number of the online help panel
involved, the panel identifier of the Configuration Tool help panel, or the section in the NetView agent
online help.
name.
4. If the problem affects the operation or use of the NetView program or the NetView agent, contact IBM
Software Support.
5. If the problem is with an online help panel, contact IBM Software Support.

the Z NetView Enterprise Management Agent
Use Table 168 on page 507 to locate examples of problems when using the Z NetView Enterprise
Management Agent (NetView agent). To use the table, do these steps:
1. Locate your problem scenario in the first column and go to the indicated page for a description of the
problem and resolution steps for correcting the problem.
If you cannot solve your problem by using the examples, follow the instructions in Chapter 2, “Classifying
problems,” on page 13 and Chapter 3, “Documenting and reporting problems,” on page 23 before
contacting IBM Software Support.
Table 168. Z NetView Enterprise Management Agent Problem Scenarios

NetView agent is not displayed in the Navigator view “NetView agent is not displayed in the Navigator
view” on page 508
Active/Active Sites subnode is not displayed in the “Active/Active Sites subnode is not displayed in the
physical Navigator view. physical Navigator view” on page 509
NetView agent node unexpectedly goes offline. “NetView agent node unexpectedly goes offline ” on
page 509
NetView subnode unexpectedly goes offline. “Z NetView subnode unexpectedly goes offline ” on
page 509
Tivoli Enterprise Monitoring Server becomes inactive “Tivoli Enterprise Monitoring Server becomes inactive
while the NetView agent is running. while the NetView agent is running” on page 510
NetView agent workspace has no data. “NetView agent workspace has no data” on page
510
A GDPS Continuous Availability solution workspace “A GDPS Continuous Availability solution workspace
does not have data. has no data” on page 512
The NetView agent workspace has partial data or “NetView agent workspace has partial data or
incomplete data. incomplete data” on page 514
Message "KFWITM081E The link target cannot be “Message "KFWITM081E The link target cannot be
found" when attempting to link to the workspace of found" when attempting to link to the workspace of
another product. another product” on page 514
No NetView agent workspaces available. “No NetView agent workspaces available” on page
515
Workspace names displayed in navigation tree are “Workspace names displayed in navigation tree are
unreadable. unreadable” on page 515
NACMD fails with BNH805I during initialization. “NACMD fails with BNH805I during initialization” on
page 515
No commands available from the Take Action window. “No commands available from the Take Action
window” on page 515

Table 168. Z NetView Enterprise Management Agent Problem Scenarios (continued)
No NetView agent situations available. “No NetView agent situations available” on page
516
Incorrect results when using the icons in the NetView “Incorrect results when using the icons in the
Command Response Summary view to find or sort NetView Command Response Summary view to find
data. or sort data” on page 516
Cross-product links missing from link list. “Cross-Product links missing from link list” on page
516
Problems with cross-product linking when linking to an “Problems with cross-product linking when linking to
OMEGAMON XE workspace. an OMEGAMON workspace” on page 516
NetView agent workspaces have no column headings “NetView agent workspaces have no column headings
for the table views. for the table views” on page 517
Cannot start the NetView agent. “Cannot start the NetView agent” on page 517
Missing NetView data when hub Tivoli Enterprise “Missing NetView data when hub Tivoli Enterprise
Monitoring Server is active on both controllers. Monitoring Server is active on both controllers” on
page 518
NetView agent is not displayed in the Navigator view

If the configured Tivoli Enterprise Monitoring Server is not available to the NetView agent when the agent
starts, the agent is not displayed on the Tivoli Enterprise Portal. In addition, RKLVLOG contains several log
entries to the effect that the endpoint is not available. After noting any error messages, verify these items:
• Verify that the NetView agent job is active. The z/OS D J,agentjobname command shows if the agent
is running.
• Verify that the NetView agent initialized properly. After starting the agent, examine the system logs and
RKLVLOG. Look for the BNH856I and BNH877I messages, which indicate that the agent is active. The
BNH855E message, which is issued when the agent does not initialize properly, indicates a critical error
occurred during initialization. Correct any problems and recycle the NetView agent.
• The NetView agent might not be able to connect to the NetView program because the PPI is not active.
The NetView agent continues to try to connect over the PPI indefinitely. Start the SSI with the PPI
option. Verify that the NetView subsystem job is running by using the z/OS D J command.
• If the PPI is active, verify that the agent is connected over the PPI by using the NetView NACTL
LISTCONN command. If the agent and the NetView program are connected, the command output looks
similar to this:
BNH888I DISPLAY OF NETVIEW ENTERPRISE MANAGEMENT AGENT CONNECTIONS

BNH889I TASK STATUS SOURCE DEST PPI LCL PPI
BNH890I NAME NAME RECEIVER RECEIVER
BNH834I -------- ------------ -------- --------- ---------
BNH834I AUTONALC CONNECTED NTVE4 CNMEMARX NTVE4
• Verify communication between the NetView agent and the Tivoli Enterprise Monitoring Server.
In the RKLVLOG data set for the agent, look for a message that indicates a successful connection to a
Tivoli Enterprise Monitoring Server such as the following message for a runtime environment that is
named PARMGRTE:
ED372343:kraarreg.cpp,1125,"ConnectToProxy") Successfully connected to

CMS PARMGRTE:CMS using ...
If the RKLVLOG data set contains several log entries that indicate that the endpoint is not available,
check the following items:

– Verify that the Tivoli Enterprise Monitoring Server is running. If the Tivoli Enterprise Monitoring Server
has not been started, start it. The NetView agent remains active and attempts to reconnect to the
Tivoli Enterprise Monitoring Server. If the configuration is correct, the NetView agent establishes a
connection with the Tivoli Enterprise Monitoring Server and becomes available without any operator
interaction.
– Confirm the connection parameters. The connection parameters used by the NetView agent are
created during the runtime environment configuration and stored in the
&rhilev.&rte.RKANPARU(KNAENV) members. Communications protocols were specified during
configuration of the NetView agent and the Tivoli Enterprise Monitoring Server. Verify that the
NetView agent and the Tivoli Enterprise Monitoring Server agree on the protocols in use.
– Verify network connectivity. Verify that a firewall or other networking issue does not prevent
communication between the Tivoli Enterprise Monitoring Server and the NetView agent.
Active/Active Sites subnode is not displayed in the physical Navigator view

If the Active/Active Sites subnode (GDPS Continuous Availability solution) is not displayed in the physical
Navigator view, check the following configuration items:
• Verify that the KNA_ACTACT environment variable is set up correctly in the NetView agent. For
information about setting the variable, see IBM Z NetView for Continuous Availability Configuring and
Using the GDPS Continuous Availability Solution.
• Verify that the TEMA.ACTIVEACTIVE subtower is enabled. For information about enabling towers, see
IBM Z NetView Administration Reference.
NetView agent node unexpectedly goes offline

If the NetView agent node unexpectedly goes offline (indicated by the node becoming disabled on the
screen), verify the following items:
• Verify that the Tivoli Enterprise Monitoring Server and the NetView agent are communicating. To do this,
use the NetView NACTL LISTCONN command.
• Verify that the NetView agent started procedure is still active. Examine the RKLVLOG and RKLVSNAP
data sets for more information.
The status of any agent node or subnode can be examined on the Managed System Status workspace. To
display the Managed System Status workspace, click the topmost node in the Navigation Tree Enterprise
and then right-click the topmost node to display a context menu for the Enterprise node. Select
Workspace > Managed System Status. In this scenario, the NetView agent node is online and the
subnode is offline.
Z NetView subnode unexpectedly goes offline

If the NetView subnode unexpectedly goes offline (indicated by the subnode becoming disabled on the
screen), a communication problem has occurred between NetView and the NetView agent. Because the
NetView agent node remains active, an active connection still exists between the NetView agent and the
Tivoli Enterprise Monitoring Server. A BNH851I message is issued if a particular subnode cannot
communicate with the NetView program. Verify the following items:
• Verify that the NACMD command was issued successfully.
• Verify that the NetView program is still active. To do this, use the NetView NACTL LISTCONN command.
• Verify that the NetView SSI is still active.
Tivoli Enterprise Monitoring Server becomes inactive while the NetView
agent is running
If the Tivoli Enterprise Monitoring Server becomes inactive while the NetView agent is running, the Tivoli
Enterprise Portal Server can no longer communicate with the Tivoli Enterprise Monitoring Server and the
KFWIFM007 message is displayed in a pop-up window. The NetView agent continues to run.
As the Tivoli Enterprise Monitoring Server recovers, communication should be re-established between the
Tivoli Enterprise Portal and the Tivoli Enterprise Monitoring Server. When the Tivoli Enterprise Portal is
again able to communicate with the Tivoli Enterprise Monitoring Server, that server again becomes
available. No operator interaction is required.
Depending on the length of time that the Tivoli Enterprise Monitoring Server is unavailable, some
situational and historical data might be lost. The default heartbeat timer between the Tivoli Enterprise
Monitoring Server and the NetView agent is 10 minutes. Therefore, it might take as long as 10 minutes
before the Tivoli Enterprise Monitoring Server recovers and you can again see data from the NetView
agent.
See the IBM Z NetView Installation: Configuring the NetView Enterprise Management Agent for additional
information.
NetView agent workspace has no data

A workspace might have no data either because of the workspace or because data collection for the
workspace was not properly configured. NetView Audit Log, NetView Command Response, and NetView
Log workspaces are populated only as a result of take action commands.
All other agent workspaces are populated based on a data collection tower or subtower, or a TEMA tower
or subtower in the CNMSTYLE member. No data is displayed in these workspaces unless the appropriate
TEMA tower or subtower is enabled. The following table shows this information for primary workspaces.
The table also shows the data collection autotask.
Table 169. Data collection towers and subtowers

Default Data
Collection Display tower or
Workspace Data Collection tower or subtower Autotask subtower
Distributed DVIPA DVIPA.DVROUT AUTOCT4 TEMA.DVROUT
Connection Routing
Distributed DVIPA Server DVIPA.DVTAD AUTOCT2 TEMA.DVTAD
Health
Distributed DVIPA Targets DVIPA.DVTAD AUTOCT2 TEMA.DVTAD
DVIPA Connections DVIPA.DVCONN AUTOCT3 TEMA.DVCONN
DVIPA Definition and DVIPA AUTOCT1 TEMA.DVDEF
Status
DVIPA Sysplex DVIPA.DVTAD AUTOCT2 TEMA.DVTAD
Distributors
HiperSockets DISCOVERY.INTERFACES. AUTOCT5 TEMA.HIPERSOCKETS
Configuration and Status HIPERSOCKETS
Inactive TCPIP TCPIPCOLLECT.TCPCONN and AUTODC3 TEMA.CONINACT
Connection Data TEMA.CONINACT
NetView Applications DISCOVERY AUTOCT7 TEMA

Table 169. Data collection towers and subtowers (continued)
Default Data
NetView Tasks TEMA.HEALTH AUTODC1 TEMA.HEALTH
OSA Channels and Ports DISCOVERY.INTERFACES.OSA AUTOCT5 TEMA.OSA
Session Data TEMA.SESSACT AUTODC4 TEMA.SESSACT
Stack Configuration and DISCOVERY AUTOAON TEMA.SYSPLEX
Status
TCPIP Connection Data TEMA.CONNACT AUTODC2 TEMA.CONNACT
Telnet Server DISCOVERY.TELNET AUTOCT6 TEMA.TELNET
Configuration and Status
VIPA Routes DVIPA.DVROUT AUTOCT4 TEMA.DVROUT
• Verify that the related towers and subtowers are enabled for the workspace in the CNMSTYLE member.
• Verify that the ROWSxxxx value (where xxxx represents the workspace) specified in the CNMSTYLE
member for the display tower or subtower is not zero.
• Verify that the AUTOTASK associated with the data collector is active and running data collection
commands.
• For workspaces that have a different data collector than display tower or subtower, issue the COLLCTL
LISTINFO command and inspect the status of the data collector. If the data collector is inactive, issue
COLLCTL START with the appropriate value.
• For workspaces that have the same data collector and display tower or subtower, issue the NACTL
LISTINFO command and inspect the status of the data collectors. If the data collector is inactive, issue
NACTL START with the appropriate value.
• Look for message BNH881I in the NetView log. If this message is present, use the IBM Z NetView
message help facility to find more information about the cause of the failure.
• Check the NetView log for errors on the data collection autotasks. See Table 169 on page 510 above.
• Do these steps if the OSA workspace has no data:
– Verify that RODM is started.
– Verify that the SNMP agent (OSNMPD) and the OSA SNMP subagent (IOBSNMP) are configured and
running.
– If the DSI047E message is present in the NetView log, ensure that the appropriate towers and
subtowers are enabled in the CNMSTYLE member. For more information about the towers and
subtowers, see IBM Z NetView Administration Reference.
• Do these steps if the HiperSockets workspace has no data:
– Verify that RODM is started.
– Verify that the SNMP agent is configured and running.
– If the DSI047E message is present in the NetView log, ensure that the appropriate towers and
subtowers are enabled in the CNMSTYLE member. For more information about the towers and
subtowers, see IBM Z NetView Installation: Configuring the NetView Enterprise Management Agent.
• If you click Cancel from a filter window, the target workspace is displayed without any data. In this
scenario, you have clicked a link to a filtered workspace, and a filter window is displayed. In the filter
window, specify or change values for one or more of the fields and click OK to display the filtered data in
the target workspace. When you click OK, the values you specified are saved, and the target workspace
is displayed using the specified values. If you click Cancel, any changes that you made are discarded
and the target workspace is displayed with no data. A filter window is displayed when clicking the
following links:
– Filtered DVIPA Connections
– Filtered Inactive TCPIP Connection Data
– Filtered Session Data
– Filtered TCPIP Connection Data
• Filter settings might prevent or delay data display. In this scenario, you have clicked a navigation item
or you have clicked a link and the workspace either displays no data or does not show all the data that
you expect. Many of the workspaces that are provided by the NetView agent are defined with filters.
Each view in the workspace can have filters defined. These filters restrict the data that is displayed to
the rows that might be interesting to the user. To view the filters that are defined to a workspace, right-
click in the view and select Properties... .
There are two kinds of filters to check: view filters and query filters.
1. Check the view filters first by selecting the Filters tab in the Properties... view. The view
filters determine which attributes are displayed in the views and are also used to filter out rows of
data returned by queries.
2. If modifying the view filters does not produce the results you want, click Select a Query to view
or change the filters that are defined in the Specification view of the query editor. Adjust the filters to
meet the needs of your enterprise. Some queries are used by multiple views and workspaces;
changing the query filter changes the behavior of all views and workspaces that use the query.
See the IBM Z NetView Enterprise Management Agent online help for information about the filters that
are defined for the product-provided workspaces. See the IBM Tivoli Monitoring: Tivoli Enterprise Portal
User’s Guide for information about defining and customizing workspaces and views.
A GDPS Continuous Availability solution workspace has no data

A GDPS Continuous Availability solution workspace has no data. This can happen because the data
collection for the workspace was not properly configured. The workspaces are populated based on the
ACTIVEACTIVE and TEMA towers and the ACTIVEACTIVE subtower statements in the CNMSTYLE
member. No data is displayed in these workspaces unless the appropriate TEMA tower or subtower is
enabled. Table 170 on page 512 shows the data collection tower or subtower, the default data
collection autotask, and the display tower or subtower that must be defined for the workspaces.
Table 170. Data collection and display towers and subtowers for GDPS Continuous Availability solution
workspaces
Default Data
Active/Query Workloads ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
DB2 Replication Details ACTIVEACTIVE.REPLICATION.DB2 AUTOACT2 TEMA.ACTIVEACTIVE
DB2 Replication Details ACTIVEACTIVE.REPLICATION.DB2 AUTOACT2 TEMA.ACTIVEACTIVE
for Workload
IMS Replication Details ACTIVEACTIVE.REPLICATION.IMS AUTOACT3 TEMA.ACTIVEACTIVE
Linux on z Systems® ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Workload Server Details
Load Balancer Groups ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Load Balancer Workloads ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Load Balancers ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE

Table 170. Data collection and display towers and subtowers for GDPS Continuous Availability solution
workspaces (continued)
Default Data
Replication Servers ACTIVEACTIVE.REPLICATION.DB2 AUTOACT2 TEMA.ACTIVEACTIVE
ACTIVEACTIVE.REPLICATION.IMS AUTOACT3 TEMA.ACTIVEACTIVE
ACTIVEACTIVE.REPLICATION.VSAM AUTOACT4 TEMA.ACTIVEACTIVE
Replication Workloads ACTIVEACTIVE.REPLICATION.DB2 AUTOACT2 TEMA.ACTIVEACTIVE

ACTIVEACTIVE.REPLICATION.IMS AUTOACT3 TEMA.ACTIVEACTIVE
ACTIVEACTIVE.REPLICATION.VSAM AUTOACT4 TEMA.ACTIVEACTIVE
SNA Workload Server ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE

Details
VSAM Replication Details ACTIVEACTIVE.REPLICATION.VSAM AUTOACT4 TEMA.ACTIVEACTIVE
Workload Lifeline ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Advisors
Workload Lifeline Agents ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Workload Servers ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Workload Site Details ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Workload Sites ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Workloads ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
z/OS Workload Server ACTIVEACTIVE.LIFELINE AUTOACT1 TEMA.ACTIVEACTIVE
Details
• Verify that the related towers and subtowers are enabled for the workspaces in the CNMSTYLE member.
• Verify that the ROWS xxxx value (where xxxx represents the workspace) that is specified in the
CNMSTYLE member for the display tower or subtower is not zero.
• Verify that the AUTOTASK that is associated with the data collector is active and is running data
collection commands.
• Verify that the autotask identified by the ACTDATA function (AUTOADAT by default) is active.
• Issue the ACTVCTL LISTINFO command and inspect the status of a data collector. If the data collector
is inactive, issue the ACTVCTL START command to start it.
Data collection for workspaces requiring the ACTIVEACTIVE.LIFELINE subtower is done on controller
systems. Data collection for workspaces requiring the ACTIVEACTIVE.REPLICATION subtower is done
on production systems.
• Look for the BNH881I message in the NetView log. If this message is present, use NetView message
help to find more information about the cause of the failure.
• For GDPS Continuous Availability solution workspaces with no data, check the NetView log for errors
issued as a result of the ACTVCTL collector command as shown in Table 171 on page 513.
Table 171. Commands that collect GDPS Continuous Availability solution data
Command Type of data collected
ACTVCTL START=LIFELINE Workload Lifeline Advisor
ACTVCTL START=DB2 DB2 (Q replication)
Table 171. Commands that collect GDPS Continuous Availability solution data (continued)
Command Type of data collected
ACTVCTL START=IMS IMS replication
ACTVCTL START=VSAM VSAM replication
• Administrators control which users can access the individual workspaces. If an operator cannot see
data for a particular workspace, the operator might not be permitted to access this type of data. For
information about permitting and restricting operator access to workspaces, see the IBM Tivoli
Monitoring: Administrator’s Guide.
NetView agent workspace has partial data or incomplete data

If the NetView agent workspace has partial data or incomplete data, some of the data is missing from the
workspace. A possible cause of this is that the NetView agent has exceeded its extended storage. To
verify if the NetView agent has exceeded its extended storage, examine the RKLVLOG file and look for this
log message:
(xxxx-xxxxxxxx:kraafira.cpp,628,"InsertRow") Can't allocate xxx bytes

for sample data …
You receive this message if a query is specified that returns many rows of data, causing an out-of-data
condition. The message source, KNATCI, varies depending on the workspace that fails. To resolve this
problem, change the LIMIT and MINIMUM values. You can also change the parameters on the RKLVIN DD
statement or the EXEC PARM field in the JCL. Additional information on this methodology can be found in
the IBM Z NetView Installation: Configuring the NetView Enterprise Management Agent.
Message "KFWITM081E The link target cannot be found" when attempting

to link to the workspace of another product
The Z NetView Enterprise Management Agent and many of the OMEGAMON XE products include
predefined links to workspaces that are provided by other products. The KFWITM081E message is
displayed whenever you try to link to a workspace that does not exist. This message is displayed if the
target workspace for the product is installed but the monitoring agent responsible for retrieving data for
the target workspace is not running.
OMEGAMON product workspaces are installed using the IBM OMEGAMON Data Files for z/OS DVD. When
the workspaces are installed, all predefined links to the workspaces become enabled, meaning that links
to the target workspaces are included in the link list when an operator right-clicks on a link icon.
If you installed the workspaces for products not installed in your environment, links to these products are
valid destinations for dynamic cross-product links. To prevent the inclusion of misleading links, install
only the help files, workspaces, and situations for products that you have installed.
Note: It is not likely that all OMEGAMON XE monitoring agents are running on all z/OS systems being
monitored. In such cases, the KFWITM081E message does not necessarily indicate a problem. For
example, if you are monitoring two z/OS systems and only one of the z/OS systems is running DB2, you
most likely have the OMEGAMON for Networks monitoring agent running on both systems but the
OMEGAMON XE for DB2 monitoring agent is running only on the system where DB2 is installed. Because
you are running both OMEGAMON products, you install help files, workspaces, and situations for both
products, which enables the links to both products. As a result, if you try to perform a cross-product link
to the OMEGAMON XE for DB2 workspace on the system where the OMEGAMON XE for DB2 monitoring
agent is not running, the KFWITM081E message results.

No NetView agent workspaces available
If no NetView workspaces are available in the navigation tree under the node representing your Z NetView
domain, verify that the Tivoli Enterprise Portal Server support for the NetView agent was successfully
configured.
Workspace names displayed in navigation tree are unreadable

If the NetView agent workspaces in the navigation tree under the node representing your NetView domain
are displayed as an ID (as for example, Kna:KNA2007781612271146, verify that the Tivoli Enterprise
Portal support for the NetView agent is successfully configured. When Tivoli Enterprise Portal support is
configured, the kna_resources.jar file is added to the CLASSPATH statement in the cnp.bat file (in a
Windows environment) or the cnp.sh (in a Linux or AIX environment). The kna_resources.jar file
contains all of the text for the NetView agent workspaces.
NACMD fails with BNH805I during initialization

NACMD fails with BNH805I during initialization with the following reasons:
• PPI Session Ending
• PPI Registration Failure
• NACMD already active
Verify the following items:
• Verify that the NetView agent is started.
• Verify that the IBM Z NetView subsystem interface (SSI) is started and running with the program-to-
program interface (PPI) enabled.
• Verify that the NACMD command DESTPPI keyword specifies the PPI receiver name of the NetView
agent. See the RECEIVER-ID section in the IBM Z NetView Application Programmer's Guide for
information about the accepted values of the receiver name. The receiver name must match the PPI
Receiver value defined on the Specify Configuration Parameters panel. To check the values used by the
NetView agent, you can do any of the following actions:
– Run the NVEMACMD PPIINFO modify command.
– Verify that the KNA_PPIRCV value in &rhilev.&rte.RKANPARU(KNAENV) matches the DESTPPI
value being used by NetView program.
– Use the IBM Z NetView DISPPI command to find the status of the PPI receiver.
• Issue the NACTL LISTCONN command to ensure that no other IBM Z NetView task is currently running
NACMD.
• Verify that the TEMA tower is enabled in the CNMSTYLE member.
• Turn on PPI trace by using the IBM Z NetView TRACEPPI command. For detailed command information,
see the IBM Z NetView Command Reference Volume 2 (O-Z) or the online help.
No commands available from the Take Action window

If no take action commands are available under the <Select Action> pull-down list in the Take Action
window, add application support for the NetView agent (kna.sql file) to the Tivoli Enterprise Monitoring
Server and recycle the monitoring server.
To add application support to the monitoring server running in a non-z/OS environment, use the NetView
agent data files DVD. For information about adding application support to a monitoring server running in a
z/OS environment, refer to IBM Z NetView Installation: Configuring the NetView Enterprise Management
Agent.
Note: Take action commands that are used with the GDPS Continuous Availability solution are only
available from workspaces defined to the Active/Active Sites subnode in the Tivoli Enterprise Portal
navigator. These commands are not accessible from workspaces defined to the NetView subnode in the
portal navigator. Similarly, the take action commands that are available from workspaces defined to the
NetView subnode are not available from workspaces defined to the Active/Active Sites subnode.
No NetView agent situations available

If NetView agent situations are not available from the Situation Editor or the navigation tree, add
application support for the NetView agent (kna.sql file) to the Tivoli Enterprise Monitoring Server and
recycle the monitoring server.
To add application support to a monitoring server running in a non-z/OS environment, use the NetView
agent data files DVD. For information about adding application support to a monitoring server running in a
z/OS environment, refer to IBM Z NetView Installation: Configuring the NetView Enterprise Management
Agent.
Note:
1. In the Situation Editor tree, NetView situations are only displayed under the NetView leaf.
2. In the Situation Editor tree, GDPS Continuous Availability solution situations are displayed under the
Active/Active Sites leaf.
Incorrect results when using the icons in the NetView Command Response
Summary view to find or sort data
Find and sort capabilities are available for the data shown in the NetView Command Response Summary
view. The default view-level page size for this view is 100 rows. Find and Sort is limited to the data
displayed on the current page. For example, if you are viewing page 6 of 10 pages, the Sort or Find that
you issue spans only the 100 rows on page 6. If you must Find or Sort more than 100 rows, you can right-
click on the view, select Properties, and change the View-level Page Size to “Return all rows” or else you
can increase the “Number of rows to return” per page.
Cross-Product links missing from link list

Cross-product workspace links are displayed in the link list if the product workspace you are linking to is
installed and your Tivoli Enterprise Portal user ID is authorized to access the target product.
If a cross-product link is missing from the link list, contact your system administrator to verify these
items:
• Verify that your user ID is authorized to access the target product.
• Verify that the target workspaces on the product are installed. OMEGAMON product help files,
workspaces, and situations are installed using the IBM OMEGAMON Data Files for z/OS DVD.
Problems with cross-product linking when linking to an OMEGAMON

workspace
If you are migrating from OMEGAMON XE V3.1 products to OMEGAMON XE V4.1 or V4.2 products, you
might have a combination of V3.1, V4.1, and V4.2 monitoring agents installed in your environment.
For example, during a migration period, you might have a mixture of OMEGAMON XE V3.1, V4.1, and V4.2
monitoring agents running in your enterprise. In this migration scenario, using links from a Z NetView

workspace to an OMEGAMON XE V3.1 workspace is successful if the target workspace exists in the V3.1
product. If the target workspace does not exist, you receive a KFWITM081E message.
If the V4.1 or V4.2 of the target workspace is modified (for example, to accept link parameters to limit the
data displayed) you might notice different behavior when you migrate the target product from V3.1 to
V4.1 or V4.2. For example, the V3.1 of the DB2 thread ID workspace does not filter the data. As a result, if
you link to the V3.1 of the DB2 thread ID workspace, all threads are displayed. This same workspace was
modified in V4.1 to accept link parameters to display data for a specific thread ID. When you update the
OMEGAMON XE for DB2 product to V4.1 or V4.2, the data is now filtered to display data for a specific
thread ID.
Security problems
If you encounter problems with take action security for the z/OS product that uses the Tivoli Management
Services infrastructure, first ensure that you have configured the NetView agent or the Tivoli Enterprise
Monitoring Server to support this function. For additional information about the take action security, see
the IBM Z NetView Installation: Configuring the NetView Enterprise Management Agent.
Review these logs for error messages:
• RKLVLOG files for the Tivoli Enterprise Monitoring Server and the NetView agent
• NetView log
If you see one of the following symptoms, the NetView CNMLINK data set was not concatenated as part
of the Tivoli enterprise management server or NetView agent RKANMODL DD statement in the startup
procedure:
• RC=17 in the Action Status window after a command is issued
• The following message in RKLVLOG: NetView interface module unavailable: CNMCNETV
If you see any of the following symptoms, the NetView APSERV command is not running:
• This message in RKLVLOG: NetView PPI send buffer rejected: 26
• RC=9 in the Action Status window after a take action command is issued
• Message KRAIRA002 in RKLVLOG, as in this example:
KRAIRA002, Executed <D A,L> with status 9, Producer(Automation Command)
In RKLVLOG, if you see the NetView PPI send buffer rejected: 24 message, the Z NetView
subsystem interface is not active.
NetView agent workspaces have no column headings for the table views
When no column headings are in the table views for NetView agent workspaces, the Tivoli Enterprise
Monitoring Services is missing data for the agent. This could occur in an environment where a z/OS Tivoli
Enterprise Monitoring Services is already running.
Copy the KNADOC, KNAATR, and KNACAT files from the &rhilev.&rte.RKANDATV data set to the
equivalent data set where the column headings are in the table views for NetView agent workspaces.
Recycle the Tivoli Enterprise Monitoring Services to pick up the changes.
Cannot start the NetView agent

If you cannot start the NetView agent, verify that you specified the configuration parameters correctly:
• Ensure that you specified the correct NetView CNMLINK data set name on the Specify Configuration
Parameters panel in the Configuration Tool.
• Verify that the CNMLINK data set is APF-authorized.
• Ensure that you performed the Load step using the Configuration Tool for the NetView agent.
For additional information, refer to IBM Z NetView Installation: Configuring the NetView Enterprise
Management Agent.
Missing NetView data when hub Tivoli Enterprise Monitoring Server is active
on both controllers
This scenario is applicable when running the GDPS Continuous Availability solution and the hub Tivoli
Enterprise Monitoring Server (monitoring server) is running on the controller systems. If the monitoring
server is active on both controllers, then data in the Tivoli Enterprise Portal (portal) could show data for
only one NetView domain. This scenario is based on the monitoring server and Z NetView Enterprise
Management Agent (NetView agent) being configured as documented in IBM Z NetView for Continuous
Availability Configuring and Using the GDPS Continuous Availability Solution.
This is the sequence of events that can cause this problem:
1. Hub monitoring server and NetView agent are active on the primary controller.
2. An ACTVCTL TAKEOVER ENABLE=(NVAGT,TEMS) command is issued.
3. A value of Yes is specified on the ACTACT.BKTEMS.Enable statement in the CNMSTLIF CNMSTYLE
member. The user is prompted to reply to the AQN016A message.
4. The user replies Yes before the hub monitoring server is stopped on the primary controller, and the
hub monitoring server is started on the backup controller.
5. The NetView agent is started on the backup controller, and connects to the hub monitoring server
running on the backup controller.
6. Data in the portal only shows information for the NetView domain running on the primary controller.
To resolve the problem, these are the steps that you should follow:
1. Stop the monitoring server on the primary controller. The Tivoli Enterprise Portal Server (portal server)
connectivity to the hub monitoring server now moves to the monitoring server on the backup
controller.
2. Recycle the portal server to synchronize event and situation data with the new hub monitoring server.

Chapter 32. Diagnostic tools for the Z NetView
Enterprise Management Agent
These are some diagnostic tools for the Z NetView Enterprise Management Agent (NetView agent). These
topics are covered:
• NetView online message and command help, described in “Using NetView online message and
command help for the NetView agent” on page 519
• NetView CNMTRACE command, described in “Using the CNMTRACE function for NetView host
components of the NetView agent function” on page 519
• The NACTL command, described in “Using the NACTL command to troubleshoot the NetView agent” on
page 521.
• The DISPPI command, described in “Using the DISPPI command to troubleshoot a PPI connection
between NetView and the NetView agent” on page 521.
• General problem determination for the NetView agent, described in “Problem determination for a
NetView agent” on page 521.
Using NetView online message and command help for the NetView agent
• When NACMD terminates, it issues message BNH805I message accompanied by message DWO050I.
Message DWO050I should not be issued on normal termination. Use the online Help facility to find
more information about the failure.
• When data collection stops due to any abnormal cause, BNH881I messages are logged to the NetView
log. Message DWO050I can provide additional details.
Using the CNMTRACE function for NetView host components of the NetView
agent function
The CNMTRACE function provides tracing for the NetView host components of the NetView agent. Tracing
can be started or ended by using common global variables. There are two versions of the global variables:
CNMTRACE.NACMD
This is the global trace control.
CNMTRACE.NACMD.opid
This is the task-specific trace control. The opid is the operator ID of the task that is running a NetView
agent REXX executable file. If the task-specific common global variable has a valid value, it takes
precedence over the global trace control.
Note: The NACMD command is the function designated for all REXX files associated with the NetView
agent. The following values are valid for the common global variables:
YES or ON
This value shows the entry and exit, the commands to be issued, and the command responses, if
any. This includes any commands issued indirectly.
NO or OFF
This value specifies that no tracing is to be performed.
DEBUG
This value shows tracing provided by the YES or ON value and more detailed data and flows.

For the task-specific variable, if the value is not one of these values (YES, ON, NO, OFF, DEBUG) or
null, then it defaults to the setting of the global variable. For the global variable, any value other than
YES, ON, or DEBUG is treated as NO (no tracing).
This is an example of running global CNMTRACE. Each message issued for the trace follows this
convention:
AUTODC1 14:21:08 | CNMTRACE NACMD CNME8204 ENTRY, PARMS: 1

AUTONALC 14:21:29 | CNMTRACE NACMD CNME8202 ENTRY, PARMS: CNMEMARX 90
14:21:29 C BNH806I TAKE ACTION COMMAND 'MAPCL' RECEIVED FOR
TASK SYSADMIN
14:21:29 | CNMTRACE NACMD CNME8202 Command: AUTOTASK
OPID=SYSADMIN
14:21:29 | CNMTRACE NACMD CNME8202 Message: DSI041I SYSADMIN
ALREADY ACTIVE OR IN PROCESS OF BECOMING ACTIVE
14:21:29 | mapcl
14:21:29 | CNMTRACE NACMD CNME8202 Data (hex):
61E2E8E2C1C4D4C9D57A40C4C5C7D9C1D5E3409481978393
14:21:29 | CNMTRACE NACMD CNME8202 Message:
CNM429I MAPCL DISPLAY
14:21:29 | CNMTRACE NACMD CNME8202 Message: NAME USAGE RECORDS BYTES
DATE TIME DP R/C
14:21:29 | CNMTRACE NACMD CNME8202 Message: -------- -------- --------
--------
-------- -------- -- ---
14:21:29 | CNMTRACE NACMD CNME8202 Message: CNMETACI 0 120 9512
04/23/19 14:15:37 R
14:21:29 | CNMTRACE NACMD CNME8202 Message: -------- -------- --------
--------
-------- -------- -- ---
14:21:29 | CNMTRACE NACMD CNME8202 Message: 1 0 120 9512
--TOTALS--
14:21:29 | CNM429I MAPCL DISPLAY
4C8481A3816EF0F461F2F361F0F740F1F47AF2F17AF2F907C3
D5D4F4F2F9C940D4C1D7C3D340C4C9E2D7D3C1E807F0F0F0F1
07F0F0F0F107E2E8E2C1C4D4C9D5074C618481A3816E
14:21:29 | NAME USAGE RECORDS BYTES DATE TIME DP R/C
4C8481A3816EF0F461F2F361F0F740F1F47AF2F17AF2F907D5
C1D4C5404040404040E4E2C1C7C54040404040D9C5C3D6D9C4
E2404040C2E8E3C5E24040404040C4C1E3C5404040404040E3
C9D4C54040
40404040C4D74040D961C307F0F0F0F107F0F0F0F107E2E8E2
C1C4D4C9D5074C618481A3816E
14:21:29 | -------- -------- -------- -------- -------- -------- -- ---
4C8481A3816EF0F461F2F361F0F740F1F47AF2F17AF2F90760
60606060606060404060606060606060604040606060606060
60604040606060606060606040406060606060606060404060
6060606060
606040406060404060606007F0F0F0F107F0F0F0F107E2E8E2
C1C4D4C9D5074C618481A3816E
N E T V I E W PRINT LOG/TRACE UTILITY 04/23/19 105 AUTONALC
04/23/19 NTV77 14:21:29 | CNMETACI 0 120 9512 04/23/19 14:15:37 R

4C8481A3816EF0F461F2F361F0F740F1F47AF2F17AF2F907C3
D5D4C5E3C1C3C9404040404040404040F040404040404040F1
F2F0404040404040F9F5F1F24040F0F461F2F361F0F74040F1
F47AF1F57A
F3F7404040404040D907F0F0F0F107F0F0F0F107E2E8E2C1C4
D4C9D5074C618481A3816E
14:21:29 | -------- -------- -------- -------- -------- -------- -- ---
4C8481A3816EF0F461F2F361F0F740F1F47AF2F17AF2F90760
60606060606060404060606060606060604040606060606060
60604040606060606060606040406060606060606060404060
6060606060
606040406060404060606007F0F0F0F107F0F0F0F107E2E8E2
C1C4D4C9D5074C618481A3816E
14:21:29 | 1 0 120 9512 --TOTALS--
4C8481A3816EF0F461F2F361F0F740F1F47AF2F17AF2F907F1

40404040404040404040404040404040F040404040404040F1
F2F0404040404040F9F5F1F240406060E3D6E3C1D3E2606007
F0F0F0F007
F0F0F0F107E2E8E2C1C4D4C9D5074C618481A3816E
14:21:29 C BNH807I TAKE ACTION RESPONSE SENT FOR COMMAND'MAPCL' TASK SYSADMIN
14:21:29 | CNMTRACE NACMD CNME8202 EXIT, RETURN CODE: 0
NETOP1 14:21:41 * BROWSE NETLOGA
14:22:38 | CNMTRACE NACMD CNME8204 ENTRY, PARMS: 1
Using the NACTL command to troubleshoot the NetView agent

Issue the NetView NACTL LISTCONN command to check the status of the connection.
Note: Use the online Help facility to find more information about the NACTL command
Using the DISPPI command to troubleshoot a PPI connection between

NetView and the NetView agent
Issue the DISPPI command to display the status of the NetView Program-to-Program Interface (PPI).
Problem determination for a NetView agent

Service information about the distributed components of Tivoli Management Services and service tasks
common to both distributed and z/OS environments is documented in IBM Tivoli Monitoring: Problem
Determination Guide. That book also explains diagnostic tools and setting up tracing for the various
distributed components of Tivoli Management Services.
This section provides an overview of service information that you must collect about the NetView agent
and instructions for setting traces and collecting logs for your own use and to forward to IBM Software
Support. These topics are covered:
• “Problem determination flow for the NetView agent” on page 521
• “Determining if the problem was caused by the NetView agent” on page 522
• “Understanding and using RAS1 logs” on page 533
• “Capturing z/OS logs to send to software support” on page 534
Problem determination flow for the NetView agent

When you encounter a problem with any component, the primary troubleshooting feature is logging.
Logging refers to the writing of text messages and trace data generated by the software to an output
destination, such as a console screen or a file. A NetView agent does not display messages at the Tivoli
Enterprise Portal. Instead, messages are sent to more typical z/OS output locations, such as sysout data
sets or spool files or, more rarely, to the z/OS system console. Logging is enabled on all monitoring agents
by default.
Tracing, however, creates a record of the processing of a computer program or transaction. Trace logs
capture information about the operating environment when component software fails to operate as
intended to help you diagnose problems. The principal log type is the reliability, availability, and
serviceability (RAS1) trace log. When the Tivoli Management Services z/OS components are initialized,
RAS1 service initialization is one of the first processes started. RAS logs are in the English language only.
The RAS trace log mechanism is available on the Tivoli Enterprise Monitoring Server, the Tivoli Enterprise
Portal Server, and the monitoring agents. Most logs are located in a logs subdirectory on the host
computer.
Chapter 32. Diagnostic tools for the Z NetView Enterprise Management Agent 521
By default, the NetView agent has minimal tracing enabled. The setting RAS1=ERROR means that only
error messages are captured. When you report a problem, IBM Software Support might ask you to enable
a more in-depth and detailed form of tracing.
IBM Software Support uses the information captured by trace logging to trace a problem to its source or
to determine why an error occurred. The default configuration for trace logging, such as the level of trace
logging, depends on the source of the trace logging. Trace logging is always enabled.
Attention: There is CPU and I/O overhead associated with detailed RAS1 tracing that might
degrade performance of the monitoring agent. You must restore RAS1 tracing to the minimal
KBB_RAS1=ERROR after problem diagnosis is completed.
Determining if the problem was caused by the NetView agent

One of the most difficult troubleshooting issues in a client-server environment such as Tivoli Management
Services is determining which component is the origin of the problem. In most cases, the problem might
seem to be a Tivoli Enterprise Portal client problem because this is what you can see. But this can be
misleading because the Tivoli Enterprise Portal client is a display-only client: the client can display data
only if it receives data from the Tivoli Enterprise Monitoring Server.
In any problem scenario, all documentation should be gathered at the time of the error. What appears to
be a client problem could very well be a server problem, especially in the scenario where data is not
showing up at the client. Below are guidelines for collecting the correct documentation for any problems
reported.
As you collect logs, create an exact description of the problem. For reproducible problems, document the
exact navigation path that produced the error. Screen prints might also help in the problem
determination.
In your problem report, try to use the correct terminology when describing the problem (for example,
workspaces, views, navigators, events, and links). Consistent use of the terminology will help IBM
Software Support to understand the problem quickly.
The sections that follow discuss types of problems that you might see and how to capture information
needed to diagnose those problems.
Reproducible problems reported as Tivoli Enterprise Portal client problems

If the problem is reproducible and is reported as a Tivoli Enterprise Portal client problem, send the client
log. The location of the log depends on the client type and operating system the client is running on. You
might be asked to set a trace in the client and then collect the log. This is a very likely scenario in the case
where a problem is reproducible.
• If the Tivoli Enterprise Portal desktop client is being used, collect the logs shown in Table 172 on page
523:

Table 172. Log locations for Tivoli Enterprise Portal desktop client
Com-
ponent Windows UNIX-based systems
Tivoli – install_dir\CNP\kcjerror.log install_dir/logs/

Enterprise – install_dir\CNP\kcjras1 hostname_PC_timestamp.log
Portal
When launched via Java Web Start: where:
desktop
client %USERPROFILE%\Application install_dir
Data\ IBM\Java|Deployment\log Specifies the directory where Tivoli
\javawsnnnnn.trace Enterprise Portal Server was installed.
where nnnnn is a unique, randomly hostname

generated numeric suffix to support Specifies the name of the system hosting
generational logs; that is, the last the product
generated log is not overlaid by the most PC
current execution of Tivoli Enterprise Specifies the product code, cq for the
Portal using Java Web Start. This is Tivoli Enterprise Portal Server.
different from the Tivoli Enterprise Portal timestamp
Browser client, which has a fixed name A decimal representation of the time at
and is overlaid with each execution cycle. which the process was started.
When launched via Jave Web Start:
%{user.home}/.java/
deploymnet/log/
javawsnnnnn.trace
where nnnnn is a unique, randomly
generated numeric suffix to support
generational logs; that is, the last generated
log is not overlaid by the most current
execution of Tivoli Enterprise Portal using
Java Web Start. This is different from the
Tivoli Enterprise Portal Browser client, which
has a fixed name and is overlaid with each
execution cycle.
• If the Tivoli Enterprise Portal browser client is being used, then collect this log:
C:\Documents and Settings\Administrator\Application Data\

IBM\Java\Deployment\log\plugin1.4.2.trace
The plugin1.4.2.trace file contains the RAS1 tracing for the Tivoli Enterprise Portal browser client and
any Java exceptions. The Tivoli Enterprise Portal client logs contain environmental information, such as
the version and build level of the Tivoli Enterprise Portal client. The log also contains the host and port
of the Tivoli Enterprise Monitoring Server that the client is connecting to.
• The Tivoli Enterprise Portal Server log might also be useful. It can be found in one of the locations in
Table 173 on page 524:
Table 173. Log locations for the Tivoli Enterprise Portal Server
Com-
ponent Windows UNIX-based
Tivoli install_dir\logs install_dir/logs/ hostname_PC_timestamp.log

Enterprise
Portal where:
Server install_dir
Specifies the directory where Tivoli Enterprise Monitoring
Server was installed.
hostname
Specifies the name of the system hosting the product
PC
Specifies the product code, cq for the Tivoli Enterprise
Portal Server. Refer to the product code appendix of IBM
Tivoli Monitoring: Problem Determination Guide for a
complete list of product codes for distributed
components.
timestamp
A decimal representation of the time at which the process
was started.
Also look for log information in this file:
kfwservices.exe
In addition, collect the Tivoli Enterprise Monitoring Server log. While this problem might be reported as a
Tivoli Enterprise Portal client problem, the client might be having difficulties because of a server failure.
• For the location of logs for a Tivoli Enterprise Monitoring Server on z/OS, see “Problems reported as
Tivoli Enterprise Portal Server problems” on page 525.
• Table 174 on page 525 shows the location of logs for a Tivoli Enterprise Monitoring Server logs on
distributed platforms:

Table 174. Log locations for Tivoli Enterprise Monitoring Server on distributed platforms
Com-
ponent Windows-based UNIX-based
Tivoli \install_dir\logs\ install_dir/logs/

Enterprise hostname_PC_HEXtimestampnn.log hostname_PC_timestamp.log
Monitoring
where: where:
Server
install_dir install_dir
Specifies the directory where Tivoli Specifies the directory where Tivoli
Enterprise Monitoring Server was Enterprise Monitoring Server was
installed. installed.
hostname hostname
Specifies the name of the system Specifies the name of the system
hosting the product hosting the product
PC PC
Specifies the product code, ms for the Specifies the product code, ms for the
Tivoli Enterprise Monitoring Server. Tivoli Enterprise Monitoring Server.
Refer to the product code appendix of Refer to the product code appendix of
IBM Tivoli Monitoring: Problem IBM Tivoli Monitoring: Problem
Determination Guide for a complete list Determination Guide for a complete list
of product codes for distributed of product codes for distributed
components. components.
HEXtimestamp timestamp
A hexadecimal representation of the A decimal representation of the time at
time at which the process was started which the process was started.
nn
Represents the circular sequence in
which logs are rotated. Ranges from
1-5, by default, though the first is
always retained, since it includes
configuration parameters.
Unreproducible problems reported as Tivoli Enterprise Portal client problems

If the problem is not reproducible and is reported as a Tivoli Enterprise Portal client problem, collect both
the client and server logs. The logs might be the only indication of the real problem. Always try to get the
logs at the time of the error. The Tivoli Enterprise Portal client has dynamic logging. Restarting the
processes before collecting the logs rewrites the log and any previous error messages might be lost.
Problems reported as Tivoli Enterprise Portal Server problems

If the problem is reported as a Tivoli Enterprise Portal Server problem, collect the server logs. The Tivoli
Enterprise Portal Server consists of two processes, so there is a reliability, availability, and serviceability
(RAS) log (referred to in this document as a RAS1 log) for each process. If this is a reproducible problem,
you might be asked to set unit traces for the Tivoli Enterprise Portal Server and then asked to gather the
logs. The location for Tivoli Enterprise Portal Server logs is found in “Reproducible problems reported as
Tivoli Enterprise Portal client problems” on page 522. Both logs contain the Tivoli RAS1 trace information.
Also, collect the client log at the time of the error if it is available.
Problems affecting the NetView agent

After you have ruled out problems with Tivoli Management Services components and the functionality for
which you installed the NetView agent is not available, then treat the problem as a NetView agent
problem. As noted earlier, the fact that problems appear in the Tivoli Enterprise Portal does not mean that
this component is the source of the failure.
Log files and trace information are provided in a common fashion across z/OS monitoring agents,
including the NetView agent, and the z/OS components of the Tivoli Management Services. Table 175 on
page 526 explains the location of log and trace files for the NetView agent and Tivoli Management
Services z/OS components. See Chapter 31, “Troubleshooting and initial diagnosis for the Z NetView
Enterprise Management Agent,” on page 507 for typical problems with the NetView agent.
Table 175. Locations of log and trace information for z/OS components
Header Header
The NetView agent RKLVLOG for the monitoring agent started task is the single most helpful
piece of service information for the NetView agent. The RKLVLOG (R =
runtime, KLV = the prefix associated with IBM Tivoli Enterprise Monitoring
Services or ITMS:Engine) is the sysout data set or spool file that contains
log and trace messages. Instructions on how to save the contents of this
log to a data set are provided under “Capturing z/OS logs to send to
software support” on page 534.
These additional zSeries log files (if available) are also useful:
• The RKLVSNAP sysout data set or spool file contains formatted dump
output.
• The RKPDLOG sysout data set or spool file contains the information and
error messages related to the handling of persistent data stores.
Tivoli Enterprise Monitoring Server Because the Tivoli Enterprise Monitoring Server on z/OS runs under
on z/OS TMS:Engine just as an OMEGAMON XE monitoring agent on z/OS does, all
logging under TMS:Engine is handled the same way; that is, log and trace
data are written to RKLVLOGs and RKPDLOGs.
ETE ETE is a base component and does not have its own RKLVLOG. This
component writes messages to the IBM System Display and Search
Facility (SDSF) Job Log. The User Response section of various ETE
messages requests that you collect systems information and memory
dumps before contacting IBM Software Support. How to collect this
information for ETE is documented in the IBM OMEGAMON and Tivoli
Management Services on z/OS shared documentation reference.
IBM Tivoli Management Services: TMS:Engine is a collection of basic operating system and communication
Engine (TMS:Engine) service routines built specifically for z/OS. All address spaces used by the
OMEGAMON XE monitoring agent on z/OS load and use the services of
TMS:Engine.
Successful initialization of TMS:Engine is noted by this message:
KLVIN408 IBM OMEGAMON PLATFORM ENGINE VERSION 400 READY
For troubleshooting information about TMS: Engine problems, refer to the

z/OS initialization section of IBM Tivoli Monitoring: Troubleshooting.
Explanations for messages generated by TMS:Engine can be found in IBM
Tivoli Monitoring: Messages.
TMS:Engine writes messages to the same RKLVLOG as the product it is
running. If you search the RKLVLOG for an OMEGAMON XE monitoring
agent on z/OS, product-specific messages start with the product code (for
example, KN3 for OMEGAMON XE for Mainframe Networks), but messages
for the TMS:Engine start with the component prefix KLV.

Table 175. Locations of log and trace information for z/OS components (continued)
Header Header
Persistent data store The RKPDLOG sysout data set or spool file contains the information and
error messages related to the handling of persistent data stores. To dump
this log, follow the procedures described for RKLVLOG in the sections that
follow.
For locations of log files for all the components of Tivoli Management Services and information about
enabling tracing for distributed components, refer to IBM Tivoli Monitoring: Problem Determination Guide.
NetView agent communication layer messages and tracing

This section covers serviceability for the NetView agent communication layer. The NetView agent
communication layer is the code that:
• Initializes and defines the PPI receiver for the NetView agent itself. This PPI receiver is defined in the
Configuration Tool.
• Manages the NACMD processing on behalf of the NetView agent.
RAS Messages
Messages are written to the console for some problems that occur in the NetView agent communication
layer. These messages are also written to the RKLVLOG. The messages are DWO746I, CNM217I, and
CNM273I. Additionally, DWO050E messages might be written to the log.
RAS Trace
The NVEMACMD TRACE command enables and disables the NetView agent communication layer trace.
There are three different trace types:
BFR
The BFR trace entries can have one or two lines. The first line always starts with BUFFER. Depending
on the return code, the buffer itself is displayed on the second line.
BUFFER action module Return Code: retcode

buffer
BUFFER SEND CNMIRAPP Return Code: 00000000
<*DONE*>
where
• action is SEND or RECEIVE
• module is the module doing the send or receive
• retcode is the return code
• buffer is the actual send or receive buffer
MOD
ENTRY
Defines module or function entry.
Example of module entry:

ENTRY module
ENTRY CNMIRAPP
Example of function entry:

ENTRY module :function
ENTRY CNMIRAPP:sndBfr
where
• module is the module name that has been entered
• function is the function within the module that has been entered
EXIT
Defines module or function exit and shows the exit return code
Example of module exit:

EXIT module Return Code: retcode
EXIT CNMIRAPP Return Code: 00000000
Example of function exit:

EXIT module :function Return Code: retcode
EXIT CNMIRAPP:sndBfr Return Code: 00000000
where
• module is the module name that has been entered
• function is the function within the module that has been entered
• retcode is the module or function exit return code
DEBUG
Provides internal diagnostics for IBM Software Support
DEBUG text
DEBUG The ICB Address is x'1894B6A8'
• text is a string containing diagnostic information

To enable the NetView agent communication layer trace during NetView agent initialization, code
KNA_COMMTRC=types in RKANPARU member KNAENV. Valid types are BFR, MOD, DEBUG, or ALL. An
example of this specification is KNA_COMMTRC=ALL
Using the KDC_DEBUG environment variable

The KDC_DEBUG environment variable can be used during TCP/IP service initialization to diagnose
connectivity problems with application layers such as telnet and FTP, and with the Tivoli Monitoring
Server, Tivoli Enterprise Portal Server, and the Tivoli Enterprise monitoring agents.
To obtain the level or tracing required to have these TCP/IP initialization messages echoed to the log, the
string KDC_DEBUG=Y must be added to either the KDSENV member or the KNAENV member of
RKANPARU. Place the KDC_DEBUG environment variable statement immediately after the
KDC_FAMILIES environment variable. You cannot dynamically alter KDC_DEBUG tracing.
Possible values for KDC_DEBUG are:
Y
When KDC_DEBUG is set to Y, the data flow between the monitoring agent and Tivoli Management
Services components (such as Tivoli Enterprise Monitoring Server and Tivoli Enterprise Portal Server)
during TCP/IP initialization is recorded, including data packages sent and received. If KDC_DEBUG=Y
is active in the environment during initialization of TCP/IP services for this address space, you can
confirm successful initialization of TCP/IP by looking for one of the following messages in RKLVLOG. If
KDC_DEBUG is set to Y and none of these messages appear in RKLVLOG, then initialization of the
TCP/IP service failed:
"KDEI1_OpenTransportProvider") Transport opened: socket/ip.tcp
"KDEI1_OpenTransportProvider") Transport opened: socket/ip.pipe
"KDEI1_OpenTransportProvider") Transport opened: socket/ip.udp
N
The data flow between the monitoring agent and Tivoli Management Services components during
TCP/IP initialization is not recorded. This is the default and the recommended setting for normal
operation.
The KDC_DEBUG environment variable controls all DCS communications tracing. Use the KDC_DEBUG
environment variable to track DCS errors or activity between the agent and the Tivoli Enterprise
Monitoring Server.

See the environment variables appendix in IBM Tivoli Monitoring: Troubleshooting for a list of environment
variables associated with other components.
Setting up RAS1 tracing

RAS1 is the component that provides trace and memory dump routines. RAS1 tracing provides runtime
filtering of product messages and is the primary diagnostic tool for the NetView agent. It is provided by
the kbb library service and is set using either the IBM Tivoli Monitoring Service Console interface or some
more direct method of manually modifying the KBB_RAS1 parameter. RAS1 messages are sent to stdout,
so that one of the components in the configurator programs redirects that output to log files.
The NetView agent might not support all of the filters and classes defined in the syntax shown in “RAS
Trace” on page 527.
Again, be aware that RAS1 tracing log files can grow large with the wrong amount of filtering. There is no
log management function or feature, so be careful with the levels of tracing that you specify. You may
want to run error tracing for all components and then any additional levels depending on diagnostic
needs.
Syntax for RAS1 traces

This syntax is used to specify an RAS1 trace in the KppENV file. After you add this command to the
KppENV file, you must stop and restart the address space for it to take effect. After that, it remains in
effect for the life of the address space. To end this RAS1 trace, you must edit the KppENV file again and
reset the trace level and stop and start the address space.
The basic syntax of the RAS1 trace commands for error tracing is as follows:
KBB_RAS1= global_class
(COMP: component_type)
(ENTRY: entry_point) (UNIT: unit_name, class)
Where:
global_class
Indicates the level of tracing that you want to see. This is a global setting that applies to all RAS1
filters within the process. If you set this global class by itself, it is global in scope and the trace cannot
filter on any of the other keywords. Separate combined classes with a space. The following are
possible values. Valid abbreviations are in parentheses.
• ERROR (ER): returns severe error messages only (this is the default for most applications).
• STATE (ST): records the condition or current setting of flags and variables within the process. If
state tracing is enabled, you can see the current state of particular variables or flags as the process
is running.
• FLOW (FL): causes a message to be generated at an entry or exit point of a function.
• DETAIL (DE): produces a detailed, verbose level of tracing.
• INPUT (IN): records data that is created in the execution of a particular API, function, or process.
• ALL: causes all available messages to be recorded, a combination of all the other forms of tracing.
COMP
Is the keyword that indicates this trace will include a component type. The COMP keyword is used to
trace groups of routines related by function (or component). Do not use this parameter unless
requested to do so by IBM Software Support.
component_type
Is the identifier for a component type. If an IBM Software Support representative instructs you to
perform a component trace, you are provided with a code for that component. Do not use this
parameter unless requested to do so by IBM Software Support.
ENTRY
Is the keyword used to narrow a filtering routine to a specific ENTRY POINT. Since multiple entry
points for a single routine are not common, this keyword is not commonly used and should only be
used at the explicit request of an IBM Software Support representative.
entry_point
Is a variable representing the name of the entry point. If you are asked to specify a value for the
ENTRY keyword, an IBM Software Support representative can tell you what value to specify for
entry_point .
UNIT
Is the keyword that indicates this trace includes collecting information using the compilation unit,
fully qualified or partially qualified. A match is performed between the compilation unit dispatched
and the compilation unit specified on the RAS1 statement. A match results in a trace entry.
unit_name
Is a variable representing the name of the compilation unit. This name can be anything that is related
to the object file name or unit compilation name. In most instances, this name defines the component
that is being traced. This value will most likely be the three-character component identifier for the
monitoring agent (for example, kna for the NetView agent).
class
One of the same values specified for Global Class but, because of its position inside the parentheses,
the class is narrowed in scope to apply only to the unit_name specified. The following are possible
values. Valid abbreviations are in parentheses.
• ERROR (ER): returns severe error messages only (this is the default for most applications).
• STATE (ST): records the condition or current setting of flags and variables within the process. If
state tracing is enabled, you can see the current state of particular variables or flags as the process
is running.
• FLOW (FL): causes a message to be generated at an entry or exit point of a function.
• DETAIL (DE): produces a detailed, verbose level of tracing.
• INPUT (IN): records data that is created in the execution of a particular API, function, or process.
• ALL: causes all available messages to be recorded, a combination of all the other forms of tracing.
Note:
1. The default setting for all components is KBB_RAS1=ERROR, meaning that only error tracing is
enabled.
2. You can specify any combination of UNIT, COMP, and ENTRY keywords. None of these keywords are
required. However, the RAS1 value you set with the global class applies to all components.
Some examples of RAS1 trace syntax follow.
Example 1 – Tracing requests to and answers from the Tivoli Enterprise Monitoring Server
To show requests to and answers from the Tivoli Enterprise Monitoring Server, specify this trace:
KBB_RAS1=ERROR (UNIT:KRA ST ERR)
The unit values ST and ERR indicate that you are collecting state and error information for the agent
framework component (KRA).
This type of agent trace is used only if you are trying to debug a specific problem, because it greatly
increases the number of messages generated by agent. With this type of trace, messages include a
detailed memory dump of all rows of agent data that have passed filtering, which includes attribute
names and values, request names, table names, and collection interval. Remember to disable this
resource-intensive form of tracing immediately after you have completed your trace.

Example 2 – Tracing proxy controller and distributed agent issues
From the Tivoli Enterprise Monitoring Server, to trace proxy controller and Tivoli Enterprise Monitoring
Server distributed agent issues, issue this command:
KBB_RAS1=ERROR (COMP:KUX ST ER) (UNIT:KRA ALL) (UNIT:KDS FL)
In this example:
• KUX is a component identifier provided to you by a representative of IBM Software Support so that you
can collect state and error information about this subcomponent.
• KRA is the unit name for the agent framework component. All trace information about this component is
being captured.
• KDS is the Tivoli Enterprise Monitoring Server component and the flow (FL) of entry or exit points
through this component are documented with records written to RKLVLOG.
Setting RAS1 trace levels for the NetView agent

For the NetView agent, the trace level KBB_RAS1=ERROR is set by default. You can change this trace level
a number of ways. Three of those ways are explained in the sections that follow.
Setting trace levels by editing RKANPARU

One of the simplest ways to set trace levels for the NetView agent is to edit the RKANPARU(KppENV)
member.
The text in bold is an example of what an IBM service representative might ask you to add to the KNAENV
member in the RKANPARU data set.
Command ===> Scroll ===> CSR

****** ***************************** Top of Data ******************************
000001 KDE_TRANSPORT=\
000002 SNA.PIPE PORT:135 USE:N\
000003 IP6.PIPE PORT:1918 USE:N\
000004 IP6.UDP PORT:1918 USE:N\
000005 IP.SPIPE PORT:3660 USE:N\
000006 IP6.SPIPE PORT:3660 USE:N\
000007 IP.PIPE PORT:1918 EPHEMERAL:Y\
000008 IP.UDP PORT:1918
000009 KBB_RAS1=ERROR (UNIT:KNATN ALL) (UNIT:KNAIRAFT
ALL)
000010 CT_CMSLIST=\
000011 IP.PIPE:x.xx.xxx.xx;\
000012 IP.UDP:x.xx.xxx.xx;
000013 CTIRA_STANDALONE=N
000014 KNA_PPISND=CNMEMATX
000015 KNA_PPIRCV=CNMEMARX
000016 CTIRA_IP_PORT=0
000017 LANG=en_US.ibm-037
****** **************************** Bottom of Data ******************************
Setting trace levels dynamically using IBM Tivoli Monitoring Service Console
You can also use the IBM Tivoli Monitoring Service Console to set trace levels for the NetView agent, as
well as for a Tivoli Enterprise Monitoring Server on z/OS or a distributed system.
The IBM Tivoli Monitoring Service Console enables you to read logs and turn on traces for remote product
diagnostics and configuration. The IBM Tivoli Monitoring Service Console is uniquely identified by its
service point name. All IBM Tivoli Monitoring Service Consoles for a host are linked and presented on the
IBM Tivoli Monitoring Service Index for that host. Point a browser to the HTTP port 1920 on a specific
host (for example, http://goby:1920) to launch the IBM Tivoli Monitoring Service Index. You can also
launch the service console by connecting via the https protocol and port 3661. You can perform
operations on a specific IBM Tivoli Monitoring process by selecting the IBM Tivoli Monitoring Service
Console associated with a service point name.
The IBM Tivoli Monitoring Service Index has links to service consoles for the components installed on a
workstation. From the Service Index, you can access links to the Agent Service Interface. You can use the
Agent Service Interface to get reports for an installed agent (for example, the Tivoli Enterprise Monitoring
agent or the Tivoli System Monitoring agent). After logging in to the local operating system, you can
choose reports of agent information, private situations, private history, and attribute descriptions and
current values. You can also make a service interface request using provided XML elements.
Starting the IBM Tivoli Monitoring Service Console

Use the following procedure to start the IBM Tivoli Monitoring Service Console.
1. Start an Internet browser.
2. In the Address field, type the URL for the Tivoli Enterprise Portal browser client installed on your web
server. The URL for the Tivoli Monitoring Services web server is
http://hostname:1920
Where hostname specifies the computer where the Tivoli Enterprise Portal Server was installed. If the
IBM Tivoli Monitoring Service Console is not displayed, a system administrator might have blocked
access to it. Refer to the IBM Tivoli Monitoring: Troubleshooting Guide for information about blocking
access to the IBM Tivoli Monitoring Service Console.
3. Click the IBM Tivoli Monitoring Service Console link associated with the desired process (service point
name).
4. When the login window opens, click OK.
In secure environments, you need a valid user ID and password to proceed. Upon successful login, the
IBM Tivoli Monitoring Service Console opens with three areas:
• Header
• Command Results
• Command Field
You can now issue IBM Tivoli Monitoring Service Console commands in the command input area. For a list
of available commands, type a question mark (?) and click Submit.
The IBM Tivoli Monitoring Service Console performs user authentication using the native operating
system security facility. If you use the IBM Tivoli Monitoring Service Console on z/OS systems, your user
ID and password are checked by the z/OS security facility (RACF/SAF). If you use the IBM Tivoli
Monitoring Service Console on Windows systems, then you must pass the Windows workstation user ID
and password prompt. This is the rule except for instances of a null or blank password. The IBM Tivoli
Monitoring Service Console never accepts a null or blank password.
A password is always required to access the service console. Blank passwords, even if correct, cannot
access the service console. Even if a user ID is allowed to log in to the operating system without a
password, access to the service console is denied. To gain access to the service console, create a
password for the user ID that is being used to log in to the service console.
The IBM Tivoli Monitoring Service Console supports the following commands, most of which are useful for
problem determination:
bss1
Manages BSS1 (Basic System Services). This command is paired with one of the following
subcommands:
• dumpcvt: Display KBBSS_cvt_t
• listenv: Display the resident CT variables
• getenv: Display environment variables
• setenv: Assign environment variable
• info: Display BSS1_Info() data
• config: Manage configuration variables

config
Used to modify the settings of the ITMS:Engine debug environment variables: RES1_DEBUG,
KDH_DEBUG, KDC_DEBUG, and KDE_DEBUG . For example, the following config command can be
used to alter the setting of KDC_DEBUG:
CONFIG KDC_DEBUG=Y
The setting of KDC_DEBUG can be restored to its original value using the following:
CONFIG KDC_DEBUG=N
http
Displays HTTP server management
kdcstat
Displays the status of KDC (RPC Service) component
ras1
Manage RAS1 (Reliability, Availability, and Serviceability). This command is paired with one of the
following subcommands:
• dumpcvt: Display KBBRA_cvt_t
• log: Display RAS1 log capture buffer
• list: List the RAS1 filters
• interpret: Interpret the control string
• units: Display the registered compilation units
The RAS1 (with no operands) command can be used to view the current ITMS:Engine log capture
buffer. When operands are supplied with the RAS1 command, the operands are assumed to be
keywords applicable to the KBB_RAS1 environment variable.
The RAS1 command is especially useful for dynamically enabling and disabling RAS1 traces. Many
times you cannot recycle the agent in order to start tracing. The RAS1 command can be used to alter
KBB_RAS1 tracing parms dynamically without the need to recycle the product. For example, to enable
the standard IRA traces, the following Service Console command can be used:
RAS1 'error (unit:kpx all) (unit:kra all)'
The (single) quoted string is passed to RAS1 as operands of the KBB_RAS1 environment variable.
After this trace is captured, the IRA trace can be disabled with the following Service Console
command: RAS1 'error (unit:kpx error) (unit:kra error)'. This has the effect of restoring the RAS1
logging level from ALL to ERROR for units kpx and kra.
res1
Displays the status of RES1 Logical Resource Manager.
Understanding and using RAS1 logs

When you open a z/OS log such as RKLVLOG, you find a mix of status lines and numbered product
messages.
Most messages with IDs are documented in the problem determination guides for each monitoring agent.
You can also determine the meaning of a message by entering the message number into an Internet
search engine. The information that follows help you interpret the messages and status lines in a z/OS
log.
Format of messages in a RAS1 log

A RAS1 log for a monitoring agent on z/OS includes the following information:
• Environmental information
– Operating system and processor data. This information is prefaced with the following string:
PPPxxmmm
Where:
PPP
Is the component prefix.
xx
Is the component code (for example, NS Node Status).
mmm
Is the module name (for example mdg/mgr for Model/Manager).
– Initial command line settings
• Component summary, including the following:
– The name of the module
– Information about where the library was loaded from
– The date and time the module was compiled
– The version (if this detail was specified)
• Formatted output, including entry and exit points and text strings. Entry and exit points show flow into
and out of a given function. The exit shows the return code, if applicable. The text depends on the kind
of trace specified. Here is an example:
(00D41 F9C-1{99%}:KV4MAIN.CPP,953,"MainWnd::MainWnd") Entry

(00D41 FD3-1{99%}:KV4MAIN.CPP,959,"MainWnd::MainWnd") Exit
Time,Thread,{%stack avail},pgm_name,Line#,function,text
As noted earlier, not all functions are RAS1 enabled, and trace level might exclude some paths. Be
careful with granularity.
Capturing z/OS logs to send to software support

To save a log to a file rather than viewing it online, you must know how to do the following:
• “Saving the contents of a z/OS log such as RKLVLOG” on page 534
• “Ending one RKLVLOG and starting another” on page 535
Saving the contents of a z/OS log such as RKLVLOG

To save the information in your z/OS logs (such as RKLVLOG), use the System Display and Search Facility
(SDSF) facility that is part of TSO.
Note: This method works only with JES2. It does not work with JES3.
Follow these instructions to use SDSF to capture (in this example) the RKLVLOG associated with any
running task in your z/OS monitoring agent.
1. From ISPF, select the SDSF option using the =s.st 2 option (for RKLVLOG; sometimes these options
are different).
2. Enter the following on the command line:
st taskname
Where taskname is the name of the procedure whose log you are trying to display and capture. For
example, entering st cansna on the command line would enable you to see the NetView agent job.
3. From the SDSF screen, enter ? next to the name of the started task to display a list of the output files
like the following. For example the output files for the sample cansn3 task noted above would look like
this:
JESMSGLG JES2
JESJCL JES2
JESYSMSG JES2
RKLVLOG CANSNA

RKLVSNAP CANSNA
RKPDLOG CANSNA
4. To print the RKLVLOG for this job to a data set, type an s next to the RKLVLOG output file. Then, on the
command line of SDSF, type:
print d
Press Enter. The d means that the file should be printed to a data set.
5. This action causes a panel similar to this one in Figure 75 on page 535 to be displayed:
COMMAND INPUT ===> SCROLL ===> CSR
Data set name ===> 'USER1.NMP181.D26033.CANSON.SYSLOG'

Member to use ===>
Disposition ===> NEW (OLD, NEW, SHR, MOD)
If the data set is to be created, specify the following.

Volume serial will be used to locate existing data sets if specified.
Management class ===> (Blank for default management class)

Storage class ===> (Blank for default storage class)
Volume serial ===> (Blank for authorized default volume) *
Device type ===> (Generic unit or device address) *
Data class ===> (Blank for default data class)
Space units ===> TRKS (BLKS, TRKS, CYLS, BY, KB, or MB)
Primary quantity ===> 5 (In above units)
Secondary quantity ===> 5 (In above units)
Directory blocks ===> 0 (Zero for sequential data set)
Record format ===> VBA
Record length ===> 240
Block size ===> 3120
* Only one of these fields may be specified
Figure 75. SDSF print to database panel
On this panel, type the data set name and characteristics for the file you are printing and press Enter.
6. You are returned to the RKLVLOG output file. On the command line, specify the number of lines you
want to print by entering a range that would include the entire file, such as:
print 1 99999999
Then press Enter. A message in the upper right corner of the panel tells you how many lines have been
printed.
7. Type print close on the SDSF command line to close the file. The log is now saved in the data set
that was specified in Step “5” on page 535.
For more information about SDSF commands, see z/OS SDSF Operation and Customization (SA22-7670).
Ending one RKLVLOG and starting another

When you recreate a problem to send it to IBM Support, you can use a z/OS MODIFY command to close
the current RKLVLOG spool data set and open a new one. This command is issued from a z/OS console.
The TLVLOG command manages the recording of information to RKLVLOG. The syntax and usage of this
command are as follows:
MODIFY stcname , TLVLOG SWITCH
, CLASS= class
, COPIES= copies , DEST= dest
, FCB= fcb , FORM= form
NO , MAXLINES= maxlines
HOLD=
YES
, UCS= ucs , USER= user
, WTRNAME= wtrname
Where:
SWITCH
Is the keyword that dynamically allocates a new RKLVLOG file using the current values, begins
recording on the new file, and closes the current RKLVLOG file, releasing it for processing by JES.
class
Is the one-character JES SYSOUT class. CLASS=A is the ITMS:Engine startup value.
copies
Is the copy count. The valid range is 1-254. COPIES=1 is the startup value.
Note: JES2 allows 255, but JES3 allows only 254.
dest
Is the 1-8 character JES SYSOUT destination. DEST=() is the startup value.
fcb
Is the 1-4 character FCB name to be used. FCB=() is the startup value.
form
Is the 1-4 character form name to be used. FORM=() is the startup value.
hold
Determines whether the SYSOUT is to be placed in a JES operator hold when spun off. Specify YES
(operator hold is requested) or NO. HOLD=NO is the startup value.
Note: If HOLD=YES is specified, you must issue the appropriate JES release command for the
SYSOUT data set to be processed by JES.
maxlines
Is the maximum number of lines to be written to RKLVLOG, in thousands (for example, MAXLINES=2
means a maximum of 2000 lines). The valid range is 0 through 16000 (16 million lines). When this
number is reached, an automatic TLVLOG SWITCH is performed, closing the current RKLVLOG and
allocating a new one If the specified value is 0, there is no maximum; you must manually enter
TLVLOG SWITCH to switch log files. MAXLINES=0 is the startup value.
Note: Unlike the other values, MAXLINES takes effect immediately. If the new MAXLINES value is less
than the number of lines that have already been written to the current RKLVLOG, a switch is
immediately performed.
ucs
Specifies the 1 to 4 character UCS name to be used. UCS=() is the startup value.

user
Is the 1-8 character user ID to which the SYSOUT is to be spooled. Ignored if DEST is blanks. USER=()
is the startup value.
wtrname
Is the 1-8 character external writer name to be used. WTRNAME=() is the startup value.
User Notes:
1. The TLVLOG command performs up to three functions, depending on the keywords that are specified.
Assuming that you selected all three functions, they would be performed in the following order:
a. Updates the dynamic allocation values. Except for MAXLINES, these values are used when the next
dynamic allocation is performed. Values are updated whenever they are coded on the command.
b. Lists the current dynamic allocation values. This is always done.
c. Switches RKLVLOGs. This is done only when SWITCH is specified on the command.
Note: You can update values and request a switch with the same command; the values are updated
first, then the switch is performed.
2. RKLVLOGs might be automatically closed after a certain number of records have been written to them,
similar to the MVS SYSLOG processing. Refer to the MAXLINES keyword for more information.
3. To set up an automatic RKLVLOG switch whenever the ITMS:Engine address space is started, add the
following command to your RKANCMD startup CLIST:
TLVLOG MAXLINES=nnn
This command causes RKLVLOG to be automatically closed and released to JES whenever nnn
thousands of lines have been written. If needed, you can add other installation-dependent values (for
example, CLASS) to this command.
4. Many diagnostic messages are recorded in RKLVLOG. If you set RKLVLOG to spin off automatically, or
if you explicitly switch RKLVLOG, you must ensure that the SYSOUT files are kept at least for the life of
the ITMS:Engine run, in case they are required for problem solving.
5. You might want to issue a TLVLOG SWITCH command after a problem occurs. This spins off the
RKLVLOG data relating to the problem into a separate spool data set, which can be included as part of
the ITMS:Engine standard problem documentation. Be sure to include all previously spun-off
RKLVLOG files
6. Because RKLVLOG is managed with standard IBM data management routines, records are buffered
before being written. If you are viewing the currently active RKLVLOG with a product such as SDSF, you
do not see the latest messages. Issue the command FLUSH TLVLOG to force the current data
management buffer to be written. Do not use the TLVLOG SWITCH to spin off the current RKLVLOG for
this purpose, as it unnecessarily fragments the messages recorded in RKLVLOG.
7. Unless you explicitly set a non-zero MAXLINES value, RKLVLOG will never automatically switch.
8. If any error occurs when writing to RKLVLOG, ITMS:Engine issues a message and disable RKLVLOG
recording. However, messages are still written to VIEWLOG and all active operator interfaces.
Depending on the error, you might be able to restart RKLVLOG by issuing a switch request.
Here are some example of ways to use this command:
1. To list the current RKLVLOG destination and values:
tlvlog
2. To establish class X and destination SYSPROG as default SYSOUT attributes, and the maximum
number of lines as 20,000:
tlvlog class=x dest=sysprog maxlines=20
3. To switch to a new RKLVLOG:
tlvlog switch
Flushing the log buffers
After a TLVLOG is switched, issuing an echo command can flush the log buffers and ensure that new
messages are written to the new RKLVLOG. The ECHO command echoes any text entered back to the
screen. The syntax of the ECHO command is shown below:
ECHO
string
Where:
string
Is a character string to be echoed back to the operator screen where the ECHO command was
entered.
User Notes:
1. Use ECHO to verify that the ITMS:Engine operator facility is functioning properly and to force all
buffered messages to the log.
2. Even after an ECHO, log output might not be visible in JES3 systems. This is apparently a result of the
way JES3 manages spool buffers.
3. Enclosing string in quotation marks is not necessary unless you want to preserve leading blanks.

Appendix A. Diagnostic command summary
The following tables list some of the commands used for diagnosis.
NetView diagnostic commands

For additional information about NetView diagnostic commands, see the NetView online help.
For TRACE, see also “NetView trace” on page 100, “GMFHS Trace” on page 219, “The RODM Internal
Trace” on page 301, and “SNA topology manager traces” on page 415.
Table 176. Summary of NetView Diagnostic Commands

Command Description
ACTVCTL LISTINFO Displays information about data collection for the Active/Active GDPS Continuous
Availability solution.
BROWSE Enables you to scan the network log or members of a partitioned data set. The
member or network log can be on a local or remote NetView program.
COLLCTL LISTINFO Displays information about data collection for the DVIPA and Discovery Manager
functions.
CMDMON Displays command performance information, including processor utilization,
storage use, and I/O activity. Write these data into z/OS SMF with record type 38
subtype 4.
DEFAULTS MSGMODID Sets whether the module identification information in DSI799I is logged for certain
error conditions.
DEFAULTS STORDUMP Specifies the maximum number of times a storage memory dump is taken if
storage overlay or control block overwrite is detected.
DFILTER Displays the recording or viewing filters that are currently in effect.
DISCONID Displays MVS console names or IDs used by the NetView program.
DSIDIAGG Monitors and reports storage discrepancies.
FIND Locates specific information while browsing a data set and a member.
GMFHS LISTINIT Produces a formatted display of the GMFHS initialization parameters.
GMFHS SHOW Produces a report with an entry for a specified network management gateway
(NMG) or domain, or all NMGs or domains known to GMFHS.
GMFHS STATUS Produces a summary report showing the status of the GMFHS job.
GMFHS TASK Displays a GMFHS subtask status report.
GMFHS TRACE Controls the level and content of the tracing performed by GMFHS tasks.
LIST DEFAULTS Lists the current DEFAULTS settings and the number of memory dumps that have
been taken for storage overlay or control block overwrite conditions (DMPTAKEN).
LIST PRIORITY Lists all NetView tasks and their priorities.
LIST SECOPTS Displays a list of the security options, their current values, the date and time of the
last update, and either the last operator ID to update the option or
INITIALIZATION if the option has not been dynamically changed using the
NetView REFRESH or DEFAULTS commands.

Table 176. Summary of NetView Diagnostic Commands (continued)
Command Description
LIST STATUS=AMLUSESS Displays all VTAM-LU sessions.
LIST STATUS=CANZLOG Displays the status of the Canzlog log.
LIST STATUS=CNMSESS Displays all active communication network management (CNM) data sessions with
your NetView program and the status of these sessions.
LIST STATUS=NNT Displays all the NNT (NetView-NetView task) sessions.
LIST STATUS=OPS Displays all the operator terminals known in this domain.
LIST STATUS=PROFILES Displays a list of profiles known in this domain.
LIST STATUS=SPANS Displays a list of all the spans defined in the NetView span table.
LIST STATUS=XCFGRPS Displays information about the XCF groups to which NetView belongs, including
the other members of the XCF group.
LIST STATUS=TASKS Displays the status of all the tasks in your NetView system, except virtual OSTs
(VOSTs).
LIST STATUS=VOST Displays the status of all the virtual OST tasks (VOSTs) in your NetView system.
LIST STATUS=XCFGRPS Displays a list of z/OS XCF groups in which the NetView program participates.
LIST TRACE Lists the settings of the trace.
NACTL LISTCONN Displays information about the Program to Program Interface (PPI) communication
between the IBM Z NetView Enterprise Management Agent and the NetView
program.
NLDM RELOAD Reloads the response time monitor (RTM) PCLASS and MAPSESS or the KCLASS
and MAPSESS definition statements. The RELOAD command does not affect
current sessions.
NLDM TRACE Starts or stops a session trace or displays resources that are being traced.
QOS Displays information that tells you if an operator is defined to the NetView program
and if the operator is currently logged on.
RODM LOGF RODM writes any buffered log to the current RODM log data set.
RODM LOGP RODM records to the primary log.
RODM LOGQ Queries the current RODM log.
RODM LOGS RODM records to the secondary log.
RODM LOGT RODM ends log activity.
RODM STATAPI RODM writes the API statistics to the RODM log file as a type 8 record.
RODM STATCELL RODM writes the cell pool statistics to the RODM log file as a type 8 record.
RESOURCE Displays system resources (processor utilization, processor time used, and storage
use) used by the NetView program.
SESSMDIS Displays session monitor session counts, storage use, and traffic rates.
TASKMON Displays task utilization data for processor, penalty, message queueing, storage,
and I/O activity for active NetView tasks.
TASKURPT Displays task utilization data for processor, penalty, message queueing, storage,
and I/O activity from SMF logs.

Table 176. Summary of NetView Diagnostic Commands (continued)
Command Description
TASKUTIL Displays task performance information, including processor (processor) utilization,
queue lengths, storage use, and active command lists.
TRACE Initiates a sequence trace that records a sequence of NetView processing steps in
virtual storage, in the DSITRACE VSAM data set, or in GTF.
TRACEPPI Starts, stops, modifies, or ends a trace for all program-to-program interface
receivers or for a specified interface receiver.
TOPOSNA LISTREQS Displays the status of pending topology manager requests to its agents.
TOPOSNA LISTRODM Displays a matrix of object types versus activity and object counts.
TOPOSNA LISTSTOR Displays storage usage counts for SNA topology manager.
TOPOSNA QUERYDEF Requests that settings be displayed.
TOPOSNA REFRESH Changes the initial default values that are provided with the NetView program for
the Status Resolution table, the OSI-Display status table, and the Exception View
table.
TOPOSNA SETDEFS Modifies the defaults for the automatic monitoring of local and network topology at
newly discovered nodes, for reconnection to RODM and CMIP Services, and for the
retry policy of other TOPOSNA commands.
TOPOSNA TRACE Starts, stops, or lists tracing in the topology manager.
NetView VERBX CNMIPCS commands

For additional information about these commands, see “Interactive Problem Control System” on page 75.
Table 177. Summary of VERBX CNMIPCS Commands

Command Description Page
ASID(asid_number) Enables you to change the address “ASID Command Output” on page 82
space identifier (ASID) number.
CPOOL(options) Displays CPOOL storage allocation “CPOOL output” on page 82
by task, subpool, and CPOOL size.
D(address) Displays storage with offsets. “Display storage output” on page 83
DISPLAY(options) Displays summary information “Display task output” on page 84
about task vector blocks (TVBs).
DISPMOD Displays LMOD and CSECT “DISPMOD output” on page 85
information.
DTCB(address) Displays the TCB and RB structure. “Display TCB output” on page 86
LEVEL Displays the NetView IPCS verb “LEVEL command output” on page 86
exit level.
LRCE(options) Displays the LRCE chain for TVBs. “LRCE output” on page 87
MAP(sum) Displays the storage usage. “MAP output” on page 88
Appendix A. Diagnostic command summary 541

Table 177. Summary of VERBX CNMIPCS Commands (continued)
MENU Displays the main menu for the “Summary of VERBX CNMIPCS verbs” on page 78
panel interface if CNMIPCS is run in
an ISPF environment and the
CNMIPCS panels are available to
TSO.
NLDM Displays status information for the “NLDM output” on page 89
session monitor.
NPDA Displays status information for “NPDA output” on page 90
hardware monitor.
QUE(options) Displays the number of messages “Message queue output” on page 91
on the queues for TVBs and others.
SAVEAREA(address Displays theSAVEAREA trace. “Save area output” on page 92
)
STORE(options) Displays storage counters for TVBs. “Storage counter output” on page 92
SUMMARY Displays summary information “Summary Output” on page 81
about the memory dump, including
CSECT information.
TBLUSECT Displays the counters for the “Automation table use count output” on page 93
automation table.
TRACE Displays the NetView internal trace “Trace output” on page 94
header and formatted trace
records.
WHO(address) Tries to determine if the address is “Identify storage output” on page 95
a module or a control block.

(Options) CPOOL, DISPLAY, LRCE, QUE, and “Options for some CNMIPCS verbs” on page 79
STORE.
Option
Description
ABEND
Selects all abending TVBs.
ACTIVE
Selects only active TVBs. This is
the default option.
ALL
Selects all TVBs.
LU(lu_name)
Selects a specific logical unit
(LU) name.
OP(operator_id)
Selects a specific operator ID
or task name.
TCB(address)
Selects a specific task control
block (TCB).
TIB(address)
Selects a specific task
information block (TIB).
TVB(address)
Selects a specific TVB.

(Options) TRACE “Options for the CNMIPCS TRACE verb” on page 79
Option
Description
ALL
Display all records. This is the
default.
DISP
Displays only DISPs.
FRE
Display only FREs.
GET
Displays only GETs.
LOST
Display only LOSTs.
MENT
Displays only MENTs.
MENTMXIT
Display only MENTs and MXITs.
MQS
Displays only MQSs.
MXIT
Displays only MXITs.
POS
Display only POSs.
PSS
Displays only PSSs.
SAF
Displays only SAFs.
STOR
Display only GETs and FREs.
SUM
Display a summary by TVB.
TCP
Display a summary of TCP/IP
trace entry types.
WAT
Display only WATs.
NetView Service Aid commands

For additional information about these commands, see the NetView online help facility.

Table 178. Summary of Service Aid Commands
RID DSIMSX A diagnostic trap that can suspend a task “RID DSIMSX” on page 546
at the point of an abend. You can trap
abends for one task by issuing a RID
command from another task.
TASKURPT A REXX procedure that generates a report “TASKURPT” on page 547
using the task resource data in the System
Management Facility (SMF) log.
DSISTRLS Option A storage list command that can produce “DSISTRLS” on page 556
various NetView storage usage data
through specific request keywords.
Option
Description
<SUMMARY>
Summary statistics about DSIGET/
DSIFRE storage services.
BLOCKS
An address-ordered listing of allocated
blocks of storage.
DETAIL
Intense detail about DSIGET storage
allocation.
CELLHIST
A storage request histogram, a
cumulative count of requests.
SHOWSTOR
Storage usage details on a task-and-
totals basis.
SHOWMQS
Running totals of the number of
DSIMQS requests sent from one task to
another task.
NAME=xxxxxxxx
Filters output by matching the name in
any of DSITVB fields that have EBCDIC
values.
ADDR=nnnnnnnn
Filters output by matching the address
of a DSITVB control block or a system
TCB address.
DSI24TRC Enables you to limit NetView internal trace “DSI24TRC” on page 562
to 24-bit mode storage requests.
DSIMODQY Lists load modules and control sections “DSIMODQY” on page 564
located at the address (hexaddr1) or in the
range (hexaddr1 through hexaddr2).
DSIGTVBA Used to retrieve NetView TVB addresses “DSIGTVBA” on page 565
into CLIST variables for subsequent use in
the address operand of the DSIGV2VR
command.

Table 178. Summary of Service Aid Commands (continued)
DSIGV2VR Used to move and convert data into CLIST “DSIGV2VR” on page 567
variables for use by automation, VIEW, or
subsequent DSIGV2VR commands.
DSIGADHX Used to add two literal hexadecimal values “DSIGADHX” on page 568
and store in CLIST variable named
varname.
DSISHWVR Used to gain diagnostic information in real “DSISHWVR” on page 569
time on NetView program. Must be run in a
command procedure.
RID DSIMSX
Format
RID
RID ID= DSIMSX TASK= taskname
Purpose
The RID DSIMSX command, which is in the NetView ESTAE/ESTAI routine, suspends a task at the point of
an abend. You can trap abends for one task by issuing a RID command from another task.
Parameters
The RID DSIMSX syntax options are defined in the following list:
ID
DSIMSX (identifies this as the abend ESTAE trap).
TASK
Name of the task that is being monitored for abends. This cannot be the name of the task entering the
RID command.
Usage
To use the RID DSIMSX command to stop a task:
1. Logon as an operator, for example, OPER4.
2. As OPER4, enter RID TASK=AUTO1,ID=DSIMSX.
3. Any abend that occurs under the AUTO1 task is now reported to the OPER4 operator. The task remains
suspended until the OPER4 operator enters RID TASK=AUTO1,CONTINUE, at which time the abend
(for example, DUMP) proceeds.
The RID command initiates monitoring of a task to trap system and user abends, including program
checks. Note the amount of what-was-running data in the output. You can use the CSECT and OFFSET
data to tell you where in a listing of the program to look for the problem.
CLIST function commands can be used in CLISTs to display more data areas from the registers in the RID
display output. You can even write new CLISTs on TSO and run them while the diagnosis is being done.

Restrictions
Do not use the RID DSIMSX command to stop a task when you want NetView internal trace or memory
dump data. It is intended to be used to debug code that is being developed on test systems. It can be
helpful during the recreation of a problem where an adequate memory dump exists.
Examples
Example: Output generated by RID DSIMSX

The following is an example of output generated by RID DSIMSX if OPER4 Issues EXCMD AUTO1,RESET
IMMED:
* NTV98 RID TASK=AUTO1,ID=DSIMSX

- NTV98 CNM986I RID FUNCTION 'STEP' COMPLETED FOR TASK AUTO1
* NTV98 EXCMD AUTO1,RESET IMMED

- NTV98 DSI268I EXCMD COMPLETE
' NTV98
CNM987I TASK AUTO1 MOD DSIMSX TYPE MODENTR ID DSIMSX
CNM988I MVT 00007080 TVB 0001D200 TIB 000422D0 TRB 000000
ABEND H 4 0005F93C 00000101
LOAD MOD C 8 03BF580C DSIRSP
CSECT C 8 03BF56EF DSIRSP
OFFSET H 4 03BF56A8 00000308
DATE C 8 03BF56DC 2008.331
PTFLEVEL C 8 03BF56E4 --------
ABENDPSW H 8 0005F9A0 078D2000 83AA74F8
Regs 0-3 D 16 0005F950 0001D2C8 00000101 03649C38 00000002
Regs 4-7 D 16 0005F960 00000002 00000018 000422D0 03649CAC
Regs 8-B D 16 0005F970 00000000 0001D200 00007080 03649C98
Regs C-F D 16 0005F980 83AA71F0 03649C3C 83AA74E6 00000000
SDWA Add H 4 03BF5474 0005F938
TASKURPT
Format

TASKURPT
*ACTIVE*
TASKURPT MAN=suffix
DSN=dsname LOGTSTAT taskid
LOG=dsname LOGOFF
MENU ABEND
HELP STOP/UNCOND
CLOSE/NORMAL
CLOSE/STOP
CLOSE/IMMED
CLOSE/ABEND
(
CYL nnnn
NEWFIRST
NOWINDOW
PREFIX prf
TAKE nnn
Purpose
TASKURPT is a REXX procedure that generates a report using the task resource data in the System
Management Facility (SMF) log. Task utilization data is normally written to the SMF log when a task ends.
You can display processor, storage, message queuing, and I/O utilization data from an active or archived
SMF log. Your output can be filtered by taskid or LU name. Your output is limited to the most recent
number of records. The default output limit is 1000. An example is when an operator logs off.
Parameters
The following list describes the parameters for TASKURPT:
*ACTIVE*
Displays data from the currently active SMF log.
MAN=suffix
Displays resource data from SYS1.MANsuffix where SYS1.MAN is the default prefix value and suffix is
a letter such as “X”.
DSN=dsname
Displays resource data that you created elsewhere to dsname using the IFASMFDP system utility.
LOG=dsname
Displays resource data from the SMF log named dsname.
MENU
Displays a list of SMF log data sets You can tab to any of them and display the resource data.
HELP
Provides command help online. This is easier to view using WINDOW TASKURPT HELP.
LOGTSTAT
This column of keywords filters the records to the specified type. Only one type can be specified. If
none is specified, all resource records are viewed.

LOGOFF
Displays only the specified record in SMF. The default is to display all events for record type 38,
subtype 2.
ABEND
subtype 2.
STOP/UNCOND
subtype 2.
CLOSE/NORMAL
subtype 2.
CLOSE/STOP
subtype 2.
CLOSE/IMMED
subtype 2.
CLOSE/ABEND
subtype 2.
taskid
This filters records to the resource records for the specific operator ID or task name.
The following options are separated from the options above and require left parenthesis as the separator
character. Do not use a right parenthesis at the end of the command.
NOWINDOW
Produces output as messages instead of displaying them in a window. Use this for PIPE automation.
TAKE nnn
Limits the display to the nnn most recent records for the applicable filters. nnn is decimal. The default
is 1000.
PREFIX prf
Is used only in combination with MAN= to specify the SMF log data set name. The default is
"SYS1.MAN". See also MAN=.
NEWFIRST
Is used to order the SMF records, so that the most recent are at the top of the screen.
CYL nnnn
Defines the size of the temporary VIO file. The file is allocated using nnnn as the primary allocation
and nnnn as the secondary. The default for nnnn is 10.
Restrictions
Do not use WINDOW TASKURPT, because TASKURPT automatically puts the output in a WINDOW, and
WINDOW TASKURPT is less efficient.
Examples
Usage
Following is the description of TASKURPT output columns:
Date
The date the record was recorded in SMF record format

Time
The time the record was recorded in SMF record format
Event
The reason the data was recorded
Operator Name
The task name or operator ID (TVBOPID)
LU/Task Name
The task name or terminal name connected to the task (TVBLUNAM)
Domain Name
The NetView domain name in which the task ran
Maximum processor
The maximum measured processor during a 10-second interval since the task began or since the last
LOGSTAT RESETMAX command
Session Seconds
The elapsed time the task has run
Used processor Seconds
The amount of processor time charged to this task by MVS
Penalty Seconds
The number of seconds this task has waited because of MAXMQIN, AVLSLOW, SLOWSTG, MAXCPU,
MAXMQOUT, or MAXIO penalties
Average processor
The percentage of one processor this task has used. The ratio of Used processor to Session Seconds.
Average Penalty
The percentage of elapsed time this task has waited for penalties. The ratio of Penalty Seconds to
Session Seconds.
Maximum Kbytes
The largest recorded usage of storage for this task since the task was started or since the last
LOGSTAT RESETMAX command.
DSIGET K/Min
The average rate (for the life of the task) at which storage was obtained by DSIGET in KB per minute.
DSIFRE K/Min
The average rate (for the life of the task) at which storage was released by DSIFRE in KB per minute
24-GET K/Min
The average rate (for the life of the task) at which storage was obtained by DSIGET.
24-FRE K/Min
The average rate (for the life of the task) at which storage was released by DSIFRE in KB per minute
(24-bit storage only)
MaxQin K/Min
The maximum rate, over a 1-minute period, at which messages were queued to this task by DSIMQS
in KB per minute. The rate is since the task started or since the last LOGSTAT RESETMAX command.
Que In K/Min
The rate, over the life of the task, at which messages were queued to this task by DSIMQS in KB per
minute.
MaxQOut K/Min
The maximum rate, over a 1-minute period, at which messages were sent by this task by DSIMQS in
KB per minute. The rate is since the task started or since the last LOGSTAT RESETMAX command.
Que Out K/Min
The rate, over the life of the task, at which messages were sent by this task by DSIMQS in KB per
minute.
In Cnt Messages
The count of the number of messages sent to this task over the life of the session.

Out Cnt Messages
The count of the number of messages sent by this task over the life of the session.
I/O Cnt
The total number of I/O functions done by NetView services on this task for the life of the task.
Max I/O IOs/Min
The maximum rate of I/O functions per minute in a 1-minute interval since the task was started or
since the last LOGSTAT RESETMAX command
I/O Rate IOs/Min
The average rate of I/O functions per minute for the life of the task.
MQI Pen Seconds
The total number of penalty seconds this task caused other tasks to wait because of the MAXMQIN,
SLOWSTG, or AVLSLOW limit of this task being exceeded. A penalty time is served when a DSIMQS
from another task is sent to the task that is over any of these limits.
Return codes
The return code for TASKURPT is zero (0), meaning the command completed, successfully.
Example: TASKURPT command

Following are some examples of the TASKURPT command:
TASKURPT MENU (CYL 100

TASKURPT *ACTIVE* (TAKE 100 NEWFIRST
TASKURPT LOG=SYS1.MANX (TAKE 50
TASKURPT DSN=ARC1.MANX (TAKE 500
TASKURPT ABEND (TAKE 50
TASKURPT MENU LOGOFF OPER6
TASKURPT MAN=Q (NOWINDOW TAKE 10 PREFIX ARCHIVE.MAN
Example: A report generated by TASKRUPT

The following example is a report generated by TASKURPT:
1:60,TASKURPT (NOWINDOW TAKE 50

Return Code=0
Number of Output Lines=56
-Ruler-0005|0010|0015|0020|0025|0030|0035|0040|0045|0050|0055|0060|
1 | Operator LU/Task Domain
2 |Date Time Event Name Name Name
3 |-------- ----------- ------------ -------- -------- --------
4 |2009.138 16:28:47.40 LOGOFF DSITRACE DSITRACE NTV98
5 |2009.138 16:28:48.11 LOGOFF AAUTSKLP AAUTSKLP NTV98
6 |2009.138 16:28:49.14 LOGOFF DSISVRT DSISVRT NTV98
7 |2009.138 16:28:49.80 LOGOFF NTV98BRW NTV98BRW NTV98
8 |2009.138 16:28:50.12 LOGOFF DSILCOPR DSILCOPR NTV98
9 |2009.138 16:28:50.20 LOGOFF NTV98LUC NTV98LUC NTV98
10 |2009.138 16:28:50.33 LOGOFF DSIAMLUT DSIAMLUT NTV98
11 |2009.138 16:28:50.73 LOGOFF ALIASAPL ALIASAPL NTV98
12 |2009.138 16:28:52.07 LOGOFF AAUTCNMI AAUTCNMI NTV98
13 |2009.138 16:28:52.51 LOGOFF NTV98VMT NTV98VMT NTV98
14 |2009.138 16:28:52.58 LOGOFF DSIQSD4A DSIQSD4A NTV98
15 |2009.138 16:28:52.90 LOGOFF DSIQRV4B DSIQRV4B NTV98
16 |2009.138 16:28:53.21 LOGOFF DSIQRV4C DSIQRV4C NTV98
17 |2009.138 16:28:53.50 LOGOFF VPDTASK VPDTASK NTV98
18 |2009.138 16:28:54.09 LOGOFF DSIQSD4B DSIQSD4B NTV98
19 |2009.138 16:28:54.38 LOGOFF DSIQSD4C DSIQSD4C NTV98
20 |2009.138 16:28:54.68 LOGOFF CNM01QSD CNM01QSD NTV98
21 |2009.138 16:28:55.01 LOGOFF DSIQRV4A DSIQRV4A NTV98
22 |2009.138 16:28:55.56 LOGOFF DSICRTR DSICRTR NTV98
23 |2009.138 16:28:56.29 LOGOFF DSIKREM DSIKREM NTV98
24 |2009.138 16:28:56.51 LOGOFF BNJDSERV BNJDSERV NTV98
25 |2009.138 16:29:05.35 LOGTSTAT MAINTASK SYSOP NTV98
26 |2009.138 16:29:05.35 LOGTSTAT NTV98PPT NTV98PPT NTV98
27 |2009.138 16:29:05.35 LOGTSTAT DSIMONIT DSIMONIT NTV98
28 |2009.138 16:29:05.35 LOGTSTAT DSITIMMT DSITIMMT NTV98
29 |2009.138 16:29:05.35 LOGTSTAT DSIDCBMT DSIDCBMT NTV98

30 |2009.138 16:29:05.35 LOGTSTAT DSIHLLMT DSIHLLMT NTV98
31 |2009.138 16:29:05.35 LOGTSTAT DSISTMMT DSISTMMT NTV98
32 |2009.138 16:29:05.35 LOGTSTAT DSIWTOMT DSIWTOMT NTV98
33 |2009.138 16:29:05.35 LOGTSTAT DSIACBMT DSIACBMT NTV98
34 |2009.138 16:29:05.35 LOGTSTAT DSILOGMT DSILOGMT NTV98
35 |2009.138 16:29:05.35 LOGTSTAT OPER3 OPER3 NTV98
42 |2009.138 16:29:05.52 LOGTSTAT DSITIMMT DSITIMMT NTV98
43 |2009.138 16:29:05.52 LOGTSTAT DSIDCBMT DSIDCBMT NTV98
44 |2009.138 16:29:05.52 LOGTSTAT DSIHLLMT DSIHLLMT NTV98
Example: Output generated by TASKURPT

The following example is the output of the TASKURPT command:
46 |2009.138 16:29:05.52 LOGTSTAT DSISTMMT DSISTMMT NTV98

47 |2009.138 16:29:05.52 LOGTSTAT DSIWTOMT DSIWTOMT NTV98
48 |2009.138 16:29:05.52 LOGTSTAT DSIACBMT DSIACBMT NTV98
49 |2009.138 16:29:05.52 LOGTSTAT DSILOGMT DSILOGMT NTV98
50 |2009.138 16:29:05.52 LOGTSTAT OPER3 OPER3 NTV98
-Ruler-0005|0010|0015|0020|0025|0030|0035|0040|0045|0050|0055|0060|
<-- End Columns 1:60-->

Return Code=0
-Ruler-0065|0070|0075|0080|0085|0090|0095|0100|0105
1 | Maximum Session Used CPU
2 | CPU% seconds seconds
3 | ------- ----------------- -----------------
4 | 0.51 994.933358 0.059714
5 | 0.30 994.606067 0.039716
6 | 1.02 994.499822 0.131732
7 | 0.39 996.640239 0.040786
8 | 0.03 996.726691 0.004718
9 | 0.28 970.865641 0.017055
10 | 0.12 996.591360 0.019000
11 | 0.13 997.132887 0.024090
12 | 0.13 997.642773 0.025757
13 | 0.07 998.886562 0.014841
14 | 0.75 999.431784 0.134403
15 | 0.07 998.927449 0.006311
16 | 0.03 999.228930 0.003820
17 | 0.03 999.521794 0.003156
18 | 0.06 999.856236 0.008128
19 | 0.06 1000.437805 0.006264
20 | 0.07 1000.732072 0.005631
21 | 0.07 1001.033959 0.006353
22 | 0.03 1001.360682 0.006341
23 | 0.07 1002.385841 0.012224
24 | 0.35 1003.200227 0.039140
25 | 0.43 1003.325160 0.046776
26 | 0.35 7793.971973 2.839490
27 | 0.14 7691.891829 1.778795
28 | 0.03 7781.594283 1.780333
29 | 0.00 7781.469443 0.001038
30 | 0.00 7781.332946 0.094697
31 | 0.00 7693.706748 0.007342

32 | 0.02 7693.514873 0.056192
33 | 0.00 7693.349482 0.002310
34 | 0.00 7692.890799 0.013383
35 | 0.24 7691.908525 0.092143
36 | 41.27 193.845658 3.765462
37 | 0.35 7794.000375 2.839490
38 | 0.35 7794.035545 2.839490

39 | 0.35 7794.125775 2.840219
40 | 0.03 7794.144457 2.840219
41 | 0.14 7692.064264 1.778795
42 | 0.03 7781.766951 1.780333
43 | 0.00 7781.642119 0.001038
44 | 0.00 7781.505620 0.094697
45 | 0.00 7693.879518 0.007342
46 | 0.02 7693.687558 0.056192
47 | 0.00 7693.522137 0.002310
48 | 0.00 7693.063454 0.013383
49 | 0.24 7692.080583 0.092143
50 | 41.27 194.017670 3.765462
51 | 0.03 7794.187914 2.840219
52 | 0.14 7692.107722 1.778795
53 | 0.03 7781.810175 1.780333
-Ruler-0065|0070|0075|0080|0085|0090|0095|0100|0105
<-- End Columns 61:104-->

Return Code=0
-Ruler-|0110|0115|0120|0125|0130|0135|0140|0145|0150|0155|01
1 | Penalty Average Average Maximum DSIGET
2 | seconds CPU% Penalty Kbytes K/min.
3 | ----------------- ------- ------- ------- ----------
4 | 0.000000 0.00 0.00 73 6
5 | 0.000000 0.00 0.00 89 6
6 | 0.000000 0.01 0.00 1524 101
7 | 0.951643 0.00 0.09 213 13
8 | 0.637185 0.00 0.06 16 0
9 | 0.000000 0.00 0.00 98 16
10 | 0.000000 0.00 0.00 94 6
11 | 0.000000 0.00 0.00 73 5
12 | 0.575414 0.00 0.05 102 16
13 | 1.801088 0.00 0.18 295 19
14 | 1.966722 0.01 0.19 81 29
15 | 2.228434 0.00 0.22 59 3
16 | 2.499864 0.00 0.25 37 2
17 | 2.793850 0.00 0.27 37 2
18 | 3.089860 0.00 0.30 74 5
19 | 3.672162 0.00 0.36 59 3
20 | 3.966305 0.00 0.39 59 3
21 | 4.241932 0.00 0.42 59 3
22 | 4.536043 0.00 0.45 37 2
23 | 5.321668 0.00 0.53 85 6
24 | 5.829898 0.00 0.58 73 6
25 | 5.811196 0.00 0.57 85 10
26 | 50.986242 0.03 0.65 1033 106
27 | 37.159961 0.02 0.48 168 17
28 | 0.000000 0.02 0.00 4 0
29 | 0.000000 0.00 0.00 3 0
30 | 0.000000 0.00 0.00 3 0
31 | 0.000000 0.00 0.00 3 0
32 | 0.000000 0.00 0.00 4 0
33 | 0.000000 0.00 0.00 3 0
34 | 0.000000 0.00 0.00 5 0
35 | 0.000000 0.00 0.00 3 0
36 | 136.000000 1.94 70.15 98 100
37 | 50.986242 0.03 0.65 1033 106
38 | 50.986242 0.03 0.65 1033 106
39 | 51.294330 0.03 0.65 1033 106
40 | 51.294330 0.03 0.65 0 106
41 | 37.159961 0.02 0.48 168 17
42 | 0.000000 0.02 0.00 4 0
43 | 0.000000 0.00 0.00 3 0
44 | 0.000000 0.00 0.00 3 0
45 | 0.000000 0.00 0.00 3 0

46 | 0.000000 0.00 0.00 4 0
47 | 0.000000 0.00 0.00 3 0
48 | 0.000000 0.00 0.00 5 0
49 | 0.000000 0.00 0.00 3 0

50 | 136.000000 1.94 70.09 98 99
51 | 51.294330 0.03 0.65 0 106
52 | 37.159961 0.02 0.48 168 17
53 | 0.000000 0.02 0.00 4 0
-Ruler-|0110|0115|0120|0125|0130|0135|0140|0145|0150|0155|01
<-- End Columns 105:157-->

Return Code=0
-Ruler-60|0165|0170|0175|0180|0185|0190|0195|0200|0205|0210|02
1 | DSIFRE 24-GET 24-FRE MaxQin Que In
2 | K/min. K/min. K/min. K/min. K/min.
3 | ---------- ---------- ---------- ---------- ----------
4 | 5 3 3 0 0
5 | 5 3 3 0 0
6 | 70 3 61 21 0
7 | 12 3 10 2 0
8 | 0 0 0 0 0
9 | 16 10 10 6 0
10 | 5 3 3 0 0
11 | 5 3 3 12 0
12 | 15 10 10 0 0
13 | 18 3 15 7 0
14 | 25 18 18 1 0
15 | 3 1 1 0 0
16 | 1 1 1 0 0
17 | 1 1 1 0 0
18 | 4 3 3 0 0
19 | 3 1 1 0 0
20 | 3 1 1 0 0
21 | 3 1 1 0 0
22 | 1 1 1 0 0
23 | 5 3 3 0 0
24 | 5 3 3 0 0
25 | 7 5 5 17 0
26 | 100 62 61 0 0
27 | 18 5 5 26 3
28 | 0 0 0 0 0
29 | 0 0 0 0 0
30 | 0 0 0 0 0
31 | 0 0 0 0 0
32 | 0 0 0 0 0
33 | 0 0 0 0 0
34 | 0 0 0 0 0
35 | 0 0 0 0 0
36 | 99 59 59 7 0
37 | 100 62 61 0 0
38 | 100 62 61 0 0
39 | 100 62 61 0 0
40 | 100 62 61 0 0
41 | 18 5 5 26 3
42 | 0 0 0 0 0
43 | 0 0 0 0 0
44 | 0 0 0 0 0
45 | 0 0 0 0 0
46 | 0 0 0 0 0
47 | 0 0 0 0 0
48 | 0 0 0 0 0
49 | 0 0 0 0 0
50 | 99 59 59 7 0
51 | 100 62 61 0 0
52 | 18 5 5 26 3
53 | 0 0 0 0 0
-Ruler-60|0165|0170|0175|0180|0185|0190|0195|0200|0205|0210|02
<-- End Columns 158:212-->

Return Code=0

-Ruler-15|0220|0225|0230|0235|0240|0245|0250|0255|0260|0265|0270|0275|028
1 | MaxQout Que Out In Cnt Out Cnt I/O Cnt Max I/O
2 | K/min. K/min. Messages Messages I/O Cnt IOs/min.
3 | ---------- ---------- ---------- ---------- ---------- ----------
4 | 20 0 0 8 32 2
5 | 21 0 0 6 30 347
6 | 44 0 11 20 57 371
7 | 21 0 1 6 31 47
8 | 13 0 0 9 0 0
9 | 2 0 5 1 122 1462
10 | 13 0 0 3 41 479
11 | 13 0 20 37 43 503
12 | 30 0 0 8 53 215
13 | 13 0 3 6 18 203
14 | 51 2 2 385 861 7743
15 | 14 0 0 5 3 23
16 | 6 0 0 2 0 0
17 | 6 0 0 2 0 0
18 | 14 0 0 3 20 227
19 | 14 0 0 5 3 11
20 | 14 0 0 5 3 23
21 | 14 0 0 5 3 23
22 | 6 0 0 2 0 0
23 | 14 0 0 4 41 479
24 | 21 0 0 6 27 311
25 | 42 0 2 10 155 1007
26 | 150 2 0 447 11686 90
27 | 10 0 3686 666 1547 12
28 | 8 0 0 22 0 0
29 | 0 0 0 0 0 0
30 | 0 0 0 0 0 0
31 | 0 0 0 0 0 0
32 | 7 0 0 42 0 0
33 | 0 0 0 0 0 0
34 | 0 0 0 0 0 0
35 | 0 0 0 0 0 0
36 | 2 0 4 1 112 827
37 | 150 2 0 447 11686 90
38 | 150 2 0 447 11686 90
39 | 150 2 0 448 11686 90
40 | 2 2 0 448 11686 90
41 | 10 0 3686 666 1547 12

42 | 8 0 0 22 0 0
43 | 0 0 0 0 0 0
44 | 0 0 0 0 0 0
45 | 0 0 0 0 0 0
46 | 7 0 0 42 0 0
47 | 0 0 0 0 0 0
48 | 0 0 0 0 0 0
49 | 0 0 0 0 0 0
50 | 2 0 4 1 112 827
51 | 2 2 0 448 11686 90
52 | 10 0 3686 666 1547 12
53 | 8 0 0 22 0 0
-Ruler-15|0220|0225|0230|0235|0240|0245|0250|0255|0260|0265|0270|0275|028
<-- End Columns 213:278-->

Return Code=0
-Ruler-0|0285|0290|0295|0300|0305|0310|
1 | I/Orate MQI Pen
2 | IOs/min. Seconds
3 | ---------- -----------------
4 | 2 0.000000
5 | 1 0.000000
6 | 3 0.000000
7 | 1 0.000000
8 | 0 0.000000
9 | 7 0.000000
10 | 2 0.000000
11 | 2 0.000000
12 | 3 0.000000
13 | 1 0.000000
14 | 53 0.000000

15 | 0 0.000000
16 | 0 0.000000
17 | 0 0.000000
18 | 1 0.000000
19 | 0 0.000000
20 | 0 0.000000
21 | 0 0.000000
22 | 0 0.000000
23 | 2 0.000000
24 | 1 0.000000
25 | 9 0.000000
26 | 90 0.000000
27 | 12 0.000000
28 | 0 0.000000
29 | 0 0.000000
30 | 0 0.000000
31 | 0 0.000000
32 | 0 0.000000
33 | 0 0.000000
34 | 0 0.000000
35 | 0 0.000000
36 | 37 0.000000
37 | 90 0.000000
38 | 90 0.000000
39 | 90 0.000000
40 | 90 0.000000
41 | 12 0.000000
42 | 0 0.000000
43 | 0 0.000000
44 | 0 0.000000
45 | 0 0.000000
46 | 0 0.000000
47 | 0 0.000000
48 | 0 0.000000
49 | 0 0.000000
50 | 37 0.000000
51 | 90 0.000000
52 | 12 0.000000
53 | 0 0.000000
-Ruler-0|0285|0290|0295|0300|0305|0310|
<-- End Columns 279:338-->
DSISTRLS
Format
DSISTRLS
SUMMARY
DSISTRLS
HELP
BLOCKS
DETAIL
CELLHIST
SHOWSTOR
SHOWMQS
SHOWMQS ADDR=xxxxxxxx
SHOWMQS NAME=nnnnnnnn
Purpose
DSISTRLS is a storage list command. It can provide various NetView storage usage data through specific
request keywords.

DSISTRLS BLOCKS is an address ordered listing of allocated blocks of storage that was retrieved using
DSIGET. Individually, obtained areas are combined when the end of one runs into the start of another.
The output gives a picture of DSIGET storage locations amid a sea of empty space, load modules, and
storage obtained with GETMAIN. It can give information about fragmentation or storage that is building
up because of coding errors. The output also provides summary statistics retrieved by DSISTRLS
SUMMARY.
DSISTRLS DETAIL provides detail about DSIGET storage allocation. It lists every individual DSIGET
storage allocation currently in use, in order of address. This request uses a large amount processor time
and needs memory for the amount of data produced.
DSISTRLS CELLHIST produces a storage request histogram. This is a cumulative count of the number of
requests for each 8-byte interval of storage in the range of 8—4096 bytes. This data can be used to
determine user loading of cell-pool areas and to assess if the cell allocations are optimal. Storage is
identified by a 24-bit versus a 31-bit request, and queued versus non-queued. Each line gives the count
of requests and a histogram scaled to its percentage of the largest value recorded. Sizes that have zero
usage are suppressed to eliminate useless information. The size of the request precedes the colon, and
the count follows; all are in decimal notation.
DSISTRLS SHOWSTOR provides storage usage details on a task and totals basis. Only storage managed
by DSIGET is shown. This is useful for tracking individual task storage problems. Detail is at the individual
byte level, so that small losses can be detected. Data is organized spreadsheet fashion.
DSISTRLS SHOWMQS provides running totals of the number of DSIMQS requests sent from one task to
another task. Both send and receive of a DSIMQS are tracked, making it possible to compute message
traffic rates and whether a task is a message source, message sink, or message neutral task. In
“Example: Output generated by DSISTRLS SHOWMQS” on page 561, note that the DSILOG is a message
sink and NTV98VMT is a message source.
DSISTRLS SHOWMQS ADDR=xxxxxxxx filters output by matching the address of a DSITVB control block
or a system TCB address. Because NetView calculates the length of the TVB, any value within the range of
a TVB will match.
DSISTRLS SHOWMQS NAME=nnnnnnnn filters DSISTRLS SHOWMQS output by matching the name in any
of DSITVB fields that have EBCDIC values.
Parameters
The DSISTRLS <SUMMARY> command provides summary statistics about DSIGET/DSIFRE storage
services.
The following list describes the fields in the DSISTRLS <SUMMARY> output:
DSIGET storage map
This output is suppressed. See DSISTRLS BLOCKS or DSISTRLS DETAIL.
Above 24-bit storage
This is the amount of DSIGET storage in use above address X'00FFFFFF'.
Mapped below 24-bit storage
This is the amount of DSIGET storage in use below address X'00FFFFFF' (includes the percentage of
DSIGET currently allocated below the line). This value is computed by counting the storage mapped
by NetView DSIGET storage integrity (built in) function.

Counted below 24-bit storage
This is a second count of storage, kept in an accumulator (not mapped). It is a second opinion about
24-bit DSIGET usage.
Maximum ever
This is the highest value ever recorded for the counted below 24-bit storage. It is a figure-of-merit of
the total demand for 24-bit storage. By comparing the 24-bit storage reported by the RESOURCE
command to the counted-below-24-bit value, you can estimate how much storage is not being
monitored by DSIGET. This gives you an estimate of how much to scale up the reported high water
mark as a safety factor in estimating total demand.
Total of all storage
This is the sum of the 24-bit and above 24-bit storage managed by DSIGET.
Storage accounting
This is the amount of 31-bit storage used to map the DSIGET requests.
Accounting storage cost
This is the amount of storage used to ensure the integrity of DSIGET. This percentage is lowest when
storage usage is high.
The following list contains a description of the fields in the DSISTRLS SHOWSTOR output:
TASK Q Current Pooled
Sum of all tasks current pooled, listed after TOTALS.
TASK Q Maximum Pooled
Sum of all tasks maximum pooled, listed after TOTALS.
TASK Q Current Non Pool
Sum of all tasks current non-pool, listed after TOTALS.
TASK Q Maximum Non Pool
Sum of all tasks maximum non-pool, listed after TOTALS.
TASK Q Total Current
Current Pooled + current non-pool. This is the ultimate current usage value.
TASK Q Total Maximum
Maximum pooled + maximum non-pool. This is the ultimate maximum usage value assuming every
individual task hit its maximum at exactly the same moment. An estimate of worst case loading.
GLOBAL Current Pooled
Storage retrieved using DSIGET Q=NO and put into cell pools.
GLOBAL Current Non Pool
Storage retrieved using DSIGET Q=NO and not put into cell pools.
GLOBAL Total Current
Current pooled + current non-pool
TOTALS
TASK Q + GLOBAL
Non Queued (Global) Storage by Task
The amount of global storage used by a particular task, both pooled and non-pooled. This storage is
often transferred using DSIMQS. Often, global tables are obtained by a particular task and transferred
to the main task because they are shared resources used by every task.
PART SUM
The sum of global storage by task. This is the amount of DSIGET requests currently allocated in global
NetView storage. It does not contain overhead as does GLOBAL Total Current. The difference can
possibly be used to see overhead management problems.
In the following example, the GLOBAL Total Current number is larger than PART SUM (see the following
example), by the amount of NetView overhead in unused pooled cells and storage management control
blocks. The output has been edited for space and the totals are not accurate.

Restrictions
DSISTRLS BLOCKS output can be lengthy and can consume processor time and storage.
Examples
Example: Output generated by DSISTRLS<SUMMARY>
NCCF NetView NTV98 OPER4 01/10/19 09:38:05

* NTV98 DSISTRLS
' NTV98
DSISTRLS DSIGET Storage Map
Start End Length Decimal
-------- -------- -------- ----------
Above 24-bit storage: 1200600
Mapped below 24-bit storage: 68560 (5.40%)
Counted below 24-bit Storage: 68560 Maximum Ever: 75288
Total of all storage: 1269160
Storage Accounting : 16640 Grand Total: 1285800
1.29% = Accounting Storage Cost
DSISTRLS End of storage map
Example: Output generated by DSISTRLS BLOCKS

* NTV98 DSISTRLS BLOCKS
' NTV98
-------- -------- -------- ----------
01D000 01DFFF 1000 4096
01E140 01EFFF 0EC0 3776
*
*
*
04DE50 04EFFF 11B0 4528
0329EFC0 0329EFFF 40 64
03646238 03646FFF 0DC8 3528
*
*
*
03CFA000 03CFCFFF 3000 12288
Example: Output generated by DSISTRLS DETAIL

* NTV98 DSISTRLS DETAIL
' NTV98
-------- -------- -------- ----------
01D000 01D1FF 0200 512
01D200 01D3FF 0200 512
01D400 01D5FF 0200 512
01D600 01D7FF 0200 512
01D800 01D9FF 0200 512
01DA00 01DBFF 0200 512
01DC00 01DDFF 0200 512
01DE00 01DFFF 0200 512
01E140 01E33F 0200 512
*
*
*
04DE50 04EFFF 11B0 4528
0329EFC0 0329EFDF 20 32
0329EFE0 0329EFFF 20 32
*
*

*
03CFB000 03CFCFFF 2000 8192
Example: Output generated by DSISTRLS CELLHIST

* NTV98 DSISTRLS CELLHIST
' NTV98
DSISTRLS Cell Pool Usage
24-BIT Non-Queued Storage
168: 1 |*
31-BIT Non-Queued Storage
8: 84 |****
48: 1031 |*************************************************
64: 24 |*
80: 108 |*****
88: 493 |***********************
96: 102 |****
120: 693 |*********************************
200: 42 |**
256: 511 |************************
976: 1 |
2016: 1 |
4000: 1 |
31-BIT Queued Storage
8: 49 |*****
16: 427 |***********************************************
24: 385 |******************************************
48: 58 |******
64: 13 |*
72: 30 |***
80: 25 |**
88: 118 |*************
160: 79 |********
512: 78 |********
640: 27 |***
1680: 53 |*****
1688: 9 |*
1784: 11 |*
2000: 22 |**
4000: 17 |*
4056: 96 |**********
DSISTRLS End of cell size usage
Example: Output generated by DSISTRLS SHOWSTOR

* NTV98 DSISTRLS SHOWSTOR
' NTV98
DSISTRLS SHOWSTOR STORAGE REPORT
Type Current Maximum Current Maximum Total Total
Pooled Pooled Non-Pool Non-Pool Current Maximum
TASK Q 339899 470958 164381 437653 504280 908611
GLOBAL 204769 270297 572231 572231 777000 842528
TOTALS 544668 741255 736612 1009884 1281280 1751139
Task Queued Storage
MainTask 24571 40954 108 74944 24679 115898
NTV98PPT 69619 118766 55352 148104 124971 266870
DSILOG 4095 4095 7976 20220 12071 24315
DSISVRT 32761 32761 77286 85396 110047 118157
DSIELTSK 4095 4095 11306 20220 15401 24315
NTV98VMT 49143 49143 8077 12633 57220 61776
NTV98BRW 4095 4095 0 0 4095 4095
OPER4 65523 102384 4120 37836 69643 140220
AUTO1 49141 77809 0 19072 49141 96881
AUTO2 36856 36856 0 19072 36856 55928
Non-Queued (Global) Storage By Tasks
MainTask 540217
NTV98PPT 11489
DSILOG 6144
CNMCSSIR 5088

CNMCALRT 3072
DSISVRT 6144
DSIELTSK 6144
NTV98VMT 45807
NTV98BRW 3072
OPER4 7770
AUTO1 3188
AUTO2 3188
PART SUM 664065
DSISTRLS End of SHOWSTOR report
Example: Output generated by DSISTRLS SHOWMQS

* NTV98 DSISTRLS SHOWMQS
' NTV98
SHOWMQS Message Queuing Report
Operator Messages Messages TASK/LU TVB TCB APPL
From To
Totals 741 741
Maintask 6 0 Maintask 000059D0 008E6D18 NTV98
NTV98PPT 7 106 NTV98PPT 0002DB10 008C8E88 NTV98PPT
DSILOG 4 605 DSILOG 0002DD08 008C7D18 DSILOG
CNMCSSIR 2 0 CNMCSSIR 0002E4E8 008C7890 CNMCSSIR
CNMCALRT 1 0 CNMCALRT 0002E6E0 008C8B68 CNMCALRT
DSISVRT 2 0 DSISVRT 0002EAD0 008C71E0 DSISVRT
DSIELTSK 1 0 DSIELTSK 0002F0B8 008C4B68 DSIELTSK
NTV98VMT 97 0 NTV98VMT 00030078 008C75E0 NTV98VMT
NTV98BRW 5 0 NTV98BRW 00030270 008C4E88 NTV98BRW
OPER4 590 9 NT98L702 0001E140 008BE478 NTV98002
AUTO1 25 21 AUTO1 0001D200 008C8848 NTV98000
AUTO2 0 0 AUTO2 0001D000 008C8168 NTV98001
DSISTRLS End of SHOWMQS Report
Example: Output generated by DSISTRLS SHOWMQS ADDR=xxxxxxxx

* NTV98 DSISTRLS SHOWMQS ADDR=2DB18
' NTV98
From To
Totals 805 805
* NTV98 DSISTRLS SHOWMQS ADDR=8C8E88

' NTV98
From To
Totals 819 819
* NTV98 DSISTRLS SHOWMQS ADDR=8C8E98

' NTV98
From To
Totals 109 109
Example: Output generated by DSISTRLS SHOWMQS NAME=nnnnnnnn

* NTV98 DSISTRLS SHOWMQS NAME=NTV98PPT
' NTV98
From To
Totals 778 778

DSI24TRC
Format
DSI24TRC
ON
DSI24TRC
HELP
OFF
Purpose
The DSI24TRC command enables you to limit the NetView internal trace for storage to 24-bit storage
requests. It also displays the current trace options.
Parameters
DSI24TRC HELP
DSI24TRC HELP displays the syntax of DSI24TRC and the current trace options.
DSI24TRC ON
DSI24TRC ON, filters DSIGMN/DSIFMN to trace only 24-bit mode storage requests and displays the
current trace options.
DSI24TRC OFF
DSI24TRC OFF sets DSIGMN/DSIFMN to trace all storage requests and displays the current trace
options.
Examples
Example: Output generated by DSI24TRC
NTV98 TRACE ON,MODE=GTF,OPT=ALL

NTV98 DSI244I NETVIEW TRACE ACTIVE FOR TASK = ALL : MODE = GTF, SIZE = 0
WITH OPTIONS = QUE PSS DISP STOR UEXIT MOD
NTV98 DSI24TRC
NTV98 DSI24TRCS NetView trace active
NTV98 DSI24TRC7 MODE=GTF
NTV98 DSI24TRC8 TASK=ALL
NTV98 DSI24TRCF OPT=QUE
NTV98 DSI24TRCG OPT=PSS
NTV98 DSI24TRCH OPT=DISP
NTV98 DSI24TRCQ OPT=STOR
NTV98 DSI24TRCL OPT=MOD
NTV98 DSI24TRCM OPT=UEXIT
NTV98 DSI24TRCK Enable trace any mode storage
NTV98 TRACE END

NTV98 DSI241I NCCF TRACE INACTIVE
NTV98 START TASK=DSITRACE

NTV98 DSI166I DSITRACE IS ACTIVATED BY OPER4
NTV98 DSI556I DSITRACE : VSAM DATASET 'OPEN' COMPLETED, DDNAME =
'DSITRCP' RETURN CODE = X'00', ACB ERROR FIELD = X'00'
NTV98 DSI556I DSITRACE : VSAM DATASET 'OPEN' COMPLETED, DDNAME =
'DSITRCS' RETURN CODE = X'00', ACB ERROR FIELD = X'00'
NTV98 DSI530I 'DSITRACE' : 'DST' IS READY AND WAITING FOR WORK
NTV98 DSI240I DSITRACE : TRACE LOG IS NOW ACTIVE
NTV98 TRACE ON,MODE=EXT,OPT=ALL,TASK=(OPER4)

NTV98 DSI244I NETVIEW TRACE ACTIVE FOR TASK = OPER4 : MODE = EXT, SIZE =
0 WITH OPTIONS = QUE PSS DISP STOR UEXIT MOD
NTV98 DSI24TRC
NTV98 DSI24TRC6 MODE=EXT
NTV98 DSI24TRCN TASK=OPER4
NTV98 DSI24TRCL OPT=MOD
NTV98 DSI24TRCM OPT=UEXIT
NTV98 DSI24TRCK Enable trace any mode storage
Example: Output generated by DSI24TRC HELP

* NTV98 DSI24TRC HELP
- NTV98 DSI24TRC1 Syntax: DSI24TRC ON|OFF|HELP
- NTV98 DSI24TRC2 Where: ON = Trace only 24-bit
- NTV98 DSI24TRC3 OFF = Trace any
- NTV98 DSI24TRC4 NetView trace inactive
- NTV98 DSI24TRCK Enable trace any mode storage
Example: Output generated by DSI24TRC ON
NTV98 TRACE ON,MODE=INT

NTV98 DSI244I NETVIEW TRACE ACTIVE FOR TASK = ALL : MODE = INT, SIZE =
250 WITH OPTIONS = QUE PSS DISP STOR
NTV98 DSI24TRC ON
NTV98 DSI24TRC5 MODE=INT, SIZE=250 PAGES (1000K)
NTV98 DSI24TRCJ Enable trace 24-bit storage only
NTV98 TRACE ON,MODE=INT

NTV98 DSI244I NETVIEW TRACE ACTIVE FOR TASK = ALL : MODE = INT, SIZE =
250 WITH OPTIONS = QUE PSS DISP STOR
NTV98 DSI24TRC ON
NTV98 DSI24TRC5 MODE=INT, size=250 PAGES (1000K)
NTV98 DSI24TRCJ Enable trace 24-bit storage only
Example: Output generated by DSI24TRC OFF
* NTV98 TRACE OFF
- NTV98 DSI243I NETVIEW TRACE IS NOW OFF
* NTV98 DSI24TRC OFF

- NTV98 DSI24TRCR NetView trace off
- NTV98 DSI24TRC5 MODE=INT, size=250 PAGES (1000K)
* NTV98 TRACE END

- NTV98 DSI241I NCCF TRACE INACTIVE
* NTV98 DSI24TRC
- NTV98 DSI24TRC4 NetView trace inactive

DSIMODQY
Format
DSIMODQY
DSIMODQY hexaddr1
hexaddr2
Purpose
The DSIMODQY command lists load modules and control sections located at the address (hexaddr1) or in
the range (hexaddr1 through hexaddr2). NetView displays the result from high memory to low memory,
regardless of the order in which the addresses are entered. This command provides the location of
modules at given memory locations; complements the DISPMOD function. DISPMOD provides the
location of a specific module.
DSIMODQY output consists of the following items:
• CSECT address in hexadecimal
• CSECT name
• Compile date
• PTF level, if any
• Load module name containing the CSECT
• Start of load module address
• Load module length
Usage
If a large address range is specified, this module uses a large amount of processor time. It can be
canceled using the RESET command.
Examples
Example: Output generated by DSIMODQY
DSIMODQY: CSECTS IN RANGE HIGH: 0000FFFF TO LOW: 00000000

CSECTADR: CSECTNME COMPDATE PTFLEVEL LOADNAME LOADADDR LOADLEN
0000FB78: DSIDRS 14.150 NV6Z°Ö}* DSIMNTEX 00008200 0000BE00
0000F748: DSIDPRS 14.150 NV6Z°Ö}* DSIMNTEX 00008200 0000BE00
0000E918: DSIDOS 14.150 NV6Z°Ö}* DSIMNTEX 00008200 0000BE00
0000BCE0: DSIDOPS 14.150 NV6Z °Ö DSIMNTEX 00008200 0000BE00
0000A720: DSIDCLS 14.150 NV6Z °Ö DSIMNTEX 00008200 0000BE00
00009468: DSICMDLD 14.150 NV6Z&\}* DSIMNTEX 00008200 0000BE00
00008200: NV63 10000 -------- DSIMNTEX 00008200 0000BE00
00008118: DSIZVLSR -------- -------- DSIZVLSR 00008118 000000E8
00007550: ABCDEFGH 01234 -------- DSIEBCDC 00007550 00000600
DSIMODQY: ENDED

DSIGTVBA
Format
DSIGTVBA
caller_id
DSIGTVBA ptrvarname
oper_id typevarname
lu_name
number
Purpose
The DSIGTVBA command returns address and type information about the Task Vector Block (TVB)
belonging to a NetView task. For information and offsets in the TVB, see the DSITVB macro in
SCNMMAC1.
Parameters
The DSIGTVBA syntax options are defined in the following list:
ptrvarname
This is the name of a variable into which DSIGTVBA places the EBCDIC (readable) hexadecimal
address of the target TVB control block. This parameter is the name of a variable and will usually be
inside the quotation marks when the command is invoked from a REXX procedure. The value returned
is always 8 character EBCDIC with leading zeros as needed. It is suitable for use with the REXX
STORAGE function or with the DSIGV2VR command.
caller_id
This is the operator ID of the task that is making the request. This is the default.
oper_id
This is the user name (OPID) for which a TVB address is required.
lu_name
This is the LU or terminal name associated with the task. This value is listed as the TERM value in the
LIST taskname command. For autotasks, the value is the same as OPID.
number
This indicates that the TVB you want is the one with that number in the internal chain of NetView
TVBs. Note that virtual OSTs (VOSTs) are not found on this chain. Your PPT task is always the value of
1 and your maintask is always the value of 0.
typevarname
This is the name of a variable into which DSIGTVBA places a token indicating the task type. The value
returned can be one of the following values:
AUT
autotask
DAU
distributed autotask
HCT
hardcopy task
IOT
internet operator
MNT
main task

NNT
NCCF to NCCF task
OPT
optional task
OST
normal (VTAM) operator
PPT
PPT task
VOST
virtual OST
Note: A VOST can be found only by specifying operid (begins with DSI#). The MNT can be found only
by specifying number.
Return codes
0
Success
100
Required input parameters are missing
104
Conversion error
112
OPID or LU name not found
116
Number specified is too large
120
Dictionary write error
Usage
The storage address is returned as 8 characters of hexadecimal data.
Examples
Example: Displaying information about a TVB
/*TEST: DSIGTVBA example */

'DSIGTVBA TVBPTR ' arg(1) 'WHATtype'
IF RC=0 THEN
DO;
say 'tvbptr='tvbptr
say 'type='whatType
luOFF = d2x(x2d(tvbptr) + 60)
say 'luname='storage(luOFF,8)
IDOFF = d2x(x2d(tvbptr) + 68)
say 'opid ='storage(IDOFF,8)
END;
ELSE
SAY 'RC was' RC
TEST 1 returns the following:
tvbptr=0001B6E0
type=PPT
luname=NTV7EPPT
opid =NTV7EPPT
TEST TOM returns the following:

tvbptr=00084080
type=OST
luname=NT7EL702
opid =TOM
For an inactive TVB, the first byte of OPID is either X'00' or X'40'.
DSIGV2VR
Format
DSIGV2VR
DSIGV2VR address offset length varname
CHR
HEX
DEC
BIT
Purpose
DSIGV2VR retrieves data from the storage defined by the address, offset, and length values. The data is
converted to the character representation appropriate for the character (CHR), hexadecimal (HEX),
decimal (DEC), or binary (BIT) option. The result is placed in the CLIST or REXX variable named varname.
Parameters
The DSIGV2VR syntax options are defined in the following list:
Address
Must be specified as a hexadecimal value.
Offset
Length
Varname
Will be resolved to the character string that results from CLIST substitution with an ampersand (&)
appended.
CHR
For this option, the data is moved, as it is, into the variable.
HEX
For this option, each byte of data is expanded to 2 characters in the range 0–9 and A–F.
DEC
For this option, the data is stored as a decimal number. The source data must be in the range of 1–4
bytes in length. Lengths of 1 and 3 denote unsigned decimal values. Lengths of 2 and 4 are
considered to be signed values.
BIT
For this option, each byte of data is expanded to 8 characters of either 1 or 0, denoting the binary
value of the data.
Return codes
8
Abend (recovered) accessing the data specified

100
Address parameter had greater than 8 characters
104
Address parameter had incorrect hexadecimal digits
108
Length parameter had incorrect hexadecimal digits
108
Dictionary update failure
112
Length parameter had incorrect hexadecimal digits
116
Data is not addressable (program check)
120
Required parameters missing
124
Offset parameter had greater than 8 characters
128
Offset parameter had incorrect hexadecimal digits
132
Conversion type had length other than 3
136
Conversion type was not CHR, DEC, HEX, or BIT
136
Character data length was longer than 255
136
Hexadecimal data was longer than 127
136
Bit data was longer than 31
136
Decimal data was more than 4 bytes
144
Hexadecimal data conversion error
144
Decimal data conversion error
666
Internal logic error — not a valid conversion type (See 136)
DSIGADHX
Format
DSIGADHX
DSIGADHX hexval1 hexval2 varname
MINUS
Purpose
DSIGADHX adds two literal hexadecimal values and stores in CLIST variable named varname. This is
useful for adding offset and address values together for use with DSISHWVR.

Parameters
The DSIGADHX syntax options are defined in the following list:
Hexval1
Must be specified as hexadecimal values.
Hexval2
Varname
Will be resolved to whatever character string results after CLIST substitution with an additional
ampersand (&) appended.
MINUS keyword
Is used for subtraction and must be placed after varname. A minus (-) character can be used, but it
conflicts with the NetView CLIST language continuation of a line function (not a problem in REXX).
Return codes
8
An abend (recovered) occurred accessing the data specified.
100
The hexval1 parameter contained greater than 8 characters.
104
The hexval1 parameter contained hexadecimal digits that are not valid.
108
The dictionary update failed.
120
The required parameters are missing.
124
The hexval2 parameter contained more than 8 characters
128
The hexval2 parameter contained hexadecimal digits that are not valid.
136
The hexadecimal data was longer than 127.
144
A hexadecimal data conversion error occurred.
DSISHWVR
Format
DSISHWVR
DSISHWVR address length
Purpose
DSISHWVR displays dump format data in hexadecimal and character on the screen.
Use DSISHWVR to gain diagnostic information in real time on NetView program. This is useful for
diagnostic analysis of control blocks, or as an output display from a diagnostic CLIST using DSIGV2VR to
retrieve address and length information.
Parameters
The following parameters apply:

• The DSISHWVR command must be run in a command procedure.
• The DSISHWVR syntax options are defined in the following list:
address
length
Return codes
This command issues diagnostic messages for input conditions that are not valid. If the storage is not
addressable, the display is either truncated or not produced. Recovery logic is used in all systems to avoid
abends and program checks.
WAIT timeout and storage limits

NetView can identify certain tasks that have waited for an event, but are not waiting for the messages
queues or task termination. In these cases, you can specify a time-out value that will cause the task to
abend with the MAXABEND value and condition forced, effectively logging the task off. The abend is used
to interrupt because normal event posting has been avoided by the command.
The described recovery is intended for use with NetView commands, such as modem configuration, which
cannot be interrupted during screen input, and to enable action to be taken if an operator leaves a
terminal unattended with the panel lock blocking messages.
The following fields are in a special table located by the address in MVTCPTPT.
MVTCPAWT (Word value)
The time in 1.048576 second units that any task can wait while not accepting messages before an
abend user 97 occurs. A decimal value of:
57 is 1 minute.
572 is 10 minutes.
3433 is one hour.
Other values can be computed and used. NetView adds the word value to the first 4 bytes of the
system clock at the time the task issues an internal-to-NetView DSIWAT to determine the expiration
time.
MVTCPASB (Word value)
The number of bytes of storage for which TVBGUSTR can increase while not accepting messages and
before an abend user 97 occurs.
MVTCPAOB (Byte of bits)
OI MVTCPAOB,X'80' Will indicate that an abend user 97 occurs if the task is posted to end, and the
task is not waiting on the terminate ECB, TVBTECB.
Assembler access to the table is shown in the following example:
DSICBS DSIMVT
L R2,MVTCPTPT
USING MVTCPARM,R2
The recovery occurs only if the fields are set to nonzero values and a NetView product module has issued
DSIWAT. The equivalent function is not available using the assembler DSIWAT macro.

Appendix B. Flows and control blocks
This appendix describes request unit flows and control blocks used by the NetView program.
Request unit flows

The diagrams in this section show the request/response unit flows between the NetView program, the
operator, and the VTAM program. If you have a problem with the NetView program, you can compare your
RU flows to these diagrams to determine the location of the error.
This section contains the request/response unit (RU) flow diagrams for the following tasks or
occurrences:
• Logging on to an operator station
• Starting the hardcopy device
• Starting cross-domain sessions (VTAM-VTAM)
• Starting a cross-domain session to support session monitor conversations
• Starting an operator terminal access facility (TAF) session
Figure 76 on page 571 is a diagram of the RU flow for an operator station logon.
Figure 76. RU Flow Diagram for Operator Station Logon

Figure 77 on page 572 is a diagram of the RU flow that occurs when you start a hardcopy device.
Figure 77. RU Flow Diagram for START Hardcopy Device
Figure 78 on page 573 is a diagram of the RU flow that occurs when you start a cross-domain session
(VTAM to VTAM).

Figure 78. RU Flow Diagram for Starting a Cross-Domain Session
Figure 79 on page 574 is a diagram of the RU flow that occurs when you start a cross-domain session
that supports session monitor conversations for continuous sessions.
Appendix B. Flows and control blocks 573

Figure 79. RU Flow Diagram for Starting a Cross-Domain Session to support session monitor conversations
for Continuous or Persistent Sessions
Figure 80 on page 575 is a diagram of the RU flow that occurs when an operator TAF session is started.

Figure 80. RU Flow Diagram for Operator TAF Session
Control blocks
This section describes NetView control blocks and related fields.
Control blocks used during Command Facility initialization

Figure 81 on page 576 shows control blocks used during command facility initialization. Descriptions of
fields for the various control blocks follow Figure 81 on page 576.

Figure 81. Control Blocks Used during Command Facility Initialization
The following list describes the fields that are found in the DSIMVT control block:
Field
Description
MVTDQT
Pointer to domain qualification table.
MVTDDT
Pointer to domain definition table.
MVTSCT
Pointer to system command table. A system command entry (SCE) is built for each CMDDEF
definition.
MVTTVB
Pointer to a chain of task vector blocks (TVBs). The number of TVBs equals the maximum number of
tasks (for example, OSTs, HCTs, NNTs) for this instance of the command facility.
MVTIND
One-byte indicator flag:
( 1... ....)
MVTINIT- Command facility initialization in progress
( .1.. ....)
MVTTERM- Command facility termination in progress
MVTACB
Pointer to the main task access method control block (ACB).
MVTTVBM
Pointer to the main task TVB.
The following list describes the fields that are found in the DSITVB control block.
Field
Description
TVBNEXT
Pointer to the next task vector block (TVB) on the TVB chain.

TVBTIB
Pointer to a task information block (TIB) that contains task control information. This field is obtained
when an operator logs on or starts a subtask.
TVBTCB
Pointer to the system TCB for this task.
TVBEXMSG
Pointer to an exception message if an error occurred.
The following list describes the fields that are found in the DSITIB control block.
Field
Description
TIBTVB
Pointer to the associated TVB.
TIBACB
Pointer to VTAM ACB that contains session initialization information.
Control blocks used during Operator Station logon (TVB)

Figure 82 on page 577 shows control blocks used during operator station logon. Descriptions of fields
for the various control blocks follow Figure 82 on page 577.
Figure 82. Control Blocks Used during Operator Station Logon
DSITVB control block fields

The following list describes the fields that are found in the DSITVB control block:
Field
Description
TVBTIB
Pointer to the OST TIB built during logon.
TVBTCB
Pointer to the system TCB for the OST. The TCB contains status information for the task.
TVBECB
The OST termination event control block (ECB). It shows whether end-of-task processing was posted.
TVBEXMSG
Pointer to an exception message if an error occurred.
TVBIND1

( 1... ....)
TVBREIN - Task reinstatement request (if the task abends, it is reinstated)
( .1.. ....)
TVBREDP - Task redispatch request (task is redispatched)
( ..1. ....)
TVBTERM - Task termination is in progress
( ...1 ....)
TVBDETCH - Task is to be detached
( .... 1...)
TVBATTCH - Task is to be attached
( .... .1..)
TVBCLSD - CLSDST PASS requested
( .... ..1.)
TVBLABT - LOGON
( .... ...1)
TVBSTART - START command issued for task
TVBIND2
( 1... ....)
TVBSTOP - STOP command issued
( .1.. ....)
TVBBYAP - Bypass authorization processing
( ..1. ....)
TVBCNRM - CLOSE NORMAL issued for this task
( ...1 ....)
TVBCIMD - CLOSE IMMEDIATE issued
( .... 1...)
TVBVCLOS - VTAM CLOSE ACB is required
( .... .1..)
TVBMOVE - MOVE command issued
( .... ..1.)
TVBCDMP - CLOSE DUMP issued
( .... ...1)
TVBABLOG - Task reinitialization after abend
TVBIND3
( 1... ....)
TVBACTV - Task is active
( .1.. ....)
TVBLOGN - LOGON in progress
( ..1. ....)
TVBLGOFF - LOGOFF in progress
( ...1 ....)
TVBAUTH - Operator ID is authorized
( .... 1...)
TVBRESET - Reset
( .... .1..)
TVBNAUTH - No authorization checking necessary

( .... ..1.)
TVBRCVAI - RECEIVE ANY issued
( .... ...1)
TVBINXIT - Processing in asynchronous IRB exits in MVS
TVBIND4
( 1... ....)
TVBPAUSE-PAUSE has been issued under this task
( .1.. ....)
TVBRCVRY - Recovery in progress
( ..1. ....)
TVBNWDVC - New device assigned
( ...1 ....)
TVBERIMM - Erase immediate message area after next input
( .... 1...)
TVBLGN - Main task LOGON exit entered
( .... .1..)
TVBETXR - Main task ETXR entered
( .... ..1.)
TVBSIMRQ - SIMLOGON required
( .... ...1)
TVBSTOPF - STOP FORCE issued for this task
TVBMTCOD
Character indicating the terminating module associated with TVBNTCOD.
TVBNTCOD
One-byte code identifying the location of the failure within the terminating module.
TVBLUNAM
VTAM LU name of the OST or operator ID if this is an autotask.
TVBOPID
Operator ID of the OST or autotask.
TVBZIND4
( .... .1..)
TVBAUTOO - Task is automated OST
( .... ..1.)
TVBAUTVS - Task starts with VTAM
( .... ...1)
TVBAUTVE - Task ends with VTAM
DSITIB control block fields

The following list describes the fields that are found in the DSITIB control block. The TIB contains task-
dependent data.
Field
Description
TIBTVB
Pointer to the TVB associated with this TIB
TIBACB
Pointer to VTAM ACB associated with this task

TIBNCCWB
Normal command CWB address
TIBEXSWB
SWB address for exit processing
TIBNPSWB
SWB address for normal processing
TIBEXPTR
Pointer to the TIB extension for the task
TIBOST control block fields

The following list describes the fields that are found in the TIBOST control block. The TIO contains OST
extension information.
Field
Description
TIOORRPL
VTAM RECEIVE RPL
TIOOSRPL
VTAM SEND RPL
TIONAUTH
Pointer to NetView-NetView authorization tables (NAT)
Control blocks used during Session Monitor initialization

Figure 83 on page 581 shows control blocks used during session monitor initialization. Descriptions of

Figure 83. Control Blocks Used during Session Monitor Initialization
AAUTGLOB control block fields

The following list describes the fields that are found in the AAUTGLOB control block:

Field
Description
GLBNAME
Control block ID: AAUTGLOB (8 bytes)
GLBFLAGS
Control flags (3 bytes):
( 1... ....)
All LU sessions traced
( .11. ....)
Reserved
( ...1 ....)
Session awareness function active
( .... 1...)
All SSCP sessions traced
( .... .111)
Reserved
( 1... ....)
Warm start flag
( .111 11..)
Reserved
( .... ..1.)
Accounting and availability measurement function active
( .... ...1)
Reserved
( 11.. ....)
Reserved
( ..1. ....)
DISABLE command was entered
( ...1 1111)
Reserved
GLBRTMP
Address of the RTM initialization parameter table (4 bytes)
GLBMSTP
Address of the MAP session definition table (4 bytes)
GLBPCTP
Address of the PCLASS definition table (4 bytes)
GLBKSID3
Default session parameter keep count (4 bytes)
GLBKSID4
Default primary trace keep count (4 bytes)
GLBKSID5
Default secondary trace keep count (4 bytes)
GLBKDPIU
Default discarded PIU keep count (4 bytes)
GLBKPSES
Default session keep count (4 bytes)
GLBBUFSZ
PIU buffer size (4 bytes)

GLBBUSZS
SAW buffer size (4 bytes)
GLBNTBUF
Number of PIU buffers (1 byte)
GLBNSBUF
Number of SAW buffers (1 byte)
GLBAMNAM
VTAM name (8 bytes)
GLBLUNAM
User-specified VTAM LU name (8 bytes)
GLBNETNA
Network name (8 bytes)
GLBNLDMD
Session monitor ID (4 bytes)
GLBSAPUN
Host subarea PU name (8 bytes)
GLBSSCP
SSCP name (8 bytes)
GLBSSCPA
SSCP subarea address (6 bytes)
GLBAMVER
Access method version number (1 byte)
GLBAMREL
Access method release number (1 byte)
GLBKMSTP
Address of KCLASS table (4 bytes)
GLBKCTP
Address of KCLASS definition table (4 bytes)
The following list describes the fields in the RTM initialization parameter table (pointed to by GLBRTMP):
Field
Description
GLBKPRTM
RTM keep wrap count (4 bytes)
GLBRTDEF
Default RTM definition (1 byte)
GLBBOUND
Default RTM bucket boundaries array of 2 byte fields (8 bytes)
GLBRFLG
RTM parameter flags (1 byte):
( 1... ....)
RTM function active
( .1.. ....)
RTM external log flag
( ..1. ....)
RTM is allowed to be displayed at secondary session end point LU
( ...1 1111)
Reserved

AAUTSTAT control block fields
The following list describes the fields that are found in the AAUTSTAT control block:
Field
Description
STATNAME
Control block ID: AAUTSTAT (8 bytes)
STATASBCOUNT
Number of active sessions being processed (4 bytes)
STATSSCPSSCP
Number of active SSCP-SSCP sessions (4 bytes)
STATSSCPPU
Number of active SSCP-PU sessions (4 bytes)
STATSSCPLU
Number of active SSCP-LU sessions (4 bytes)
STATLULU
Number of active LU-LU sessions (4 bytes)
STATRECORDQUE
Number of sessions queued for storage to VSAM (4 bytes)
MAPSESS table control block fields

The following list describes the fields found in the MAPSESS table for performance/keep class (pointed to
by GLBMSTP/GLBKMSTP):
Field
Description
MSTNAME
Control block ID: AAUTMST (8 bytes)
MSTNOENT
Number of table entries (4 bytes)
MSTENTRY
Array of 72 byte entries
The following list describes the fields found in the MST entry structure:
Field
Description
EPLUPNAM
Primary session end point name (8 bytes)
ESLUPNAM
Secondary session end point name (8 bytes)
MSTEPCLS
Performance/keep class name of this entry (8 bytes)
MSTEERN
Session ER number (1 byte)
MSTEVRN
Session VR number (1 byte)
MSTETPN
Session transmission priority number (1 byte)
MSTEFLAG
Control flags (1 byte):
( 1... ....)
ER number present

( .1.. ....)
VR number present
( ..1. ....)
TP
( ...1 1111)
Reserved
Performance class table control block fields

The following list describes the fields found in the performance class table (pointed to by GLBPCTP):
Field
Description
PCTNAME
Control block ID: AAUTPCT (8 bytes)
PCTNOENT
Number of performance class table (PCT) entries (4 bytes)
PCTMEM
Name of data set member that AAUTPCT is built from (8 bytes)
PCTOPER
ID of operator who loads PCT (8 bytes)
PCTOPDOM
Domain of the operator (8 bytes)
PCTTIME
Local time when PCT reloaded (8 bytes)
PCTENTRY
Array of 24-byte entries
The following list describes the fields found in the PCT entry structure:
Field
Description
PCTEPCLS
Performance class name (8 bytes).
PCTEOBJT
Objective response time. The default is 0 (2 bytes).
PCTEOBJP
Objective percent. The default is 0 (1 byte).
PCTEBNDS
Array of 2-byte entries of bucket boundaries. The default is 10, 20, 50, or 100 (8 bytes).
PCTEDEF
Response time monitor (RTM) definition. The default is X'F' (1 byte).
PCTEFLAG
Control indicators (1 byte):
( 1... ....)
Display RTM locally allowed. The default is 0.
( .111 1111)
Reserved.
KCLASS definition table control block fields

The following list describes the fields found in the KCLASS definition table (pointed to by GLBKCTP):
Field
Description

KCTNAME
Control block ID: AAUTKCT (8 bytes)
KCTNOENT
Number of keep class table (KCT) entries (4 bytes)
KCTMEM
Name of data set member that AAUTKCT is built from (8 bytes)
KCTOPER
ID of operator who loads KCT (8 bytes)
KCTOPDOM
Domain of the operator (8 bytes)
KCTTIME
Local time when KCT is reloaded (8 bytes)
KCTENTRY
Array of 16-byte entries
The following list describes the fields in the KCT entry structure:
Field
Description
KCTEKCLS
Keep class name (8 bytes).
KCTESAW
Session awareness filter (1 byte):
1
= Discard
2
= Keep
KCTEDASD
VSAM recording filter (1 byte):
X'00'
= Never record
X'04'
= Record normal end
X'08'
= Record if abnormal unbind occurs
X'10'
= Record if bind failure occurs
X'20'
= Record if initial failure occurs
X'40'
= Record if trace data exists
X'80'
= Record if RTM data exists
X'C0'
= Record if session has trace or RTM data
X'38'
= Record if session ends abnormally
X'FF'
= Always record
KCTEPIUS
PIU keep count (2 bytes).

Control blocks used during Hardware Monitor initialization
Figure 84 on page 587 shows control blocks used during hardware monitor initialization. Descriptions of
Figure 84. Control Blocks Used during Hardware Monitor Initialization
DSITIB control block fields

The following is the field found in the DSITIB control block:
Field
Description
TIBINT1
Pointer to BNJTDIR (main data services task control block)
BNJTDIR control block fields

The following list describes the fields that are found in the BNJTDIR control block:
Field
Description
DIRDWCP
Pointer to table for wrap card entries or 0
DIRDRCP
Pointer to table for ratio card entries or 0
DIRAFTP
Pointer to first alerts recording filter table or 0
DIRESFTP
Pointer to first events/statistics recording filter table or 0
DIROFTP
Pointer to first authorized operator filter table or 0
DIRVIEWP
Pointer to first viewing filter table or 0

DIRDSTF
Pointer to BNJTDSTF (DST flags table) or 0
DIRTBLP
Pointer to resource types table
DIRCDSXP
Pointer to BNJTCDSX (DST control block storage table) or 0
BNJTCDSX control block fields

The following list describes the fields that are found in the BNJTCDSX control block:
Field
Description
CDSXPTR(N)
Pointer to BNJTDSX control block or 0
CDSXAVAL(N)
= I if BNJTDSX(N) is currently in use
= A if BNJTDSX(N) is available for use by a DST request
= U if BNJTDSX(N) does not yet exist
BNJTDSTF control block fields

The following list describes the fields that are found in the BNJTDSTF control block:
Field
Description
DSTFLAG1
=1 if a PURGE *ALL is in progress
DSTFLAG2
=1 if a CTL initialization card was supplied, but was not valid
DSTFLAG3
=1 if a valid CTL initialization card was supplied
DSTBLFLG
=1 if SMF batch logging/reporting is enabled
DSTBRFLG
=1 if a valid REPORTS initialization card was supplied
Control blocks used during Status Monitor initialization

Figure 85 on page 589 shows control blocks used during status monitor initialization. Descriptions of

Figure 85. Control Blocks Used during Status Monitor Initialization
The following list describes the fields that are found in the CNMDMCT control block:
Field
Description
MCTVCH
Control block header (4 bytes)
MCTRCATP
Pointer to TVB for CNMTARCA task (4 bytes)
MCTMVTP
Pointer to DSIMVT (4 bytes)
MCTPVTP
Pointer to CNMDPVT (4 bytes)
MCTIMTP
Pointer to CNMDIMT (4 bytes)
MCTRDATP
Pointer to RDAT (4 bytes)
MCTVMID
STATMON main task name, for example CNM01VMT (8 bytes).
MCTTPNDP
Pointer to SPO TPEND routine (4 bytes)
MCTTPECB
Pointer to SPO TPEND ECB (4 bytes)
MCTVSECB
SPO VTAM send ECB (4 bytes)
MCTVRECB
SPO VTAM receive ECB (4 bytes)
MCTCTL1
Control byte 1 (1 byte):

( 1... ....)
MCTRCAUP-CNM01VMT active
( .1.. ....)
Reserved
( ..1. ....)
Reserved
( ...1 ....)
Reserved
( .... 1...)
Reserved
( .... .1..)
MCTBRWUP-CNM01BRW active
( .... ..1.)
Reserved
( .... ...1)
Reserved
MCTCTL3
( 1... ....)
MCTMONIT-'O MONIT' option was coded in DSICNM member
( .1.. ....)
Reserved
( ..1. ....)
Reserved
( ...1 ....)
Reserved
( .... 1...)
Reserved
( .... .1..)
Reserved
( .... ..1.)
Reserved
( .... ...1)
Reserved
MCTCTL4
( 1... ....)
MCTSTATC - Node status change occurred
( .1.. ....)
MCTNMON - If on, node monitoring was switched on with MONIT START, ALL; if off, node
monitoring was switched off with MONIT STOP, ALL
( ..1. ....)
Reserved
MCTMSGSP
SWB for DSIMOS invocations used by the VMT task (4 bytes)

Appendix C. RECFMS record formats
This appendix contains the format of RECFMS records 00 - 06 that are forwarded from NetView-
supported resources to the mainframe server.
RECFMS header
Bytes 00 through 13 are consistent for RECFMS record formats 00 through 05. These bytes form the
RECFMS header for each RECFMS record.
Table 179. RECFMS Header

Bytes Bits Description
00-02 Network services header: X'410384'
03-07 MS header
08-11 0-11 Block ID code
08-11 12-13 ID number in binary
12-13 Reserved
RECFMS 00
The RECFMS 00 record is created when an unsolicited alert is sent to the mainframe server. See “RECFMS
header” on page 591 for bytes 00 - 13, the RECFMS header.

14 0-1 "01" for format 1
14 2-7 Reserved
Bytes Bits Value Alert Type
15 0-3 X'1' Permanent error (PERM)
15 0-3 X'2' Temporary error (TEMP)
15 0-3 X'3' Performance (PERF)
15 0-3 X'4' Operational or procedural (PROC)
15 0-3 X'5' Customer application error (CUST)
15 0-3 X'6' User generated (USER)
15 0-3 X'7' SNA summary (SNA)
15 0-3 X'F' Unclassified

Bytes Bits Value Major Cause Code
15 4-7 X'1' Hardware or microcode
15 4-7 X'2' Software
15 4-7 X'3' Link connection
15 4-7 X'4' Protocol
15 4-7 X'5' Environment
15 4-7 X'6' Removable media
15 4-7 X'7' Either hardware or software
15 4-7 X'8' SNA logical
15 4-7 X'9' Operator of sending product
15 4-7 X'A' Media or hardware
15 4-7 X'B' Hardware
15 4-7 X'C' Microcode
15 4-7 X'F' Undetermined
15 4-7 X'11' User
15 4-7 X'13' Component offline
Bytes Value Minor Cause Code
16 X'01' Base processor
16 X'02' Service processor
16 X'03' Microcode (non-customer programmable)
16 X'04' Main storage
16 X'05' DASD drive
16 X'06' Printer
16 X'07' Card reader or card

punch
16 X'08' Tape drive
16 X'09' Keyboard
16 X'0A' Selector pen
16 X'0B' Magnetic stripe reader

16 X'0C' Display/printer
16 X'0D' Display unit
16 X'0E' Remote product (adjacent

link station)
16 X'0F' Internal power supply
16 X'10' I/O attached controller
16 X'11' Communication controller

scanner
16 X'12' Communication controller link adapter
16 X'13' Link adapter
16 X'14' Channel adapter
16 X'15' Loop adapter
16 X'16' Direct attach adapter
16 X'17' Miscellaneous adapter
16 X'18' Channel
16 X'19' Link (unknown owner)
16 X'1A' Link (common carrier)
16 X'1B' Link (customer)
16 X'1C' Loop (unknown owner)
16 X'1D' Loop (common carrier)
16 X'1E' Loop (customer)
16 X'1F' X.21 network
16 X'20' X.25 network
16 X'21' Local X.21 interface
Appendix C. RECFMS record formats 593

16 X'22' Local X.25 interface
16 X'23' Local modem
16 X'24' Remote modem
16 X'25' Local modem interface
16 X'26' Remote modem interface
16 X'27' Local probe
16 X'28' Remote probe
16 X'29' Local probe interface
16 X'2A' Remote probe interface
16 X'2B' Network connection
16 X'2C' IBM program SCP or major application
16 X'2D' IBM application program
16 X'2E' IBM access method
16 X'2F' Customer application program
16 X'30' IBM communication controller program

(T4 PU)
16 X'31' IBM control program
16 X'32' Remote modem interface

or remote product
16 X'33' Link or remote modem
16 X'34' SDLC format exception
16 X'35' BSC format exception
16 X'36' S/S format exception
16 X'37' SNA format exception

16 X'38' External power
16 X'39' Thermal
16 X'3A' Paper
16 X'3B' Tape
16 X'3C' DASD (removable media)
16 X'3D' Card
16 X'3E' Magnetic stripe card
16 X'3F' Negative SNA response
16 X'40' System definition error
16 X'41' Installation restriction
16 X'42' Adjacent link station

offline
16 X'43' Adjacent link station busy
16 X'44' Controller or device
16 X'45' Local probe or modem
16 X'46' Tape or drive
16 X'47' Card reader, card punch, or display/printer
16 X'48' Controller application

program
16 X'49' Keyboard or display
16 X'4A' Storage controller
16 X'4B' Channel or storage

controller
16 X'4C' Storage control unit or controller

16 X'4D' Controller
16 X'4E' DASD data or media or drive
16 X'4F' DASD data or media
16 X'50' Diskette
16 X'51' Diskette/drive
16 X'58' Application program
16 X'68' Magnetic stripe reader or coder
16 X'69' Check "bank"

reader
16 X'6A' Document feed mechanism
16 X'6B' Coin feed mechanism
16 X'6C' Envelope depository
16 X'80' Token-ring LAN error
16 X'81' CSMA/CD LAN error
16 X'FF' Undetermined
Bytes Description
17 Reserved
18 User action code. The hardware monitor

uses this, along with the block number,
to locate the following information:
• Alert description on alert displays

• Event description on alert displays
• Proper recommended action display
• Proper detail display
19 Reserved
After these fields, one or more RECFM4s can be appended. Text Vector, Detail Qualifier Vector, and
Name List Vector RECFM4s are retired (supported only for PUs not at the current level of SNA).

Text vector
Bytes Description
00 Vector length in binary
01 Vector type X'00'
02-n Text message
Detail qualifier vector

There can be multiple detail qualifier RECFM4s in the same RU.
Bytes Description
01 Vector type X'0D'
02-n Detail qualifiers; this information is shown on the hardware monitor event detail panel.
Name list vector

Bytes Description
01 Vector type X'0C'
02 If this value is X'02', the hierarchy name list in this RECFM4 is used with network names
supplied by higher levels of MS code.
03 Number of entries in the name list (up to five)
Bytes 04-n Identifier for non-NAU Failing beyond PU
00 Length of the resource name
01-m Resource name
Resource
from n Type: Meaning
to end Acronym
m+1 to m+4 ADAP Adapter
m+1 to m+4 ALA Alternative line attachment
m+1 to m+4 ALS Adjacent link stations
m+1 to m+4 BRDG LAN bridge
m+1 to BSC Binary synchronous link

m+4

Resource
to end Acronym
m+1 to m+4 CBUS CSMA/CD bus
m+1 to m+4 CHAN Channel
m+1 to m+4 COMC Communication controller
m+1 to m+4 CPU Host processor
m+1 CTF Customer transaction facility

to m+4
m+1 to m+4 CTRL Controller
m+1 to DCA Device cluster adapter

m+4
m+1 to m+4 DEV Device
m+1 to m+4 DISK Disk drive
m+1 to DSKT Diskette drive

m+4
m+1 to m+4 IOCU I/O control unit
m+1 to m+4 LAN Local area network
m+1 to m+4 LCTL Local controller
m+1 to m+4 LDEV Local device
m+1 LINK Communications link

to m+4
m+1 to m+4 LOOP Loop
m+1 to m+4 NETW Network
m+1 to m+4 PGM Program
m+1 to m+4 PROG Program
m+1 to m+4 RING Token-ring

Resource
to end Acronym
m+1 to m+4 SCF System control facility
m+1 to m+4 SCU Storage control unit
m+1 to m+4 STAT Terminal station on loop
m+1 to m+4 TAPE Magnetic tape drive
m+1 to m+4 TCU Tape controller
m+1 TTY Teletype

to m+4
m+1 to m+4 USER Human or programmed operator
m+1 to m+4 WKST Workstation
m+1 nnnn Machine type designator

to m+4
m+1 to m+4 xyzz If x = X'00' and y = X'00'

zz contains an encoded value
that can be translated into a
resource type, or a unique
type code within a block ID.
Null Vector
Bytes Description
00 X'00' (zero
length) indicates the end of RECFM4s.
RECFMS 01
RECFMS 01 records contain SDLC link test statistics. These test patterns are sent to a remote (link-
attached) resource. Statistics are then retrieved from the remote (link-attached) resource.

The format of RECFMS 01 records Systems Network Architecture Formats
Bytes 00 - 13 (the RECFMS header) “RECFMS header” on page 591

Bytes Description
14-15 Binary counter showing the number of times the secondary SDLC station has received an
SDLC TEST command with or without a valid frame check sequence (FCS).
16-17 Binary counter showing the number of times the secondary SDLC station has received an
SDLC TEST command with a valid FCS and has transmitted an SDLC test response.
RECFMS 02
RECFMS 02 records contain a summary of error statistics generated by certain resources.

Bytes Bits Summary Counter Validity Mask
14 0 1 =product counter valid
14 1 1 = communication adapter counter valid
14 2 1 = SNA negative response counter valid
14 3-7 Reserved
Bytes Description
15-16 Reserved
17-18 Binary counter showing product-detected hardware errors (internal)
19-20 Binary counter showing communication adapter errors (internal or external)
21-22 Binary counter showing SNA negative responses
RECFMS 03
RECFMS 03 records show error statistics generated by certain remote (link-attached) SNA resources. The
exact contents of the statistical counters depends on the device type. The RECFMS 03 records can
contain counter sets.

Bytes Value Communication Adapter Counter Set Number

14 X'01' Counter set 1

Bytes Value Communication Adapter Counter Set Number
Bytes Bits Communication Adapter Validity Mask 1
15 0 1 = counter 1 is valid
Bytes Bits Communication Adapter Validity Mask 2
Bytes Description
17 Reserved
Bytes Binary Counters

18 Binary counter 1

Bytes Binary Counters
19 Binary counter 2
20 Binary counter 3
21 Binary counter 4
22 Binary counter 5
23 Binary counter 6
24 Binary counter 7
25 Binary counter 8
26 Binary counter 9
27 Binary counter 10
Table 180. Counter Set Descriptions

Counter Sets 1 and 2 Set 4 Set 5 Set 6
1 Nonproductive Not initialized control I-frames transmitted I-packets transmitted
timeout
2 Idle timeout Command reject I-frames received I-packets received
3 Write retry Not initialized sense RR-frames RR-packets
transmitted transmitted
4 Overrun Bus-out parity-select RR-frames received RR-packets received
5 Underrun Bus-out parity-write RNR-frames RNR-packets
transmitted transmitted
6 Connection problem Internal parity-write RNR-frames received RNR-packets
received
7 FCS error Internal parity read REJ-frames INTERRUPT packets
control unit transmitted transmitted
8 Primary station abort Internal parity read REJ-frames received INTERRUPT packets
channel received
9 SDLC command reject Internal parity-cycle Retransmissions Connection request
steal
10 DCE error Data check Frames with FCS Connections
errors
11 Write timeout Data length check Receive side errors Reset indications
12 Status is not valid Connect received Receive side overruns Clear indications

Table 180. Counter Set Descriptions (continued)
Counter Sets 1 and 2 Set 4 Set 5 Set 6
13 Communication Disconnect received Transmit side Data packet with D-
adapter machine underruns bit transmitted
check
14 Data length received Data packet with D-
bit received
15 Connect parameter
error
16 Incorrect sequence
RECFMS 05
RECFMS 05 records provide engineering change (EC) level information about SNA controllers to the
mainframe server systems. The following devices provide EC level data when requested by the hardware
monitor.
See “RECFMS header” on page 591 for bytes 00 - 13, the RECFMS header.
Release level data (RECFMS 05)

The NetView program sends an REQMS 05 record to the controller to request release level information.
The response from the controller is sent to the NetView program in an RECFMS 05 record.
This data provides you with hexadecimal data that can be interpreted to describe the hardware,
microcode, or programming levels of SNA controllers.
The following products provide release level data to the NetView program:
• System/38
• 3104 Display Terminal
• 3174 Subsystem Control Unit
• 3274/6 Control Unit
• 3720 Communication Controller
• 3725 Communication Controller
• 3776/7 Communication Terminal
• 7426 Terminal Interface Unit
• 8775 Display Terminal
You can find 3174 configuration information in “RECFMS 05, 3174 configuration information” on page
604.
IBM System/38
Bytes Value Description
14 X'02' Constant X'02' to identify bytes 15-18
15 X'02' Planar level number
16 X'02' SCA-ROS card level
17 X'02' Periodic EC level
18 X'02' OU level

IBM 3104
Bytes Description
14 Part number of chip 1
RECFMS 05, 3174 configuration information

In response to a REQMS 05 request from the mainframe server, the 3174 returns two types of RECFMS
files to the mainframe server. The first type of response contains the 3174 configuration table
information. The second type of response contains information about microcode patches applied, RPQs
applied (with level information), and DFT load diskette installed (with level information). The second type
of response can require more than one RECFMS file to return all the information to the mainframe server.
After the 3174 receives an ACTPU from the mainframe server, it sends the configuration table in response
to the first REQMS 05 request.
Succeeding REQMS 05 requests retrieve the second type of response, while the continuation byte
indicates more data. If the continuation byte indicates no further data, the first type of response is sent at
the next request from the mainframe server.
This pattern of response to REQMS 05 requests continues while the physical unit is active.
See “RECFMS header” on page 591 for bytes 00 - 13, the RECFMS header.
Bytes Value Description

14 X'02' Always X'02' for 3174
15 X'01' Format 1 identifier
16 X'C1' Configuration level
Bytes Description
17 Release level
18 Suffix level
19-21 Maintenance level
Bytes Value 22 Control Unit Type
22 X'00' 3174
22 X'01' Reserved
22 X'02' Token-Ring Network 3270 Gateway
Bytes Description
23 Reserved
24 Reserved

Bytes Value 25 Alternate Keyboard Selection Configuration Question
25 X'01' 8K0808 Typewriter 132 = 1000
25 X'02' 8K0932 Typewriter 132 = 0100
25 X'04' 8K1038 Typewriter 132 = 0010

without Numeric Lock
25 X'08' 8K1038 Typewriter 132 = 0020

with Numeric Lock
25 X'10' 8K1158 Typewriter, 132 = 0001

87-key APL
without Numeric Lock
25 X'20' 8K1158 Typewriter, 132 = 0002

87-key APL
with Numeric Lock
Bytes Description
26 Reserved
Bytes Value 27 Miscellaneous Option Selection Configuration Question

27 X'04' Encrypt/Decrypt feature installed
27 X'08' Device input screen request 116 = 1
27 X'20' User-defined address 116 = 2
Bytes Value 28 Communication Interface Options Configuration Question

28 X'40' EMI Switched 317 = 2
28 X'10' X.21 Switched modem installed 101 = 6
28 X'04' X.21 non-switched modem installed 101 = 2
Bytes Value 29 Miscellaneous TP Options Configuration Question
29 X'80' External = 310 = 1

switched modem
(U.S. and Canada)
29 X'40' NRZI or internal clock 313 =1
29 X'20' Nonswitched line 317 and 101 = 1 or 2
29 X'10' RTS from STX to EOT 340 = 2
29 X'08' SNBU 317 = 1

Bytes Value 29 Miscellaneous TP Options Configuration Question
29 X'04' Reserved
29 X'02' Permanent RTS 340 = 1
29 X'01' Reserved
Bytes Description Configuration Question

30, 31 Control unit address 104
32, 33 Control unit upper limit 104/105
34 Channel Configuration
Bytes Value Adapter Question
Information
34 X'00' Burst size 002 225 = 0
34 X'10' Burst size 004 225 = 1
34 X'20' Burst size 008 225 = 2
34 X'30' Burst size 016 225 = 3
34 X'40' Burst size 032 225 = 4
34 X'50' Burst size 064 225 = 5
34 X'60' Burst size 256 225 = 6
34 X'70' Burst size 512 225 = 7
X'02' Interlocked high-speed transfer

34 224 = 2
35 Channel Configuration
Bytes Value Adapter Question
Attention Value
35 X'0A' (SNA) 10 - 99 milliseconds 223

-X'63'

36 Channel
Adapter Configuration
Bytes Value Support of Question
Command Retry
36 X'01' Command retry 222 = 1
Bytes Value 37 Optional Code Selections Configuration Question
37 X'80' MSR, 10 or 63 characters 141 = C or D
37 X'40' Auto Entry MSR, 141 = B or D

10 or 63 characters
37 X'08' Reserved
37 X'04' Reserved
37 X'02' Between bracket 213 = 1

sharing (BBS)
Bytes Description
38, 39 Reserved
40, 41 Control unit model number
42 Reserved for host-attach mode
Bytes Value 43 Host-Attach Mode Configuration Question
43 X'A2' X.21 Switched 101 = 6
43 X'62' X.25 101 = 3
43 X'21' SNA channel 101 = 5
43 X'22' SDLC 101 = 2
43 X'12' BSC 101 = 1
43 X'11' Non-SNA channel 101 = 4
43 X'2A' Token-Ring 101 = 7

Network
43 X'02' Remote
43 X'01' Local

Bytes Value 44 Model Type Configuration Question
44 X'80' 3174 Model 1L, 1R, 2R, and 3R 100 = 0XX
44 X'40' 3174 Model 51R, 52R, and 53R 100 = 5XX
44 X'20' 3174 Model 81R and 82R 100 = 8XX
Bytes Value 45 Model Type Configuration Question

45 X'01' 01X 100 = 01L or 01R
45 X'02' 02X 100 = 02R
45 X'03' 03X 100 = 03R
45 X'51' 51X 100 = 51R
45 X'52' 52X 100 = 52R
45 X'53' 53X 100 = 53R
45 X'81' 81X 100 = 81R
45 X'82' 82X 100 = 82R
Bytes Value 46 Language Code Configuration Question
46 X'01' EBCDIC (U.S. English) 121
46 X'02' ASCII (U.S. English) 121
46 X'03' Austrian/German 121
46 X'04' Belgian 121
46 X'05' Brazilian 121
46 X'06' Reserved 121
46 X'07' Danish 121
46 X'09' Finnish/Swedish 121
46 X'0A' Reserved 121
46 X'0B' Reserved 121
46 X'0C' Reserved 121
46 X'0D' Reserved 121
46 X'0E' International 121

46 X'0F' Italian 121
46 X'10' Japanese (English) 121
46 X'13' Spanish 121
46 X'15' Spanish-speaking 121
46 X'16' English (UK) 121
46 X'17' Norwegian 121
46 X'18' Finnish/Swedish 121
46 X'19' English (WT) 121
46 X'1A' Reserved 121
46 X'1B' Reserved 121
46 X'1C' Portuguese (alternate) 121
46 X'1D' Canadian Bilingual 121
46 X'1E' French Azerty 105 121
46 X'1F' Reserved 121
46 X'21' ASCII International 121
46 X'22' ASCII 8 121
46 X'23' Cyrillic 121
46 X'24' Greek 121
46 X'25' Icelandic 121
46 X'26' ROECE 121

46 X'27' Turkish 121
46 X'28' Yugoslavic 121
46 X'29' New Swiss French 121
46 X'2A' New Swiss German 121
46 X'2B' New Belgian 121
46 X'2C' Reserved 121
46 X'2D' Reserved 121
46 X'2E' Thai 121
46 X'2F' Reserved 121
Bytes Description
47-53 Reserved
Bytes Value 54 Color Display Controller Options Configuration Question

54 X'02' Decompression feature 165 = 1
54 X'01' Reserved
Bytes Description
55 Reserved

56-64 Unique machine identifier 108
Bytes Description
65-76 Reserved
Bytes Value 77 X.21 Switched Key Support SDLC Configuration Question

77 X'80' Direct key support for all terminals 362
77 X'40' DIAL key support for all terminals 362
77 X'20' LOCAL/COMM key support 362
77 X'10' DISC key support for all terminals 362
77 X'08' EXT key support for all terminals 362
77 X'04' DISC after second entry for all terminals 362
77 X'02' DCE support for direct call 362

Bytes Value 77 X.21 Switched Key Support SDLC Configuration Question
77 X'01' DCE support for address call 362
Bytes Value 77 X.21 Switched Key Support BSC Configuration Question
77 X'01' BSC WACK support present 176 = 1

78 X.21 and X.25 SDLC, number of retries when a number can 360/451
be dialed again
Bytes Value 79 X.21 Switched, Seconds Between Configuration Question

Entries-361
79 X'00' 0.0 361
79 X'0C' 0.1 361
79 X'18' 0.2 361
79 X'24' 0.3 361
79 X'30' 0.4 361
79 X'3C' 0.5 361
79 X'48' 0.6 361
79 X'54' 0.7 361
79 X'60' 0.8 361
79 X'6C' 0.9 361
79 X'78' 1.0 361
79 X'84' 1.1 361
79 X'90' 1.2 361
79 X'9C' 1.3 361
79 X'A8' 1.4 361
79 X'B4' 1.5 361
79 X'C0' 1.6 361
79 X'CC' 1.7 361
79 X'D8' 1.8 361
79 X'E4' 1.9 361
79 X'F0' 2.0 361
Bytes Description
80-98 Reserved
Bytes Value 99 File Present Indicator

99 X'08' Reserved

Bytes Value 99 File Present Indicator
99 X'04' Reserved
99 X'02' Diskette 2 is present
99 X'01' Diskette 1 is present
Bytes Description
100-117 Reserved
Bytes Value 118 Control Unit Identifier

118 X'00' 3274
118 X'01' 3174

119-121 XID 215
Bytes Value Description Configuration Question

122 X'80' DFT support
122 X'40' Reserved
122 X'20' Load diskette dump completed
122 X'10' MIS has been configured 117
122 X'08' Reserved
123-125 Reserved
126 Nonstandard window size for X.25 435
Bytes Value 127 Modifiable Keyboard Selection Configuration Question
127 X'08' IBM-enhanced 136

keyboard
127 X'04' Data entry keyboard 136
127 X'02' APL keyboard 136
127 X'01' Typewriter keyboard 136
Bytes Description
128-140 Reserved
Bytes Value 141 Attribute Select Keyboards Configuration Question
141 X'02' With numeric lock 166
141 X'01' Without numeric lock

Bytes Description
142-153 Reserved
Bytes Value 154 Response to Alert Function for SDLC, Configuration Question
X.25, and X.21 Switched
154 X'00' No alert function 220 = 0
154 X'03' Alert function with 220 = 3

test alert (all ports)

test alert (port 0)

no test alert
Bytes Value 155 X.25 Nonstandard Packed Size and Configuration Question
Modifiable Keypad Overlay
155 X'30' 512 bytes non- 434 = 3

standard pack size
155 X'20' 256 bytes non- 434 = 2

standard pack size
155 X'10' 128 bytes non- 434 =1

standard pack size
155 X'02' Modifiable keypad 138 = 2

with PF keys
155 X'01' Modifiable keypad, 138 = 1

data entry type
Bytes Description
156-173 Reserved
Bytes Value 174 Modifiable Keyboard Configuration Question
174 X'00' Modifiable keyboard 137

not specified
174 X'08' Modifiable 137

keyboard ID D

Bytes Value 174 Modifiable Keyboard Configuration Question

keyboard ID C

keyboard ID B

keyboard ID A

175 DFT options utility field 173
Bytes Description
176 Reserved

177 Number of entries in the port address table 117
Bytes Description
178 Reserved
179 Reserved
Bytes Value 180 Embedded RPQ and Miscellaneous Configuration Question

Features
180 X'80' Clear key (formerly RPQ 8K0978) 125
180 X'40' Unsupported control codes 125
180 X'20' Clicker option 125
180 X'08' PS load altered screen 125
180 X'04' PC file transfer aid 125
180 X'02' Background alarm 125
180 X'01' Deferred keystroking (remote SNA only) 125
Bytes Description
181 Reserved
Bytes Value 182 X.25 Incoming Calls Options Configuration Question

182 X'80' Validate calling DTE address 420
182 X'60' Accepts calls with reverse-charge facility 420
not requested

Bytes Value 182 X.25 Incoming Calls Options Configuration Question
equal to reverse-charge requested
182 X'10' Accepts packets that include the negotiate 420
packet size facility
182 X'08' Accept packets that include the negotiate 420
window size facility
182 X'04' Validate CID on incoming packet 420
182 X'02' Negotiate throughput class 420
Bytes Value 183 X.25 Outgoing Call Options Configuration Question

183 X'80' Supply calling DTE address in call request 421
packet
183 X'40' Request no reverse-charge through 421
reverse-charge facility field
183 X'20' Request reverse-charge through reverse- 421
charge facility field
183 X'10' Include packet size facility field in the call 421
request packet
183 X'08' Include window size facility field in the call 421
request packet
183 X'04' Include the connection identifier in the call 421
request packet
183 X'02' Include throughput class facility in the call 421
request packet
183 X'01' Reversed 421
Bytes Value 184 Packet and Window Sizes Configuration Question
184 X'30' 512-byte packet size 430 =3
184 X'20' 64-byte 430 =0

X'10' packet size
when both bytes are off
184 X'01' Modulo 128 431 = 1
184 X'01' Modulo 8 431 = 0

when bit is off

185 X.25 window size 432
Bytes Value 186 X.25 K-maximum Out and Configuration Question

Throughput Class
186 X'3X' 75 bps 440 = 3
186 X'4X' 150 bps 440 = 4
186 X'5X' 300 bps 440 = 5
186 X'6X' 600 bps 440 = 6
186 X'7X' 1200 bps 440 = 7
186 X'8X' 2400 bps 440 = 8
186 X'9X' 4800 bps 440 = 9
186 X'AX' 9600 bps 440 = A
186 X'BX' 19200 bps 440 = B
186 X'CX' 48000 bps 400 = C
187 X.25 closed user group (CUG) 441
188-189 X.25 recognized private 442

operating agency (RPOA)
Bytes Value 190 X.25 Keyboard Support Configuration Question

190 X'80' X.25 DISC (supported per bit 4 definition) 409
190 X'40' X.25 DISC (supported on port 0) 409
190 X'20' X.25 LOCAL and COMM keys (bit 4 409
definition)
190 X'10' X.25 LOCAL and COMM keys 409
190 X'08' X.25 keys supported on all ports 409
190 X'04' Display only mainframe server network 409
(DTE) address fields
190 X'02' DISC (SVC) or LOCAL (PVC) key performs 409
disconnect or local mode operation

Bytes Value 191 Network Type Configuration Question
191 X'00' Connection is CCITT 400 = 0
191 X'01' Connection is DATANET-1 400 = 1
191 X'02' Connection is to UKPSS or TELENET 400 = 2
Bytes Description
192-207 RPQ parameter list
208-223 Reserved
Bytes Value 224 Response Time Monitor, Part 1 Configuration Question

No RTM; RTM configured with no
224 X'00' 127 = 1Y
mainframe server support
224 X'01' Display logs on 127 = 2Y

port 0 only RTM
configured with
no mainframe
server support

all ports RTM
configured with
no mainframe
server support
224 X'03' No display of logs 127 = 4Y

on subsystem RTM
configured with
mainframe server
support

port 0 only RTM
configured with
mainframe server
support

all ports RTM
configured with
mainframe server
support
225 X'01' Time until first 127 = X1

character is displayed
on the screen

225 X'02' Time until keyboard 127 = X2

is available for input
225 X'03' Time until receipt 127 = X3

of CD/EB
225 X'04' Time until last 127 = X4

character
Bytes Description
226-233 RTM time boundary
Bytes Value 234 SNA RTM Option Parameters Configuration Question

234 X'80' RTM enabled 128
234 X'40' Unsolicited on session end 128
234 X'20' Unsolicited on counter overflow 128
234 X'10' RTM alerts enabled 128
Bytes Value 235 Circuit Type for X.25 Configuration Question

235 X'80' Reserved
235 X'40' Reserved
235 X'20' Reserved
235 X'10' Qualified logical link control (QLLC) or 403 = 1 or 403 = 0
physical service header (PSH) control
235 X'08' Two-way call 401 = 4
235 X'04' Outgoing call only 401 = 3
235 X'02' Incoming call only 401 = 2
235 X'01' Permanent virtual circuit 401 = 1
236-243 Host DTE (network address) 423
244-251 Local DTE (network address) 424
252-253 Local channel identifier (X.25) 402
Bytes Value 254-255 Link Level Transmit Timeout Configuration Question

254-255 X'25' 37 450
254-255 X'00' 00 450

Bytes Value 254-255 Link Level Transmit Timeout Configuration Question
254-255 X'10' 16 450
254-255 X'20' 32 450
254-255 X'30' 48 450
254-255 X'40' 64 450
RECFMS 05 for the 3174: RPQ, patch, and DFT information

See “RECFMS header” on page 591 for bytes 00 to 13.
Symbols used for RPQ information are as follows:
Symbol
Meaning
ab
Origin of the RPQ a = one number b = one letter
cccc
4-digit RPQ number
e
1-digit RPQ suffix
Symbols used for patch information are as follows:
Symbol
Meaning
dd
decimal digits
Product ID
X'FF' indicates that bytes X'01'-X'17' should be ignored
Table 181. RECFMS 05 (Format 2)
Byte Value Meaning
14 X'02' Always X'02' for 3174
15 X'02' Format 2 identifier
16-20 abcccce RPQ 1 information
21-22 Reserved
28-29 Reserved
35-36 Reserved

Table 181. RECFMS 05 (Format 2) (continued)
Byte Value Meaning
42-43 Reserved
49-50 Reserved
56-57 Reserved
63-64 Reserved
70-71 Reserved
77-78 Reserved
84-85 Reserved
86-88 dddddd Patch 1 information

Byte Value Meaning
176 dd DFT 1 product ID

Byte Value Meaning
176-178 dddd DFT 1 product number
179 dd DFT 1 release level
180 dd DFT 1 maintenance level
181-185 dddddddddd DFT 1 RPQ information
186-193 Reserved
204-211 Reserved
222-229 Reserved
DFT 4 RPQ information

235-239 dddddddddd

Byte Value Meaning
240-247 Reserved
248 X'00' or X'FF'X'00' = Continue sending Continuation character
format 2X'FF' = No more format 2 data
IBM 3274
3274 configurations C and D, besides providing EC level information, also provide a complete copy of the
configuration table.
Bytes Value 14 Descriptor
14 X'00' EC level data only
14 X'01' EC level data and configuration table
Engineering Change Level Data
Bytes Description
15-30 Installed patch ID values
31 Number of RPQs installed on 3274
32 Reserved
33 RPQ 1 ID
38 RPQ 2 ID
43 RPQ 3 ID
48-50 Control values for suffix numbers
51-60 Reserved
61 Feature disk level
62 Feature disk suffix
63 System disk level
64 System disk suffix
65 Language disk level
66 Language disk suffix
67 RPQ 1 disk level
68 RPQ 1 disk suffix
69 RPQ 2 disk level
71 RPQ 3 disk level

Engineering change level and configuration table
Bytes Value 15 Diskette Type

15 X'C3' Copy RPQ
15 X'C6' Font
15 X'D3' Language
15 X'D4' Feature
15 X'E2' System
15 X'E4' Dump
15 X'E6' Load
15 X'E8' Encrypt/decrypt
15 X'E9' Zap
Bytes Description
16 Feature level (see bytes 127, 128)
17 System level (see bytes 129, 130)
18 Language level (see bytes 131, 132)
Bytes Value 19 Interface Adapter

19 X'01' LCA (Model 1A)
19 X'02' LHA (Model 1B)
19 X'04' HPCA/CCA (Model 1C)
19 X'08' SLHA (Model 1D)
19 X'21' LCA (Model 41A)
19 X'24' HPCA/CCA (Model 41C)
19 X'28' SLHA (Model 41D)
19 X'41' LCA (Models 21A and 31D)
19 X'42' LHA (Models 21B)
19 X'44' HPCA/CCA (Models 21C and 31C)
19 X'48' SLHA (Models 21D and 31D)
19 X'84' (Models 51C and 52C)
19 X'A4' (Model 61C)
Bytes Description
20 Channel address (for models 1A, 21A, 31A, and 41A)
Bytes Value 21 Flags

21 X'00' Not models 1A, 21A, 31A, and 41A
21 X'01' Models 1A, 21A, 31A, and 41A

Bytes Value 22 Line Code (C Models)
22 X'01' EBCDIC
22 X'02' ASCII
Bytes Value 23 Line Control

23 X'01' BSC
23 X'02' SDLC
Bytes Description
24 BSC polling address
25 BSC or SDLC selection address
Bytes Value 26 Miscellaneous Options

26 X'01' CCA
26 X'02' HPCA
26 X'04' Encrypt/decrypt
26 X'08' Requested panel to assign ports individually
26 X'10' Printer polled from mainframe server
Bytes Value 27 Remote Attachments (C Models)

27 X'00' CCITT V.35 or external modem interface
27 X'01' Modem that can support a Wrap test
27 X'02' DDS adapter
27 X'04' X.21 leased line
27 X'08' Integrated modem with more than 1200 bps
27 X'10' X.21 switched line
27 X'20' Loop
27 X'40' Switched External Modem Interface (EMI)
27 X'80' 1200 bps nonswitched Integrated Modem (IM) (Model 51C only)
Bytes Value 28 TP Options (C Models)

28 X'01' Omit answer tone
28 X'02' Point-to-point
28 X'04' Half speed
28 X'08' Select standby
28 X'10' Special request to send
28 X'20' Nonswitched line
28 X'40' NRZI or internal clock
28 X'80' WT DCE switched network

Bytes Description
29 Control storage base
30-33 Control storage addition
Bytes Value 34 Storage Extension

34 X'01' Not installed
34 X'02' Model 1x processor
34 X'40' Model 41x or 61C processor
34 X'80' Model 21x, 31x or 51x processor
Bytes Value 35 Request to Send

35 X'01' RTS installed
Bytes Value 36 Optional Code Selection

36 X'01' 3289 text print control
36 X'02' Between bracket sharing
36 X'04' Personal computer
36 X'08' Entry assist
36 X'80' 1063 magnetic reader
36 X'80' 1063 auto entry magnetic reader

37 X'01' SCS printer support not present
37 X'02' Host loadable PAM not present
37 X'04' Local copy not present
37 X'10' Magnetic reader not present
Bytes Value 38 Type B Driver Or Receiver

38 X'00' None
38 X'01' One card
38 X'02' Two cards
38 X'03' Three cards
38 X'04' Four cards
Bytes Value 39 Type A Driver Or Receiver

39 X'01' One card
39 X'02' Two cards
39 X'03' Three cards
39 X'04' Four cards

Bytes Description
40 Total category B terminals
41 Total category A terminals
42 Total all terminals
Bytes Value 43 Modem and Connection Option

43 X'01' High speed loop operation
Bytes Description
44 EBCDIC BSC control unit ID
45 Language type
46 Extended function store response
47 'A' DCB count
48 Total DCB count
49 Print authorization matrix entry count
Bytes Value 50 Keyboards

50 X'01' Typewriter
50 X'02' Data entry
50 X'04' Data entry II
50 X'08' APL
50 X'10' TEXT
Bytes Description
51 Extended DCB count
Bytes Value 52 Color and Programmed Symbols

52 X'01' Color displays attached
52 X'02' Programmed symbols feature
Bytes Value 53 Structured Fields And Decompression

53 X'01' Structured field and attribute processing
53 X'02' Decompression feature
Bytes Description
54 X.21 switched retry timing response
55-56 Validation number
57-75 Reserved

Bytes Value 76 SDLC X.21 Switched
76 X'01' DCE support address call
76 X'02' DCE support direct call
76 X'04' Reserved
76 X'08' External key support on all terminals
76 X'10' Disconnect key support on all terminals
76 X'20' Comm/local key support on all terminals
76 X'40' Dial key support on all terminals
76 X'80' Direct key support on all terminals
Bytes Value 76 BSC

76 X'01' WACK support
Bytes Description
77 Number of redialing attempts allowed
Bytes Value 78 Ring Time (X.21 Switched)

78 X'01' 0.1 seconds
78 X'80' 12.8 seconds
Bytes Description
79 Reserved
Bytes Value 80/1200 bps Integrated Modem

80 X'08' Feature 5508
80 X'10' Feature 5507
80 X'20' Feature 5502
80 X'40' Feature 5501
80 X'80' Feature 5500
Bytes Description
81-96 Patch ID values
97 Number of RPQs installed

Bytes Description
98 Reserved
Bytes Bits 99-103 EC Level of First RPQ Installed Below Configuration D

99-103 0-11 Three-digit EC level
99-103 12-39 7-digit part number
Bytes Bits 99-103 EC Level of First RPQ Installed Configuration D and Above
99-103 0-15 Last four digits of RPQ number
99-103 16-39 Six-digit EC level
Bytes Description
104-108 EC level of second RPQ installed
109-113 EC level of third RPQ installed
114 Feature diskette expected suffix
115 System diskette expected suffix
116 Language diskette expected suffix
117 Reserved
118-120 PU ID number
Bytes Value 121 Configuration Support

121 X'08' TCA device configured, load diskette not required
121 X'10' Multiple interactive screen support
121 X'20' Dump complete (3290)
121 X'40' Transfer of operational load module to load diskette
121 X'80' 3290 support
Bytes Value 122 Flag

122 X'C3' Diskette is a copy generated by copy utility.
Bytes Description
123-126 Reserved
127 Feature diskette level
128 Feature diskette suffix
129 System diskette level
130 System diskette suffix
131 Language diskette level
Bytes Bits Value 133-134 EC and Suffix Levels of First RPQ Installed
133-134 0 X'0' EC and suffix levels

Bytes Bits Value 133-134 EC and Suffix Levels of First RPQ Installed
133-134 0 X'1' The following conditions apply:
X'8100'
Configuration level A
X'8200'
Configuration level B
X'8400'
Configuration level C
X'8800'
Configuration level T
X'C000'
Configuration level D or above
Bytes Description
135-136 EC and suffix levels of second RPQ installed (same conditions as bytes 99-103)
137-138 EC and suffix levels of third RPQ installed (same conditions as bytes 99-103)
Bytes Value 139 Magnetic Reader Type

139 X'00' None
139 X'01' Numeric (3270 compatible)
139 X'02' Alphanumeric (auto-entry for nondisplay data)
139 X'03' Alphanumeric (auto-entry for all data)
Bytes Value 140/3279 Attribute Selection Keyboards

140 X'01' Attribute selection keyboard
140 X'02' Numeric lock and advanced function keyboard
Bytes Description
141-152 Reserved
Bytes Value 153 Alert

153 X'00' No alert function requested
153 X'01' Alert function without test alert capability
153 X'02' Alert function with test alert on port 0
153 X'03' Alert function with test alert on all ports
Bytes Description
154-158 Reserved
159 EC level for load diskette
160 Suffix level for load diskette
161-165 ID for 3290 RPQ
166 First port with multiple interactive screen capability

Bytes Description
167 Number of ports with two LTERM addresses
168 Number of ports with three LTERM addresses
169 Number of ports with four LTERM addresses
170 Number of ports with five LTERM addresses
171-172 3290 RPQ options
173 Reserved
Bytes Value 174 3290 Features and Functions
174 X'80' Enable 3290 local copy format controls
174 X'40' Auto form feed before local copy
174 X'20' Auto form feed after

local copy
Bytes Description
175 Reserved
176 Number of primary local devices defined on 3274
177 Number of logical terminal extensions
Bytes Value 178 Keypad Selection

178 X'00' Default keyboard (based on national language)
178 X'01' Program function keypad
179 X'20' Clicker selection
179 X'40' Unsupported control code translation
179 X'80' Dual-function

clear key
Bytes Description
180-190 Reserved
191-206 RPQ parameter list
207-225 Category A port assignment table (32 possible ports)

Bytes Description
226-270 Reserved
IBM 3276
Bytes Description
14 Implementation-defined data describing hardware, microcode, and program levels. 3276s
have 48 fields. Each field is 4 bytes in length, is an unsigned packed decimal, and contains
a ROS chip 7-digit part number.
IBM 360X
EC level data is provided by 3601 and 3602 devices.
Bytes Description
14 6-digit current EC level of installed microcode plus a 2-digit patch level
IBM 3720
Bytes Description
14-23 Microcode level
24 Control program type and level
25-70 Customer identification
71-74 3720
75-76 01/02/11/12
77-84 Machine serial number
Bytes Description
85 Microcode historical data
• Last microcode fix (MCF)
Applied: MCF ID (8 characters) application date (3 characters)
• Number of most recently applied patches (binary)
• Most recently applied patches: 16 entries, each entry contains
– Patch ID (8 characters)
– Status:
X'01'APPLIED
X'02' NONAPPLIED
X'04' IN PROGRESS
X'08' BAD CHECKSUM
IBM 3725 Communication Controller
Bytes Description
14 10-digit current EC level

of installed microcode

Bytes Description
24 Control program type and level
25 Customer identification
71 Machine type
75 Model identification
77-84 Machine serial number field
77-80 Machine serial number
81-84 Reserved
Bytes 85-255 ZAP Historical Data

85 Number of entries in the table
86-255 ZAP historical data table. This table can contain up to 10 entries. Each entry contains:
• 12 bytes for the ZAP ID
• 1 byte for the status
X'01' NON APPLIED
X'02' APPLIED
X'04' UNDEFINED
X'08' BAD CHECKSUM
• 3 bytes for the application date
Zeros pad the storage locations between the last entry and offset 255.
IBM 3776/7 MLU
Bytes Description
14 6-digit current EC level

of installed microcode
IBM 4701
Bytes Description
14 6-digit current EC level of installed microcode plus a 2-digit patch level
IBM 7426
Bytes Description
14 8-digit load module EC number (EBCDIC)
22 ROS Module-0 Chip-1 P/N (packed decimal)

Bytes Description
Setup Data for Host System
Bytes Description
86 SDLC station address
87 Downstream load data set name
95 Loop carrier speed and loop data

speed (Model 1)
Bytes Bits 96 Line Type

96 0-3 Link line type (Model 2)
96 4-7 Reserved
Bytes Bits 97 Line Type

97 0-3 Reserved
97 4-7 X'1' NRZI (Model 2) X'2' NRZ
Bytes Description
98-101 Reserved
Setup Data for Port 0

102 0-3 Device type

102 4-7 Line type
103 0-3 Parity and stop bits
103 4-7 Line speed
104 0-3 ENTER key definition
104 4-7 Target printer for local copy
Bytes Description
105-109 Reserved

110 0-3 Device type
110 4-7 Line type
111 4-7 Line speed
Bytes Description
113-127 Reserved

118 0-3 Device type
118 4-7 Line type
119 4-7 Line speed
Bytes Description
121-125 Reserved

126 0-3 Device type
126 4-7 Line type
127 4-7 Line speed

Bytes Description
129-165 Reserved
MCPC Log Area
Bytes Value 166 Error Code

166 X'01' Storage parity error
166 X'02' DMA parity check
166 X'03' MEF parity check
166 X'41' Program check
166 X'42' MEF write protect check
166 X'43' PIRR interrupt
166 X'81' MCPC bit 0
166 X'82' MCPC bit 1
IBM 8775
Bytes Description
14 8-digit hardware part number of the ROS module located at X'8000' and shown in the
format 4421XXXC where XXX is a variable

Appendix D. DSINDEF data set format
If the status monitor information is not in the right column when you look at the status monitor display,
looking at the DSINDEF file can be helpful. The CNMDPREC control block provides mapping of DSINDEF.
CNMDPREC is also known as the NetView status monitor run parameters input record.
DSINDEF provides the VTAM node control application input record containing the run parameters to the
NetView status monitor task. DSINDEF is built by the CNMNDEF (CNMSJ007) job, and resides on the
DSIPARM data set.
Each record in DSINDEF is 80 bytes long. Each record provides information about:
• Major nodes of the network
• Minor nodes of the network
• Comments
The records in DSINDEF must adhere to a hierarchy in which minor nodes follow major nodes; for
example, an NCP name followed by a LINE, followed by PUs, and then LUs.
Note: The status monitor accepts data created by CNMNDEF but does not support any logic to verify this
data. Therefore, take care when modifying or viewing this data to maintain the correct values for the
entries specified in DSINDEF.
The layout of the CNMDPREC control block is shown in Table 182 on page 637.
Table 182. Layout of the CNMDPREC Control Block

Off-set Bytes Field Name Description
0 1 PRCODE Specifies a 1-byte required field. Values for PRCODE
are:
*
Designates this entry as a comment that is ignored
by the status monitor task (xxxxxVMT).
R
Specifies a resource entry that is included in the
status monitor resource data table.
O
You can use this operand to place a resource in the
DSINDEF member when it is omitted when you use
the STATOPT keyword. The resource is not placed
in the resource data table and is not available to
the status monitor.
N
You can use this operand to place a list of network
identifiers supported by the status monitor for the
resource. These entries are placed after all
resources in the DSINDEF file (member).
1 1 Reserved
2 8 PRVNAME Specifies an 8-byte VTAM/NCP resource name. This is
a required field when the PRCODE is R or O.
10 1 Reserved

Table 182. Layout of the CNMDPREC Control Block (continued)
11 14 PRSNAME Specifies a 13-byte symbolic name that is displayed
on the status monitor panel. This is a required field
when the PRCODE is R or O.
25 1 Reserved

26 1 PRTYPE Specifies a 1-byte resource type. This is a required
field when the PRCODE is R or O. The values for
PRTYPE are:
H
Specifies a mainframe server
N
Specifies one of the following items:
• NCP name
• NCP major node
• Channel-attached major node
• ICA major node
• LAN major node
• Packet major node
L
Specifies a line that can be an NCP or channel-to-
channel adapter (CTCA)
C
Specifies a PU or cluster (NCP or CTCA)
T
Specifies an LU or terminal (NCP or CTCA)
S
Specifies a switched major node
R
Specifies a switched PU
Q
Specifies a switched LU
F
Specifies a local major node
E
Specifies a local PU
D
Specifies a local LU or terminal
B
Specifies an application major node
A
Specifies an application
Y
Specifies a CDRM major node
Z
Specifies a CDRM
W
Specifies a CDRSC major node
X
Specifies a CDRSC
Appendix D. DSINDEF data set format 639

27 1 PRSUBT Specifies a 1-byte resource subtype. This is a required
field when the PRTYPE is C, R, or E. The values for
PRSUBT when the PRTYPE is C, R, or E are as follows:
4
Specifies that the PU is a type 4
5
2
1
Blank
Not required for this resource type
The values for PRSUBT when the PRTYPE is N are as
follows:
Blank
Specifies NCP major node
C
Specifies channel-attachment major node
I
Specifies ICA major node
L
Specifies LAN major node
P
Specifies packet major node
28 1 PRSUBSUB Specifies a 1-byte field that further classifies PU type

2 resources. This field is required when the PRSUBT is
2. The values for PRSUBSUB are as follows:
1
Specifies that the PU is a type 2.1
0
29 13 Reserved
42 1 PR_GRAPHICAL_MONITOR No longer in use.
43 1 PRXCLUDE Specifies a 1-byte field that excludes application
nodes from activity recording. This is a required field.
The field is blank if the resource is not an application
node. The values for PRXCLUDE are as follows:
Y
Specifies to collect activity detail for application
nodes
N
Specifies that activity detail is not collected for
application nodes or it is not an application node
44 1 Reserved

45 1 PRAUTORE Specifies a 1-byte field excluding a node from
automatic reactivation. This is a required field. The
values for PRAUTORE are as follows:
Y
Specifies to perform automatic reactivation
N
Specifies to exclude the resource from automatic
reactivation
47 8 PR_NETID Specifies the network identifier for the resource. You

can specify the network identifier using the NETID
keyword on the macro statement that defined the
resource or you can assign it using the sift-down rules.
46 34 Reserved
Figure 86 on page 641 is an example of a DSINDEF data set.
***********************************************************************
* *
* NETWORK DESCRIPTION CREATED USING: ATCSTR01 ATCCON01 *
* *
***********************************************************************
R A01SWNET SWITCHED MAJOR S N NETC
R ECH001 APPLICATION A Y N NETC
R A50LSG ICA MAJ NODE NI N NETC
R A50H800 THIS IS A LINE L C NETC
R A50H801 PU TYPE 2 C21 C NETB
R A50I80A LU 1 T C NETA
R A50H804 LINE 02 L C NETA
R A50H841 PU TYPE 5 C5 C NETA
R PUBC0 PU TYPE 4 C4 C NETA
R A50LMN LAN MAJ NODE NL N NETA
R A50LL01 LINE L C NETA
R A50LP01 PU TYPE 5 C5 C NETA
R A50LL31 LINE L C NETA
R A50LP31 PU TYPE 4 C4 C NETA
R X25VCP PACKET MAJ NP N NETA
R XL0101 LINE L C NETA
R XP0101 PU TYPE 4 C4 C NETA
R XL0106 LINE L C NETA
R XP01061 PU TYPE 2 C2 C NETA
R XI020A1C LU T C NETA
.
.
.
Figure 86. Sample of a DSINDEF data set
Appendix D. DSINDEF data set format 641

Appendix E. Message data block to automation
internal function request cross-reference
This section contains a table for cross-referencing message data block (MDB) fields to automation
internal function requests (AIFRs).
Table 183. Message data block field to automation internal function request cross-reference
MDB Control Block Description Decimal, BUFHDR,
Field Hexadecimal, IFRAUTO, or
Character DSIAIFRO
Field
MDBGMID 4-byte ID field Decimal GOJGMID
MDBGSYID 1-byte system ID Decimal GOJGSYID
MDBGSEQ 3-byte sequence number Decimal GOJGSEQ
MDBGTIMH 8-character time HH.MM.SS Character GOJGTIMH
MDBGTIMT 3-character time .TH Character GOJGTIMT
MDBGDSTP 7-character date stamp in YYYYDDD format Character GOJGDSTP
MDBGMFLG(nn) 2-byte flags Decimal GOJGMFLG
MDBGMFLG(1) This is a delete operator message (DOM) IFRAUDOM
MDBGDOM IFRAUWDO
GOJGDOM
MDBGMFLG(2) Sound processor alarm GOJGALRM
MDBGALRM
MDBGFLG(3) Hold message until it is deleted GOJGHOLD
MDBGHOLD
MDBGFGPA 4 characters of foreground presentation attributes Character GOJGFGPA
MDBGFGPA(1) Foreground control field GOJGFCON
MDBGFCON
MDBGFGPA(2) Foreground color field GOJGFCOL
MDBGFCOL
MDBGFGPA(3) Foreground highlighting field GOJGFHIL
MDBGFHIL
MDBGFGPA(4) Foreground intensity field GOJGFINT
MDBGFINT
MDBGBGPA 4 characters of background presentation attributes Character GOJGBGPA
MDBGBGPA(1) Background control field GOJGBCON
MDBGBCON
MDBGBGPA(2) Background color field GOJGBCOL
MDBGBCOL
MDBGBGPA(3) Background highlighting field GOJGBHIL
MDBGBHIL

Table 183. Message data block field to automation internal function request cross-reference (continued)
Character DSIAIFRO
Field
MDBGBGPA(4) Background intensity field GOJGBINT
MDBGBINT
MDBGOSNM Originating system name IFRAUWSN
GOJGOSNM
MDBGJBNM Job name IFRAUWJA
GOJGJBNM
MDBCPROD • 16-byte SCP product level Character, CPOCPROD
decimal
• 4-character MVS CP object version level
• 4-character control program name
• 8-character FMID of originating system
MDBCERC 128 bits routing codes Decimal IFRAUWRT

CPOCERC
MDBCDESC 2-byte descriptor code Decimal IFRAUWDS
CPOCDESC
MDBDESCA System failure IFRAUWDS
CPOCDESC
MDBDESCB (2) Immediate action required IFRAUWDS
CPOCDESC
MDBDESCC (3) Eventual action required IFRAUWDS
CPOCDESC
MDBDESCD (4) System status IFRAUWDS
CPOCDESC
MDBDESCE (5) Immediate command response IFRAUWDS
CPOCDESC
MDBDESCF (6) Job status IFRAUWDS
CPOCDESC
MDBDESCG (7) Application program/processor DOM at end of task IFRAUWDS
CPOCDESC
MDBDESCH (8) Out-of-line IFRAUWDS
CPOCDESC
MDBDESCI (9) Operator request IFRAUWDS
IFRAUMCS(3)
CPOCDESC
MDBDESCJ (10) Track command response IFRAUWDS
CPOCDESC
MDBDESCK (11) Critical eventual action IFRAUWDS
CPOCDESC
MDBDESCL (12) Delivered but not held IFRAUWDS
CPOCDESC

Character DSIAIFRO
Field
MDBDESCM (13) NetView automation table had opportunity to process IFRAUWDS
this message before the write-to-operator (WTO) was CPOCDESC
issued.
MDBDESCN (14) Reserved None
MDBDESCO (15)
MDBDESCP (16)
MDBCMLVL Message level flags CPOCMLVL
MDBCMLVL(1) Write-to-operator-with-reply (WTOR) IFRAUWWR
MDBMLR CPOMLR
MDBCMLVL(2) Immediate action IFRAUWDS(2)
MDBMLIA CPOMLIA
MDBCMLVL(3) Critical eventual action IFRAUWDS(11)
MDBMLCE CPOMLCE
MDBCMLVL(4) Eventual action IFRAUWDS(3)
MDBMLE CPOMLE
MDBCMLVL(5) Informational CPOMLI
MDBMLI
MDBCMLVL(6) Broadcast IFRAUWBD
MDBMLBC IFRAUMCS(6)
CPOMLBC
MDBCMLVL(7) Reserved None
MDBCMLVL(8)
MDBCMLVL(9)
MDBCMLVL(10)
MDBCMLVL(11)
MDBCMLVL(12)
MDBCMLVL(13)
MDBCMLVL(14)
MDBCMLVL(15)
MDBCMLVL(16)
MDBCATTR 2-byte message attribute CPOATTR
MDBCATTR(1) Reserved None
MDBCATTR(2) Message is a command response IFRAUMCS(3)
MDBCMCSC CPOCMCSC
MDBCATTR(3) Message issued by authorized program CPOCAUTH
MDBCAUTH IFRAUPLS
MDBCATTR(4) Message is to be retained by AMRF CPOCRETN
MDBCRETN
Appendix E. Message data block to automation internal function request cross-reference 645
Character DSIAIFRO
Field
MDBCATTR(5) Reserved None
MDBCATTR(6)
MDBCATTR(7)
MDBCATTR(8)
MDBCATTR(9)
MDBCATTR(10)
MDBCATTR(12)
MDBCATTR(13)
MDBCATTR(14)
MDBCATTR(15)
MDBCATTR(16)
MDBCPRTY 2-byte message priority Decimal CPOCPRTY
MDBCASID ASID of issuer Decimal IFRAUWAS
CPOCASID
MDBCTCB 4-byte task control block (TCB) address of issuer Hexadecimal IFRAUTCB
IFRAUWJT
CPOCTCB
MDBCTOKN 4-byte DOM token associated with message Decimal IFRAUWID
CPOCTOKN
MDBCSYID 1-byte system ID for DOM Decimal CPOCSYID
MDBDOMFL 1-byte DOM flags CPODOMFL
MDBDOMFL(1) DOM by message ID MSGDOMAT
MDBDMSGI IFRAUWDT
IFRAUWDA
CPODMSGI
MDBDOMFL(2) DOM by system ID CPODSYSI
MDBDSYSI
MDBDOMFL(3) DOM by ASID IFRAUWDT
MDBDASID IFRAUWDA
CPODASID
MDBDOMFL(4) DOM by job step TCB IFRAUWDT
MDBDJTCB IFRAUWDA
CPODJTCB
MDBDOMFL(5) DOM by token IFRAUWDT
MDBDTOKN IFRAUWDA
MDBDTOKN
MDBCMISC 1-byte miscellaneous routing information CPOCMISC
MDBCMISC(1) Display UD messages CPOCCUD
MDBCUD
MDBCMISC(2) Display only UD messages CPOCFUDO
MDBCFUDO

Character DSIAIFRO
Field
MDBCMISC(3) Queues by ID only CPOCFIDO
MDBCFIDO
MDBCOJID 8-character originating job ID Character IFRAUWJU
CPOCOJID
MDBCKEY 8-byte key associated with message Character, CPOCKEY
hexadecimal
MDBCAUTO 8-byte message processing facility (MPF) automation Character CPOCAUTO
token
MDBCCART 8-byte command and respond token Character, CPOCCART
hexadecimal
MDBCCART 8-byte command and respond token Character, CPOCCART
hexadecimal
MDBCCNID 4-byte MVS target console Decimal CPOCCNID
IFRAUCON
Use CONVCON to find 8-character console name, save
IFRAUWUC
in IFRAUCON
MDBCMSGT 16-bit message type CPOCMSGT

MDBCMSGT(1) Display jobnames IFRAUWFI(9)
MDBMSGTA CPOMSGTA
MDBCMSGT(2) Display status IFRAUWFI(10)
MDBMSGTB CPOMSGTB
MDBCMSGT(3) Monitor active CPOMSGTC
MDBMSGTC
MDBCMSGT(4) Indicates existence of QID field in WPL (AOS/1) CPOMSGTD
MDBMSGTD
MDBCMSGT(5) Reserved None
MDBCMSGT(6) Monitor SESS IFRAUWFI(14)
MDBMMSGTF CPOMSGTF
MDBCMSGT(7) Reserved None
MDBCMSGT(8)
MDBCMSGT(9)
MDBCMSGT(10)
MDBCMSGT(11)
MDBCMSGT(12)
MDBCMSGT(13)
MDBCMSGT(14)
MDBCMSGT(15)
MDBCMSGT(16)
MDBCRPYL 2-byte reply ID length Decimal CPOCRPYL
MDBCRPYI 8-character reply ID Character CPOCRPYI
Character DSIAIFRO
Field
MDBCTOFF Offset in the message text field of the beginning of the CPOCTOFF
message
MDBCRPYB 4-byte binary reply ID CPOCRPYB
MDBCLCNT 2-byte count of the number of lines in the message. Decimal CPOCLCNT
CPOCLCNT and MDBCLCNT are not supported by the
NetView program. Use the count of buffers on the
IFRAUTBA chain instead. GETMSIZE provides this
function.
MDBCOJBN 8-character originating job name CPOCOJBN

MDBTLEN 2-byte text object length HDRTLEN
MDBTTYPE 2-byte text object type flags HDRLNTYP in
each data
buffer
HDRTTYPE
MDBTTYPE(1) Control text HDRLNCTL
MDBTCONT HDRTCONT
MDBTTYPE(2) Label text HDRLNLBL
MDBTLABT HDRTLABT
MDBTTYPE(3) Data text HDRLNDAT
MDBTDATT HDRTDATT
MDBTTYPE(4) End text HDRLNEND
MDBTENDT HDRTENDT
MDBTTYPE(5) Prompt text HDRTPROT
MDBTPROT
MDBTTYPE(6) Reserved None
MDBTTYPE(7)
MDBTTYPE(8)
MDBTTYPE(9)
MDBTTYPE(10)
MDBTTYPE(11)
MDBTTYPE(12)
MDBTTYPE(13)
MDBTTYPE(14)
MDBTTYPE(15)
MDBTTYPE(16) Text object presentation field overrides general object HDRTFPAF
MDBTFPAF presentation attribute field
MDBTMTPA 4-byte presentation attributes HDRTMTPA
MDBTMTPA(1) Presentation control HDRTPCON
MDBTPCON
MDBTMTPA(2) Presentation color HDRTPCOL
MDBTPCOL

Character DSIAIFRO
Field
MDBTMTPA(3) Presentation highlighting HDRTPHIL
MDBTPHIL
MDBTMTPA(4) Presentation intensity HDRTPINT
MDBTPINT
MDBTMSGT Variable length message text Message text is
in buffers
chained from
IFRAUTBA and
IFRAUTBL.
The remaining fields and flags from WQE are not
mapped by MDB.
First message of a multi-line-write-to-operator IFRAUWFR
(MLWTO) message. Can be inferred from IFRAUTBA (not useful)
chain for each buffer on chain.
Middle message of MLWTO. Can be inferred from IFRAUWMD
IFRAUTBA chain for each buffer on chain. (not useful)
Last message of MLWTO. Can be inferred from IFRAUWLS (not
IFRAUTBA chain for each buffer on chain. useful)
Single message line. Can be inferred from IFRAUTBA IFRAUWSI (not
chain for each buffer on chain. useful)
Suppressed message. Bit is always set to zero (0). IFRAUWSP
Routing and descriptor codes exist. Inferred from IFRAUMCS(1)
other data.
Queue conditionally to REG0 console. Bit is set to zero IFRAUMCS(2)
(0).
Message type flag field exists. Can be inferred from IFRAUMCS(4)
other data.
Message is reply to WTOR. Bit is set to zero (0). IFRAUMCS(5)
Queue to hardcopy only. Bit is set to zero (0). IFRAUMCS(7)
Queue unconditionally to console in REG0. Bit is set to IFRAUMCS(8)
zero (0).
No time stamp. Bit is set to zero (0). IFRAUMCS(9)
Do not log to minor WQEs. Bit is set to zero (0). IFRAUMCS(11)
Extended WPL exists. Bit is set to zero (0). IFRAUMCS(12)
Bypass queue to hardcopy. Bit is set to zero (0). IFRAUMCS(14)
WQELBK keyword specified. Bit is set to zero (0). IFRAUMCS(15)
Character DSIAIFRO
Field
Note: Inferred means that the old field must be set by testing the values of other fields. For example, if at least
one route code is nonzero, set the route codes included with flag on.
Fields not in the MDB are set to zero (0). These fields show how the WTO SVC was issued, not to what the
message is about.

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries.
Consult your local IBM representative for information on the products and services currently available in
your area. Any reference to an IBM product, program, or service is not intended to state or imply that only
that IBM product, program, or service may be used. Any functionally equivalent product, program, or
service that does not infringe any IBM intellectual property right may be used instead. However, it is the
user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not give you any license to these patents. You can send
license inquiries, in writing, to:
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property
Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing

Legal and Intellectual Property Law
IBM Japan, Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS"
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore,
this statement might not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically
made to the information herein; these changes will be incorporated in new editions of the publication.
IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in
any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of
the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road

Austin, TX 78758
U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases
payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by
IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any
equivalent agreement between us.
Information concerning non-IBM products was obtained from the suppliers of those products, their
published announcements or other publicly available sources. IBM has not tested those products and
cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of
those products.
Programming Interfaces
This publication documents information that is NOT intended to be used as Programming Interfaces of
IBM Z NetView.
Trademarks
IBM, the IBM logo, and ibm.com® are trademarks or registered trademarks of International Business
Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be
trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at
"Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml .
Adobe is a trademark of Adobe Systems Incorporated in the United States, and/or other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or
its affiliates.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or
both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and service names might be trademarks of IBM or other companies.
Privacy policy considerations

IBM Software products, including software as a service solutions, (“Software Offerings”) may use cookies
or other technologies to collect product usage information, to help improve the end user experience, to
tailor interactions with the end user or for other purposes. In many cases no personally identifiable
information is collected by the Software Offerings. Some of our Software Offerings can help enable you to
collect personally identifiable information. If this Software Offering uses cookies to collect personally
identifiable information, specific information about this offering’s use of cookies is set forth below.
This Software Offering does not use cookies or other technologies to collect personally identifiable
information.
If the configurations deployed for this Software Offering provide you as customer the ability to collect
personally identifiable information from end users via cookies and other technologies, you should seek
your own legal advice about any laws applicable to such data collection, including any requirements for
notice and consent.

For more information about the use of various technologies, including cookies, for these purposes, See
IBM’s Privacy Policy at http://www.ibm.com/privacy and IBM’s Online Privacy Statement at http://
www.ibm.com/privacy/details the section entitled “Cookies, Web Beacons and Other Technologies” and
the “IBM Software Products and Software-as-a-Service Privacy Statement” at http://www.ibm.com/
software/info/product-privacy.
Notices 653
Index
Numerics 78-80 404

78-81 405
22-22 379 78-82 406
22-23 379 78-83 407
22-24 379 78-84 407
22-25 380 79-0 413
22-26 380 79-1 413
22-27 380 79-2 413
22-29 381 79-3 413
22-30 381 79-64 414
22-31 381 79-65 414
22-32 382 79-66 414
22-37 382
22-38 383
22-39 383
A
22-40 383 abend
22-47 383 E/AS task 474
22-56 384 Event/Automation Service task 474
78-0 385 abend (abnormal end)
78-173 408 0C1 253
78-191 408 0C4 56, 253
78-20 385 0C8 255
78-23 386 301 56
78-25 386 9C5 (reason code 0) 256
78-26 386 9C5 (reason code 33) 256
78-27 387 A78 received at NetView termination 54
78-28 387 A78 received at task termination 54
78-30 388 classifying a problem
78-31 388 GMFHS 14
78-32 389 NetView 13
78-35 390 RODM 14
78-36 390 SNA topology manager 15
78-37 391 diagnostic procedure 27
78-38 391 documenting procedure 27
78-40 392 first failure data capture trace 150
78-41 392 FLBTOPO (task) 331
78-42 392 keyword (ABEND) 13
78-43 393 linearization processing problem 56
78-44 394 NetView
78-46 395 0C4 56
78-47 396 301 56
78-48 397 A78 received at NetView termination 54
78-56 398 A78 received at task termination 54
78-58 399 first failure data capture trace 150
78-59 399 linearization processing 56
78-65 400 RID function 59
78-66 400 subtask 53
78-69 400 U0258 54
78-71 400 U0268 54
78-72 401 U0269 54
78-73 401 reporting procedure 27
78-74 401 RID (remote interactive debug) function 59
78-75 402 RODM
78-76 402 0C1 253
78-77 403 0C4 253
78-78 403 0C8 255
78-79 404 9C5 (reason code 0) 256
Index 655
abend (abnormal end) (continued) application, RODM
RODM (continued) failure 249
9C5 (reason code 33) 256 loop 257
abends when SNA topology manager starting 256 archive data feature of Canzlog 63, 69
SNA topology manager array, allocate storage request, NetView trace 148
abend error condition 332 asynchronous method loop, RODM 257
abends after initialization 332 attribute error, RODM 191
abends during initialization 331 Automated Operations Network (AON) 447
FLBTOPO (task) 331 automation
subtask 53 not driven when expected 67
U0258 54 not occurring correctly 66
U0268 54 unexpectedly driven 66
U0269 54 automation internal function request (AIFR) 643
ABEND keyword 13
abend problems
NetView management console 174
B
abnormal reaction from RODM 259 BIND trace record, IP services 118
ACCEPT trace record, IP services 118 blank status history 346
accessibility xxiv BNH160I message 57
Active/Query Workloads BNH161I 58
Data Collection tower or subtower BNH162I 58
ACTIVEACTIVE.LIFELINE 512 BNH163I 58
ActiveActiveSites subnode 509 books
activity (VY) trace record 139 see publications xxi
aggregate correlated objects business tree
cannot navigate between object and contained pop-up menu in — does not display on AIX platform
resources problem scenario and resolution 213
problem scenario and resolution 212
aggregate correlated objects with same object
problem scenario and resolution 210 C
aggregate correlated objects, information displayed
CANCEL trace record, IP services 119
changes
cannot access VTAM CMIP services 328
cannot activate a resource 347
aggregate resource status incorrect 361
cannot deactivate a resource 347
AIFR (automation internal function request) 643
cannot navigate between
AIX problems
correlated aggregate object and contained resources
server window disappears
cannot obtain topology data 337
topology server does not complete initialization
cannot recycle a resource 347
Canzlog
alert
archive data feature 51, 63, 69
no change in status 186
CUE command 41
not in hardware monitor history panel, NetView
log 67–69
management console 186
problem determination using 40
not in history at workstation, NetView management
CE (resource status change processed) 139
console 186
changed information for correlated aggregate object
alert adapter services, IP trace 494
problem scenario and resolution 211, 212
alert and alert history problems and resolutions
changes
problems and resolutions 186
for status to resources not reflected in views
alert problems
alert not in hardware monitor history panel 186
lost for properties
alert not in history at workstation 186
alerts are not converted to EIF events 481
checkpoint processing fails, RODM 258
alerts are not forwarded 480
class index report, RODM dump utility 308
alerts do not change status 186
class listing report, RODM dump utility 305
continuously forwarded 482
classifying a problem
incorrectly cached 483
abend (abnormal end)
alert/message adapter, event receiver 497
GMFHS 14
allocate storage request, NetView trace 148
keyword ABEND 13
AON (Automated Operations Network), worksheet 447
NetView 13
API 257
RODM 14
application
SNA topology manager 15
RODM
building a keyword string 6
user API does not return from EKGWAIT 257

classifying a problem (continued) command (continued)
describing a problem 5 IPCS (interactive problem control system) (continued)
keyword VERBX CNMIPCS command summary 78
ABEND (abnormal end) 13 NCCF GENALERT 491
DOC (documentation) 15 NetView
INCORROUT (incorrect output) 15 TRACE 100
LOOP 16 NetView management console
MSG (message) 17 incorrect command profile 347
PERFM (performance) 19 issued with unexpected result 190
WAIT 20 response window 219
loop sent with unexpected result 190
disabled 16 unexpected result when issued or sent 190
enabled 16 problem scenario and resolution
keyword (LOOP) 16 attribute error, GMFHS/RODM 191
message cannot initiate IP session using NETCONV 188
keyword (MSG) 17 cannot initiate LU 6.2 session using NETCONV 189
NetView program 18 COS gateway error, GMFHS 190
number 18 issued with unexpected result, NetView
range 17 management console 190
RODM 17 NETCONV, cannot initiate IP session 188
SNA topology manager 17 NETCONV, cannot initiate LU 6.2 session 189
RETAIN database 5 OST (operator station task) error, GMFHS 191
search string 5 PPI gateway error, GMFHS 191
CLOSE trace record, IP services 119 sent with unexpected result, NetView management
CNM983E 59 console 190
CNM998E 59 service point error, GMFHS 191
CNM999E 59 time-out error, GMFHS 191
CNME8231 160 unexpected result when issued or sent, NetView
CNME8320 160 management console 190
CNMSSTAC sample 160 RPCINFO 491
CNMSTYLE service aid command 544
documenting a problem summary, diagnostic commands 539
documentation needed 24 TASKMON 19
CNMTARCA 139 TASKUTIL 19
CNMTRACE TRACE 491
GDPS Continuous Availability solution 169 tree facility, SNA topology manager 347
code 12 using command tree facility 347
RODM 439 VERBX CNMIPCS command 541
code 122 command facility
RODM 439 control block
coding control parameter, RODM dump utility 304 DSIMVT 576
command DSITIB 579
DISPLAY STATUS 491 DSITVB 577
GMFHS TIBOST 580
attribute error, RODM 191 problem scenario and resolution
cannot initiate LU 6.2 session using NETCONV 189 logon/bind problem 52
COS gateway error 190 command failures
NETCONV, cannot initiate LU 6.2 session 189 command tree 439
OST (operator station task) error 191 GETTOPO 440
PPI gateway error 191 SNA environment 441
response window 219 command problems
service point error 191 attribute error, RODM 191
time-out error 191 cannot initiate LU 6.2 session using NETCONV 189
GMFHS TRACE COS gateway error 190
description 219 OST (operator station task) error 191
event manager task tracing 223 PPI gateway error 191
IPC task tracing 223 service point error 191
starting 220 time-out error 191
stopping 220 unexpected result when issued or sent, NetView
using in-storage trace table 222 management console 190
viewing output online 221 command statistics data in SMF log 99
IPCS (interactive problem control system) command tree
CNMIPCS TRACE verb options 79 command failures 439
CNMIPCS verb options 79 commands, issuing
Index 657
commands, issuing (continued) Data Collection tower or subtower (continued)
case– sensitive text 439 DVIPA.DVROUT 510, 511
common asynchronous trace record, IP services 133, 134 DVIPA.DVTAD 510
component or connection status TCPIPCOLLECT.TCPCONN and TEMA.CONINACT 510
not properly reflected on topology console TEMA.CONNACT 511
problem scenario and resolution 194 TEMA.HEALTH 511
configuration initialization error, GMFHS 193 TEMA.SESSACT 511
CONNECT trace record, IP services 119, 120 database
connection status problem recording failure 34
problem scenario and resolution 194 dataspace, RODM dumping 302
control block used DB2 Replication Details
command facility initialization 575 Data Collection tower or subtower
DST initialization 587 ACTIVEACTIVE.REPLICATION.DB2 512
hardware monitor initialization 587 DB2 Replication Details for Workload
operator station logon (TVB) 577 Data Collection tower or subtower
session monitor initialization 580 ACTIVEACTIVE.REPLICATION.DB2 512
status monitor initialization 588 debugging method, RODM 248
controlling resource status describing a problem 5
activating resource diagnosing a problem
using command tree facility 347 E/AS 469
using NetView management console pop-up menu Event/Automation Service 469
347 GMFHS 183, 469
deactivating resource NetView management console 183
using command tree facility 347 NetView program 51
using NetView management console pop-up menu RODM 245
347 SNA topology manager 323
recycling resource diagnostic tool, GMFHS
using command tree facility 347 Console Log window 219
using NetView management console pop-up menu trace
347 description 219
conventions event manager task tracing 223
typeface xxv IPC task tracing 223
correlated aggregate objects starting 220
cannot navigate between object and contained stopping 220
resources TRACE command 219
problem scenario and resolution 212 using in-storage trace table 222
correlated aggregate objects with same object viewing output online 221
problem scenario and resolution 210 diagnostic tool, NetView management console
correlated aggregate objects, information displayed Console Log window 219
changes trace, GMFHS
problem scenario and resolution 211 event manager task tracing 223
correlation identifiers, status monitor 140 IPC task tracing 223
COS (common operation services) starting 220
gateway error 190 stopping 220
CPU usage using in-storage trace table 222
diagnosing 99 viewing output online 221
cross reference, MDB to AIFR 643 diagnostic tool, NetView program
cross-product linking problems 516 first failure data capture trace 150
cross-product links, missing 514, 516 IPCS 75
customer support 3 message 96
network log
description 96
D identifying message origin 98
Data Collection tower or subtower in storage 98
ACTIVEACTIVE.LIFELINE 512, 513 MSGMODID 98
ACTIVEACTIVE.REPLICATION.DB2 512, 513 TASKUTIL command output 96
ACTIVEACTIVE.REPLICATION.IMS 512, 513 PPI trace facility
ACTIVEACTIVE.REPLICATION.VSAM 513 description 151
DISCOVERY 510, 511 GTF output files 156
DISCOVERY.INTERFACES 511 locating oldest record 155
DISCOVERY.INTERFACES.HIPERSOCKETS 510 locating table 155
DISCOVERY.TELNET 511 trace anchor block 151
DVIPA 510 trace record 152
DVIPA.DVCONN 510 trace table 151

diagnostic tool, NetView program (continued) documenting a problem
service aid command abend (abnormal end)
DSI24TRC command 562 determining which task abended 30
DSIGADHX command 568 documenting procedure 27
DSIGTVBA command 565 dump of a NetView abend 28
DSIGV2VR command 567 dump of an FLBTOPO abend 32
DSIMODQY command 564 out-of-storage problem causing abend 30
DSISHWVR command 569 reporting procedure 27
DSISTRLS command 556 short-of-storage abend 30
RID DSIMSX command 546 collecting problem data 23
TASKURPT command 548 documentation
WAIT time-out and storage limit 570 documenting procedure 33
SMF type 38 subtype 2 task utilization data 99 reporting procedure 33
TASKURPT 99 documentation needed
trace 100 APAR (authorized program analysis report) 23
diagnostic tool, RODM CNMSTYLE 24
dump utility component ID number 23
class index report 308 FMID (function monitor ID) 23
class listing report 305 IHSERROR.LOG 24
coding control parameter 304 message log 24
description 302 NetView trace 23
dumping dataspace allocated by RODM 302 network log 23
informational message 311 PTF (program temporary fix) 23
invoking 303 status monitor preprocessor job output 24
object index report 309 system log 23
object listing report 308 trace 23
statistical report 310 incorrect output
load function error listing 312 documenting procedure 34
log entry 261 reporting procedure 34
message 251 loop
return code 250 documenting procedure 35
trace, internal 301 reporting procedure 35
diagnostic tool, SNA topology manager message log data
IPCS (interactive problem control system) 375 documenting procedure 40
log entry 376 reporting procedure 40
message 375 performance
NetView internal trace 375 documenting procedure 37
network log 375 reporting procedure 37
recovery from trace error 429 wait
system log 375 documenting procedure 38
TASKMON 375 reporting procedure 38
TASKUTIL 375 DSI124I 59
TOPOSNA LISTxxxx request 429 DSI24TRC command 562
trace 415 DSI625I 55
VTAM CMIP trace 429 DSIAMII 198
diagnostic tools DSIGADHX command 568
IP Management 165 DSIGET/DSIFRE trace record 114
NetView management console 215 DSIGTVBA command 565
Z NetView Enterprise Management Agent 519 DSIGV2VR command 567
directory names, notation xxv DSIMODQY command 564
Distributed DVIPA DSINDEF form 637
Connection Routing 510 DSIPSS trace record 115
distributed mainframe server DSISHWVR command 569
error not recorded 71 DSISTRLS command 556
no data recorded 71 DSIWAT/DSIPOS/DISPATCH trace record 114
solicited data not recorded 71 dump utility, RODM
DOC keyword 15 class index report 308
documentation class listing report 305
keyword (DOC) 15 coding control parameter 304
documentation problem description 302
documenting procedure 33 dumping dataspace allocated by RODM 302
reporting procedure 33 informational message 311
documentation problems invoking 303
NetView management console 176 object index report 309
Index 659
dump utility, RODM (continued) Event Viewer
object listing report 308 alerts not in history at workstation, NetView
statistical report 310 management console 186
duplicate GMFHS resource Event/Automation Service
problem scenario and resolution 198 diagnosing a problem 469
DVIPA list of problem scenarios 469
Connection Routing 510 online help support 491
Connections 510 output log 491
Definition and Status 510 problem background worksheet 461
Distributor Targets 510 Event/Automation Service, IP trace 494
Server Health 510 Event/Automation Service, tracing 493
Sysplex Distributors 510 events
DVIPA management not received from z/OS instrumentation 194
A command returns incomplete data 159
Distributed DVIPA Connection Routing data is
incomplete in the workspace 159
F
no configuration changes received 158 failure
No data is returned from a DVIPA 3270 command 159 GMFHS status solicitation 193
no DVIPA statistics recorded 159 failures
DWO049W 60, 61 caused by RMTCMD errors 441
DWO090A 63 caused by RUNCMD errors 441
DWO158W 64 caused by timeouts 441
DWO627E 66 IP environment 440
object status update 442
E fault problems
NetView management console 174
E/AS FINA (force INACT) trace record 139
diagnosing a problem 469 first failure data capture trace, NetView 150
list of problem scenarios 469 fixes, obtaining 7
online help support 491 FLB300W 335
output log 491 FLB403I 337
problem background worksheet 461 FLB404I 343
E/AS, IP trace 494 FLB405W 342
E/AS, tracing 493 FLB407E 344
EKG_LogLevel value, RODM 262 FLB408W 344
EKG1101E 251 FLB409W 337
EKG1104E 258 FLB420I 337
EKG1105E 258 FLB421I 343
EKG1106E 258 FLB422W 342
EKG1111I 251 FLB424E 344
EKG1112E 258 FLB425W 344
EKG1113I 258 FLB426W 337
EKG1116I 260 FLB443I 343
EKG1117I 260 FLB481E 334
EKG1326D 256 FLB482E 329, 334
EKGPRINT 258 FLB485E 329
EKGWAIT 257 FLB486I 335
environment variable, KNA_ACTACT 509 FLB540I 337
environment variables, notation xxv FLB541W 342
EP/local error not recorded 70 FLB542E 344
error FLB544W 337, 344
reading file FLBSYSD 326 FLB584I 343
errors FLB600E 376
reason code 122 439 FLB601W 376
return code 12 439 FLB602I 376
RODM, FLC070E 439 FLB603I 376
RODM, FLC076E 439 FLB604I 376
event problems FLB610I 343
negative response from an event server 488 FLB677E 328
no reply from event server 487 FLB684E 334
not converted to alerts 487 FLB685W 337, 344
not forwarded to the hardware monitor 486 FLBEXV customization table 327
event receiver FLBOSIDS customization table 327
recycling 490 FLBSRT customization table 327

FLBSYSD initialization file 326 GIVESOCKET trace record, IP services 125
FLBTOPO task abend 331 GMFHS
FLC070E duplicate resource
RODM Errors 439 problem scenario and resolution 198
FLC076E error received during configuration initialization 193
RODM Errors 439 problems
flows information required for TSC 177
multiple Init_Accept received problems and resolutions 192
problem scenario and resolution 196 status solicitation failure 193
flows, request unit 571 GMFHS (Graphic monitor facility host subsystem)
force INACT (FINA) trace record 139 problem determination 440
formatter, RODM log GMFHS (Graphic Monitor Facility host subsystem)
customizing 265 diagnosing a problem 183
description 265 list of problem scenarios 183
invoking 267 problem background worksheet 177
message 267 trace 219
return code 267 GTF (generalized trace facility)
free storage request, NetView trace 149 event ID
FREEADDRINFO TCxx trace record, IP services 120 SNA topology manager 415
format ID
G record format
gateway data format, SNA topology manager 416
COS gateway error 190 example, SNA topology manager 416
PPI gateway error 191 header, SNA topology manager 415
GDPS Continuous Availability solution return code
CNMTRACE 169 SNA topology manager 384
diagnosis or problems 167
event receiver problems 167 H
list of problem scenarios 167
subnode not displayed 509 hang problems
workspace has no data 512 NetView management console 175
general information hardware monitor
problem worksheet control block
NetView management console 173 BNJTCDSX 588
generalized trace facility 415 BNJTDIR 587
GETADDRINFO TCxx output trace record, IP services 121 BNJTDSTF 588
GETADDRINFO TCxx trace record, IP services 120, 121 DSITIB 587
GETCLIENTID TAxx trace record, IP services 134 hardware monitor history panel, NetView management
GETCLIENTID TCxx trace record, IP services 121 console
GETHOSTBYADDR trace record, IP services 122 alert not listed in 186
GETHOSTBYNAME trace record, IP services 122 high-level language (HLL)
GETHOSTID TAxx trace record, IP services 134, 135 first failure data capture trace 150
GETHOSTID TCxx trace record, IP services 122 RID (remote interactive debug) function 59
GETHOSTNAME TAxx trace record, IP services 135 hints, problem determination
GETHOSTNAME TCxx trace record, IP services 122, 123 DVIPA management
GETNAMEINFO TCxx output trace record, IP services 123, A command returns incomplete data 159
124 Distributed DVIPA Connection Routing data is
GETNAMEINFO TCxx trace record, IP services 123 incomplete in the workspace 159
GETPEERNAME trace record, IP services 124 no configuration changes received 158
GETSOCKNAME trace record, IP services 124 No data is returned from a DVIPA 3270 command
GETSOCKOPT TAxx trace record, IP services 135 159
GETSOCKOPT TCxx Option Value Mapping 1, IP services 135 no DVIPA statistics recorded 159
GETSOCKOPT TCxx Option Value Mapping 2, IP services 136 IP Management 157
GETSOCKOPT TCxx Option Value Mapping 3, IP services 136 XCF services
GETSOCKOPT TCxx Option Value Mapping 4, IP services 136 BNH067I message 162
GETSOCKOPT TCxx Option Value Mapping 5, IP services 136 BNH558E message 163
GETSOCKOPT TCxx Option Value Mapping 6, IP services 136 BNH587I message 161
GETSOCKOPT TCxx Option Value Mapping 7, IP services 137 discovery commands fail 162
GETSOCKOPT TCxx trace record, IP services 124, 125 master NetView, unexpected switch 162
GETTOPO command no data returned 161
failures 440 PLEXCTL command fails 162
processing 440 START XCFGROUP problems 162
tracing 440 unable to contact enterprise system 163
Index 661
hints, problem determination (continued) information required (continued)
XCF services (continued) for reporting problems to TSC (continued)
unexpected switch of master NetView 162 general information 177
Z NetView Enterprise Management Agent 507 GMFHS-related information 177
HiperSockets problem classification 178
data collection tower or subtower 510 problem description 178
missing data 160 RODM applications 177
workspace data missing 511 RODM methods 177
hung, topology manager 335 system-related information 177
Information/Access IBM licensed program 3
informational message, RODM dump utility 311
I Init_Accept flows
I/O usage multiple received
diagnosing 99 problem scenario and resolution 196
IBM Software Support specialist 4 INITAPI trace record, IP services 125, 126
icon INITAPIX trace record, IP services 125, 126
for resource is missing from view initialization
problem scenario and resolution 204 topology server does not complete on AIX
IEC161I 052-084 258 problem scenario and resolution 200
IEC161I 203-204 251 initialization error
IEC161I 227-229 258 alert adapter 476
IEC340I 258 alert-to-trap service 479
IHSERROR.LOG 24, 216 confirmed alert adapter 476
image confirmed message adapter 477
partially painted in preview 213 E/AS 475
IMS Replication Details event receiver 478
Data Collection tower or subtower Event/Automation Service 475
ACTIVEACTIVE.REPLICATION.IMS 512 message adapter 477
incorrect trap-to-alert service 478
connectivity shown in view unwanted services are starting 479
problem scenario and resolution 207 initiating IP session, using NETCONV 188
tree view list initiating LU 6.2 session, using NETCONV 189
problem scenario and resolution 204 INITTOPO processing, improving 438
view layout installation exit (UX) trace record 112
problem scenario and resolution 205 instrumentation
incorrect NetView management console command profile (z/OS-based) problems and resolutions 193
347 instrumentation problems
incorrect output (z/OS–based) problems and resolutions
archived data 70 events not received from 194
diagnostic procedure 34 events not received from z/OS instrumentation 194
distributed mainframe server data not recorded 71 interactive problem control system 75
distributed mainframe server error 71 Interface Management 160
documenting procedure 34 internal trace, status monitor 139
EKGPRINT data set, RODM 258 Internet Protocol
EP/local error 70 missing objects from views 443
keyword (INCORROUT) 15 IOCTL RETARG TCxx Mapping 1, IP services 137
message origin using MSGMODID 98 IOCTL RETARG TCxx Mapping 2, IP services 137
NetView automation 66 IOCTL RETARG TCxx Mapping 3, IP services 137
reporting procedure 34 IOCTL RETARG TCxx Mapping 4, IP services 138
solicited remote device data not recorded 71 IOCTL RETARG TCxx Mapping 5, IP services 138
unsolicited remote error 71 IOCTL TAxx trace record, IP services 137
incorrect output problems IOCTL TCxx REQARG Mapping 1, IP services 126
NetView management console 176 IOCTL TCxx REQARG Mapping 2, IP services 126
incorrect resource status IOCTL TCxx REQARG Mapping 3, IP services 126
problem scenario and resolution 194 IOCTL TCxx REQARG Mapping 4, IP services 127
incorrect timestamps IOCTL TCxx REQARG Mapping 5, IP services 127
if topology server is on Windows platform IOCTL TCxx REQARG Mapping 6, IP services 127
problem scenario and resolution 200 IOCTL TCxx trace record, IP services 126
INCORROUT keyword 15 IP
information displayed for correlated aggregate object cannot initiate session with NETCONV 188
changes NETCONV, cannot initiate session 188
problem scenario and resolution 211 IP connectivity problems
information required recycling the event receiver 490
for reporting problems to TSC recycling the PPI 490

IP connectivity problems (continued) IP services (continued)
recycling the trap-to-alert service 490 TCxx trace entries (continued)
IP Management SETSOCKOPT Option Value Mapping 3 131
diagnostic tools 165 SETSOCKOPT Option Value Mapping 4 131
problem determination 157 SETSOCKOPT Option Value Mapping 5 131
IP services SETSOCKOPT Option Value Mapping 6 131
common asynchronous trace record 133, 134 SETSOCKOPT Option Value Mapping 7 131
TAxx trace entries SETSOCKOPT trace record 130
GETCLIENTID trace record 134 SHUTDOWN trace record 131, 132
GETHOSTID trace record 134, 135 SOCKET Trace Record 132
GETHOSTNAME trace record 135 TAKESOCKET trace record 132, 133
GETSOCKOPT trace record 135 TERMAPI trace record 133
IOCTL trace record 137 trace exit record 138
TCPX trace record 138 IP trace, E/AS 494
TCxx trace entries IP trace, Event/Automation Service 494
ACCEPT trace record 118 IPCS (interactive problem control system)
BIND trace record 118 CNMIPCS TRACE verb
CANCEL trace record 119 options 79
CLOSE trace record 119 CNMIPCS verb
CONNECT trace record 119, 120 options 79
FREEADDRINFO trace record 120 command output
GETADDRINFO output trace record 121 ASID 82
GETADDRINFO trace record 120, 121 CPOOL 82
GETCLIENTID trace record 121 D 83
GETHOSTBYADDR trace record 122 DISPLAY 84
GETHOSTBYNAME trace record 122 DISPMOD 85
GETHOSTID trace record 122 DTCB 86
GETHOSTNAME trace record 122, 123 LEVEL 86
GETNAMEINFO output trace record 123, 124 LRCE 87
GETNAMEINFO trace record 123 MAP 88
GETPEERNAME trace record 124 NLDM 89
GETSOCKNAME trace record 124 NPDA 90
GETSOCKOPT Option Value Mapping 1 135 QUE 91
GETSOCKOPT Option Value Mapping 2 136 SAVEAREA 92
GETSOCKOPT Option Value Mapping 3 136 STORE 92
GETSOCKOPT Option Value Mapping 4 136 SUMMARY 81
GETSOCKOPT Option Value Mapping 5 136 TBLUSECT 93
GETSOCKOPT Option Value Mapping 6 136 TRACE 94
GETSOCKOPT Option Value Mapping 7 137 WHO 95
GETSOCKOPT trace record 124, 125 description 75
GIVESOCKET trace record 125 installation 75
INITAPI trace record 125, 126 operation 76
INITAPIX trace record 125, 126 option selection example 80
IOCTL REGARG Mapping 1 137 VERBX CNMIPCS command
IOCTL REGARG Mapping 2 137 summary 78
IOCTL REGARG Mapping 3 137
K
IOCTL REQARG Mapping 1 126 keyword
IOCTL REQARG Mapping 2 126 ABEND (abnormal end) 13
IOCTL REQARG Mapping 3 126 ABENDxxx 29
IOCTL REQARG Mapping 4 127 AUTO 69
IOCTL REQARG Mapping 5 127 building a string 6
IOCTL REQARG Mapping 6 127 DOC (documentation) 15
IOCTL trace record 126 INCORROUT (incorrect output) 15
LISTEN trace record 127 LOOP 16
RECV trace record 127, 128 MINUS 568
RECVFROM trace record 128 MSG (message) 17
SELECT exit trace record 129 NETID 641
SELECT trace record 128 NUMILU 190
SEND trace record 129 OPERSEC 52
SENDTO trace record 129 OPTION 117, 138
SETSOCKOPT Option Value Mapping 1 130 PARM (parameter) 265
SETSOCKOPT Option Value Mapping 2 130 PERFM (performance) 19
Index 663
keyword (continued) log entry, RODM (continued)
SAF 140 log-level value 262
SAFA 140 record format, formatted
STATOPT 637 record type 0 271
SUPPRESS 69 record type 1 273
TASK 138 record type 10 300
WAIT 20 record type 2 275
WQELBK 649 record type 3 278
KFWITM081E 514 record type 4 280
KNA_ACTACT environment variable 509 record type 5 282
record type 6 284
record type 7 286
L record type 8 291
layout of view is incorrect record type 9 297
problem scenario and resolution 205 record format, unformatted
links, cross-product 514, 516 record type 0 270
Linux on z Systems Workload Server Details record type 1 272
Data Collection tower or subtower record type 10 298
ACTIVEACTIVE.LIFELINE 512 record type 2 274
list record type 3 277
for tree view is incorrect record type 4 279
problem scenario and resolution 204 record type 5 281
list of problem scenarios record type 6 283
E/AS 469 record type 7 284
Event/Automation Service 469 record type 8 287
GDPS Continuous Availability solution 167 record type 9 296
GMFHS 183 log entry, SNA topology manager
MultiSystem Manager 437 description 376
NetView management console 183 displayed using message
NetView program 51 associated data (FLB603I and FLB604I) 376
RODM 245 error event (FLB600E) 376
SNA topology manager 323 informational event (FLB602I) 376
sysplex 157 warning event (FLB601W) 376
Z NetView Enterprise Management Agent 507 event type 376
LISTEN trace record, IP services 127 format
Load Balancer Groups format of log data 377, 378
Data Collection tower or subtower major code, description 377
ACTIVEACTIVE.LIFELINE 512 minor code 377
Load Balancer Workloads probe ID 376, 378
Data Collection tower or subtower major code 78
ACTIVEACTIVE.LIFELINE 512 minor code 0 (78-0) 334, 385
Load Balancers minor code 173 (78-173) 408
Data Collection tower or subtower minor code 191 (78-191) 408
ACTIVEACTIVE.LIFELINE 512 minor code 20 (78-20) 385
load function, RODM minor code 23 (78-23) 386
error listing 312 minor code 25 (78-25) 339, 386
lockup problems minor code 26 (78-26) 386
NetView management console 175 minor code 27 (78-27) 387
log minor code 28 (78-28) 387
Canzlog log 67 minor code 30 (78-30) 388
network log 67 minor code 31 (78-31) 388
system log 67 minor code 32 (78-32) 389
log entry, RODM minor code 35 (78-35) 390
components that output data to log file 262 minor code 36 (78-36) 390
defining 261 minor code 37 (78-37) 391
description 261 minor code 38 (78-38) 391
EKG_LogLevel value 262 minor code 40 (78-40) 392
formatter minor code 41 (78-41) 392
customizing 265 minor code 42 (78-42) 392
description 265 minor code 43 (78-43) 393
invoking 267 minor code 44 (78-44) 394
message 267 minor code 46 (78-46) 395
return code 267 minor code 47 (78-47) 396
log file, components that output data to 262 minor code 48 (78-48) 397

log entry, SNA topology manager (continued) loop (continued)
major code 78 (continued) RODM (continued)
minor code 56 (78-56) 398 user application 257
minor code 58 (78-58) 399 LOOP keyword 16
minor code 59 (78-59) 399 loop problems
minor code 65 (78-65) 400 NetView management console 175
minor code 66 (78-66) 400 looping 99
minor code 69 (78-69) 400 looping, alert/message adapter 497
minor code 71 (78-71) 349, 400 lost connection with agent node 344
minor code 72 (78-72) 401 lost property changes
minor code 73 (78-73) 401 problem scenario and resolution 199
minor code 74 (78-74) 401 lost trace record, NetView 114
minor code 75 (78-75) 402 LU 6.2
minor code 76 (78-76) 402 cannot initiate session, NetView management console
minor code 77 (78-77) 403 189
minor code 78 (78-78) 403 NETCONV, cannot initiate session 189
minor code 79 (78-79) 404 LU not found with locate resource 346
minor code 80 (78-80) 404 LUC
minor code 81 (78-81) 405 macro invocation 110
minor code 82 (78-82) 406 receive exit 110
minor code 83 (78-83) 407
minor code 84 (78-84) 407
major code 79
M
minor code 0 (79-0) 413 manual, problem with 33
minor code 1 (79-1) 413 manuals
minor code 2 (79-2) 413 see publications xxi
minor code 3 (79-3) 413 MDB (message data block) 643
minor code 64 (79-64) 414 MENT (module entry) trace record 113
minor code 65 (79-65) 414 message adapter services, IP trace 494
minor code 66 (79-66) 414 message data block (MDB) 643
log entry, system interface message keyword (MSG) 17
major code 22 message log
minor code 22 (22-22) 379 job output for status monitor preprocessor
minor code 23 (22-23) 379 documentation needed to document a problem 24
minor code 24 (22-24) 379 message log data
minor code 25 (22-25) 380 diagnostic procedure 40
minor code 26 (22-26) 380 documenting procedure 40
minor code 27 (22-27) 380 reporting procedure 40
minor code 29 (22-29) 381 message problems
minor code 30 (22-30) 381 documentation problems
minor code 31 (22-31) 381 information required - reporting problems to TSC
minor code 32 (22-32) 382 181
minor code 37 (22-37) 382 incorrect output problems
minor code 39 (22-39) 383 180
minor code 40 (22-40) 383 incorrectly cached 485
minor code 47 (22-47) 383 loop classification
log file 179
components that output data to RODM 262 NetView management console 174
RODM, components that output data to 262 not converted to EIF event 485
log, , message not forwarded to event server 483
documenting a problem performance output problems
documentation needed 24 information required - reporting problems to TSC
logon/bind problem with command facility 52 181
loop problem classification
asynchronous method, RODM 257 information required - reporting problems to TSC
diagnostic procedure 35 179
disabled 16 wait classification
documenting procedure 35 information required - reporting problems to TSC
enabled 16 180
keyword (LOOP) 16 message queueing rates
reporting procedure 35 diagnosing 99
RODM message, NetView management console
Index 665
message, NetView management console (continued) message, SNA topology manager (continued)
GMFHS FLB600E (error log entry) 376
IHSERROR.LOG 216 FLB601W (warning log entry) 376
message log 216 FLB602I (informational log entry) 376
IHSERROR.LOG 216 FLB603I (partial log data) 376
message log 216 FLB604I (end of log data) 376
output logs 216 FLB610I 343
message, NetView program FLB677E 328
BNH160I 57 FLB684E 334
BNH161I 57, 58 FLB685W 337, 344
BNH162I 57, 58 online help 375
BNH163I 57, 58 range 17, 375
CNM983E 59 messages, routing 438
CNM998E 59 minimized windows
CNM999E 59 problem scenario and resolution 198
DSI124I 59 missing configuration
DSI625I 55 problem scenario and resolution 202
DWO049W 60, 61 missing resource
DWO090A 63 view does not contain
DWO158W 64 problem scenario and resolution 208
DWO627E 66 MODE=EXT 103
network log 96 MODE=INT 101
origin using MSGMODID 98 module entry (MENT) trace record 113
message, RODM module exit (MXIT) trace record 113
EKG1101E 251 MONIT (VMON) trace record 139
EKG1104E 258 MONOPER keyword to TRACE command 106
EKG1105E 258 more detail view does not exist
EKG1106E 258 problem scenario and resolution 202
EKG1111I 251 MQS (message queuing service) 111
EKG1112E 258 MSG (message) keyword 17
EKG1113I 258 MSGMODID, using to identify message origin 98
EKG1116I 260 multiple
EKG1117I 260 Init_Accept flows received
EKG1326D 256 problem scenario and resolution 196
IEC161I 052-084 258 multiple objects with same object
IEC161I 203-204 251 problem scenario and resolution 210
IEC161I 227-229 258 MultiSystem Manager
IEC340I 258 list of problem scenarios 437
incorrect output in EKGPRINT data set 258 problem background worksheet 433
range 17 MXIT (module exit) trace record 113
message, SNA topology manager
FLB300W 335
FLB403I 337
N
FLB404I 343 NETCONV command cannot initiate IP session 188
FLB405W 342 NETCONV command cannot initiate LU 6.2 session 189
FLB407E 344 NetView
FLB408W 344 Applications 510
FLB409W 337 Tasks 511
FLB420I 337 NetView management console
FLB421I 343 diagnosing a problem 183
FLB422W 342 diagnostic tools 215
FLB424E 344 list of problem scenarios 183
FLB425W 344 problem background worksheet
FLB426W 337 abend problems 174
FLB443I 343 general information 173
FLB481E 334 loop problems 175
FLB482E 329, 334 problem classification 174
FLB485E 329 problem description 174
FLB486I 335 system-related information 173
FLB540I 337 NetView program
FLB541W 342 diagnosing a problem 51
FLB542E 344 diagnostic tool 75
FLB544W 337, 344 list of problem scenarios 51
FLB584I 343 message 96

NetView program (continued) O
problem background worksheet 45
trace 100 object index report, RODM dump utility 309
NetView service aid command object listing report, RODM dump utility 308
DSI24TRC command object status update failures 442
description 562 objects with same object
HELP 562 problem scenario and resolution 210
OFF 562 OC (operator command) trace record 139
ON 562 online help support for E/AS 491
syntax diagram 562 online help support for Event/Automation Service 491
DSIGADHX command online publications
description 568 accessing xxiv
syntax diagram 568 operator command (OC) trace record 139
DSIGTVBA command OSA
description 565 data collection tower or subtower 511
syntax diagram 565 missing data 160
DSIGV2VR command workspace data missing 511
description 567 OST (operator station task)
syntax diagram 567 error, GMFHS 191
DSIMODQY command out-of-storage problem causing abend 30
description 564 output logs, GMFHS
syntax diagram 564 description 216
DSISHWVR command output, incorrect
description 569 NetView management console 176
syntax diagram 569
DSISTRLS command
<SUMMARY> 557
P
BLOCKS 559 path names, notation xxv
CELLHIST 557 penalty time, amount assessed
description 556 diagnosing 99
DETAIL 557 PERFM keyword 19
SHOWMQS 557 performance problem
SHOWMQS ADDR=xxxxxxxx 557 diagnostic procedure 37
SHOWMQS NAME=nnnnnnnn 557 documenting procedure 37
SHOWSTOR 558 keyword (PERFM) 19
syntax diagram 556 reporting procedure 37
RID DSIMSX command performance problems
description 546 NetView management console 176
syntax diagram and description 546 pop-up menu in business tree
TASKURPT not displayed on AIX platform
command examples 549 problem scenario and resolution 213
return code 551 PPI (program-to-program interface)
TASKURPT command gateway error 191
description 548 recycling 490
syntax diagram 547 trace facility
WAIT time-out and storage limit description 151
description 570 GTF output files 156
NetView trace locating oldest record 155
job output for status monitor preprocessor locating table 155
documentation needed to document a problem 23 trace anchor block 151
network log trace record 152
description 96 trace table 151
identifying message origin 98 preprocessor
in storage 98 documenting a problem
MSGMODID 98 documentation needed 24
TASKMON command 96 job output for status monitor preprocessor
TASKUTIL command 96 documentation needed to document a problem 24
network views, unable to monitor preview image
problem scenario and resolution 207 partially painted 213
not enough storage, topology manager 326 printing
notation trace record
environment variables xxv when MODE=EXT 103
path names xxv when MODE=INT 100
typeface xxv problem
Index 667
problem (continued) problem classification (continued)
classifying problem worksheet
abend (abnormal end) 13 NetView management console 174
building a keyword string 6 processor traps
describing a problem 5 information required - reporting problems to TSC
documentation 15 178
INCORROUT (incorrect output) 15 wait problems
loop 16 information required - reporting problems to TSC
message 17 180
performance 19 problem description
RETAIN database 5 problem worksheet
search string 5 NetView management console 174
wait 20 problem determination
collecting data 23 Canzlog 40
documenting describing problems 4
abend 27 determining business impact 4
documentation 33 DVIPA management
documentation needed 23 A command returns incomplete data 159
INCORROUT (incorrect output) 34 Distributed DVIPA Connection Routing data is
loop 35 incomplete in the workspace 159
message log data 40 no configuration changes received 158
performance 37 No data is returned from a DVIPA 3270 command
wait 38 159
reporting no DVIPA statistics recorded 159
IBM Software Support 23 IP Management 157
IBM Software Support specialist 4 submitting problems 5
Information/Access IBM licensed program 3 using Canzlog 40
searching the database for a solution 3 XCF services
software support database, searching solutions 3 BNH067I message 162
worksheet BNH558E message 163
AON 447 BNH587I message 161
E/AS 461 discovery commands fail 162
Event/Automation Service 461 master NetView, unexpected switch 162
GMFHS 177 no data returned 161
MultiSystem Manager 433 PLEXCTL command fails 162
NetView 45 START XCFGROUP problems 162
NetView management console 173 unable to contact enterprise system 163
RODM 239 unexpected switch of master NetView 162
SNA topology manager 317 Z NetView Enterprise Management Agent 507
Z NetView Enterprise Management Agent 501 problem scenario
problem classification alert adapter initialization error 476
documentation problems alert is continuously forwarded 482
information required - reporting problems to TSC alert is incorrectly cached 483
181 alert-to-trap service initialization error 479
incorrect output problems alerts are converted to EIF events 481
information required - reporting problems to TSC alerts are not forwarded 480
180 confirmed alert adapter initialization error 476
loop problems confirmed message adapter initialization error 477
information required - reporting problems to TSC E/AS 474
179 E/AS initialization error 475
message problems E/AS task suspended 475
information required - reporting problems to TSC event receiver initialization error 478
179 Event/Automation Service 474
NetView management console Event/Automation Service initialization error 475
abend problems 174 Event/Automation Service task suspended 475
documentation problems 176 events are not converted to alerts 487
incorrect output problems 176 events are not forwarded to the hardware monitor 486
loop problems 175 GDPS Continuous Availability solution 167
message problems 174 IP connectivity problems 490
performance problems 176 message adapter initialization error 477
wait problems 175 message is incorrectly cached 485
performance problems message is not converted d to EIF event 485
information required - reporting problems to TSC message is not forwarded to event server 483
181 negative response from an event server 488

problem scenario (continued) problem scenario, NetView management console (continued)
no reply from an event server 487 alert
recycling the PPI 490 no status change 186
suspended task 475 alert and alert history problems and resolutions 186
symptom attribute error, RODM 191
configuration initialization error 193 component or connection status
connection status problem 194, 200 not properly reflected on topology console 194
duplicate GMFHS resource 198 duplicate GMFHS resource 198
GMFHS status solicitation failure 193 events not received from z/OS instrumentation 194
incorrect resource status 194 gateway error
incorrect timestamps if topology server is on COS (common operations services) 190
Windows platform 200 GMFHS
information displayed for object changes 211 attribute error, RODM 191
minimized window problem 198 cannot initiate LU 6.2 session using NETCONV 189
multiple Init_Accept flows received 196 command time-out error 191
multiple objects with same object 210 COS gateway error 190
property changes lost 199 NETCONV, cannot initiate LU 6.2 session 189
resource exists but status is not updated 195 OST (operator station task) error 191
resource icon missing from view 204 PPI gateway error 191
server windows disappear on AIX platform 200 service point error 191
status changes to resources not reflected in views GMFHS problems and resolutions 192
196 incorrect resource status 194
tree view list is incorrect 204 incorrect timestamps
unable to monitor views of your network 207 if topology server is on Windows platform 200
view does not contain resource 208 instrumentation (z/OS-based) 193
trap-to-alert service initialization error 478 IP session 188
traps are not converted to alerts 489 list of problem scenarios 183
traps are not forwarded 488 minimized window problem 198
unwanted services are starting 479 multiple Init_Accept flows received
Z NetView Enterprise Management Agent 507 problem scenario and resolution 196
problem scenario, APM pop-up menu in business tree
APM not displayed on AIX platform 213
cannot initiate IP session using NETCONV 188 preview image partially painted 213
NETCONV, cannot initiate IP session 188 property changes lost 199
command resource exists but status is not updated
cannot initiate IP session using NETCONV 188 problem scenario and resolution 195
NETCONV, cannot initiate IP session 188 server windows disappear on AIX platform 200
problem scenario, E/AS service point error 191
list of problem scenarios 469 status changes to resources not reflected in views
problem scenario, Event/Automation Service problem scenario and resolution 196
list of problem scenarios 469 status problems and resolutions 194
problem scenario, GMFHS symptom
attribute error, RODM 191 alert not in hardware monitor history panel 186
command alert not in history at workstation 186
attribute error, RODM 191 alerts do not change status 186
cannot initiate LU 6.2 session using NETCONV 189 attribute error, RODM 191
COS gateway error 190 cannot navigate between object and contained
NETCONV, cannot initiate LU 6.2 session 189 resources 212
OST (operator station task) error 191 command cannot initiate LU 6.2 session using
PPI gateway error 191 NETCONV 189
service point error 191 command result unexpected 190
time-out error 191 COS gateway error 190
configuration initialization error 193 missing configuration 202
COS gateway error 190 more detail view does not exist 202
list of problem scenarios 183 NETCONV, cannot initiate LU 6.2 session 189
OST (operator station task) error 191 no result when issued or sent 190
PPI gateway error 191 OST (operator station task) error 191
service point error 191 PPI gateway error 191
status solicitation failure 193 real resource not shown 211
time-out error sent with no result 190
command 191 service point error 191
problem scenario, MultiSystem Manager time-out error 191
list of problem scenarios 437 topology console hangs when accessing view 198
problem scenario, NetView management console unable to open view 206
Index 669
problem scenario, NetView management console (continued) problem scenario, RODM (continued)
symptom (continued) abend (abnormal end) (continued)
view layout is incorrect 205 9C5 (reason code 0) 256
view shows incorrect connectivity 207 9C5 (reason code 33) 256
time-out error when topology manager starting 256
command 191 abnormal reaction 259
topology console application failure 249
hangs during sign-on 198 asynchronous method loop 257
unable to connect from, to topology server 197 checkpoint processing fails 258
topology console hangs during sign-on 198 debugging method 248
topology console hangs when accessing view 198 fails to complete checkpoint processing 258
topology display subsystem view problem 213 incorrect output
topology server 199 EKGPRINT data set 258
topology server does not complete initialization 200 list of problem scenarios 245
Views 202 loop
problem scenario, NetView program asynchronous method 257
abend (abnormal end) user application 257
0C4 56 message
301 56 EKG1101E 251
A78 received at NetView termination 54 EKG1104E 258
A78 received at task termination 54 EKG1105E 258
linearization processing 56 EKG1106E 258
RID (remote interactive debug) function 59 EKG1111I 251
subtask 53 EKG1112E 258
U0258 54 EKG1113I 258
U0268 54 EKG1116I 260
U0269 54 EKG1117I 260
automation EKG1326D 256
not driven when expected 67 IEC161I 052-084 258
not occurring correctly 66 IEC161I 203-204 251
unexpectedly driven 66 IEC161I 227-229 258
distributed mainframe server error not recorded 71 IEC340I 258
DSIFRE message 60 incorrect output in EKGPRINT data set 258
DSIGET message 61 return code
EP/local error not recorded 70 12, reason code 121 251
linearization processing problem 56 12, reason code 122 251
list of problem scenarios 51 12, reason code 194 252
logon/bind problem with command facility 52 12, reason code 20 250
message 12, reason code 211 254
CNM983E 59 12, reason code 212 254
CNM998E 59 12, reason code 213 254
CNM999E 59 slow response 260
DSI124I 59 troubleshooting reference 249
DSI625I 55 user API does not return from EKGWAIT 257
DWO049W 60, 61 user application loop 257
DWO090A 63 problem scenario, SNA topology manager
DWO158W 64 abend (abnormal end)
DWO627E 66 after initialization 332
MS transport cancels 66 during initialization 331
NetView operator cannot browse archived data 70 error condition 332
not attempting to archive Canzlog data 69 FLBTOPO task 331
return code automatic monitoring does not work 336
U0258 abend code 55 blank status history 346
U0268 abend code 55 cannot find LU with locate resource 346
U0269 abend code 55 cannot issue resource control command
RMTCMD RUNCMD response on MVS console 72 generic commands fail 347
security problem 73 cannot obtain topology data 337
solicited data not recorded 71 hung (not processing requests)
unsolicited remote error not recorded 71 RODM checkpoint 335
problem scenario, RODM incorrect view
abend (abnormal end) aggregate resource status incorrect 361
0C1 253 class of node object is incorrect 350, 367
0C4 253 multiple subnetworks in same view 366
0C8 255 resource not in view 340, 350

problem scenario, SNA topology manager (continued) problem scenario, SNA topology manager (continued)
incorrect view (continued) object unexpectedly purged (continued)
resource status incorrect 357 by TOPOSNA PURGE command 350, 362
resource status unknown 354 resource control requests do not work
unexpected resource in view 347, 368 incorrect NetView management console command
view cannot be displayed 350, 362 profile 347
view disappears 350, 362 suspended (not processing requests)
initialization failure RODM checkpoint 335
cannot access RODM 329 unexpected reinitialization 335
cannot access VTAM CMIP services 328 unexpected shutdown
error reading customization table 327 log entry 78-0 334
error reading file FLBSYSD 326 storage shortage 334
not enough storage 326 unrecoverable RODM error 334
severe error 327 VTAM CMIP services ended 334
warning error 327 problem scenario, sysplex
wrong autotask 326 list of problem scenarios 157
list of problem scenarios 323 problem worksheet
message NetView management console
FLB300W 335 abend problems 174
FLB403I 337 documentation problems 176
FLB405W 342 incorrect output problems 176
FLB407E 344 loop problems 175
FLB408W 344 message problems 174
FLB409W 337 performance problems 176
FLB420I 337 problem classification 174
FLB421I 343 problem description 174
FLB422W 342 system-related information 173
FLB424E 344 wait problems 175
FLB425W 344 problems
FLB426W 337 information required for TSC
FLB481E 334 GMFHS-related information 177
FLB482E 329, 334 problem classification 178
FLB485E 329 problem description 178
FLB486I 335 RODM applications information 177
FLB540I 337 RODM methods information 177
FLB541W 342 system-related information 177
FLB542E 344 processor exception problems
FLB544W 337, 344 NetView management console 174
FLB584I 343 processor traps
FLB610I 343 problem classification
FLB677E 328 information required - reporting problems to TSC
FLB684E 334 178
FLB685W 337, 344 property changes lost
monitor operation unexpectedly ended problem scenario and resolution 199
lost connection with agent node 344 publications
monitor completed 343 accessing online xxiv
stopped by TOPOSNA STOP command 342 IBM Z NetView xxi
topology manager ended 343 ordering xxiv
VTAM CMIP services ended 343
object missing attribute value, RODM
agent not reporting attribute 339, 340
R
log entry 78-25 339 real resource not shown
not monitoring correct type of topology 339 as member of correlated aggregate object
unsupported attribute 339 problem scenario and resolution 211
object not purged reallocate storage request, NetView trace 149
error purging object 349 reason code 122
log entry 78-71 349 RODM 439
object being monitored 347–349 RECFMS record format 591
object unexpectedly purged recording failure, database 34
by a topology update (link object) 353 RECV trace record, IP services 127, 128
by a topology update (node object) 350, 367 RECVFROM trace record, IP services 128
by a topology update (TG object) 353 remote interactive debug (RID) function 59
Index 671
Replication Servers RODM (Resource Object Data Manager) (continued)
Data Collection tower or subtower message 251
ACTIVEACTIVE.REPLICATION.DB2 513 problem background worksheet 239
ACTIVEACTIVE.REPLICATION.IMS 513 reason code 122 439
ACTIVEACTIVE.REPLICATION.VSAM 513 return code 250
Replication Workloads return code 12 439
Data Collection tower or subtower trace, internal 301
ACTIVEACTIVE.REPLICATION.DB2 513 RODM applications
ACTIVEACTIVE.REPLICATION.IMS 513 problems
ACTIVEACTIVE.REPLICATION.VSAM 513 information required for TSC 177
reporting a problem RODM methods
IBM Software Support 23 problems
IBM Software Support specialist 4 information required for TSC 177
Information/Access IBM licensed program 3 routing
searching the database for a solution 3 messages 438
software support database, searching solutions 3 RUNCMD errors 441
request unit (RU) flows 571
resource
duplicates for GMFHS
S
problem scenario and resolution 198 SAF (security authorization facility) trace record
exists but status is not updated AUTH 141
problem scenario and resolution 195 description 140
icon is missing from view EXTRACT 142
problem scenario and resolution 204 FASTAUTH 144
status change processed (CE) trace record 139 LIST 145
resource status, incorrect STAT 145
problem scenario and resolution 194 TOKENMAP 146
resource, missing TOKENXTR 146
view does not contain VERIFY 147
problem scenario and resolution 208 search string 5
resources searching the database for a solution 3
status changes not reflected in views security authorization facility trace record 140
problem scenario and resolution 196 security problem
RETAIN 3 NetView program 73
RETAIN database 5 Z NetView Enterprise Management Agent 517
return code SELECT exit trace record, IP services 129
NetView program SELECT trace record, IP services 128
U0258 abend code 55 SEND trace record, IP services 129
U0268 abend code 55 SENDTO trace record, IP services 129
U0269 abend code 55 service point error, GMFHS 191
RODM Session Data 511
12, reason code 121 251 session monitor
12, reason code 122 251 control block
12, reason code 194 252 AAUTGLOB 581
12, reason code 20 250 AAUTKCT 585
12, reason code 211 254 AAUTMST 584
12, reason code 212 254 AAUTPCT 585
12, reason code 213 254 AAUTSTAT 584
return code 12 KCLASS definition table 585
RODM 439 MAPSESS table 584
RID (remote interactive debug) function 59 performance class table 585
RID DSIMSX 546 NLDM command, trace status 78
RMTCMD errors 441 status, trace NLDM command 78
RMTCMD RUNCMD response on MVS console 72 SETSOCKOPT TCxx Option Value Mapping 1, IP services 130
RODM (Resource Object Data Manager) SETSOCKOPT TCxx Option Value Mapping 2, IP services 130
abend 255 SETSOCKOPT TCxx Option Value Mapping 3, IP services 131
diagnosing a problem 245 SETSOCKOPT TCxx Option Value Mapping 4 IP services 131
diagnostic tool 261 SETSOCKOPT TCxx Option Value Mapping 5, IP services 131
dump utility 302 SETSOCKOPT TCxx Option Value Mapping 6, IP services 131
errors 439 SETSOCKOPT TCxx Option Value Mapping 7, IP services 131
FLC070E 439 SETSOCKOPT trace record, IP services 130
FLC076E 439 short-of-storage abend 30
list of problem scenarios 245 SHUTDOWN trace record, IP services 131, 132
log entry 261 sign-on problems

sign-on problems (continued) storage
topology console hangs diagnosing 99
problem scenario and resolution 198 storage outage 99
slow response from RODM 260 storage request, NetView trace 148
SMF Log Record 38 Subtype 2 99 storage shortage, topology manager 334
SMF Log Record 38 Subtype 4 99 subsystem view
SNA topology manager for topology display is not complete 213
diagnosing a problem 323 subtask abend, NetView 53
diagnostic tool 375 summary of diagnostic commands 539
hung 335 suspended task
list of problem scenarios 323 E/AS task 475
log entry 376 Event/Automation Service task 475
message 375 start, stop commands 475
problem background worksheet 317 suspended, topology manager 335
recovery from trace error 429 swapping memory, workstation operating system 19
suspended 335 symptom
TOPOSNA LISTxxxx request 429 abend (abnormal end)
trace 415 0C1, RODM 253
VTAM CMIP trace 429 0C4 56
SNA Workload Server Details 0C4, RODM 253
Data Collection tower or subtower 0C8, RODM 255
ACTIVEACTIVE.LIFELINE 513 301 56
SNMP trap problems 9C5 (reason code 0), RODM 256
not converted to alerts 489 9C5 (reason code 33), RODM 256
not forwarded 488 A78 received at NetView termination 54
SOCKET TCxx trace record, IP services 132 A78 received at task termination 54
Software Support after topology manager initialization 332
contacting 3 during topology manager initialization 331
describing problems 4 FLBTOPO task 331
determining business impact 4 keyword (ABEND) 13
receiving weekly updates 7 linearization processing 56
submitting problems 5 RID (remote interactive debug) function 59
software support database, searching solutions 3 RODM, when topology manager starting 256
solicited remote data not recorded 71 subtask 53
Stack 160 topology manager error condition 332
Stack Configuration and Status 511 U0258 54
statistical report, RODM dump utility 310 U0268 54
status U0269 54
not updated for resource abnormal reaction from RODM 259
problem scenario and resolution 195 APM
problem scenario and resolution cannot initiate IP session using NETCONV 188
alerts do not change status 186 NETCONV, cannot initiate IP session 188
problems and resolutions 194 application failure, RODM 249
solicitation failure asynchronous method loop, RODM 257
GMFHS 193 automatic monitoring, topology manager 336
status monitor automation
CNMDMCT control block 589 not driven when expected 67
internal trace (CNMTARCA) not occurring correctly 66
activity (VY) record 139 unexpectedly driven 66
correlation Identifiers 140 blank status history 346
force INACT (FINA) record 139 cannot find LU with locate resource 346
MONIT (VMON) record 139 cannot issue resource control command
operator command (OC) record 139 generic commands fail 347
resource status change processed (CE) record 139 cannot obtain topology data 337
status monitor preprocessor, job output checkpoint processing fails, RODM 258
documenting a problem command
documentation needed 24 cannot initiate IP session using NETCONV 188
status problems NETCONV, cannot initiate IP session 188
changes to resources not reflected in views 196 debugging method, RODM 248
incorrect resource status 194 distributed mainframe server error not recorded 71
multiple Init_Accept flows received 196 documentation problem
resource exists but status is not updated 195 keyword (DOC) 15
status solicitation failure DSIFRE message 60
GMFHS 193 DSIGET message 61
Index 673
symptom (continued) symptom (continued)
EP/local error not recorded 70 message (continued)
hung, topology manager FLB403I 337
RODM checkpoint 335 FLB404I 343
incorrect output FLB405W 342
EKGPRINT data set, RODM 258 FLB407E 344
keyword (INCORROUT) 15 FLB408W 344
incorrect view FLB409W 337
aggregate resource status incorrect 361 FLB420I 337
class of node object is incorrect 350, 367 FLB421I 343
multiple subnetworks in same view 366 FLB422W 342
resource not in view 340, 350 FLB424E 344
resource status incorrect 357 FLB425W 344
resource status unknown 354 FLB426W 337
unexpected resource in view 347, 368 FLB443I 343
view cannot be displayed 350, 362 FLB481E 334
view disappears 350, 362 FLB482E 329, 334
initialization failure, topology manager FLB485E 329
cannot access RODM 329 FLB486I 335
cannot access VTAM CMIP services 328 FLB540I 337
error reading customization table 327 FLB541W 342
error reading file FLBSYSD 326 FLB542E 344
not enough storage 326 FLB544W 337, 344
severe error 327 FLB584I 343
warning error 327 FLB610I 343
wrong autotask 326 FLB677E 328
linearization processing problem 56 FLB684E 334
list of problem scenarios FLB685W 337, 344
E/AS 469 IEC161I 052-084 258
Event/Automation Service 469 IEC161I 203-204 251
GDPS Continuous Availability solution 167 IEC161I 227-229 258
MultiSystem Manager 437 IEC340I 258
NetView management console 183 incorrect output in EKGPRINT data set, RODM 258
NetView program 51 keyword (MSG) 17
RODM 245 monitor operation unexpectedly ended
SNA topology manager 323 lost connection with agent node 344
sysplex 157 monitor completed 343
Z NetView Enterprise Management Agent 507 stopped by TOPOSNA STOP command 342
logon/bind problem with command facility 52 topology manager ended 343
loop VTAM CMIP services ended 343
asynchronous method, RODM 257 MS transport cancels 66
keyword (LOOP) 16 NetView operator cannot browse archived data 70
user application, RODM 257 not attempting to archive Canzlog data 69
message object missing attribute value, RODM
CNM983E 59 agent not reporting attribute 339, 340
CNM998E 59 log entry 78-25 339
CNM999E 59 not monitoring correct type of topology 339
DSI124I 59 unsupported attribute 339
DSI625I 55 object not purged
DWO049W 60, 61 error purging object 349
DWO090A 63 log entry 78-71 349
DWO158W 64 object being monitored 347–349
DWO627E 66 object unexpectedly purged
EKG1101E 251 by a topology update (link object) 353
EKG1104E 258 by a topology update (node object) 350, 367
EKG1105E 258 by a topology update (TG object) 353
EKG1106E 258 by TOPOSNA PURGE command 350, 362
EKG1111I 251 performance problem
EKG1112E 258 keyword (PERFM) 19
EKG1113I 258 problem scenario, NetView program 57
EKG1116I 260 resource control requests do not work
EKG1117I 260 incorrect NetView management console
EKG1326D 256 command profile 347
FLB300W 335 return code

symptom (continued) Tivoli (continued)
return code (continued) user groups xxiv
U0258 abend code 55 Tivoli Software Information Center xxiv
U0268 abend code 55 topology console
U0269 abend code 55 hangs during sign-on
return code, RODM problem scenario and resolution 198
12, reason code 121 251 hangs when accessing view
12, reason code 122 251 problem scenario and resolution 198
12, reason code 194 252 problem scenarios and resolutions 197, 199
12, reason code 20 250 problem with minimized windows
12, reason code 211 254 problem scenario and resolution 198
12, reason code 212 254 unable to connect from
12, reason code 213 254 to topology server 197
RMTCMD RUNCMD response on MVS console 72 topology console problems
security problem 73 connection status problem
slow response from RODM 260 problem scenario and resolution 194
solicited data not recorded 71 display for subsystem view not complete
suspended, topology manager problem scenario and resolution 213
RODM checkpoint 335 duplicate GMFHS resource
unexpected reinitialization, topology manager 335 problem scenario and resolution 198
unexpected shutdown, topology manager problem with minimized windows
log entry 78-0 334 problem scenario and resolution 198
storage shortage 334 property changes lost
unrecoverable RODM error 334 problem scenario and resolution 199
VTAM CMIP services ended 334 topology console hangs during sign-on
unsolicited remote error not recorded 71 problem scenario and resolution 198
user API does not return from EKGWAIT, RODM 257 topology console hangs when accessing view
user application loop, RODM 257 problem scenario and resolution 198
wait unable to connect to topology console from topology
keyword (WAIT) 20 server
sysplex problem scenario and resolution 197
list of problem scenarios 157 topology manager, SNA
system hung 335
problems suspended 335
information required for TSC 177 topology server
system-related information unable to connect to
problem worksheet from topology console 197
NetView management console 173 topology server problems
incorrect timestamps if topology server is on Windows
platform
T problem scenario and resolution 200
TAKESOCKET trace record, IP services 132, 133 server does not complete initialization on AIX
task utilization data in SMF log 99 problem scenario and resolution 200
TASKMON command 19, 336 server windows disappear on AIX
TASKMON command output 96 problem scenario and resolution 200
TASKURPT trace, GMFHS
commands 548 description 219
examples 549 event manager task tracing 223
syntax diagram 547 IPC task tracing 223
TASKUTIL command 19 starting 220
TASKUTIL command output 96 stopping 220
TCPIP TRACE command 219
Active Connections 511 using in-storage trace table 222
Inactive Connections 510 viewing output online 221
TCPX trace record, IP services 138 trace, NetView
Telnet Server 511 documenting a problem
TERMAPI trace record, IP services 133 documentation needed 23
TestMode statement, using 497 trace, NetView program
TIME trace record 117 capture first failure data 150
timeout failures 441 CNMTARCA module trace record 138
timestamps external trace
incorrect if topology server is on Windows platform table example 104
problem scenario and resolution 200 first failure data capture 150
Tivoli GMFHS TRACE command 219
Index 675
trace, NetView program (continued) trace, SNA topology manager (continued)
internal trace GTF record format (continued)
IP services 117 multi-record event 415
status monitor 138 internal trace buffer
table example 102 description 418
internal trace dataspace 109 format 418
IP services, internal trace 117 record header 418
locating when MODE=INT 100 NetView trace
MONOPER keyword 106 allocate storage request 148
NetView TRACE command 100 array, allocate storage request 148
PPI trace facility free storage request 149
description 151 reallocate storage request 149
GTF output files 156 storage request 148
locating oldest record 155 record format
locating table 155 4000-0002 (CENT) 420
trace anchor block 151 4000-0003 (CEXT) 420
trace record 152 4001-0008 (LOGS) 421
trace table 151 4002-0007 (MSGS) 421
printing record 4003-000E (CMIP) 422
when MODE=EXT 103 4004-0019 (RTIB) 423
when MODE=INT 100 4004-001A (RARY) 423
record 4005-0015 (RCLS) 424
constant for option byte (DSIPSS) 115 4005-0016 (RON) 424
description 108 4005-0017 (ROBJ) 425
DSIGET/DSIFRE 114 4005-0018 (RATR) 425
DSIPSS 115 4007-001E (UPDT) 426
DSIWAT/DSIPOS/DISPATCH 114 4008-0000 (GET) 426
installation exit (UX) 112 4008-0001 (FREE) 427
lost 114 4009-0006 (FSM) 427
LUC macro invocation 110 400A-0004 (NEW) 427
LUC receive exit 110 400A-0005 (DEL) 428
message queuing service (MQS) 111 400A-001B (CBEG) 428
MODE=EXT 103 400A-001C (CEND) 428
MODE=INT 101 400A-001D (XMOG) 429
module entry (MENT) 113 CBEG (400A-001B) 428
module exit (MXIT) 113 CEND (400A-001C) 428
presentation services (DSIPSS) 115 CENT (4000-0002) 420
TIME record 117 CEXT (4000-0003) 420
trace table header 109 CMIP (4003-000E) 422
VPDTASK trace record 112 DEL (400A-0005) 428
SAF (security authorization facility) trace record 140 FREE (4008-0001) 427
SNA topology manager FSM (4009-0006) 427
allocate storage request 148 GET (4008-0000) 426
array, allocate storage request 148 LOGS (4001-0008) 421
free storage request 149 MSGS (4002-0007) 421
reallocate storage request 149 NEW (400A-0004) 427
storage request 148 RARY (4004-001A) 423
starting 100 RATR (4005-0018) 425
status monitor, internal trace 138 RCLS (4005-0015) 424
stopping 100 ROBJ (4005-0017) 425
TRACE command 100 RON (4005-0016) 424
when to use 100 RTIB (4004-0019) 423
trace, RODM UPDT (4007-001E) 426
description 301 XMOG (400A-001D) 429
internal 301 starting and stopping 415
trace, SNA topology manager tracing, E/AS 493
category tracing, Event/Automation Service 493
performance consideration 20 trap problems
GTF event ID 415 NetView management console 174
GTF format ID 415 trap-to-alert service
GTF record format recycling 490
data format 416 tree view list is incorrect
example 416 problem scenario and resolution 204
header 415 troubleshooting

troubleshooting (continued) view problems (continued)
GMFHS (Graphic Monitor Facility host subsystem) 183 topology console hangs when accessing view (continued)
NetView management console 183 problem scenario and resolution 198
NetView program 51 topology display subsystem view not complete
typeface conventions xxv problem scenario and resolution 213
tree view list is incorrect
U unable to monitor views of your network
unable to connect problem scenario and resolution 207
to topology server from topology console unable to open view
from topology console 197 problem scenario and resolution 206
problem scenario and resolution 197 view does not contain resource
unable to monitor views of your network problem scenario and resolution 208
problem scenario and resolution 207 view layout is incorrect
unable to open view problem scenario and resolution 205
problem scenario and resolution 206 view shows incorrect connectivity
unexpected reinitialization, topology manager 335 problem scenario and resolution 207
unexpected shutdown, topology manager 334 view shows incorrect connectivity
unrecoverable RODM error 334 problem scenario and resolution 207
unsolicited remote error not recorded 71 views
user abend, SNA topology manager 332 status changes not reflected in
user API does no return from EKGWAIT 257 problem scenario and resolution 196
user API does not return from EKGWAIT, RODM 257 Views
user application loop, RODM 257 problem scenarios and resolutions 202
user group, NetView xxv views of your network, unable to monitor
user groups problem scenario and resolution 207
NetView xxv VIPA
Tivoli xxiv Routes 511
using commands 491 VMON (MONIT) trace record 139
using TestMode statement 497 VPDTASK trace record 112
UX trace record 112 VSAM Replication Details
Data Collection tower or subtower
ACTIVEACTIVE.REPLICATION.VSAM 513
V VTAM CMIP
cannot access services 328
variables, notation for xxv
services ended 334, 343
VERBX CNMIPCS command summary 78
VY (activity) trace record 139
view does not contain resource
view does not open W
view layout is incorrect wait
problem scenario and resolution 205 diagnostic procedure 38
view problems documenting procedure 38
cannot navigate between object and contained keyword (WAIT) 20
resources reporting procedure 38
problem scenario and resolution 212 WAIT command 570
information displayed for object changes WAIT keyword 20
problem scenario and resolution 211 wait problems
multiple objects with same object NetView management console 175
problem scenario and resolution 210 window
pop-up menu in business tree not displayed problem when minimizing
problem scenario and resolution 213 problem scenario and resolution 198
preview image partially painted windows
problem scenario and resolution 213 for server disappear on AIX
real resource not shown as member of object problem scenario and resolution 200
problem scenario and resolution 211 Workload Lifeline Advisors
requested configuration is missing Data Collection tower or subtower
problem scenario and resolution 202 ACTIVEACTIVE.LIFELINE 513
requested more detail view is missing Workload Servers
problem scenario and resolution 202 Data Collection tower or subtower
resource icon missing from view ACTIVEACTIVE.LIFELINE 513
problem scenario and resolution 204 Workload Site Details
topology console hangs when accessing view Data Collection tower or subtower
ACTIVEACTIVE.LIFELINE 513
Index 677
Workload Sites
Workloads
worksheet, problem
AON 447
E/AS 461
Event/Automation Service 461
GMFHS 177
MultiSystem Manager 433
NetView management console
abend problems 174
documentation problems 176
general information 173
incorrect output problems 176
loop problems 175
message problems 174
performance problems 176
problem classification 174
problem description 174
system-related information 173
wait problems 175
NetView program 45
RODM 239
Z NetView Enterprise Management Agent 501
wrong autotask, topology manager 326
X
XCF services
BNH067I message 162
BNH558E message 163
BNH587I message 161
discovery commands fail 162
master NetView, unexpected switch 162
no data returned 161
PLEXCTL command fails 162
START XCFGROUP problems 162
unable to contact enterprise system 163
unexpected switch of master NetView 162
Z
Z NetView Enterprise Management Agent
diagnostic tools 519
list of problem scenarios 507
problem background worksheet 501
problem determination 507
z/OS
instrumentation problems and resolutions 193
z/OS Workload Server Details

IBM®
GC27-2865-05

Troubleshooting Guide

Uploaded by

Copyright:

Available Formats

Troubleshooting Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting Guide

Uploaded by

Copyright:

Available Formats

IBM Z NetView

Part 1. Getting started with troubleshooting...........................................................1

Chapter 1. Diagnosing problems................................................................................................................. 3

Chapter 2. Classifying problems............................................................................................................... 13

Chapter 3. Documenting and reporting problems.................................................................................... 23

Part 2. Diagnosing the NetView program.............................................................. 43

Chapter 4. NetView program problem worksheet.................................................................................... 45

Chapter 5. Troubleshooting and initial diagnosis for the NetView program............................................ 51

Chapter 7. Troubleshooting and initial diagnosis for IP Management...................................................157

Chapter 8. Diagnostic tools for IP Management.....................................................................................165

Part 3. Diagnosing NetView Management Console and GMFHS problems............. 171

Chapter 10. NetView Management Console problem worksheet..........................................................173

Chapter 11. Graphic Monitor Facility Host Subsystem problem worksheet..........................................177

Part 4. Diagnosing NetView REST Server problems............................................. 225

Chapter 14. NetView REST Server problem worksheet......................................................................... 227

Chapter 16. Diagnostic tools for NetView REST Server..........................................................................235

Part 5. Diagnosing RODM problems.................................................................... 237

Chapter 17. RODM problem worksheet.................................................................................................. 239

Chapter 18. Troubleshooting and initial diagnosis for RODM................................................................ 245

Part 6. Diagnosing SNA Topology Manager problems...........................................315

Chapter 20. SNA Topology Manager problem worksheet...................................................................... 317

Part 7. Diagnosing MultiSystem Manager problems.............................................431

Chapter 23. MultiSystem Manager worksheet....................................................................................... 433

Part 8. Diagnosing Automated Operations Network problems............................. 445

Chapter 25. AON problem worksheet.....................................................................................................447

Chapter 26. Troubleshooting and initial diagnosis for AON................................................................... 453

Part 9. Diagnosing Event/Automation Service problems......................................459

Chapter 27. Event/Automation Service problem worksheet................................................................. 461

Chapter 29. Diagnostic tools for the Event/Automation Service............................................................491

Part 10. Diagnosing Z NetView Enterprise Management Agent problems............. 499

Chapter 30. Z NetView Enterprise Management Agent worksheet....................................................... 501

Appendix A. Diagnostic command summary....................................................... 539

Appendix B. Flows and control blocks................................................................ 571

Appendix C. RECFMS record formats.................................................................. 591

Appendix D. DSINDEF data set format................................................................637

Appendix E. MDB to AIFR cross-reference.......................................................... 643

1. The Diagnostic Path for Classifying, Documenting, and Reporting Problems........................................... 11

2. NetView Error Message Format.................................................................................................................. 18

3. Sample memory dump of a NetView ABEND............................................................................................. 29

4. Sample memory dump Data of an FLBTOPO ABEND.................................................................................32

5. Example of the DSI625I message.............................................................................................................. 55

6. Diagnosing a Storage Overlay Problem Using IPCS................................................................................... 61

7. Diagnosing a Control Block Overwrite Problem Using IPCS...................................................................... 66

8. Syntax of the CNMIPCS Routine................................................................................................................. 77

9. Example of Summary Output......................................................................................................................82

10. Example of Output from the ASID Command.......................................................................................... 82

11. Example of Output from the CPOOL Command....................................................................................... 83

12. Example of Output from the D Command................................................................................................ 84

13. Example for Output from the IPCS DISPLAY Command..........................................................................85

14. Example of Output from IPCS DISPMOD Command................................................................................86

15. Example of Output Produced Using the DTCB Command....................................................................... 86

16. Example of Output from the IPCS LRCE Command................................................................................. 87

17. Example of Output from the MAP Command........................................................................................... 88

18. Example of Output Produced Using the MAP(sum) Command............................................................... 88

19. Example of Output from the NLDM Command.........................................................................................90

20. Example of Output from the NPDA Command......................................................................................... 91

21. Example of Output from the IPCS QUE Command.................................................................................. 92

22. Example of Output from the SAVEAREA Command.................................................................................92

23. Example of Output from the IPCS STORE Command.............................................................................. 93

27. Example of Output from the WHO Command.......................................................................................... 95