COMM-PRO

HNAS VnRnMn
PROBLEM SUMMARY HISTORY

This HNAS VnRnMn Problem Summary History file contains retired problem log entries for problems that were closed and replaced with official APAR's. We will continue to provide these history items for historical reference although relocation from the HNAS VnRnMn Problem Summary file to this history file will eliminate unnecessary duplication.

This History section is provided for historical purposes only and is not intended to assist customers in their identification of problems for troubleshooting and fault isolation although there may be Closed/Closed Deferred lower priority problem entries for older active HNAS VnRnMn releases that reflect correction in a never release (i.e. problem discovered in 230, corrected in 240). We suggest that you primarily review the HNAS VnRnMn Problem Summary and HNAS VnRnMn Maintenance (APAR and PTF) Information Summary files for problem determination find and search activity.

Hyperlink entries for these STATUS: CLOSED Problem log entries are no longer provided in the HNAS Problem Summary Matrix and are now provided in the HNAS Problem Summary History Matrix below:

HNAS Problem Summary History Detail Follows:

     HNAS Problem Summary History Matrix

2008-07-04  - PROBLEM 2008182A

 PROBLEM_ID:  2008182A
     STATUS:  OPEN, under analysis.
  OPEN_DATE:  2008-06-30
REVISE_DATE:  2008-mm-dd
 CLOSE_DATE:  2008-07-17
 SERVICE(S):  VTAM / LLC4 / EDITRAN
  MANDATORY:  N/A
 ORIGIN/REF:  240_ATC
  CUST_TECH:  N/A
    CP_TECH:  PRT
    PUBLISH:  YES 2008-07-04
   PTF_INFO:  N/A
  PTF_CLASS:  N/A
   --------

   OVERVIEW:  HNAS REQSESS for a callin EDITRAN LLC4 data session
              rejected by NOTIFY after CPU upgrade.

    PROBLEM:  See overview.

DESCRIPTION:  The NOTIFY indicates the the HNAS REQSESS was rejected
              by the PLU (usually by a LOGON exit routine).

              The CICS log shows:

              DFHZC2405 E 01/07/2008 14:06:43 CICSPT90 0EC1 CSNE Node
              EATC0EC1 not activated.  VTAM RETURN CODE 1000 ((6) Module
              name: DFHZSYX)

              DFHZC2487 E 01/07/2008 14:06:43 CICSPT90 0EC1 CSNE
              EATC0EC1 Session connection failed. Node unavailability
              return code 2.  ((9) Module name: DFHZLGX)

              The VTAM log shows:

              IST663I CINIT REQUEST FAILED, SENSE=08010000  671

   SOLUTION:  As a part of the CPU upgrade process an EDITRAN parameter
              "Adquirir LUs en conexión" ("Acquire LUs in connection")
              was changed from NO to YES.  This caused the PLU to
              attempt to ACQUIRE the HNAS data session SLU after
              sending the call accept on the control session LU.  The
              REQSESS fails because it was issued at the same time as
              the PLU's OPNDST ACQUIRE.  Sense=08010000 indicates
              resource unavailable.

              Restoring the original parameter value corrected the
              problem.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A

2008-09-25  - PROBLEM 2007363A

 PROBLEM_ID:  2007363A
     STATUS:  CLOSED
  OPEN_DATE:  2007-12-29
REVISE_DATE:  2008-01-02 - IBM PMR #30328 opened.
 CLOSE_DATE:  2008-09-25 - See IBM PMR resolution.
 SERVICE(S):  HNAS non-SMPE installation processing
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  240_NBG
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
  PTF_CLASS:  TO-BE-DETERMINED
   --------

   OVERVIEW:  see problem

    PROBLEM:  Z/OS V1R9, TSO RECEIVE (IEBCOPY) RC-8 condition.

DESCRIPTION:  The HNAS install fails and the following messages
              are generated:

21.19.52 JOB18216  IEB1021E 9A7B,D,SYS00002,1D- OP,OVERFLOW
         INCOMP,0000151A000029,EXCP   LEN=X'0000' SENSE=0040-41
21.19.52 JOB18216  IEB1022I I/O ERROR ON PDS    DDN=SYS00002 
         VOL=SYP012 DSN=SYSR.HNAS.V2R4M0.OBJ
21.19.52 JOB18216  IEB1023I DURING WRITE MEMBER=CONSDNAS 
         TTR=X'000029' MBBCCHHR=X'000000151A000029' TAPE BLOCK=0
21.19.57 JOB18216  IEB1021E 9A4B,D,SYS00023,1D- OP,OVERFLOW
         INCOMP,0000020400001F,EXCP   LEN=X'0000' SENSE=0040-41
21.19.57 JOB18216  IEB1022I I/O ERROR ON PDS    DDN=SYS00023 
         VOL=SYP025 DSN=SYSR.HNAS.V2R4M0.OBJX
21.19.57 JOB18216  IEB1023I DURING WRITE MEMBER=VCCLEAR  
         TTR=X'00001F' MBBCCHHR=X'000000020400001F' TAPE BLOCK=0

   SOLUTION:  It turned out to be a problem with the CLEARDIR
              programm from IBM, which is used to initialize
              the directory of the PO datasets. There has been a
              change with z/OS 1.9.  CLEARDIR works with RECFM=FB,
              LRECL=80 and BLKSIZE=... but fails with RECFM=U and
              BLKSIZE=0 which is used for the OBJECT datasets.

              Customer's z/OS team has opened an incident with
              IBM (PMR #30328). They have also reinstalled the
              the z/OS 1.7 version of CLEARDIR so that the HNAS
              installation can be completed without error.

CIRCUMVENTION: Customer used their older Z/OS 1.7 level CLEARDIR
               to complete the HNAS product install.

 APPLY_INFO:  TO-BE-DETERMINED

2007-04-03  - PROBLEM 2007068A

 PROBLEM_ID:  2007068A
     STATUS:  CLOSED
  OPEN_DATE:  2007-03-09
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-04-03
 SERVICE(S):  GATE RVS via Datus Switch
  MANDATORY:  N/A
 ORIGIN/REF:  240_VWG
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
  PTF_CLASS:  TO-BE-DETERMINED
   --------

   OVERVIEW:  See problem

   PROBLEM1:  NAS4707W LU XVWM0L92 GENERATING ERR/INFO PACKET FOR CTCP
              AVBR11I9  GATE CMD RCV'D=C6, HNAS ERROR CODE=03

   PROBLEM2:  NAS5704W RESET RECEIVED FOR MCH XOTDATM1 VC 00405548
              XVWM0L92 LU 0042A9C8 CAUSE/DIAG=003/081 (03/51) DIAGX=0000

DESCRIPTION1: The NAS4707W alert indicates that an invalid GATE command
              byte was receive on a non-FC data session.

DESCRIPTION2: The NAS5704W 03/51 reset indicates that an improper cause
              code was received from a DTE.  The log shows that these
              resets can arrive at a rate of 10/sec.  It is not clear
              if the resets came in on the X25 link and were reported
              to HNAS in this way or if the PLU sent resets with cause
              and diagnostic values that the router did not like (HNAS
              does not issue an alert if the PLU sends a reset).

              Subsequent tests show that the RESET originates at the
              remote end.  The router receives cause/diag = 17/002
              which is forwarded to HNAS as 03/51.  The cause is not
              known and tracing at the remote end is not possible.
              Since the failed transfer is retried successfully the
              customer does not want to pursue this.

   SOLUTION1: This is likely a problem with PLU reset processing.

   SOLUTION2: N/A

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED

2007-01-31  - PROBLEM 2007031A

 PROBLEM_ID:  2007031A
     STATUS:  CLOSED
  OPEN_DATE:  2007-01-31
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-02-12
 SERVICE(S):  INSTALL
  MANDATORY:  NO
 ORIGIN/REF:  240_ITL
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
  PTF_CLASS:  ENHANCEMENT to install jobs
   --------

   OVERVIEW:  see problem

    PROBLEM:  Customer wants to omit unneeded VOL-SER and UNIT
              information when SMS is used to allocate HNAS
              data sets.

DESCRIPTION:  With SMS VOL/SER and UNIT information are supplied by
              the operating system based on the data sets first DSN
              qualifier.  The ##VL and ##UN customization variables
              are not required.

   SOLUTION:  The HNASGJOB REXX EXEC will now accept ##VL='*SMS'.
              When this is coded the ##UN variable is ignored and
              the JCL produced by the EXEC will not include the
              VOL=SER= or UNIT= parameters.

              The SMPGJOB (used to build jobs for installing with
              SMP/E) is similar to the HNASGJOB EXEC in that the
              ##VL and ##UN customization variables are present and
              they are used to produce JCL in an allocate step.
              However the variables are also used in statements used
              to define the VSAM data sets and clusters required by
              the CSI data set.  At this time SMPGJOB is not being
              modified to support ##VL='*SMS'.

CIRCUMVENTION: Code dummy VL= and UN= parameters:

              VL=111111,UN=3390.

              The JCL produced will include VOL=SER=111111,UNIT=3390
              which will be ignored when SMS allocates data sets.

 APPLY_INFO:  N/A 

2007-03-05  - PROBLEM 2007015B

 PROBLEM_ID:  2007015B
     STATUS:  CLOSED - APAR 2400031 issued
  OPEN_DATE:  2007-01-15
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2007-03-29
 SERVICE(S):  VTAM
  MANDATORY:  N/A
 ORIGIN/REF:  240_CMB
    CP_TECH:  PRT
    PUBLISH:  NO_WIP
   PTF_INFO:  TO-BE-DETERMINED
  PTF_CLASS:  ENHANCEMENT-APAR
   --------

   OVERVIEW:  (see problem)

    PROBLEM:  LLC0 session ends with DIAG=219 after PLU rejects FMD
              with a -RSP and SENSE=0811082C but sense not shown.

DESCRIPTION:  HNAS clears the call when a PIU is rejected in order 
              to ensure that the remote is aware of the undelivered 
              data.  The SENSE information, which could help with 
              problem diagnosis is not shown.  For example:

              FAPL: "Break: Asks the receiver of this sense code to
              to terminate the present chain with CANCEL ...").

              081C indicates that the PLU does not support inbound
              RH chains.

   SOLUTION:  A new alert message will be created to display the 
              PLU's sense data when the -RSP causes a clear.

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED  

2006-12-22  - PROBLEM 2006355A

 PROBLEM_ID:  2006355A
     STATUS:  CLOSED
  OPEN_DATE:  2006-12-21
REVISE_DATE:  N/A
 CLOSE_DATE:  2006-12-22
 SERVICE(S):  HNAS Timers - Daylight Savings
  MANDATORY:  N/A
 ORIGIN/REF:  230_BMO
    CP_TECH:  CPT
    PUBLISH:  YES
   PTF_INFO:  N/A
  PTF_CLASS:  N/A
   --------

   OVERVIEW:  See problem.

    PROBLEM:  Customer concerned that Daylight Savings changeover
              could cause timer problems and affect HNAS operation.

DESCRIPTION:  There will be no impact on your HNAS system when
              Daylight Savings time is toggled.

              HNAS timers utilize a special one-second HNAS
              system utility timer that is independent from the
              time-of-day clock.  Changes to the time-of-day
              clock do not affect processing of the HNAS system
              utility timer process.

              There is one situation where HNAS does utilize the
              Host System time-of-day Clock to determine if HNAS
              was stopped so that a NAS0301E warning message can
              be issued signifying that a ‘TIMER LOST INTERRUPT
              INDICATED  condition occurred (refer to Messages &
              Codes section for additional information regarding
              this message).  This message may be generated once
              during a changeover to/from Daylight Savings Time
              but is not a problem, it will not affect HNAS
              operation or transaction integrity.

              Our HNAS Timers documentation section will be
              updated to include information on this subject.

   SOLUTION:  N/A

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A 

2006-01-15  - PROBLEM 2006354A

 PROBLEM_ID:  2006354A  will become APARs 2300204 and 2400018
     STATUS:  CLOSED  OPEN_DATE:  2006-12-20
REVISE_DATE:  2006-12-29 - Description comments updated.
              2007-01-02 - Description updated to reflect CPA CDF.
 CLOSE_DATE:  2007-01-13
 SERVICE(S):  CNFG - IDLETO=  LLC0|LLC3|LLC5
  MANDATORY:  YES
 ORIGIN/REF:  230_CPA
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
  PTF_CLASS:  STANDARD-APAR
   --------

   OVERVIEW:  see problem.

    PROBLEM:  HNAS unaware of a lost TCP/IP session after remote
              network outage -- the IDLETO= parameter is not
              working properly.

DESCRIPTION:  Customer is having problems with hung LLC0 LUs.  The
              problems seem to relate to network difficulties.  The
              HNAS BUILD IDLETO=15 parameter was coded so that HNAS
              would clean up sessions that were inactive for 15
              minutes.  The parameter does not appear to be working.
              HNAS becomes aware of the lost session when a 120
              minute TCP keepalive operation fails.  While the
              keepalive timer will clean up the lost session, prior
              to the 120 minute timeout, customer issues the VTAM
              INACT/ACT command to the HNAS SLU to eliminate the
              hung resource.

              This situation occurs when an MXT is addressed by an
              SVC0=, SVC3= or SVC5= definition string in a TYPE=MCH
              REMOTE statement.  If IDLETO is not specified on the
              MXT, 0 is recorded as the IDLETO value for the MXT.  
              This incorrectly overrides the value coded on BUILD or 
              on the TYPE=MCH remote.

   SOLUTION:  Revise configuration logic so that run time code can
              determine that no IDLETO= value was coded on an MCH/MXT
              REMOTE.  HNAS call setup logic would use the MXT value
              (if coded), the MCH value (if coded) and lastly the
              BUILD value (with a zero default).

CIRCUMVENTION: When an SVC0= or SVC5= definition string uses an MXT
              pointer code IDLETO=value on the TYPE=MXT REMOTE if
              idle timeout logic is required.

 APPLY_INFO:  TO-BE-DETERMINED  

2006-11-10  - PROBLEM 2006315A

 PROBLEM_ID:  2006315A
     STATUS:  CLOSED
  OPEN_DATE:  2006-11-09
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-11-10
 SERVICE(S):  Non-SMP/E INSTALL
  MANDATORY:  N/A
 ORIGIN/REF:  240_VWG
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
  PTF_CLASS:  N/A
   --------

   OVERVIEW:  see problem.

    PROBLEM:  User unable to specify a different TCP module library
              that is used for the HNAS linkedit step.

DESCRIPTION:  The ##TCL= customization statement is used to provide
              the TCP module library name used in the HNASMNT job.
              The default library is ##TCL='TCPIP.SEZACMTX' and is
              correct for most environments. The ##TCL variable
              is not used in the pattern JCL (TCPIP.SEZACMTX is,
              incorrectly, hard coded).

   SOLUTION:  Use the ##TCL customization variable in the pattern
              JCL used to build HNAS installation JOBs.

CIRCUMVENTION: Correct member HNASMNT in hlq.HNASCNTL.  Change the
              //SYSLIB DD DSN=TCPIP.SEZACMTX,DISP=SHR statement so
              the proper library name is used.

 APPLY_INFO:  N/A.  Versions of the HNASGJOB REXX EXEC shipped after
              the close date will use the ##TCL variable when
              generating the above SYSLIB statement.  

2006-09-20  - PROBLEM 2006262A

 PROBLEM_ID:  2006262A
     STATUS:  CLOSED
  OPEN_DATE:  2006-09-19
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-09-20
 SERVICE(S):  Non-SMP/E INSTALL
  MANDATORY:  RECOMMENDED
 ORIGIN/REF:  240-SDD
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A - New distributions as of 2006-09-20 will contain
  PTF_CLASS:  N/A   the OBJECT parameter.
   --------

   OVERVIEW:  (see problem)

    PROBLEM:  The non-SMP/E HNASMNT JOB can fail with a CC=12 after
              NASMAIN assembly step.

DESCRIPTION:  The hlq.HNASCNTL(NASASM) assembly PROC assumes that
              OBJECT is the default assembler option.  If it is
              not, the link edit fails with:

               IEW2230S 0414 MODULE HAS NO TEXT.
               IEW2677S 5130 A VALID ENTRY POINT COULD NOT BE ...

   SOLUTION:  Pattern JCL will be revised to specify OBJECT in the
              PARM= list for the assembly steps.  This problem is
              installation dependent.

CIRCUMVENTION: Add OBJECT (following NODECK) in the assembler PARM=
              statement in hlq.HNASCNTL(NASASM).

 APPLY_INFO:  See PTF_INFO and CIRCUMVENTION.

2006-09-12  - PROBLEM 2006243A

 PROBLEM_ID:  2006243A
     STATUS:  CLOSED
  OPEN_DATE:  2006-08-31
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-09-12
 SERVICE(S):  INSTALL REXX EXEC
  MANDATORY:  RECOMMENDED
 ORIGIN/REF:  240_GME
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
  PTF_CLASS:  N/A
   --------

    PROBLEM:  The HNAS install REXX EXECs (HNASGJOB & SMPGJOB) produce
              invalid JCL when the high level data set name qualifier
              (##QL custimization variable) is longer than 23 bytes).

DESCRIPTION:  The install execs build the install JOBs by processing
              pattern JCL that is part of the exec.  The value for
              the ##QL variable is inserted in places where it is
              required.  In some cases the pattern JCL card has other
              information (for example, DISP=(OLD,KEEP)) that follows
              the data set name.  If ##QL is longer than 23 characters
              part of the DISP parameter may be positioned beyond card
              column 71.  This causes a JCL error.

   SOLUTION:  EXECs modified to ensure that information is not moved
              beyond card column 71 when the high level qualifier is
              inserted.

              For non-SMP install the hlq length limit is 31.  This
              results from the fact the '.HNASMACX.STR' is used as
              a low level DSN (44-13=31).

              For SMP/E installs the hlq length limit is 26.  This is
              a result of the DSPREFIX() SMP parameter limit.


CIRCUMVENTION: This failure occurs on the SYSLMOD DD card in the
              NASASM member of hlq.HNASCNTL.  NASASM is an assembly
              PROC that is invoked multiple times by the installation
              process.  To correct the error, edit the NASASM member
              and put the DISP=(OLD,KEEP) parameter on a separate
              card.  Because HNAS adds a low level data set name
              (e.g. '.HNASMACX.STR') to the high level qualifier the
              maximum length for ##QL is 31 (44-13).

 APPLY_INFO:  N/A 

2006-09-28  - PROBLEM 2006215A  - APARs 2300202 and 2400007 issued.

 PROBLEM_ID:  2006215A
     STATUS:  CLOSED, pending APAR.
  OPEN_DATE:  2006-08-03
REVISE_DATE:  2006-09-27
 CLOSE_DATE:  2006-09-28
 SERVICE(S):  PVC VTAM, PVC Resets
  MANDATORY:  YES
 ORIGIN/REF:  230_FIS
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A, see APAR.
  PTF_CLASS:  STANDARD-APAR
   --------

   OVERVIEW:  See problem

  PROBLEM 1:  IMS to IMS PVC connection receives reset:

              NAS5705W RESET SCHEDULED ON MCH mch-nm VC vc-addr
              lu-name LU lu-addr CAUSE/DIAG=000/219 (00/DB) DIAGX=0000

DESCRIPTION1: When HNAS receives a -RSP to a PIU sent to the PLU
              the following actions occur:

              If the sense is 10xx the NAS3711I alert is issued
              and the negative response is ignored (APAR 2300198).

              For other sense values:

              If the session is not a PVC the VTAM session is ended.
              If there is an X25 session it is cleared (DIAG=219/DB).

              If the session is a PVC then a RESET DIAG=129 is sent
              to inform the remote of the -RSP.  The VTAM session is
              ended (ACB closed, PLU receives NOTIFY).  When the sense
              is 0826 (request not supported) there is no reason to
              end the VTAM session because the PLU knows that the data
              was discarded (this can happen if a data base has been
              taken down).

 SOLUTION 1:  HNAS logic modified to not end the VTAM session when
              a -RSP SENSE=0826 is received from the PLU on a PVC
              session.

  PROBLEM 2:  When HNAS is restarted (HNAS-TO-HNAS environment) the 
              first outbound PLU FMD PIU is not sent by HNAS.

DESCRIPTION2: After APAR 2300107 the VC upper window edge is not
              set when a PVC SETUP packet is built.  This makes
              the VC's X25 transmit window appear closed.  Host
              data must be deferred until the window is opened.
              Most installations will not see this because in most
              cases the router sends a RESET DIAG=015 following it's
              response to the HNAS PVC SETUP.  This reset opens the
              X25 window.

 SOLUTION 2:  HNAS logic modified to properly set the upper window
              edge.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A 

2006-07-18  - PROBLEM 2006179A

 PROBLEM_ID:  2006179A
     STATUS:  CLOSED
  OPEN_DATE:  2006-06-28
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-07-06
 SERVICE(S):  GATE
  MANDATORY:  N/A
 ORIGIN/REF:  230_LPT
    CP_TECH:  PRT
    PUBLISH:  Yes - Overview
   PTF_INFO:  N/A
  PTF_CLASS:  N/A
   --------

    PROBLEM:  GATE sessions occasionally fail with
              CAUSE/DIAG=000/145 (00/91) DIAGX=0000

DESCRIPTION:  This diagnostic code (and the NAS3703W alert) indicate
              that the session was ended by a NOTIFY from the PLU.

              Trace shows outbound call request, call accept recv'd
              and sent to CTCP.  After REQSESS DELAY, REQSESS is
              sent to PLU (normal completion).  NOTIFY received
              SENSE=8013 (path error/COS table).

   SOLUTION:  Customer found that moving HNAS to the same LPAR
              corrected the condition.

CIRCUMVENTION: Customer put HNAS in the same machine as the PLU.

 APPLY_INFO:  N/A< 

2006-07-07  - PROBLEM 2006152A

 PROBLEM_ID:  2006152A
     STATUS:  CLOSED - Fixed in 240.
              DEFERRED TO V2R4
  OPEN_DATE:  2006-06-01
PRVCHG_DATE:  2006-06-01
 CLOSE_DATE:  2006-06-01
 SERVICE(S):  TRCTRAP console command support
  MANDATORY:  N/A
 ORIGIN/REF:  230_CCS
    CP_TECH:  CPT/SFD
    PUBLISH:  YES
  PTF_CLASS:  N/A
   PTF_TYPE:  240 base code.
  
    PROBLEM:  SNAP dump is not taken again after a trap hit when
              the customer issued TRCTRAP RSME.

DESCRIPTION:  Customer specified TRAPACTION=ALL which will suspend
              tracing and force a SNAP dump after a trap hit.  They
              issued TRCTRAP RSME which resumes tracing but not SNAP
              dumping.  TRCTRAP RSMEALL or TRCTRAP RSME RSMESNAP
              is required to resume all trap actions.

   SOLUTION:  HNAS will be modified to issue a message to alert user
              to the fact that RSMEALL or RSMESNAP is required to
              resume SNAP dumping.  TRCTRAP SHOW will be modified to
              also display the SNAP state in addition to the trace
              state.

CIRCUMVENTION: Issue command TRCTRAP RSMEALL to re-enable SNAP
               controls.

 APPLY_INFO:  N/A

2006-06-15  - PROBLEM 2006138A

 PROBLEM_ID:  2006138A
     STATUS:  CLOSED - Corrected in 240.
              DEFERRED TO V2R4
  OPEN_DATE:  2006-05-18
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-06-14
 SERVICE(S):  CONSOLE
  MANDATORY:  NO
 ORIGIN/REF:  230|240_CPT
    CP_TECH:  CPT
    PUBLISH:  YES_OVERVIEW
   PTF_INFO:  N/A - Standard in 240
   --------

   OVERVIEW:  'D garbage' display command doesn't generate error.

    PROBLEM:  Logic is missing to validity check Display command
              followers. This causes the default display output
              to be generated.

DESCRIPTION:  See PROBLEM.

   SOLUTION:  D{MEM} command will test arguments for valid hex
              data instead of defaulting to BASE + 0 100 and
              issue error message accordingly.

CIRCUMVENTION: Ensure that no extraneous or invalid characters
               follow the display command prior to entering.

 APPLY_INFO:  N/A 

2006-04-09  - PROBLEM 2006079A  (now part of 230C (Datafono Support)

 PROBLEM_ID:  2006079A
     STATUS:  CLOSED
  OPEN_DATE:  2006-03-20
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-04-04
 SERVICE(S):  LLC0/5 CALLOUT
  MANDATORY:  YES
 ORIGIN/REF:  230C_CCS
    CP_TECH:  PRT
    PUBLISH:  YES 
   PTF_INFO:  N/A
 ----------
  PTF_CLASS:  N/A
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2006079A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2006-mm-dd
              With APARs: 23000nn and 23000nn applied.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS , MCHHRQ , MCHLUIN , XOTRCV , XOTBXM
  SOURCE(S):  XFNASWA
 ----------

    PROBLEM:  Customer would like +RSP to BIND that triggers a
              callout to be sent when call accept received.
              CICS would show 'being ACQUIRED' as the resource
              status.

DESCRIPTION:  HNAS currently provides a +RSP to an LLC0/5 BIND when
              the BIND data has been validated and the call request
              scheduled.  If the PLU attempts to send data after the
              BIND response then HNAS waits for the VC to activate
              before accepting and sending the data.

   SOLUTION:  HNAS modified to delay the BIND response until the
              call has succeeded (call accept received, +RSP to BIND)
              or failed (clear or timeout, -RSP to bind).  The sense
              data for a -RSP is 0801C3D9 (0801=resource not available
              C3D9='CR'=call request).

              This solution is being provided for 230C distributions
              (Datafono) and for the V2R4M0 release.


CIRCUMVENTION: N/A


 APPLY_INFO:  N/A -- part of 230.C standard distribution.  

2006-08-28  - PROBLEM 2006054A  - APAR 2400003 issued.

 PROBLEM_ID:  2006054A
     STATUS:  CLOSED
  OPEN_DATE:  2006-02-23
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-08-28
 SERVICE(S):  LLC-0/5 callout
  MANDATORY:  TO-BE-DETERMINED
 ORIGIN/REF:  230_CCS
    CP_TECH:  PRT
    PUBLISH:  YES_OVERVIEW
   PTF_INFO:  TO-BE-DETERMINED
  PTF_CLASS:  ENHANCEMENT_APAR
   --------

   OVERVIEW:  See problem.

    PROBLEM:  Customer would like to associate an MXT address with
              each callout DTE address.

DESCRIPTION:  A callout LLC0 resource with multiple destination
              addresses is specified as follows:

                SVC0=(n,slu-nm/dte1-dte2-dte3O/mxt-nm/cud,...)

              When the SLU is bound by the PLU a call request packet
              is generated using dte1 as the called DTE address.  If
              this call fails (clear or no response to call request
              packet) then calls are placed to dte2 and dte3.  The
              TYPE=MXT REMOTE named by the mxt-nm operand provides
              CUD=, DTEADDR= and FAC= parameters to provide data
              placed in the call request packet.  Each outbound call
              will contain the same MXT information because there is
              one MXT pointer.

   SOLUTION:  At this time the only solution is a custom mod that
              locates addition MXT REMOTEs using the fact that if
              the MXTs are sequential in the CDF then the control
              are sequential in storage.

CIRCUMVENTION: TO-BE-DETERMINED

 APPLY_INFO:  TO-BE-DETERMINED

2006-03-22  - PROBLEM 2006048A  - - APAR 2300186 issued.

 PROBLEM_ID:  2006048A
     STATUS:  CLOSED - successfully tested.
  OPEN_DATE:  2006-02-17
PRVCHG_DATE:  2006-02-20
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-03-22
 SERVICE(S):  QLLC support
  MANDATORY:  N/A
 ORIGIN/REF:  230_ITE
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas230m/apars/
              (Complete FIX is contained in the P06048A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  2300182, 2300159, 2300157, 2300136
              and the associated APAR chains

              Note: Due to the large number of PreReqs, we
                    recommend a product maintenance refresh
                    to pick up this problem fix.

  OBJECT(S):  MCHBFR, QLSSCP, NASUTIL, XOTBXM
  SOURCE(S):  LUD

    PROBLEM:  A NOTIFY request is being rejected with 200D sense
              after a TERM-SELF response is returned to the SLU.

DESCRIPTION:  HNAS is rejecting a NOTIFY request that is received
              after a TERM-SELF request/response exchange because the
              NOTIFY request is received before an outstanding DACTLU
              response.  The following alarm message is also issued:

              NAS8241W INVALID REQ FOR LU LA50     ON PU P0AEMERC
                       RH/RU=0B80008106200C06 RC=34

              The NOTIFY request should not be rejected because it
              occurs after the TERM-SELF response is transmitted by
              HNAS thus satisfying the rules for immediate request
              mode protocol for the SLU half-session within the
              normal flow.  The outstanding DACTLU response, which is
              expedited, originates in the SSCP half-session which
              should be treated independently.  The exception to this
              rule is in HDX mode within the SLU/PLU session where a
              response to a request must be returned before another
              request can be sent.  If a violation of the rule occurs
              in this state, the 200D sense is appropriate.

   SOLUTION:  The NOTIFY processor will be modified to ignore the
              state of the SSCP (HNAS) half-session and only look
              at the SLU half-session when determining if the
              immediate request mode protocol is being violated.

 APPLY_INFO:  See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance.

              Corrective logic included in distributions created
              after CLOSE_DATE.  Otherwise, apply maintenance as
              directed in the APPLY_INFO (PTF).

2006-04-07  - PROBLEM 2006004A  -- RETIRED

 PROBLEM_ID:  2006004A
     STATUS:  RETIRED - Customer solved problem, no info available.
  OPEN_DATE:  2006-01-04
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-04-07
 SERVICE(S):  GATE
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_BNP
    CP_TECH:  PRT
    PUBLISH:  OVERVIEW
  PTF_CLASS:  APAR
   PTF_INFO:  TO-BE-DETERMINED
   --------

   OVERVIEW:  see problem

    PROBLEM:  TOM, a GATE application, program ABENDs when a call
              request packet with no RESID is received from HNAS.

DESCRIPTION:  Customer reports receiving the following GATE call
              request packet:

              0B820500430303F9000000

              This appears to be a packet with no RESID (Fxxx)
              between the 0B call request type byte and the
              82, 05, 00430303 lengths byte, called, calling
              addresses.  The customer is running STRIPRTEIN
              so the Calling/Called address length digits
              appear correct although the actual addresses
              content appears incorrect.  F9 (CUD?) should not
              produce a GATE call with their CDF.  The 430303
              could also be misplaced facilities.

   SOLUTION:  Customer will be asked if they would like us to
              prepare a diagnostic patch or run with TRCMCH ICR.

              The TOM GATE CTCP application vendor provided a
              patch to circumvent the Abend.  The cause of the
              malformed packet still needs to be identified.


CIRCUMVENTION: TO-BE-DETERMINED

 APPLY_INFO:  TO-BE-DETERMINED  

2006-01-20  - PROBLEM 2005348A  (associated with problem 2005279B)

 PROBLEM_ID:  2005348A
     STATUS:  CLOSED  -- APAR 2300176 issued.
  OPEN_DATE:  2005-12-14
PRVCHG_DATE:  2006-01-07
REVISE_DATE:  2006-01-09
REVISE_DATE:  2006-01-12
 CLOSE_DATE:  2006-01-20
 SERVICE(S):  LLC-n Round Robin Support
  MANDATORY:  NO
 ORIGIN/REF:  230_DBG
    CP_TECH:  SFD/PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
  PTF_CLASS:  ENHANCEMENT-APAR (once testing is completed)
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas230m/apars/
              (Complete FIX is contained in the P05348A.ZIP file)

   COREQ(S):  2005279B (S/T markers in RTEIN=)
  PREREQ(S):  2300169, 2300166, 2300163, 2300161, 2300151
              and their associated APAR chains

              Note: Due to the large number of PreReqs, we
                    recommend a product maintenance refresh
                    to pick up this APAR.

  OBJECT(S):  CNFGOPTS, CNFGRTIN, CONSDLCL, CONSMLCL, NASCNFG,
              VCCLRQ, XOTUT1
  SOURCE(S):  NASMAIN, MCHD, XFNASWA

   OVERVIEW:  Enhancement to RTEIN= processing to allow inbound
              calls to be distributed across multiple MCHs defined
              by TYPE=MCH REMOTEs.

    PROBLEM:  Customer requested the ability to distribute inbound
(ENHANCEMENT) GATE sessions over multiple CTCPs on distinct MCHs
              addressed by the LOCAL statement's RTEIN= operand.
              Because the LLC type is not known until the MCH is
              addressed and processed (MCH operands such as LLC0=,
              CUD0= and CTCP= set the LLC TYPE) this enhancement
              distributes sessions for all LLC types when the
              enabling option is coded.

DESCRIPTION:  When OPTIONS=BALANCERTEIN is coded on an XOT LOCAL
              (PORT=1998) statement the following actions are
              taken when an inbound call is received:

              1) the RTEIN= list is processed against the called
              and/or calling DTE addresses in the call request
              packet.  The MCH address in each RTEIN= entry that
              could be used for the call is recorded in an internal
              table.  A RTEIN= entry 'could be used' if there is a
              calling or called address match.  A RTEIN= entry with
              no dte address is treated as the end of the list (even
              if there are more entries) and the MCH it names does
              participate in the round robin logic.

              2a) If no RTEIN= entries are selected by the RTEIN=
              scan and RTEIN= does not end with a no DTE address
              entry then the inbound call is cleared with DIAG=202.

              2b) If no RTEIN= entries are selected by the RTEIN=
              scan and RTEIN= ends with a no DTE address entry then
              the TYPE=MCH REMOTE addressed by the no DTE address
              entry is used for the call.

              2c) If one or more RTEIN= entries are selected (tabled)
              by the RTEIN= scan then the MCHs addressed by the table
              are searched to locate an MCH with a round robin marker
              (a flag in the MCH control block).  If no marker is
              found the first MCH in the table is marked and used for
              the call.  If a marker is found then it is moved to the
              next MCH addressed by the table (possibly after wrapping
              to the first table entry) and that MCH is used for the
              call.

              Examples (OPTIONS=BALANCERTEIN assumed):

              RTEIN=(MCH1/7777,MCH2/7777,MCH3/7777,MCH4)
              Inbound calls with a called DTE address starting with
              7777 will be routed in round robin fashion to MCH1,
              MCH2 or MCH3.  All other calls go to MCH4.

              RTEIN=(MCH1/7777S,MCH2/7777S,MCH3S/7777,MCH4)
              Same as above except selection of MCH1/2/3 is based on
              the calling DTE address in the call request packet
              instead of the called DTE address.

              RTEIN=(MCH1/7777,MCH1/6666,MCH2/7777,MCH2/6666,
                     MCH3/7777,MCH3/6666,MCH4)
              Calls with a DTE address starting with 7777 or 6666 will
              be routed in a round robin fashion to MCH1, MCH2 or
              MCH3.  The first 3 calls with any combination of the
              7777 or 6666 called addresses will be routed to MCH1,
              MCH2 and MCH3 (first call to MCH1, second call to MCH2,
              etc).

   SOLUTION:  See description.

