COMM-PRO

HNAS VnRnMn
PROBLEM SUMMARY

This HNAS Problem Summary documentation area provides information on open problems (on-hold or pending-extended where a customer action with long term delays) or closed problems (a non APAR solution provided or resolution deferral 'Open, Deferred' to a later HNAS release yet to be implemented).  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 problem logs because there is typically a 2-3 day lag period before problem entries are recorded.  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, 
                           Active Problem Summary  or  Problem Summary History 

                                          HNAS Problem Summary Matrix

HNAS Problem Summary Detail Follows:

2009-01-29  - PROBLEM 2007178A

 PROBLEM_ID:  2007178A
     STATUS:  HELD, awaiting another failure (customer will get DUMP)
PREV_STATUS:  OPEN, under analysis 
  OPEN_DATE:  2007-06-27
PRVCHG_DATE:  2007-06-27
REVISE_DATE:  2007-07-18
REVISE_DATE:  2009-01-29 - changed status to on hold.
 CLOSE_DATE:  2007-mm-dd
 SERVICE(S):  TCPIP interface
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  240_BNP
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED (TBD)
  PTF_CLASS:  TO-BE-DETERMINED
   --------

   OVERVIEW:  see problem

    PROBLEM:  HALT AT LOC 80061022 IN NASTCP  : TCPIP REPLY ID FAILURE

DESCRIPTION:  This NASHALT occurs after a number of SELECT alarms of
              following form are generated:

              NAS2252E CLIENT=010.253.204.035(18640) SOCKID=0017
                       PCEID=010C NAME=XOTBNP3I
              NAS2252E SELECT REQUEST INTERRUPT LOST,
                       SOCKET MUST BE CLOSED

              This problem is reminiscent of a similar problem that
              was fixed by APAR 2300199.  Customer is running at the
              HNAS 2400021 level.

   SOLUTION:  TBD

              APAR 2400042 created to log additional information in
              TCPIP external interrupt table which supplies enough
              new data to make HNAS PCE traces unnecessary for this
              particular problem.

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED  

2007-07-18 - PROBLEM 2007151A

 PROBLEM_ID:  2007151A
     STATUS:  CLOSED
  OPEN_DATE:  2007-05-31
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-09-27
 SERVICE(S):  GATE
  MANDATORY:  TBD
 ORIGIN/REF:  240_TKK
  CUST_TECH:  BP
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
  PTF_CLASS:  N/A
   --------

   OVERVIEW:  see problem

    PROBLEM:  NAS4709W REMOTE L868 G2B00440 LU 001FC830 LUIQ TIMEOUT,
              LUIQ BFR CT=0002

DESCRIPTION:  This message indicates that HNAS has data for the GATE
              that cannot be delivered.  The above message follows:

              NAS7716W INBOUND GATE CALL REQ FROM 149.206.157.179 TO MCH
              L868 FAILED, CTCP CLR'D VIA LU R8068A01

              NAS7716W CAUSE/DIAG=000/064 (00/40) DIAGX=0000

   SOLUTION:  This problem was due to network circumstances:

              The customer used an ISDN-link with 2 B-channels,
              each with a speed of 64 kbps.  With his older ISDN-adapter
              he could not operate both channels in parallel.  He now
              uses a new and better ISDN-adapter of another vendor,
              so 2 incoming calls can be handled by HNAS.  2 SVC4 LUs
              are defined for this mch-link.  However under RVS the
              parameter MAXSVC was set =1 because of problems with
              the old isdn-adapter. This parameter now set to 2 so
              RVS can handle 2 incoming calls.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A  

2007-07-26  - PROBLEM 2007108B

 PROBLEM_ID:  2007108B
     STATUS:  CLOSED
  OPEN_DATE:  2007-04-19
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-07-26
 SERVICE(S):  LLC-0/5
  MANDATORY:  N/A
 ORIGIN/REF:  240_BBV
    CP_TECH:  PRT
    PUBLISH:  YES_(2007-08-03)
   PTF_INFO:  N/A
   --------

   OVERVIEW:  see problem

    PROBLEM:  Customer would like HNAS to establish an LLC0 callout
              without a BIND from the PLU.

DESCRIPTION:  Customer state that there is no way for IMS to acquire
              an HNAS SLU.  They want HNAS to send a call request.
              If a call accept is returned a REQSESS will start the
              session with the PLU.

   SOLUTION:  Current LLC0/5 definitions allow a connection identifier
              'I', 'O', or 'T'.  A new id of 'A' (autocall) could be
              to make HNAS initiate the call.

  SOLUTION2:  Customer found a way to get IMS to acquire the HNAS
              LU.  From Casimiro July 26 email:

              1.-Define the HNAS LUs in IMS.

              2.-IMS command : START LTERM ltermname
                 As in IMS, ltermname is the HNAS-slu-name.

              3.-IMS command : OPNDST NODE HNAS-slu-name.
                 HNAS-slu-name is the VTAM HNAS lu defined with the
                 VBUILD TYPE=APPL statement.

              The commands can be done via IMS autooperator or
              via System Automation.

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED  

2006-07-18  - PROBLEM 2006171A

 PROBLEM_ID:  2006171A
     STATUS: ON HOLD, customer using circumvention.
  OPEN_DATE: 2006-06-20
