COMM-PRO

HNAS VnRnMn
ACTIVE PROBLEM SUMMARY

This HNAS Active Problem Summary documentation area provides information on open problems (currently being analyzed, pending an action, or pre APAR assignment).  Open problem entry reports relating to custom enhancements (CustomUserMods) provided to customers (in test mode) are also located in this section.  Some problem entries never make it into this log because there is typically a 2-3 day lag period before problem entries are recorded here.  If an APAR for the condition is generated during the lag period the problem entry won't be published although the APAR will be publish with notation (was unpublished problem yyyyjdti).    

This section is provided to assist customers in their identification of problems for troubleshooting and fault isolation by identifying problems currently under review or analysis, and identifying non APAR problems or anomalies deferred to a later HNAS release.  Please contact your HNAS first level technical support representative or access their problem reporting system for specific problem tracking; or refer to the respective APAR Maintenance Summary sections for APAR activity.  Problem summary entries are in the same format as our APAR memo's for ease of viewing and eventual conversion to actual APARs, as required.  APAR entries provide standard corrective logic (PTF) maintenance, instructions on circumventing various problems (configuration changes, etc.) and may defer correction to a later HNAS VnRnMn release.  Some problem log entries may contain circumventions in lieu of APAR assignment pending resolution in a later release.

Related sections:  HostNAS VnRnMn APAR Assignment Cross Reference List
                           HostNAS VnRnMn Maintenance (APAR and PTF) Information Summaries
                           HostNAS VnRnMn Product Information References,    see Custom User Enhancements
                           HostNAS VnRnMn Problem Summary (Pre APAR/PTF and Non-APAR) Information,
                           HNAS Problem Summary  and  HNAS Problem Summary History 

                                          HNAS Problem Summary Matrix

IBM Problem Maintenance Records (HNAS Associations)  

Please refer to the HNAS Problem Summary History link 
for information
on inactive or closed IBM PMR's. 

HNAS Problem Summary Detail Follows:

2010-mm-dd  - PROBLEM 2010nnnA

 PROBLEM_ID:  2009nnnA
     STATUS:  PENDING
  OPEN_DATE:  2010-mm-dd
REVISE_DATE:  N/A
 CLOSE_DATE:  2010-mm-dd
 SERVICE(S):  .

              Additional information will be provided as available.

2010-09-08  - PROBLEM 2010243A
              
 PROBLEM_ID:  2010243A
     STATUS:  CLOSED
  OPEN_DATE:  2010-08-31
 CLOSE_DATE:  2010-08-31
 SERVICE(S):  z/OS V1R11 TCP/IP interface support (TAKESOCKET logic)
  MANDATORY:  YES
 ORIGIN/REF:  240_LPT
    CP-TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  See IBM PTF UK57562 APAR PM18321

   OVERVIEW:  NASHALT 0198 ABEND occurs during TAKESOCKET processing.

    PROBLEM:  The TAKESOCKET command fails with ERNO=113 which says
              'the socket was already taken' followed by the NASHALT.

DESCRIPTION:  The TAKESOCKET command was introduced into HNAS by APAR
              2100011 for z/OS V1R2 support in May, 2002.  The command
              is required as part of the socket establishment process.
              The command has worked properly for every z/OS release
              since that time except for V1R11.  We suspect a bug was
              introduced into the TCP/IP stack for z/OS V1R11 that
              caused the TAKESOCKET command to fail.

              Note: This problem seems to occur only when IBM APARs
                    PM01000 or PM13795 are applied to a z/OS V1R10
                    or V1R11 system.  Also, for z/OS V1R12 which
                    includes these APARs.

   SOLUTION:  Apply IBM PTF UK57562, APAR PM18321 to fix this problem.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A

2010-01-20  - PROBLEM 2010018A  (see also 2007178A)
              Same as unpublished problems 2009111A and 2009118A)
              
 PROBLEM_ID:  2010019A
     STATUS:  OPEN, under analysis/debugging
  OPEN_DATE:  2010-01-18
REVISE_DATE:  2010-01-19
REVISE_DATE:  2010-01-20 - IBM PMR (22974,000,858) assigned
 CLOSE_DATE:  2010-mm-dd
 SERVICE(S):  TCPIP Application Program Interface
  MANDATORY:  TO BE DETERMINED (TBD)
 ORIGIN/REF:  240_FIS
  CUST_TECH:  NICOLAS
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  TBD

    PROBLEM:  NASHALT - HALT AT LOC 8006DB3A IN NASTCP  :
              TCPIP REPLY ID FAILURE

