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

Subscribe

You can track all active APARs for this component.

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 number

    II12453

  • Reported component name

    V2 LIB INFO ITE

  • Reported component ID

    INFOV2LIB

  • Reported release

    001

  • Status

    CLOSED CAN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2000-07-10

  • Closed date

    2000-07-10

  • Last modified date

    2003-06-30

  • 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



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

z/OS family

Software version:

001

Operating system(s):

MVS, OS/390, z/OS

Reference #:

II12453

Modified date:

2003-06-30

Translate my page

Machine Translation

Content navigation