REVISE_DATE: 2006-07-17
 CLOSE_DATE: 2006-mm-dd
 SERVICE(S): GATE Fast Connect
  MANDATORY: TO-BE-DETERMINED (TBD)
 ORIGIN/REF: 230_LPT
    CP_TECH: PRT
    PUBLISH: YES
   PTF_INFO: TO-BE-DETERMINED
  PTF_CLASS: TO-BE-DETERMINED
   --------
 
   OVERVIEW: See Problem.

    PROBLEM: HNAS GATE FC control session does not reactivate
             when the PLU is recycled (FC=Fast Connect).

DESCRIPTION: PLU UNBINDs HNAS GATE FC CTL session LU. Session
             does not restart when PLU brought back up.

   SOLUTION: N/A

CIRCUMVENTION: Customer changed the CTCP take down procedure
               to include commands to take down the Application
               Major Node associated with the CSFI GATE FC MCH
               resources.

 APPLY_INFO: TO-BE-DETERMINED

2006-07-21  - PROBLEM 2006088B 

 PROBLEM_ID:  2006088B
     STATUS:  CLOSED - DEFERRED TO 240.
  OPEN_DATE:  2006-03-29
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-07-21
 SERVICE(S):  LU TRACE, GATE-FC
  MANDATORY:  NO
 ORIGIN/REF:  230_CP
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
   --------

   OVERVIEW:  <see problem>

    PROBLEM:  Trace is started on a GATE FC data session LU is
              not propagated to the VC when a session starts.
              If the default VC/LU traces are active there is no
              problem.  The difficulty occurs when a trace is
              started on a specific GATE FC LU the trace bit is
              not copied to the VC when the VC is connected to 
              the LU.

DESCRIPTION:  <see problem>

   SOLUTION:  <solution description>

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A  

2006-01-16  - PROBLEM 2006011N

 PROBLEM_ID:  2006011N

     STATUS:  CLOSED
  OPEN_DATE:  2006-01-11
 CLOSE_DATE:  2006-01-11
 SERVICE(S):  HNAS DATE Format
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_BNP
    CP_TECH:  CPT
    PUBLISH:  OVERVIEW
  PTF_CLASS:  N/A
   PTF_INFO:  N/A
   --------

   OVERVIEW:  N/A

    PROBLEM:  N/A

DESCRIPTION:  Date 
		formats for new memo entries as of this date 
              will now contain the date 
		format of yyyy-mm-dd 
              instead of mm-dd-yyyy.  Older open memo dates 
		may
              be reformatted as well.

   SOLUTION:  N/A

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A 

2006-01-12  - PROBLEM 2005347B

 PROBLEM_ID:  2005347B
     STATUS:  CLOSED (non HNAS problem) 
              Problem caused by an operational anomaly. 
  OPEN_DATE:  2005-12-13
PRVCHG_DATE:  2005-12-15
REVISE_DATE:  2006-01-12
 CLOSE_DATE:  2006-01-12
 SERVICE(S):  QLLC
  MANDATORY:  N/A
 ORIGIN/REF:  230_IZB
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  N/A
   --------

    PROBLEM:  Hanging LU's - NAS3702W with sense 0801.  NAS3702W
              messages issued for QLLC SLUs when APPLNAME=ACQUIRE
              is specified.

DESCRIPTION:  APPLNAME=ACQUIRE is supposed to inhibit REQSESS from
              being presented to PLU.  ACQUIRE implies that BIND
              is not to be solicited.  SLU waits indefinitely to
              be bound.  However, if HNAS receives an INIT-SELF,
              it assumes that the user does not want to wait to be
              acquired and thus initiates a REQSESS request to
              solicit a BIND from the PLU (CICS).

              In this customer's environment, SLU names are special.
              Some SLUs (those with even numbered SLU names) are
              bound by CICS automatically while others (with odd
              numbered SLU names) solicit a BIND from CICS via
              an INIT-SELF.  The REQSESS that results from the
              INIT-SELF is being rejected with 0801 sense because
              the SLU TCTs are not enabled in CICS.  This is an
              operational problem.

   SOLUTION:  Operations personnel must enable the odd numbered SLUs
              to CICS so that the REQSESS will not be rejected.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A    

12-13-2005  - PROBLEM 2005340A

 PROBLEM_ID:  2005340A
     STATUS:  CLOSED
  OPEN_DATE:  12-06-2005
REVISE_DATE:  mm-dd-2006
 CLOSE_DATE:  12-13-2005
 SERVICE(S):  LLC-0
  MANDATORY:  N/A
 ORIGIN/REF:  230_ITL
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
   --------

   OVERVIEW:  See problem.

    PROBLEM:  CICS session ends after HNAS receives a RESET packet 
              with CAUSE/DIAG=000/001. 

DESCRIPTION:  The Cisco initiated RESET indicates that the router 
              has detected an invalid PS (X25 send sequence number) 
              from the Network. The call is cleared. A side effect 
              is CICS FMD PIUs being rejected with 0801 sense 
              (resource not available). 

              Cisco Debug message: 
              
              X.25 Data packet, Bad P(S), Receive window violation 

   SOLUTION:  Customer corrected a window size mismatch between the 
              Network and the router. (Network is W=7 and router was 
              W=2. Router and HNAS will be changed to W=7). 

              Note: Cisco router debug trace revealed that network
              was sending three packets (one beyond the window size.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A    

2006-01-18  - PROBLEM 2005334A

 PROBLEM_ID:  2005334A
     STATUS:  ON HOLD
  OPEN_DATE:  2005-11-30
PRVCHG_DATE:  2005-11-30
 CLOSE_DATE:  2006-mm-dd
 SERVICE(S):  TCP/IP interface logic
  MANDATORY:  N/A
 ORIGIN/REF:  230_CPA
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  TBD
   PTF_TYPE:  TBD - (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  TBD
   COREQ(S):  N/A
  PREREQ(S):  TBD
  OBJECT(S):  TBD
  SOURCE(S):  TBD

    PROBLEM:  Customer reports that when HNAS is started at the
              same time as the TCPIP stack, it sometimes takes
              more than 5 minute to complete it's initialization
              or may never complete it's initialization.

DESCRIPTION:  In some cases if HNAS is started after TCPIP is started
              and the 'TCP/IP START COMPLETE' is issued but before the
              'BPXI004I OMVS INITIALIZATION COMPLETE' is displayed,
              HNAS can take over 5-minutes to come active and display
              the 'NAS0001I HOST NAS INITIALIZATION COMPLETE, ...'
              message.  In other cases, the NAS0001I message is never
              displayed which looks like HNAS did not complete it's
              initialization.

              The 5-minute delay seems to be coming from the INITAPI
              request.  Consider at the following messages which are
              contiguous in the HNAS log:

              19:50:29 NAS2030I SERVER=193.032.133.201(01998)
                       SOCKID=0000 PCEID=0007 NAME=XOTSRVR2
              19:50:29 NAS2030I API CONNECTION TO TCPIP    VR=0616
                       CAN BE PERFORMED
              19:55:13 NAS2050I SERVER=193.032.133.201(01998)
                       SOCKID=0000 PCEID=0007 NAME=XOTSRVR2
              19:55:13 NAS2050I API CONNECTION TO TCPIP
                       HAS BEEN ESTABLISHED

              The NAS2030I message is issued when the GETIBMOPT request
              ends signaling that the stack is active.  The NAS2050I
              message is issued when the INITAPI completes.  HNAS does
              not timeout the INITAPI.  It only provides a delay between
              successive INITAPIs when the first fails.  The INITAPI is
              not failing.  It's ending is being withheld by the stack.
              This is probably because the stack is not completely
              ready to handle subsequent BIND commands.  Perhaps IBM can
              tell us more.  The 'BPXI004I OMVS INITIALIZATION COMPLETE'
              was issued at 19:55:12 according to the SYSLOG file so the
              INITAPI ended 1 second later.

              In the HNAS log sent by the customer, we can see that
              HNAS has connected to the stack (INITAPI ended normally)
              and that the LOCAL server (XOTSRVR2) has been
              successfully bound so this rules out a problem with
              HNAS interfacing to the stack. Normally, the NAS0001I
              message is produced after all TCP/IP initialization
              activity has completed (NAS2010I and NAS2020I message
              issued) but this does not appear to happen in the log
              that was sent. There are a few things that will defer
              the NAS0001I message from being issued.

              1) The DMAP APAR command that is issue automatically must
                 complete before NAS0001I is issued (all APARed modules
                 are displayed).

              2) All MCH initialization must complete before NAS0001I
                 is issued(NAS1700I and NAS1709I messages issued).

              3) Server/Client initialization must complete before
                 NAS0001I is issued(NAS2010I and NAS2020I messages
                 issued).


              All 3 of these functions appear to have completed and
              yet the NAS0001I  message is withheld.  To see what
              might be causing this, we need to look at HNAS control
              blocks.  The easiest way to do this is to issue the
              TRCTRAP SNAP console command after it is noticed that
              NAS0001I message has not been produced when is expected.
              This would be after the 3 initialization steps have been
              completed.  We have requested this from the customer.

   SOLUTION:  TBD
   
CIRCUMVENTION: Start HNAS after the TCP/IP initialization completes.

 APPLY_INFO:  N/A     

12-20-2005  - PROBLEM 2005326A

 PROBLEM_ID:  2005326A
     STATUS:  CLOSED
  OPEN_DATE:  11-22-2005
REVISE_DATE:  mm-dd-2006
 CLOSE_DATE:  12-19-2005
 SERVICE(S):  VTAM
  MANDATORY:  N/A
 ORIGIN/REF:  230_SDD
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
   --------

   OVERVIEW:  see problem.

    PROBLEM:  Session ends with DIAG=219 (HNAS received -RSP from PLU).

DESCRIPTION:  Trace showed the following events:
              BIND image allowed multiple element chains.
              PLU's receive RU size = 256.
              M-bit chain received with total length=266.
              256 byte FIC RU sent to PLU.
              10 byte LIC RU sent to PLU.
              PLU sent SIGNAL to HNAS.
              PLU sent -RSP with SENSE=0811 to HNAS.
              HNAS ends session with DIAG=219.

   SOLUTION:  Customer changed PLU receive RU size so that HNAS no
              longer sends multiple element chains.  Bind image
              allowed the chains, PLU could not handle them.

CIRCUMVENTION: See solution.

 APPLY_INFO:  N/A   

11-05-2005  - PROBLEM 2005304A

 PROBLEM_ID:  2005304A
     STATUS:  CLOSED
  OPEN_DATE:  10-31-2005
 CLOSE_DATE:  11-05-2005
 SERVICE(S):  SMP/E Product Installation/Maintenance
  MANDATORY:  N/A
 ORIGIN/REF:  230_CPT
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
   --------

    PROBLEM1:  Documentation refers to SMP/E edistribution directory
               when lns.zip file is now primarily provided.

    PROBLEM2:  SMP/E installation process has SMPFTP step documented
               while the majority of customers don't use this method.

    PROBLEM3:  SMP/E maintenance query for ++FUNCTION, DESC doesn't
               reveal APAR maintenance level.

    PROBLEM4:  SMP/E edistribution file packaging different than
               non-SMP/E.


DESCRIPTION1:  See Problem1/Solution1.

DESCRIPTION2:  See Problem2/Solution2.

DESCRIPTION3:  See Problem3/Solution3.

DESCRIPTION4:  See Problem4/Solution4.


   SOLUTION1:  The distribution file name will now have the form:
               lns_2300nnn_2005-mm-yy_cust#_cid.zip

   SOLUTION2:  The FTPGET JOB and the customization statements used
               to configure the job (user-id, server addr, etc.)
               have been removed.

   SOLUTION3:  The DESC() operand is now shipped as follows:

      DESC(Comm-Pro X25 Network Access dd_mon_yyyy APAR LEVEL 2300nnn)
               dd   = day of month
               mon  = month (e.g. NOV)
               yyyy = year
               nnn  = APAR level.

   SOLUTION4:  The SMP/E edistribution file packaging updated with
               similar file structure as non-SMP/E edistributions.

               The HNAS documentation manuals were updated to reflect
               the changes for items 1-4.  

CIRCUMVENTION: N/A

 APPLY_INFO:   N/A  

10-27-2005  - PROBLEM 2005298C

 PROBLEM_ID:  2005298C
     STATUS:  CLOSED
  OPEN_DATE:  10-25-2005
 CLOSE_DATE:  10-27-2005
 SERVICE(S):  LLC0
  MANDATORY:  N/A
 ORIGIN/REF:  230_BPS
    CP_TECH:  N/A
    PUBLISH:  YES, OVERVIEW
   PTF_INFO:  N/A
   --------

   OVERVIEW:  Customer is installing HNAS to provide LLC0 sessions
              with a CICS PLU.

    PROBLEM:  CICS transaction processors are receiving upper case
              characters where lower case is expected.

DESCRIPTION:  Traces show that lower case characters received from
              the remote are correctly forwarded to CICS.

   SOLUTION:  DFH3767 terminal definition in CICS had UCTRAN=YES.
              Changing to UCTRAN=NO solved the problem.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A  

10-25-2005  - PROBLEM 2005291A

 PROBLEM_ID:  2005291A
     STATUS:  CLOSED
  OPEN_DATE:  10-18-2005
REVISE_DATE:  10-19-2005  PROBLEM & DESCRIPTION rewritten.
              10-25-2005  PROBLEM & DESCRIPTION rewritten.
 CLOSE_DATE:  10-25-2005
 SERVICE(S):  GATE
  MANDATORY:  N/A
 ORIGIN/REF:  230_ECI
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
   --------

    PROBLEM:  GATE Editran data sessions fail to start because CINIT
              (created by HNAS data session REQSESS) is rejected by
              the CTCP (a CICS program) with 0801 sense (resource
              unavailable).

DESCRIPTION:  see Problem.

   SOLUTION:  Problem was a CICS configuration error.  The resource
              in CICS was generated with ACQ=YES.  Changing to ACQ=NO
              fixed the problem.  I believe that the acquire option
              makes the resource look busy to the new call so that
              the CINIT must be rejected.

CIRCUMVENTION: Enable CICS ACQ=NO option.

 APPLY_INFO:  N/A

10-15-2005  - PROBLEM 2005257A

 PROBLEM_ID:  2005257A
     STATUS:  OPEN, under analysis.
  OPEN_DATE:  09-14-2005
REVISE_DATE:  mm-dd-2006
 CLOSE_DATE:  mm-dd-2006
 SERVICE(S):  GATE - Call Request Packet - Sub addressing
  MANDATORY:  TO-BE-DETERMINED
 ORIGIN/REF:  230_GEM
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
   --------

    PROBLEM 1: CTCP rejects a GATE call request because the called
               address field does not contain a 4.

    PROBLEM 2: HNAS clears a Fast Connect GATE call request when
               CONNECT=SUBD is coded and the inbound call request
               packet has no called DTE address.

DESCRIPTION 1: When there is no subaddress in an incoming call
               HNAS (and NPSI) use CUD data to determine the LLC
               type.  If there is no CUD, GATE (LLC4) is selected
               and the call request is sent to the first CTCP in
               the LUNAME= list.  We have been told that in this
               case the call request packet delivered to the CTCP 
               will have 4 inserted as the called address in the 
               call request packet.  HNAS does not do this.