DESCRIPTION:  *** Orginally reported in April, 2009 ***

              We are seeing TCPIP SELECT commands that do not end.
              A TCPIP SELECT command is used by HNAS to monitor a
              socket connection for input data (REMOTE sockets) or
              for inbound socket connection requests (LOCAL socket).
              When a SELECT is issued, HNAS conditions it to end
              because data or a connection has arrived or when the
              stack sees no activity on the socket for one minute
              (this stack timeout duration is set by HNAS when the
              SELECT is issued).  In addition, HNAS runs it's own
              background timeout of 90-seconds to catch a SELECT
              that does not end which appears to be the case based
              on NAS2252E messages that have been logged.

              Note that a SELECT not ending indicates that there is
              a problem with the TCPIP stack because it should end
              each SELECT with either data (REMOTE), connection
              received (LOCAL) or when the 1-minute stack timer
              expires.  The 90-second timer that HNAS runs is meant
              to recover from a SELECT that is not ended by the stack.
              This logic was added years ago and PMRs were opened with
              IBM but a fix was never provided.  The original PMRs
              were 55314,227 82217, 82661 and 82706.

              The current NASHALT condition (0198 ABEND) occurs
              because HNAS receives an invalid reply ID for a command
              it has issued.  This is the same problem we have seen
              at 2 other customers.  We believe it is related to the
              missing (or more properly stated) delayed SELECT ending.
              Note that when the HNAS 90-second background SELECT
              timer expires, HNAS CANCELs the outstanding SELECT which
              should imply that a subsequent (delayed) SELECT ending
              should not occur.  This does not seem to be the case.

              *** Newly reported NASHALT on January 18, 2010 ***

              After reviewing the ABEND dump sent to us by the
              customer, we have observed the following:

              The ABEND is occurring because HNAS is processing a
              TCPIP interrupt for the server socket (LOCAL Process
              Control Element - PCE) and the interrupt ID is not
              what HNAS expects.  For the server PCE, HNAS normally
              keeps a TCPIP SELECT command active so that incoming
              connections can be processed.

              The SELECT can end when an inbound connection is
              received or after a 60-second timeout expires.  In the
              latter case, the SELECT is simply re-issued.  As it
              turns out, the SELECT is ending to process an inbound
              connection.  In this case, HNAS issues a TCPIP ACCEPT
              command for the server PCE to accept the connection.
              The ABEND is occurring because HNAS is getting another
              SELECT ending when it expects an ACCEPT ending.  The
              SELECT ID does not match the expected ACCEPT ID.  The
              DUMP reveals that the HNAS main task is processing
              the second SELECT ending with an ACCEPT command running.
              Looking ahead in time, there are 21 other TCPIP
              interrupts that have to be processed at the task level.
              Of these, there are 3 more SELECT endings with the same
              SELECT ID as before followed the expected ACCEPT ending.
              This suggests a problem in the TCPIP stack since every
              command except the CANCEL command should have only one
              ending.  The CANCEL command is an exception since two
              endings are expected.  One for the command being
              CANCELed and the other for the CANCEL command itself.

              New PMR(22974,000,858) was opened for this problem 
              superseding old PMR(58533,001,822) which was closed.

              Note: The DUMP also shows that 6,740,331 TCPIP commands
                    were successfully executed before the ABEND
                    occurred.  HNAS had been running for 2 hours,
                    50 minutes and 31 seconds.  This translates to
                    an average of 658 TCPIP commands per second
                    being executed.  This does not seem to be an
                    exorbitant rate.  However, unforeseen problems
                    can arise if HNAS is not running at the same
                    dispatch priority as TCPIP and in non-swappable
                    mode. It is very important to make sure that
                    HNAS operates in this way.

   SOLUTION:  TBD

CIRCUMVENTION: N/A

 APPLY_INFO:  TBD 

2010-01-13  - PROBLEM 2009355A

 PROBLEM_ID:  2009355A
     STATUS:  CLOSED
  OPEN_DATE:  2009-12-21
REVISE_DATE:  2009-mm-dd
 CLOSE_DATE:  2010-01-13
 SERVICE(S):  DTF
  MANDATORY:  N/A
 ORIGIN/REF:  240_cns
  CUST_TECH:  N/A
    CP_TECH:  prt
    PUBLISH:  YES
   PTF_INFO:  N/A
  PTF_CLASS:  N/A
   --------

   OVERVIEW:  See problem

    PROBLEM:  NAS5727E RECEIVED 2ND MSG FROM RMT rmt-nm  FOR LU lu-name
              ON MCH mch-nmme DATA=xxxxxxxx

DESCRIPTION: The customer configured the Datafono LU with OPTIONS=DATAF.
             This option indicates that the PLU wishes to process the
             D-- Datafono response message sent by the remote Datafono
             device when it receives an 'M' message from the PLU.
             That is, when a D-- response is received by HNAS, a D--
             input message is sent to the PLU to inform it that the
             remote has responded to the 'M' message from the PLU.
             We believe that when this option is specified the PLU
             should not send a second 'M 'message until it has received
             a D-- message from the remote for the first 'M' message.

   SOLUTION:  Customer changed HNAS CDF from OPTIONS=DATF to DATAFAM.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A

2008-12-24  - Active Problem Summary information area now available.

Last Update - September 8, 2010