CIRCUMVENTION: N/A

 APPLY_INFO:  See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance.

              Corrective logic included in distributions created
              after CLOSE_DATE.  Otherwise, apply maintenance as
              directed in the APPLY_INFO (PTF).  

 12-09-2005  - PROBLEM 2005343N

 PROBLEM_ID:  2005343N

     NOTICE:  Problem Summary Notice

              Individual text format problem log memo are no longer
              provided as separate hyperlink files although the html
              memos can be saved as text, as required.

              Note that the aparid.zip problem fix will continue
              to include the memo is ASCII and EBCDIC format. 

2006-01-24  - PROBLEM 2005341B

 PROBLEM_ID:  2005341B
     STATUS:  CLOSED -- APAR 2300179 issued.
  OPEN_DATE:  12-07-2005
PRVCHG_DATE:  12-08-2005
REVISE_DATE:  12-09-2005
 CLOSE_DATE:  2006-01-24
 SERVICE(S):  TCPIP interface support
  MANDATORY:  TBD
 ORIGIN/REF:  230_BNP (SMP/E)
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas230m/apars/
              (Complete FIX is contained in the P05341B.ZIP file)
              ===> This must be distributed as an SMP/E USERMOD
   COREQ(S):  N/A
  PREREQ(S):  2300124, 2300117 (customer is at the 2300131 level)
  OBJECT(S):  NASUTIL
  SOURCE(S):  NASTCP

    PROBLEM:  NASHALT IN NASTCP - INVALID TCPIP INTERRUPT occurs after
              NAS2201W SOCKET REQUEST FAILED, RC=FFFFFFFF 0000040C
              message is issued.

DESCRIPTION:  ERNO=40C in NAS2201W message says that the TCPIP stack
              is inactive.  NASHALT says that TCPIP socket number
              that was provided for the interrupt request was invalid.

              Prior to the NAS2201W message above, HNAS received an
              indication that the HOME LOCAL's connection to the stack
              had been severed resulting in a NAS2102E alarm message.

              There are a couple of things wrong in the HNAS TCPIP
              logic that this problem has revealed.

              1) The routine (TCPSUS) that provides TCPIP socket
                 number management (decrement request in this case) is
                 testing for normal SOCKET completion (STTCPSOC+STCMND)
                 On the SOCKET failure path, STCMND has not been set
                 so the ABEND occurs due a validity check.

              2) When the TCPIP sever is detected for the LOCAL server
                 (NAS2202E message), subsequent TAP requests for
                 REMOTEs for which the severed LOCAL is HOME should
                 be inhibited.  This will prevent thrashing NAS2201W
                 messages.

CIRCUMVENTION: N/A

   SOLUTION:  1) HNAS will be modified to ensure that STTCPSOC+STCMND
                 is set on the SOCKET request failure path to avoid
                 the ABEND.

              2) HNAS will be modified to prevent TAPping for REMOTEs
                 whose HOME LOCAL is IDLE which is the state set after
                 a stack sever or when the LOCAL remains idle after
                 it's socket is closed. 

2006-01-23  - PROBLEM 2005334B

 PROBLEM_ID:  2005334B
     STATUS:  CLOSED  -- APAR 2300178 issued.
  OPEN_DATE:  2005-11-30
REVISE_DATE:  2005-12-05
              Use ERROR/INFO packets to report errors.
              Clear on FC control session = reinitialize control
              control session.
 CLOSE_DATE:  2006-01-23
 SERVICE(S):  GATE FC, GATE
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_SDD
    CP_TECH:  PRT
    PUBLISH:  YES, WIP
   PTF_INFO:  TO-BE-DETERMINED
   --------

   OVERVIEW:  see problem

    PROBLEM:  VIRTEL GATE FC control session comes down when 135/001
              X25 RESET packet received.

DESCRIPTION:  The JOB log (taken over a period of 24 days) shows 25
              resets of this type.  The portion of the SYSPRINT file
              sent shows that on two occasions the following occurred
              after the reset:

              The data session LU receives 2 packets with invalid
              GATE control bytes.  These cause HNAS to generate
              DIAG packets for the CTCP (sent via the control session)
              with the text "SENDING DIAG PKT :INVALID CTCP DATA SES
              CMD BYTE".

              The CTCP then sends a CLEAR packet to HNAS on the control
              session LU.  These are invalid (the control session is
              only used DIAG and INFO packets and these only flow
              from HNAS to the CTCP).

              When HNAS receives the invalid PIU with the Clear,
              another DIAG packet with the text "SENDING DIAG PKT :
              FMD INV ON FC CONTROL SESSION" is generated and sent to
              the CTCP via the control session.

              The DIAG packet appears to generate another Clear on the
              FC control session LU.

              The loop is not infinite.  After a period, the control
              session sends an UNBIND which terminates the control
              session LU and it's related data session LUs.

              The DIAG packets were designed to inform the CTCP of
              problems via the control session.  This now appears to
              be a bad idea.

   SOLUTION:  When HNAS receives an invalid packet on a GATE control
              or data session LU a NAS4707W alert message will be
              issued and an ERROR/INFORMATION REPORT message (not a
              DIAGNOSTIC message) will be sent to the CTCP on the
              control session LU.  Alert format:

              NAS4707W LU lu-nm GENERATING ERR/INFO PACKET FOR CTCP
                       plu-nm GATE CMD RCV'D=cc, HNAS ERROR CODE=ee

              cc = X25 command byte received by HNAS.
              ee = Error code: 1 = Invalid cmd on GATE ctl session.
                               2 = Invalid cmd on FC GATE ctl session.
                               3 = Invalid cmd on GATE data session.
                               4 = cmd on FC GATE data session does
                                   not meet minimum length requirement.
                               5 = cmd on GATE ctl session does not
                                   meet minimum length requirement.
                               6 = cmd on GATE data session does not
                                   meet minimum length requirement.

              When HNAS receives a CLEAR packet on an FC control
              session LU a NAS4708W alert message will be issued and
              a CLEAR-CONFIRM will be returned to the CTCP.  Data
              session LUs will not be affected.  Alert format:

              NAS4708W GATE FC CTL SES LU lu-nm CLEARED BY CTCP plu-nm
              CAUSE/DIAG=cc/dd

              cc/dd = CTCP's CLEAR cause and diagnostic bytes (in hex).

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED   

11-29-2005  - PROBLEM 2005320A

 PROBLEM_ID:  2005320A
     STATUS:  CLOSED, see APAR 2300165.
  OPEN_DATE:  11-16-2005
 CLOSE_DATE:  11-29-2005
 SERVICE(S):  DPARM trace parameter display processing
  MANDATORY:  N/A
 ORIGIN/REF:  230_BNP
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  TBD
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  TBD
   COREQ(S):  N/A
  PREREQ(S):  2300163, 2300161
  OBJECT(S):  CONSDPRM
  SOURCE(S):  NASMAIN

    PROBLEM:  Customer reports that DPARM trace parameter display can
              be confusing.

DESCRIPTION:  Confusion results from the fact that when the same trace
              flag is manipulated by an equivalent console command
              using the ALLON|ALLOFF arguments, the DPARM display
              shows ON|OFF instead of ALLON|ALLOFF.  For example,
              when TRCMCH ALLON is entered followed by DPARM, the
              DPARM display for TRCMCH is ON instead of ALLON.

   SOLUTION:  The DPARM display processor will be modified to display
              ALLON or ALLOFF for those trace parameters that have an
              equivalent console command that accepts the ALLON and
              ALLOFF arguments.

              In addition, ALLON and ALLOFF will now also be accepted
              as followers for the TRCLU, TRCVC, TRCMCH, TRCMCHX,
              TRCBFR, TRCDATA, TRCDISP and TRCIO start parameters
              and will be treated identically to the ON and OFF
              followers which are currently supported in the PARM=
              operand.

11-16-2005  - PROBLEM 2005312A

 PROBLEM_ID:  2005312A
     STATUS:  CLOSED, see APAR 2300163
  OPEN_DATE:  11-08-2005
PRVCHG_DATE:  11-09-2005
 CLOSE_DATE:  11-15-2005
 SERVICE(S):  Netview alarm message processing
  MANDATORY:  N/A
 ORIGIN/REF:  230_CEC
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  TBD
   PTF_TYPE:  (OBJ) HNASOBJ and (SRC) HNASMAC (refresh required)
    PTF_LOC:  TBD
   COREQ(S):  N/A
  PREREQ(S):  TBD
  OBJECT(S):  CNFGOPTS, OSUT1
  SOURCE(S):  NASMAIN
              and possibly: XFCNFGWA, XFGBLS, XFIDR, XFPCE, XFWTO

    PROBLEM:  Customer reports that he is unable to route HNAS alarm
              messages (unsolicited/asynchronous WTOs) to the NETLOG
              instead of the SYSLOG.

DESCRIPTION:  Customer has tried using the Netview ASSIGN command as
              recommended by Comm-Pro but this does not seem to work.

              ASSIGN  MSG=NAS*,PRI=OPER1
              ASSIGN  MSG=NAS*,COPY=OPER1

              This requires that OPER1 is defined as a Netview console
              and that SHOWON or SHOWERR option is active.

              Customer also tried modifying the Netview automation
              table which allowed HNAS alarm messages to go to NETLOG
              but they are also going to SYSLOG which he does not want.

              IF MSGID= 'NAS' . THEN
                              BEGIN;
                              ALWAYS
                      DISPLAY(Y) NETLOG(Y) SYSLOG(N)
              END;

              At this point, we are still trying to determine why
              SYSLOG(N) does not prevent HNAS alarm messages from
              getting to SYSLOG.

              <Begin 11-10-2005 description changes>

              We now believe that the reason that all HNAS alarms
              are going to NETLOG and SYSLOG is because SYSLOG is
              defined as the HARDCOPY console where messages are
              logged before they can be filtered by the Netview
              automation table where SYSLOG(N) is coded.

              This is occurring because all HNAS WTOs use ROUTCDE=8
              (teleprocessing control) which cannot be omitted from
              HARDCOPY routing.

              <End 11-10-2005 description changes>

              <Begin 11-10-2005 solution changes>

   SOLUTION:  HNAS should be changed to use some other routine code.
              For example, ROUTCDE=11 (programmer information). The
              ROUTCODE parm in the HARDCOPY section of the CONSOLxx
              member is SYS1.PARMLIB would have to be changed to
              remove ROUTCDE=11 from ROUTCODE list.  For example,
              from ROUTCODE(ALL) to ROUTCODE(1-10,12-128). This
              will required an IPL.

              To temporarily modify the HARDCOPY routing, the VARY
              command can be used as follows:

              VARY SYSLOG,HARDCPY,DROUT=(11)

              To make the choice of HNAS WTO routing code more
              flexible, HNAS will be modified to accept a new BUILD
              options: OPTIONS=WTOROUTCODE=value which will be used
              for all HNAS WTOs.

              <End 11-10-2005 solution changes>

              Additional information will be provided as available.

2006-01-12  - PROBLEM 2005298A  - Became APAR 2300175

 PROBLEM_ID:  2005298A
     STATUS:  CLOSED 
  OPEN_DATE:  2005-10-25
PRVCHG_DATE:  2005-10-25
REVISE_DATE:  2005-12-09
 CLOSE_DATE:  2006-01-12
 SERVICE(S):  CONSOLE - alternate SYSPRINT DCB parameters
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_FDK  (GRK)
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas230m/apars/
              (Complete FIX is contained in the P05298A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  NASPRNT
  SOURCE(S):  N/A

    PROBLEM:  HNAS log records are being truncated when alternate
              (not SYSOUT=*) dataset is used for SYSPRINT.

DESCRIPTION:  Alternate dataset was allocated with DCB parameters
              of RECFM=FBA,LRECL=133,BLKSIZE=3990 but was changed
              by HNAS to RECFM=VA, LRECL=135 and BLKSIZE=4054 when
              alternate dataset was opened via PRNT CLSOPN ddname.
              Not sure that this caused the problem because we were
              unable to duplicate the same condition in our lab.

              <begin 12-09-05>
              Problem appears to be related to PRNTDATE parameter
              which causes Julian date to be appended to beginning
              of each print record.  For large records, like the
              ones reported by the user, last 5-bytes at the end of
              the record gets truncated because the print routine
              (XFPRNT) enforces a maximum buffer data size of 128
              bytes even though the existing DCB parameters specify
              RECFM=VA,LRECL=135.

   SOLUTION:  The print interface routine will be modified to
              increase the print buffer size to 133 bytes which
              will accommodate the missing 5-bytes of data and the
              DCB parameters will be changed to RECFM=VA,LRECL=137.
              <end 12-09-05>

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED 

2006-01-20  - PROBLEM 2005279B  (Developed along with problem 2005348A)

 PROBLEM_ID:  2005279B
     STATUS:  CLOSED -- became apar 2300176.
  OPEN_DATE:  2005-10-06
REVISE_DATE:  2005-mm-dd
 CLOSE_DATE:  2006-01-20
 SERVICE(S):  LLC-n RTEIN= (=>S)
  MANDATORY:  NO
 ORIGIN/REF:  230_CPT
    CP_TECH:  SFD/PWB
    PUBLISH:  OVERVIEW
 ----------
   PTF_INFO:  N/A
  PTF_CLASS:  ENHANCEMENT-APAR (once testing is completed)
 ----------

   OVERVIEW:  Allow RTEIN= processing to be controlled by calling
              address (=>S) in addition to the existing called DTE
              address (=>T) in a manner similar to that used for
              the RTEOUT= operand.

    PROBLEM:  <See overview>

DESCRIPTION:  <See overview>

   SOLUTION:  HNAS modified to accept the following RTEIN= format:

              RTEIN=(...,mch-name/addr{S|T},...)

Example:

RTEIN=(MCH1/20367777T,MCH2/7796S)

When an inbound XOT call is received elements in the RTEIN= list
are scanned left to right looking for a virtual MCH for the call.

If a RTEIN entry has a T marker (or if no marker is coded after
the address) the called address in the inbound call request
packet is compared to the address in the RTEIN= entry.

If a RTEIN entry has an S marker then the calling address in the
inbound call request packet is compared to the address in the
RTEIN= entry.

In either case an n digit RTEIN entry matches an m digit call
request packet if n < m and the first n digits match.

RTEIN addr 123567 matches call request packet addresses 1234567,
1234567xx, etc.

Side effect for the STRIPRTEIN option:

This option causes HNAS to strip the RTEIN digits used for MCH
selection from the called address in the call request packet
sent to the CTCP.  When the calling address selects the MCH the
packet sent to the CTCP will have the original called address
(option suppressed).

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A   

2006-03-15  - PROBLEM 2005279A

 PROBLEM_ID:  2005279A
     STATUS:  CLOSED - Likely to be a PLU Problem
  OPEN_DATE:  2005-10-06
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-03-14
 SERVICE(S):  GATE
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_SDD
    CP_TECH:  PRT
    PUBLISH:  YES_OVERVIEW
   PTF_INFO:  TO-BE-DETERMINED
   --------

    PROBLEM:  Calls to GATE Fast Connect (FC) HNAS SLU are cleared
              with DIAG=130, DIAGX=4.

DESCRIPTION:  These DIAG and DIAGX values indicate that when HNAS
              received an inbound call from the remote there were
              no active fast connect SLUs for the session.

              It appears that the CTCP did not acquire the HNAS 
              data session LUs.

   SOLUTION:  N/A.

CIRCUMVENTION: TO-BE-DETERMINED

 APPLY_INFO:  TO-BE-DETERMINED

2006-11-27  - PROBLEM 2005277B

 PROBLEM_ID:  2005277B
     STATUS:  CLOSED -- became apar 2400014.
  OPEN_DATE:  2005-10-14
REVISE_DATE:  2006-mm-dd
 CLOSE_DATE:  2006-11-27
 SERVICE(S):  Console command modifier processing
  MANDATORY:  NO
 ORIGIN/REF:  230_SIK
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  ENHANCEMENT APAR
   PTF_TYPE:  TBD
    PTF_LOC:  TBD
   COREQ(S):  TBD
  PREREQ(S):  TBD
 SUPERSEDES:  N/A
  OBJECT(S):  TBD
  SOURCE(S):  TBD

    PROBLEM:  Customer indicates that it is difficult to remember
              the left side modifiers in effect which can cause
              confusion when issuing commands that use modifiers.

DESCRIPTION:  Due to the large number of resources in the customer's
              configuration, using left side modifiers can cause
              confusion when issuing some console command.  Customer
              has a hard time remembering which modifiers are set.
              Left side modifiers as well as active filter settings
              (previously entered standalone or previous entered as
              left side modifiers) filter can sometimes get in the
              way causing confusion.

   SOLUTION:  Under consideration/review.
              For console commands that utilize remembered modifier,
              add new option BRM|NOBRM (bypass remembered modifiers)
              so that all remembered filter option will be ignored
              when the command is executed.  With this new option
              the user won't have to display the current parameters
              DPARM to see what values are enabled and doesn't need
              to be concerned with temporarily overriding specific
              modifiers (filters).

              Another consideration for this implementation would
              be to prefix or suffix the command with a special
              character (#,*,$...) i.e. #DLU or DLU# which would
              signal the command decode to bypass the remembered
              modifiers.

CIRCUMVENTION: Use DPARM command to display remembered modifiers.
               Never use left side modifiers so that permanent
               values are not set.  Use right side modifiers only
               to set temporary values for each command as needed.

 APPLY_INFO:  TO-BE-DETERMINED   

10-22-2005  - PROBLEM 2005276A

 PROBLEM_ID:  2005276A
     STATUS:  CLOSED, see APAR 2300160
  OPEN_DATE:  10-03-2005
REVISE_DATE:  mm-dd-2005
 CLOSE_DATE:  10-22-2005
 SERVICE(S):  GATE FC
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_SDD
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
   --------
             
   PROBLEM1:  HALT AT LOC stor-addr IN XOTFCDC : INV FC VCLCST

   PROBLEM2:  Alert message issued without NASnnnni prefix.

DESCRIPTION1: HNAS incorrectly processes CTCP reset packet request
              when it arrives at the same time as an inbound reset
              packet from the remote.

DESCRIPTION2: Following alert message generated without a message
              id header:

              lu-name LU 007C8800 SENDING DIAG PKT :FMD INV ON
                      FC GATE  CTL SES  BFR NEXT

  SOLUTION1:  <solution description>

  SOLUTION2:  <solution description>

CIRCUMVENTION: TO-BE-DETERMINED

 APPLY_INFO:  TO-BE-DETERMINED  

10-26-2005  - PROBLEM 2005256A

 PROBLEM_ID:  2005256A
     STATUS:  CLOSED, see APAR 2300161
  OPEN_DATE:  09-13-2005
PRVCHG_DATE:  09-17-2005
REVISE_DATE:  mm-dd-2005
 CLOSE_DATE:  10-26-2005
 SERVICE(S):  CONSOLE - Mon Tap
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_CPT
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
   --------

    PROBLEM:  Some console commands (MON TAP blank) are treated as
              ALLON when error message should be generated.

DESCRIPTION:  What's happening is that when MON TAP is entered
              without a follower, ON is assumed.  When RNM= is
              omitted and ID=0, the MON TAP flag is set in all
              PCEs.  That's why 'M' appears in the DPCE display.
              The use of ID=0 for all PCEs predates the addition
              of RNM=.  This is an unwelcome side affect of ID=0
              but it is well documented in the console section.
              What we need to fix this, that is, to issue a error
              message when ID= has not been set, is to treat ID=0
              differently than ID= omitted (or never specified).

   SOLUTION:  Numeric modifiers like ID= will now be treated as
              omitted when they are un-initialized.  If zero is
              specified for a numeric modifier, it will imply a
              request for 'all' related resources.  This will
              allow HNAS to issue an error message if a command
              that requires either ID= or RNM= and both are
              omitted (MON TAP for example).

              Further, specifying ID=0 will also generate an error
              message if a valid ID= value is required for a command
              (ID=lo{-hi} VARY for example).  For commands that
              treat ID=0 as 'all' PCEs, they will now process all
              PCEs if ID=0 or ID= (omitted) is specified. If a zero
              (0) value is entered for a numeric modifier, it must
              be entered as the only value (0-0 is not permitted).

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED  

09-09-2005  - PROBLEM 2005252A

 PROBLEM_ID:  2005252A
     STATUS:  OPEN, under analysis.
  OPEN_DATE:  09-06-2005
REVISE_DATE:  mm-dd-2005
 CLOSE_DATE:  10-18-2005 - See APAR 2300157
 SERVICE(S):  QLLC
  MANDATORY:  TO-BE-DETERMINED (TBD)
 ORIGIN/REF:  230_HVB  (distrib-aparid)
    CP_TECH:  PRT
    PUBLISH:  WIP
   PTF_INFO:  TO-BE-DETERMINED|N/A
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)
 ----------
  PTF_CLASS:  TO-BE-DETERMINED|N/A <OVERVIEW/SHORT PROBLEM MEMO>
 ----------

    PROBLEM:  QLLC session ended by remote, following message issued:
              NAS7601W MCH GRISU    LU HP1GRP08 DECODE RC=0C
              TH/RH=2C000108 2F890BB0 A0021030 3C1280C6

DESCRIPTION:  NAS7601W with RC=0C indicates a sequence error on the
              device to HNAS flow.  A 2001 -RSP is returned to the
              remote which causes the UNBIND.

   SOLUTION:  Apply 2300157 -- we believe the seq# error is due to
              incorrect combining of 2 FMD PIUs.

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED  

07-27-2005  - PROBLEM 2005071A

 PROBLEM_ID:  2005071A  (Enhancement)
     STATUS:  OPEN, under development/testing.
  OPEN_DATE:  03-12-2005
REVISE_DATE:  mm-dd-2005
 CLOSE_DATE:  07-27-2005 - Customer decided that they don't require
              special PVC switching for router backup control.
              General enhancement items 2-5 have been reassigned to
              problem 2005208A and will be provided shortly via an
              Enhancement APAR.        
 SERVICE(S):  PVC B/U Router Support and General Enhancement
  MANDATORY:  NO 
 ORIGIN/REF:  230_ITL
    CP_TECH:  CP
    PUBLISH:  YES, WIP
 ----------
   PTF_INFO:  TO-BE-DETERMINED
 ----------
  PTF_CLASS:  TO-BE-DETERMINED
 ----------

    PROBLEM:  Customer requires router/interface back-up solution
              (alternate connection) for their PVC sessions.

DESCRIPTION:  This requirement arises out of the ability of the
              telephone company to switch an X25 link to an
              alternate router.

   SOLUTION:  The alternate router must have a PVC configuration
              matching the configuration at the primary router.
              When this is done, HNAS will receive PVC SETUP packets
              and RESET cause=0F (network operational) packets from
              both routers.

              When a SETUP packet for a PVC that has already been
              setup is received, HNAS allocates a secondary VC
              (Virtual Circuit control block) for the session with
              the secondary router.  HNAS has no way to determine
              which router has the X25 link.

              After the secondary PVC session is established (by
              the SETUP packet) HNAS waits for data flow to identify
              the router with the X25 link.

              If inbound data is received the location of the X25
              link is known.

              If the PLU sends data, the data is sent to the router
              that established the first PVC session.  If this router
              has the X25 link then data flows normally.  If the
              router does not have the link then HNAS will receive
              a RESET cause=01, diagnostic=01 (out of order)
              indicating that the message was not delivered.  HNAS
              marks the VC to record the failure and notifies the
              PLU of the error by sending an UNBIND.  A new SLU
              session is started (ACB open REQSESS issued to ask for
              a BIND from the PLU).  When the PLU sends data on the
              new session the backup session with the backup router
              will be used.  If data can't be sent on the backup
              session (neither router has the X25 link) then HNAS
              will continue to attempt to send data until there is
              success or until data is received from the remote.


   NEW ALERT MESSAGES:

              In the following:
              lu_nm is the HNAS SLU name associated with an HNAS PVC.
              ip_addr(pt) is the ip address and port for a session
              HNAS has with a TYPE=XOT REMOTE.  rmt_nm is the name
              of the remote.

              NAS7770I LU lu_nm SWITCHING FROM ip_addr(pt)-rmt_nm
                       TO ip_addr(pt)-rmt_nm

              HNAS switching the named LU to a new ip address
              (backup session).

              NAS7771I LU lu_nm DROPPING ip_addr(pt)-rmt_nm
                       USING ip_addr(pt)-rmt_nm

              A second PVC SETUP received for the named LU.
              The existing session was not active so it was dropped
              and the secondary session will be used.

              NAS7772I LU lu_nm PRI PVC SES ip_addr(pt)-rmt_nm
                       START SEC SES ip_addr(pt)-rmt_nm

              A second PVC SETUP received for the named LU.
              A secondary session was established.

              NAS7773W UNABLE TO ALLOCATE 2ND SES PVC VC FOR LU lu_nm

              HNAS unable to allocate VC control block for a
              secondary pvc session when a PVC SETUP received.
              Check BUILD statement VCLMT= value.

              NAS7774W REMOTE rmt-nm CLOSED TCP SESSION IN RESPONSE TO
                       PVCSETUP FROM LU lu-nm

              This router response to a PVC SETUP indicates that the
              router already has an active PVC session for the PVC.


              If TRCMCH OCR specified when a PVC setup is sent by
              HNAS the following records are logged in SYSPRINT:

              NAS7719T OUTBOUND PVCSETUP GENERATED FOR LU lu-nm
                       PLU=plu-nm REMOTE=rmt-nm
              NAS7798T PVC STATUS=00 INIT LCN:NM lcn:Serialmch-nm
                       RESP LCN:NM lcn:rmt-int-nm
              NAS7798T (SENDER) IN.WIN=iw OUT.WIN=ow
                       IN.PSZ (2**N)=ip OUT.PSZ (2**N)=op

                       If ip=10 the input packet size is 2**10=1024.

              If TRCMCH ICR specified when a PVC setup is received
              by HNAS the following records are logged in SYSPRINT:

              NAS7718T ip-addr(port) PVCSETUP TO MCH mch-nm
              NAS7798T PVC STATUS=00 INIT LCN:NM lcn:Serialmch-nm
                       RESP LCN:NM lcn:rmt-int-nm
              NAS7798T (SENDER) IN.WIN=iw OUT.WIN=ow
                       IN.PSZ (2**N)=ip OUT.PSZ (2**N)=op

              The NAS7718T and NAS7719T are also used to trace
              inbound and outbound call requests ('CALL REQ' will
              appear where 'PVCSETUP' appears).


   REVISED STATUS CODES (General Enhancement):

              When HNAS is unable to process a PVC Setup packet from
              a router a PVC Setup response is returned with a
              status byte indicating the problem.  When the status
              code is greater than X'0F' the router will no longer
              attempt to setup the PVC.  HNAS used the codes from
              RFC 1613, many of which are greater than X'0F'.  If
              a router PVC is configured before HNAS is configured
              for the same PVC the HNAS reject status of X'13' (No
              such destination interface) will cause the router to
              stop sending setup requests for the new PVC.  If setup
              requests are required (as they are for backup support)
              then this causes a problem.  The following PVC Setup
              status codes are now used by HNAS:

              X'08'  Destination interface not up.
              X'09'  Window size > 7 or packet size > 4096.
              X'0C'  No such destination interface (MCH not found).
              X'0D'  No such destination PVC.
              X'0E'  PVC setup protocol error.
              X'0F'  No VC available for secondary PVC session
                     (NAS7773W issued).


   REVISED DVC (Console Command) OUTPUT FOR PVCs:

              The DVC command generates the following:
                PID  IFN  VCN  CID      SLUNAME  VCOPT VCST  LLC CLGADDR
                004A 002A 0001 B8000007 MCH1P001 V  PA DATA  PAD
                004A 0008 0001          MCH1P001 V  PA DATA  PAD

              The column under the 'P' in VCOPT contains an 'S' for
              SVCs and a 'P' for PVCs.  For PVCs the character to the
              right of the 'P' has the following meaning:

              'D' - PVC is down (PCV SETUP packets not exchanged).
              'A' - PVC available for use.  This state is set by
                    default when the SETUP exchange completes.
                    In the above, two SETUPs have completed for the
                    MCH1P001 LU (there is a primary VC session and
                    a secondary VC session).  The router with the X25
                    link will not be known until data packets are
                    received or sent.
              'I'   PVC is inactive (link down or out of order reset
                    has been received).

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED    

04-12-2005  - PROBLEM 2005041B

 PROBLEM_ID:  2005041B
     STATUS:  CLOSED, APAR 2300138 ISSUED.
  OPEN_DATE:  02-10-2005
REVISE_DATE:  mm-dd-2005
 CLOSE_DATE:  06-10-2005
 SERVICE(S):  PCNE/GATE/PAD Configuration Enhancement
  MANDATORY:  N/A
 ORIGIN/REF:  230_SDD
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  CUSTOM-USER-MOD
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  TBD 
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGSVC0, CNFGSVC4, CNFGSVC5
  SOURCE(S):  N/A

    PROBLEM:  The SVC0=, SVC4= and SVC5= operands do not currently
(ENHANCEMENT) allow an SLU prefix name, suffix start value and suffix
              count value to be specified to generate SLU names like
              the LUNAME= operand does for GATEFC SLUs.

DESCRIPTION:  See problem/solution.

   SOLUTION:  The SVC0=, SVC4= and SVC5= operand processors are being
              reviewed to see if SLU names can be generated based on
              a prefix name, suffix start value and suffix count value
              defined as the first, second and third operand entry.

              Currently, the first SVCi= entry is the vclmt and the
              subsequent entries are SLU names.  Missing SLU names are
              replaced by default SLU names which are created using
              the first 4-characters of the REMOTE name followed by a
              0|4|5 for the LLC type followed by the SVCi= index
              number (001, 002, 003, etc).

              Current:   SVCi=(vclmt,slunm1,slunm2,...)
              Alternate: SVCi=(pfxslu,sfxst,vclmt)

              The current and alternate specifications will both be
              accepted.  For the alternate specification:

              The pfxslu value may be any valid assembler language
              symbol up to 5-characters in length starting with
              either an alpha character (A,B,C,...,Z) or an accepted
              special character (@, #, $ or %).  This suboperand is
              REQUIRED to indicate that the new specification is
              being used.

              The sfxst value must be a hexadecimal number between
              0 and FFF without the framing characters X''.  If sfxst
              is omitted (,,), a default value of 0 will be used.

              The vclmt value must be a decimal number between 0 and
              511 (the SVCi= array size).  If vclmt is omitted, a
              default value of 1 will be used.

              As is the case with the LUNAME= operand, the SLU names
              that HNAS generates from the pfxslu, sfxst and vclmt
              will be always be 8-characters in length with zero (0)
              pad characters between the last pfxslu char and the
              suffix value.

              Examples:

              If SVC0=(TT,1,3) is specified, the generated SLU
              names would be TT000001, TT000002, TT000003.

              If SVC0=(TTTTT,1,3) is specified, the generated SLU
              names would be TTTTT001, TTTTT002, TTTTT003.

 APPLY_INFO:  N/A - Provided to user encountering the problem.
              This problem FIX is applied like an APAR.

03-08-2005  - PROBLEM 2005032B  (became APAR 2300119)

 PROBLEM_ID:  2005032B
     STATUS:  CLOSED, successfully tested at POR.
  OPEN_DATE:  02-01-2005
REVISE_DATE:  02-08-2005 Corrective logic sent to customer,
                         awaiting results.
REVISE_DATE:  02-23-2005 Second customer is encountering the
                         same failure.
REVISE_DATE:  03-02-2005 First customer is encountering output
                         hanging in host application queue.  
                         This is reflected in HNAS by NAS7717W 
                         message with CAUSE/DIAG=000/197 (00/C5).
 CLOSE_DATE:  03-08-2005
 SERVICE(S):  TCPIP SELECT timeout processing.
  MANDATORY:  TBD
 ORIGIN/REF:  230_POR,230_SNC
    CP_TECH:  SFD
    PUBLISH:  YES
 ----------
  PTF_CLASS:  CUSTOM-USER-MOD
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  TBD
   COREQ(S):  N/A
  PREREQ(S):  APAR 2300104 (and associated APARs PREREQ chains)
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  NASTCP

    PROBLEM:  0C4-10 ABEND can occur in client TCPIP SELECT timeout
              processor due to bad base register.

DESCRIPTION:  Logic added by APAR 2200073 (V2R2M0) to recover from
              a lost SELECT interrupt starts a timer when SELECT is 
              issued for a socket to detect pending input data.  If 
              the timer expires, it indicates that the TCPIP stack
              'forgot' to signal the end of the SELECT.  In this
              case HNAS issues a CANCEL which then forces the
              stack to end the SELECT.  This timeout is normally
              a very rare condition.  The ABEND is occurring because
              a transmit operation is also running before the SELECT
              timer expires.  The transmit processor changes the
              active base register value so when the timeout processor
              receives control it is no longer using the base register
              value that it had established but is instead using that
              of the transmit processor.  This wrong base register
              is what causes the ABEND.

              After further review, it appears that the SELECT
              timeout is occurring because the timer is not aborted
              when the SELECT ends normally.  This means that the
              timeout processor is being dispatched for a non-event.

              <begin 02-08-2005>
              After applying the fix, customer reports the following:

              Outgoing packets eventually stop flowing so the fix was
              removed.  An HNAS log of this error situation was not
              available, however, a Clear with cause/diag=011/243
              was received.

              Our BP contact asked the customer if someone had checked
              for the meaning of this Clear error code but only a
              generic was found.  Our BP contact found the following
              explanations:

              1) reason undefined - incompatible user data or
              2) disconnection - incompatible information in
                 user data or
              3) ITI timer expired or user aborted.
                 The ITI activity timer expired or you did
                 something to abort the call.  Try the call again.

              Our comments:

              While the customer observed that outgoing packets
              stopped flowing, the fix did, in fact, eliminate the
              ABEND.  The stoppage of outgoing packets may or may
              not be related to the fix.  We are currently awaiting
              additional information to be provided by the customer.
              <end 02-08-2005>

              <begin 03-02-2005>
              In addition to outgoing packets hanging in the host
              application output queue, HNAS is getting Call Accept
              timeouts which result in NAS7717W alarm message with
              with CAUSE/DIAG=000/197 (00/C5).

              This is occurring because the TCPRCV subroutine is not
              being called after the Call Request packet is sent.
              The result is that the subsequent Call Accept packet
              is not read in by HNAS.

              This is happening because CLNTRCV logic in NASTCP
              is testing PCECLK>0 to see if the PCE is running a
              timer.  The call to TCPRCV is bypassed in this case
              until the timer expires or has been cancelled.  But
              it turns out that the timer was cancelled by TRCVBLK
              logic by setting PCETMRX=0 but CLNTRCV does not know
              this because it is not testing PCETMRX>0.  It is
              testing the wrong field (PCECLK).

              When PCETMRX=0, NASTMR logic in NASUTIL will set
              PCECLK=0 when the PCE is removed from the timer QCB
              but this can happen as much as a second after CLNTRCV
              executes.  So, what we have is a timing problem.
              <end 03-02-2005>

   SOLUTION:  1) The SELECT timeout processor will be corrected to
                 restore its own base register before continuing its
                 execution.  This will prevent the 0C4 ABEND.

              2) The SELECT timer will be stopped when a SELECT ends
                 normally.  This will prevent the timeout processor
                 from getting control when it should not.

              <begin 03-02-2005>
              The SELECT timer logic at TRCVBLK set PCETMRX=0 to
              cancel the SELECT timer.  CLNTRCV logic has been
              changed to test PCETMRX instead of PCECLK.
              <end 03-02-2005>

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED

              This problem FIX is applied like an APAR and is
              intended for use by the customer that this problem
              report was opened for.

2006-09-25  - PROBLEM 2005018D

 PROBLEM_ID:  2005018D
     STATUS:  CLOSED, RETIRED
  OPEN_DATE:  2005-01-18
 CLOSE_DATE:  2006-09-25
 SERVICE(S):  LLC4 (GATE) MRMT LUNAME=sluname modify support.
  MANDATORY:  NO
 ORIGIN/REF:  230_BNP
    CP_TECH:  SFD
    PUBLISH:  YES
 ----------
  PTF_CLASS:  N/A

    PROBLEM:  Customer reports that they are unable to dynamically
              change the GATE pluname suboperand of the LUNAME= 
              operand for an MCH.

DESCRIPTION:  Customer originally thought they needed the ability to
              change the sluname or pluname of an LUNAME= entry for
              GATE support.  Subsequently, customer realized that this
              modification would induce other problems.  The rationale
              is that we always strongly recommend that users adopt
              the same names used with NPSI to minimize the changes in
              the environment in the first step of a migration.  When
              an user wants to change the SLU or PLU name for GATE,
              the best way is to stop and restart HNAS with a new CDF.
              Such a change also requires a change in the application
              so the application also has to be stopped and restarted.
              This obviously would also be true if the SLU or PLU name
              change was done dynamically in HNAS which essentially
              defeats the purpose of a dynamic change enhancement.

   SOLUTION:  N/A

CIRCUMVENTION: Stop HNAS and the CTCP application, change the required
               SLU and/or PLU names then restart HNAS and the CTCP.

 APPLY_INFO:  N/A   

01-24-2005  - PROBLEM 2005018B  (became APAR 2300104)

 PROBLEM_ID:  2005018B
     STATUS:  CLOSED
  OPEN_DATE:  01-18-2005
REVISE_DATE:  mm-dd-2005
 CLOSE_DATE:  01-24-2005
 SERVICE(S):  Outbound Call Request processing.
  MANDATORY:  TBD
 ORIGIN/REF:  230_POR
    CP_TECH:  SFD
    PUBLISH:  YES
 ----------
  PTF_CLASS:  CUSTOM-USER-MOD
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  TBD
   COREQ(S):  N/A
  PREREQ(S):  APAR 2300094 (and associated APARs PREREQ chains)
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  NASTCP

    PROBLEM:  Callout requests randomly fail and the following alarm
              message is issued:

              NAS7720W mchname CALL OUT, CAN'T CALL
                       CALLED ADDR=B071323332260000
                       CALLING ADDR=C071136596090000
              NAS7717W CAUSE/DIAG=000/130 (00/82) DIAGX=0010

DESCRIPTION:  This failure is timing related and is more apt to
              occur when there is a lot of simultaneous inbound and
              outbound connect activity.  Based on the HNAS log
              provided by the customer after a trace trap that was
              set as follows:

              TRCTRAP=(ALRMLIST=(NAS7720I),TRCACTION=(SNAP,SUSP)

              we were able to discover a timing window where the
              allocation of a REMOTE Process Control Element (PCE)
              for a callout attempt occurred while the HOME LOCAL
              PCE was in a pseudo IDLE state.  This state only occurs
              after the LOCAL PCE is used to close a temporary socket
              that was active during ACCEPT/TAKESOCKET processing.
              The LOCAL PCE is in dispatch pending state with
              PCESTAT=STIDLE which causes the REMOTE PCE allocator
              to 'think' that the HOME LOCAL is inactive when it
              really is not.

   SOLUTION:  The REMOTE PCE allocation routine has been modified
              to detect the pseudo IDLE state so that the outbound
              call attempt can be completed.

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED

              This problem FIX is applied like an APAR and is
              intended for use by the customer that this problem
              report was opened for.

2006-10-06  - PROBLEM 2005018A

 PROBLEM_ID:  2005018A
     STATUS:  CLOSED, APAR 2400008 issued.
  OPEN_DATE:  2005-01-18
 CLOSE_DATE:  2006-10-06
 SERVICE(S):  LLC4 (GATE) MRMT LUNAME=* modify support.
  MANDATORY:  NO
 ORIGIN/REF:  230_BNP
    CP_TECH:  SFD
    PUBLISH:  YES
 ----------
  PTF_CLASS:  TO-BE-DETERMINED

    PROBLEM:  Customer reports that they are unable to dynamically
              remote the asterisk that follows pluname suboperand
              of the LUNAME= operand for an MCH.

DESCRIPTION:  Customer specified a GATEFC MCH with the LUNAME=
              operand coded as follows:

              LUNAME=(V115A/GTMW4000*/R115/0/5)

              Since an asterisk (*) is specified after the pluname,
              HNAS will issue a REQSESS to force a BIND from the
              CTCP.  If the CTCP is not active, the REQSESS will
              fail and the following message will be issued:

              NAS3702W REQSESS FROM SLU V115A TO PLU GTMW4000
                       FAILED R15=xx R0=xx FDB2=xx SENSE=xxxxxxxx

              The customer does not want to activate the CTCP to
              eliminate this message and prefers to remove the
              asterisk 'on the fly' to prevent HNAS from issuing
              the REQSESS.  He wants HNAS to wait for the CTCP
              to come active and BIND the SLU when it does.

              The customer attempted to remove the asterisk by
              entering the following console command:

              RNM=V115 MRMT LUNAME=V115A/GTMW4000

              Unfortunately, this generated the following error
              message because LUNAME= modification is only allowed
              for TYPE=SPU REMOTE definition statements:

              NASC311E RNM=V115 TYPE=MCH INVALID, REQUIRED

   SOLUTION:  We will provide an enhancement that will allow the
              asterisk to be removed from the pluname suboperand
              of the LUNAME= operand for a TYPE=MCH|XTP REMOTE
              definition statement to be modified using the MRMT
              console command.

CIRCUMVENTION: Stop HNAS, remove the asterisk from the LUNAME=
               operand then restart HNAS.  OR, filter the NAS3702W
               alarm message dynamically using the ALARM console
               command as follows:

               ALARM FILTER=(NAS3702W(S or P))

 APPLY_INFO:  TO-BE-DETERMINED

01-04-2005  - PROBLEM 2004364A (became APAR 2300095)

 PROBLEM_ID:  2004364A
     STATUS:  CLOSED (pending APAR)
  OPEN_DATE:  12-29-2004
REVISE_DATE:  12-31-2004
 CLOSE_DATE:  12-31-2004
 SERVICE(S):  LLC0 (PCNE) callout
  MANDATORY:  NO.
 ORIGIN/REF:  230_IZB (see problem ref 2004356A)
    CP_TECH:  SFD
    PUBLISH:  OVERVIEW, Publish APAR
 ----------
  PTF_CLASS:  CUSTOM-USER-MOD
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  TBD
   COREQ(S):  See problem 2004356A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  Customer reports that default CUD used for PCNE
              callout 01000000 is actually CUD value for PAD call.

DESCRIPTION:  When CUD is not specified for a PCNE call, a default
              value of 01000000 is used.  This CUD is normally used
              for PAD and conditions the remote DTE to provide and
              accept PAD services rather than PCNE services.  The
              correct default value of C0000000 should be used for
              PCNE when the CUD is omitted from the SVC0= operand.

   SOLUTION:  HNAS will be modified to use a CUD value of 0C000000
              for callout PCNE SLUs when a CUD value is omitted from
              SVC0= operand entries.

CIRCUMVENTION: Code C0000000 as the CUD value for the callout SVC0
               entry as follows:

               SVC0=(vclmt,
                     :
                     sluname/dteaddr1{-dteaddr2-{dteaddr3}}O//C0000000,
                     :

 APPLY_INFO:  TO-BE-DETERMINED

              This problem FIX is applied like an APAR and is
              intended for use by the customer that this problem
              report was opened for.

 11-24-2004  - PROBLEM 2004328A

 PROBLEM_ID:  2004328A
     STATUS:  CLOSED
  OPEN_DATE:  11-23-2004
 CLOSE_DATE:  11-24-2004
 SERVICE(S):  GATE
  MANDATORY:  N/A
 ORIGIN/REF:  220_SIK
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  N/A
 ----------
  PTF_CLASS:  N/A
 ----------

    PROBLEM:  Customer getting 129 (X'81' clears).  GATE callin.

DESCRIPTION:  This clear code, used by HNAS to report a duplicate
              session, is being used by a remote system to clear
              a GATE call immediately after receiving a call accept
              from HNAS.

              Customer says that if HNAS is up for 2 or 3 days then
              the router runs out of VCs.  All calls get cleared with
              cause 001, diag 071 (busy, no logical channel
              available).

              We have no information on the state of HNAS when this
              happens.  This is a V2R2M0 system

   SOLUTION:  Router reconfigured to refuse calls from this customer
              (x25 route #n source dteaddr clear).

              Customer migrated to V2R3M0.  Will open new problem if
              condition isn't resolved.   

CIRCUMVENTION: N/A

 APPLY_INFO:   N/A  

11-18-2004  - PROBLEM 2004307A - Became APAR 2300086

 PROBLEM_ID:  2004307A
     STATUS:  CLOSED
  OPEN_DATE:  11-02-2004
REVISE_DATE:  11-09-2004
 CLOSE_DATE:  11-17-2004
 SERVICE(S):  QLLC
  MANDATORY:  YES
 ORIGIN/REF:  230_RWE
    CP_TECH:  PRT
    PUBLISH:  YES, WIP
   PTF_INFO:  TO-BE-DETERMINED
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)
 ----------
  PTF_CLASS:  TO-BE-DETERMINED
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004nnna.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: mm-dd-2004
              With APARs: 23000nn and 23000nn applied.
 SUPERSEDES:  N/A
  OBJECT(S):  QLSSCP, XOTUT1
  SOURCE(S):  N/A
 ----------

    PROBLEM:  QLLC sessions for devices on an SPU hang.

DESCRIPTION: 1) Transmission of a large RU causes HNAS to build a
                chain of X25 data packets connected by M (more data)
                bits.  An M-bit packet chain is created for each TH
                segment required to transfer the RU.  If HNAS receives
                a NOTIFY POWER OFF then transmission of output to the
                remote is terminated.  The termination can leave the
                X25 level with an active M bit chain.  HNAS send
                operations are deferred until the chain is completed.
                Because of a logic error the M bit chain is never
                completed and send operations stop for all devices on
                the SPU.

                <Nov 09, 2004 revision>
             2) When a HNAS QLLC PU activates HNAS sends an ACTLU PIU
                to every LU defined for the PU.  These PIU flow on
                the LU-LU session.  If activity occurs on the HNAS
                to remote PU session (such as a NMVT request) a
                situation can occur where HNAS is waiting for an
                an ACTLU response before it sends the NMVT response
                and the remote is waiting for an NMVT response before
                sending an ACTLU response.
                <Nov 09, 2004 revision>

   SOLUTION: 1) Logic corrected to properly terminate an M bit chain
                when a NOTIFY POWER OFF is received.

                <Nov 09, 2004 revision>
             2) HNAS scheduling logic revised to avoid the deadlock.
                <Nov 09, 2004 revision>


 APPLY_INFO:  See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance.

              Corrective logic included in distributions created
              after CLOSE_DATE.  Otherwise, apply maintenance as
              directed in the APPLY_INFO (PTF).

08-23-2005  - PROBLEM 2004300A

 PROBLEM_ID:  2004300A  (became APAR 2300152 08-23-2005)
     STATUS:  CLOSED
  OPEN_DATE:  10-26-2004
REVISE_DATE:  11-10-2004
 CLOSE_DATE:  11-10-2004
 SERVICE(S):  PAD
  MANDATORY:  YES, for certain host applications like TPE.
 ORIGIN/REF:  230_SDD
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)

    PROBLEM:  Customer reports that PAD terminals cannot communicate
              with TPE host application.

DESCRIPTION:  PAD terminals are unable to effectively communicate
              with certain host applications like TPE because
              special ASCII characters are not being translated
              correctly for the application.

   SOLUTION:  HNAS provides an alternate translate table as member
              MCHTTBL1 in the HNASMAC library.  By assembling this
              member using the inline PROC in the HNASMNT job and
              stowing the object output in the HNASOBJ library
              as member MCHTTBLS, the HNAS link edit step will
              pick up the correct translate tables for TPE access.

              Starting with distributions after October 26, 2004
              HNAS provides the alternate translate table as module
              MCHTTBL1 in the HNASOBJX library.  By changing the
              module name to MCHTTBLS, the assembly of the HNASMAC
              member MCHTTBL1 can be avoided.

CIRCUMVENTION: See SOLUTION.

 APPLY_INFO:  See SOLUTION.  

11-16-2004  - PROBLEM 2004286A - Became APAR 2300085

 PROBLEM_ID:  2004286A 
     STATUS:  CLOSED, APAR issued.
  OPEN_DATE:  10-12-2004
REVISE_DATE:  11-16-2004
 CLOSE_DATE:  11-16-2004
 SERVICE(S):  LLC4
  MANDATORY:  YES
 ORIGIN/REF:  230_RWG / 230_RBG
    CP_TECH:  PWB
    PUBLISH:  PENDING, Under Construction
   PTF_INFO:  TO-BE-DETERMINED
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)

    PROBLEM:  HNAS display shows bound GATE data LUs with no VC.
              These LUs are not available for new sessions.

DESCRIPTION:  When HNAS sends a a clear packet to a CTCP and UNBIND
              is expected in response.  If there is no UNBIND the
              HNAS LU is 'lost' (unavailable for new calls).

   SOLUTION:  The following improvements have been made in GATE
              session end processing:

              1) When a clear is sent to the CTCP HNAS starts a
                 3 second timer.  If the timer expires the LU is
                 released (PLU will receive a NOTIFY).  The
                 diagnostic byte in the NAS3799I session end message
                 will be 221 (X'DD').

              2) Some CTCPs send a final message after receiving a
                 clear packet from HNAS.  This message is rejected by
                 HNAS since there is no session.  The rejection makes
                 the CTCP think there is an error.  With this apar on
                 the message is silently discarded.  Tests indicate
                 that if HNAS sends the message to the remote it will
                 be silently discarded by the router.

              3) If HNAS receives a clear to a VC that is already
                 clearing then the second clear is ignored.  In order
                 to detect this session end error an alarm message

                 NAS7713W SECOND CLEAR FROM ip-addr ON rmt-name
                          MCH mch-nm LU lu-nm

                 is issued to record the error.  Additionally, the
                 session is ended with a diagnostic code of 222
                 (X'DE').

CIRCUMVENTION: N/A

 APPLY_INFO:  TO-BE-DETERMINED  

11-18-2004  - PROBLEM 2004279A  - Became APAR 2300086 

 PROBLEM_ID:  2004279A
     STATUS:  CLOSED
  OPEN_DATE:  10-05-2004
REVISE_DATE:  11-09-2004
REVISE_DATE:  11-10-2004 (REQDISCONT/NMVT decode problem removed
                         from this problem.  Now covered under
                         problem 2004247A)
 CLOSE_DATE:  11-10-2004
 SERVICE(S):  QLLC
  MANDATORY:  YES, when QLLC resources are required
 ORIGIN/REF:  RWE_230
    CP_TECH:  SFD
    PUBLISH:  YES, CLOSED
   PTF_INFO:  TO-BE-DETERMINED
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)
 ----------
  PTF_CLASS:  APAR-BUG
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004279A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 05-28-2004
              With APAR: 2300039
 SUPERSEDES:  N/A
  OBJECT(S):  QLSSCP
  SOURCE(S):  N/A
 ----------

    PROBLEM1: NASHALT 0198 ABEND can occur when a NOTIFY request
              is received.

    PROBLEM2: ACTPU text in NAS8110I message is being overlaid.

DESCRIPTION1: When a QLLC SLU is configured for auto logging
              (applid value is specified for the SLU in the
              LUNAME= operand), an ABEND can occur due to a
              timing problem when a NOTIFY request with the
              power on indicator is received.  The following
              NASHALT text is generated:

              HALT AT LOC 80059016 IN   QLALOG: QLCLOT BIND INIT
                                                FAILURE

              It turns out that the name of the routine (QLALOG)
              is not displayed correctly and the failure reason
              is misleading.  It is a BIND initialization failure
              but not because of callout but rather because of a
              timing problem.

              Here is the sequence leading up to the ABEND:

              Event                               Comments

              ACTLU response received from SLU    power off indicated
              NOTIFY request received from SLU    power on indicated
              VTAM OPEN ACB performed
              VTAM SETLOGON performed
              VTAM REQSESS issued                 SLU wired to PLU
              BIND request sent by PLU
              NOTIFY request received from SLU    power off indicated
              BIND EXCR received from SLU         0801 sense included
              NOTIFY request received from SLU    power on indicated

              The last NOTIFY request results in the ABEND because
              the HNAS SSCP simulator thinks that the SLU is idle.
              This is due to the previous NOTIFY with power off.
              HNAS then attempts to autolog the SLU on to the PLU.
              However, because BIND processing has not completed,
              the autolog processor (QLALOG) finds the previous
              BIND still pending.  This is a validity error that
              causes the NASHALT.  The problem seems to be related
              to the NOTIFY request with power off that is received
              while the BIND request is in flight.  The NOTIFY
              processor fails to recognize this state.  This causes
              the SSCP/SLU state to be set to IDLE.  In this state
              subsequent PIUs directed at the PLU are purged.  This
              prevents the BIND response from getting back to the
              PLU which leaves the PLU/SLU state as BIND pending
              which results in the ABEND when the last NOTIFY is
              received.

DESCRIPTION2: ACTPU text in NAS8110I message is being overlaid
              when NAS8141W INVALID REQ message is issued.  The
              register used to convert the decode return code that
              is displayed as RC=XX at end of the NAS8141W message
              is actually pointing to body of NAS8110I message.
              The result is that ACTPU text is overlayed by
              NAS8141W RC value and RC value at end of NAS8141W
              message displays as XX.

   SOLUTION1: The ABEND routine name and reason have been corrected
              in the QLALOG routine.  The NOTIFY request processor
              has been modified to detect the BIND in progress state
              when the power off indicator is set.  If this occurs,
              the ACB will be closed.  Closing the ACB will force
              the outstanding BIND request to be aborted.  This
              will prevent the ABEND from occurring when the NOTIFY
              request with power on is received.

   SOLUTION2: HNAS has been modified to point at the correct location
              so that the RC value at the end of the NAS8141W message
              is displayed correctly and the ACTPU text in the
              NAS8110I message is not overlayed.

CIRCUMVENTION: N/A

 APPLY_INFO:  This problem FIX is applied like an APAR and is
              intended for use by the customer that this problem
              report was opened for.

12-09-2004  - PROBLEM 2004264A  - Became APAR 2300092 

 PROBLEM_ID:  2004264A
     STATUS:  CLOSED
  OPEN_DATE:  09-20-2004
REVISE_DATE:  11-28-2004
 CLOSE_DATE:  12-09-2004
 SERVICE(S):  GATE
  MANDATORY:  N/A
 ORIGIN/REF:  230_SWC (2300069), IZB, BNP, RWG, HVB
    CP_TECH:  PRT
    PUBLISH:  YES, WIP
   PTF_INFO:  TO-BE-DETERMINED
 ----------
  PTF_CLASS:  TO-BE-DETERMINED
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas230m/apars/
              (Complete FIX is contained in the @apar.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  VCCLEAR, XOTRCV, XOTXMTC 
  SOURCE(S):  N/A
 ----------

    PROBLEM:  NAS7703W alarm issued when remote sends Diagnostic
              packet.

DESCRIPTION:  HNAS GATE session termination logic does not release 
              the VC and LU control blocks for the session until 
              the CTCP has been sent a Clear or Clear-Confirm 
              packet to the CTCP. If the CTCP does not have a 
              RECEIVE active to accept the HNAS termination message 
              then the VC's TCPIP session is left active. In this 
              state a new call can be received. HNAS treats this 
              as an error and tries to clear the new call. HNAS sees
              the second clear for the VC as an error and does not 
              send the clear. After 10 minutes the router sends a 
              diagnostic packet which causes the alarm messages: 
 
                NAS7703W DIAG FROM ip-addr(port) 
                NAS7799I PKT=1000F132 1001. 

   SOLUTION:  Correct HNAS logic to release the VC control block 
              and close the TCP/IP session as soon as transmission
              of a GATE Clear packet completes. 

CIRCUMVENTION: N/A

APPLY_INFO:  This problem FIX is applied like an APAR and is
              intended for use by the customer that this
              problem reported was opened for. 

11-19-2004  - PROBLEM 2004252A  (became APAR 2300088)

 PROBLEM_ID:  2004252A
     STATUS:  CLOSED
  OPEN_DATE:  09-08-2004
REVISE_DATE:  11-01-2004 (COREQ added)
 CLOSE_DATE:  11-19-2004
 SERVICE(S):  TCPIP
  MANDATORY:  N/A
 ORIGIN/REF:  230_BNP
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  N/A
   COREQ(S):  Problem 2004204A
  PREREQ(S):  APAR 2300047
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  NASTCP

    PROBLEM:  HNAS can terminate abnormally with ABEND 0198 (NASHALT)
              after a TCPIP stack is stopped.

DESCRIPTION:  This latest 0198 ABEND (NASHALT) that has occurred
              when a customer took the stack down underneath HNAS
              is a completely new problem, related but different
              than the problem corrected by APAR 2300042.  We have
              never seen it before.  APAR 2300042 addressed a
              problem with the HNAS stack 'SEVER' logic which was
              fixed and extensively tested on out z/OS V1R4 system.
              It turns out that the SEVER correction logic introduced
              by APAR 2300042 is working just fine.  However, the
              subsequent logic that attempts to re-establish contact
              with the SEVERed stack has found a problem.  Briefly:

              When HNAS is first started OR after a connection
              between a stack and an HNAS LOCAL is SEVERed (the stack
              is taken down), HNAS continually attempts to establish
              contact with the stack for the LOCAL.  As part of this
              processing, HNAS interrogates all the stacks to see if
              the stack identified by the LOCAL TCPNAME= operand can
              accept an API connection.  HNAS uses the GETIBMOPT
              command to do this.  This command is processed by the
              z/OS MVS system (UNIX kernel) on behalf of all stacks
              running on the system.  The command produces a map of
              the installed stacks and has the following format:

              byte   contents

              00-03  stack count => number of TCPIP images
                     (0=> no images present)

              04-0F  map for first stack image

                     04-05 status: 8xxx => stack is active
                                   4xxx => stack is terminating
                                   2xxx => stack is down
                                   1xxx => stack has stopped
                                           or is stopping

                     06-07 stack version

                     08-0F stack name (TCPNAME=)

              10-1B map for second stack image
              :
              etc

              When the GETIBMOPT command ends, HNAS interrogates
              the map produced by GETIBMOPT.

              If the stack count is zero, HNAS waits and then retries
                 the GETIBMOPT command after a forced delay.

              If the stack count is non-zero, HNAS steps through the
                 map looking for a stack name match with the TCPNAME=
                 operand on the requesting LOCAL.

              If a name match is not found, HNAS waits and then retries
                 the GETIBMOPT command after a forced delay.

              If a name match is found, HNAS tests the status flags.

              If the status flags are 8xxx, HNAS assumes that the
                 named stack is active.  In this case, HNAS attempts
                 to establish an API connection to the stack using
                 the INITAPI command.  The ABEND 0198 is occurring
                 because the INITAPI command is being rejected with
                 ERNO=040C which says 'TCP/IP is not installed or
                 is not active'.  This makes no sense because the
                 GETIBMOPT command indicated that the named stack
                 was active.  HNAS is now confused and this results
                 in the NASHALT - 0198 ABEND.  We do NOT believe that
                 this is an HNAS problem.  HNAS is being tricked into
                 thinking that the SEVERed stack is actually active.

   SOLUTION/  HNAS TCPIP logic will be modified to treat an INITAPI
CIRCUMVENTION failure as though the GETIBMOPT command showed that
              the stack was down.  The 0198 ABEND will be prevented
              and HNAS will retry the GETIBMOPT command after a forced
              delay.  The GETIBMOPT/INITAPI commands will continue to
              be executed until the named stack comes active or HNAS
              is shutdown.

 APPLY_INFO:  N/A - Provided to user encountering the problem.
              This problem FIX is applied like an APAR.

03-21-2005  - PROBLEM 2004247A  - Became APAR 2300122

 PROBLEM_ID:  2004247A
     STATUS:  CLOSED
  OPEN_DATE:  09-03-2004
REVISE_DATE:  mm-dd-2004
 CLOSE_DATE:  03-21-2005
 SERVICE(S):  QLLC
  MANDATORY:  YES, when QLLC resources are required
 ORIGIN/REF:  RWE_230
    CP_TECH:  SFD
    PUBLISH:  YES, WIP
   PTF_INFO:  TO-BE-DETERMINED
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)
 ----------
  PTF_CLASS:  APAR-BUG
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004247A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 05-28-2004
              With APAR: 2300039
 SUPERSEDES:  N/A
  OBJECT(S):  QLSSCP
  SOURCE(S):  N/A
 ----------

    PROBLEM:  REQDISCONT and NMVT PIUs are rejected with NAS8141W
              message followed by a Clear Request.

DESCRIPTION:  HNAS does not decode REQDISCONT or NMVT but issues
              a NAS8141W message and clears the call instead.
              The REQDISCONT logic ultimately leads to Clear anyway
              after DACTLU, DACTPU and DISCONT PIUs would have been
              exchanged.  The rejected NMVT also clears the call
              when it should not.

   SOLUTION:  HNAS will be modified to inhibit the NAS8141W reject
              message for REQDISCONT and NMVT and process these PIUs
              as required.

CIRCUMVENTION: N/A

 APPLY_INFO:  This problem FIX is applied like an APAR and is
              intended for use by the customer that this problem
              report was opened for.  

09-17-2004  - PROBLEM 2004243A - Became APAR 2300072  

 PROBLEM_ID:  2004243A
     STATUS:  PENDING user test, under analysis. CLOSED, APAR 2300072 issued. 
  OPEN_DATE:  08-30-2004
REVISE_DATE:  mm-dd-2004
 CLOSE_DATE:  09-17-2004
 SERVICE(S):  GATE
  MANDATORY:  N/A
 ORIGIN/REF:  SWC_230
    CP_TECH:  PRT
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED - 
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)
 ----------
  PTF_CLASS:  APAR-BUG
 ----------

    PROBLEM:  Inbound GATE call requests fail with the message
              NAS7702E CALL REQ REFUSED - NO VC BLOCKS OR BUFFER
              SHORTAGE CLEAR DIAG=130 (82)

DESCRIPTION:  All the customer's VC's (a total of 9) are on the
              MCH active queue.  All are in state P6 (clear sent).
              All carry a diag byte of C6 (inactivity timeout).
              The VCPCE pointer is zero in all VCs, indicating the
              TCP/IP connection is gone.

              The customer has IDLETO=1 coded on BUILD.  Because
              of a V2R3M0 change to a branch, 1 indicates anything
              in the range 0 to 1 seconds (it was 1 to 2 in V2R2M0).
              The early expiration of this timer appears to have
              uncovered a bug in the GATE session takedown sequence.

              Further dump analysis required.  Customer told to 
              increase the VC count and set IDLETO to 2.

   SOLUTION:  Under investigation

CIRCUMVENTION: Ensure sufficient number of VCs, code IDLETO=2 if
               1 is desired.

 APPLY_INFO:  TO-BE-DETERMINED 

08-16-2004  - PROBLEM 2004228A - Became APAR 2300067

 PROBLEM_ID:  2004228A
     STATUS:  CLOSED
  OPEN_DATE:  08-15-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  08-16-2004
 SERVICE(S):  NASAUTH Authorization File Validation 
  MANDATORY:  NO
 ORIGIN/REF:  230_NBG 
    CP_TECH:  SFD 
    PUBLISH:  YES 
   PTF_INFO:  N/A, see APAR. 
              
    PROBLEM:  Descriptive WTO message not provided when NASAUTH 
              Authorization failure occurs (ABEND 198 'AC FAILURE)
              due to customer coding error (//AUTH DD statement). 

DESCRIPTION:  When a bad NASAUTH file is supplied, HNAS will ABEND 
              at startup time with NASHALT 198 'AC FAILURE' but 
              it is not always easy to tell why the NASAUTH file 
              is bad.  HNAS issues a WTO before the NASHALT to 
              identify the reason for the failure but sometimes 
              the WTO can be purged by the system during the ABEND 
              processing. This appears to be timing related. 

   SOLUTION:  Instead of a 'catchall' ABEND reason for the NASHALT,
              a specific description will be provided in addition 
              to the WTO which may or may not be displayed. 

APPLY_INFO: N/A - PROVIDED TO USER AS REQUIRED. 

12-21-2004  - PROBLEM 2004225A  (covered under APAR 2300092) 

 PROBLEM_ID:  2004225A
     STATUS:  CLOSED, variation of problem 2004264A (2300092)
  OPEN_DATE:  08-12-2004
 CLOSE_DATE:  12-21-2004
 SERVICE(S):  X.25 General (DIAG packets received)
  MANDATORY:  N/A
 ORIGIN/REF:  230_IZB (BTX Online Application LLC4/GATE)
    CP_TECH:  SFD
    PUBLISH:  YES
   PTF_INFO:  TO-BE-DETERMINED
              (CLASS/TYPE/LOC/COREQ/PREREQ/SUPER/OBJECT/SOURCE)

    PROBLEM:  X.25 Diagnostic packets with code=228 (X'EE') are
              being spuriously received and the following messages
              are produced.

              NAS7703W DIAG FROM 172.016.137.065(40561)
              NAS7799I PKT=1000F1EE 1001

DESCRIPTION:  See problem.

              Note that the customer says the router is front-ended
              by a DATUS X.25/ISND switch.  We are not sure if the
              switch is the cause of the problem.  This is under
              investigation.

   SOLUTION:  A TRCALL trace with TRCTRAP=(RCVLIST=(04F1EEFF)) is
              being collected to see what leads up to the reception
              of the Diag packet.  Router traces are also expected
              to be run.  Waiting on trace results.

 APPLY_INFO:  N/A 

11-11-2004  - PROBLEM 2004212A

 PROBLEM_ID:  2004212A
     STATUS:  CLOSED   
  OPEN_DATE:  07-30-2004
 CLOSE_DATE:  11-11-2004
 SERVICE(S):  Alarm messages
  MANDATORY:  N/A
 ORIGIN/REF:  230_NBG
    CP_TECH:  SFD/PWB
    PUBLISH:  YES
   PTF_INFO:  Shipped as a user mod.
              Contact Comm-Pro for current location.
  PTF_CLASS:  CUSTOM-USER-MOD.
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
   COREQ(S):  N/A
  PREREQ(S):  2300051, 2300047
 SUPERSEDES:  N/A
  OBJECT(S):  XOTTR  (NAS7... alarm messages)
  SOURCE(S):  NASTCP (NAS2... and NAS8... alarm messages)

    PROBLEM:  User's Host Automation Monitor program has difficulty
              filtering multi-line HNAS alert messages because all
              lines of the message start with the same string (e.g.
              NAS7717W).

DESCRIPTION:  See problem.

   SOLUTION:  A custom mod to install sequence numbers in multi-line
              alarm messages is available.  For example, NAS7717W
              alarm will be displayed as two lines starting with
              NAS7717W1 and NAS7717W2.  Insertion of the sequence
              number shifts the message text to the right.

CIRCUMVENTION: N/A

 APPLY_INFO:  The custom mod is applied like an APAR.
              See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance. 

11-15-2004  -  PROBLEM 2004208B - Became APAR 2300084

 PROBLEM_ID:  2004208B
     STATUS:  CLOSED
REVISE_DATE:  08-25-2004
REVISE_DATE:  10-15-2004
 CLOSE_DATE:  11-15-2004
 SERVICE(S):  Modify PCNE/GATE/PAD SLU names
  MANDATORY:  OPTIONAL
 ORIGIN/REF:  230_SDD
    CP_TECH:  SFD
    PUBLISH:  YES, OVERVIEW
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004nnnB.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 08-16-2003
              With APARs: 2300066, 2300065, 2300064, 2300061, 2300060
              and their associated pre-reqs.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSDRMT, CONSHELP, CONSMLCL, CONSMRMT,
              MCHSVCI, MCHUT1, NASCNFG
  SOURCE(S):  N/A

    PROBLEM:  Customer requires the ability to modify SLU names in
(ENHANCEMENT) their PCNE, GATE and PAD CFT environment.

DESCRIPTION:  Some users need the ability to add or modify SLU
              names for LLC0 (PCNE), LLC4 (GATE) and/or LLC5 (PAD)
              connections.  Normally, SLU names for PCNE/GATE/PAD
              resources are fixed by the configuration.  This means
              that HNAS must be stopped and restarted in order to
              and or change a PCNE/GATE//PAD SLU name.

   SOLUTION:  The HNAS MRMT console command processor is has been
              modified to allow PCNE/GATE/PAD SLU names to be added
              or changed for the SVC0=/SVC4=/SVC5= operands on a
              TYPE=MCH REMOTE in a manner similar to what is now
              done for the LUNAME= operand on a TYPE=SPU REMOTE.

              The following HELP MRMT display illustrates the syntax
              that is used for the enhanced MRMT SVC0=|SVC4=|SVC5=
              console command processor:

              {SVC0=sluname{={*|newname}}
                    /{*|{X}dd...dd||I{applid}
                       |dd...dd-dd...dd-dd...dd||O
                       |{X}dd...dd-{X}dd...ddd-{X}dd...dd||B{applid}}
                    /{*|mxtname}
                    /{*|cud}}
              {SVC4=sluname{={*|newname}}}
              {SVC5=sluname{={*|newname}}
                    /{*|{X}dd...dd||I{applid}
                       |dd...dd-dd...dd-dd...dd||O
                       |{X}dd...dd-{X}dd...ddd-{X}dd...dd||B{applid}}
                    /{*|mxtname}
                    /{*|cud}}

              NOTE: enter * for dd...dd|applid|mxtname|cud|rcvcnt|
                            sndcnt to delete the value
                          * after sluname= to delete an existing
                            SLU entry
                          a newname after sluname= to change an
                            existing SLU name
                          the same sluname after sluname= to add a
                            new SLU name

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A - PROVIDED TO USER AS REQUIRED.

2006-08-11  - PROBLEM 2004208A

 PROBLEM_ID:  2004208A
     STATUS:  CLOSED - Documentation updated improving description.
  OPEN_DATE:  2004-07-26
PRVCHG_DATE:  2004-11-15
REVISE_DATE:  2005-09-22 - Deferred.
 CLOSE_DATE:  2006-08-11
 SERVICE(S):  CDF Configuration Error Messages
  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:  Some HNAS Configuration Alert Messages don't
              correctly describe the error condition encountered.

DESCRIPTION:  The following configuration error message is pending
              correction:

              NAS1301S REMOTE XOTCNIN  HOME DEFAULT CANNOT
                       BE RESOLVED FOR TYPE=XOT, REQUIRED

              This message is generated because the SOCLMT= operand
              for the default HOME LOCAL definition statement is
              too low, that is, more REMOTE sockets of the same type
              (e.g., TYPE=XOT) were defined via the REMOTE VCLMT=
              operand than were reserved via the LOCAL SOCLMT=
              operand.


              Format1 generic description:

              NAS1301s REMOTE opname OMITTED, action

              Indicates that the opname operand on the REMOTE
              definition statement was omitted.  This version of
              the NAS1301s message does not display a REMOTE name
              because it is generated during the processing of the
              current REMOTE definition statement.  The REMOTE name
              is displayed after the line of asterisks that starts
              the REMOTE processing.  The current REMOTE is
              delimited by a new line of asterisks.


              Format2 generic description:

              NAS1301s REMOTE rmtname opname OMITTED, action

              Indicates that the opname operand on the REMOTE
              definition statement named rmtname was omitted.  This
              version of the NAS1301s message displays a REMOTE name
              because it is generated after the entire CDF is scanned
              rather than during processing of the current REMOTE
              definition statement.

   Solution:  Ensure that the SOCLMT= value is large enough to
              handle all the REMOTE sockets of the same type
              whether or not a HOME LOCAL is specified for the
              REMOTE via the HOME= operand or a default HOME
              LOCAL is assigned by the configuration.

CIRCUMVENTION: Allow the SOCLMT= operand value to default.  The
              default of 2000 is normally large enough to handle
              all REMOTE sockets.  If more are required, increments
              of 2000 should be specified for SOCLMT=.  The SOCLMT=
              value should always be larger than the sum of all
              REMOTE VCLMT= operand values for a LOCAL and REMOTE
              of the same type.

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

11-19-2004  - PROBLEM 2004204A  (became apar 2300088)

 PROBLEM_ID:  2004204A
     STATUS:  CLOSED
              (was OPEN, pending tests for 11-01-2004 modifications)
  OPEN_DATE:  07-22-2004
REVISE_DATE:  07-27-2004 - reviewing traces/control blocks
              Original problem description indicated the customer's
              CTCP (TOM) ABENDed during load tests.

              Customer analysis showed that the CTCP ABEND was a
              result of a TOM CTCP bug (APAR-ID=xxxxxxxxx) caused
              by the load generating program (calls wrapped at
              the router).  With the TOM fix applied the load test
              continued to generate the NAS2201 error message with
              the 27DD RC.  After this message has been issued HNAS
              requires a reload.  References to the CTCP ABEND have
              been removed from the following text.
REVISE_DATE:  09-09-2004
REVISE_DATE:  11-01-2004
 CLOSE_DATE:  11-19-2004
 SERVICE(S):  GATE, TCPIP interface
  MANDATORY:  YES
 ORIGIN/REF:  230_BNP
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  STANDARD APAR (after problem fix has been verified)
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory for customer experiencing problem
              (SMP/E format cumulative distribution)
   COREQ(S):  Problem 2004252A
  PREREQ(S):  APARs 2300082, 2300081, 2300061 (and associated APAR
              chains)
  OBJECT(S):  CONSDPRM, CONSHELP, CONSSHOW, CONSSTAT, CONSTBFR,
              CONSTDAT, CONSTDSP, CONSTIO, NASCNFG, NASUTIL
  SOURCE(S):  NASMAIN, NASTCP, XFBLK, XFNASWA, XFPCE

    PROBLEM:  X.25 Network load test can cause HNAS to issue the
              following:

              NAS2201W SOCKET REQUEST FAILED, RC=FFFFFFFF 000027DD
              NAS7717W LU lu-name CALL TO DTE ADDR dte-addr VIA
              REMOTE xxxxxxxx FAILED
              NAS7717W CAUSE/DIAG=000/195 (00/C3) DIAGX=0000

              After this outbound call requests fail and HNAS must
              be reloaded.

DESCRIPTION:  At the time of the failure the customer was conducting
              stress tests using a CTCP named TOM.  The above error
              message indicates that HNAS is trying to use a socket
              that the stack thinks is already in use.  This
              indicates that an error has been made in the recording
              of active sockets.

              09-09-2004 <begin>
              The fix to NASTCP to ensure that the ACCEPT socket
              number is not used as the TAKESOCKET socket number
              does not seem to correct the NAS2201W ERNO=27DD error
              condition.  The last HNAS log from Gerard had TCPIP
              informational messages being purged from SYSPRINT so
              we could not see what led up to the NAS2201W error.
              The ALRMFLTR= operand was changed from the original
              value that originally showed why the NAS2201W error
              was being generated.
              09-09-2004 <end>

              11-01-2004 <begin>
              27DD error condition occurs when HNAS is busy
              processing numerous inbound and outbound socket
              connection requests and many sockets are already in
              use.  Problem occurs because the TAKESOCKET processor
              does not record the new socket that is passed from the
              server subtask to a client subtask for an inbound
              connection.  If an outbound SOCKET request is initiated
              after the TAKESOCKET request has started, the SOCKET
              processor will wind up using the same socket that is
              being used by the TAKESOCKET processor.  Because events
              are processed FIFO by the TCPIP stack, the TAKESOCKET
              request will win the socket and the SOCKET request will
              fail with the 27DD error condition (NAS2201W message).

              The reason that this problem does not occur more
              often is because HNAS allocates sockets for outbound
              connections from low to high while it allocates sockets
              for inbound connections from high to low.  When many
              sockets are active, an intersection can occur.
              11-01-2004 <end>

   SOLUTION:  A trace will be required to see why the 27DD (socket
              in use) error occurred.

              09-09-2004 <begin>
              Advised Gerard to specify ALRMFLTR=(A) so that all
              informational alarms are logged in SYSPRINT.  This
              should show what led up to the NAS2201W error.
              Awaiting further input from BNP.
              09-09-2004 <end>

              10-08-2004 <begin>
              Updated version of NASTCP (APARID=P04204A2) contains
              logic to display socket descriptor set in SYSPRINT
              if SHOWMORE option set (option forced on).  In
              addition, abbreviated trace entries generated to
              log SOCKID, SOCCNT, SOCLMT when socket is opened
              or closed via SOCKET, ACCEPT or TAKESOCKET call.
              10-08-2004 <end>

              11-01-2004 <begin>
              SHOWMORE option incorporated as a start parm.  It
              controls logging of additional diagnostic information
              in SYSPRINT, specifically NAS2711I messages that
              display socket in use descriptor flags (PCESOCDS).

              NASTCP has been modified to record every socket
              allocation request.  Previously, SOCKET and ACCEPT
              socket allocations were recorded but TAKESOCKET socket
              allocations were not (an oversight).  This resulted
              in the 27DD error condition due to collision when a
              SOCKET call for an outbound request and a TAKESOCKET
              call for inbound request occurred simultaneously.
              Because TAKESOCKET socket allocation requests are
              now recorded, a SOCKET request will not be able to
              the same socket that is being used by TAKESOCKET.
              This will eliminate the 27DD error condition.
              11-01-2004 <end>

 APPLY_INFO:  N/A - PROVIDED TO USER AS REQUIRED.  

07-23-2004  - PROBLEM 2004201A 

 PROBLEM_ID:  2004201A
     STATUS:  CLOSED - Became APAR 2300060
  OPEN_DATE:  07-19-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  07-23-2004
 SERVICE(S):  DATE Feature under GATE
  MANDATORY:  NO
 ORIGIN/REF:  230_BNP
    CP_TECH:  PWB
    PUBLISH:  YES, WIP
  PTF_CLASS:  CUSTOM-USER-MOD
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  N/A
   COREQ(S):  TO-BE-DETERMINED
  PREREQ(S):  TO-BE-DETERMINED
 SUPERSEDES:  TO-BE-DETERMINED
  OBJECT(S):  TO-BE-DETERMINED
  SOURCE(S):  TO-BE-DETERMINED

    PROBLEM:  HNAS doesn't support DATE feature.

DESCRIPTION:  LLC5 session that used to operate under DATE can't
              operate correctly with HNAS.

              Under DATE, LLC5 call requests are processed by a
              CTCP.  If the CTCP is not active a Clear is sent
              in response to a Call Request packet.  Transpac
              has an option to retry calls that fail in this
              way.  The customer uses this retry logic to
              generate a new call that is routed to a different
              MCH with an operational CTCP.

   SOLUTION:  The customer's configuration includes a GATE CTCP
              that can be used to determine if the host PLU is
              available.

              When an LLC5 call is received the first GATE control
              session LU specified by the HNAS LUNAME= parameter
              will be tested for an active session.  If the LU is
              active, the LLC5 call will be accepted and PLU
              selection via LOGTAB processing will proceed.  If
              the LU is not active the call will be cleared with
              a clear diagnostic of X'FE' (254).  This will allow
              Transpac to retry the call.

 APPLY_INFO:  N/A - WILL BE PROVIDED TO USER AS REQUIRED. 

07-22-2004  - PROBLEM 2004198A

 PROBLEM_ID:  2004198A  (became APAR 2300059)
     STATUS:  CLOSED
  OPEN_DATE:  07-16-2004
REVISE_DATE:  07-22-2004
 CLOSE_DATE:  07-22-2004
 SERVICE(S):  GATE Fast Connect
  MANDATORY:  YES if OPTIONS=LCN0USED|RESIDSTART=value is required
 ORIGIN/REF:  CMF_230,230_CPT
    CP_TECH:  SFD/PWB
    PUBLISH:  YES, WIP
  PTF_CLASS:  TO-BE-DETERMINED
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004198a.ZIP file)
   COREQ(S):  TO-BE-DETERMINED
  PREREQ(S):  TO-BE-DETERMINED
 SUPERSEDES:  N/A|apar-id
  OBJECT(S):  N/A|members,
  SOURCE(S):  N/A|members,

    PROBLEM:  Configuration error messages can be generated for
              a GATE FC MCH when certain options are specified.

DESCRIPTION:  Error messages:

              NAS1311W REMOTE OPTIONS=LCN0USED REQUIRES SVC4=
                       RESOURCES, IGNORED

              is issued when an MCH is configured for GATE Fast
              Connect (FC) resources and OPTIONS=LCN0USED is also
              specified.

              07-22-2004 <begin>
              NAS1311W REMOTE OPTIONS=RESIDSTART REQUIRES SVC4=
                       RESOURCES, IGNORED

              is issued when an MCH is configured for GATE Fast
              Connect (FC) resources and OPTIONS=RESIDSTART=value
              is also specified.
              07-22-2004 <end>

              Additionally, the RESIDs generated for GATE FC data
              session LUs do not start at zero when LCN0USED is
              specified.

   SOLUTION:  HNAS has been modified to allow the OPTIONS=LCN0USED
              and OPTIONS=RESIDSTART=value for a GATE FC MCH.

 APPLY_INFO:  N/A - PROVIDED TO USER AS REQUIRED.

09-10-2004  - PROBLEM 2004196B

 PROBLEM_ID:  2004196B
     STATUS:  CLOSED (became APAR 2300070)
  OPEN_DATE:  07-14-2004  (carried over from 04-06-2004 activity)
REVISE_DATE:  07-21-2004
REVISE_DATE:  07-30-2004
REVISE_DATE:  08-09-2004
REVISE_DATE:  08-17-2004
REVISE_DATE:  08-18-2004
REVISE_DATE:  08-20-2004
REVISE_DATE:  08-22-2004
REVISE_DATE:  08-23-2004
REVISE_DATE:  09-01-2004
REVISE_DATE:  09-02-2004
REVISE_DATE:  09-03-2004
REVISE_DATE:  09-07-2004
 CLOSE_DATE:  09-10-2004
 SERVICE(S):  CART= and PFXWTO Support for NETVIEW
  MANDATORY:  NO (for NETVIEW/NCCF and session manager users)
 ORIGIN/REF:  230_RBS,FDK(RWG),NBG
              FDK(RWG) -
              RBS - Requires support (refresh) by 2004-09-20.
              NBG -
    CP_TECH:  SFD/CPT
    PUBLISH:  YES, WIP
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  TO-BE-DETERMINED
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004nnnb.ZIP file)
   COREQ(S):  TO-BE-DETERMINED
  PREREQ(S):  2300049, 2300026 and 2300006
 SUPERSEDES:  TO-BE-DETERMINED
  OBJECT(S):  NASCONS, NASUTIL
  SOURCE(S):  XFBLK

   ORIGINAL
    PROBLEM:  Output from HNAS modify command (issued via NETVIEW)
              is not routed back to NETVIEW.

DESCRIPTION:  APARs 2300026 and 2300006 were issued to institute
              various CART=token and 'PFXWTO options' capabilities
              to support NETVIEW and HNAS console and alert message
              output routing.

              Customer was provided with some trace options and
              NETVIEW ASSIGN commands for additional testing.

              To allow NETVIEW to filter on the NASNAME=value or
              'PFXWTO text' (text is user assigned name) you need
              to issue the following NETVIEW ASSIGN commands:

                For Console output: ASSIGN MSG=nasname,COPY=opername
                For Alarm messages: ASSIGN MSG=nasname,PRI=opername

              To activate these enhancements, the following parameters
              should be specified when HNAS is started:

                PARM='APFMEMSP=(229,230),USEMDFY,TRCCONS,TRCDBUG,
                      SHOWCONS,PFXWTO,PFXWTO CONS,TRCPRNT'

                Note: 'PFXWTO text-name' can be coded on the PARM=
                      list if a prefix name other than NASNAME=name
                      is used.

              07-20-2004 <begin>
              Customer advises that console output is now being
              routed.  HNAS and NETVIEW worked with success to a large
              extent.  HNAS messages and HNAS operator command output
              appeared on the NCCF screen and in the NETLOG, but
              not on the NETVIEW window (3270 full screen session).
              Customer is checking with IBM as to why it fails with
              the NETVIEW window.  The question is simply if an HNAS
              operator command can be passed thru a NETVIEW pipe.
              07-20-2004 <end>

              07-28-2004 <begin>
              Customer advises that PIPE command did not solve
              problem with NETVIEW 3270 full screen window, so we
              need to find out why.  What is the correct CART token?
              One member of their z/OS system automation group has
              suggested that HNAS would only need to flag its
              command output as command responses. The CART= value
              would be created by the MVS system since several
              NETVIEW operators can send an HNAS command at the same
              time and each one would get his output back based on
              CART=token.  This means that using the ALRMCART=
              operand for a generic CART= value for alarm messages
              will not work.  However, since alarm messages seem to
              be routed correctly using the NETVIEW ASSIGN command,
              the ALRMCART= operand is probably not required.  We
              are investigating whether issuing console command
              output WTOs as responses will make a difference.
              NETVIEW routing seems to work with existing WTO
              format for everything except the NETVIEW 3270 window.
              In the mean time, customer was advised to perform
              traces to determine CART= routing parameter using the
              following commands:

              TRCCONS TRCDBUG TRCSUBR TRCPRNT

              Awaiting results of this trace.
              07-28-2004 <end>

              08-09-2004 <begin>
              Traces show that CART= value in CIB is null when
              console command comes from NETVIEW terminal.  However,
              the console name is present.
              08-09-2004 <end>

              08-12-2004 <begin>
              Passing the console name via the WTO CONSNAME=
              parameter did not solve the problem.  Use of
              CONSID= parameter will now be tried.
              08-12-2004 <end>

              08-18-2004 <begin>
              MCSFLAG=(REG0) and CONSID= are mutually exclusive.
              This combination caused D23 (RC=10040007) ABEND.
              08-18-2004 <end>

              08-20-2004 <begin>
              CONSID= is still generating D23 (RC=10040007) ABEND.
              Thought is now that CONSID= may be mutually exclusive
              with CART= and/or MCSFLAG=(RESP).

              D23 occurred for the third time.  Also, missing branch
              after WTO call with CONSID= specified.

              The D23 ABEND may be occurring because the MF=L WTO
              Parmlist Extension (WPX) that is being produced for
              CART= is being rejected when the MF=E WTO is issued
              with CONSID=.  When CART= is specified on a MF=L WTO,
              a larger WPX is produced with the WPX Version Level
              (WPXVRSN) set to 2.  When CONSID= is specified on a
              MF=L WTO, a shorter WPX is produced with WPXVRSN=1.
              Although the WPXVRSN=2 WPX is large enough to handle
              CONSID= and CART=, it is possible that the WTO SVC
              (SVC35) does not like the WPXVRSN=2 with CONSID=.  The
              documentation for the D23 ABEND with RC=10040007 says
              'the error occurred during a validity check of a
              parameter list' (the 10 in RC=1004007).  The 07 at
              the end of the RC says 'the caller requested mutually
              exclusive functions'.  Unfortunately, this appears to be
              a kind of 'catchall' because it does not tell you which
              functions or parameters are mutually exclusive.  The
              hope is that WPXVRSN=2 is the conflicting value.
              08-20-2004 <end>

              08-22-2004 <begin>
              D23 ABEND resolved.  Believe WPXVRSN=1 solved problem.
              In prior tests with WPXVRSN=2, D23 ABEND occurs even
              though WPXCONS (X'40') was set in WPXMCSF1 by MF=E WTO
              which mad it unnecessary for CONSID= to be specified
              with CART= on MF=L WTO.  This leave WPXVRSN=2 as the
              suspected cause of the D23 ABEND (see solution note
              of 08-20-2004 below for background information).
              Although D23 ABEND has been corrected, WTO is still
              not being routed to NCCF console.  We now suspect that
              we need to add MCSFLAG=RESP to WTO (this specification
              was removed on 08-20-2004).
              08-22-2004 <end>

              08-23-2004 <begin>
              Adding MCSFLAG=RESP to the MF=L and MF=E WTO call has
              allowed console output to be routed to the originating
              (soliciting) console.  Next problem to be resolved is
              why output cannot also be PIPEd to NETVIEW.  Will be
              working on this over the next week or so.
              08-23-2004 <end>

              09-01-2004 <begin>
              Console response output is now being delivered to
              the requesting console but console prompt message
              is not.  It turns out that console prompt message
              a non-extended format WTO which prevents WTOPFX
              from propagating it into an extended form WTO to
              so that the CONSID= operand can be used when the
              PFXWTO prefix is inserted into the WTO.
              09-01-2004 <end>

              09-02-2004 <begin>
              ZAP to use CONSID=PCECNID when PCECART=0 and
              CART=PCECART when PCECART>0 allows console response
              output (including console prompt message) to be
              routed to soliciting console.  However, PIPE of
              console command does not result in response output
              getting back to soliciting console.
              09-02-2004 <end>

              09-03-2004 <begin>
              Forcing CONSID=PCECNID when PCECART=0 and
              CART=PCECART when PCECART>0 allows console response
              output (including console prompt message) to be
              routed to soliciting console.  However, PIPE of
              console command still does not result in response
              output getting back to soliciting console.
              09-03-2004 <end>

              09-07-2004 <begin>
              Forcing CONSID=PCECNNM with CART=PCECART when PCECART>0
              allows console response output to be routed back to the
              soliciting console regardless of whether PFXWTO CONS is
              in affect.

              On August 23, MCSFLAG=RESP was added to all MF=L form
              WTOs that are created when PFXWTO CONS is in affect.
              This was required so that the MF=E form WTO with
              CONSID=PCECNID could route console output back to the
              soliciting NCCF console.

              When PFXWTO CONS is not in affect, the MF=E form WTO
              uses CART=PCECART and CONSNAME=PCECNNM.

              Unlike extended MCS flags (set via CONSNAME= for
              example), base MCS flags (set va MCSFLAG=RESP for
              example) on a MF=L form WTO cannot be overridden
              on the MF=E form WTO.  When PFXWTO CONS is not in
              affect, no base MCS flags are set in the MF=L form
              WTO (null default is used).  When the MF=E form WTO
              with CART=PCECART and CONSNAME=PCECNNM is executed,
              it was observed that even though no base MCS flags
              are set, console output is returned to the soliciting
              NCCF console regardless of whether the command came
              via a MODIFY request or was PIPEd.  This says that
              MCSFLAG=RESP and CONSID=PCECNID are not required for
              the NCCF console and hence PFXWTO CONS is not required
              for any console routing.
              09-07-2004 <end>

   SOLUTION:  Pending debugging results.

              07-20-2004 <begin>
              IBM suggests that the customer should try the following:

              PIPE NETV HNAS command | COLOR RED | CONS

              This command sequence should cause the command response
              to the HNAS operator command will be displayed in RED
              on the NCCF screen.  If the command output does not
              appear in RED on the NCCF screen then HNAS commands are
              NOT 'pipeable' and cannot be seen in the window.
              07-20-2004 <end>

              07-28-2004 <begin>
              Awaiting trace results.
              07-28-2004 <end>

              08-09-2004 <begin>
              HNAS has been modified to pass the console name to
              the WTO service routine via the CONSNAME= parameter.
              08-09-2004 <end>

              08-12-2004 <begin>
              HNAS has been modified to pass the console ID to
              the WTO service routine via the CONSID= parameter.
              In addition, MCSFLAG=(REG0,RESP) and ROUTCDE=(2,8)
              have been added.  The REG0 value causes the WTO
              to be queued for the console identified by the
              CONSID= parameter.  The RESP value identifies the
              WTO as being a response to a console command.  The
              ROUTCDE= values of 2 identifies the WTO as master
              console information and 8 as teleprocessing control
              (8 was the only value previously specified).
              08-12-2004 <end>

              08-18-2004 <begin>
              REG0 keyword removed from MCSFLAG= operand on
              console WTO call.
              08-18-2004 <end>

              08-20-2004 <begin>
              HNAS NASUTIL module modified to issue WTO with CONSID=
              but no CART= if PCECNID>0 (from CIBXCNID field).  Also,
              MCSFLAG= parameter allowed to default.

              Corrected missing branch after WTO call with CONSID=
              specified.  Changed WTO230 logic in NASUTIL to issue
              MF=E WTO with CART=PCECART if WPXVRSN=2, otherwise, with
              CONSID=PCECNID.  Changed WTOPFX logic in NASUTIL to
              issue MF=L WTO with CART= for asynch flow (alert message)
              or when PCECNID=0 for synch flow (console message).
              The former causes a longer WPX (WTO parmlist extension)
              with WPXVRSN=2 to be produced for the CART= parameter.
              The latter causes a shorter WPX to be produced which
              is compatible with the CONSID= parameter.

              Note that CONSID= is used only when PFXWTO CONS is
              in affect.

              It may be that the WPXVRSN=2 value is not the cause
              of the D23 ABEND but rather the fact that CONSID= was
              not specified along with CART= on the original list
              form WTO.  The CONSID= parameter sets WPXCONS (X'40')
              in WPXMCSF1.  The WTO processor must check this flag
              in the MF=L WTO when the MF=E WTO is executed.  The
              change to the HNAS WTOPFX routine described above,
              while forcing WPXVRSN=1, also sets the WPXCONS flag
              so that one or both of these changes should satisfy
              WTO validity checking.  It may be worth going back and
              adding CONSID= with CART= to the original MF=L WTO in
              the WTOPFX routine and then repeating the test using
              the WPXVRSN=2 list form WTO.
              08-20-2004 <end>

              08-22-2004 <begin>
              Add MCSFLAG=RESP to MF=L and MF=E WTO with CONSID=
              parameter.
              08-22-2004 <end>

              09-01-2004 <begin>
              The WTOPFX routine has been modified to convert a
              non-extended format WTO console response into an
              extended format WTO console response so that the
              CONSID= operand can be used.  This will allow the
              console prompt message to be routed back to the
              requesting console.  Also provided ZAP to only
              use CONSID=PCECNID if PCECART=0 and CART=PCECART
              when PCECART>0.
              09-01-2004 <end>

              09-02-2004 <begin>
              The WTOPFX routine has been modified to unconditionally
              use CART=PCECART for asynch flow (alarm messages),
              CONSID=PCECNID,MCSFLAG=RESP for synch flow (console
              output) when PCECART=0 and CART=PCECART,MCSFLAG=RESP
              for synch flow when PCECART>0.  It is hoped that the
              latter will fix the PIPE command problem.
              09-02-2004 <end>

              09-03-2004 <begin>
              The WTOPFX routine has been modified to include
              CONSNAME=PCECNNM with CART=PCECART,MCSFLAG=RESP
              for synch flow (console output) when PCECART>0.
              When PCECART=0, CONSID=PCECNID,MCSFLAG=RESP will
              still be used.
              09-03-2004 <end>

 APPLY_INFO:  N/A - WILL BE PROVIDED TO USER AS REQUIRED. 

2006-01-18  - PROBLEM 2004196A

 PROBLEM_ID:  2004196A
     STATUS:  CLOSED, available in 240
  OPEN_DATE:  2004-07-14
REVISE_DATE:  2004-mm-dd
 CLOSE_DATE:  2006-01-18
 SERVICE(S):  CONSOLE - PING XOT Enhancement
  MANDATORY:  N/A
 ORIGIN/REF:  230_NBG
    CP_TECH:  SFD/CPT
    PUBLISH:  YES, WIP
  PTF_CLASS:  240 Base Code
   PTF_TYPE:  N/A

    PROBLEM:  PING XOT doesn't allow operator to specify the
              XOT Call Request packet CUD= (call user data) or
              FAC= Facilities values.

DESCRIPTION:  Customer uses HNAS PING XOT command to query remote
              X.25 Network and Pad environments for monitoring.
              They require the ability to select various FAC= and
              CUD= values based upon the destination network.

              Please refer to the PING XOT command description in
              the Console Subsystem Operation Guide for additional
              information.

   SOLUTION:  Provide logic that will allow user to override the
              default CUD= and FAC= values via PING subparameters.

              In 240 'PING dmy-name' support will allow users to 
              specify all static XOT ping subparameters in the CDF
              so that user can simply ping the dmy-name REMOTE,
              TYPE=DMY for the desired result.  All ping XOT call
              request values as well as the ipaddr/port values can
              now be provided on the dmy-name remotes providing 
              the user with complete control over the various
              parameters.

 APPLY_INFO:  N/A 

07-14-2004  - PROBLEM 2004194A

 PROBLEM_ID:  2004194A
     STATUS:  Closed, APAR 2300055 issued.
  OPEN_DATE:  07-12-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  07-14-2004
 SERVICE(S):  QLLC
  MANDATORY:  N/A
 ORIGIN/REF:  230_NBG
    CP_TECH:  PRT
    PUBLISH:  YES
  PTF_CLASS:  Standard APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  XOTBXM2
  SOURCE(S):  N/A

    PROBLEM:  Inbound call request from RJE station fails with
              SENSE=08350027 (connect error with pointer).

              The remote is rejecting the BIND from HNAS.

DESCRIPTION:  The remote RJE station starts a session with INIT-SELF.
              This PIU contains the PLU name and a password.  No URC
              (User Request Correlation) is present.  A REQSESS is
              sent to the PLU and a BIND results.  The BIND PIU is
              rejected by the remote with 08350027 sense.

   SOLUTION:  The BIND sent by HNAS ends with the PLU name field.
              This field may be followed by user data, URC data an
              an SLU name.  HNAS does not send these fields.

              ZAP that extends the BIND with 3 bytes of zeroes
              (indicating that user data, URC data and the SLU name
              are not present) fixed the problem.

 APPLY_INFO:  N/A - ZAP provided to user encountering the problem.

07-08-2004  - PROBLEM 2004181A

 PROBLEM_ID:  2004181A
     STATUS:  CLOSED (APAR 2300054 issued for item 1 and 2)
              CLOSED, see circumvention for item 3 issue.
  OPEN_DATE:  06-29-2004
 CLOSE_DATE:  07-08-2004
 SERVICE(S):  All (PLU session establishment) Diagnostics
  MANDATORY:  N/A
 ORIGIN/REF:  230_POR
    CP_TECH:  PWB
    PUBLISH:  YES
  PTF_CLASS:  APAR issued for Item 1 and 2.
              See Circumvention for Item 3 for QLLC portion.
   PTF_TYPE:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  Diagnosis is difficult when the PLU rejects a REQSESS
              from HNAS.  The only notification is the following:

              NAS3799I LU lu-name  ENDING   SESSION ON MCH mch-name
              HNAS CAUSE/DIAG=000/145 (00/91) DIAGX=0000

              In a QLLC environment the above message is issued every
              10 seconds.

DESCRIPTION:  The 145 (X'91') diagnostic value indicates that HNAS
              received a NOTIFY or CLEANUP PIU from VTAM indicating
              that the session is over.

              NOTIFY is used when session setup fails (HNAS gets
              +RSP to it's REQSESS then session is rejected (BIND
              not forthcoming).

              CLEANUP is used when a session is terminated after
              setup completes (e.g. PLU ABEND in mid session).

   SOLUTION:  1) A new message NAS3703W is issued when a NOTIFY is
                 received for an LU:

                 NAS3703W mch-nm VC addr lu-nm LU addr RECEIVED 
                 NOTIFY CODE=aabbcc00 SENSE=ssssssss
                    aa = control vector type (X'03' expected)
                    bb = status 00 = OLU & DLU SSCPs not connected.
                                01 = session terminated
                                02 = session setup received
                                03 = procedure error
                    cc = xxxxxxxx    BIT values
                         ||||||||___ reserved
                         |||||||____ 1 = session rejected at SSCP
                         ||||||_____ reserved
                         |||||______ 0 = setup procedure error
                         ||||        1 = takedown procedure error
                         ||||_______ 1 = setup rejected at SLU
                         |||________ 1 = setup rejected at PLU
                         ||_________ 1 = error sending BIND to SLU
                         |__________ 1 = error sending CINIT to PLU

                    ssssssss = sense data from PLU or VTAM.

              2) A new message NAS3704W is issued when a CLEANUP is
                 received for an LU:

                 NAS3704W mch-nm VC addr lu-nm LU 0013E3D0 RECEIVED 
                 CLEANUP CODE=aa00000
                    aa= xxxxxxxx Reason Bits
                        ||_________ 1 = Network Manager
                        |__________ 1 = Abnormal

                        For remaining bits see SNA Format & Protocol.

CIRCUMVENTION:
 
               3) For QLLC resources the REQSESS failure causes HNAS
                  to issue a DACTLU followed by a 10 second time
                  delay before a new start sequence (ACTLU, REQSESS).

                  If the PLU is not configured for a resource it may
                  reject the REQSESS and the connect sequence will
                  loop.

                  There are two solutions:

                  A) Correct the PLU's definitions so the the session
                     can start.

                  B) If the resource is a type that is acquired when
                     it is needed (e.g. a printer) then code ACQUIRE
                     in the APPLNAME= operand and point the SLU at
                     the ACQUIRE using the appl_index_i operand.

                     Example:
                      PU01 REMOTE TYPE=SPU,IDBLK=xxx,IDNUM=yyyyy
                                  APPLNAME=(ACQUIRE,TSO)
                                  LUNAME=(,SLU1///1,
                                           SLU2///0)

                     When PU01 activates a REQSESS (for TSO) will be
                     issued for SLU1.  SLU2 will wait to be acquired
                     by  a PLU.

 APPLY_INFO:  N/A   

11-24-2004  - PROBLEM 2004180A

 PROBLEM_ID:  2004180A
     STATUS:  CLOSED
  OPEN_DATE:  06-28-2004
REVISE_DATE:  11-23-2004 (SWD added to ORIGIN_REF)
REVISE_DATE:  11-24-2004 (confirmation from IZB that problem has
              not re-occurred since upgrading to HNAS 2300078
              which was installed on Oct. 7, 2004)
 CLOSE_DATE:  11-24-2004
 SERVICE(S):  QLLC CALLOUT FAILURE ALERT-MESSAGE
  MANDATORY:  NO, RECOMMENDED
 ORIGIN/REF:  230_IZB/230_SWD  (2300045)
    CP_TECH:  SFD
    PUBLISH:  YES, PROBLEMLOG
  PTF_CLASS:  N/A
   PTF_TYPE:  N/A

    PROBLEM:  NAS7717W callout failure message is not being logged
              on SYSCONS or in SYSPRINT.

DESCRIPTION:  When QLLC callout fails, indication of why is not
              displayed.

   SOLUTION:  Installation of new HNAS distribution at the 2300078
              level has eliminated this problem.  The following
              messages will be displayed when a QLLC callout fails:

              NAS7717W LU sluname CALL TO DTE ADDR dteaddr VIA REMOTE
                          rmtname FAILED
              NAS7717W CAUSE/DIAG=ddd/ddd (xx/xx) DIAGX=xxxx

CIRCUMVENTION: See SOLUTION.

 APPLY_INFO:  N/A - PROVIDED TO USER AS REQUIRED.  

07-20-2004  - PROBLEM 2004170A

 PROBLEM_ID:  2004170A
     STATUS:  CLOSED,  APAR 2300056 issued.
  OPEN_DATE:  06-18-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  07-06-2004
 SERVICE(S):  MLCL (RTEIN/RTEOUT) console command enhancement
  MANDATORY:  N/A
 ORIGIN/REF:  230_NBG
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004170A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  APAR 2300045
              (and associated APARs PREREQ chains)
 SUPERSEDES:  N/A
  OBJECT(S):  CONSHELP, CONSMLCL, NASCNFG
  SOURCE(S):  XFCNFGWA

    PROBLEM:  Unable to insert new entries in the LOCAL RTEIN= and
(ENHANCEMENT) RTEOUT= operand lists.

DESCRIPTION:  Currently, if a new entry is added to the RTEIN= or
              RTEOUT= operand, it can only be added to the end of
              each operand's list.  If the associated DTE address
              is a superset of a previous entry, the new entry will
              never be used.  For example, assume the following
              RTEIN= operand list:

              RTEIN=(ABCD/47113456,
                     EFGH/23456,
                     IJKL/345689)

              When MLCL RTEIN=XYZA/2345678 is entered, the RTEIN=
              operand list will look as follows:

              RTEIN=(ABCD/47113456,
                     EFGH/23456,
                     IJKL/345689,
                     XYZA/2345678)

              Because DTE address 23456 occurs earlier in the
              RTEIN= list (for MCH EFGH), the new entry for MCH
              XYZA will not be accessed.

   SOLUTION:  The MLCL command has been modified so that a new
              entry can be inserted at a specific position in the
              RTEIN= and RTEOUT= operand lists.  In this way the
              the entry will be tested before the old entry that
              has a subset of the new DTE address.  Using the
              example above, to insert XYZA/2345678 as the second
              entry in the RTEIN= operand list, prefix the MCH
              name (XYZA) with a decimal entry number value as
              follows:

              MLCL RTEIN=2,XYZA/2345678      <- comma before XYZA
                                                is optional

              This command changes the RTEIN= operand list to look
              as follows:

              RTEIN=(ABCD/47113456,
                     XYZA/2345678,
                     EFGH/23456,
                     IJKL/345689)

              Note also that logic has been added that allows you
              to delete an entire entry, not just its DTE address.
              To remove the entry for MCH EFGH in the RTEIN= list
              above, enter the following command:

              MLCL RTEIN=3,*                 <- comma before * is
                                                optional

              This command changes the RTEIN= operand list to look
              as follows:

              RTEIN=(ABCD/47113456,
                     XYZA/2345678,
                     IJKL/345689)

              The following description is now produced when HELP
              MLCL or MLCL ? is entered:

DESCRIPTION (* => PRIVILEGED)
MODIFY LOCAL CONFIGURATION PARAMETERS
ENTER> LNM=lclname MLCL {INIT={ACTIVE|IDLE},
                         DELAYTIME=min,
                         RETRYLMT=cnt}
                        {OPTIONS={BALANCERTEOUT|NOBALANCERTEOUT}}
                        {RTEIN={entnum}mchname{-refnum}/dd...dd}
                        {RTEOUT={entnum}rmtname{-refnum}/dd...dd
                                ||{S|T}

NOTE: enter entnum as the position of an entry to be inserted or
                   deleted
            refnum as the position of an entry relative to like
                   named entries
                 * for mchname|rmtname to delete entry when entnum
                   is given to
                 * for dd...dd to delete DTE address for a selected
                   entry

NOTE: entnum and refnum, if entered, are relative to one

 APPLY_INFO:  N/A - Provided to user encountering the problem.
              This problem FIX is applied like an APAR. 

06-22-2004  - PROBLEM 2004167A

 PROBLEM_ID:  2004167A
     STATUS:  CLOSED, APAR 2300047 issued.
  OPEN_DATE:  06-15-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  06-22-2004
 SERVICE(S):  TRCTRAP console command enhancement
  MANDATORY:  NO (recommended enhancement)
 ORIGIN/REF:  230_CPT
    CP_TECH:  SFD
    PUBLISH:  YES, Overview

    PROBLEM:  Trace trapping logic doesn't generate an alert message
(ENHANCEMENT) when trace trapping is enabled via the TRCTRAP console
              command.  

              Additional information will be provided as available.

 11-15-2004  - PROBLEM 2004162B - became APAR 2300083

 PROBLEM_ID:  2004162B
     STATUS:  CLOSED
  OPEN_DATE:  06-10-2004
REVISE_DATE:  08-08-2004
REVISE_DATE:  10-15-2004
REVISE_DATE:  11-08-2004 (example changed)
 CLOSE_DATE:  11-10-2004
 SERVICE(S):  PCNE/PAD Configuration Enhancement
  MANDATORY:  N/A
 ORIGIN/REF:  230_AMA
              230_ITL also interested in this support - Feb 2005.
              230_RWE possibly later this year.
              230_SDD interested.
              230_AMI interested - 2004-11-02 test planned
              230_ITL 2004-11-05 test planned
              230_AMI will test ASAP.
    CP_TECH:  SFD
    PUBLISH:  YES, WIP
  PTF_CLASS:  ENHANCEMENT APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the P04162B.zip file)
   COREQ(S):  N/A
  PREREQ(S):  APARs 2300064, 2300061, 2300060, 2300057, 2300037,
                    2300035, 2300018 and their associated pre-reqs.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGSVC0, CNFGSVC3, CNFGSVC5, CONSDRMT, CONSMRMT,
              MCHHRQ, MCHNRQC, MCHSVCI, NASCNFG, VCCLRQ, VCDAT,
              XOTBXM
  SOURCE(S):  VTMUT1, XFNASWA

    PROBLEM:  The SVC0= and SVC5= operands allow you to specify SLUs
(ENHANCEMENT) as callin (I) or callout (O) but not twoway (T).

DESCRIPTION:  See problem/solution.

   SOLUTION:  The SVC0= and SVC5= operand logic has been modified
              to accept a T value (for twoway) following the DTE
              address so that the same SLU can be used for callin
              and callout connections.  When a T is detected, the
              ACB for the SLU is opened so that it can be acquired
              (bound).  If an inbound call arrives before the SLU
              is bound and the calling DTE address matches one of
              the called DTE addresses associated with the SLU
              (there can be up to 3 DTE addresses specified for the
              SLU), the SLU will be allocated to the inbound VC.
              If a BIND arrives prior to an inbound call, the SLU
              will be processed in the same fashion as an SLU
              defined with the 'O' (for callout) option.

              08-08-2004 <begin>
              Configuration, console and run time changes for this
              modification have been pre-tested in the Comm-Pro lab
              but stress testing will be done at customer site.
              08-08-2004 <end>

              10-15-2004 <begin>
              Configuration description for twoway mixed DTE address
              and Xidnum specification.  Up to 3 DTE addresses and/or
              Xidnum values can be specified for a twoway SLU.   Run
              time logic will match the inbound calling DTE address to
              DTE addresses in an SVC0/5 entry as well as any Xidnum
              values in an entry from the CUD field of the Call Request
              packet.  A 'hit' on a matching DTE address or Xidnum
              value will allocate the SLU to the inbound connection
              if it is not already allocated.  If the SLU is acquired
              (bound) before any inbound Call Request is received, the
              DTE addresses in the list will be used (successively)
              for outbound call attempts.  Any Xidnum values in the
              list will be skipped.

              Example:

              SVC0=(vclmt,
                    :
                    slunm/dteaddr1-Xidnum1-dteaddr2T01/mxtnm/cud,
                    |     |        |       |       ||  |     |
                    |     |        |       |       ||  |     |<-CUD
                    |     |        |       |       ||  |        for OT
                    |     |        |       |       ||  |        call
                    |     |        |       |       ||  |
                    |     |        |       |       ||  |<-MXT name
                    |     |        |       |       ||
                    |     |        |       |       ||<-APPLNAME index
                    |     |        |       |       |
                    |     |        |       |       |<- IT/OT SLU flag
                    |     |        |       |
                    |     |        |       |<- 2nd callin/callout DTE
                    |     |        |
                    |     |        |<- callin Xidnum
                    |     |
                    |     |<- 1st callin/callout DTE
                    |
                    |<- twoway SLU name
                    :
              10-15-2004 <end>


              11-08-2004 <begin>

              Sample: SVC0=(2,
                            SLU1/12345-12346-12347T//C0000000,
                            SLU2/23456-23457-X034560T//C0000000)
              11-08-2004 <end>

 APPLY_INFO:  N/A - Provided to user encountering the problem.
              This problem FIX is applied like an APAR.

09-08-2004  - PROBLEM 2004162A

 PROBLEM_ID:  2004162A
     STATUS:  CLOSED,Not-Tested/Implemented - 
              User decided not to employ usermod.
  OPEN_DATE:  06-10-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  08-26-2004
 SERVICE(S):  PCNE/PAD Configuration Enhancement
  MANDATORY:  N/A
 ORIGIN/REF:  230_AMA
    CP_TECH:  SFD
    PUBLISH:  YES
  PTF_CLASS:  CUSTOM-USER-MOD
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004162A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  NASCNFG
  SOURCE(S):  XFNASWA

    PROBLEM:  The SVC0= and SVC5= operands are limited to 511 SLU
(ENHANCEMENT) entries.

DESCRIPTION:  See problem/solution.

   SOLUTION:  The SVC0= and SVC5= operand arrays (SLUs) have been
              increased from 511 to 1023 entries so that a larger
              number of PCNE/PAD SLUs can be defined per MCH.

 APPLY_INFO:  N/A - Provided to user encountering the problem.
              This problem FIX is applied like an APAR.

07-06-2004  - PROBLEM 2004161B

 PROBLEM_ID:  2004161B
     STATUS:  CLOSED, APAR 2300052 issued.
  OPEN_DATE:  06-09-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  07-06-2004
 SERVICE(S):  GATE_CALLOUT  (PFXDCEADDR)
  MANDATORY:  NO, ENHANCEMENT
 ORIGIN/REF:  230_BNP
    CP_TECH:  PWB/SFD
    PUBLISH:  YES, WIP
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004nnnB.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGDCAD, CNFGOPTS, CONSDRMT, CONSHELP, CONSMRMT,
              NASCNFG, XOTUT1
  SOURCE(S):  XFNASWA

    PROBLEM:  Users unable to employ REPDCEADDR features for GATE
              callout sessions when GATE calling address contains
              subaddress only digits for application routing.

DESCRIPTION:  The REPDCEADDR feature was initially designed to
              associate GATE callout sessions (via the calling
              address) with routers (via the RTEOUT=values) and
              interfaces (via x25 route, substitution filtering)
              for proper application to router interface mapping.
              REPDCEADDR logic will only replace the GATE calling
              address when the CTCP's call request packet has no
              calling address field (calling address length = 0).

              Some GATE callout applications require that the
              subaddress digits in the calling address portion
              of the CTCP's  call request packet be prefixed
              with the DCEADDR= digits in the HNAS CDF.

   SOLUTION:  A new parameter is currently under development
              which will prefix the GATE CTCP's calling address
              field with the HNAS DCEADDR= calling address.

              PFXDCEADDR -
              This new option will cause HNAS to insert the
              DCEADDR=value in front of the calling address
              supplied in a GATE CTCP's call request packet.

              If the generated calling address is longer than
              15 digits then a clear diag=147 is returned to
              the CTCP.

              If there is no calling address in the CTCP's
              call request packet then the calling address
              will be the DCEADDR.

              REPDCEADDR -
              This existing option will continue to only
              insert the HNAS DCEADDR=values into the GATE
              calling address filed when no digits are
              provided (calling address length of zero).

 APPLY_INFO:  N/A - Will be provided as an APAR.

07-15-2004  - PROBLEM 2004161A

 PROBLEM_ID:  2004161A
     STATUS:  Closed - problem went away (see 06-14-2004 Revision)
  OPEN_DATE:  06-09-2004
REVISE_DATE:  06-14-2004
 CLOSE_DATE:  07-15-2004
 SERVICE(S):  QLLC
  MANDATORY:  N/A
 ORIGIN/REF:  220_CET (2110020)
    CP_TECH:  PWB
    PUBLISH:  YES
   PTF_TYPE:  N/A, Non-APAR
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004nnna.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  MCHRL3RR
  SOURCE(S):  N/A

    PROBLEM:  CFT file transfer using IND$FILE fails.
              Following messages present:

              NAS7601W MCH GM3270   LU LTGPROL1 DECODE RC=04
                       TH/RH=28000102 005D0090 004F4455 49545F50

              NAS7601W MCH GM3270   LU LTGPROL1 DECODE RC=0C
                       TH/RH=2C000102 005E0090 00647569 742C2043

              BEGIN <06-14-2004>
              Traces of the failing LU were requested.  Before
              running the trace customer noticed that a remote
              was setting up a session that failed every 5 
              seconds.  This configuration error was fixed and
              the problem went away.  A custom version of 
              MCHRL3RR was developed to clear the call when 
              any decode error (except sequence error) occurs.
              This was never sent.  We may want to reconsider
              this change for a later release.
              END   <06-14-2004>

DESCRIPTION:  There are two problems:

              1) An incomplete message was delivered to the
                 QLLC request/response processor.
                 This leads to NAS7601W RC=04 (invalid TH mapping).

              2) The request/response processor discards messages
                 with the invalid TH mapping error.  A stronger
                 reaction is required.

                 As a result of the discarded PIU, subsequent input
                 is out of sequence.  This leads to the
                 NAS7601W RC=0C (sequence error) message.

                 HNAS returns negative responses to out of sequence
                 PIUs.  Here too, a stronger response may be needed.

   SOLUTION:  1) When a PIU decode error occurs HNAS will terminate
                 it's session with the PLU and send a DACTLU to
                 the remote device.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A 

06-07-2004 - PROBLEM 2004159N

 PROBLEM_ID:  2004159N
     STATUS:  CLOSED
NOTICE_DATE:  06-07-2004
 SERVICE(S):  PROBLEM LOG CHANGE NOTICE
  MANDATORY:  N/A
 ORIGIN/REF:  CPT
   PTF_TYPE:  N/A

       NOTE:  All 'STATUS: CLOSED' problem log entries replaced by
              APARs are now located in the HNAS Problem Summary
              History file instead of the standard HNAS Problem 
              Summary file.

07-21-2004  - PROBLEM 2004154A

 PROBLEM_ID:  2004154A
     STATUS:  CLOSED, APAR 2300057 issued.
  OPEN_DATE:  06-02-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  07-21-2004  (tested in-house)
 SERVICE(S):  QLLC Configuration Enhancement
  MANDATORY:  N/A
 ORIGIN/REF:  230_AMA
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004154A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGSVC3, CONSDRMT
  SOURCE(S):  N/A

    PROBLEM:  SVC3=1 is required when MCH supports QLLC resources
(ENHANCEMENT) even when SPU allocation is exclusively by IDBLK/IDNUM
              and not DTE address.

DESCRIPTION:  A vclmt value is required in the SVC3= operand (first
              suboperand) even if no SPU names are also provided.
              The MCH will not allow QLLC connections unless an LLC3
              vclmt value is given.  This can be confusing when SPU
              allocation is done using IDBLK/IDNUM match only.  Any
              MCH defined for QLLC support can access any SPU in the
              CDF.

   SOLUTION:  Rather than requiring that SVC3=1 be specified to mark
              the MCH for QLLC support, SVC3=ALLOW will now be
              accepted.  This new keyword indicates that the MCH
              allows any number of QLLC connections.

 APPLY_INFO:  N/A - Provided to user encountering the problem.
              This problem FIX is applied like an APAR. 

06-02-2004 - PROBLEM 2004149A

  PROBLEM_ID: 2004149A
      STATUS: CLOSED, APAR 2300042 issued.
   OPEN_DATE: 05-28-2004
 REVISE_DATE: 06-02-2004
  CLOSE_DATE: 06-02-2004
  SERVICE(S): TCPIP
   MANDATORY: N/A
  ORIGIN/REF: 230_BNP
    PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
     PTF_LOC: N/A
    COREQ(S): N/A
   PREREQ(S): N/A
  SUPERSEDES: N/A
   OBJECT(S): NASUTIL
   SOURCE(S): NASMAIN and NASTCP

     PROBLEM: HNAS terminates abnormally when TCPIP stack is
              stopped.

              06-02-2004 <begin>
              HNAS does not always process TCPIP stack sever
              properly.
              06-02-2004 <end>

DESCRIPTION: HNAS ends abnormally when the stack is stopped even
             though it is supposed to survive this event.

             06-02-2004 <begin>
             If the TCPIP stack is stopped while HNAS is still
             running, an unsolicited interrupt is presented to
             HNAS indicating that the connection to the stack
             has been severed.

             When the SVRSTRT option is in affect, HNAS is
             supposed to recover from the sever condition.

             When the SVRSTRT option is not in affect, HNAS is
             supposed to automatically shut down when the sever
             condition is detected.

             In some cases, HNAS behavior can be unpredictable
             when a sever occurs.

             Because of logic introduced with multiple stack
             support, shutting HNAS down when a sever occurs is
             wrong if HNAS is connected to another stack that
             is still operational.  In this case, HNAS must
             continue running regardless of the SVRSTRT option.

             Existing logic causes HNAS to remain running after
             a sever occurs if the SVRSTRT option is active but
             sever cleanup processing erroneously releases all
             VC and LU memory.  The result is that HNAS still
             runs but cannot process new connections.
             06-02-2004 <end>

   SOLUTION: Current analyzing problem.  Solution not yet
             available.

             06-02-2004 <begin>
             HNAS TCPIP sever logic has been modified to prevent
             HNAS from stopping (shutting down) when a stack is
             is stopped if multiple stacks are defined (multiple
             LOCAL definitions with different TCPNAME= operand
             values) regardless of the SVRSTRT option.  In
             addition, VC and LU resources will only be released
             when HNAS is shut down.  When the SVRSTRT is not
             active, HNAS will automatically shut down only when
             all LOCAL and REMOTE connections to all stacks are
             closed or severed.
             06-02-2004 <end>

 APPLY_INFO: N/A - Provided to user encountering the problem.
             This problem FIX is applied like an APAR. 

06-02-2004 - PROBLEM 2004148A

 PROBLEM_ID: 2004148A
     STATUS: CLOSED, APAR 2300041 issued.
  OPEN_DATE: 05-27-2004
REVISE_DATE: 05-30-2004
 CLOSE_DATE: 06-02-2004
 SERVICE(S): QLLC
  MANDATORY: N/A
 ORIGIN/REF: 230_IZB
   PTF_TYPE: (OBJ)
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
 SUPERSEDES: N/A
  OBJECT(S): XOTBXM2, MCHRL3RR
  SOURCE(S): N/A

    PROBLEM: QLLC SLU sending PIUs to HNAS.  HNAS sends a pacing
             response, SLU responds with TERM-SELF.  The QLLC
             session ends.

DESCRIPTION: An HNAS logic error causes an IPR (Isolated Pacing
             Response) to be sent with the expedited flow bit set
             in the PIU's TH.  This violates SNA rules.

             <beg 05-30-2004>
             SLU continues to respond TERM-SELF to HNAS IPR.  Bind
             image contains an SLU send limit.  SLU does not send
             PI (pacing indicator) in any request sent to HNAS.
             We believe the SLU is using the lack of PI to turn
             off SLU to PLU send pacing logic.
             <end 05-30-2004>


   SOLUTION: HNAS modified to not set the TH expedited flow bit in
             an IPR.

             <beg 05-30-2004>
             HNAS modified to ignore SLU send pacing logic if no
             request with a PI has been received by HNAS.
             This added MCHRL3RR to the OBJECT(S) list.
             <end 05-30-2004>

 APPLY_INFO: N/A - Provided to user encountering the problem.
             This problem FIX is applied like an APAR.

05-19-2004  - PROBLEM 2004140N

 PROBLEM_ID:  2004140N
     STATUS:  CLOSED
NOTICE_DATE:  05-19-2004
 SERVICE(S):  PROBLEM LOG CHANGE NOTICE
  MANDATORY:  N/A
 ORIGIN/REF:  CPT
   PTF_TYPE:  N/A

       NOTE:  The HNAS Problem Summary Matrix table heading/field
              was changed from PTF_TYPE to ORIGIN/REF to provide
              quick viewing of problem origin activity.  PTF_TYPE
              will continue to be provided in the individual 
              problem log entries as required.  

05-26-2004 - PROBLEM 2004140A

 PROBLEM_ID: 2004140A
     STATUS: CLOSED, APAR 2300038 issued.
  OPEN_DATE: 05-19-2004
 CLOSE_DATE: 05-26-2004
 SERVICE(S): QLLC SUPPORT
  MANDATORY: YES
 ORIGIN/REF: 230_IZB
   PTF_TYPE: (OBJ) HNASOBJX
    PTF_LOC: FTP Server Directory /hnas_maint/hnasproblem/
             (Complete FIX is contained in the 2004140A.ZIP file)
   COREQ(S): N/A
  PREREQ(S): APAR 2300031 and 2300036
  OBJECT(S): MCHRL3RR and QLSSCP
  SOURCE(S): N/A

    PROBLEM: 1) APPLNAME=ACQUIRE is treated as a PLU name by
                UNBIND processor.

             2) 0198 ABEND (NASHALT - IN VTMLUFM : LU DIRTY) can
                occur after LU is UNBOUND.

DESCRIPTION: 1) The UNBIND processor fails to recognize ACQUIRE as
                a reserved keyword and uses it as a PLU name in a
                REQSESS request if the SLU in the LUNAME= operand
                has an associated applid.  The REQSESS is rejected
                by VTAM which causes the LU's ACB to be closed, a
                DACTLU to be transmitted and a delay imposed before
                an ACTLU is transmitted.  The delay timeout routine
                calls the LU format routine (VTMLUFM) before
                scheduling the ACTLU transfer.  This leads to the
                problem 2.

             2) If a PIU is received after an LU is unbound and
                before it is bound again via REQSESS solicitation,
                the PIU is enqueued for host transfer on the LU
                input queue (LUIQ).  A PIU may be received after an
                UNBIND has been transmitted if the UNBIND has not
                actually reached the remote LU (like trains passing
                in the night).  If a REQSESS fails, the sequence
                described in problem 1 occurs.  Because LUIQ is
                non-empty when the VTMLUFM routine receives control,
                it ABENDs because it 'knows' that LUIQ should be
                empty.

   SOLUTION: 1) The UNBIND processor has been modified to test for
                APPLNAME=ACQUIRE when an applid is present.  If
                ACQUIRE is specified, the LU's ACB is opened and a
                SETLOGON request is passed to VTAM.  This conditions
                the LU to wait for and accept a new BIND.

             2) The QLLC input processor has been modified to test
                the LU state for BIND/BIND-PENDING before enqueing
                any PIU to the LU input queue.  In LU IDLE state
                or REQSESS-PENDING state, no PIUs are expected from
                the remote LU.  Any residual PIUs that are received
                in the IDLE/REQSESS-PENDING states are discarded.

 APPLY_INFO:  This problem FIX is applied like an APAR.

              See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance.

              Corrective logic included in distributions created
              after CLOSE_DATE.  Otherwise, apply maintenance as
              directed in the APPLY_INFO (PTF).   

05-19-2004  - PROBLEM 2004138A

 PROBLEM_ID: 2004138A
     STATUS: CLOSED, APAR 2300036 issued.
  OPEN_DATE: 05-17-2004
 CLOSE_DATE: 05-19-2004
 SERVICE(S): QLLC CALLOUT SUPPORT
  MANDATORY: YES
 ORIGIN/REF: 230_IZB
   PTF_TYPE: (OBJ) HNASOBJX
    PTF_LOC: FTP Server Directory /hnas_maint/hnasproblem/
             (Complete FIX is contained in the 2004138A.ZIP file)
   COREQ(S): N/A
  PREREQ(S): APAR 2300031
  OBJECT(S): QLSSCP and VCUT1
  SOURCE(S): N/A

    PROBLEM: When a BIND initiated (OPTIONS=CLOTINITYP=BIND) Call
             Request fails (Clear received), a subsequent BIND will
             not initiate another Call Request.

DESCRIPTION: When a Clear is received as a response to a QLLC Call
             Request, the VCVCRL routine is called to release the VC.
             As part of the clear processing, the ACBs for the SLUs
             on the SPU associated with the VC are closed but the VC
             control block remembrance (LUVC) is not reset.  When a
             subsequent BIND is received, the BIND is queued rather
             than initiating another Call Request because the LUVC
             filed is non-zero.  The result is that the SLU session
             is hung.  When displayed from VTAM, the SLU state will
             be PSEST.  A VTAM INACT/ACT command does not fix the
             problem.

   SOLUTION: The callout initiator has been modified to set LUVC=0
             when a Clear is received as a response to a Call
             Request.  This will permit a subsequent BIND to
             initiate a new call.

 APPLY_INFO: This problem FIX is applied like an APAR.

             See Chapter 6 (Product Maintenance Installation
             section) from the HNAS Guide and Reference Manual
             for instructions on how to install PTF's (Object,
             Source and ZAPs) or Refresh/Upgrade maintenance.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in the APPLY_INFO (PTF).  

05-13-2004  - PROBLEM 2004133A

 PROBLEM_ID: 2004133A
     STATUS: CLOSED, APAR 2300034 issued.
  OPEN_DATE: 05-12-2004
 CLOSE_DATE: 05-13-2004
 SERVICE(S): QLLC SUPPORT
  MANDATORY: N/A
 ORIGIN/REF: 230_IZB
   PTF_TYPE: N/A
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): XOTBXM2
  SOURCE(S): N/A

    PROBLEM: QLLC session can hang.  Requests the PLU are not
             not sent to the SLU because HNAS (incorrectly) thinks
             a pacing response is owed.  This problem occurs when
             a non-FMD request (e.g. BID) closes the HNAS send
             window after a pace response is received in the middle
             of the window.

DESCRIPTION: See problem.

   SOLUTION: HNAS modified to properly process it's send pacing
             window.

 APPLY_INFO: N/A  

05-12-2004 - PROBLEM 2004127B

 PROBLEM_ID: 2004127B
     STATUS: CLOSED, APAR 2300031 issued.
  OPEN_DATE: 05-06-2004
 CLOSE_DATE: 05-12-2004
 SERVICE(S): QLLC CALLOUT SUPPORT
  MANDATORY: YES
 ORIGIN/REF: 230_IZB
   PTF_TYPE: (OBJ) HNASOBJX
    PTF_LOC: FTP Server Directory /hnas_maint/hnasproblem/
             (Complete FIX is contained in the 2004127B.ZIP file)
   COREQ(S): PROBLEM 2004112A
  PREREQ(S): N/A
  OBJECT(S): MCHBFR and QLSSCP
  SOURCE(S): N/A

    PROBLEM: 0198 ABEND (NASHALT) can occur when QLLC callout
             is BIND initiated (OPTIONS=CLOTINITYP=BIND).

DESCRIPTION: NASHALT can occur if OPTIONS=CLOTINITYP=BIND is
             specified when an ACTLU response is received for an
             SLU that is in BIND pending state (LUBST1=LUBSTBN).
             Problem occurs because the BIND remembrance field
             (LUSVFREQ=LURQBIND) is only set in the LU control
             block for the SLU whose BIND initiated the Call
             Request.

             When the ACTLU response is received, HNAS performs
             a validity check and if LUBST1=LUBSTBN is set but
             LUSVFREQ<>LURQBIND, the NASHALT is issued.

   SOLUTION: The callout initiator has been modified to set
             LUSVFREQ=LURQBIND for all SLUs on the SPU if a BIND
             is received during the callout procedure.

 APPLY_INFO: This problem FIX is applied like an APAR.

             See Chapter 6 (Product Maintenance Installation
             section) from the HNAS Guide and Reference Manual
             for instructions on how to install PTF's (Object,    
             Source and ZAPs) or Refresh/Upgrade maintenance.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in the APPLY_INFO (PTF).  

05-12-2004 - PROBLEM 2004127A

 PROBLEM_ID: 2004127A
     STATUS: CLOSED, APAR 2300031 issued.
  OPEN_DATE: 05-06-2004
 CLOSE_DATE: 05-12-2004
 SERVICE(S): QLLC Support
  MANDATORY: YES
 ORIGIN/REF: 230_IZB
   PTF_TYPE: (OBJ) HNASOBJX members
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): MCHRL3RR
  SOURCE(S): N/A

    PROBLEM: Following message issued, QLLC session hangs:

             NAS7601W MCH mch-nm LU lu-nm DECODE RC=20
             TH/RH=2C000102 00010BB0 A0021030 3C1280C6

DESCRIPTION: HNAS is unable to decode a formatted FMD request or
             response from the SLU in a QLLC session.  When this
             this happens, the NAS7601W message is issued and the
             PIU is discarded.

   SOLUTION: HNAS changed to pass the FMD PIU it can't decode to
             the PLU.

 APPLY_INFO: N/A

07-20-2004  - PROBLEM 2004125A

 PROBLEM_ID:  2004125A
     STATUS:  230 - CLOSED           (Apar 2300028 issued)
              220 - DEFERRED to 230  (Partial fix 2200089)
  OPEN_DATE:  05-04-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  05-12-2004             (Posted 07-20-2004)
 SERVICE(S):  QLLC SUPPORT
  MANDATORY:  YES
 ORIGIN/REF:  220_ITL and 230_ITL
    CP_TECH:  SFD/CPT
    PUBLISH:  YES
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  N/A - PENDING
   COREQ(S):  N/A
  PREREQ(S):  APAR 2200089
 SUPERSEDES:  N/A
  OBJECT(S):  QLSSCP
  SOURCE(S):  N/A

    PROBLEM:  REQSESS timeout can sometimes be inhibited and when
              it does occur, ACB is left open.

DESCRIPTION:  A REQSESS timeout can be inhibited if an FMD response
              is received after a REQSESS PIU has been passed to
              the PLU (pending a response).  If a REQSESS timeout
              does occur (PLU BIND was not received), the SLU ACB
              is left open so that a subsequent OPEN (via a new
              connection) will fail.

   SOLUTION:  The SLU/SSCP FMD response processor has been modified
              to only reset the SLU clock if a response timeout is
              running.  This will allow a possible REQSESS timeout
              to be left running.  The REQSESS timeout processor
              has been modified to close the LU ACB before a DACTLU
              is scheduled.  This will allow subsequent login
              attempts that reopen the ACB to work properly.

 APPLY_INFO:  This problem FIX is applied like an APAR.

              See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance.

              Corrective logic included in distributions created
              after CLOSE_DATE.  Otherwise, apply maintenance as
              directed in the APPLY_INFO (PTF).  

03-02-2005  - PROBLEM 2004124A

 PROBLEM_ID:  2004124A
     STATUS:  RETIRED - No Further Occurrence
  OPEN_DATE:  05-03-2004
REVISE_DATE:  N/A
 CLOSE_DATE:  03-02-2005
 SERVICE(S):  QLLC SUPPORT
  MANDATORY:  YES
    CP_TECH:  SFD
 ORIGIN/REF:  230_SNC
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnasproblem/
              (Complete FIX is contained in the 2004124A.ZIP file)
   COREQ(S):  N/A
  PREREQ(S):  Problem 2004112A
  OBJECT(S):  QLSSCP
  SOURCE(S):  N/A

    PROBLEM:  Spurious SPU disconnect can occur.

DESCRIPTION:  It appears that HNAS disconnects an SPU and its SLUs
              for no apparent reason.  We are attempting to trap
              activity that leads up to the disconnect.

              The following alarm messages are generated:

              15:50:13 NAS3799I LU EX006103 ENDING SESSION ON MCH
                       LR222801 HNAS CAUSE/DIAG=***/*** (**/**)
                                     DIAGX=****
                       :
              15:50:13 NAS8010I CLIENT=010.022.200.070(13650)
                       SOCKID=001E PCEID=0008 NAME=ROUTEURI
              15:50:13 NAS8010I PU PX0061   ENDING SESSION ON MCH
                       LR222801 (0001)
              15:50:13 NAS2210I CLIENT=010.022.200.070(13650)
                       SOCKID=001E PCEID=0008 NAME=ROUTEURI
              15:50:13 NAS2210I SOCKET CONNECTION CLOSED

   SOLUTION:  Resolution still pending.

 APPLY_INFO:  This problem FIX is applied like an APAR (pending).

              See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance.

              Corrective logic included in distributions created
              after CLOSE_DATE.  Otherwise, apply maintenance as
              directed in the APPLY_INFO (PTF).  

05-12-2004 - PROBLEM 2004120A

 PROBLEM_ID: 2004120A
     STATUS: CLOSED (230) - APAR 2300030 issued.
  OPEN_DATE: 04-29-2004
REVISE_DATE: 05-02-2004 (220/230 Solution section updated)
REVISE_DATE: 05-11-2004
 CLOSE_DATE: 05-12-2004
 SERVICE(S): QLLC SUPPORT
  MANDATORY: YES
 ORIGIN/REF: 230_SNC
   PTF_TYPE: (OBJ) HNASOBJX
    PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
             (Complete FIX is contained in the 2004120A.ZIP file)
   COREQ(S): N/A
  PREREQ(S): PROBLEM 2004112A
  OBJECT(S): QLSSCP
  SOURCE(S): N/A

    PROBLEM: Printer SLU cannot be bound.

DESCRIPTION: HNAS will OPEN the ACB for an SLU when an applid
             value is associated with the SLU in the LUNAME=
             operand (dedicated PLU support) or when input is
             received from the SLU as part of LOGON processing.
             Since printers cannot enter input, there is no way
             to OPEN its ACB to accept a BIND unless an applid
             is specified.  However, this will restrict the
             printer SLU to one PLU application only.  Printers
             are generally shared among multiple applications.

   SOLUTION: VRM specific, see 230 Solution: / 220 Solution:

   230
   SOLUTION: The QLLC ACTLU response and NOTIFY request logic has
             been modified to OPEN the ACB for an SLU and wait
             for a BIND if the applid index value associated with
             the SLU identifies the keyword 'ACQUIRE' in the
             APPLNAME= operand on the TYPE=SPU REMOTE definition
             statement.  This will place the SLU in a state that
             will allow it to be bound.  Note that the keyword
             ACQUIRE becomes a reserved keyword like MCHSOL and
             CONSOLE and thus cannot be the name of a real PLU
             application.

   220 
   SOLUTION: This problem was corrected in 230 only.  If printer
             SLU support is required, you must install 230.

 APPLY_INFO: This problem FIX is applied like an APAR.

             See Chapter 6 (Product Maintenance Installation
             section) from the HNAS Guide and Reference Manual
             for instructions on how to install PTF's (Object,
             Source and ZAPs) or Refresh/Upgrade maintenance.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in the APPLY_INFO (PTF).  

05-04-2004 - PROBLEM 2004119A

 PROBLEM_ID: 2004119A
             2004119A_1st-pass_history-only 
     STATUS: CLOSED, APAR 2300024 issued. 
  OPEN_DATE: 04-28-2004
REVISE DATE: 05-02-2004:
             Replace Description, remove corrective ZAP.
 CLOSE_DATE: 05-04-2004
 SERVICE(S): LLC0 and LLC5 Callout Support
  MANDATORY: YES
 ORIGIN/REF: 230_CIN
   PTF_TYPE: (OBJ) HNASOBJX members
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): VCCLEAR , MCHHL0RQ and MCHHL5RQ
  SOURCE(S): N/A

    PROBLEM: HNAS User 198 ABEND with the message:
             HALT AT LOC xxxxxxxx IN XOTBXM: INV VC

DESCRIPTION: Event Sequence:

             PLU BINDs an HNAS LLC0/5 callout LU.

             HNAS sends call request packet to network.

             PLU sends first FMD request (request held by HNAS
             because there is, as yet, no session).

             Remote rejects call with CLEAR.

             HNAS (incorrectly) sends -RSP to the PLU's FMD.
             The -RSP should not be sent because if multiple
             RTEOUT= entries are coded or if multiple DTE callout
             DTE addresses are coded for the LU then the FMD
             could still be sent if a call succeeds.

             HNAS schedules new call (multiple RTEOUT= entries).

             PLU UNBINDs (because of the -RSP).

             HNAS detaches VC and LU but (incorrectly) leaves
             call request pending in VC.  Call request packet
             builder detects a validity check when a VC with a
             call request has no LU (required to supply called
             DTE address).

   SOLUTION: HNAS changed to leave a PLU FMD request pending until
             all callout paths have been tried.  UNBIND logic
             changed to abort a pending call request.

 APPLY_INFO: N/A   

05-12-2004 - PROBLEM 2004112A


 PROBLEM_ID: 2004112A
     STATUS: CLOSED (220) - APAR 2200089 issued
             CLOSED (230) - APARs 2300028 and 2300029 issued
  OPEN_DATE: 04-21-2004
REVISE_DATE: 04-29-2004
REVISE_DATE: 05-03-2004
REVISE_DATE: 05-04-2004
REVISE_DATE: 05-09-2004 (for 230)
REVISE_DATE: 05-12-2004 (for 230)
 CLOSE_DATE: 05-03-2004 (for 220),
             05-12-2004 (for 230)
 SERVICE(S): QLLC SUPPORT
  MANDATORY: YES
 ORIGIN/REF: 220_ITL
   PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX (05-09-2004) members
    PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
             for V2R2M0 and /hnas_maint/hnas230m/apars/ for V2R3M0.
             (Complete FIX is contained in the 2004112A.ZIP file)
   COREQ(S): N/A
  PREREQ(S): APAR 2200065 (for 220)
  OBJECT(S): MCHNRQC and QLSSCP
  SOURCE(S): VTMTR and VTMUT1 (05-09-2004 for 230)

    PROBLEM: LOGON data from INIT-SELF PIU is being truncated
             resulting in missing data being passed to VTAM
             causing eventual session connect failure.

             04-29-2004 <begin>
             When REQSESS fails for a QLLC SLU, DACTLU is scheduled
             but LU ACB is not closed.
             04-29-2004 <end>

             05-03-2004 <begin>
             REQSESS timeout can sometimes be inhibited and when
             it does occur, ACB is left open.
             05-03-2004 <end>

             05-09-2004 <begin>
             The wrong MCH name is displayed in the NAS3798I message
             and logged in the HNAS trace table when an SLU ACB is
             opened for an SPU with OPTIONS=CLOTINITYP=BIND.
             05-09-2004 <end>

DESCRIPTION: HNAS extracts the PLU name from the INIT-SELF PIU
             and passes it to VTAM in the REQSESS request.  HNAS
             ignores any other data that may be present.

             04-29-2004 <begin>
             A REQSESS failure due to an invalid PLU application
             name or invalid LOGON data carried in an INIT_SELF or
             via USSTAB processing causes subsequent logon attempts
             to fail.  The REQSESS failure forces the LU to be
             deactivated (DACTLU) but does not close the LU ACB.
             When a subsequent connection is attempted, the ACB
             open routine is called, but because the LU ACB is
             still open, the OPEN fails with RC=0858 and USSMSG7
             is transmitted before the DACTLU.  Problem was seen
             when INIT_OTHER was processed.
             04-29-2004 <end>

             05-04-2004 <begin>
             A REQSESS timeout can be inhibited if an FMD response
             is received while after a REQSESS has been passed to
             the PLU.  If a REQSESS timeout does occur (PLU BIND
             was not received), the SLU ACB is left open so that
             a subsequent OPEN (via a new connection) will fail.
             05-04-2004 <end>

             05-09-2004 <begin>
             When OPTIONS=CLOTINITYP=BIND is specified for a
             TYPE=SPU REMOTE definition statement, the ACB for all
             SLUs on the SPU are opened when the OPTIONS=MCHTMR=
             value expires for the first MCH in the CDF.  This
             MCH may or may not be related to the SPU in question.
             Hence, using it's name in the NAS3798I message and
             HNAS trace table entry can be misleading.
             05-09-2004 <end>

   SOLUTION: The INIT-SELF PIU processing logic has been modified
             so that all data is passed to VTAM in the REQSESS
             request.

             04-29-2004 <begin> 
             The REQSESS failure routine has been modified to close
             the LU ACB before the DACTLU is scheduled.  This will
             allow subsequent login attempts that reopen the ACB
             to work properly.
             04-29-2004 <end>

             05-04-2004 <begin>
             The SLU/SSCP FMD response processor has been modified
             to only reset the SLU clock if a response timeout is
             running.  This will allow a possible REQSESS timeout
             to be left running.  The REQSESS timeout processor
             has been modified to close the LU ACB before a
             DACTLU is scheduled.  This will allow subsequent
             login attempts that reopen the ACB to work properly.
             05-04-2004 <end>

             05-09-2004 <begin>
             When an SLU ACB is opened for a TYPE=SPU REMOTE
             definition statement with OPTIONS=CLOTINITYP=BIND,
             the MCH name and active connection count are
             displayed as asterisks (********).
             05-09-2004 <end>

 APPLY_INFO: This problem FIX is applied like an APAR.

             See Chapter 6 (Product Maintenance Installation
             section) from the HNAS Guide and Reference Manual
             for instructions on how to install PTF's (Object,
             Source and ZAPs) or Refresh/Upgrade maintenance.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in the APPLY_INFO (PTF).  

06-02-2004 - PROBLEM 2004111A

 PROBLEM_ID: 2004111A 
     STATUS: CLOSED, APAR 2300040 issued.
  OPEN_DATE: 04-20-2004
    REVISED: 05-28-2004
 CLOSE_DATE: 06-02-2004
 SERVICE(S): QLLC SUPPORT
  MANDATORY: YES
 ORIGIN/REF: 230_SNC
   PTF_TYPE: (OBJ) HNASOBJX
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): MCHRL3RR
  SOURCE(S): N/A

    PROBLEM: Reset 05/02 can be received for a QLLC VC.

DESCRIPTION: When HNAS is processing inputs from different LUs
             connected via the same X25 virtual circuit, it is
             possible for an incorrect P(R) value to be sent.
             This causes an X25 RESET to occur and the QLLC
             sessions on the VC will be taken down.

   SOLUTION: HNAS P(R) (packet level acknowledgement) logic
             corrected.

 APPLY_INFO: N/A   

04-22-2004 - PROBLEM 2004105A


 PROBLEM_ID: 2004105A
     STATUS: CLOSED, APAR 2300021 issued.
  OPEN_DATE: 04-12-2004
 CLOSE_DATE: 04-22-2004
 SERVICE(S): CONSOLE SUBSYSTEM - PING COMMAND
  MANDATORY: YES
 ORIGIN/REF: 230_SWT
   PTF_TYPE: (OBJ) HNASOBJX
    PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
            (Complete FIX is contained in the 2004105A.ZIP file)
   COREQ(S): N/A
  PREREQ(S): APAR 2300012
  OBJECT(S): CONSPING
  SOURCE(S): N/A

    PROBLEM: PING command does not process called a DTE address
             override value properly when the IP address is omitted.

DESCRIPTION: APAR 2300012 was supposed to correct an error that
             allows a DTE address override to be specified without
             an IP address comma place holder.

             In some cases, the first character of the override
             DTE address is being clipped before the DTE address
             is decoded which causes the first character to be
             deleted and the DTE address length to be reduced
             by one.

   SOLUTION: The PING command decode logic has been modified to
             prevent the first character of the DTE address
             override from being deleted.

 APPLY_INFO: See Chapter 6 (Product Maintenance Installation
             section) from the HNAS Guide and Reference Manual
             for instructions on how to install PTF's (Object,
             Source and ZAPs) or Refresh/Upgrade maintenance.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in the APPLY_INFO (PTF). 

04-16-2004 - PROBLEM 2004098A (230 version of 2004085A)

 PROBLEM_ID: 2004098A
     STATUS: CLOSED, APAR 2300018 issued.
  OPEN_DATE: 03-25-2004
REVISE_DATE: 04-08-2004
REVISE_DATE: 04-09-2004
REVISE_DATE: 04-13-2004
REVISE_DATE: 04-15-2004
 CLOSE_DATE: 04-16-2004
 SERVICE(S): QLLC SUPPORT
  MANDATORY: N/A
 ORIGIN/REF: 230_CIN,(220_ITL)
   PTF_TYPE: N/A
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): MCHHL3RQ, MCHRL3RR, MCHHRQ
  SOURCE(S): VTMSND1, VTMSND2 04-08-2004

    PROBLEM: HNAS does not treat the sequence UNBIND (bind
             forthcoming), BIND correctly.  The BIND is rejected
             with sense 0805FFFF and the NAS4704W warning message
             is issued.  The QLLC session fails to start.

             04-08-2004 <begin>
             With the BIND/UNBIND/BIND sequence corrected the QLLC
             session still fails to start.  This is because the
             SESSIONC macro used to send the remote's response to
             the second PLU SDT fails with R15=04, R0=14, FDB2=7C.
             This failure aborts the session.
             04-08-2004 <end>

             04-09-2004 <begin>
             With the 04-08-2004 correction on the session fails to
             start.  The SLU sends an UNBIND '32FE20110000' in
             response to the first FMD PIU sent by HNAS.  This
             response indicates a pacing error.
             04-09-2004 <end>

             04-13-2004 <begin>
             PROG726 error at remote device when first message in
             the second BIND session sent to HNAS.  NAS7601W warning
             message displayed with RC=0C.
             04-13-2004 <end>

             04-15-2004 <begin>
             USSMSG 10 send after unbind processing completes for
             a QLLC LU generated with an application index (dedicated
             PLU).
             04-15-2004 <end>

DESCRIPTION: When the UNBIND bind forthcoming is received HNAS
             sends an UNBIND PIU to the remote device.  The LU
             state is set to "unbind in progress". For application
             LUs, VTAM supplies the response to an UNBIND to the
             PLU.  This means that the PLU is free to send a BIND
             request while HNAS is still waiting for the remote to
             respond to the UNBIND request.  When a BIND arrives
             under these conditions it is (improperly) rejected
             and the NAS4704W warning message is issued.

             04-08-2004 <begin>
             The SESSIONC send SDT response failure is because a
             bit set by previous RPL operations is not turned off
             when the SESSIONC is issued.
             04-08-2004 <end>

             04-09-2004 <begin>
             When the UNBIND in the BIND/UNBIND/BIND sequence is
             processed, HNAS does not properly reset the pacing
             window controls.  As a result, the first FMD PIU sent
             in the new session does not carry the pace bit (as
             required by SNS pacing protocol).
             04-09-2004 <end>

             04-13-2004 <begin>
             UNBIND does not reset the normal flow SLU to HNAS
             sequence number.  As a result the first FMD after
             the BIND/UNBIND/BIND sequence is rejected by HNAS
             with SENSE=2001 (invalid sequence number).
             04-13-2004 <end>

             04-15-2004 <begin>
             When an HNAS QLLC LU receives an UNBIND and the LU
             was generated with an application index (TYPE=SPU
             remote LUNAME=(,LUNM///appl-index) HNAS should
             request a new session with the specified PLU. Because
             of a logic error, HNAS sends USSMSG 10.
             04-15-2004 <end>

   SOLUTION: HNAS modified to properly process A BIND that arrives
             while hnas is waiting for a previous UNBIND response.

             04-08-2004 <begin>
             HNAS modified to rest the USERRH RPL bit before a
             SESSIONC macro is issued.
             04-08-2004 <end>
             04-09-2004 <begin>
             HNAS modified to properly reset pacing controls when
             a QLLC UNBIND is processed.
             04-09-2004 <end>

             04-13-2004 <begin>
             HNAS modified to reset the normal flow sequence
             number when a QLLC UNBIND is processed.
             04-13-2004 <end>

             04-15-2004 <begin>
             HNAS modified to request a new session with the
             permanently assigned PLU.
             04-15-2004 <end>

 APPLY_INFO: N/A  

 03-29-2004  - PROBLEM 2004089N

 PROBLEM_ID: 2004089N

     NOTICE: Problem Summary Notice

             Text format problem summary (non-html) entries are now
             located as separate members in directory:

                \maint\hnasproblem\ .

             The text format Problem Summary file problemsum.txt is 
             no longer maintained, please refer to the problemsum.htm
             file for up-to-date information.   

02-10-2005  - PROBLEM 2004089A

 PROBLEM_ID:  2004089A  (became APAR 2300107)
     STATUS:  CLOSED
  OPEN_DATE:  03-29-2004
REVISE_DATE:  01-29-2005 - additional information provided by HVBINFO
 CLOSE_DATE:  02-10-2005
 SERVICE(S):  PVC SUPPORT
  MANDATORY:  N/A
 ORIGIN/REF:  230_CP,230_BPO,230_HVB
    CP_TECH:  PWB,SFD
    PUBLISH:  YES, WIP
   PTF_INFO:  TBD
   PTF_TYPE:  N/A
    PTF_LOC:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  TBD
  SOURCE(S):  TBD

    PROBLEM:  PVC session fails to activate (see NAS7707W) when HNAS
              initiates the PVC Set-up with packet and window size
              values that don't match the network requirements.

              <begin 01-29-2005>
              HVBINFO reported that PVCs setup fails after IMS
              is taken down and restarted.  PVCs worked prior to
              this event which suggests that they were set up by
              the router, not HNAS.  This is based on the fact
              that the following messages are being generated
              when IMS is restarted.

              NAS7704W REMOTE 223.220.021.099(03796) RESPONDED TO
                       NAS PVC SETUP W/STATUS=18
              NAS7708W XOT PVC SETUP INIT=SERIALBVPVC
                       RESP=SERIAL4/0

              <end 01-29-2005>

 DESCRIPTION: HNAS does not allow the PVC packet and window sizes
              to be specified in the CDF.  The defaults set by HNAS
              are packet size=256 and window size=4.  These values
              are carried in the PVC Setup packet sent by HNAS to
              start the PVC session.  If the values are rejected by
              the remote because the remote's configuration has
              different values then a ZAP is required.

              This problem rarely occurs because in almost all cases
              the router starts the PVC Set-up process and HNAS will
              set the packet and window sizes to the values provided
              from the routers PVC Set-up packet.

   SOLUTION:  The PVC operand will be modified to allow an MXT to
              be associated with a PVC entry.  The packet size and
              window size for the PVC will be extracted from the FAC=
              operand on the associated MXT via facility 42 and 43,
              respectively.

              PVC=(...,slunm/llc/applid/ifname/rmtname/mxtname....)

              mxtname REMOTE TYPE=MXT
                             FAC=420A0A,    ; set packet size to 1024
                                 430404,    ; set window size to 4

              Note: In this enhancement, the PVC windowsize/packetsize
                    are expressed using SVC Facility Parameter values
                    normally used in Call Request packets.  For PVC's
                    the window and packet sizes are provided in the
                    PVC set-up packet.

CIRCUMVENTION:

   TEMPORARY: A patch (ZAP) can be provided to set the packet and
    SOLUTION: window sizes to the required defaults.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*     V2R3M0 ZAP TO SET WINDOW SIZE TO x AND PACKET SIZE TO 2**y
*     FOR PVC SESSIONS
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME HNAS XOTBXM
VER  07B4 4110,0004
REP  07B4 4110,000x <- change x to window size configured in router
VER  07CC 4110,0008
REP  07CC 4110,000y <- change y to packet size exponent (2**y)
                       configured in router

 APPLY_INFO:  N/A 

04-21-2004 - PROBLEM 2004085A

 PROBLEM_ID: 2004085A
     STATUS: CLOSED, APAR 2200085 issued.
  OPEN_DATE: 03-25-2004
 CLOSE_DATE: 04-21-2004
 SERVICE(S): QLLC SUPPORT
  MANDATORY: N/A
 ORIGIN/REF: 220_ITL
   PTF_TYPE: N/A
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): MCHHL3RQ, MCHRL3RR, MCHHRQ.
  SOURCE(S): N/A

    PROBLEM: HNAS does not treat the sequence UNBIND (bind
             forthcoming), BIND correctly.  The BIND is rejected
             with sense 0805FFFF and the NAS4704W warning message
             is issued.  The QLLC session fails to start.

DESCRIPTION: When the UNBIND bind forthcoming is received HNAS
             sends an UNBIND PIU to the remote device.  The LU
             state is set to "unbind in progress".  For application
             LUs, VTAM supplies the response to an UNBIND to the
             PLU.  This means that the PLU is free to send a BIND
             request while HNAS is still waiting for the remote to
             respond to the UNBIND request.  When a BIND arrives
             under these conditions it is (improperly) rejected
             and the NAS4704W warning message is issued.

   SOLUTION: HNAS modified to properly process A BIND that arrives
             while hnas is waiting for a previous UNBIND response.

 APPLY_INFO: N/A

05-18-2004 - PROBLEM 2004084A

 PROBLEM_ID: 2004084A
     STATUS: CLOSED, APAR 2200090 issued.
  OPEN_DATE: 03-24-2004
REVISE_DATE: 04-12-2004
REVISE_DATE: 05-11-2004
 CLOSE_DATE: 05-18-2004
 SERVICE(S): GATE SUPPORT
  MANDATORY: N/A
 ORIGIN/REF: 220_NMP
   PTF_TYPE: N/A
    PTF_LOC: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): MCHSTRT, MCHNRQC
  SOURCE(S): VTMTR

    PROBLEM: GATE control session not properly reactivated when PLU
             taken down and restarted.  Inbound calls are cleared
             with DIAG=138 (X'8A') = control session not bound.
             NAS3702W message issued.

DESCRIPTION: When the PLU is terminated HNAS receives a NOTIFY
             request.  This takes down the control session LU.
             After a one minute time delay the ACB for the control
             session LU is reopened and a REQSESS is sent to the
             PLU (assuming a PLU name was coded in the HNAS CDF).
             If the REQSESS fails, HNAS waits for the PLU to issue
             a BIND to activate the control session.  If no BIND
             is sent, all inbound calls that require the control
             session to be active will fail.  CTCPs that don't
             acquire their control session LUs will not be useable
             after the take down sequence.

   SOLUTION: HNAS modified to retry the REQSESS every minute.  The
             ACB remains open so that a BIND from the PLU will be
             accepted.

             04-12-2004 <begin>
             Customer has put in place some kind of circumvention
             on the CSFI side which appeared to have corrected
             the problem.  We are awaiting details as to what was
             specifically changed as well as the results after the
             HNAS problem fix logic was applied.
             04-12-2004 <end>

             05-11-2004 <begin>
             Circumvention is to start HNAS 5 minutes after CSFI.

             Additional tests show that the GATE FC data session LUs
             are not useable because of apar 2200035.  This APAR
             ignores a REQSESS completion with R15=04 R0=10 FDB2=12
             because HNAS (incorrectly) thinks a BIND is coming.

             Problem fix has been revised so that all REQSESS
             failures are reported (NAS3702W message).  In addition,
             REQSESS for a GATE control session or FC data sessions
             sessions is retried based on the OPTION=MCHTMR=seconds
             value (default = 60 seconds).
             05-11-2004 <end>

 APPLY_INFO: N/A 

02-26-2004 - PROBLEM 2004055A


 PROBLEM_ID: 2004055A
     STATUS: CLOSED, APAR 2200077 issued.
  OPEN_DATE: 02-24-2004
 CLOSE_DATE: 02-26-2004/03-09-2004
 SERVICE(S): QLLC SUPPORT
  MANDATORY: N/A
 ORIGIN/REF: 220_NBG
   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 can ABEND with 0C4 if an SPU is defined but is not
             referenced in any SVC3= operand.

DESCRIPTION: In 220, an SPU and its SLUs are initialized when HNAS
             start logic interrogates all SVC3= operands on all MCHs.
             If an SPU is defined in the CDF but is not referenced
             in any SVC3= operand, it will not be initialized
             correctly.  At run time, if the un-initialized SPU is
             selected via IDBLK/IDNUM matching, an 0C4 ABEND will 
             occur because the LU control blocks (LUBs) for the
             SLUs defined in the LUNAME= operand for the SPU will
             not have been resolved.

   SOLUTION: The HNAS 220 fix to this problem will be to issue a
             configuration error message indicating the the free
             SPU must be referenced in at least one SVC3= operand.
             This error message will cause HNAS to terminate after
             the CDF is completely scanned.  This fix will be
             implemented as an APAR.

             The HNAS 230 fix to this problem is to initialize all
             SPUs in the CDF regardless of whether or not they are
             referenced in an SVC3= operand.

 APPLY_INFO: NONE   

02-10-2004  - PROBLEM 2004040A

 PROBLEM_ID:  2004040A
     STATUS:  CLOSED,DEFERRED,FIXED_IN_V2R3M0.
  OPEN_DATE:  02-09-2004
 CLOSE_DATE:  02-24-2004
 SERVICE(S):  HNASRCV and HNASMNT Assemblies (220/230)
  MANDATORY:  NO
 ORIGIN/REF:  220_GED
   PTF_TYPE:  N/A DEFERRED-TO-230
    PTF_LOC:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  HNAS assembly steps can encounter CC-4 warning
              message: 'ASMA015W - Literal bounds exceeded'.

DESCRIPTION:  The HNASRCV (installation) or HNASMNT (maintenance)
              job assemblies can encounter CC-4 warning message
              'ASMA015W Literal bounds exceeded'.  Although the
              message is displayed, the literal constant assembles
              correctly so the messages can be ignored.

   SOLUTION:  The HNAS 230 fix to this problem is to rework the
              complex literal statements so that CC=4 is not
              generated avoiding potential confusion.

 APPLY_INFO:  NONE

02-10-2004 - PROBLEM 2004021B

 PROBLEM_ID: 2004021B
     STATUS: CLOSED, APAR 2200073 issued.
  OPEN_DATE: 01-21-2004
 CLOSE_DATE: 02-16-2004
 SERVICE(S): LLC0 callin, possibly other LLCn types.
  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: Customer reports that XOT Pipe appears inoperable,
             after several hours/days of normal operation then
             callin XOT session connects/disconnects fail.

DESCRIPTION: XOT session connect/disconnect activity between
             the router and HNAS gets into a state where new
             session attempts are rejected and remote session
             disconnects don't complete.  Call Request and
             Clear Request packets from remote network-to-
             router can encounter 30 second response timeouts.
             This causes router to generate Clear Request
             with diagnostic codes 49(31) or 50(32) as well
             as Diagnostic Packets eventually closing the
             XOT socket which can then become unavailable.

             Router 'debug xot event' monitor reports:

                    'XOT open failed' messages,  while

             HNAS SYSPRINT may report the following messages:

                    NAS3799I Clear CAUSE/DIAG=000/049 (00/31),
                    NAS7715W CLEAR DIAG=130 (82) or
                    NAS7703W DIAG FROM ...
                    NAS7799I PKT=1000F132 1001

     ACTION: This problem is currently under investigation at
             a customer site running under Z/OS V1R3.

             Current debugging activity indicates that there
             is a potential bug or anomaly in the Z/OS V1R3
             stack code.  We are currently working with IBM
             on this problem.

   SOLUTION: See APAR 2200073.  

01-15-2004 - PROBLEM 2004010A

 PROBLEM_ID: 2004010A
     STATUS: CLOSED, APAR 2200070 issued.
  OPEN_DATE: 12-15-2003
 CLOSE_DATE: 01-15-2004
 SERVICE(S): ALL
  MANDATORY: YES
 ORIGIN/REF: 220_ETL_12-05-2003
   PTF_TYPE: <N/A>
    PTF_LOC: <N/A>
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): VTMEXIT, VTMRCV1.

    PROBLEM: HNAS exit routine rejects BIND with sense=0805C5E7.
             Session fails to start.

DESCRIPTION: When the PLU uses a BIND, UNBIND (bind pending), BIND
             sequence HNAS can incorrectly reject the second BIND.

             The VIRTEL GATE support CTCP uses the above sequence.

             The problem occurs when the UNBIND and BIND occur at
             nearly the same time.  If the BIND exit is driven before
             the HNAS task level has processed the UNBIND then the
             LU appears already bound to the BIND exit routine.
             Since multiple sessions are not supported the new bind
             is rejected with the above sense.

   SOLUTION: HNAS corrected to not reject a BIND in the above
             situation.

 APPLY_INFO: See Chapter 6 (Product Maintenance Installation
             section) from the HNAS Guide and Reference Manual
             for instructions on how to install PTF's (Object,
             Source and ZAPs) or Refresh/Upgrade maintenance.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in the APPLY_INFO (PTF).  

01-06-2004 - PROBLEM 2003346A

 PROBLEM_ID: 2003346A
     STATUS: CLOSED, APAR 2200067 issued.
  OPEN_DATE: 12-12-2003
 CLOSE_DATE: 01-06-2004
 SERVICE(S): TCPIP (SHARED SOCKET POOLS)
  MANDATORY: YES, IF SHARED SOCKET POOLS ARE USED
 ORIGIN/REF: 220_CFF_12-12-2003
   PTF_TYPE: <N/A>
    PTF_LOC: <N/A>
    COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): NASTCP

    PROBLEM: TCPIP SOCKET requests begin to fail with error number
             27DD after HNAS has been running for awhile.

DESCRIPTION: Callout SOCKET requests can fail with the following
             error message being issued after HNAS has been running
             for some time or when there is considerable inbound
             and outbound VC connect activity.

             NAS2201W CLIENT=ipaddr(port) SOCKID=001E PCEID=xxxxx
             NAME=lclname
             NAS2201I SOCKET REQUEST FAILED, RC=FFFFFFFF 000027DD

             The problem occurs because the socket number that 
             HNAS provides to the stack in the SOCKET request is
             also used by another active socket.  The 27DD error
             number says 'the requested socket number is a
             duplicate'.   Normally, if a duplicate socket number
             is given to the stack in the SOCKET request, the stack
             will provide an unused socket number when the SOCKET
             request ends.  HNAS always uses the socket number that
             the stack provides regardless of the value it requests.
             It now appears that some levels of the stack require
             that the requested socket number always be unused.

             HNAS gets into this situation over time because the
             requested socket number that is assigned to the TCPIP
             Process Control Elements (PCEs) during the CDF scan
             can be overlaid when a new inbound connection is
             received.  Since the same PCE can be used for both
             inbound and outbound connections (when shared socket
             pool support is defined via PORT=1998 operand), the
             overlaid requested socket from a previous inbound
             connection is used for an outbound connection.  If
             this overlaid socket number is already in use, the
             27DD error will be generated.

CIRCUMVENTION: Specify separate inbound and outbound socket pools,
               with the inbound pool (PORT=DYNAMIC) configured
               before the outbound socket pool (PORT=1998).

    SOLUTION: HNAS logic has been corrected to always provide an
              unused socket number for the TCPIP SOCKET request.

  APPLY_INFO: See Chapter 6 (Product Maintenance Installation
              section) from the HNAS Guide and Reference Manual
              for instructions on how to install PTF's (Object,
              Source and ZAPs) or Refresh/Upgrade maintenance.

              Corrective logic included in distributions created
              after CLOSE_DATE.  Otherwise, apply maintenance as
              directed in the APPLY_INFO (PTF).

11-19-2004  - PROBLEM 2003230A

 PROBLEM_ID:  2003230A
     STATUS:  RETIRED
              PENDING_PROBLEM_RE-CREATION,DEBUG/TRAP
              12-11-2003 - Unable to recreate problem as of this date.   
  OPEN_DATE:  08-18-2003
 CLOSE_DATE:  ..-..-2003
RETIRE_DATE:  11-19-2004 - Retired, unable to recreate (UFO).
 SERVICE(S):  TCPIP interface support
  MANDATORY:  NO
 ORIGIN/REF:  220_CAJ
   PTF_TYPE:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  HNAS ABENDS after NAS2051S message is issued.

DESCRIPTION:  HNAS was started when the TCPIP stack was down.  In
              this situation HNAS detects this fact and issues the
              following message:

              NAS2031W SERVER=ipaddr(port) SOCKID=sid PCEID=pid ...
              NAS2031I API CONNECTION TO stacknm IS BEING DEFERRED

              HNAS will interrogate the stack again in 10 minutes to
              see if it is active.  If it is not, the sequence
              repeats.  If it is active, HNAS will issue an INITAPI
              command to connect to the stack and then continue its
              initialization until finally issuing the following
              message when initialization is complete:

              NAS0001I HOST NAS INITIALIZATION COMPLETE, ALL
                       FUNCTIONS READY

              This sequence has been tested in our lab and seems to
              work properly.  However, at a customer site, we appear
              to be having different symptoms that so far cannot be
              explained.  Additional messages are being generate
              that indicate that 'ALL FUNCTIONS ARE READY' but we
              do not actually see the NAS0001I message.  The ABEND
              that occurs after the NAS2051I message suggests that
              the connection to the stack was severed prior to the
              message but we do not see any other message that
              confirms this.

   SOLUTION:  This problem cannot be recreated at the customer site
              so it is being deferred pending another occurrence.

 APPLY_INFO:  N/A

08-12-2003  - PROBLEM 2003220A

 PROBLEM_ID:  2003220A
     STATUS:  CLOSED, Non-APAR, See Solution: V2R2M0/V2R3M0 notice.
  OPEN_DATE:  08-08-2003
 CLOSE_DATE:  08-12-0303
 SERVICE(S):  GATE X25.VC Group 'n' Range support
  MANDATORY:  NO
 ORIGIN/REF:  220_CAJ
   PTF_TYPE:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  Inbound GATE call requests to the CTCP start with
              X'F001' as the RESID (resource identifier) in the call
              request packet sent to the CTCP.  Subsequent IDs will
              be X'F002', etc.

              The customer's CTCP expects the RESID values to start
              at X'F014'.

DESCRIPTION:  In NPSI it is possible to configure the range of valid
              VC logical channel numbers following the definition of
              an MCH.  If X25.VC LCN=(020,024) is coded in logical
              channel group 0 then the RESIDs in GATE call requests
              will start with X'F014'.

              With HNAS, each call request is carried in a separate
              TCP/IP session.  HNAS is not aware of the X25 line
              configuration at the router and does not know the LCN.
              This necessitated the creation of a logical MCH which
              an inbound call is routed to via the RTEIN= operand.
              RESIDs on this type of MCH start at 1 plus the number
              PVCs defined for the MCH (usually 0).

   SOLUTION:  In V2R3M0 the MCH will support OPTIONS=RESIDSTART=val.
              In V2R2M0 a special custom patch can be provided.

 APPLY_INFO:  Special patch available upon request.

08-25-2003  - PROBLEM 2003219A

 PROBLEM_ID:  2003219A
     STATUS:  CLOSED, Non-APAR, See Solution: V2R2M0/V2R3M0 notice.
  OPEN_DATE:  08-07-2003
 CLOSE_DATE:  08-23-2003
 SERVICE(S):  ALL
  MANDATORY:  YES
 ORIGIN/REF:  220_KWT_08-07-2003
   PTF_TYPE:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  MCHHRQ
  SOURCE(S):  N/A

    PROBLEM:  CICS issues UNBIND after HNAS rejects CICS BID
              with 0814 sense (BID rejected RTR forthcoming).

DESCRIPTION:  HNAS is receiving a BID when it is contention winner
              and there are packet on LUIQ.

              CICS treats RTR as an invalid request.
              This could depend on the terminal type (customer has
              3767 defined)

              Customer is testing a ZAP which rejects the BID with
              0813 sense (BID rejected, no RTR forthcoming).

   SOLUTION: In V2R3M0 the MCH will support OPTIONS=NORTRBIDREJ.
             In V2R2M0 the following APPLY_INFO patch can be used.

 APPLY_INFO: Special ZAP.

***
*** Aug 12, 2003 customer running the following with good results.
***

* * * * * * * *
*   Aug 7, 2003
*   V2R2M0
*   ZAP TO REJECT BID WITH 0813 SENSE (INSTEAD OF 0814).
* * * * * * * *
 NAME NASMAIN MCHHRQ
 VER 02EE 4710,A7B0
 REP 02EE 47F0  

08-25-2003 - PROBLEM 2003218A

 PROBLEM_ID: 2003218A
     STATUS: CLOSED, APAR 2200051 issued.
  OPEN_DATE: 08-04-2003
 CLOSE_DATE: 08-25-2003
 SERVICE(S): ALL
  MANDATORY: YES
 ORIGIN/REF: 220_KWT_08-04-2003
   PTF_TYPE: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): MCHTMR
  SOURCE(S): N/A

    PROBLEM: Inbound calls are cleared with DIAG=130 (X'82').

DESCRIPTION: This problem occurs when a new call arrives and there
             are no LU control blocks available for use.  This will
             happen if all the LUs in an SVCx= list are in use.

             When the following sequence occurs an LU can become
             permanently unavailable:

             Call arrives
             HNAS allocates LU
             Issues REQSESS to ask PLU for a BIND (normal complete)
             10 sec timer started to ensure bind received
             Timer expires, LU and VC detached, call cleared with
             DIAG=143 (X'8F').
             BIND received

             At this point the LU is bound but has no VC session.
             If the PLU does a SEND error status will be returned
             and the session will be reset.
             If the PLU waits for input the LU is effectively lost.

   SOLUTION: HNAS logic corrected to CLOSE the HNAS ACB when this
             timeout is received.

 APPLY_INFO: N/A

08-25-2003 - PROBLEM 2003210A

 PROBLEM_ID: 2003210A
     STATUS: CLOSED, Non-APAR, See Solution: V2R2M0/V2R3M0 notice.
  OPEN_DATE: 07-29-2003
 CLOSE_DATE: 08-23-2003
 SERVICE(S): LLC0/LLC4/LLC5
  MANDATORY: NO
 ORIGIN/REF: 220_CAJ_07-06-2003
   PTF_TYPE: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): N/A

    PROBLEM: CICS issues unexpected UNBIND during session.

DESCRIPTION: Two problems are under investigation, identified:

             1) HNAS rejects BID if it is in the process of
                assembling an M-bit chain when the BID arrives.

             2) In contention session w/ brackets the following:
                a) packet received, sent to CICS as OIC BB
                b) before CICS can end bracket second packet
                   received.  set to CICS as OIC no bracket bits
                   (i.e. part of first bracket).
                c) CICS UNBINDS with BRACKET error message.

   SOLUTION: In V2R3M0 the following options may be coded:

             1) OPTION=INHIBITBIDREJ
                Causes HNAS to accept a PLU BID when an
                inbound message (PIU) is being assembled.

             2) OPTION=ONEPIUINB
                Causes HNAS to hold the second PIU in an
                inbound sequence until the PLU has ended
                the bracket started by the first inbound
                PIU.

             In V2R2M0, following APPLY_INFO patches can be used.


 APPLY_INFO: Special ZAP.

*
* July 6, 2003
* ZAP to accept PLU BID when M-bit chain assembly in progress
*
 NAME NASMAIN MCHHRQ
 VER 02DE 4710,A2FA
 REP 02DE 47F0

*
* July 29, 2003
* ZAP to requeue input if PIU for next chain is ready before
* LU has ended bracket for previous chain.  CICS does not
* like the second PIU in the bracket.
*
 NAME NASMAIN MCHLUIN
 VER 035C 9180,5133
 REP 035C 91A0
 VER 0360 4710
 REP 0360 4770 

08-25-2003  - PROBLEM 2003210A

 PROBLEM_ID:  2003210A
     STATUS:  CLOSED, Non-APAR, See Solution: V2R2M0/V2R3M0 notice.
  OPEN_DATE:  07-29-2003
 CLOSE_DATE:  08-23-2003
 SERVICE(S):  LLC0/LLC4/LLC5
  MANDATORY:  NO
 ORIGIN/REF:  220_CAJ_07-06-2003
   PTF_TYPE:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  CICS issues unexpected UNBIND during session.

DESCRIPTION:  Two problems are under investigation, identified:

              1) HNAS rejects BID if it is in the process of
                 assembling an M-bit chain when the BID arrives.

              2) In contention session w/ brackets the following:
                 a) packet received, sent to CICS as OIC BB
                 b) before CICS can end bracket second packet
                    received.  set to CICS as OIC no bracket bits
                    (i.e. part of first bracket).
                 c) CICS UNBINDS with BRACKET error message.

   SOLUTION:  In V2R3M0 the following options may be coded:

                 1) OPTION=INHIBITBIDREJ
                    Causes HNAS to accept a PLU BID when an 
                    inbound message (PIU) is being assembled.

                 2) OPTION=ONEPIUINB
                    Causes HNAS to hold the second PIU in an 
                    inbound sequence until the PLU has ended 
                    the bracket started by the first inbound 
                    PIU.

              In V2R2M0, following APPLY_INFO patches can be used.


 APPLY_INFO:  Special ZAP.

*
*     July 6, 2003
*     ZAP to accept PLU BID when M-bit chain assembly in progress
*
 NAME NASMAIN MCHHRQ
 VER 02DE 4710,A2FA
 REP 02DE 47F0

*
*     July 29, 2003
*     ZAP to requeue input if PIU for next chain is ready before
*     PLU has ended bracket for previous chain.  CICS does not
*     like the second PIU in the bracket.
*
 NAME NASMAIN MCHLUIN
 VER 035C 9180,5133
 REP 035C 91A0
 VER 0360 4710
 REP 0360 4770 

12-14-2003 - PROBLEM 2003203A

 PROBLEM_ID: 2003203A
     STATUS: CLOSED, APAR 2200065 issued.
  OPEN_DATE: 07-22-2003
 CLOSE_DATE: 12-14-2003
 SERVICE(S): QLLC
  MANDATORY: YES
 ORIGIN/REF: 220_NBG_07-22-2003
   PTF_TYPE: N/A
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): QLSSCP
  SOURCE(S): N/A

    PROBLEM: When remote QLLC resources start and stop sessions
             resources get in a state where new sessions for
             specific LUs cannot be started.  The NAS3799I session
             end message is issued with CAUSE/DIAG=000/220.

DESCRIPTION: When a QLLC session is stopped and restarted the HNAS
             LU control block is not properly refreshed.  This leads
             to VTAM operations ending in error.  The VTAM error
             causes session start to fail.

   SOLUTION: HNAS logic corrected to refresh the LU control block
             before starting a new session.

 APPLY_INFO: N/A.

07-02-2003 - PROBLEM 2003183A, REVISED JULY 3, 2003

 PROBLEM_ID: 2003183A
     STATUS: CLOSED,SEE_APAR_2200038
  OPEN_DATE: 07-02-2003
 CLOSE_DATE: 07-07-2003
 SERVICE(S): 220 Transparent PAD (XPAD) logic.
  MANDATORY: NO
 ORIGIN/REF: 220_BNP
   PTF_TYPE: CIRCUMVENTION / ZAP
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): N/A

    PROBLEM: When an LLC5 transparent PAD call-in session starts
             and MCHSOL is used to select the PLU name for the
             session, HNAS sends the NPSI default PAD parameters
             to the remote PAD.  These parameters should not be
             sent when PAD=TRANSP has been coded.

             <text added July 3, 2003>
             If PADPARM=(xx/yy,...) is specified, the NPSI default
             parameters are still sent.  The message

             NAS1311W REMOTE PADPARM REQUIRES PAD=INTEG, IGNORED

             is issued.  The ignored parameter is treated as an 
             omitted parameter and the NPSI default parameters
             are sent.
             <end of text added July 3, 2003>

DESCRIPTION: See problem.

   SOLUTION: To circumvent this problem code PADPARM=NONE on the
             on the TYPE=REMOTE MCHs with PAD=TRANSP

             <text added July 3, 2003>
             If you wish to send PADPARMs when a PAD=TRANSP session
             begins and MCHSOL is used there are two choices:

             1) Apply the ZAP shown below.  This changes the
                configurator so that PADPARM= is allowed with
                PAD=TRANSP.

             2) Provide an MXT for the SVC5= LUs as follows:
                MCH1 REMOTE TYPE=MCH
                PAD=TRANSP
                SVC5=(xx,
                      LU001//MXT1,LU002//MXT1,...)
                MXT1 REMOTE TYPE=MXT 
                     PADPARM=(aa/bb,cc/dd,...)
             <end of text added July 3, 2003>

 APPLY_INFO: ZAP FIX added July 3, 2003

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* JULY 3, 2003
*
* PROBLEM ID: 2003183A
*
* PADPARM= PARMS NOT SENT WHEN CODED ON TYPE=MCH REMOTE
* WITH PAD=TRANSP AND MCHSOL USED FOR PLU SELECTION.
*
* ZAP CHANGES CONFIGURATOR TO ALLOW PADPARM= ON TYPE=MCH
* REMOTE WITH PAD=TRANSP
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 NAME NASMAIN CNFGPADP
 VER 0310 4770,A12A
 REP 0310 47F0,A12A  

06-30-2003  - PROBLEM 2003181A

 PROBLEM_ID:  2003181A
     STATUS:  DEFERRED,FIXED_IN_V2R3M0.G
  OPEN_DATE:  06-30-2003
 CLOSE_DATE:  06-30-2003
 SERVICE(S):  GATE
  MANDATORY:  NO
 ORIGIN/REF:  220_CPT
   PTF_TYPE:  N/A
  PREREQ(S):  N/A
  OBJECT(S):  MCHNRQC
  SOURCE(S):  N/A

    PROBLEM:  NAS7715W ip-addr CALL REQ TO MCH mch-nm FAILED ...
              message issued incorrectly after ACB for GATE
              data session fails to open.  NAS3701W (OPEN failed)
              is also issued.

              NAS7715W is incorrect because it reports the failure
              of an inbound call.  The failure is due to the
              following outbound call sequence:

              CTCP call request ---->
                                <--- call accept from remote to CTCP
                                     OPEN for data session ACB fails
                                     NAS3701W issued (OPEN failed)
                                     NAS7715W issued

DESCRIPTION:  See problem.

   SOLUTION:  In our next release the NAS7717W message will be
              displayed to report the outbound call failure.

 APPLY_INFO:  NONE  

07-23-2003 - PROBLEM 2003178A

 PROBLEM_ID: 2003178A
     STATUS: CLOSED,SEE_APAR_2200045 
  OPEN_DATE: 06-27-2003
 CLOSE_DATE: 07-23-2003
 SERVICE(S): HNAS ALERT MESSAGE SUPPORT (NAS2121I/NAS2121W)
  MANDATORY: NO, BUT RECOMMENDED
 ORIGIN/REF: AUD,220_BNP(JPM)
   PTF_TYPE: N/A
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): N/A

    PROBLEM: During HNAS socket close processing, a TCPIP CANCEL
             command is used to 'knock' down the active TCPIP
             command (normally a SELECT or RECEIVE).  We have
             observed that for some levels of the TCPIP stack
             (for example, z/OS V1R4), the CANCEL command sometimes
             ends in error and the following message is displayed:

             NAS2121W SERVER=ipaddr(port) SOCKID=xxxxx PCEID=xxxxx
             NAME=lclname
             NAS2121I CANCEL REQUEST FAILED, RC=FFFFFFFF 00000071

DESCRIPTION: We believe that this condition occurs and these messages
             are being generated because the TCPIP stack is making
             a mistake.  HNAS CANCEL logic has not changed since
             V2R1M1 which added support for z/OS V1R2.  Similarly,
             the TCPIP API has remained the same since z/OS V1R2.
             Our assumption is that the CANCEL command failures were
             introduced by maintenance applied to the TCPIP stack.
             The particular error number that HNAS receives for
             the CANCEL command (00000071) indicates that the TCPIP
             socket descriptor is invalid.  This cannot be true
             because if it were all other TCPIP commands would fail
             but they do not.

             Since we believed this to be a stack error, we opened
             up a PMR with IBM (#55214).  We were able to recreate
             problem in our lab with HNAS and TCPIP stack traces
             running.  We passed the TCPIP stack trace on to IBM
             and it revealed a timing problem.  Apparently, after
             HNAS receives a Clear, the remote end can take the
             socket down before HNAS can (a TCP FIN is received
             almost immediately after the Clear is received).  The
             result is that the socket is essentially closed by
             the time HNAS is attempting to close it but due to
             timing HNAS has not yet detected this.  The ERNO=71
             is wrong for this error, which IBM acknowledges.
             ERNO=71 says 'invalid socket descriptor' which is
             misleading (seems to be a catchall).  An ERNO that
             says 'socket is already closed' would have been more
             appropriate.  IBM has APARed this and will fix it in
             a later release of the TCP stack.

   SOLUTION: For now, we will treat this error number after a
             Clear is received as 'normal' CANCEL command ending.

             Since the CANCEL failure does not impact the subsequent
             socket close processing, we recommend filtering out the
             NAS2121s messages using the ALRMFLTR= operand on the
             BUILD definition statement as follows:

             ALRMFLRT=(ALLOW,NAS2121*(S))

             We would like to keep track of customers encountering
             this condition.  If you encounter this error condition
             please send an e-mail to support@comm-pro.com and be
             sure to include the following information:

             - HNAS DNAS display output (this information is
               located near the beginning of the HNAS SYSPRINT
               output or can be displayed via the operator
               console HNAS modify interface).

             - z/OS, TCP/IP Stack and VTAM level

 APPLY_INFO: NONE  

06-12-2003 - PROBLEM 2003163A

 PROBLEM_ID: 2003163A
     STATUS: CLOSED,SEE_APAR_2200045   

06-26-2003 - PROBLEM 2003157A

 PROBLEM_ID: 2003157A
     STATUS: CLOSED, SEE_APAR_2200036
  OPEN_DATE: 06-06-2003
 CLOSE_DATE: 06-26-2003
 SERVICE(S): HNAS QLLC SUPPORT
  MANDATORY: YES
 ORIGIN/REF: 220_NGB_05-13-2003
   PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): N/A

    PROBLEM: HNAS clears a QLLC VC call immediately after the
             connection is established with DIAG=53.

DESCRIPTION: After a QLLC VC is established, HNAS sends an XID
             request to the remote PU to solicit an XID response
             that carries, among other things, the IDBLK/IDNUM
             values that are required to select the correct
             TYPE=SPU REMOTE for the VC.  HNAS, by default,
             assumes the role of primary link station.

             The call is being cleared with DIAG=53 because HNAS
             receives an XID request instead of a response and the
             request has no I-field.  HNAS is actually in error on
             two accounts.  First, it should allow for the receipt
             of an XID request when a response is expected (XID
             collisions are allowed in the QLLC protocol) and
             second, it should allow a null I-field in the XID
             request it receives.  Unlike XID responses that MUST
             carry an I-field (containing, for example, the IDBLK/
             IDNUM values, MAXDATA value, etc), XID requests do
             not have to provide and I-field.

   SOLUTION: The HNAS QLLC logic has been modified to allow for
             an XID request that is received when a response is
             expected and the request need not contain an I-field.
             In this case, HNAS will answer with a format 1 XID
             response and HNAS will assume the role of secondary
             link station.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in APPLY_INFO.

 APPLY_INFO: See APAR.

05-23-2003 - PROBLEM 2003143A

 PROBLEM_ID: 2003143A
     STATUS: CLOSED,SEE_APAR_2200039
  OPEN_DATE: 05-23-2003
 CLOSE_DATE: 07-09-2003
 SERVICE(S): GATE (LLC4)
  MANDATORY: YES
 ORIGIN/REF: 220_AUD
   PTF_TYPE: OBJ
  PREREQ(S): N/A
  OBJECT(S): MCHSTRT, MCHNRQC, XOTGTCC
  SOURCE(S): N/A

    PROBLEM: When a GATE callout operation fails the data session
             LU allocated for the call may not be released.  When
             this happens HNAS can run out of GATE data session LUs
             (these are defined by the SVC4= REMOTE operand).  The
             result is that new GATE sessions cannot be started
             The NAS7717W and NAS7715W messages with DIAG=130/X'82'
             may be issued.

DESCRIPTION: See problem

   SOLUTION: Modules corrected to release the data session LU.

 APPLY_INFO: This problem fix is shipped as an email attachment.
             The file 2003143A.STR was created by a TSO XMIT issued
             against a PDF containing the 3 corrected modules.

             1) Back up the QQQQ.HNASOBJX data set (if it has members).
                (QQQQ = your high level HNAS qualifier).
                QQQQ.HNASOBJ contains your original distribution modules.
                QQQQ.HNASOBJX contains corrected modules.

             2) To install the fix transfer 2003143A.STR to your
                system.   The file should be placed in a sequential
                data set named xxxx.AUDOBJX.  This data set should
                be allocated with RECFM = FB(3120,80),
                SPACE=(TRK,(5,5)).

             3) Issue the TSO command:
                RECEIVE INDS('xxxx.AUDOBJX')

                When prompted for restore parameters enter:
                DSN('QQQQ.HNASOBJX')
                This loads the corrected modules into QQQQ.HNASOBJX.

             4) Run the HNASMNT JOB.  This relinks HNAS with the
                corrected modules.

07-17-2003 - PROBLEM 2003134A

 PROBLEM_ID: 2003134A
     STATUS: CLOSED,SEE_APAR_2200043
  OPEN_DATE: 05-14-2003
 CLOSE_DATE: 07-17-2003
 SERVICE(S): QLLC
  MANDATORY: YES
 ORIGIN/REF: 220_POR_04-30-2003
   PTF_TYPE: (SRC) <-On FTP Server /hnas_maint/hnas220m/apars
   COREQ(S): N/A
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): VTMRCV1

    PROBLEM: QLLC session hangs after an exchange of a few
             messages.

DESCRIPTION: When the QLLC PLU sends a null FMD PIU to HNAS, an
             incorrect RECEIVE macro is issued.  If the PLU as
             done a SEND for the next FMD PIU, the HNAS RECEIVE
             effectively discards the new PIU and the session hangs.

   SOLUTION: Code modified to correct HNAS RECEIVE logic.

             Corrective logic included in distributions created
             after CLOSE_DATE.  Otherwise, apply maintenance as
             directed in APPLY_INFO.

 APPLY_INFO: The corrected module (VTMRCV1) is a VTAM dependent
             module that must be assemble using your installation's
             macro library. 

01-02-2003  - PROBLEM 2002354A

 PROBLEM_ID:  2002354A
     STATUS:  CLOSED,IMPROVED_LOGIC_IN_221/230
  OPEN_DATE:  12-20-2002
 CLOSE_DATE:  12-31-2002
 SERVICE(S):  HNAS NAS2261W, NAS2262W and NAS2263I messages.
  MANDATORY:  NO, BUT RECOMMENDED
 ORIGIN/REF:  JPM,GT2 (211)
   PTF_TYPE:  CIRCUMVENTION:CONFIG_NON-APAR
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  When HNAS receives a socket connection for a router
              that is not configured in the CDF, a recursive connect
              loop can ensue which can affect HNAS performance and
              induce unnecessary CPU load.  The systems operator is
              informed of this condition when the following message
              sequence is displayed:

              NAS2261W SERVER=ipaddr(port) SOCKID=xxxxx PCEID=xxxxx
                       NAME=lclname
              NAS2261I ACCEPT REQUEST FAILED, RC=FFFFFFFF FFFFFFFF
              NAS2262W SERVER=ipaddr(port) SOCKID=xxxxx PCEID=xxxxx
                       NAME=lclname
              NAS2262I REMOTE=ipaddr(port) NOT CONFIGURED,
                       CONNECTION REJECTED
              NAS2263I IDLCNT=xxxxx ACTCNT=xxxxx SOCLMT=xxxxx

DESCRIPTION:  This condition occurs and these messages are generated
              because HNAS does not have the control blocks it needs
              to handle the socket connection(s).

   SOLUTION:  If you intend to allow router connections for specific
              routers only, the IP address of the router must match
              the value specified for the IPADDR= operand on some
              REMOTE definition statement in the HNAS CDF.  In this
              case you should NOT specify IPADDR=DYNAMIC which allows
              any Cisco XOT router to connect to HNAS because the
              router's IP address is resolved dynamically.

              For IBM or Cisco routers, specify a TYPE=XTP|XOT REMOTE
              definition statement with the exact IP address of the
              router whose connections are failing in the HNAS CDF.

              If you will be adding Cisco routers to your network and
              do not want to specifically identify each by its IP
              address in the HNAS CDF, specify a TYPE=XOT REMOTE
              definition statement with IPADDR=DYNAMIC and a VCLMT=
              operand value large enough to handle your expected
              router connection load.  IPADDR=DYNAMIC allows the
              router IP address to be resolved dynamically so that
              the connection will not be rejected.  This will prevent
              the recursive connection loop that can affect HNAS
              performance and induce non-productive CPU overhead.

              Note that the NAS2263I message identified above is
              displayed only when a client connection is rejected
              because the number of available sockets for the
              configured router has been reached.  The ACTCNT= value
              represents the maximum available socket count for the
              router.

              If the NAS2263I message is displayed, you should
              increase the VCLMT= operand value for the active REMOTE
              definition statement (INIT=ACTIVE) or activate the idle
              REMOTE definition statement (INIT=IDLE) using the VARY
              console command.  In the latter case, the VCLMT= operand
              value from the activated REMOTE definition statement
              will be added to the ACTCNT= value and subtracted from
              the IDLCNT= value (the SCOLMT= value will remain
              unchanged).

              If the NAS2263I message is not displayed, it means that
              no REMOTE definition statement exists for the router
              that initiated the connection.  In this case, you
              must either stop HNAS and specify a REMOTE definition
              statement for the router in the CDF, reconfigure the
              router to use an available and previously unused REMOTE
              definition statement in the CDF or remove the router
              from the network.

 DOC_UPDATE:  2003-01-02 - HNAS 220 Messages and Codes AlertMsg
              NAS2261|NAS2262|NAS2263 documentation updated.

              Please refer to the revised documentation section
              for additional information.

 APPLY_INFO:  NONE.

01-16-2003  - PROBLEM 2002346A

 PROBLEM_ID:  2002346A
     STATUS:  CLOSED,IMPROVED_LOGIC_IN_221/230
  OPEN_DATE:  12-12-2002
 CLOSE_DATE:  01-10-2003
 SERVICE(S):  HNAS SYSPRINT dsname LOG FILE CONFIGURATIONS.
              (DOES NOT APPLY TO SYSOUT=* ENVIRONMENTS) 
  MANDATORY:  NO, RECOMMENDED. (SEE SOLUTION CIRCUMVENTION)
 ORIGIN/REF:  FDK_92511 (220)
   PTF_TYPE:  CIRCUMVENTION:CONFIG_NON-APAR
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  A B37 ABEND (insufficient dataset space) can occur
              when HNAS writes a record to the SYSPRINT dataset 
              and the dataset is full.

DESCRIPTION:  This condition occurs either because the space 
              allocated for the SYSPRINT dataset is too small or 
              because the PRTLMT= operand value is too high to
              prevent HNAS from writing to a full dataset.

   SOLUTION:  The problem can be circumvented by either increasing
              the SPACE= operand value for the SYSPRINT dataset or
              or supplying a BUILD PRTLMT= operand value that is 
              small enough to prevent the current SYSPRINT space 
              allocation from being exceeded.  The PRTLMT= operand 
              specifies the maximum number of records written to 
              SYSPRINT.  This value multiplied by 133 should be 
              less than the total SYSPRINT dataset space including
              all extents.

              In the next release of HNAS (221/230), this problem
              has been fixed by adding a DCB exit list (EXLST=) to
              the HNAS SYSPRINT DCB.  The exit list contains an
              entry for an ABEND exit.  Not all SYSPRINT ABENDs
              are recoverable but B37s are.  When the SYSPRINT
              dataset becomes full, the ABEND exit receives
              control.  The exit writes a message to the system
              operator then closes the SYSPRINT dataset.  If
              multiple SYSOUT DD names are present in the HNAS
              start JCL, another SYSOUT dataset (or the same one)
              can be reopened using the 'PRNT OPEN ddname'console
              subsystem command.  Normally, DISP=OLD is specified
              for the SYSOUT DD statement(s) so logging in the 
              dataset(s) restarts at the top.  This new logic 
              takes care of the problem that can occur when the
              PRTLMT= operand value is too high to prevent the 
              B37 ABEND.

 APPLY_INFO:  NONE.

12-03-2002 - PROBLEM 2002337A,  REVISED NOVEMBER 23, 2003 - SEE APAR 2200062.

 PROBLEM_ID: 2002337A
     STATUS: CLOSED_CIRCUMVENTION,IMPROVED_LOGIC_IN_221
  OPEN_DATE: 12-03-2002
 CLOSE_DATE: 01-17-2003
 SERVICE(S): HNAS Clear diagnostic byte for UNBINDs.
  MANDATORY: NO
 ORIGIN/REF: BNP_92424 (211)
   PTF_TYPE: CIRCUMVENTION:ZAP_NON-APAR
  PREREQ(S): N/A
  OBJECT(S): N/A
  SOURCE(S): N/A

    PROBLEM: When HNAS receives an UNBIND from the PLU a CLEAR
             X.25 packet is sent to terminate the call.  The
             diagnostic byte in the packet is 140 (X'8C').
             Under the same conditions NPSI clears with a
             diagnostic of 0.

             We are currently reviewing the NPSI and HNAS logic
             to determine if the UNBIND cause code of 01 (normal
             end of session) should cause a Clear diagnostic code
             of 0 while values greater than 01 should generate
             a Clear diagnostic code 140.

DESCRIPTION: See problem.

   SOLUTION: In the next release of HNAS (V2R2M1), this problem
             has been fixed by adding logic to generate a clear
             diag=0 for 'normal end of session' UNBIND Type 1
             and diag=140 for other (Type 3 and above) UNBINDs.

             In this circumvention ZAP, HNAS was modified to use
             0 as the diagnostic byte when clearing is caused by
             an UNBIND.

 APPLY_INFO: The following ZAPs circumvent the problem:


*   DECEMBER 3, 2002
*
*   APAR 211xxxx <- APAR NOT ASSIGNED FOR THIS RELEASE.
*
*   ZAP TO clear with diagnostic 0 when PLU terminates session
*   with UNBIND.
*
*   ZAP FOR V2R1M1
*   --------------
 NAME NASMAIN MCHHL0RQ  <= LLC0
 VER 0444 008C
 REP 0444 0000
 VER 04E2 008C
 REP 04E2 0000
 NAME NASMAIN MCHHL4RQ  <= LLC4
 VER 05DA 008C
 REP 05DA 0000
 VER 05F2 008C
 REP 05F2 0000
 NAME NASMAIN MCHHL5RQ  <= LLC5
 VER 072E 008C
 REP 072E 0000
 VER 07E2 008C
 REP 07E2 0000

*   DECEMBER 3, 2002
*
*   APAR 220xxxx <- APAR NOT ASSIGNED FOR THIS RELEASE.
*
*   ZAP TO clear with diagnostic 0 when PLU terminates session
*   with UNBIND.
*
*   ZAP FOR V2R2M0
*   --------------
 NAME NASMAIN MCHHL0RQ  <= LLC0
 VER 044E 008C
 REP 044E 0000
 VER 0462 008C
 REP 0462 0000
 NAME NASMAIN MCHHL4RQ  <= LLC4
 VER 05EA 008C
 REP 05EA 0000
 VER 0602 008C
 REP 0602 0000
 NAME NASMAIN MCHHL5RQ  <= LLC5
 VER 0738 008C
 REP 0738 0000
 VER 074C 008C
 REP 074C 0000  

11-26-2002  - PROBLEM 2002330A
 
 PROBLEM_ID:  2002330A
     STATUS:  CLOSED_CIRCUMVENTION,CONFIG_OPTION_IN_221/230
  OPEN_DATE:  11-26-2002
 CLOSE_DATE:  01-17-2003
 SERVICE(S):  Time delay when starting interactive GATE session
              started by a CTCP (callout).
  MANDATORY:  NO
 ORIGIN/REF:  FMP_92419 (211)
   PTF_TYPE:  CIRCUMVENTION:ZAP_NON-APAR
  PREREQ(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

    PROBLEM:  APAR 2100005 introduced a time delay between sending
              a Call Accept to a CTCP and sending a REQSESS to VTAM
              to set up the GATE data session.  The delay was 
              required for CFT call setup.

              When the CFT delay is applied to interactive GATE
              sessions users have complained about sluggish session
              setup.

DESCRIPTION:  See problem.

   SOLUTION:  In V2R2M1 HNAS will contain a configuration option 
              which will specify whether or not the session start 
              delay will be imposed.

              For users requiring a fix at the V2R1M1 or V2R2M0 
              levels a ZAP is provided (see APPLY_INFO, below).

 APPLY_INFO:  The following ZAPs circumvent the problem:


*    NOVEMBER 26, 2002
*
*    APAR 211xxxx  <- APAR NOT ASSIGNED FOR THIS RELEASE. 
*
*    ZAP TO REMOVE TIME DELAY BETWEEN SENDING CALL ACCEPT TO A GATE
*    CTCP AND SENDING REQSESS TO VTAM TO START THE DATA SESSION.
*
*    ZAP FOR V2R1M1
*    --------------
 NAME NASMAIN MCHNRQC
 VER 0632 47F0,A174
 REP 0632 58F0,A2AC


*    NOVEMBER 26, 2002
*
*    APAR 220xxxx  <- APAR NOT ASSIGNED FOR THIS RELEASE. 
*
*    ZAP TO REMOVE TIME DELAY BETWEEN SENDING CALL ACCEPT TO A GATE
*    CTCP AND SENDING REQSESS TO VTAM TO START THE DATA SESSION.
*
*    ZAP FOR V2R2M0
*    --------------
 NAME NASMAIN MCHNRQC
 VER 06FE 921C,6043,9203,6042,4100
 REP 06FE 58F0,A35E,0DEF,47F0,A1BA   

Last Update - April 7, 2010