DESCRIPTION 2: When CONNECT=SUBD is coded and there is no called
               address in an inbound call request packet then the
               call is treated as if there was a Sub addressing
               digit of 0.  HNAS does not do this.

   SOLUTION:

CIRCUMVENTION 1: Customer configured router to add the subaddr:

              x25 route input-interface Serial0/1 source 198299722 
                        substitute-dest  4 xot 172.28.144.175

CIRCUMVENTION 2: No circumvention is available.

 APPLY_INFO:  TO-BE-DETERMINED  

06-30-2005  - PROBLEM 2005210A

 PROBLEM_ID:  2005210A
     STATUS:  OPEN, pending problem re-creation.
  OPEN_DATE:  06-29-2005
REVISE_DATE:  mm-dd-2006
 CLOSE_DATE:  mm-dd-2006
 SERVICE(S):  VTAM
  MANDATORY:  TO-BE-DETERMINED
 ORIGIN/REF:  230-GAD
    CP_TECH:  PRT
    PUBLISH:  YES, WIP
   PTF_INFO:  TO-BE-DETERMINED
   --------

    PROBLEM:  Session ended by PLU (IMS) after HNAS rejects PIU
              from PLU.

DESCRIPTION:  If a multiple element chain is rejected (for example
              by a bracket race condition) HNAS can deliver more
              than 1 -RSP to the PLU.  This violates SNA rules and
              the PLU terminates the session with an UNBIND.

   SOLUTION:  <solution description>

CIRCUMVENTION: Customer circumvented problem by changing the PLU so
              that single element chains are sent to HNAS.

 APPLY_INFO:  TO-BE-DETERMINED  

11-29-2004  - PROBLEM 2004334A

 PROBLEM_ID:  2004334A
     STATUS:  CLOSED
  OPEN_DATE:  11-29-2004
 CLOSE_DATE:  11-29-2004
 SERVICE(S):  NON-SMPE PRODUCT-INSTALLATION (HNASRCV)
  MANDATORY:  NO, AS REQUIRED
 ORIGIN/REF:  230_CP
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  SEE CIRCUMVENTION
  PTF_CLASS:  NON-APAR

    PROBLEM:  HNAS load module link edit step can generate the
              following error message:

              IEW2515W 4731 DIRECTORY ENTRY FOR MEMBER MCHTTBLS
                            IDENTIFIED BY DDNAME HNASOBJ IS NOT
                            MARKED AS LOAD MODULE.

DESCRIPTION:  This error message is generated because the shipped
              version of MCHTTBLS has lost its 'load module'
              attribute which the linkage editor complains about.

              This, however, does not affect HNAS operation.
              Translate processing for PAD terminals continues
              to operate correctly.

              This error condition was introduced with non-SMPE 
              distributions created after 11-10-2004.

   SOLUTION:  The HNAS non-SMPE distribution creation job has been
              corrected to eliminate the lost 'load module'
              attribute for MCHTTBLS condition.  A maintenance 
              refresh is required to eliminate the error message.

CIRCUMVENTION: Ignore the IEW2515W error message.

 APPLY_INFO:  N/A - See circumvention/solution.  

01-28-2005  - PROBLEM 2004314B

 PROBLEM_ID:  2004314B
     STATUS:  CLOSED
  OPEN_DATE:  11-09-2004
 CLOSE_DATE:  01-25-2005
 SERVICE(S):  GATE FTAM file transfer program
  MANDATORY:  N/A
 ORIGIN/REF:  230_SWD
    CP_TECH:  PRT
    PUBLISH:  YES, OVERVIEW
   PTF_INFO:  N/A
 ----------
 ----------

    PROBLEM:  FTAM Gate file transfers abort.

              Customer noticed that when the transfers fail the
              session end message indicates that HNAS cleared the
              call (normal end is clear from remote).

              Traces show that unbind shows up when there has been
              no definite response generated for 3 seconds (because
              packets were not built or sent due to closed X25
              window).

              VTAM traces taken while working on this problem had
              the following message logged just before the UNBIND:

              DSJ124I MESSAGE 0026223 UNDEFINED SC/NC/DFC COMMAND
              00026223 BFFR TRACE IN ORIGIN(xxxxx) DESTINATION(yyyyy)
              TH   40000000000000000001000A0001000A1D0009EB0DBF2ED30005
                   EXP  OSAF OEF(0001000A 0DBF) DSAF DEF(0001000A 09EB)
                   ERN(0) VRN(0) TP PRI(0) VR SEQ(000) TG
                   SEQ(000) SEQ(2ED3) COUNT(00005)
              RH   6B8000    SC     DR1 FMT          REQ
              RU             SC/NC/DF(FF)   05

              The Session Control FF05 RU is an internal VTAM RU that
              is not properly interpreted by ACF/TAP.  The DSJ124I
              message can be ignored.

DESCRIPTION:  PLU issues unbind in mid transfer.

              VTAM internal traces show that unbind is from the PLU.

   SOLUTION:  Customer currently looking into application resolution.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A  

2006-01-11  - PROBLEM 2004314A

 PROBLEM_ID:  2004314A
     STATUS:  DEFERRED until next release
  OPEN_DATE:  2004-11-09
PRVCHG_DATE:  2004-11-09
REVISE_DATE:  2005-09-22 - Deferred.
 CLOSE_DATE:  yyyy-mm-dd
 SERVICE(S):  CDF Configuration dialout processing
  MANDATORY:  NO, circumvention should be used until logic changed
 ORIGIN/REF:  230_ITL
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  N/A
   PTF_TYPE:  N/A - SEE STATUS.
    PTF_LOC:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  HNAS does not support NPSI DIALNO= special characters
              in dteaddr/cud suboperands of SVC0/5= operand.

DESCRIPTION:  See problem.

   Solution:  Looking at changing the way HNAS parses the dteaddr
              and/or cud suboperands of the SVC0/5= operand in order
              to allow NPSI DIALNO= special characters. This is a
              significant change.

CIRCUMVENTION: Use the mxtname suboperand of the SVC0/5= operand and
              its CUD= operand to supply information for HNAS that is
              currently provided for NPSI via the DIALNO= operand
              on the PU statement in the Switched Major Node File.
              For example:

instead of using the cud suboperand of the SVC0/5= operand as follows

MCH     REMOTE SVC0=(3,
                     MAZZEK03/X900060-2624100610050400102T//C0900060,
                     MAZZEK04/X900040-2624100610050400102T//C0900040,
                     MAZZEK05/X900020-2624100610050400102T//C0900020)
               :

which limits the outbound CUD to 4-byes, the following can be used:

MCH     REMOTE TYPE=MCH
               SVC0=(3,
                     MAZZEK03/X900060-2624100610050400102T/MXTEK03,
                     MAZZEK04/X900040-2624100610050400102T/MXTEK04,
                     MAZZEK05/X900020-2624100610050400102T/MXTEK05)
               :
MXTEK03 REMOTE TYPE=MXT
               CUD=C0900060C40000
MXTEK04 REMOTE TYPE=MXT
               CUD=C0900040C40000
MXTEK05 REMOTE TYPE=MXT
               CUD=C0900020C40000

The CUD= operand takes the role of zzzzz in DIALNO= plus USRFILD
without the need for special characters.

 APPLY_INFO:  N/A - CORRECTIVE LOGIC WILL BE AVAILABLE VIA UPGRADE.

12-01-2004  - PROBLEM 2004272B

 PROBLEM_ID:  2004272B
     STATUS:  CLOSED, No APAR solution required. 
  OPEN_DATE:  09-28-2004
 CLOSE_DATE:  12-01-2004
 SERVICE(S):  QLLC and PCNE
  MANDATORY:  N/A
 ORIGIN/REF:  230_RWE,230_SWD
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  N/A

    PROBLEM:  The following messages can be issued:

              NAS3701W mch-nm OPEN  FAILED FOR lu-name ACB.  R15=08
              NAS3702W REQSESS FROM SLU lu-nm TO PLU plu-nm FAILED
              R15=04 R0=10 FDB2=12 SENSE=0805000B

              - or -

              NAS3702W REQSESS FROM SLU lu-nm TO PLU plu-nm FAILED
              R15=04 R0=10 FDB2=12 SENSE=08570002

DESCRIPTION:  The error indicates that an LU was opened twice.
              The REQSESS after the second open fails because the
              session limit is exceeded.

   SOLUTION:  Customer indicates that REQSESS failure with 0805000B
              sense (session limit exceeded) has 'gone away' but
              they cannot explain why.  REQSESS failure with 08570002
              sense (SSCP/PLU session does not exist) continues to
              occur but customer does not consider this a problem.
              The 08570002 REQSESS failure seems to occur only when
              the application is selected but is not active.

APPLY_INFO:  N/A - no corrective logic required.

10-08-2004  - PROBLEM 2004253D

 PROBLEM_ID:  2004253D
     STATUS:  CLOSED, SEE-CIRCUMVENTION.
  OPEN_DATE:  09-09-2004
 CLOSE_DATE:  09-14-2004
 SERVICE(S):  PRODUCT-INSTALLATION
  MANDATORY:  NO, AS REQUIRED.
 ORIGIN/REF:  230_SDD
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  SEE CIRCUMVENTION.
  PTF_CLASS:  NON-APAR

    PROBLEM:  For some versions of the z/OS assembler the default
              option NODECK was changed to DECK. This can cause
              errors with some catalogued procedures if the OBJECT
              DD statement is missing.

DESCRIPTION:  HNAS module assembly output is normally stowed in
              the dataset referenced by the SYSLMOD DD statement.
              This does not require the DECK parameter.  If DECK
              is specified or is allowed to default, assembly
              output can also be stowed in the dataset referenced
              by the OBJECT DD statement which must be present to
              avoid an error message.

   SOLUTION:  NODECK assembly parameter now included in the HNASRCV
              JCL for refresh and upgrade product distributions.

CIRCUMVENTION: Users can manually add the NODECK parameter to the
               HNASRCV or HNASMNT assembly JCL member or request a
               product upgrade or refresh.

 APPLY_INFO:  N/A - See circumvention/solution.  

07-08-2004  - PROBLEM 2004187A

 PROBLEM_ID:  2004187A
     STATUS:  CLOSED (see circumvention)
  OPEN_DATE:  07-04-2004
 CLOSE_DATE:  07-08-2004
 SERVICE(S):  CNFG, GATE EDITRAN
  MANDATORY:  Suggested for GATE EDITRAN Environments
 ORIGIN/REF:  230_BPS
    CP_TECH:  N/A
    PUBLISH:  YES
  PTF_CLASS:  N/A
   PTF_TYPE:  CIRCUMVENTION
    PTF_LOC:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  Alarm issued when GATE data session starts:

              NAS3702W REQSESS FROM SLU slu-nm TO PLU plu-nm FAILED
              R15=04 R0=10 FDB2=12 SENSE=0805000B

              The PLU is the EDITRAN file transfer application.

DESCRIPTION:  When HNAS is ready to start a GATE data session a two
              2 second delay is taken between the delivery of the
              call accept packet to the CTCP and the issuing of a
              REQSESS macro to request a bind to start the data
              session.  This delay is required by some CTCPs.  The
              EDITRAN CTCP can issue an OPNDST ACQUIRE during this
              delay interval.  When the HNAS REQSESS is issued it
              fails as shown above.

CIRCUMVENTION: Code the following in the TYPE=MCH REMOTE definition:

               OPTIONS=(REQSESSDELAY=0)

              This removes the REQSESS delay and allows the GATE 
              data session to start.

 APPLY_INFO:  N/A  

11-22-2004  - PROBLEM 2004172A

 PROBLEM_ID:  2004172A
     STATUS:  ON HOLD, Pending user interest/requirement. 
              (was PENDING,  Under investigation/consideration)
  OPEN_DATE:  06-20-2004
REVISE_DATE:  10-26-2004 - Status change to ON HOLD.
 CLOSE_DATE:  mm-dd-2004
 SERVICE(S):  LLC0|LLC5 d-bit support consideration
  MANDATORY:  NO, Custom 
 ORIGIN/REF:  230_CSP/ISP
    CP_TECH:  PWB
    PUBLISH:  YES, Overview
  PTF_CLASS:  PENDING

    PROBLEM:  HNAS doesn't currently provide any XOT d-bit support.
              Implementation of this support is currently under
              investigation/consideration.  If implemented, this
              will be billable to the organization requesting the
              custom support. 

              Additional information will be provided as available.

08-17-2004  - PROBLEM 2004147A

 PROBLEM_ID:  2004147A
     STATUS:  PENDING, SEE-CIRCUMVENTION.
  OPEN_DATE:  05-26-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  08-17-2004
 SERVICE(S):  TCPIP INTERFACE (UNIX TIMER SERVICES)
  MANDATORY:  RECOMMENDED
    CP_TECH:  SFD
 ORIGIN/REF:  220_NBK
  PTF_CLASS:  PENDING
   PTF_TYPE:  CIRCUMVENTION (Host configuration option). 
    PTF_LOC:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  ABEND CODE SEC6, REASON CODE=0000FD1D after 18 
              days of HNAS program execution.

DESCRIPTION:  The ABEND SEC6, REASON=0000FD1D appears to be a
              problem with max CPU time for a UNIX process.
              HNAS becomes a UNIX process when it connects to
              the TCPIP stack.

              The maximum CPU time for a UNIX process is set by
              the MAXCPUTIME parameter in the BPXPRMxx member
              located in SYS1.PARMLIB.  Setting MAXCPUTIME=86400
              disables the timer.  Also, the TIME= parameter on
              the HNAS JOB card or EXEC statement will override
              the MAXCPUTIME parameter.  If a TIME= operand is
              not specified the system default is used.

   SOLUTION:  Modify appropriate timer controls to extend or
              disable the execution timers.   See circumvention.

CIRCUMVENTION: Code value MAXCPUTIME=86400 in SYS1.PARMLIB
               member BPXPRMxx to disable the timer.  We also
               suggest that you code TIME=1440 or TIME=NOLIMIT
               on the HNAS EXEC statement then restarting HNAS.

 APPLY_INFO:  N/A - SEE CIRCUMVENTION.  

02-02-2004  - PROBLEM 2004021A

 PROBLEM_ID:  2004021A
     STATUS:  CLOSED
  OPEN_DATE:  01-21-2004
 CLOSE_DATE:  01-30-2004
 SERVICE(S):  LLC0 callin,
              Using XID value to locate LU for the session.
  MANDATORY:  N/A
 ORIGIN/REF:  220_BIC
   PTF_TYPE:  <N/A>
    PTF_LOC:  <N/A>
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  HNAS clears inbound LLC0 call with DIAG=130 (X'82').
              NPSI processing of XID CUD data not matched.

DESCRIPTION:  Consider the following configuration:

              REMOTE TYPE=MCH,
              SVC0=(10,LUA001/X010101,LUA002/X010102/
                    LUB001/X010201,LUB002/X010202,LUB003/X010203...)

              When an inbound LLC0 call is routed to the above
              logical MCH, HNAS locates an SLU for the call by
              processing the SVC0= string.  In the above, XID
              values (in call user data) of 010101, 010102,
              010201 AND 010202 select LUA001, LUA002, LUB001
              and LUB002 respectively.  If an XID value can't
              be found or if the associated LU is busy, the new
              call fails (HNAS clears with CAUSE=000, DIAG=130
              (X'82')).

              With NPSI, if an LLC0 XID value fails to locate an LU
              the XID value is increments and a new attempt to start
              a session is made.

              HNAS does not increment the XID value if a selected LU
              is not available.  To provide similar logic in HNAS
              code the following:

              REMOTE TYPE=MCH,
              SVC0=(10,LUA001/X0101,LUA002/X0101/
                    LUB001/X0102,LUB002/X0102,LUB003/X0101,...)

              With the above definitions only the first 2 bytes of
              call user data are used for SLU selection.  If the
              XID starts with 0101 then either LUA001 or LUA002
              will be selected.  If both are busy the call fails
              with DIAG=130.  Similarly, 0102xx can select any
              available LUBxxx for the session.

              This CDF coding technique provides the NPSI 'step XID'
              facility.

12-06-2003  - PROBLEM 2003330A

 PROBLEM_ID:  2003330A
     STATUS:  Closed - customer received PTF 2920 from Virtel
  OPEN_DATE:  11-26-2003
 CLOSE_DATE:  12-06-2003
 SERVICE(S):  GATE, GATE FC
  MANDATORY:  NO
 ORIGIN/REF:  220_CFO
   PTF_TYPE:  N/A
    PTF_LOC:  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  HNAS does not respond when a CLEAR request is received
              from a CTCP and there is no X25 session.

DESCRIPTION:  Current HNAS logic assumes that if there is no VC
              then a Clear or Clear Confirm has been scheduled for
              delivery to the CTCP.

              At one installation the CTCP sends Clear commands every
              2 seconds.  HNAS does not respond to these commands.
              The loop ends after 5 minutes.

   SOLUTION:  HNAS modified so that a clear confirm is returned to
              the CTCP if a Clear is received from the CTCP and there
              is no VC session and no request queued for the CTCP.

              HNAS was also modified to reject the CTCP's Clear PIU.

              With either change applied HNAS continued to receive
              Clears from the CTCP.  Customer contacted Virtel (CTCP
              supplier) and received PTF 2920 which corrected the
              problem.

07-22-2003  - PROBLEM 2003199A

 PROBLEM_ID:  2003199A
     STATUS:  CLOSED, DEFERRED_TO_V2M3R0
  OPEN_DATE:  07-18-2003
 CLOSE_DATE:  07-22-2003
 SERVICE(S):  GATE, XPAD.
  MANDATORY:  NO
 ORIGIN/REF:  220_CAJ_07-10-2003
   PTF_TYPE:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  HNAS can send duplicate RRs during message segmentation
              processing when the RU size is erroneously set too low
              in the host.  This condition creates unnecessary TCP/IP
              and X25 packet traffic.

DESCRIPTION:  For GATE and XPAD sessions with MBITCHN=YES HNAS
              receives an M-bit chain and delivers it to the
              PLU as a sequence of only in chain PIUs with the RU
              size specified in the BIND image.  After delivery of
              an OIC RU HNAS schedules an RR to ensure that the
              X25 packet level is open.  When the RU size is smaller
              than the X25 M-bit chain message size HNAS incorrectly
              sends an RR after each PIU is delivered to the PLU.

              Most installations specify an RU size large enough to
              contain the message represented by the inbound M-bit
              chain (this avoids the need to reconstruct the
              original message from a series of only in chain GATE
              messages).  When this is done the extra RRs are not
              sent.

              This problem is not being APARed for V2R2M0 because
              in our experience when the RU size is too small the
              PLU will unbind the session when the series of OIC
              PIUs is received.

   SOLUTION:  V2R3M0 HNAS logic corrected to not send the extra RRs.

 APPLY_INFO:  N/A.

07-23-2003  - PROBLEM 2003190A
 PROBLEM_ID:  2003190A
     STATUS:  CLOSED,NON-HNAS_PROBLEM
  OPEN_DATE:  07-09-2003
 CLOSE_DATE:  07-23-0303
 SERVICE(S):  220 PVC Support
  MANDATORY:  NO
 ORIGIN/REF:  220_SIK
   PTF_TYPE:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  Unable to establish a PVC LLC0 session with CSFI.

DESCRIPTION:  After an exchange of XOT PVC SETUP packets HNAS
              receives a RESET packet with CAUSE=X'0F'.  This
              cause indicates 'network operational'.  When a
              RESET is received HNAS delivers a SIGNAL to the
              PLU.  Some PLUs may not want to receive this
              command.

   SOLUTION:  Customer determined that the RESET packet was not
              the reason that the PVC session did not start.
              The problem was a CSFI configuration problem.

 APPLY_INFO:  N/A

03-21-2003  - Renamed this document section and link from 'Open
              Problem Summary' to 'Problem Summary' to better
              reflect the content STATUS (which can be PENDING,
              OPEN, CLOSED, DEFERRED, etc.) for each PROBLEM_ID.

12-11-2002  - Open Problem Summary information area now available.

Last Update - January 20, 2010