II12453: NON-CODE PROBLEMS IN TIVOLI NETVIEW 1.3 R400 NVINFO

APAR status

• Closed as canceled.

Error description

• Information apar for non-defect related problems:
  5697B8200 r400 tme10 netview for 1.3 nvinfo
  ***********************************************************
  Problem:  Unexpected routing of SSI netview commands to a
  different LPAR in a SYSPLEX.
  Solution:  There is a new keyword documented in the Installation
  manual for use in start proc CNMSJ010 Netview SSI that makes use
  of a new MVS SSI feature. ( CPF )
      The keyword is PFXREG=ONE/ALL/NONE and can preempt local
  processing of Netview SSI generated commands and force them to
  a single Netview SSI and related Netview application address
  space.  If the new target does not have the console id
  coded on an autotask keyword CONSOLE=xxxxx then the command
  will be rejected.
     It is recommended for SYSPLEXs with mixed releases of
  Netview that the keyword be coded NO.
  ****************************************************
  Problem:  Following messages are issuing during
  NetView initialization as a result of the STARTCNM ALL command
  issued via CNME1034:
  FLB447I SNA TOPOLOGY MANAGER IS INITIALIZING
  FLB301E RODM ERROR ENCOUNTERED ON RODM FUNCTION 1101 FOR OBJECT.
  FLB483W SNA TOPOLOGY MANAGER FAILED TO CONNECT TO RODM 'RODMNAME
  DSI530I 'DUIFEAUT' : 'OST' IS READY AND WAITING FOR WORK
  FLB678W SNA TOPOLOGY MANAGER FAILED TO CONNECT TO CMIP SERVICES.
  Solution:  See help for each message if you want to use
  SNA Topology Manager.  If you don't intend to use SNA Topology
  Manager, then you will need to edit the STARTCNM (CNME1015)
  Rexx exec by editing the following lines:
  1.  Comment out line 43:
  /*        slist3.2  = 'AUTOTASK FLBTOPO'    */
  2.  Change line 44 as follows:
      snum = 1
  *
  The above will prevent FLBTOPO autotask from starting when a
  STARTCNM ALL (which is the NetView default) is issued. FLBTOPO
  autotask is the SNA Topology Manager autotask that connects to
  RODM at initialization.
  *************************************************************
  NETVASIS PIPE UNIX ls -al | CORRWAIT 10 | CONSOLE
  The above command is issued from NetView to the
  CNMEUNIX unix server.  Nothing gets returned to the NetView
  operator who issued the command.  However, in the job output
  for CNMEUNIX and in the cnmeunix.stdout file, the following
  is returned:
  9 Aug 2000 09:57:34, Specified PPI receiver, AO#00030, nota
     available
  No other errors are preceded or followed by this error.
  ANSWER:
  If the above is true and no other errors precede the above error
  then the problem is most likely that the CORRWAIT value
  is too low.   The above error will also occur if the
  CORRWAIT stage is omitted from the PIPE UNIX.
  PIPE UNIX must contain the CORRWAIT stage and the
  CORRWAIT must be long enoough.  The value
  CORRWAIT depends on the individual customer's environment.
  Test with larger CORRWAIT values.
  (S. Jacobs)
  ***************************************************************
  PROBLEM:  Commands issued from NetView are echoed twice in the
  syslog.  Once under the STC of the NetView issuing the command
  and once under the STC of the second NetView running in the same
  host.  Also, commands issued from the MVS console are being
  echoed in the syslog twice.  The second echo is issued under
  NetView's STC id.
  WORKAROUND:  Issue STOP TASK=CNMCSSIR from NetView and then
  restart it with EXCMD AUTO1,START TASK=CNMCSSIR.
  CONCLUSION:  Make sure you have an authorized message
  receiver logged onto NetView (code AUTH=MSGRCVR in an
  autotask's logon profile) or better yet, update your MPFLST
  to include a .NO_ENTRY AUTO(NO).
  WITH 2 NETVIEWS AND MVS CMD IS ENTERED FROM NETVIEW:
  The problem is caused by the second NetView having
  an ALWAYS DISPLAY(Y) coded in the automation table or a
  specific entry in the automation table which traps the reply of
  the MVS command and specifies DISPLAY(Y) with no associated
  ROUTE parameter to route the message.  In NetView 1.3 the PPT
  task starts CNMCSSIR.  When the response to the MVS command
  comes into the second NetView as an unsolicited message,
  the message runs through automation under the PPT.  If no ROUTE
  is specified when DISPLAY(Y) is matched for the message, then
  the message will go to the PPT.  Any messages the PPT needs to
  DISPLAY, will either be displayed at the authorized message
  receiver or if no message receiver is logged on, then the
  message will be output to SYSOP (system console).  This is the
  PPT's automation flow and is documented in the Automation.
  Guide.
  WITH ONE NETVIEW AND CMD IS ENTERED FROM MVS CONSOLE:
  The solution is the same in that an authorized message receiver
  needs to be logged onto NetView.  However, this authorized
  message receiver will receive anything that has DISPLAY(Y)
  coded in the automation table and no ROUTE specified.  The
  better solution would be to code a .NO_ENTRY AUTO(NO) in the
  MPFLSTxx member of SYS1.PARMLIB.  This would cut down on the
  cpu utilization as well that CNMCSSIR uses.
  **********************S. Jacobs
  BELOW ARE THREE COMMON SCENARIOS CUSTOMERS MAY RUN INTO
  WHILE RUNNING NETVIEW 1.3 AND RECEIVING UNSOLICITED
  MVS MESSAGES:
  1. ALWAYS DISPLAY(Y) coded in automation table, no ASSIGN
     exists for the message and no authorized receiver
     logged on.
  ===> WTO received by CNMCSSIR will be displayed to system
  console.  The effect is duplicate messages on the syslog.
  The customer should always have an authorized receiver
  logged onto NetView.  If this authorized receiver is a real
  ost (not an autotask), then the real ost will see all of
  these unsolicited MVS messages.  If this authorized receiver
  is an autotask, then the autotask will get presented the
  unsolicited MVS messages, but the messages won't be displayed
  anywhere unless the autotask is associated with a physical
  MVS console.
  THE RECOMMENDATION IS FOR THE CUSTOMER TO
  TUNE THEIR MPFLST SO THEY KNOW WHAT MESSAGES ARE COMING INTO
  NETVIEW. MANY CUSTOMERS HAVE AN MPFLST .NO_ENTRY AUTO(YES)
  AND THIS CAUSES UNNECESSARY CPU UTILIZATION BY CNMCSSIR.
  ANOTHER RECOMMENDATION WOULD BE TO CREATE AN AUTHORIZED MESSAGE
  RECEIVER WHO IS ALSO AN AUTOTASK.
  2.  EXEC(CMD('xyz') ROUTE(ONE *)) in automation table.  xyz exec
      contains an &WAIT.  &WAIT is not allowed to run under PPT
      so NetView issues an error message and exec fails.
  ===> In NetView 1.3, unsolicited MVS messages received over the
  SSI presented to CNMCSSIR.  Then, the message is checked
  for ASSIGN processing.  If no ASSIGN exists for the message,
  CNMCSSIR runs through the automation table.  If a match on
  EXEC statement, then CNMCSSIR sends the exec to run under the
  operator who started CNMCSSIR.  This operator is the PPT in
  NetView 1.3.
  THE RECOMMENDATION IS TO CODE AN OPERATOR TASK WHO IS ALWAYS
  LOGGED ON INSTEAD OF '*'.
  3.  ALWAYS DISPLAY(Y) coded in automation table and no
  authorized receiver logged on.
  ===> Customer is receiving numerous E type (external) messages
  from MVS.  When display(y) is coded in automation table
  and automation is run under the PPT, the PPT outputs the
  message to the authorized receiver.
  RECOMMENDATION IS TO CHOOSE AN OPERATOR TASK WHO IS ALSO
  AN AUTOTASK AS YOUR AUTHORIZED RECEIVER.
  **********************************************
  PROBLEM:  From AON panel FKXK2221, a user chooses PF4
  (commands) and then chooses DROP to drop a TN3270 session.  No
  response is received from the DROP and the session is not
  dropped.
  SOLUTION:  If you coded DEBUG on the EXEC statement of CNMSJTSO
  or CNMSSTSO, then you will see in the job output an error
  message saying that authority is denied for the DROP command.
  The NETSTAT DROP requires the following RACF definition in the
  profile of the user issuing the command.  In AON's case, you
  would need to code this in the RACF profile for the TSO ids
  which represent your TSO servers (see the TSOSERV keyword in
  FKXCFG01).
             MVS.VARY.TCPIP.DROP
  ***************************************************
  PROBLEM:  Customer issues:
  NETVASIS PIPE UNIX ls -al | corrwait 10 | console
  *
  and it fails.  They look in the /tmp/cnmeunix.stdout and find
  the following error.  Along with the error the Unix Server
  terminates:
  -4 "SPAWNP", 4, -1, 81, 594003D
  *
  The 003D is the reason code found in the OMVS Messages and
  Codes manual and it means that the file is not found.
  SOLUTION:  The path statement in CNMSJUNX incorrectly picked up
  the line number to the far right of the path statement because
  the customer was using an LU2 type session to edit his CNMSJUNX
  member.  The editor put the line numbers on the right side of
  the member.  When the customer changed his editor so that the
  line numbers were on the left, the Unix server started up and
  stayed up when a PIPE UNIX was issued.
  *********************************************************
  PROBLEM: AAU022i messages with aaudrbdb and/or aauspvsa with
  8/16 codes (record not found) during purge processing. You can
  ignore the message. Example :
  AAU022I AAUSPVSA  02 DBAUTO1  VSAM I/O COMPLETION FAILURE: VSAM
  R/C - 8 MINOR = 16, VSAM DATASET = AAUVSPL , KEY "CNMP1....
  These two modules, aaudrbdb and aauspvsa had been changed to
  perform an erase for all records on the database with the
  sessions being PURGED. These changes can result in an attempt
  to erase records that do NOT exist.
  SOLUTION: No action is necessary. Processing of the purge
  continues. NLDM is trying to erase records that are not found
  /are not there. If they were there, we would just be purging
  them anyways.  02/05/2001 ggg
  ****************************************************************
  NetView for z/OS ABENDS0C4 CNMCNETV+X'8E'.
  The customer was trying to use CNMCNETV to create an alert in
  z/OS NETVIEW V13 and was getting an ABENDS0C4 at CNMCNETV+X'8E'.
  .
  The code is checking a control block for the SSI descriptor(for
  example, NETV) and failed. A CLC instruction for the SSTDESC
  is the instruction involved at that location. Per the customer,
  code from the vendor was needed to add a SAC (set address space
  control) instruction. This instruction involves moving between
  primary/secondary modes and access register modes. The zap fix
  id from Landmark is RN00013. The offical PTF number from them
  is not known, so contact Lankmark with the zap number. ggg
  *************************************************************
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• closing
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels