COMM-PRO

HNAS V2R4M0 - 2006-2009
MAINTENANCE SUMMARY

(Refresh/Upgrade maintenance is currently available directly from Comm-Pro or their agents)

The individual APAR hyperlink *.ZIP files provide all of the necessary SRC (source) and OBJ (object) updates for the respective PTF.  Most APARs have  PREREQ(S) as designated in the APAR memos (multiple APAR PTF's may be required to install a particular APAR PTF).  If a product refresh or upgrade is required you will need to contact your HNAS support representative to order the appropriate edistribution.  HNAS product edistributions are provided via our ftp server and build as requested (e-mail attachment can also be provided upon special request).  We suggest that you contact your HNAS support representative to request that an FTP userid account be set-up for your organization if you haven't already done so.

HNAS V2R4M0 APAR Summary Matrix

              Please refer to the X.25 HostNAS (HNAS) Product Notices web page
              section HNAS V2R4M0 - Release Status for additional information.

sum240_2009

2009-12-14  - APAR 2400098

       APAR:  2400098  
     STATUS:  CLOSED
  OPEN_DATE:  2009-11-18
OLDCLS_DATE:  2009-12-09
   REV_DATE:  2009-12-14 - Recalled and Reissued.
 CLOSE_DATE:  2009-12-14
 SERVICE(S):  Console command and Authorization message processing
  MANDATORY:  NO
 ORIGIN/REF:  240_CSP,240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400098.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distributions with APARs 2400096, 2400094, 2400080 and
              their associated APAR chains applied.
 SUPERSEDES:  N/A

  OBJECT(S):  CNFGEXEC, CONSEXEC, CONSVARY, NASCONS, NASUTIL
  SOURCE(S):  XFBLK

     PROBLEM: This Enhancement APAR addresses the following console
              improvements:

    PROBLEM1: Customer indicates that the following message is
              confusing because it is issued continually:

              NAS9206I HNAS MAINTENANCE/USE ANNIVERSARY DATE WILL
                       EXPIRE IN 0ddd DAYS

    PROBLEM2: Customer issues a console command list (EXEC (cmdlist))
              via JCL but not all commands in list execute when one
              of the commands ends in error.

    PROBLEM3: Customer would like to disconnect an active PVC even
              if it's SLU is inactive to force the XOT PVC to enter
              PVC Setup pending state where the Router or HNAS will
              send a PVC Setup request once the retry timer expires.

DESCRIPTION1: Starting with APAR 2400095, the NAS9206I message is
              issued continually until the current date is within 45
              days of the MAINTENANCE/USE ANNIVERSARY DATE (EOMDATE)
              at which time, the message severity is changed from 'I'
              to 'W' (NAS9206W).  If the EOMDATE is not extended either
              with a new refresh distribution or via an EOMKEY, the
              EOMDATE will expire.  A new EOMDATE is required to allow
              HNAS to be used.  Some customers do not realize the
              importance of this because the NAS9206I message is
              always issued and tends to be ignored.

DESCRIPTION2: Due to the way the EXEC command list is executed, an
              error in any command in the list causes the subsequent
              commands in the list to be purged.  The rationale being
              that the commands in the list could be related and all
              depend on the successful completion of previous commands
              in the list.  Some customers specify commands that are
              unrelated and expect all to be executed regardless of
              errors in any single command in the list.

DESCRIPTION3: When the 'VARY sluname FORCE' command is issued to a PVC
              SLU and the SLU is active, the SLU is UNBOUND and the
              PVC connection is RESET (the TCP/IP socket is not
              closed).  However, if a PVC SLU is inactive but the PVC
              connection is active, it will remain active even though
              it should be closed.

   SOLUTION1: HNAS has been modified to withhold the NAS9206I messages
              until 60 days before the EOMDATE is to expire.  This
              should make the messages more significant and less
              likely to be ignored.  In addition, the message severity
              will change from 'I' to 'W', from 'W' to 'E' and then
              from 'E' to 'S' the closer the current date gets to the
              EOMDATE.

   SOLUTION2: HNAS has been modified to accept two new options within
              an inline command list or DDNAME command list.

              PURGEONERROR (the default) specifies that subsequent
              commands in a command list are to be purged if an error
              occurs for any command in the list.

              NOPURGEONERROR specifies that subsequent commands in a
              command list are to be executed even if any command ends
              in error.

              Example: EXEC (NOPURGEONERROR,cmd1,...,cmdn)

              Notes: 1) The PURGEONERROR|NOPURGEONERROR options are
                        valid for the EXEC= operand on the BUILD
                        definition statement as well as the EXEC
                        console command.

                     2) The PURGEONERROR|NOPURGEONERROR options are
                        not included in the command list but are
                        decoded and acted upon immediately when
                        parsed.

                     3) The PURGEONERROR|NOPURGEONERROR option remains
                        in effect until changed by the EXEC console
                        command.  You can display the current option
                        in effect by issuing EXEC LIST (no cmdlist).

   SOLUTION3: The 'VARY sluname FORCE' command has been modified to
              close an active PVC TCP/IP socket even when it's SLU is
              inactive.  Prior to this enhancement, the VARY command
              would have been rejected in this situation with the
              following message:

              NASC015E FUNCTION ALREADY INACTIVE, VARY COMMAND ABORTED

              Note that this message will still be issued if both the
              PVC SLU and the PVC itself are inactive.

              Note that this new logic eliminates the two step process
              of first finding the PID for the PVC socket and then
              issuing the VARY ID=pid FORCE command to close the PVC
              socket.  This new support allows customers to work with
              an sluname which is useful for installations that employ
              automated console command processes.

              PVC Setup note: Closure of the socket causes the XOT PVC
              to re-enter PVC Setup pending state which will cause the
              the PVC Setup to be sent from the appropriate initiator
              once the retry timer expires.

              Note that while testing this enhancement it was observed
              that when the VARY command was entered incorrectly, for
              example, when the sluname was entered after a VARY
              operand rather than immediately after the VARY command
              (e.g., V OFF sluname) and no left hand modifiers were
              set, the following error message was generated:

              NASC100E ID= OMITTED, REQUIRED FOR V COMMAND EXECUTION

              While it is true that when no resource name modifiers
              are specified for a command that operates on them (e.g.,
              LNM=, RNM= LUNM=) like the VARY command does, the command
              reverts to the ID= modifier.  If ID= is also omitted as
              a left hand modifier, the NASC100E message is generated.

              This can be confusing for users who are not used to using
              the ID= modifier.  For this reason, we have added text to
              NASC100E error message that, hopefully, will further
              explain why the message was issued.  The new format for
              the NASC100E message is as follows:

              NASC100E ID= AND OTHER MODIFIERS OMITTED, REQUIRED
                       FOR V COMMAND EXECUTION
              NASC100E ID= IS REQUIRED WHEN NO OTHER RESOURCE
                       IDENTIFICATION IS SPECIFIED
              NASC100E IF COMMAND OPERATES ON LNM=, RNM= OR LUNM=,
                       ENSURE THAT RESOURCE NAME
              NASC100E IS SPECIFIED BEFORE ANY COMMAND OPERANDS
                       (EXAMPLE: V LUNM=sluname OFF)

CIRCUMVENTION1: N/A

CIRCUMVENTION2: N/A

CIRCUMVENTION3: Use the DVC command to display the PID for the PVC
                socket then issue VARY ID=pid FORCE to close the PVC
                socket.

 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).

2009-09-16  - APAR 2400097  (was problem 2009204A)

       APAR:  2400097  
     STATUS:  CLOSED
  OPEN_DATE:  2009-07-23
 CLOSE_DATE:  2009-09-16
 SERVICE(S):  DTF
  MANDATORY:  RECOMMENDED if Datafono pseudo leased resources used.
 ORIGIN/REF:  240_ATC
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400097.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2009-08-13 with refresh APAR
              2400095 and correction APAR 2400096 applied.
              Refresh required if you are below the 2400095 APAR
              level.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHL0RQ , MCHTMR
  SOURCE(S):  N/A

    PROBLEM:  HALT AT LOC xxxxxxxx IN MCHTMR  : INV LU 3

DESCRIPTION:  There is an error when processing an early session end for
              a Datafono pseudo leased resource genned with the DATAF
              and RETPIU options.  The error occurs when the PLU sends
              an 'M' message at the same time that the remote clears the
              Datafono call.  The alert "NAS5722W DATAFONO SESSION ENDED
              ON LEASED LU lu-name (UNEXP'D CLR RECVD)
              CAUSE/DIAG=(00/00) DIAGX=0000" is also present.

   SOLUTION:  End of session logic corrected.

              If the PLU attempts to send data after the PIU associated
              with the RETPIU Datafono option has been sent to the PLU
              (this should not occur) then the VTAM session is ended
              (ACB closed) and the following alert is issued:

              NAS3799I LU lu-name ENDING   SESSION ON MCH mch-nm HNAS
              CAUSE/DIAG=000/223 (00/DF) DIAGX=0009

              An enhancement part of this APAR causes HNAS to send the 
              following alert when the "Please Wait ..." message is sent
              to a remote (EMSGE Datafono option):

              NAS5726W EMSGE MESSAGE SENT TO LU lu-name (16 SEC PLU
              DELAY)

              This alert indicates that HNAS has been waiting 16 seconds
              for a response from the PLU (the PLU is very busy).  No 
              other action is taken (the EMSGE timer is restarted).

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).

2009-09-10  - APAR 2400096
 
       APAR:  2400096
     STATUS:  CLOSED
  OPEN_DATE:  2009-08-27
 CLOSE_DATE:  2009-09-10
 SERVICE(S):  EOMKEY
  MANDATORY:  YES if an EOMKEY containing expired EOMDATE date is used.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400096.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distributions with APARs 2400095
              their associated APAR chains applied.
 SUPERSEDES:  N/A

  OBJECT(S):  CONSMMEM, NASUTIL
  SOURCE(S):  NASMAIN,  XFNASWA

   OVERVIEW:  EOMKEY correction for APAR 2400095.

    PROBLEM:  Invocation of EOMKEY containing an already expired
              EOMDATE causes 45 day grace period to be ignored.

DESCRIPTION:  If an EOMKEY is provided to extend an EOMDATE and
              the new EOMDATE is itself already expired the grace
              period warning alert messages (NAS9206i) operation
              will be bypassed and customer specific severe alert
              messages and services actions will occur immediately.

              This occurs because the EOMDATE update logic fails to
              initialize the ABEND grace period.  This problem does
              not occur when the EOMKEY contains an EOMDATE that is
              not expired, that is, is beyond the current date
              (TODAYSDATE).

   SOLUTION:  HNAS has been modified to initialize the grace period
              correctly when an EOMKEY contains an already expired
              EOMDATE.

              General Notes for APAR 2400096:

              1) The ability to set an older EOMDATE via an EOMKEY
                 is normally only used to simulate an EOMDATE
                 expiration during testing as directed by support
                 personnel (a parameter is available for testing).

                 Users with multiple EOMKEYs (saved for historical
                 reasons) should make sure that they are using the
                 current EOMKEY in their production environment.
                 This will ensure that you do not apply an expired
                 EOMKEY to a non-expired EOMDATE system.

              2) Before putting a new EOMKEY in operation, you should
                 test it using the HNAS FASTRUN execution.  This can
                 be done even while your production HNAS is running.
                 This will ensure that there are no surprises when
                 the EOMKEY is applied against your production HNAS.

                 Specify PARM='FASTRUN,EOMKEY=dd...dd'

              3) Cosmetic fix.

                 Effective with APAR 2400095, DNAS display line 9
                 erroneously displays '000D' for the AUTH= value
                 for a permanent distribution when it should simply
                 display '000'.  Although the '000' indicates a
                 permanent distribution and the trailing 'D' can be
                 ignored, the 'D' has been removed by this APAR thus
                 restoring the AUTH= display to it's previous
                 incarnation.

                 AUTH=000D SHIPID=0000000000199999 <- 2400095 display

                 AUTH=000  SHIPID=0000000000199999 <- 2400096 display

CIRCUMVENTION: Request an EOMKEY with an unexpired EOMDATE.

 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).

2009-08-13  - APAR 2400095

       APAR:  2400095_R  
     STATUS:  CLOSED
  OPEN_DATE:  2009-07-01
   REV_DATE:  2009-08-13 - Recalled and Reissued.
 CLOSE_DATE:  2009-08-13
 SERVICE(S):  EOMDATE Authorization Processing
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR also includes enhancements
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

   OVERVIEW:  HNAS EOMDATE extension processing.

    PROBLEM:  A way is needed to extend the HNAS MAINTENANCE/USE
              anniversary date (EOMDATE) without having to install
              a new refresh distribution.

DESCRIPTION:  Users cannot always install refresh edistributions
              to extend an about to expire EOMDATE period due to
              scheduling or 'no change' periods in their host
              which could lead to HNAS generating warning|severe
              alert messages and potential service or support
              interruptions.

              Prepaid Annual Maintenance/Use fees have always been
              required to run the HNAS product and receive product
              maintenance and support.  The EOMDATE denotes the
              End of Maintenance/Use date for the current prepaid
              period.  This date is used as follows:

              - DNAS display provides the date in the following
                format and is used by the user and HNAS product
                support services to validate the current license
                use period:

                MAINTENANCE/USE ANNIVERSARY DATE IS 2009/12/31

              - HNAS program will generate Information and Warning
                alert messages (NAS9206I and NAS9206W) based upon
                preset intervals prior to the EOMDATE expiration.

              - HNAS program can generate Severe alert messages
                (NAS9206S) and potential service interruptions
                based upon preset intervals once the EOMDATE has
                expired.

              These messages are intended to provide reminders that
              the HNAS MAINTENANCE/USE anniversary date is nearing
              expiration or has already expired. These messages are
              detailed in the HNAS Messages and Codes documentation.

              It is important that the prepaid HNAS Maintenance/Use
              period is renewed in a timely manner to avoid the
              Sever messages or potential service interruption.

   SOLUTION:  HNAS has been modified to allow the EOMDATE to be
              updated 'on the fly' using the new MMEM EOMKEY=dd...dd
              console command and/or the new HNAS start parameter
              PARM=(...,EOMKEY=dd...dd,...).  The console command
              is provided so that HNAS does not have to be stopped
              and restarted in order to extend the EOMDATE.  The
              start parameter is provided so that the console
              command does not have to be issued each time HNAS is
              stopped and restarted.  The console command is a
              temporary EOMDATE update.  The start parameter makes
              the new EOMDATE permanent so long as the EOMKEY start
              parameter is specified.  The EOMDATE will revert to
              it's original distribution value if the EOMKEY start
              parameter is not specified or the console command is
              not issued.

              When a new EOMDATE is extended using an EOMKEY, the
              DNAS display will reflect this using an asterisk (*)
              after the date when the new EOMDATE record is written.
              For example:

              MAINTENANCE/USE ANNIVERSARY DATE IS 2010/12/31*

              Notes: 1) The EOMKEY dd...dd string must be exactly
                        16 decimal digits in length.

                     2) The dd...dd string is an encrypted string
                        provided by Comm-Pro for a each user.  The
                        EOMKEY string contains a new EOMDATE and the
                        CUSTID for the customer so that is unique for
                        each user.  A special file is supplied as an
                        email attachment which contains the EOMKEY as
                        well as other identifying information.  The
                        given EOMKEY will then have to be copied and
                        pasted as a MMEM console command argument or
                        a start parameter.  The new EOMKEY file has
                        the following format:

                        EOMKEY=5962850727872317
                        HNAS EOMKEY CREATED AT 17:32:31 ON 2009/07/15
                        SHIPID=0000000000199999
                        CUSTID=SFD_99999
                        CUSTINFO=COMM-PRO ASSOCIATES
                        MAINTENANCE/USE ANNIVERSARY DATE IS 2011/01/31

                     3) If an invalid dd...dd string is specified,
                        HNAS will issue an error message but will
                        continue running.

               As part of this APAR, the following new error messages
               are provided:

               NAS9203W HNAS EOMKEY IS INVALID, CUSTID DOES NOT
                        MATCH, IGNORED
               NAS9203W KEYCID=99990 HNASCID=99999

               NAS9203W HNAS EOMKEY IS INVALID, EOMDATE IS TOO
                        LOW, IGNORED
               NAS9203W KEYEOM=20101130 HNASEOM=20101231

               The messages above are issued if the supplied EOMKEY
               contains a CUSTID value in error or an EOMDATE that
               is less than the EOMDATE currently in effect (shown
               in the DNAS MAINTENANCE/USE ANNIVERSARY DATE display).

               Content in the NAS9206S EOMDATE expired messages was
               modified to accommodate the EOMKEY logic.  Please
               refer to the alert messages section for additional
               information.

CIRCUMVENTION: Install a product refresh distribution to extend
               the EOMDATE.

 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).

2009-06-16  - APAR 2400094

       APAR:  2400094_E  
     STATUS:  CLOSED
  OPEN_DATE:  2009-05-01
 CLOSE_DATE:  2009-06-16
 SERVICE(S):  Startup Parameter processing
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400094.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distributions with APARs 2400090, 2400089, 2400083 and
              their associated APAR chains applied.
 SUPERSEDES:  N/A

  OBJECT(S):  CNFGEXEC, CNFGSCHD, CONSEXEC, CONSSCHD
  SOURCE(S):  NASMAIN,  XFNASWA,  XFPCE

   OVERVIEW:  The z/OS JCL scanner enforces a limit of 100 characters
              within the PARM= operand on the EXEC statement.

    PROBLEM:  The EXEC start parameter string limit of 100 characters
              can be too short.

DESCRIPTION:  Because of the z/OS JCL limit of 100 characters for the
              EXEC PARM= operand, you are limited as to how many start
              parameters you can supply in the PARM= operand.  For many
              HNAS start parameters, there is an equivalent console
              command which allows you to specify these commands in
              the EXEC= (or CONCMDQ= operand) on the BUILD definition
              statement so that the desired functions can be started
              after the CDF is scanned instead of when HNAS processes
              it's start parameters.  This is a good workaround for the
              100 character limit but does not address the problem when
              a start parameter does not have an equivalent console
              command.

   SOLUTION:  In order to allow ALL start parameters to be given when
              HNAS is started, HNAS has been modified to accept a new
              start parameter: PARMFILE=pfddname.  This new parameter
              is specified s follows:

              PARM='...,PARMFILE=pfddname,...'

              pfddname identifies a DDNAME in the HNAS start JCL that
              represents a sequential file containing a list of other
              start parameters.

              Comments are allowed in the pfddname file and must start
              with an asterisk (*) or semi-colon (;) in record column
              one (1).  Comments can also appear on a parameter record
              but must start with a semi-colon after the parameter.
              Each non-comment record in the pfddname file has the
              following format:

              parm ; comment

              Multiple parameters can be specified on a single record
              as follows:

              parm1,parm2,...,parmn ; comment

              Notes: 1) Leading and trailing blanks are removed from
                        each record before the values are processed.

                     2) An embedded PARMFILE= parameter in the
                        pfddname file will signal the end of data
                        in the file.  Any records that follow the
                        embedded PARMFILE= parameter will be ignored
                        and the new pfddname file will be processed.

                        An embedded PARMFILE= parameter allows you
                        to chain parameter files.  This can also be
                        done by specifying consecutive PARMFILE=
                        parameters in the PARM= operand as follows:

                        PARM='..,PARMFILE=pfddnm1,PARMFILE=pfddnm2,..'

                     3) When a PARMFILE= parameter is encountered in
                        the PARM= operand, the parameters in the
                        pfddname file are processed before any
                        subsequent parameters in the PARM= operand.
                        After the pfddname file is processed, HNAS
                        will process the remaining parameters in the
                        PARM= operand.

EXAMPLE: Assume the HNAS start JCL appears as follows:

//LDNAS240 JOB (),COMMPRO,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=&SYSUID
//*ROUTE XEQ   MVSESA1
//LOADNAS EXEC PGM=HNAS,REGION=0M,
// PARM='APFMEMSP=(230),PARMFILE=PFILE001,PARMFILE=PFILE002,GENNWDF'
//STEPLIB  DD DSN=COMM1.V2R4M0.HNASLOAD,DISP=SHR
//VTAMLIB  DD DSN=SYS1.VTAMLIB,DISP=SHR           <- USSTAB
//*        DD DSN=COMM1.V2R4M0.HNASLOAD,DISP=SHR  <- CUSTOM USSTABS
//*NETVLIB DD DSN=NETVIEW.CNMLINK,DISP=SHR        <- CNMNETV
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//AUTH     DD DSN=COMM1.V2R4M0.HNASMAC(NASAUTH),DISP=SHR
//PFILE001 DD DSN=COMM1.V2R4M0.HNASMAC(PFILE001),DISP=SHR
//PFILE002 DD DSN=COMM1.V2R4M0.HNASMAC(PFILE002),DISP=SHR
//NEWDEFN  DD DSN=COMM1.V2R4M0.NEWCNFG(Z240NEW),DISP=OLD
//CONFIG   DD DSN=COMM1.V2R4M0.OLDCNFG(Z240OLD),DISP=SHR

PFILE001 and PFILE002 identify 2 parameter files.  These files are
listed below:

For PFILE001:

* PFILE001
* THIS PARMFILE CONTAINS ADDITIONAL PARMS THAT ARE ADDED
* TO THOSE IN THE EXEC PARM= OPERAND.  SPECIFY AS
* PARM='...,PARMFILE=PFILENAM,...'
*
RMTCONS PRIV , TRCCONS                  ; CONSOLE OPTIONS
TRCSUBR                                 ; TRACE SUBROUTINE CALLS
TRCWTO                                  ; TRACE WTOS
SHOWCMSG                                ; COMPRESS WTOS

For PFILE002:

* PFILE002
* THIS PARMFILE CONTAINS ADDITIONAL PARMS THAT ARE ADDED
* TO THOSE IN THE EXEC PARM= OPERAND.  SPECIFY AS
* PARM='...,PARMFILE=PFILENAM,...'
*
TRCDBK , TRCBST                         ; TRACE DATA BLOCK AND BINARY
STATS ON                                ; COLLECT STATS
TRCDISP,TRCDATA,TRCBFR,TRCIO            ; TRACE PCE EVENTS
SVRSTRT                                 ; ALLOW STACK RESTART

After processing the PARM= operand with the 2 parameter files, the
result is a PARM= parameter string that is logically equivalent to
the following:

// PARM='APFMEMSP=(230),RMTCONS PRIV,TRCCONS,TRCSUBR,TRCWTO,SHOWCMSG,TR*
//             CDBK,TRCBST,STATS ON,TRCDISP,TRCDATA,TRCBFR,TRCIO,SVRSTR*
//             T,GENNWDF'

The only difference is that the PARM= value above could not have been
specified in JCL because it exceeds the 100 character limit and thus
would have generated a JCL error.

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).

2009-05-28  - APAR 2400093  (was unpublished problem 2009138A)

       APAR:  2400093  
     STATUS:  CLOSED
  OPEN_DATE:  2009-05-18
 CLOSE_DATE:  2009-05-28
 SERVICE(S):  TCPIP
  MANDATORY:  REQUIRED to prevent potential ABEND.
 ORIGIN/REF:  240_atc
     CPTECH:  SFD/prt
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400093.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2009-03-13
              With APARs: 2400089 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  XOTXMTC
  SOURCE(S):  NASTCP

   OVERVIEW:  TCP/IP Select timeout processing.

    PROBLEM:  HALT AT LOC xxxxxxxx IN NASTCP  : TCPIP TRANSMIT FAILURE

DESCRIPTION:  The HALT is preceded by:

              NAS2252E CLIENT=172.016.101.112(29421) NAME=xxxxxx SELECT
              REQUEST INTERRUPT LOST, SOCKET MUST BE CLOSED

              An error in HNAS close processing logic leads to a
              TCPXMT call with an invalid PCE address of zero.

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).

2009-04-30  - APAR 2400092

       APAR:  2400092  
     STATUS:  CLOSED
  OPEN_DATE:  2009-04-30
 CLOSE_DATE:  2009-04-30
 SERVICE(S):  HNAS end-of-day timer processing
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400092.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400089 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  NASUTIL
  SOURCE(S):  N/A

   OVERVIEW:  HNAS end-of-day timer processing.

    PROBLEM:  NAS0910I end-of-day rollover message not generated.

DESCRIPTION:  Due to logic added by APAR 2400089, HNAS end-of-day
              processing is not executed.  This prevents HNAS
              PULSE from being taken and the following message
              from being generated:

              NAS0910I 3 BELLS AND ALL IS WELL AT 00:00:00 ON ...

   SOLUTION:  Error introduced by APAR 2400089 has been corrected.

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).

2009-04-30  - APAR 2400091  (was problem 2009119A)

       APAR:  2400091
     STATUS:  CLOSED
  OPEN_DATE:  2009-04-29
 CLOSE_DATE:  2009-04-30
 SERVICE(S):  MRMT applid update processing
  MANDATORY:  YES if you modify the SVC0|5 applid value
 ORIGIN/REF:  240_NBK
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400091.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400084 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSMRMT
  SOURCE(S):  N/A

   OVERVIEW:  MRMT processing.

    PROBLEM:  SLU will not reconnect to VTAM application after the
              SVC0|5 applid is changed using MRMT command to change
              the PLU assignment.

DESCRIPTION:  Due to an error in the setting of the applid field
              (LUSVCAID) in the SLU control block (LUB), the SLU
              status byte (LUSTAT) is overlaid making the SLU
              appear offline.  DLU command shows OFLN status when
              it should show IDLE.

              The result of this overlay is that the SLU ACB OPEN
              routine will not issue an OPEN macro for the SLU thus
              preventing any further communication with VTAM.  The
              SLU becomes unusable.

              The MRMT syntax causing the problem is as follows:

              MRMT SVC5=sluname/{dteaddr}I{applid}...

              Specifically, the customer entered the following
              command to change the applid from 0 to 5 for PAD SLU
              A04TM900 to switch assignment to a different PLU.

              MRMT RNM=L015 SVC5=A04TM900/I5

   SOLUTION:  The MRMT console command processor has been modified
              to prevent the LUSTAT field from being overlaid when
              an applid change takes place.

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).

2009-03-30  - APAR 2400090  (was problem 2009075A)

       APAR:  2400090  
 
     STATUS:  CLOSED
  OPEN_DATE:  2009-03-16
 CLOSE_DATE:  2009-03-30
 SERVICE(S):  Dataset Error Recovery Processing (including PRTSWLST
              SYSPRINT switch processing).
  MANDATORY:  YES
 ORIGIN/REF:  240_POR
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400090.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400089 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGEXEC, CNFGPRSW, CNFGSCHD, CNFGTRTR,
              CONSEXEC, CONSPRNT, CONSSCHD, CONSTRTR,
              NASCNFG,  NASPRNT,  NASUTIL
  SOURCE(S):  XFBLK,    XFCNFGWA

   OVERVIEW:  Problems related to how HNAS handles dataset (DCB) 
              ERP processing.

    PROBLEM:  HNAS ABENDs with 0C4-10 immediately after a recoverable
              B37-04 ABEND occurs for a full SYSPRINT dataset.

DESCRIPTION:  The recoverable B37-04 ABEND is supposed to force a
              SYSPRINT switch to occur via the PRTSWLST= configuration
              operand for static (DASD) datasets.

              Due to an error in all HNAS DCB ABEND error processors
              (not just those related to SYSPRINT datasets), HNAS
              erroneously issues a CLOSE macro in the ABEND processors
              which results in a 0C4-xx ABEND after the original ABEND
              (normally a B37-04) occurs.  ABEND exit routines are
              invoked using a DCB exit list (the EXLST= operand when
              the DCB is opened).  The IBM Data Management Macro guide
              specifically states that a DCB ABEND exit must not issue
              any data management macro (for example, CLOSE) as part
              of Error Recovery Processing.  This piece of information
              was inadvertently missed in the original DCB ABEND exit
              implementation.

   SOLUTION:  All HNAS DCB ABEND exit routines have been modified to
              NOT issue any data management macro but instead set a
              flag that will be interrogated by 'mainline' logic
              which will, in turn, issue the required CLOSE macro.
              This will prevent the 0C4-xx ABEND from occurring
              after the ABEND exit relinquishes control and mainline
              code takes over.  Specifically, this will allow SYSPRINT
              switching within the PRTSWLST= operand to operate as
              documented.

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).

2009-03-13  - APAR 2400089

       APAR:  2400089  
     STATUS:  CLOSED
  OPEN_DATE:  2009-02-25
REVISE_DATE:  2009-03-12
 CLOSE_DATE:  2009-03-13
 SERVICE(S):  General Maintenance for HNAS Authorization/Anniversary
              EOM Date processing, Alarm logging and presentation.
 ORIGIN/REF:  240_cpt
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  REFRESH (REQUIRED)
    PTF_LOC:  Contact Support Services for Refresh E-distribution.
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  CNFGALMT, NASPRNT, NASUTIL, OSUT1
  SOURCE(S):  NASMAIN,  NASTCP,  XFNASWA, XFWTO

     SUMMARY: This APAR contains a collection of changes identified
              by Problem# (#=1|2|3) addressing various issues:

    PROBLEM1: Logic changes to address HNAS End of Maintenance/Use
              Anniversary Date (EOMDATE) validation processing.

DESCRIPTION1: See Problem.

   SOULTION1: HNAS authorization check processing has been modified
              to validate the End of Maintenance/Use Anniversary Date
              (EOMDATE) which heretofore was displayed for information
              only using the DNAS command.

                 MAINTENANCE/USE ANNIVERSARY DATE IS yyyy/mm/dd

              For permanent users (AUTH=000 in the DNAS display),
              runtime code has been modified to accommodate this
              change which will now perform End of Maintenance/Use
              validation as part of authorization check processing
              based on EOMDATE=yyyy/mm/dd.  This date reflects the
              Maintenance/Use license anniversary date that was
              in effect when HNAS was installed or refreshed.
              EOMDATE validation is intended to provide a 'heads up'
              notification as the HNAS Maintenance/Use license
              approaches it's anniversary date.

              HNAS will now interrogate the EOMDATE everyday at noon
              and display the following messages based on how the
              EOMDATE relates to the current date, that is, today's
              date (TODAYSDATE).

              If TODAYSDATE+45 < EOMDATE

                 NAS9206I HNAS MAINTENANCE/USE ANNIVERSARY DATE WILL
                          EXPIRE IN xxxx DAYS

              If TODAYSDATE < EOMDATE <= TODAYSDATE+45

                 NAS9206W HNAS MAINTENANCE/USE ANNIVERSARY DATE WILL
                          EXPIRE IN xxxx DAYS

                 Note that the message severity has been changed from
                 I (Informational) to W (Warning) when EOMDATE is
                 within 45 days of TODAYSDATE.

              If TODAYSDATE >= EOMDATE

                 NAS9206E HNAS MAINTENANCE/USE ANNIVERSARY DATE
                          EXPIRED xxxx DAYS AGO

              In addition to the EOMDATE messages described above,
              the following authorization message has been changed.

              From: NAS9206I HNAS AUTHORIZATION FILE ALLOWS DATAFONO
                             SUPPORT

              To:   NAS9220I HNAS AUTHORIZATION FILE ALLOWS DATAFONO
                             SUPPORT

              Additional information on this new authorization
              processing is provided in the HNAS documentation.

CIRCUMVENTION1: Contact COMM-PRO for a refresh distribution.

    PROBLEM2: Alarm logging table does not include all runtime
              alarms.

DESCRIPTION2: Because the alarm logging table is allocated after
              the CDF scan completes, a number of runtime alarms
              (like NAS92xxs AUTH alarms) are not logged.

   SOLUTION2: HNAS has been modified to allocate the alarm logging
              table immediately after it starts with a default
              entry limit of 512.  The limit, which was previously
              specified in the CDF as the ninth (last) suboperand
              of the ALRMLMTS= operand, has been retired.  If a
              value is specified, the following configuration alert
              message is generated:

              NAS1101D BUILD ALRMLMTS LOGGING TABLE LIMIT PARAMETER
              NAS1101D HAS BEEN RETIRED, 0512 ALWAYS USED

              Note: Prior to this APAR, a user could specify a value
                    of zero (0) for the alarm logging table limit
                    which would prevent the table from being created.
                    Since the alarm logging table is an important
                    component for debugging problems, this change
                    means that the table will ALWAYS be generated.

CIRCUMVENTION2: N/A

    PROBLEM3: Alarm logging table counts can be in error for some
              alarm messages.

DESCRIPTION3: Because of an error in the processing of some multiple
              line alarms (NAS2030I for example), the alarm counts
              are not correct.  This has to do with how the HNAS
              WTO service routine (XFWTO) processes the WTO.

   SOLUTION3: The XFWTO macro and it's service routine have been
              fixed to process multi-line WTOs correctly so that
              the alarm logging table reflects the proper alarm
              count when displayed using the ALARM LOG=? command.

CIRCUMVENTION3: N/A

 APPLY_INFO:  N/A

2009-02-23  - APAR 2400088  (was unpublished problem 2009049B)

       APAR:  2400088   
     STATUS:  CLOSED
  OPEN_DATE:  2009-02-17
 CLOSE_DATE:  2009-02-23
 SERVICE(S):  Datafono
  MANDATORY:  RECOMMENDED if Datafono
 ORIGIN/REF:  240_cgs
     CPTECH:  PRT
  PTF_CLASS:  STANDARD APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400088.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-04-23
              With APAR: 2400074 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHL0RQ
  SOURCE(S):  N/A

    PROBLEM:  Datafono (DTF) session ends after alert 'NAS5724W LU
              lu-nm DID NOT RECEIVE 'M' MSG SYNC RESP FROM REMOTE'

DESCRIPTION:  Customer PLU is sending a multiple element RU chain
              containing a DTF 'M' message.  The second (and last)
              RU chain element requires a second HNAS buffer because
              the size of FIC RU matched the X25 packet size.
              The buffer is not allocated because HNAS is already
              running the DTF M message D-- response timer (error).
              Since the X25 M-bit chain does not complete, there is
              no D-- response from the remote and the session fails.

   SOLUTION:  Logic for processing DTF FIC RU corrected so that an
              RU chain for a DTF 'M' message is sent correctly.

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).

2009-02-10  - APAR 2400087  (was problem 2009300A)

       APAR:  2400087  
     STATUS:  CLOSED
  OPEN_DATE:  2008-10-26
 CLOSE_DATE:  2009-02-10
 SERVICE(S):  DATAFONO
  MANDATORY:  RECOMMENDED if Datafono resources 
 ORIGIN/REF:  240_ATC
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400087.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-12-12
              With APAR: 2400084 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  VCCLEAR
  SOURCE(S):  N/A

    PROBLEM:  Leased Datafono session ending with NAS3799I (ACB closed)
              instead of NAS5721I (leased session end, ACB left open).

DESCRIPTION:  This condition can occur if the remote sends a Clear to
              HNAS when the LU is not in "response & disconnect" state
              which indicates the clear is expected.

              Customer had the RETPIU option coded which is supposed to
              flush the PLU output when an unexpected clear is received.
              The output was not flushed.  This is because the code was
              incorrectly) written to only test RETPIU if IMS was also
              coded.

   SOLUTION:  HNAS Clear logic corrected so that RETPIU option does not
              require the IMS option.

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).

2009-02-07  - APAR 2400086

       APAR:  2400086_I  
     STATUS:  CLOSED
  OPEN_DATE:  2009-01-23
REVISE_DATE:  2009-mm-dd
 CLOSE_DATE:  2009-02-05
 SERVICE(S):  HNAS Authorization Processing
  MANDATORY:  N/A
 ORIGIN/REF:  240_cbs
     CPTECH:  SFD
  PTF_CLASS:  INTERNAL-APAR
   PTF_TYPE:  REFRESH (user refresh not required)
    PTF_LOC:  N/A
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  NASUTIL
  SOURCE(S):  N/A

    PROBLEM:  Internal (non-user) logic changes to address HNAS 
              date authorization validation processing issues.

DESCRIPTION:  See Problem.

   SOLUTION:  Runtime code modified to accommodate this change
              which will now perform additional date validation
              of the authorization files.

CIRCUMVENTION: N/A

 APPLY_INFO:  N/A

sum240_2008

2008-12-23  - APAR 2400085  (was unpublished problem 2008343A)

       APAR:  2400085_R  
     STATUS:  CLOSED
  OPEN_DATE:  2008-12-08
REVISE_DATE:  2008-12-23 SHIPJOB change, does not affect distribution.
 CLOSE_DATE:  2008-12-20
 SERVICE(S):  HNAS Trial Period Expiration Shutdown Processing
  MANDATORY:  N/A
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  UTILITY-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  N/A - Does not affect existing customers.
   COREQ(S):  N/A
  PREREQ(S):  N/A
  OBJECT(S):  NASUTIL
  SOURCE(S):  NASMAIN, XFNASWA


    PROBLEM:  HNAS continues to run after trial period expires as
              long as the product isn't restarted.

DESCRIPTION:  Effective with APAR 2400085 for trail distributions only,
              when the DNAS command output shows a 16-digit SHIPID=
              field that starts with a 1 (1xxxxxxxxxxxxxxx) and a
              non-zero AUTH=value, it indicates that HNAS will ABEND
              when the trial NASAUTH file expires. Conversely, if the
              SHIPID= field is not 16 digits in length, HNAS will
              continue to run when the trial NASAUTH file expires but
              will not be allowed to restart if it is shutdown.

              The HNAS trial product was initially designed to not
              allow the product to be restarted or activated after the
              trial expiration date.  There are now some organizations
              that require the product to shutdown when the trial
              expires.

   SOLUTION:  SHIPJOB and runtime code modified to provide new option.

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).

2008-12-12  - APAR 2400084  (was problem 2008241A)

       APAR:  2400084_E  
     STATUS:  CLOSED
  OPEN_DATE:  2008-08-28
 CLOSE_DATE:  2008-12-12
 SERVICE(S):  CNFG/VTAM
  MANDATORY:  YES (if GENERIC resources used)
 ORIGIN/REF:  240_BA2
     CPTECH:  SFD/prt
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400084.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-11-26
              with APAR: 2400083 applied.
 SUPERSEDES:  N/A

  OBJECT(S):  CNFGSVC0 , CNFGSVC5 , CONSDRMT , CONSMRMT , MCHNRQC ,
              MCHSVCI  , NASCNFG  , VCCLEAR  , XOTBXM   , XOTRCV  ,
              XOTXMTC
  SOURCE(S):  VTMSND1  , VTMUT1   , XFNASWA

DESCRIPTION:  See PROBLEM

    PROBLEM:  Customer would like HNAS APPL LUs to be associated
              with generic VTAM resource names so the PLU can use
              a generic name when acquiring an HNAS LU (to trigger
              an X25 callout).

   SOLUTION:  SVC0= and SVC5= string processors have been modified
              to allow the specification of a GENERIC name in
              addition to the HNAS APPL SLU name:

              e.g. SVC0=(..,LU001+GENNM/...)

              The optional generic name (GENNM above) will be sent
              to VTAM via (SETLOGON OPTCD=GNAMEADD) after the ACB
              associated with the HNAS APPL LU LU001 is opened.
              This allows VTAM to acquire the LU001 using the
              GENNM generic name.

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).

2008-11-26  - APAR 2400083  (was unpublished problem 2008323B)

       APAR:  2400083  
     STATUS:  CLOSED
  OPEN_DATE:  2008-11-18
 CLOSE_DATE:  2008-11-26
 SERVICE(S):  TCPIP stack deactivation and SVRSTRT processing.
  MANDATORY:  YES
 ORIGIN/REF:  240_csp, 240_cpt
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400083.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400081 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGTPNM, NASCNFG, NASUTIL
  SOURCE(S):  NASTCP,   XFBLK,   XFNASWA,  XFPCE,  XFXTRN

   OVERVIEW:  Problems related to how HNAS handles the SVRSTRT
              start parameter when the TCPIP stack is deactivated.

    PROBLEM1: The following message can be generated when the
              TCPIP stack is deactivated:

              NAS7720W BRN1 CALL OUT, CAN'T CALL CALLED
              ADDR=F311022081263127 CALLING ADDR=C311022081040000

DESCRIPTION1: The above alert indicates that unmapable addresses were
              used or that a PCE could not be found for a callout
              operation.

              When the SVRSTRT option is not in effect (the default),
              HNAS remains active after the stack is taken down when
              it should have been shutdown.  The message is generated
              because HNAS will not reconnect with the stack even
              though VTAM sessions are still allowed to come active.

              The following TCPIP alerts are also present:

              NAS2401W CLIENT=169.165.250.144(01656) SOCKID=0001
              PCEID=0009 NAME=BR1XOT
              NAS2401W RECEIVE REQUEST FAILED, RC=FFFFFFFF 00000005
              (00005)
              **** RECEIVE ended with I/O errors.

              NAS2401W CLIENT=169.165.250.144(01657) SOCKID=0002
              PCEID=000A NAME=BR1XOT
              NAS2401W RECEIVE REQUEST FAILED, RC=FFFFFFFF 0000040C
              (01036)
              **** RECEIVE ended because stack was down.

              NAS2102E TCPIP SEVER INDICATED, PATHID=0001
              TCPNAME=RCCTCP11
              **** Stack down.

              Note: Inbound calls will also fail (calls cleared)
                    under this scenario because the HNAS HOME
                    server component remains down.

   SOLUTION1: When the SVRSTRT option is not specified and the stack
              is taken down, HNAS has been modified to shutdown as
              the documentation specifies.  This will require HNAS
              to be restarted when the stack is restarted.

CIRCUMVENTION1: Specify the SVRSTRT option so that HNAS will monitor
                the stack for reactivation which will prevent the
                callouts and callins from failing.

    PROBLEM2: When the SVRSTRT option is omitted and multiple stacks
              are defined to HNAS, connections to an active stack can
              hang if one stack is stopped.

DESCRIPTION2: When SVRSTRT is omitted and only one stack is defined
              to HNAS, HNAS should shutdown (see problem 1).  Due to
              a logic error, HNAS remains active but will not allow
              the stopped stack to restart.  In addition, the SVRSTRT
              logic erroneously prevents other stacks from continuing
              operation.  This causes the hang condition.

   SOLUTION2: HNAS has been modified to force the SVRSTRT option
              when multiple stacks are specified.  This will ensure
              that an active stack will continue to communicate with
              HNAS if another stack is taken down.  In addition, it
              will allow the deactivated stack to come active again.
              The following new configuration message is generated
              in this case.

              NAS1211D MULTIPLE TCPNAME VALUES SPECIFIED,
                       SVRSTRT OPTION FORCED

CIRCUMVENTION2: N/A

              Note: These 2 problems were introduced into HNAS when
                    multiple server support was added in February of
                    2002.  During our testing of the multiple server
                    support, the SVRSTRT option was active and so HNAS
                    recovered as it was supposed to when one stack
                    was taken down.  Apparently, the same tests were
                    not performed with the SVRSTRT option omitted nor
                    did any user report a problem with this option
                    until November 18, 2008.

                    We believe that this problem is unusual because
                    many customers run with the SVRSTRT option or
                    manually shutdown HNAS whenever the stack is
                    taken down which will avoid the problem.

 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).

2008-07-07  - APAR 2400082  (was unpublished problem 2008188A)

       APAR:  2400082  
     STATUS:  CLOSED
  OPEN_DATE:  2008-07-05
 CLOSE_DATE:  2008-07-07
 SERVICE(S):  Configuration processing
  MANDATORY:  YES if FASTRUN is used
 ORIGIN/REF:  240_NBK
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400082.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400080 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSDNWD, NASCNFG
  SOURCE(S):  XFCNFGWA

    PROBLEM:  Customer encounters 0C4-10 ABEND during HNAS FASTRUN 
              processing after upgrading to HNAS maintenance level
              2400080.

DESCRIPTION:  Due to an error introduced by APAR 2400080, FASTRUN 
              processing ABENDs when the NAS1391I MXT override 
              messages are being generated. This occurs because the 
              wrong internal operand indices were assembled for APAR 
              2400080 which are different than those assembled in 
              the MXT override modules. 

   SOLUTION:  HNAS configuration processing has been modified so that  
              the correct internal operand indices are assembled to 
              match those in the MXT override modules.

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).   

2008-06-27  - APAR 2400081  (was unpublished problem 2008156A)

       APAR:  2400081_E  
     STATUS:  CLOSED
  OPEN_DATE:  2008-06-04
 CLOSE_DATE:  2008-06-27
 SERVICE(S):  RESET, RESETINO Option
  MANDATORY:  NO
 ORIGIN/REF:  240_CSP
     CPTECH:  PRT
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400081.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-04-23
              With APAR: 2400074 applied.
              Refresh recommended if you are below the 2400075 level.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS CONSDRMT CONSMRMT VCRESET
  SOURCE(S):  XFNASWA

    PROBLEM
ENHANCEMENT:  OPTIONS=RESETINO may be specified on a TYPE=MCH REMOTE
              to specify processing to occur when HNAS receives a
              RESET packet from the remote.

DESCRIPTION:  This option causes HNAS to end the PLU session with a
              NOTIFY (generated when the LU's. ACB is closed).  The
              NAS3799I session end message will show "HNAS CAUSE/
              DIAG=000/211".

              The X25 session that initiated the RESET is also ended
              with a CLEAR CAUSE/DIAG=000/211.

              This option can be manipulated with console commands:

                MRMT mch-name OPTIONS=RESETINO    ; set option.
                MRMT mch-name OPTIONS=NORESETINO  ; resets option.

              When RESETINO is in effect:

              LLC0 and LLC5 SVCs:
              Any inbound RESET terminates the PLU session and ends
              the X25 session with CLEAR C/D=000/211.

              LLC0 and LLC5 PVCs:
              Inbound RESETs with C/D=000/015 or 000/000 are ignored
              (these are used by the router to report PVC operational
              status).  Any other inbound RESET terminates the PLU
              session with a NOTIFY.  The X25 PVC session remains
              active.

              LLC3 sessions:
              Because an inbound RESET can potentially affect many
              PLU sessions HNAS has always terminated all associated
              PLU sessions when a reset is received (as above,
              C/D=000/015 and 000/015 are excepted for PVC QLLC
              sessions).

              LLC4 sessions:
              An inbound RESET is passed to the GATE PLU where the
              processing decision is made.

              When HNAS generates a RESET (Outbound) the PLU session
              is always taken down (APAR 2300140).

              This enhancement was recently requested by a customer
              who needed to force a disconnect when their remote
              end user equipment generated a reset (mismatch window
              size) that caused the session transaction to hang.

              This enhancement is based upon the NPSI RESETINO=YES|NO
              option that up to this point was not required by the
              NAS/HNAS user base.  The NPSI RESETINO=(ccdd,ccdd,...)
              option providing RESET cc=Cause and dd=Diagnostic code
              filtering is not included in this enhancement.

   SOLUTION:  N/A

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). 

2008-06-18  - APAR 2400080

       APAR:  2400080_E  
     STATUS:  CLOSED
  OPEN_DATE:  2008-06-12
 CLOSE_DATE:  2008-06-18
 SERVICE(S):  Configuration and Console, enhancements and fix.
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400080.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  With APAR 2400079 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGCNCM, CNFGEXEC, CNFGSCHD, CONSDMAP, CONSDNWD,
              CONSHELP, CONSSNAP, NASCNFG, NASCONS 
  SOURCE(S):  SYSLIN, XFBLK, XFCNFGWA, XFMODMAP, XFXTRN 

    SUMMARY:  This APAR contains 4 PROBLEM#s (#=1-4) issues, 3
              enhancements and 1 fix for the configuration and
              console subsystem.

    PROBLEM1
ENHANCEMENT1: The configuration operand counterpart for the EXEC
              console command is CONCMDQ= instead of EXEC=.

DESCRIPTION1: There is a lack of name symmetry for the EXEC console
              command and the CONCMDQ= configuration operand unlike
              the SCHEDULE command and the SCHEDULE= operand.

   SOLUTION1: The HNAS configuration process was modified to accept
              EXEC= as an alias for the CONCMDQ= operand.

    PROBLEM2
ENHANCEMENT2: The CONCMDQ=|EXEC= operand does not allow a DDNAME to
              be specified in addition to a command list.

DESCRIPTION2: See problem description.

   SOLUTION2: The HNAS configuration process was modified to accept
              CONCMDQ=ddname or EXEC=ddname as a value where ddname
              identifies a command list file.  This is similar to
              what is now done for the SCHEDULE=ddname operand.

    PROBLEM3
ENHANCEMENT3: There is no current way to request a SNAP dump of
              individual HNAS storage areas.

DESCRIPTION3: Currently, the TRCTRAP SNAP is the only way to solicit
              a SNAP dump of HNAS storage areas but this command dumps
              ALL HNAS storage areas.  There is no way to take a SNAP
              dump of individual HNAS storage areas.

   SOLUTION3: HNAS has been modified to accept the new SNAP console
              command which accepts a list of individual HNAS storage
              area names as arguments.  The SNAP command syntax is
              as follows:

              SNAP {ALL|trgtlist}

              trgtlist={ALOG|ALARMLOG}  <- alarm log
                       {BFR|BFRSTOR}    <- buffer pool
                       {CNFG|CONFIG}    <- configuration area
                       {CVT}            <- communications vector table
                       {DNAS|CONSDNAS}  <- DNAS module (NASIDENT)
                       {MCH|MCHSTOR}    <- MCH area (MCH,VCB,LUB)
                       {MLOG|MAINTLOG}  <- maintenance log
                       {PCE|PCESTOR}    <- dynamic PCE area
                       {TINT|TCPINTBL}  <- TCPIP interrupt table
                       {TRC|TRACE}      <- internal trace table
                       {VINT|VTAMINTBL} <- VTAM interrupt table
                       {WA|XFNASWA}     <- workarea
                       {WAX}            <- workarea extension

    PROBLEM4: The SCHEDULE= operand does not restrict command text
              to 63-bytes.

DESCRIPTION4: Effective with APAR 2400075, the command text provided
              for the CONCMDQ= operand, EXEC and SCHEDULE console
              commands was set to 63-bytes maximum to allow 2-bits in
              the command string length byte to be reserved for flags.
              This was done to support the overlay of the HNASCMD->
              with EXECCMD->, SCHDCMD->, PRXYCMD-> and TRAPCMD->, as
              appropriate.  This change was erroneously missed for
              the SCHEDULE= operand.

   SOLUTION4: The HNAS configuration process was modified to limit
              the length of queued command text for the SCHEDULE=
              operand to 63-bytes.

 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). 

2008-05-31  - APAR 2400079  (was unpublished problem 2008128A and 2008144A)

       APAR:  2400079  
     STATUS:  CLOSED
  OPEN_DATE:  2008-05-27
 CLOSE_DATE:  2008-05-30
 SERVICE(S):  SYSPRINT, Alert and Configuration messages
  MANDATORY:  NO, RECOMMENDED
 ORIGIN/REF:  240_SMB,240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400079.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after 2008-04-30 or an earlier
              distribution with APAR 2400075 and associated APAR
              chains applied
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGIPAD, CNFGSVC3, NASCNFG, NASPRNT
  SOURCE(S):  N/A

     SUMMARY: This APAR contains 3 PROBLEM#s (#=1|2|3) issues,
              relating to Configuration and Alert messages.

    PROBLEM1: NAS1321W REMOTE IPADDR TCPIP Alert Messages generates
              a CC=4 Warning message for a configuration option that
              is permissible.

DESCRIPTION1: The NAS1321W message was created to identify potential
              run time problems when an IPADDR/PORT combination is
              not unique.  It turns out that these messages are
              actually more for information rather than as a warning.

              The following messages are affected:

              NAS1321W REMOTE IPADDR WAS ALSO SPECIFIED FOR LOCAL
                       NAMED LXOT
              NAS1321W VALID ONLY IN HNAS-TO-HNAS ENVIRONMENT USING
                       THE SAME TCPIP STACK

              NAS1321W REMOTE IPADDR AND PORT WERE ALSO SPECIFIED FOR
                       REMOTE NAMED R2CNOT1
              NAS1321W THE SOCKETS FROM BOTH REMOTES WILL BE COMBINED
                       IN A COMMON POOL

   SOLUTION1: The NAS1321W message severity was changed from
              Warning (CC=4) to Informational (CC=0) to eliminate
              non-zero condition codes for valid (although unusual)
              configuration options.  Message NAS1321I will now be
              used for these configuration messages.

    PROBLEM2: NAS1391I messages generate too much SYSPRINT output
              during HNAS initialization.

DESCRIPTION2: The NAS1391I message was created to show which MXT
              operands override their MCH counterparts when an MXT
              is associated with an SLU within the SVC0=, SVC3=,
              SVC5= or PVC= operand.  Since most customers use MXTs
              to override root MCH operands, the number of NAS1391I
              messages can become extensive leading to NAS0200W
              messages which sets CC=4.

   SOLUTION2: The HNAS configuration process has been changed to
              only issue the NAS1391I messages during a FASTRUN
              execution.  These messages will not be seen in a
              normal HNAS run.  If you need to see the effect
              of MXT operand overrides, you will need to run a
              FASTRUN execution of HNAS prior to a normal run.

    PROBLEM3: FASTRUN processing ends with CC=04 after addition of
              MCH definitions.

DESCRIPTION3: The additional MCH statements added a number of LUs.
              This caused 20,000 additional NAS1391I messages to
              be generated which resulted in the following alert
              to be issued:

              NAS0200W 16384 SYSPRINT LOG RECORDS WRITTEN

              The 'W' severity code causes the FASTRUN process to
              end with a CC=4 completion.

   SOLUTION3: The NAS0200W message severity was changed from
              Warning (CC=4) to Informational (CC=0) to eliminate
              non-zero condition codes for this valid informational
              alert message.

CIRCUMVENTION: {optional, when appropriate}

 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). 

2008-05-20  - APAR 2400078  (was unpublished problem 2008112A)  

       APAR:  2400078_E  
     STATUS:  CLOSED
  OPEN_DATE:  2008-02-04
 CLOSE_DATE:  2008-05-20
 SERVICE(S):  Console, DVC/DLU Display Fix and VCTO|LUTO Enhancement
  MANDATORY:  NO, but recommended.
 ORIGIN/REF:  240_CPT
     CPTECH:  PRT/SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400078.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-02-28
              With APAR 2400059, 2400070 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSDLU, CONSDVC, MCHPVCI
  SOURCE(S):  N/A

     SUMMARY: This APAR contains 2 PROBLEM#s (#=1|2) issues, 1
              problem and 1 enhancement for the console subsystem
              DVC and DLU display output.

    PROBLEM1: Uninitialized PVC DVC VCST field depicts DATA state
              when IDLE should be depicted.

DESCRIPTION1: The DVC VCST field should depict a state of IDLE (P1)
              prior to PVC Setup initialization.  Once the PVC Setup
              is successful the state should depict DATA (P4D1)
              state.

              This condition did not affect the actual operation of
              the PVC although the status was incorrectly displayed.

   SOLUTION1: Logic corrected to initialize PVC into VC state P1
              instead of P4D1 before PVC Setup exchanges.

    PROBLEM2
ENHANCEMENT2: Enhancement providing the ability to determine if a
              PVC is in timer recovery state.

DESCRIPTION2: The DVC and DLU commands do not indicate if a VC or LU
              timer, respectively, is running.  In particular, for a
              PVC, prior to PVC Setup initialization.

              In viewing the PVC connect status DVC VCST or DLU STAT,
              it doesn't reveal that the setup PVC LU is in timer
              reconnect mode (PVCRECONTMR=).

   SOLUTION2: The DVC and DLU commands have been modified to provide
              a new column.  For DVC, the VCTO column will now display
              the current VC timer in effect if one is active.  For
              DLU, the LUTO column will now display the current LU
              timer in effect if one is active.  Note also that the
              the DLU STAT column has been renamed LUST.  The data
              listed in this column remains the same.

              For DVC, the VCTO column can contain the following:

              CALL - SVC Call Request sent to DTE, response expected.
              RQSE - REQSESS sent to VTAM, BIND expected.
              RCWT - PVC reconnect wait state (PVCRECONTMR=), REQSESS
                     issued on timer expiration.
              RQSD - REQSHUT sent to VTAM, SHUTDOWN expected.
              STUP - PVC Setup sent to DTE, response expected.
              CLR  - SVC Clear Request sent to DTE, response expected.
              STLG - REQSESS wait state (REQSESSDELAY=), REQSESS
                     issued on timer expiration.
              EMSG - Datafono EMSGE sent to DTE, response expected.
              SUWT - PVC Setup wait state (PVCSETUPTMR=), Setup
                     issued on timer expiration.
              MSYN - Datafono MULTISYNC sent to DTE, response expected.
              STMD - QLLC QSM sent to SPU, response expected.
              DISC - QLLC QDISC sent to SPU, response expected.
              XID  - QLLC QXID sent to SPU, response expected.
              TEST - QLLC QTEST sent to SPU, response expected.
              REXP - QLLC PIU sent to SPU, response expected.
              ICOL - QLLC SPU input collection in progress.
              OMTR - QLLC SPU output metering in progress.
              CLSD - QLLC SPU close wait state, open performed
                     on timer expiration.

              For DLU, the LUTO column can contain the following:

              DLAY - QLLC DACTLU/ACTLU wait state, ACTLU issued
                     on timer expiration.
              REXP - QLLC PIU sent to SLU, response expected.
              RQSE - REQSESS sent to VTAM, BIND expected.
              RQSD - REQSHUT sent to VTAM, SHUTDOWN expected.

 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).  

2008-05-14  - APAR 2400077  (was unpublished problem 2008126A)

       APAR:  2400077  
     STATUS:  CLOSED
  OPEN_DATE:  2008-05-05
 CLOSE_DATE:  2008-05-14
 SERVICE(S):  Configuration processing
  MANDATORY:  YES if SOCLMT= value is specified
 ORIGIN/REF:  240_SMB
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400077.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400032 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGHOME, CNFGSCLM
  SOURCE(S):  N/A

    PROBLEM:  Customer gets 0198 (NASHALT) ABEND when they specify
              SOCLMT=602 and the sum of TYPE=XOT REMOTE VCLMT= values
              plus the TAP sockets equals 602.  Two REMOTEs with
              different IPADDR= values were specified which means
              that two TAP sockets are required.  VCLMT=300 was
              specified for each REMOTE for a total of 602 sockets.

 DESCRIPTION: ABEND occurs because SOCLMT= value includes the TAP
              socket for a router but it does not also include the
              temporary socket value.  The temporary socket value was
              introduced with APAR 2100011 but was not accounted for
              in the total socket count calculation.  Configuration
              processing should detect this error but does not.  The
              result is that the NASHALT occurs during initialization
              because SOCLMT=604 should have been specified instead
              of SOCLMT=602.

   SOLUTION:  The HNAS configuration processing has been modified to
              detect when the SOCLMT= value is too low and then issue
              the following error message before terminating.  This
              will prevent HNAS from starting and thus eliminate the
              NASHALT.

              NAS1311S REMOTE XOTCNOT2 HOME XOTSRVR LIMIT REACHED
                       SOCCNT=00303 SOCLMT=00602 NEEDED=00301

CIRCUMVENTION: Omit the SOCLMT= operand to allow it to default to
               2000.

 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).  

2008-05-05  - APAR 2400076  (was unpublished problem 2008050A)

       APAR:  2400076  
     STATUS:  CLOSED
  OPEN_DATE:  2008-02-19
 CLOSE_DATE:  2008-05-05
 SERVICE(S):  GATE
  MANDATORY:  YES
 ORIGIN/REF:  240_NBG
     CPTECH:  prt
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400076.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-01-13
              with APAR: 2400018 applied.
              Refresh recommended if you are below the 2400070 level.
 SUPERSEDES:  N/A
  OBJECT(S):  XOTFCDC , XOTGTDC
  SOURCE(S):  N/A

    PROBLEM:  NAS4709W REMOTE rmt-nm lu-nm LU lu-addr LUIQ TIMEOUT,
              LUIQ BFR CT=xxxx alert issued.

DESCRIPTION:  This alert indicates the buffer at the head of the LU
              input queue has been there for 5 minutes.  The alert
              indicates that data from the remote is not being
              delivered to the PLU.

              The LU involved is a GATE data session LU.  The input
              queue is 'stuck' because there is an incomplete M-bit
              chain being received from the remote.  The incomplete
              M-bit chain is followed by a Clear confirm packet.

              The queue is not serviced because of the incomplete
              packet at the queue head.  The Clear confirm packet is
              a result of a Clear sent to HNAS by the GATE PLU.
              This situation occurs rarely.

              The problem arises because HNAS does not clear the LU 
              input queue when the CTCP sends a Clear packet.

   SOLUTION:  HNAS modified to clear the LU input queue when a GATE
              Clear packet is received from the CTCP.

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).  

2008-05-05  - APAR 2400075  (was unpublished problem 2008034A)

       APAR:  2400075_RE  
     STATUS:  CLOSED
  OPEN_DATE:  2008-02-04
 CLOSE_DATE:  2008-05-05
 SERVICE(S):  Console Enhancements & Multiple Commands Line Fix
  MANDATORY:  NO, but recommended for improved flexibility.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.
   COREQ(S):  N/A
  PREREQ(S)   N/A

     SUMMARY: This APAR contains 3 PROBLEM# (#=1|2|3) issues, 2
              enhancements and 1 fix for the console subsystem.

    PROBLEM1
ENHANCEMENT1: Need the ability to schedule LOCAL console commands
              from a REMOTE console and vice versa.

DESCRIPTION1: Currently, commands entered from any console (LOCAL
              or REMOTE) are executed for that console only.  There
              is no way to schedule commands or modify queues and
              workareas for one console from another.

   SOLUTION1: HNAS has been modified to accept a console PCE name
              as the first argument for certain commands so that
              the command will affect the named console rather than
              the requesting console.  The following commands have
              been modified for this support.

              ********************************************************

              ALARM {LCLCONS|rconname} {action}

              action = {ON|OFF} {TEST='text'}
                       {FILTER={?|*|
                                ({A|P|S},id1({A|P|S|FC|FU}),...
                                         ...,idn({A|P|S|FC|FU}))}}
                       {LIMITS={?|*|@|
                                (tsec,ict,dct,act,wct,ect,sct,uct)}}
                       {LOG={?|CLEAR|RESET}}
                       {MSGTXT={?|SHORT|LONG}}
                       {PULSE={?|*|(hh:mm:ss,hh:mm:ss,seconds)}}
                       {SHOW}

              ********************************************************

              EXEC {LCLCONS|rconname} {action}

              action = (cmd1,...,cmdn) <- Execute inline command list
                       ddname          <- Execute dataset command list
                       LIST ddname     <- List dataset command list
                       STOP            <- Stop command list execution

              ********************************************************

              SCHEDULE {LCLCONS|rconname} {action}

              action = (time1,cmd1,..) <- Append inline schedule list
                                          to active schedule list
                       ddname          <- Append dataset schedule list
                                          to active schedule list
                       LIST ddname     <- List dataset schedule list
                       LIST            <- List active schedule list
                       SUSP            <- Suspend active schedule list
                       RSME            <- Resume active schedule list
                       PRG             <- Purge active schedule list

              ********************************************************

              {ID=lo{-hi}} SMSG 'text'

                           -OR-

                           SMSG {LCLCONS|rconname} 'text'

              ********************************************************

                           TRCCONS {ALLON|ALLOFF} <- global control

                             -OR-

              {ID=lo{-hi}} TRCCONS {ON|OFF}

                             -OR-

                           TRCCONS {LCLCONS|rconname} {ON|OFF}

              ********************************************************

              Notes: 1) When the LCLCONS argument is specified, it
                        directs command processing to the local
                        console.  When LCLCONS and rconname are
                        omitted for the local console, LCLCONS is
                        assumed.

                     2) When the rconname argument is specified, it
                        directs command processing to the named
                        remote console.  When LCLCONS and rconname
                        are omitted for a remote console, rconname
                        is forced to the name of the remote console.

                     3) Console names can be provided by issuing the
                        DPCE TYPE=CONS command.  Only consoles that
                        are in the active state can be targeted by
                        the rconname parameter.

                     4) The LCLCONS and rconname arguments are valid
                        for privilege consoles only when specified
                        for the EXEC or SCHEDULE command.  These
                        commands are normally non-privileged while
                        the ALARM command and all trace commands are
                        privileged.

                     5) When a command is executed, the normal console
                        command echo prefix is HNASCMD->.  This prefix
                        is changed when the command is the result of
                        an EXEC command, SCHEDULE command, comes from
                        another console or is the result of a TRAP.
                        In these cases, the HNASCMD-> echo prefix is
                        replaced with EXECCMD->, SCHDCMD->, PRXYCMD->
                        or TRAPCMD->, respectively, so that these
                        commands can be identified in the SYSPRINT
                        log file.

                        *** MIGRATION ISSUE ***

                        In order to implement the HNASCMD-> overlay
                        logic, it was necessary to set the maximum
                        queued command size to 63 bytes.  Prior to
                        this APAR, the maximum queued command size was
                        80 bytes.  This does not affect the CONCMDQ
                        queue size itself which remains at 512 bytes.

    PROBLEM2
ENHANCEMENT2: Need the ability to specify a PCE name for commands
              that operate on PCEs.

DESCRIPTION2: For those commands that use a PCE as an argument via
              ID= or RNM= modifiers, there is no way to specify a
              PCE name when the PCE is not associated with a LOCAL
              or REMOTE definition statement.

   SOLUTION2: HNAS has been modified to accept a PCE name as the first
              argument for certain commands so that the command will
              affect the named PCE rather than the PCEs identified by
              RNM= or ID= modifier.  The following commands have
              been modified for this support.

              ********************************************************

              {ID=lo{-hi}}  DPCE {rmtname} {parmlist}

                            -OR-

              {RNM=rmtname} DPCE {rmtname} {parmlist}

                            -OR-

                            DPCE {pcestatic|pcename} {parmlist}

              parmlist = {FMT1|FMT2}
                         {SHOWNAME|SHOWADDR}
                         {ALLID}
                         {TYPE={TMR|CONS|NETV|UTIL|TCP|XTP|XOT}}
                         {PROT={XTP|XOT}}
                         {STATE={IDLE|ACTIVE}}
                         {TRACE={ON|OFF}}

              ********************************************************

                            cmdnm {ALLON|ALLOFF} {types} <- global

                             -OR-

              {ID=lo{-hi}}  cmdnm {rmtname} {ON|OFF} {types}

                             -OR-

              {RNM=rmtname} cmdnm {rmtname} {ON|OFF} {types}

                             -OR-

                            cmdnm {pcestatic|pcename} {ON|OFF} {types}

              cmdnm = {STATS|TRCBFR|TRCDATA|TRCDISP|TRCIO|TRCPCE}

              types = {ALLTYPES|NOTYPES} or
                      {CONS|NETV|TCP|TMR|UTIL|XOT|XTP}

              ********************************************************

              Notes: 1) pcestatic = TIMER|LCLCONS|NETVIEW|NASUTIL|
                                    XTPUTIL|XOTUTIL|PING

                        Alternative names for the pcestatic argument
                        are as follows:

                        WATMRPCE = TIMER
                        WACONPCE = LCLCONS
                        WANTVPCE = NETVIEW
                        WANASPCE = NASUTIL
                        XTPUTIL  = XTPUTIL
                        XOTUTIL  = XOTUTIL
                        WAPNGPCE = PING

                     2) When the pcestatic argument is specified, it
                        directs command processing to named static
                        PCE.

                     3) When the pcename argument is specified, it
                        directs command processing to the named PCE.

                     4) When pcestatic and pcename are omitted, the
                        command operates off of the RNM= or ID=
                        modifier.  When the RNM= modifier is used,
                        command processing is directed at the named
                        REMOTE.  When the ID= modifier is used, command
                        processing is directed at the identified PCEs.

                     5) PCE names can be provided by issuing the DPCE
                        command.

    PROBLEM3: Unable to enter multiple SCHEDULE commands via the
              HNAS console.

DESCRIPTION3: HNAS, erroneously, does not allow multiple SCHEDULE
              or EXEC commands to be entered on the same line.  For
              example, SCHEDULE ddname SCHEDULE LIST is rejected
              and the following error message is issued:

              NASC512E PARAMETERS DUPLICATED, SCHEDULE COMMAND ABORTED

              This occurs because the second SCHEDULE command is
              treated as another DDNAME.  This command string is
              supposed to append the ddname schedule list to the
              resident schedule list and then LIST the new resident
              schedule list.

              Similarly, EXEC ddname1 EXEC ddname2 is also rejected
              with the same error because the second EXEC command is
              also treated as another DDNAME.  In fact, for SCHEDULE
              or EXEC, any command that follows the first SCHEDULE
              or EXEC command is also treated as a second DDNAME.
              For example, EXEC ddname DNAS will be rejected with
              the NASC512E message when it should be accepted.

   SOLUTION3: HNAS has been corrected to allow multiple SCHEDULE
              or EXEC commands to be entered on the same input line
              and to allow other commands to follow these commands.

 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).

2008-04-23  - APAR 2400074  (was problem 2008045A, 2008045B, 2008063A)

       APAR:  2400074_E  
     STATUS:  CLOSED                      
  OPEN_DATE:  2008-02-14
   REV_DATE:  2008-04-23 - Recalled and Reissued.
 CLOSE_DATE:  2008-04-23
 SERVICE(S):  Miscellaneous Enhancements & DATAF Fix
  MANDATORY:  RECOMMENDED
 ORIGIN/REF:  240_cpt,240_atc
     CPTECH:  SFD,PRT
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400074.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-04-08
              With APAR: 2400073 applied.
              Refresh recommended if you are not at the 2400070 level.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS , CONSDRMT , CONSMRMT , MCHHL0RQ , MCHTMR
              MCHUT2   , VCDAT    , XOTRCV   , XOTTR
  SOURCE(S):  LUD      , VCDD     , VTMRCV1  , VTMUT1   , XFNASWA

   PROBLEM1:  HNAS Datafono support does not include the IDTST=YES/NO
              option.

  SOLUTION1:  Logic added to allow IDTST to be specified as in the
              OPTIONS= list of a TYPE=DFX REMOTE.

              Sample:

              rmt-name REMOTE TYPE=DFX
                       OPTIONS=(DATAFAM,EMSGE,IDTST,XID=STD,IMS);

              When IDTST is in effect HNAS looks for the X'5F' and
              X'60' ID delimiter characters in inbound R(3) messages
              from the remote.  If an ID is present it is remembered
              in the HNAS LU control block for the session.

              The ID string in PLU output messages is tested against
              the ID in the LU.  If there is a match the 11 characters
              following the Datafono message type byte are removed
              before data is sent to the remote.

              If the IDs do not match the PLU's message is discarded
              and the following alert is issued:

              NAS5725W LU lu-name DISCARDING MSG W BAD ID FROM
                       PLU plu-name

              Special Cases:

              When IDTST is coded and the inbound R(3) message does
              not have an ID (no 5F/60 delimiter characters) then
              outbound messages are not checked for an ID string.

              When IDTST is coded and the PLU sends a message that
              is less that 12 bytes long the message is sent without
              modification.

              If multiple inbound R(3) messages arrive each is
              processed for an ID string.

              If the R(3) ID string length is greater that 11 bytes
              then ID string is ignored and the following alert is
              issued:

              NAS5723W DATAFONO IDTST LU lu-name REC'D ID STRING W
                       LENGTH > 11

   PROBLEM2:  When Datafono option DATAF coded and the PLU sends
              a series of M messages HNAS does not wait for a D(8)
              response that must be sent by the remote for each M
              message (as required by the Datafono specification).


  SOLUTION2:  HNAS corrected to wait for the D(8) ('D--') response
              after transmission of an M message.  If the required
              response is not received in 40 seconds the following
              alerts are issued:

              NAS5724W LU lu-nm DID NOT RECEIVE 'M' MSG SYNC RESP
              FROM REMOTE
              NAS3799I LU lu-nm ENDING   SESSION ON MCH mch-nm  HNAS
              CAUSE/DIAG=000/223 (000/223 (00/DF) DIAGX=0008


   PROBLEM3:  HNAS does not provide a way for CUD0 to participate
              in the selection of the HNAS SLU name for an inbound
              session.

  SOLUTION3:  A new option (OPTIONS=CUD0SELECTSLU) allows the SVCi=
              'X' processing code to start the hex compare at CUD0
              (instead of CUD1).

              Sample statement for a TYPE=MCH REMOTE:

              OPTIONS=CUD0SELECTSLU
              CUD0=(A2,A3,A4)
              CTCP=(80,80,80)
              SVC0=(7,LU1/XA2,LU2/XA2,
                      LU3/XA3,LU4/XA3,
                      LU5/XA4,LU6/XA4,LU7/XA4)

              The CUD0= and CTCP= parameters identify the CUD0 values
              that create LLC0 calls that will be assigned LUs from
              the SVC0= string.  The CUD0SELECTSLU option causes the
              LU allocation routine to select the LU if the hex value
              following the X character matches the CUD0 value in the
              call request packet.  In the above, LU1 & LU2 will be
              used for CUD0=A2 calls, LU3 & LU4 will be used for
              CUD0=A3 calls and LU5, LU6 & LU7 will be used for
              CUD0=A4 calls.  Up to 511 SVC0= entries may be coded.
              Any number of LUs may be associated with a particular
              CUD0 value.

   PROBLEM4:  The NAS7708W alert (displays PVC SETUP packet data
              when there is a SETUP problem) does not identify
              the LU name associated with the PVC session.

  SOLUTION4:  LU: lu-name field added to the alert message.  If
              the LU name is not available (for example, when
              there is no MCH name in HNAS matching the responder
              field in a SETUP from the remote) then '********'
              is displayed in the LU name area.

   PROBLEM5:  The NAS7718T trace (displays PVC SETUP packet connect
              activity) does not identify the LU name associated
              with the PVC session.

  SOLUTION5:  LU: lu-name field added to the trace message.  If
              the LU name is not available (for example, when
              there is no MCH name in HNAS matching the responder
              field in a SETUP from the remote) then '********'
              is displayed in the LU name area.

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).  

2008-04-10  - APAR 2400073  (was problem 2004274A)

       APAR:  2400073  
     STATUS:  CLOSED
  OPEN_DATE:  2004-10-01
 CLOSE_DATE:  2008-04-10
 SERVICE(S):  QLLC
  MANDATORY:  RECOMMENDED if QLLC in use.
 ORIGIN/REF:  230|240_NBG
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400073.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHL3RQ
  SOURCE(S):  VTMRCV1

    PROBLEM:  QLLC X25 session terminated when the PLU sends a 
              CLEAR PIU to HNAS.

DESCRIPTION:  Because of a logic error an X25 CLEAR is generated 
              when the PLU sends a CLEAR PIU to a QLLC LU. The 
              CLEAR PIU from the PLU is not delivered to the 
              remote because of the X25 clear.
              
   SOLUTION:  Logic corrected.

              This problem was originally reported on Oct 1, 2004.
              It was inadvertently omitted from a previous V2R3M0
              APAR.  This problem has only been seen at one HNAS
              installation.

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).  

2008-03-18  - APAR 2400072  (was problem 2008074A)

       APAR:  2400072  
     STATUS:  CLOSED
  OPEN_DATE:  2008-03-14
 CLOSE_DATE:  2008-03-18
 SERVICE(S):  PVC
  MANDATORY:  YES if PVCs used.
 ORIGIN/REF:  240_FIS
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400072.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-02-28
              with REFRESH APAR: 2400070 applied.
              If you are not at the above level a refresh is
              recommended.
 SUPERSEDES:  N/A
  OBJECT(S):  VCCLRQ
  SOURCE(S):  N/A

    PROBLEM:  HALT AT LOC 800637E6 IN NASTCP : TCPIP TRANSMIT FAILURE

DESCRIPTION:  Halt resulted because BFRPCEPT was 0 when a buffer was
              passed to TCPXMT.  The LU was a PVC LLC0 LU with a VTAM
              session that was forced by a VARY ON command.  This HNAS
              console command should not open the ACB for a PVC with 
              no session.

   SOLUTION:  The PVC VTAM session start routine was modified to not
              open a PVC LU's ACB if there is no PVC session (PVC
              SETUPs have not been exchanged with the router).

              The customer used the VARY lu OFF/ON sequence because
              the LU associated with the PVC was not active.  When a
              PVC LU's ACB is not open it indicates that the PVC
              session has not been established with PVC SETUP packets.
              Until the SETUP sequence completes the LU can't be used
              by the PLU because there is no remote to receive PLU
              data.

              The status of a PVC LU can be displayed with the HNAS 
              console DLU command or a VTAM D NET,ID= command.

CIRCUMVENTION: Do not issue VARY lu-name OFF/ON sequence for a PVC
              LU that has no session with the router.

 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).   

2008-03-18  - APAR 2400071  (was unpublished problem 2008028A)    

       APAR:  2400071  
     STATUS:  CLOSED
  OPEN_DATE:  2008-03-02
   REV_DATE:  2008-03-18 - Memo updated. 
 CLOSE_DATE:  2008-03-13
 SERVICE(S):  Configuration and Console parameter processing
  MANDATORY:  NO, but highly recommended
 ORIGIN/REF:  240_ATC
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400071.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400070 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS, CONSDRMT, CONSMLCL, CONSMRMT
  SOURCE(S):  N/A

    PROBLEM:  Error in parameter decode processing can cause one
              parameter to be processed as another.

 DESCRIPTION: Customer specified OPTIONS=DATAFM for a TYPE=DFX
              REMOTE when he meant to specify OPTIONS=DATAFAM but
              because the parameter decode processing accepts DATAF
              or DATAFAM, DATAFM was treated as DATAF.  This occurs
              because the decode tests for a text match but not
              also a text length match.

              Note that the decode problem is not limited to the
              DATAF argument but also affects other operands.  For
              example CUD=NONExxx is treated as CUD=NONE instead
              of being rejected.

   SOLUTION:  The configuration and console command parsers have been
              modified to not only test for a parameter text match
              but also a text length match.  This will ensure that,
              for example, DATAFM will be rejected rather than being
              treated as DATAF.

CIRCUMVENTION: Specify the correct parameter exactly as intended.

 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).   

2008-02-29  - APAR 2400070

       APAR:  2400070_RE  
     STATUS:  CLOSED
  OPEN_DATE:  2008-02-06
REVISE_DATE:  N/A
 CLOSE_DATE:  2008-02-29
 SERVICE(S):  Console input error message processing
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.
   COREQ(S):  N/A
  PREREQ(S):  N/A

   OVERVIEW:  This Enhancement APAR addresses the following console
              and debugging improvement.

    PROBLEM
ENHANCEMENT:  Sometimes it is difficult to determine which console
              command argument is in error when the NASC532E error
              message is issued.

DESCRIPTION:  When a console command is entered and one of the command
              arguments is in error, the command is rejected and the
              following messaged is issued:

              NASC532E PARAMETER DATA INVALID, cmdname COMMAND ABORTED

              This message tells you that there was a problem with
              the command parameter data but it does not tell you
              which parameter is in error.

   SOLUTION:  The console command error processor has been modified
              to display up to 8 bytes before and after the parameter
              data that is in error.  The new format for the NASC532E
              message is as follows:

              NASC532E PARAMETER DATA INVALID: baddata...,
                       cmdname COMMAND ABORTED

              The new format of the error message should help you
              resolve input errors more quickly than in the past.

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).  

2008-02-26  - APAR 2400069  (was unpublished problem 2008045C)

       APAR:  2400069_E  
     STATUS:  CLOSED
  OPEN_DATE:  2008-02-14
 CLOSE_DATE:  2008-02-26
 SERVICE(S):  CALLOUT T21= X25 Level 3 Timer
  MANDATORY:  NO
 ORIGIN/REF:  240_smb
     CPTECH:  prt/sfd
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400069.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  With APAR 2400068 and associated APAR chains.
              If you are not at the 2400064 level a refresh is
              recommended.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS, CONSDRMT, CONSMRMT, XOTXMTC
  SOURCE(S):  XFNASWA

    PROBLEM
ENHANCEMENT:  Customer requires the ability to increase the Call
              Request timer from the 30 second fixed value.

DESCRIPTION:  HNAS CALLOUT operation can prematurely timeout because
              a Call Accept from the remote is taking longer than the
              existing fixed 30 second timer permits.  An internal
              Clear DIAG=C5 is generated and the socket is closed
              when this condition is encountered.

              The X.25 Level 3 Call Request response timer (T21=) was
              implemented to control this condition.

   SOLUTION:  HNAS has been modified to accept OPTIONS=SVCCALLTMR=nn|
              T21=nn on the TYPE=MCH and TYPE=MXT REMOTE statements.
              This allows users to specify the call accept timeout
              intervals.  The OPTION on MXT REMOTEs only applies to
              LLC0/LLC5 calls that use the MXT.

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).  

2008-03-21  - APAR 2400068  (was unpublished problem 2008037A and
                            2007318A)

       APAR:  2400068_E  
     STATUS:  CLOSED
  OPEN_DATE:  2008-02-06
   REV_DATE:  2008-03-21 - Memo description updated (problem ref)
 CLOSE_DATE:  2008-02-12
 SERVICE(S):  Alarm message control
  MANDATORY:  RECOMMENDED
 ORIGIN/REF:  240_NBG/RWG
     CPTECH:  prt
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400068.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2008-01-17
              with APAR: 2400064 applied.
              Refresh recommended for installation below 2400064.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS, CONSALRM, XOTTR
  SOURCE(S):  NASTCP, XFBLK, XFNASWA

ENHANCEMENT:  Customer needs control of Call Request packet trace
              message size and system console routing as well as
              control of selected alert message sizes.

DESCRIPTION:  See problem.

   SOLUTION:  HNAS has been modified to accept the following BUILD
              statement OPTIONS= parameter:

              OPTIONS=ALRMSGTXT=SHORT|LONG

              The main reason for this change is to provide call
              activity information in the job log for use by programs
              that process the log and to force various alarm messages
              to fit on a single line.

   EFFECT1:   When used in conjunction with TRCMCH ICR OCR the new
              option changes the way that inbound and outbound calls
              are traced.

              LONG, the default, coded with TRCMCH ICR ON / OCR ON
              results in the following records being sent to SYSPRINT:

              NAS7718T followed by 3 NAS7798T messages giving the call
              request packet content.  These are the 'normal' pre-
              APAR ICR trace records.

              NAS7719T followed by 3 NAS7798T messages giving the call
              request packet content.  These are the 'normal' pre-
              APAR OCR trace records.

              SHORT coded the with TRCMCH ICR ON results in the
              following being sent to SYSPRINT and to the operator's
              console:

              NAS7730I ED:eeeeeeeeeeeeeee ING:ggggggggggggggg
              CUD:cccccccc FAC:llffffffffffff MCH:mch-name
              IP:a.b.c.d

              e...e: called address (up to 15 decimal digits).
              g...g: calling address (up to 15 decimal digits).
              c...c: call user data (up to 4 bytes displayed).
              ll   : facilities length byte.
              f...f: facility data (up to 6 bytes displayed).
              mch-name: name of
        thall.
            a.b.c.d: ip address that sent the call request to HNAS.

              SHORT coded the with TRCMCH OCR ON results in the
              following being sent to SYSPRINT and to the operator's
              console:

              NAS7731I ED:eeeeeeeeeeeeeee ING:ggggggggggggggg
              CUD:cccccccc FAC:llffffffffffff RMT:remote-nm
              LU:lu-name

              The content of the ED:, ING:, CUD: and FAC: fields is
              described above.
              remote-nm: name of the TYPE=XOT REMOTE used for the call.
              lu-name  : name of the HNAS LU that triggered the call.

   EFFECT2:   When a GATE CTCP clears an inbound call request HNAS
              issues a 2 line NAS7716W alert.  With ALRMSGTXT=SHORT
              the following single line alert is generated:

              NAS7716W a.b.c.d TO mch-name FAILED, CTCP CLEAR
              VIA LU lu-name CAUSE/DIAG=ccc/ddd (xx/yy) DIAGX=xxxx

              a.b.c.d:  IP address that sent the call request.
              mch-name: name of the HNAS MCH that received the call.
              lu-name:  name of the HNAS LU the CTCP sent clear to.
              ccc/ddd:  cause and diagnostic from the CTCP.
              xx/yy:    hex versions of ccc/ddd.
              xxxx:     diagnostic extension (currently not used).

   EFFECT3:   When an callout fails (remote returns clear or does
              not respond to the HNAS call request) HNAS issues a 2
              line NAS7717W alert.  With ALRMSGTXT=SHORT the following
              single line alert is issued:

              NAS7717W LU lu-name CALL TO called-addr|desc-text
              RMT rmt-name FAILED CAUSE/DIAG=ccc/ddd (xx/yy) DIAGX=xxxx

              lu-name:  name of LU that generated the call.
              called-addr: called DTE address in the call request pkt.
              desc-text: descriptive text from the RTEOUT= slot
                         for the call.  If coded, this text replaces
                         the called-address field.
              rmt-name: name of the TYPE=XOT REMOTE used for the call.
              ccc/ddd:  cause and diagnostic from the CTCP.
              xx/yy:    hex versions of ccc/ddd.
              xxxx:     diagnostic extension (currently not used).

   EFFECT4:   For example, when ALRMSGTXT=LONG (the default) is in
              effect, the NAS2200I message is displayed as follows:

              NAS2200I SERVER=010.117.056.171(01998)
                 SOCKID=0000 PCEID=0009 NAME=LXOT
              NAS2200I SOCKET ASSIGNED BY SERVER,
                 SOCCNT=00001 SOCLMT=02000

              When ALRMSGTXT=SHORT is in effect, this same message
              is displayed as follows:

              NAS2200I SERVER=010.117.056.171(01998) NAME=LXOT
                 SOCKET ASSIGNED BY SERVER, SOCCNT=00001 SOCLMT=02000

 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). 

2008-02-02  - APAR 2400067  (no problem number assigned)

       APAR:  2400067  
     STATUS:  CLOSED
  OPEN_DATE:  2008-02-01
 CLOSE_DATE:  2008-02-02
 SERVICE(S):  Console Subsystem - Remote Console
  MANDATORY:  YES, if remote console access is used and APAR 2400066
              has been applied.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400067.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400066 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  NASCONS
  SOURCE(S):  N/A

    PROBLEM:  Remote console password prompt is not displayed until
              input is entered.

 DESCRIPTION: Logic changes introduced with APAR 2400066 can cause
              the remote console password prompt to be inhibited
              until input is entered.  The standard input prompt
              from the CONPRMT= operand is displayed instead.  This
              makes it appear as though no password is required.

   SOLUTION:  The logic introduced with APAR 2400066 has been
              corrected so that the password prompt appears as it
              normally should.

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).  

2008-01-31  - APAR 2400066  (was unpublished problem 2008028A)

       APAR:  2400066  
     STATUS:  CLOSED
  OPEN_DATE:  2008-01-28
 CLOSE_DATE:  2008-01-31
 SERVICE(S):  Console Subsystem - Remote Console
  MANDATORY:  YES, if remote console access is used and APAR 2400064
              has been applied.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400066.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400064 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  NASCONS, NASUTIL
  SOURCE(S):  N/A

    PROBLEM:  Remote console session connect processing bug can
              cause HNAS to loop preventing other HNAS tasks from
              operating.

 DESCRIPTION: Logic changes introduced with Enhancement APAR 2400064
              can cause HNAS to loop when a remote console session
              connection is attempted.  The problem occurs because of
              a branch instruction that should have been but was not
              modified when APAR 2400064 logic was added.  The bad
              branch is not always executed due to a timing problem
              which means that this failure can be intermittent but
              should nevertheless be corrected.

   SOLUTION:  The branch instruction has been corrected.

CIRCUMVENTION: Do not use remote console access, restrict use to
               local (/F modify) access.

 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).   

2008-01-17  - APAR 2400065  (no problem number assigned)

       APAR:  2400065  
     STATUS:  CLOSED
  OPEN_DATE:  2008-01-14
 CLOSE_DATE:  2008-01-17
 SERVICE(S):  VTAM USSMSG - MCHSOL
  MANDATORY:  YES
 ORIGIN/REF:  240_cpt
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400065.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-06-06
              With APARs: 2400040 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHSOL
  SOURCE(S):  N/A

    PROBLEM:  0C4 ABEND when starting a remote console session
              using MCHSOL and USSMSG 0 ("Command Accepted") is
              specified.

DESCRIPTION:  APAR 2400032 (USSTAB reload) introduced logic that
              causes a S0C4 abend when USSMSG 0 is defined and a
              console session is started using MCHSOL.  The error
              is due to 0 being used as a control block address.

   SOLUTION:  Logic corrected.

CIRCUMVENTION: Don't use MCHSOL for console access.

 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).  

2008-01-17  - APAR 2400064  (was unpublished problem 2007022A and
                             2007339A)

       APAR:  2400064_RE  
     STATUS:  CLOSED
  OPEN_DATE:  2007-01-22
 CLOSE_DATE:  2008-01-17
 SERVICE(S):  Scheduled console command processing
  MANDATORY:  NO, but recommended for improved diagnostics.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.
   COREQ(S):  N/A
  PREREQ(S)   N/A

ENHANCEMENT:  Need the ability to schedule console commands that
              can be executed automatically at specific times.

DESCRIPTION:  As an aid to problem diagnosis, sometimes it is
              necessary to start/stop traces as well as issue
              display commands at specific times.  Prior to this
              enhancement this action could only be done manually
              via operator intervention.

   SOLUTION:  HNAS has been modified to accept the new SCHEDULE=
              operand and SCHEDULE console command that allows
              commands to be scheduled for automatic execution.

              Syntax for SCHEDULE= operand is as follows:

              SCHEDULE=ddname|(hh:mm:ss,cmd,...,hh:mm:ss,cmd)

              Syntax for SCHEDULE console command is as follows:

              SCHEDULE ddname|(hh:mm:ss,cmd,...,hh:mm:ss,cmd)
              SCHEDULE LIST {ddname}
              SCHEDULE SUSPEND|SUSP
              SCHEDULE RESUME|RSME
              SCHEDULE PURGE|PRG

              Where: (hh:mm:ss,cmd,...,hh:mm:ss,cmd) is an inline
                     schedule list.  Inline times and commands are
                     added to the end of an existing schedule list
                     if one is active.

                     ddname identifies a file that contains a list
                     of times and commands.  A ddname schedule list
                     can contain the following:

                     Comments are allowed and start with an asterisk
                     (*) or semi-colon (;) in record column 1.
                     Comments can also appear on a command line but
                     must start with a semi-colon after the command.

                     A single time and command can be specified on
                     a single record as follows:

                     hh:mm:ss , cmd ; comment

                     Although we recommend enclosing the strings in
                     parentheses () as follows:

                     (hh:mm:ss , cmd) ; comment

                     Multiple times and commands can be specified on
                     a single record as follows:

                     (hh:mm:ss , cmd , ... , hh:mm:ss , cmd) ; comment

                     LIST will display the current schedule list in
                     effect.  If ddname is not specified, the active
                     (current) schedule list is displayed.  If ddname
                     is specified, the identified schedule list is
                     displayed but the active schedule list remains
                     unaffected.

                     SUSPEND causes the active schedule list to be
                     suspended so that no commands will be scheduled.
                     The list itself is maintained.

                     RESUME causes the active schedule list that was
                     suspended to be resumed so that commands will be
                     scheduled again.

                     PURGE causes the current schedule list to be
                     cleared.  No commands are left to be scheduled
                     and the SUSPEND state is cleared.

              Notes: 1) In order to provide symmetry between SCHEDULE
                        and EXEC command processing, the EXEC command
                        was also modified to allow multiple commands
                        to be specified on a single record within a
                        command list file as follows:

                        (cmd , ... , cmd) ; comment

                        A single command can still be specified on a
                        single record as follows:

                        cmd ; comment

                     2) For both the EXEC and SCHEDULE commands, you
                        may enclose a cmd within single or double
                        quotes (e.g., cmd, 'cmd' or "cmd" are valid).
                        If single quotes are part of a cmd, it can be
                        enclosed in double quotes (e.g., smsg 'test'
                        or "smsg 'test'" are valid).  The enveloping
                        single or double quotes are removed from each
                        cmd before the values are saved.

                     3) For both the EXEC and SCHEDULE commands,
                        leading and trailing blanks are removed from
                        each cmd (and time for the SCHEDULE command)
                        before the values are saved.

                     4) For both the EXEC and SCHEDULE commands, an
                        END command will signal the end of data in a
                        file.  In addition, for EXEC, an embedded
                        EXEC command and for SCHEDULE, an embedded
                        SCHEDULE command will also signal the end of
                        data in a file.  Any records that follow
                        these statements will be ignored.

                     5) For both the EXEC and SCHEDULE commands, the
                        CONCMDQ queue is used to save commands.  For
                        the EXEC command, cmd values are enqueued
                        to CONCMDQ in a first in, first out (FIFO)
                        manner.  For the SCHEDULE command, cmd values
                        are enqueued to CONCMDQ in a last in, first out
                        (LIFO) manner.  LIFO enqueue is used because
                        scheduled commands must be executed at the
                        specified time rather than after any other
                        queued commands.

                        WARNING: If a command is currently running
                        when a scheduled command is enqueued, the
                        current command is aborted in favor of the
                        scheduled command (the same action takes
                        place when a command is entered by a console
                        operator).  If a command list is running,
                        the list is interrupted while the scheduled
                        command executes.  The command list is then
                        restarted with the next queued command after
                        the scheduled command executes.

                     6) Multiple commands can be scheduled for
                        execution at the same time.  For example:

                        (12:00:00,ALARM LOG=?,12:00:00,DNAS)

                        WARNING: Because scheduled commands are
                        enqueued to CONCMDQ in a LIFO manner, commands
                        with the same schedule time are executed in the
                        reverse order from how they are listed in the
                        schedule list.  In the list above, DNAS will be
                        executed before ALARM LOG=? at approximately
                        noon each day.  You should consider this when
                        listing commands in a schedule list.

                        A simple solution to ensure processing order
                        (avoiding reverse coding) is to sequentially
                        list the commands and step by 1 second as
                        depicted in the following sample:

                        (12:00:00,ALARM LOG=?,12:00:01,DNAS)

                     7) Wildcards (*) may be specified for any time
                        digit.  When a wildcard character is supplied
                        for a time digit (hh:mm:ss), it will be
                        replaced with the corresponding digit from
                        the current time then the resulting time
                        will be tested against the current time.

                        Examples:

                        If (**:**:00,ALARM LOG=?) is a scheduled
                        command, the ** will be replaced by the
                        current hours and minutes values so that
                        ALARM LOG=? will be executed every 60
                        seconds.

                        If (**:30:00,ALARM LOG=?) is a scheduled
                        command, the ** will be replaced by the
                        current hours value so that ALARM LOG=? will
                        be executed at half past every hour.

                        If (1*:00:00,ALARM LOG=?) is a scheduled
                        command, the * will be replaced by the low
                        order hours digit so that ALARM LOG=? will
                        be executed on the hour between 10:00 and
                        and 19:00 each day.

                        If (12:**:00,ALARM LOG=?) is a scheduled
                        command, the ** will be replaced by the
                        current minutes value so that ALARM LOG=?
                        will be executed once per minute between
                        12:00 and 12:59 each day.

                        You can specify a wildcard for any time except
                        the low order second digit (hh:mm:s*) because
                        a scheduled command would be executed every
                        second which could impact HNAS performance.

                     8) For the SCHEDULE command when an inline list
                        or ddname list is given, entries are added to
                        the end of the active SCHEDULE list in effect.

                        If the active schedule list contains another
                        SCHEDULE command, the specified schedule list
                        will replace the active (RESIDENT) list.  This
                        allows you to chain schedule lists (see Item 9
                        examples). 

                     9) For the EXEC command, an embedded EXEC command
                        allows you to chain command lists.  For the
                        SCHEDULE command, an embedded SCHEDULE command
                        allows you to chain schedule lists.

                        For example, if you want to run a different
                        schedule list each day, you could structure
                        them as follows (assume HNAS is started on
                        Monday):

                        BUILD SCHEDULE=DD4MON

                        //DD4MON DD DSN=hlq.HNASMAC(DD4MON),DISP=SHR
                        //DD4TUE DD DSN=hlq.HNASMAC(DD4TUE),DISP=SHR
                        //DD4WED DD DSN=hlq.HNASMAC(DD4WED),DISP=SHR
                        //DD4THU DD DSN=hlq.HNASMAC(DD4THU),DISP=SHR
                        //DD4FRI DD DSN=hlq.HNASMAC(DD4FRI),DISP=SHR
                        //DD4SAT DD DSN=hlq.HNASMAC(DD4SAT),DISP=SHR
                        //DD4SUN DD DSN=hlq.HNASMAC(DD4SUN),DISP=SHR

                        Each schedule list file will end with a
                        SCHEDULE command that points at the next
                        file which will take effect at midnight.

                        The DD4MON file will end with the following
                        statement: (00:00:00,SCHEDULE DD4TUE)

                        The DD4TUE file will end with the following
                        statement: (00:00:00,SCHEDULE DD4WED)

                        :

                        The DD4SUN file will end with the following
                        statement: (00:00:00,SCHEDULE DD4MON)

                        In this way, you can operate with a different
                        set of scheduled commands each day and because
                        DISP=SHR is specified for each ddname, you can
                        make changes to any of the inactive list files
                        while HNAS is running.  Note also that you can
                        alter the normal schedule list flow by simply
                        entering a new SCHEDULE command from the
                        operator console.

                        As another example, suppose you want to run
                        different schedule lists during the day and
                        night, you could structure them as follows
                        (assume HNAS is started during the day):

                        BUILD SCHEDULE=DD4DAY

                        //DD4DAY DD DSN=hlq.HNASMAC(DD4DAY),DISP=SHR
                        //DD4NIT DD DSN=hlq.HNASMAC(DD4NIT),DISP=SHR

                        As before, each schedule list file will end
                        with a SCHEDULE command that points at the
                        other file which will take effect at the
                        specified time.

                        The DD4DAY file will end with the following
                        statement: (00:00:00,SCHEDULE DD4NIT)

                        The DD4NIT file will end with the following
                        statement: (06:00:00,SCHEDULE DD4DAY)

                    10) When a scheduled command is executed, the
                        normal console command echo prefix is changed
                        from HNASCMD-> to SCHDCMD-> so that scheduled
                        commands can be identified in the SYSPRINT
                        log file.

                    11) When SCHEDULE=schdlist is decoded during HNAS
                        activation, scheduled commands are suspended
                        until after the NAS0001I INITIALIZATION
                        COMPLETE message is issued and after first
                        CONCMDQ=cmdlist processing.

 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).

sum240_2007

2007-12-17  - APAR 2400063  (was unpublished problem 2007340A)

       APAR:  2400063_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-12-06
 CLOSE_DATE:  2007-12-17
 SERVICE(S):  TRCTRAP and Shutdown SNAP Dump Processing
  MANDATORY:  NO
 ORIGIN/REF:  240_cpt
     CPTECH:  PRT/SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400063.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-11-29
              With APAR: 2400059 applied.
              Refresh recommended if you are below the 2400055 level.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSDNAS , CONSTRTR , MCHUT2 , NASUTIL
  SOURCE(S):  NASMAIN  , NASTCP , XFNASWA , XFIDR

    PROBLEM
ENHANCEMENT:  Enhancement providing improved debug & run-time
              history information in the SYSPRINT output for
              TRCTRAP and Shutdown SNAP Dump activity.

DESCRIPTION:  SNAP dump now provides the following identifiers
              and sections:

              %%BEGIN-SNAP  - Begin of SNAP dump identifier
              DNAS AREA     - Raw DNAS Cust Ship info (unformatted)
              APAR AREA     - Raw APAR Identifiers    (unformatted)
              ALARM AREA    - Raw Alarm counters      (unformatted)
              %%END-SNAP    - End of SNAP dump identifier

   SOLUTION:  HNAS logic added to provide these enhancements.

              Note: In addition to the enhancement documented in
                    this memo, 2 other TRCTRAP related changes are
                    also included.

                    1) REMEALL in the NAS0050A message was changed
                       to RSMEALL which is the correct spelling.

                    2) The ddname in the NASC121E message which can
                       be displayed incorrectly has been fixed (The
                       incorrect ddname display occurred when a new
                       ddname was entered which was shorter than
                       the old ddname).

CIRCUMVENTION: Enter display commands before and after Snap dump.

 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). 

2007-12-07  - APAR 2400062

       APAR:  2400062  
     STATUS:  CLOSED
  OPEN_DATE:  2007-12-05
 CLOSE_DATE:  2007-12-07
 SERVICE(S):  GATE
  MANDATORY:  YES
 ORIGIN/REF:  240_nbg
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400062.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-03-05
              With APAR: 2400028 applied.
              REFRESH recommended if you are below 2400055 level.
 SUPERSEDES:  N/A
  OBJECT(S):  VCCLEAR
  SOURCE(S):  N/A

    PROBLEM:  NAS4709W REMOTE mch-mm  lu-nm LU lu-addr LUIQ
              TIMEOUT, LUIQ BFR CT=0002

DESCRIPTION:  The NAS4709W alert indicates that input messages
              from the remote have been on the LU input queue
              for over 4 minutes.  In this case the alert
              indicates a hung LU resource.

              This occurs for a GATE session when a Clear packet
              is received in the middle of an m-bit chain.  The
              Clear packet is placed after the message being
              accumulated so that the clear can be sent to the
              GATE CTCP.  HNAS then, incorrectly, waits for a
              data packet with M=0 to complete the m-bit chain
              being received.  Because of the Clear, this will
              never happen.

   SOLUTION:  HNAS Clear processing changed to mark the queued
              message complete.  This will cause the message
              fragment and the inbound clear to be delivered to
              the CTCP.

              This problem was originally 2300143.  The problem
              re-appeared in V2R4M0 because of an error made
              when the V2R3M0 fix was copied to V2R4M0.

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).  

2007-12-04  - APAR 2400061  (was unpublished problem 2007280A)

       APAR:  2400061
     STATUS:  CLOSED
  OPEN_DATE:  2007-10-07
   REV_DATE:  2007-12-04 - XOTXMTC added to memo OBJECT(S): list
 CLOSE_DATE:  2007-12-03
 SERVICE(S):  PVC
  MANDATORY:  RECOMMENDED if PVCs used.
 ORIGIN/REF:  240_CSK
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400061.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-09-23
              With APARs: 2400053 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  VCRESET XOTXMTC
  SOURCE(S):  N/A

    PROBLEM:  When a PLU terminates a PVC VTAM session there can
              be a delay (up to 60 seconds) before a new session
              can start.

DESCRIPTION:  When a PLU terminates a PVC VTAM session (UNBIND,
              NOTIFY, CLEANUP, TPEND) HNAS closes the VTAM ACB
              and sends a RESET to the remote session with an
              appropriate diagnostic code.  The ACB is reopened
              by timer logic.  The delay to the OPEN may be as
              long as 60 seconds.  During this time the PVC LU
              cannot be acquired by the PLU.  This may cause the
              PLU to fail.

              This condition was observed in an environment where
              a batch program was utilized to open the session,
              initiate the transaction and close the session.
              The batch program failed if it was not able to re-
              acquire the HNAS LU because the LU's ACB was not
              open.  HNAS timer logic, which could take up to 60
              seconds, reopens the ACB.

   SOLUTION:  When a RESET-Confirm is received or transmitted to
              a PVC HNAS (with this APAR) will re-open a closed
              PVC LU's ACB without delay.

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).  

2007-11-29  - APAR 2400060

       APAR:  2400060  
     STATUS:  CLOSED
  OPEN_DATE:  2007-11-29
 CLOSE_DATE:  2007-11-29
 SERVICE(S):  DMCH FMT3 processing
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400060.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400042 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CONSDMCH

   OVERVIEW:  See Problem

    PROBLEM:  Console session hangs when DMCH FMT3 is entered and
              RNM= is not set.

DESCRIPTION:  Due to an error introduced with APAR 2400027, the DMCH
              FMT3 command no longer works when an RNM= value is not
              set.  The console session hangs and no further input
              can be processed.  This occurs because of a bad branch
              in the FMT3 logic that causes subsequent DMCH command
              processing to be bypassed.

   SOLUTION:  The DMCH FMT3 processor has been modified to correct
              the bad branch.

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). 

2007-12-01  - APAR 2400059  (was problem 2006106A, 2006270A and 
                             unpublished problem 2007288A)

       APAR:  2400059_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-11-01 (various problem enhancement dates)
 CLOSE_DATE:  2007-11-29
 SERVICE(S):  PVC Setup Enhancements
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT,230_FIS,240_CSK
     CPTECH:  SFD/PRT
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX and (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400059.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-10-17
              With APAR: 2400055 applied.
              Refresh recommended for systems below the 2400055 level.

 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS , CONSDRMT , CONSMRMT , MCHHL0RQ , MCHHL5RQ ,
              MCHNRQC  , MCHPVCI  , MCHTMR   , VCCLRQ   , VCUT1    ,
              XOTRCV   , XOTXMTC
  SOURCE(S):  VCDD     , XFNASWA

    OVERVIEW: PVC operational enhancements:

    PROBLEM1: NO way to control the frequency of HNAS attempts to
              establish the VTAM session between an XOT PVC VC and
              the PLU.

    PROBLEM2: No way to control the frequency of PVC SETUP packets
              sent by HNAS to establish the a PVC session with the
              router.

    PROBLEM3: No way to specify PVC SETUP response status so that a
              PVC can be shutoff at the router.

  Solution 1: OPTIONS=PVCRECONTMR=secs may be coded on TYPE=MCH or
              TYPE=MXT REMOTE statements.  The value coded for secs
              specifies how often HNAS tries to reconnect the VTAM
              session between a PVC VC and the PLU.

              If PVCRECONTMR= is omitted on a TYPE=MCH REMOTE a
              default value of 60 seconds will be used.  If
              PVCRECONTMR= is omitted on a TYPE=MXT REMOTE no
              default value is set and the root MCH value will be
              used.

              Values between 5 and 254 may be coded for secs.

  Solution 2: OPTIONS=PVCSETUPTMR=secs may be coded on TYPE=MCH or
              TYPE=MXT REMOTE statements.  The value coded for secs
              specifies how often HNAS should send a PVC SETUP
              packet to establish a PVC session with the router.
              The option only has meaning if the PVC definition in
              the HNAS CDF identifies a router to be used for the
              session (see PVC= operand description in Chapter 4).

              If PVCSETUPTMR= is omitted on a TYPE=MCH REMOTE a
              default value of 60 seconds will be used.  If
              PVCSETUPTMR= is omitted on a TYPE=MXT REMOTE no
              default value is set and the root MCH value will be
              used.

              Values between 10 and 254 may be coded.

  Solution 3: OPTIONS=PVCSETUPREJ=code may be coded on TYPE=MCH or
              TYPE=MXT REMOTE statements.  The value coded for code
              specifies a hexadecimal PVC SETUP reject status value
              that will be used any time HNAS receives a SETUP for
              the PVC. Since a status code greater than X'0F' causes
              the router to stop sending SETUP packets for the PVC,
              this option may be used to make the router stop sending
              SETUP packets for selected PVCs.

              If PVCSETUPREJ= is omitted, SETUP packets are processed
              normally (status code to connect or reject the session
              generated by HNAS in accordance with RFC 1613).

              code is specified as a hex value between 00 and 7F.
              X'' framing characters are not to be used.  The value
              hex 12 is not allowed because this is the status code
              used in a PVC CONNECTED SETUP response.  The value 0
              is treated the same as omitted (0 is not valid as a
              SETUP response status code).

 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).  

2007-11-19  - APAR 2400058  (was unpublished problem 2007322A)

       APAR:  2400058  
     STATUS:  CLOSED
  OPEN_DATE:  2007-11-18
 CLOSE_DATE:  2007-11-19
 SERVICE(S):  PVC, VTAM
  MANDATORY:  YES
 ORIGIN/REF:  240_CSK
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
------------
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400058.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-04-09
              With APAR: 2400032 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  VTMUT1

    PROBLEM:  HALT AT LOC 8006DA0C IN MCHLXBA : VTAM REQ LOST

DESCRIPTION:  Validity check ABEND. HNAS is processing a buffer 
              request for PLU data but there is no active request 
              in the LU. 

              When a CLEANUP request is received for an LU the LU 
              is refreshed (ACB closed, LU purged from queues). If 
              the LU has a PVC VC attached the VC buffer request 
              queue is not purged of PLU buffer requests. When the 
              VC request queue is serviced the HALT occurs because 
              the LU no longer has an active PLU request (because 
              of the CLEANUP).

     SOLUTION:  HNAS logic corrected.

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)  

2007-10-29  - APAR 2400057  (was unpublished problem 2007277A)

       APAR:  2400057  
     STATUS:  CLOSED
  OPEN_DATE:  2007-10-04
 CLOSE_DATE:  2007-10-29
 SERVICE(S):  TRCMCH LCL|GBL processing
  MANDATORY:  NO
 ORIGIN/REF:  240_SIK
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400057.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400055 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSTMCH
  SOURCE(S):  N/A

    PROBLEM:  TRCMCH default of GBL is confusing when RNM=rmtname
              modifier is provided.

 DESCRIPTION: Currently, GBL is the default parameter for the ICR,
              OCR, ICRF, ICLR and OCLR parameters even when an
              RNM= modifier value is given.  For example:

              HNASCMD-> TRCMCH MCH1 ICR
              HNASXEQ-> TRCMCH RNM=MCH1 GBL ICR ON

              For HNASCMD-> input, the user probably intended ICR
              to have local significance for the MCH named MCH1.
              However, the HNASXEQ-> echo of the command shows that
              ICR has global significance even though RNM=MCH1 is
              given.

   SOLUTION:  HNAS will be modified to force a default of LCL when
              LCL|GBL is not specified but RNM= or ID= is specified.
              GBL will still be the default when RNM= and ID= are
              not set.  Examples:

              HNASCMD-> TRCMCH MCH1 ICR            <- RNM provided
              HNASXEQ-> TRCMCH RNM=MCH1 LCL ICR ON

              HNASCMD-> TRCMCH ICR                 <- no RNM or ID
              HNASXEQ-> TRCMCH GBL ICR ON

              HNASCMD-> TRCMCH MCH1 GBL ICR        <- RNM with GBL
              HNASXEQ-> TRCMCH RNM=MCH1 GBL ICR ON

CIRCUMVENTION: Enter LCL or GBL as appropriate.

 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).  

2007-10-29  - APAR 2400056

       APAR:  2400056  
     STATUS:  CLOSED
  OPEN_DATE:  2007-10-26
 CLOSE_DATE:  2007-10-29
 SERVICE(S):  Configuration processing, LOCAL|REMOTE TYPE= operand.
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400056.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400055 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  NASCNFG
  SOURCE(S):  N/A

    PROBLEM:  NASHALT, 0198 ABEND can occur if TYPE= operand is
              omitted from LOCAL or REMOTE definition statement.

DESCRIPTION:  An ABEND can occur during CDF pre-scan processing if
              the TYPE= operand is not specified for a LOCAL or
              REMOTE definition statement.  This is due to the
              default type of XTP not being set during the CDF
              pre-scan pass.  The default type of XTP is set
              during normal CDF scan processing but erroneously
              was not set during the pre-scan pass.

   SOLUTION:  HNAS has been modified to set the default TYPE to
              XTP during the CDF pre-scan pass as it does during
              the normal CDF scan pass.

CIRCUMVENTION: Ensure that a TYPE= value is specified.

 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).  

2007-10-17  - APAR 2400055  (was unpublished problem 2007268A)

       APAR:  2400055_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-09-25
 CLOSE_DATE:  2007-10-17
 SERVICE(S):  TCP/IP TAP XOT processing
  MANDATORY:  NO, but recommended for improved diagnostics.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400055.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APARs 2400045 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGOPTS, CONSDRMT, CONSMRMT, MCHFCI, MCHSVCI, NASCNFG
  SOURCE(S):  NASTCP,   XFBLK,    XFNASWA

ENHANCEMENT:  Customers would like to activate TAP (XOT Keep Alive)
              processing without taking a REMOTE down (out of
              service) if a TAP Contact Lost failure occurs.

DESCRIPTION:  Currently, if 2 consecutive TAP failures occur, HNAS
              assumes that the remote router is down and then resets
              all the active TCPIP sockets associated with the failed
              router.  All LU/VC connections to the router are also
              closed.

              Sometimes, a customer would like to monitor the TAP
              process (MONTAP) and leave the connections active even
              when it appears that the router is down.

   SOLUTION:  HNAS has been modified to accept NOCLOSEONTAPFAILURE as
              a new REMOTE option.  When OPTIONS=NOCLOSEONTAPFAILURE
              is specified for a TYPE=XOT REMOTE, a TAP failure will
              not cause all active connections to the router to be
              closed.  The sessions will remain active even though the
              router is marked as down.  When a TAP failure occurs,
              the following message is generated based on the setting
              of the {NO}CLOSEONTAPFAILRE option.

              NAS2502E CLIENT=010.117.056.100(02704) SOCKID=0001
                       PCEID=000B NAME=R1CNIN
              NAS2502E ROUTER CONTACT LOST, CLOSEONTAPFAILURE
                       OPTION IS IN EFFECT

              NAS2505E CLIENT=010.117.056.100(02704) SOCKID=0001
                       PCEID=000B NAME=R1CNIN
              NAS2505E ROUTER CONTACT LOST, NOCLOSEONTAPFAILURE
                       OPTION IS IN EFFECT

              In addition, the new option can be toggled using the
              MRMT command as follows:

              MRMT rmtname OPTIONS={NO}CLOSEONTAPFAILURE

              The DRMT command will display the current TAP failure
              option.  CLOSEONTAPFAILURE can only be specified as an
              MRMT option and is the default when NOCLOSEONTAPFAILURE
              is not specified in the CDF.

              The MONTAP NAS2511M message was also modified to
              display a retry count (ddddd).  The count is reset
              when a successful TAP response is received.  The
              count indicates the number of unsuccessful TAP
              attempts.

              NAS2511M CLIENT=010.117.056.100(02704) SOCKID=0001
                       PCEID=000B NAME=R1CNIN
              NAS2511M XOT TAP TIMEOUT, RESPONSE NOT RECEIVED
                       FOR CONNECTION SETUP (ddddd)

              Note: If MRMT rmtname OPTIONS=CLOSEONTAPFAILURE is
                    entered when NOCLOSEONTAPFAILURE was in effect
                    and router contact was lost (NAS2505E message
                    was issued), all active connections to the
                    down router are immediately closed and the
                    following message is generated:

                    NAS2507E CLIENT=010.117.056.100(02704) SOCKID=0001
                             PCEID=000B NAME=R1CNIN
                    NAS2507E ROUTER CONTACT LOST, CLOSEONTAPFAILURE
                             OPTION IS IN EFFECT

                    This message is identical to the NAS2502E message
                    except for the message ID.

 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). 

2007-10-10  - APAR 2400054

       APAR:  2400054  
     STATUS:  CLOSED
  OPEN_DATE:  2007-10-10
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-10-10
 SERVICE(S):  GATEFC LUNAME= decode processing
  MANDATORY:  YES
 ORIGIN/REF:  240_BNP
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400054.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400040 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CNFGLUNM

   OVERVIEW:  See Problem

    PROBLEM:  Due to an error introduced by APAR 2400035, parsing of
              the LUNAME= operand for GATEFC can cause the LUNAME=
              operand to be rejected and HNAS to terminate during
              activation.

DESCRIPTION:  APAR 2400035 was issued to allow GATEFC data session
              SLU names to be generated in decimal or hex.  This
              is accomplished by appending a -D or -H to the PFXLU
              value (-H is assumed if omitted).  The syntax for
              the GATEFC LUNAME= operand is as follows:

              REMOTE LUNAME=(...,SLUNM-{A|I}
                                /PLUNM{||*}
                                /PFXLU-{D|H}
                                /SFXST
                                /SLUCT,..)

              The problem occurs when the SFXST value is zero (0).
              This causes the initialization of the SLUCT limit
              value to be bypassed.  When the uninitialized SLUCT
              limit value is compared against the given SLUCT value,
              it causes the SLUCT to be rejected and hence HNAS
              to terminate after the entire CDF is scanned.

   SOLUTION:  HNAS has been modified to initialize the SLUCT limit
              value when zero is specified for SFXST.

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).

2007-09-23  - APAR 2400053  (was unpublished problem 2007263A)

       APAR:  2400053  
     STATUS:  CLOSED
  OPEN_DATE:  2007-09-20
 CLOSE_DATE:  2007-09-23
 SERVICE(S):  PVC
  MANDATORY:  YES
 ORIGIN/REF:  240_FIS
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
------------
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400053.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  N/A, REFRESH recommended (CONTACT SUPPORT SERVICES).
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHL0RQ , MCHHL5RQ , MCHNRQC , MCHTMR ,
              VCCLRQ   , VCDAT    , VCRESET , XOTBXM
  SOURCE(S):  N/A
------------

    PROBLEM1: ABEND  U198 HALT AT LOC 8008F252 IN VTMLUFM : LU DIRTY

DESCRIPTION1: When a PVC LU has no VTAM session inbound data causes:

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

              DIAG=196 (VTAM FMD send error) indicates that PVC data
              could not be sent to the PLU because there was no VTAM
              session.

              The NASHALT was caused when 2 consecutive inbound
              messages arrived at nearly the same time.  A logic
              error occurs when processing of the second message
              starts before processing of the first message has
              completed.

   SOLUTION1: HNAS logic corrected.

    PROBLEM2: Meaning of the NAS5705 alert is not always clear.

DESCRIPTION2: The NAS5705 alert reports the failure of a VTAM SEND
              macro.  This can mean that a problem was reported by
              VTAM or that there was no session with the PLU.

   SOLUTION2: The NAS5705 alert will be issued with DIAG=196 and
              DIAGX=0001 when the RESET reflects the fact that
              the PVC VTAM session has not been bound.

    PROBLEM3: The PVC VTAM session connect timer (used to control
              how often HNAS issues a REQSESS VTAM macro to ask
              the PLU for a BIND) has varying values.

DESCRIPTION3: The timer values varied depending on the type of
              REQSESS failure.  This has caused problems for some
              PVC users.

   SOLUTION3: A value of 60 seconds is now used.  This will mean
              that sessions will start more quickly and that the
              NAS3702W REQSESS FAILED alert message will be issued
              more often.  The 60 second value matches the value
              used for other 'permanent' sessions (callout, GATE
              control).

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).   

2007-09-17  - APAR 2400052

       APAR:  2400052_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-09-17
 CLOSE_DATE:  2007-09-17
 SERVICE(S):  TRCLMT= operand processing
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_CSP
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400052.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   N/A
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGTRLM
  SOURCE(S):  N/A

    PROBLEM:  Enhancement providing larger trace table.

DESCRIPTION:  Some installations require a trace table larger than
              current maximum of 32767 entries.

   SOLUTION:  HNAS has been modified to allow a TRCLMT= value up
              to 1048575 entries.

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). 

2007-09-14  - APAR 2400051

       APAR:  2400051  
  OPEN_DATE:  2007-09-14
 CLOSE_DATE:  2007-09-14
 SERVICE(S):  Buffer allocation and release processing.
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400051.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400046 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  NASUTIL
  SOURCE(S):  N/A

    PROBLEM
ENHANCEMENT:  Enhancement providing buffer allocation and release
              timestamp and tracestamp.

DESCRIPTION:  As an aid to diagnosing some types of problems, it is
              advantageous to know when a buffer was allocated and
              when it was released.  Using the allocation timestamp
              and release timestamp, it can be determined how long
              a buffer has been in use.  The current trace table
              pointer is also saved at allocation and release so
              these events can be correlated with trace activity.

   SOLUTION:  HNAS has been modified to log the current time and
              current trace pointer when a buffer is allocated and
              when it is released.  These values are only used by
              Comm-Pro support personnel for problem diagnosis.

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).  

2007-09-05  - APAR 2400050 

       APAR:  2400050  
     STATUS:  CLOSED
  OPEN_DATE:  2007-09-05
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-09-05
 SERVICE(S):  BUILD ALRMFLTR= operand processing
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400050.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400021 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CNFGAFLT

   OVERVIEW:  See Problem

    PROBLEM:  Alarm filtering may not be provided when the default
              disposition (first ALRMFLTR= suboperand) is omitted.

DESCRIPTION:  When the first ALRMFLTR= suboperand is not specified
              but a comma place holder is, the ALRMFLTR= parser
              erroneously treats the omitted disposition as an 
              alarm ID of ********(A).  The means that all alarms
              are allowed regardless of any subsequent alarm IDs
              specified in the ALRMFLTR= list.  For example if the
              following is specified:

              BUILD ALRMFLTR=(,
                              NAS2****(P),
                              NAS3701W(P))

              The ALARM FILTER=? console command will display the
              following:

              HNASCMD-> ALARM FILTER=?
              HNASXEQ-> ALARM FILTER=?
              ALRMFLTR=ALLOW
                       ********(A)
                       NAS2****(P)
                       NAS3701W(P)

              The default disposition is set to ALLOW but a bogus
              alarm ID entry of ********(A) is also set.  Since the
              filtering of alarms is processed from left to right
              (first to last) in the ALRMFLTR= list, the ********(A)
              alarm ID will allow all alarms to be sent to SYSCONS
              before the other alarm IDs are tested.

   SOLUTION:  The ALRMFLTR= parser has been fixed to process the
              omitted disposition correctly so that ALLOW is set
              but the ********(A) alarm ID is not generated.

CIRCUMVENTION: Always specify a default disposition as the first
               ALRMFLTR= suboperand.  For example:

               BUILD ALRMFLTR=(ALLOW,
                               NAS2****(P),
                               NAS3701W(P))

 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). 

2007-09-04  - APAR 2400049  (was unpublished problem 2007235A)

       APAR:  2400049  
     STATUS:  CLOSED
  OPEN_DATE:  2007-08-07
 CLOSE_DATE:  2007-08-30
 SERVICE(S):  CALLOUT
  MANDATORY:  YES
 ORIGIN/REF:  240_SDD
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
------------
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400049.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2004-08-22
              With APAR: 2400047 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  XOTUT1
  SOURCE(S):  N/A
------------

    PROBLEM:  NAS7720W MGO3     CALL OUT, CAN'T CALL CALLED
              ADDR=9177374981000000 CALLING ADDR=6100121000000000

DESCRIPTION:  When an outbound call is to be made HNAS refers to
              the RTEOUT= operand on the LOCAL statement associated
              with the MCH that has a call request (BIND received 
              for callout LU or GATE call request packet received 
              from a CTCP).  RTEOUT=, in conjunction with the 
              called or calling DTE address, is used to identify a
              TYPE=XOT REMOTE used for the call.  This REMOTE 
              provides the target IP address for the XOT call and a
              PCE control block used to maintain the TCP/IP session
              for the call.  As a validity check, the PCE allocation 
              routine ensures that the TYPE=XOT REMOTE's PCE points 
              at the original LOCAL statement.  When the LOCAL 
              statement has a SOCLMT= greater that 2000 the validity
              check can fail.  This causes the outbound call to fail
              with the NAS7720W alert.

CIRCUMVENTION: Code SOCLMT=2000 on the LOCAL statement (if possible).

 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).  

2007-08-22  - APAR 2400048

       APAR:  2400048_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-08-16
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-08-22
 SERVICE(S):  HNAS EXEC PARM= processing.
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400048.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400044 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  NASMAIN
  OBJECT(S):  N/A

   OVERVIEW:  See Problem

    PROBLEM
ENHANCEMENT:  Provide the ability to specify a larger number of start
              parameters in the HNAS EXEC PARM= operand by supporting
              abbreviated start parameter operands.

DESCRIPTION:  JCL restricts the PARM= value to 100 characters which
              can be limiting for customers who need to specify many
              HNAS start parameters.

   SOLUTION:  HNAS will be modified to allow abbreviations for new
              and existing start parameters so that they will more
              likely fit within the 100 character limit of the PARM=
              operand.  For example:

              TLU MXDT for TRCLU MAXDATA will save 5 characters.

              Abbreviated     Existing    Character
              Parameter       Parameter   Savings

              ALON            ALLON         2
              ALOF            ALLOFF        3
              CNCM            CONCMDQ       3
              MXDT            MAXDATA       3
              MNDT            MINDATA       3
              NODT            NODATA        2
              PKDT            PKTDATA       3
              APFX            APFXEQ        2
              ACHK            AUTHCHK       3
              CWRN            CNFGWARN      4
              FRUN            FASTRUN       3
              GNDF            GENNWDF       3
              MTAP            MONTAP        2
              PWTO            PFXWTO        2
              PCFG            PRNTCNFG      4
              PDAT            PRNTDATE      4
              PLU             PRNTLU        3
              POFF            PRNTOFF       3
              PON             PRNTON        3
              PQLC            PRNTQLLC      4
              PSYS            PRNTSYS       3
              PTCP            PRNTTCP       3
              PVC             PRNTVC        3
              PVTM            PRNTVTAM      4
              PXOT            PRNTXOT       3
              PXTP            PRNTXTP       3
              PCON            RMTCONP       3
              RCON            RMTCONS       3
              SCFG            SHOWCNFG      4
              SCMS            SHOWCMSG      4
              SCON            SHOWCONS      4
              SERR            SHOWERR       3
              SMOR            SHOWMORE      4
              SOFF            SHOWOFF       3
              SON             SHOWON        3
              SVRS            SVRSTRT       3
              TALL            TRCALL        2
              TBFR            TRCBFR        2
              TBRQ            TRCBFRQ       3
              TBST            TRCBST        2
              TCFG            TRCCNFG       3
              TCON            TRCCONS       3
              TDAT            TRCDATA       3
              TDBK            TRCDBK        2
              TDBG            TRCDBUG       3
              TDSP            TRCDISP       3
              TIO             TRCIO         2
              TLU             TRCLU         2
              TMCH            TRCMCH        2
              TMCX            TRCMCHX       3
              TPRT            TRCPRNT       3
              TSUB            TRCSUBR       3
              TTSK            TRCTASK       3
              TVC             TRCVC         2
              TWTO            TRCWTO        2

CIRCUMVENTION: Most HNAS start parameters have console command
               counterparts to toggle their value.  For those that
               do, specify these commands within the CONCMDQ=
               operand on the BUILD definition statement.

 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). 

2007-08-22  - APAR 2400047  (was problem 2007198A)

       APAR:  2400047  
     STATUS:  CLOSED
  OPEN_DATE:  2007-07-17
 CLOSE_DATE:  2007-08-22
 SERVICE(S):  PVC Support
  MANDATORY:  RECOMMENDED
 ORIGIN/REF:  240_BPS
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400047.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-04-09
              With APARs: 2400032 Applied.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHL0RQ , MCHHL5RQ , XOTBXM , XOTUT1
  SOURCE(S):  N/A

  PROBLEM 1:  PVC VTAM session fails to restart after PVC SETUP
              sequence completes.

  PROBLEM 2:  NAS3799I LU LBOF4BTL ENDING   SESSION ON MCH XJ052  HNAS
              CAUSE/DIAG=***/*** (**/**) DIAGX=****

  PROBLEM 3:  If VARY ID=pvc-pce-id is used to terminate a TCP/IP
              session HNAS does not send a new PVC SETUP.  The PVC
              remains down.

DESCRIPTION 1: When a PVC SETUP sequence occurs HNAS sets a timer
               that starts the VTAM session for the PVC.  Under some
               very unusual circumstances VC RESET processing can 
               clear the timer so that the VTAM session does not 
               start.  The router normally sends a DIAG=0F RESET when
               SETUP processing completes.

DESCRIPTION 2: When the PLU UNBINDs an HNAS PVC session the UNBIND
               processor does not pass the cause code to the routine
               that generates the NAS3799I message.

DESCRIPTION 3: If the ID for the VARY is the ID of the first PVC on a
               TYPE=XOT REMOTE the active flag is reset for that PCE.
               An error in the PCE allocation logic used to locate
               a PCE for an outbound Call Request or PVC SETUP packet
               incorrectly treats the flag as an indication that all
               resources on the remote are inactive.

 SOLUTION 1:  HNAS RESET processing corrected.

 SOLUTION 2:  UNBIND routine corrected so that DIAG code appears in
              NAS3799I alert.

 SOLUTION 3:  PCE allocation logic corrected.

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).  

2007-08-20  - APAR 2400046

       APAR:  2400046  
     STATUS:  CLOSED
  OPEN_DATE:  2007-08-17
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-08-20
 SERVICE(S):  FASTRUN CONCMDQ and PFXWTO processing
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400046.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400042 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  NASUTIL

   OVERVIEW:  See Problems

    PROBLEM1: HNAS FASTRUN does not end after all queued console 
              commands are executed when CONCMDQ=cmdlist is 
              specified. 

    PROBLEM2: HNAS does not compress PFXWTO prefix text when the
              SHOWCMSG option is in effect.

DESCRIPTION1: Logic added with APAR 2400001 causes HNAS to remain
              active after all queued console commands have been
              executed when FASTRUN CONCMDQ is in effect.

DESCRIPTION2: When the PFXWTO prefix text (via the PFXWTO text
              follower or the NASNAME= value) is less than eight
              characters and SHOWCMSG option is in effect, HNAS
              does not remove the trailing blanks after the text
              value.

   SOLUTION1: HNAS FASTRUN CONCMDQ logic has been corrected so that
              HNAS ends after all queued console commands have been
              executed.

   SOLUTION2: HNAS has been modified to remove trailing blanks from
              the PFXWTO prefix text value when the SHOWCMSG option
              is in effect.

CIRCUMVENTION1: Issue QY command to force HNAS to end.

CIRCUMVENTION2: 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).  

2007-08-14  - APAR 2400045 

       APAR:  2400045  
     STATUS:  CLOSED
  OPEN_DATE:  2007-08-13
 CLOSE_DATE:  2007-08-14
 SERVICE(S):  ALARM logging
  MANDATORY:  NO, but recommended.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400045.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APARs 2400044 and associated APAR chains.

 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  NASTCP

    PROBLEM:  Some TCPIP and QLLC alarms are incorrectly counted
              resulting in an erroneous display when ALARM LOG=?
              is issued.

DESCRIPTION:  Due to logic introduced by APAR 2400036, XFWTO flags
              that used to be passed in register 0, byte 1 (R0B1)
              are now passed in R0B2.  Some XFWTO calls were not
              adjusted for this new flag convention.  The result is
              that the 'more data' flag, which is used to associate
              one message with another and which should be passed in
              R0B2, is being passed in R0B1, the old convention.
              When multiple line alarm is issued, the alarm is not
              counted until the last line is written.  All but the
              last line carry the 'more data' flag.  Because this
              flag is being passed in R0B1 instead of R0B2, each
              line of a multi-line message can look like the last
              line, depending on the 'trash' in R0B2, which causes
              causes the alarm count to be incremented more than it
              should be.  For example, the NAS2513M message below
              can be counted 3 times instead of just once depending
              on what value is in the uninitialized R0B2.

   NAS2513M CLIENT=010.117.056.100(02704) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
   NAS2513M XOT TAP SEQUENCE IS STARTING, TRANSMITTING CALL REQUEST
   NAS2513M PKT=0000001F10010BA820360001303600010106420707430404 ...

   SOLUTION:  HNAS has been modified to pass the 'more data' flag in
              R0B2, the correct byte.

 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).  

2007-08-14  - APAR 2400044  (was problem 2007114A)

       APAR:  2400044_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-04-24
 CLOSE_DATE:  2007-08-14
 SERVICE(S):  TCP/IP TAP Monitor processing
  MANDATORY:  NO, but recommended for improved diagnostics.
 ORIGIN/REF:  240_HVB
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400044.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APARs 2400042, 2400039, 2400030
              and associated APAR chains.

              Note: Due to the large number of PREREQs, we
                    recommend a REFRESH distribution to pickup
                    this enhancement.

 SUPERSEDES:  N/A
  OBJECT(S):  CONSMON,  CONSTALL, CONSTLU,  CONSTVC,  NASCONS,
  SOURCE(S):  NASMAIN,  NASTCP,   XFBLK,    XFNASWA

ENHANCEMENT:  Customer would like the NAS2513M message produced during
              MON TAP to provide the same information that the NAS2613M
              message does for PING.

DESCRIPTION:  Currently, the NAS2513M message provides a hex display
              of the Call Request packet fields while the NAS2613M
              message lists the various fields by name making them
              easier and faster to scan.

   SOLUTION:  HNAS has been modified to list Call Request fields for
              the NAS2513M message by name in a manner similar to
              what is done for the NAS2613M message.

              This new feature is controlled by the new MON TAP
              followers: PKTDATA, MAXDATA, MINDATA and NODATA.

              PKTDATA (the default) causes the existing TAP monitor
              messages with raw packet data to be displayed as
              follows:

   NAS2513M CLIENT=010.117.056.100(02704) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
   NAS2513M XOT TAP SEQUENCE IS STARTING, TRANSMITTING CALL REQUEST
   NAS2513M PKT=0000001F10010BA820360001303600010106420707430404 ...
   NAS2515M CLIENT=010.117.056.100(02704) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
   NAS2515M XOT TAP SEQUENCE IN PROGRESS, RECEIVED CLEAR REQUEST
   NAS2515M PKT=000000051001130D40
   NAS2513M CLIENT=010.117.056.100(02704) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
   NAS2513M XOT TAP SEQUENCE IN PROGRESS, TRANSMITTING CLEAR CONFIRM
   NAS2513M PKT=00000003100117
   NAS2517M CLIENT=010.117.056.100(02705) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
   NAS2517M XOT TAP SEQUENCE COMPLETED SUCCESSFULLY

              MAXDATA causes the raw packet data to be withheld and
              instead displays the values for the DTEADDR=, DCEADDR=
              FAC= and CUD= operands as follows:

 1 NAS2513M CLIENT=010.117.056.100(02704) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
 2 NAS2513M XOT TAP SEQUENCE IS STARTING, TRANSMITTING CALL REQUEST
 3 NAS2513M DTEADDR=20360001 DCEADDR=3036000101
 4 NAS2513M FAC=06420707430404
 5 NAS2513M CUD=01000000C8D5C1E2E3C1D7
 6 NAS2515M CLIENT=010.117.056.100(02704) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
 7 NAS2515M XOT TAP SEQUENCE IN PROGRESS, RECEIVED CLEAR REQUEST
 8 NAS2515M DTEADDR=20360001
 9 NAS2513M CLIENT=010.117.056.100(02704) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
10 NAS2513M XOT TAP SEQUENCE IN PROGRESS, TRANSMITTING CLEAR CONFIRM
11 NAS2513M DTEADDR=20360001 DCEADDR=3036000101
12 NAS2517M CLIENT=010.117.056.100(02705) SOCKID=0001 PCEID=000B
            NAME=R1CNIN
13 NAS2517M XOT TAP SEQUENCE COMPLETED SUCCESSFULLY

              MINDATA causes only the DTEADDR= and DCEADDR= values
              to be displayed.  Lines 4 and 5 are withheld.

              NODATA causes text information to be displayed without
              any packet data.  This is still useful because the
              REMOTE IPADDR= and NAME are displayed.  Lines 3, 4, 5,
              8 and 11 are withheld.

 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).  

2007-08-01  - APAR 2400043  (was unpublished problem 2007166A)

       APAR:  2400043  
     STATUS:  CLOSED
  OPEN_DATE:  2007-06-15
 CLOSE_DATE:  2007-08-01
 SERVICE(S):  GATE
  MANDATORY:  YES
 ORIGIN/REF:  240_DBO
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX,  but a REFRESH is recommended.
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400043.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-07-17
              With refresh APAR: 2400042 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHBFR , MCHHL4RQ , MCHUT1 , VCRESET
  SOURCE(S):  N/A

    PROBLEM:  OSI/CS ABEND after processing RESET CAUSE=03 DIAG=02 and
              an incorrect ERR/INFO packet from HNAS.

DESCRIPTION:  If a RESET packet is received when the GATE PLU is sending
              a large PIU and the X25 window for the session is closed
              then HNAS processing of the RESET results in an ERR/INFO
              packet being generated to report and invalid GATE command
              byte from the PLU (CTCP).  This ERR/INFO packet caused
              the OSI/CS CTCP to ABEND.

              The inbound RESET should have aborted the outbound PIU.
              Because of an HNAS error only the first 128 bytes of
              the PIU were discarded.  Byte 129 was then processed as
              a GATE command byte.  This byte was not valid as a GATE
              command so an ERR/INFO packet was generated to report
              the 'problem'.  The ERR/INFO packet header contains a
              byte which has the current GATE command.  The OSI/CS
              CTCP ABENDs if the command in the ERR/INFO packet is not
              a valid GATE command.  An OSI/CS APAR has been issued
              to fix this.  HNAS is also being APARed because the RESET 
              should not have generated the bad command detection and 
              the subsequent ERR/INFO packet.  While investigating this
              problem we found out that the resource ID carried in the
              ERR/INFO packet could have a non-zero leading hex digit
              (in violation of GATE specifications).  This problem is 
              also fixed by this APAR.

   SOLUTION:  HNAS RESET logic corrected and ERR/INFO packet's RES-ID
              field leading digit zeroed.

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).  

2007-07-13  - APAR 2400042  (created to help solve problem 2007178A)

       APAR:  2400042_E 
     STATUS:  CLOSED
  OPEN_DATE:  2007-06-27
 CLOSE_DATE:  2007-07-13
 SERVICE(S):  TCP/IP interface support
  MANDATORY:  NO, but recommended for improved debugging.
 ORIGIN/REF:  240_BNP
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400042.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APARs 2400039, 2400038, 2400037, 2400034
              and associated APAR chains.

              Note: Due to the large number of PREREQs, we
                    recommend a REFRESH distribution to pickup
                    this enhancement.

 SUPERSEDES:  N/A
  OBJECT(S):  CNFGBFSZ, CNFGOPTS, CONSDLU,  CONSDMCH, CONSDVC,
              CONSMRMT, CONSPING, CONSTLU,  CONSTLUQ, CONSTMCH,
              CONSTMCX, CONSTVC,  CONSTVCQ, MCHINI,   NASCNFG,
              NASUTIL,  QLSSCP,   XTPRCV
  SOURCE(S):  NASMAIN,  NASTCP,   XFBLK,    XFPCE

    PROBLEM
ENHANCEMENT:  Enhancement that logs diagnostic information within
              each TCPIP external interrupt data record.

DESCRIPTION:  Customer has experienced a 0198 ABEND (NASHALT validity
              check) after receiving the following alarm messages:

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

              These messages were followed by the following NASHALT:

              HALT AT LOC 80061022 IN NASTCP  : TCPIP REPLY ID FAILURE

              ABEND dump contained TCPIP external interrupt table but
              table did not contain enough information to determine
              the cause of the NASHALT.  Advised customer to run HNAS
              TCPIP traces to collect additional diagnostic data.

   SOLUTION:  HNAS has been modified to log additional diagnostic
              data within the TCPIP external interrupt area making
              the need for HNAS TCPIP traces less of a requirement.
              It should now be possible to resolve problem 2007178A
              with the external interrupt table data only.

CIRCUMVENTION: Disable LU, MCH and VC traces and start global PCE
               traces: TRCALL OFF TRCPCE ALLON

 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).  

2007-06-26  - APAR 2400041  (was unpublished problem 2007176A)

       APAR:  2400041  
     STATUS:  CLOSED
  OPEN_DATE:  2007-06-25
 CLOSE_DATE:  2007-06-26
 SERVICE(S):  GATE CALLOUT
  MANDATORY:  YES
 ORIGIN/REF:  240_LBG
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400041.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2006-09-08
              With APAR: 2400005 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHNRQC
  SOURCE(S):  N/A

    PROBLEM:   NAS5701E REMOTE mch-nm 2 MIN HDR BFR WAIT. NAS FREE
               CT=00600 RMT BFR CT=00100 after Clear diag=195 (C3).

DESCRIPTION:  When an internal clear is generated by HNAS during a
              GATE callout operation an error in buffer release
              logic keeps the MCH ownership count from being properly
              updated.  After 200 failures MCH xmit buffer allocation
              stops waiting for buffers already allocated to be freed.
              The buffers were freed but not properly accounted for
              so transmit operations for the MCH will not resume.

              The DIAG=195 internal clear occurs on a GATE callout
              only if the call fails at the TCP/IP level -- in this
              case with:

              NAS2271W CONNECT REQUEST FAILED, RC=FFFFFFFF 00000041

              This is an unusual event that resulted during a router
              outage or router ipaddr problem.

   SOLUTION:  Buffer release logic corrected.

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).  

2007-06-06  - APAR 2400040

       APAR:  2400040  
     STATUS:  CLOSED
  OPEN_DATE:  2007-06-06
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-06-06
 SERVICE(S):  LOGTAB and USSTAB processing
  MANDATORY:  YES
 ORIGIN/REF:  240_TKK
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400040.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400036 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CNFGLGTB, CNFGLUNM, CNFGUSTB, MCHSOL

   OVERVIEW:  See problem.

    PROBLEM:  MCHSOL logon and/or USS table processing can fail and
              error message NAS5703W is generated when the LOGTAB=
              and/or USSTAB= is omitted from a REMOTE.

DESCRIPTION:  Due to an error introduced by APAR 2400032, it is
              possible for logon and/or USS table processing to
              fail when the associated table is not specified
              for a REMOTE.  This was discovered by a customer
              using HNAS QLLC support (TYPE=SPU REMOTE).

              When LOGTAB= and/or USSTAB= is omitted for a TYPE=SPU
              REMOTE, corresponding value(s) from BUILD are not
              propagated to the REMOTE.  When MCHSOL gets control
              it discovers a null LOGTAB= and/or USSTAB= value
              which causes the error.

              The error occurs because of a bad test in the MCHSOL
              module that was not updated when APAR 2400032 was
              introduced.

   SOLUTION:  Configuration logic has been modified to use the LOGTAB=
              and/or USSTAB= value from BUILD if the corresponding
              parameter is omitted for a TYPE=SPU REMOTE. In addition,
              the MCHSOL module has been updated to correct the bad
              table tests.

CIRCUMVENTION: Specify a LOGTAB= and/or USSTAB= value for the affected
               TYPE=SPU REMOTE.

 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).  

2007-06-06  - APAR 2400039  (was unpublished problem 2007144A/2007130A)

       APAR:  2400039_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-05-10 for 2007130A
              2007-05-24 for 2007144A
 CLOSE_DATE:  2007-06-06
 SERVICE(S):  PING console command processing.
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_NBG
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400039.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S)   APAR 2400037 and 2400036 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSPING
  SOURCE(S):  XFBLK

    PROBLEM 
ENHANCEMENT:  Enhancement providing destination IPADDR and DTEADDR 
              addresses in all PING response alarm messages as well
              as providing a correlation sequence number in all 
              PING request and response messages. 

DESCRIPTION:  Customer has SYSPRINT alarm message scanning program 
              that isolates various HNAS alerts. Customer needs 
              the ability to easily correlate PING requests and 
              responses in SYSPRINT as well as easily identifying 
              the destination router IPADDR and network DTEADDR. 

   SOLUTION:  HNAS has been modified to generate one line response
              messages that provide succinct information for PING 
              and at the same time provide data that makes it easy 
              to correlate PING initiation and termination messages.
              In lieu of the console name in PING response messages,
              a correlation sequence number is provided along with
              the target IPADDR= and DTEADDR= values.  The following
              sample messages illustrate the new PING information.

NAS2613M PINGING SOCKET=010.117.056.001(01998)
                 REQUESTED BY WACONPCE (00001)
NAS2613M         DTEADDR=1036000103 DCEADDR=20361234
NAS2613M         FAC=06420707430202
NAS2613M         CUD=01000000
NAS2611M PING CALL TIMED OUT FOR SOCKET=010.117.056.001(01998)
         DTEADDR=1036000103 (00001)

NAS2613M PINGING SOCKET=010.117.056.100(01998)
                 REQUESTED BY WACONPCE (00002)
NAS2613M         DTEADDR=203643211 DCEADDR=20361234
NAS2613M         FAC=06420707430202
NAS2613M         CUD=01000000
NAS2615M PING CALL CLEARED (0D/40) FOR SOCKET=010.117.056.100(01998)
         DTEADDR=203643211 (00002)

NAS2613M PINGING SOCKET=010.117.056.100(01998)
                 REQUESTED BY WACONPCE (00003)
NAS2613M         DTEADDR=1036000103 DCEADDR=20361234
NAS2613M         FAC=06420707430202
NAS2613M         CUD=01000000
NAS2617M PING CALL ACCEPTED FOR SOCKET=010.117.056.100(01998)
         DTEADDR=1036000103 (00003)

              Note that the PING sequence number is displayed in
              parentheses after the DTEADDR= value thus allowing
              PING requests and responses to be correlated.  The
              requesting console name is provided in the NAS2613M
              initiation message along with the PING sequence
              number which becomes the correlation count in PING
              responses.

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). 

2007-05-24  - APAR 2400038  (was unpublished problem 2007143A)

       APAR:  2400038  
     STATUS:  CLOSED      
  OPEN_DATE:  2007-05-23
 CLOSE_DATE:  2007-05-23
 SERVICE(S):  INSTALL, HNASMNT JOB & SMP RECEIVE JOB
  MANDATORY:  YES
 ORIGIN/REF:  240_FIS
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400038.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-04-26
              With APARs: 2400036 and 2400033 (refresh) applied.
 SUPERSEDES:  N/A
  OBJECT(S):  NASUTIL, OSUT1
  SOURCE(S):  XFMSG

    PROBLEM:  During product installation the assembly of VTMTR 
              receives CC=8 with the error message:
              
              ASMA034E Operand PRTXBST beyond active USING ......

DESCRIPTION:  This error occurs because APAR 2400036 introduced
              changes to the XFMSG macro which increased it's
              expansion size.  The increased size moved the
              PRTXBST symbol beyond addressability.

   SOLUTION:  VTMTR changed to move these symbols in range.
              XFMSG has been modified to restore it's previous
              expansion size.  NASMSG service routine in module
              OSUT1 and XFWTO service routine in module NASUTIL
              modified to handle restored XFMSG macro.

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).  

2007-05-09  - APAR 2400037

       APAR:  2400037  
     STATUS:  CLOSED
  OPEN_DATE:  2007-05-09
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-05-09
 SERVICE(S):  PING console command processing
  MANDATORY:  NO
 ORIGIN/REF:  240_NBG
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400037.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400033 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CONSPING

   OVERVIEW:  See problem.

    PROBLEM:  The last digit of the DTEADDR= value in a PING Call
              Request packet is dropped when an odd number of digits
              is specified and DCEADDR=NULL|NONE is in effect for
              a referenced TYPE=DMY REMOTE.

DESCRIPTION:  Logic introduced by APAR 2400033 that prevents trash
              from being sent when DCEADDR=NONE|NULL is specified
              inadvertently causes the last digit of an odd DTEADDR=
              value to be dropped.  The called DTE address field
              ends up being an even number of digits even though
              the called length is odd.  This changes the position
              of the facilities and call user data fields which can
              confuse the router.

   SOLUTION:  The PING console command processor has been modified
              to correct the problem with an odd DTEADDR= value and
              a null DCEADDR= value.

CIRCUMVENTION: Ensure that a proper DCEADDR= value is specified 
               other than NONE|NULL.

 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). 

2007-04-26  - APAR 2400036  (was unpublished problem 2007103A)

       APAR:  2400036_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-04-13
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-04-26
 SERVICE(S):  WTO (Configuration & Alert Messages) processing
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the ace="Courier New">2400036.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400035 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  NASMAIN,  NASTCP,   XFBLK,    XFMSG,    XFNASWA,
              XFWTO
  OBJECT(S):  CNFGDLNM, CNFGDXNM, CNFGIDTO, CNFGIPAD, CNFGLGTB,
              CNFGLUNM, CNFGMSLM, CNFGPLSE, CNFGPVC,  CNFGPWPR,
              CNFGSVC0, CNFGSVC3, CNFGSVC4, CNFGSVC5, CNFGSYSL,
              CNFGTAP,  CNFGTRAN, CNFGUSTB, CNFGVLCM, CONSDNAS,
              CONSEXEC, CONSMON,  CONSMRMT, CONSPRNT, CONSSHOW,
              CONSSTAT, CONSTRTR, NASCNFG,  NASCONS,  NASPRNT,
              NASUTIL,  OSUT1,    QLSSCP,   VCCLRQ

   OVERVIEW:  See Problem

    PROBLEM
ENHANCEMENT:  An option is now available that when invoked will
              remove extraneous blanks from NASnnnns Configuration
              and Alert messages.

DESCRIPTION:  Currently, messages that contain names or other variable
              text data can cause multiple blanks to appear in alarm
              messages.  Removing multiple blanks makes messages look
              cleaner in SYSPRINT log and on SYSCONS.

   SOLUTION:  HNAS has been modified to allow the new XFWTO and XFMSG
              macro COMPMSG= parameter to be selectively invoked for
              certain messages that contain variable length text
              data.  This new operand by itself will not cause
              compression but will require the new SHOWCMSG start
              parameter to be set as well.  This will allow customers
              to control the compression process for those who use
              message filtering tools that depend on fixed message
              offsets.  Consider the following message for example:

              NAS3799I Without Compression:

              0         1         2         3         4         5
              012345678901234567890123456789012345678901234567890123
              |                                                    |
              NAS3799I LU MCH1PVC  ENDING   SESSION ON MCH MCH1
              RMT  CAUSE/DIAG=000/130 (00/82) DIAGX=0000
              |                                        |
              456789012345678901234567890123456789012345
                    6         7         8         9

              NAS3799I With Compression:

              0         1         2         3         4
              01234567890123456789012345678901234567890123456
              |                                             |
              NAS3799I LU MCH1PVC ENDING SESSION ON MCH MCH1
              RMT CAUSE/DIAG=000/130 (00/82) DIAGX=0000
              |                                       |
              78901234567890123456789012345678901234567
                 5         6         7         8


              Note1: While message compression does use additional
                     CPU cycles, the affect appears to be minimal.
                     However, HNAS environments with excessive alert
                     message activity should consider measuring the
                     effect upon CPU load with compression enabled
                     (SHOWCMSG ON) and disabled (SHOWCMSG OFF) to
                     see if compression is causing an unacceptable
                     percentage of CPU load.  Our in-house testing
                     revealed a CPU seconds difference per WTO for
                     SHOWCMSG ON versus SHOWCMSG OFF to be an
                     additional 0.000011048 seconds per WTO or
                     approximately 0.002846% additional overhead
                     per WTO.

              Note2: The SHOW console command processor has also
                     been modified to accept the new CMSG {ON|OFF}
                     argument in order to dynamically toggle the
                     SHOWCMSG start parameter setting.

 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). 

2007-04-20  - APAR 2400035  (was unpublished problem 2007108A)

       APAR:  2400035_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-04-18
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-04-20
 SERVICE(S):  GATEFC SLU name generation processing
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_SMB
    CP_TECH:  SFD, PRT
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400035.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400032 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  XFNASWA
  OBJECT(S):  CNFGLUNM, CNFGVCLM, CONSDRMT, CONSMRMT,
              MCIFCI,   MCHINI,   MCHSTRT,  NASCNFG

   OVERVIEW:  See Problem

    PROBLEM
ENHANCEMENT:  Customer needs the ability to generate decimally
              suffixed SLU names for GATEFC CTCP.

DESCRIPTION:  Existing logic generates hexadecimally suffixed 
              SLU but customer's CTCP is setup to have SLU 
              names in decimal order.

   SOLUTION:  HNAS has been modified to allow the hex/decimal 
              identifier to be appended to the end of the the
              SLU prefix value.

              Old Syntax:
              LUNAME=(sluname/pluname/pfxlu/sfxst/slucnt)

              New Syntax:
              LUNAME=(sluname/pluname/pfxlu{-H|-D}/sfxst/slucnt)

              If pfxlu-D is specified, decimal SLU names will be
              generated.  If pfxlu-H or pfxlu (no -X) is specified,
              hex SLU names will be generated as before.

 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). 

2007-04-11  - APAR 2400034

       APAR:  2400034
     STATUS:  CLOSED
  OPEN_DATE:  2007-04-06
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-04-11
 SERVICE(S):  Console command list processing
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400034.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400032 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  XFBLK
  OBJECT(S):  CONSEXEC, NASCONS

   OVERVIEW:  See Problems

    PROBLEM:  General EXEC LIST code cleanup, no runtime problems.

    PROBLEM1: The following error message can be generated when a
              large command list is provided via the EXEC ddname
              command:

              NASC054E EXEC CMDLIST1 FILE EXCEEDS QUEUED COMMAND
                       LIMIT, EXEC COMMAND ABORTED

    PROBLEM2: EXEC LIST command does not generate an error message
              when command list name is not provided.

DESCRIPTION1: If more than 512 bytes of command data and data length
              bytes are listed in the command list identified by the
              ddname argument, the NASC054E message will be generated
              even if the command list contains an embedded EXEC
              command (which ends the current command list) listed
              early in the command list file.  The problem occurs
              because the decode of the embedded EXEC command is
              not performed until after the entire command list is
              read into memory.  Some users like the ability to list
              many commands in an EXEC command list beyond the EXEC
              command for use at a later time.  The current logic
              prevents large numbers of saved commands to be listed
              in a command list file.

DESCRIPTION2: If EXEC LIST is specified, the following messages are
              generated:

              HNASCMD-> EXEC LIST
              HNASXEQ-> EXEC LIST
              NASC055I EXEC SYSPRINT FILE HAS BEEN READ,
                       IT WILL NOW BE LISTED
              EXEC          COMMAND LIST CONTAINS THE FOLLOWING:
              HNASCMD->

              No data is listed.

   SOLUTION1: The EXEC command processor has been modified to stop
              queuing commands when it detects an embedded EXEC
              command or the new END statement.  This will allow you
              to save commands beyond the EXEC or END command in a
              command list file.  For example, if a command list
              file was constructed as follows:

              DNAS JCL
              ALARM LOG=?
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              END
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'

              and you entered: EXEC cmdlist1 LIST

              the following output would be produced:

              HNASXEQ-> EXEC CMDLIST1 LIST
              NASC055I EXEC CMDLIST1 FILE HAS BEEN READ,
                       IT WILL NOW BE LISTED
              EXEC CMDLIST1 COMMAND LIST CONTAINS THE FOLLOWING:
              => DNAS JCL
              => ALARM LOG=?
              => SMSG 'THIS LONG MESSAGE IS DESIGNED TO FLOOD CONCMDQ'
              => END

              Note that if the LIST argument was omitted, only these
              4 commands would be executed.

   SOLUTION2: The EXEC command processor has been modified to issue
              following message if EXEC LIST is specified without a
              command list:

              NASC052E EXEC COMMAND LIST WAS NOT PROVIDED,
                       REQUIRED FOR EXEC COMMAND

              In addition, the following message will be issued if
              EXEC ddname is specified but the named command list
              dataset is empty (contains no commands or display
              comments (# text) but may contain non-display comments
              ('* text')):

              EXEC ddname FILE IS NULL, EXEC COMMAND ABORTED


CIRCUMVENTION1: Break a large command list into multiple smaller 
                command lists by chaining them together. For 
                example: 

                  CMDLIST1: command11 
                            command12
                            EXEC CMDLIST2 

                  CMDLIST2: command21 
                            command22 
                            EXEC CMDLIST3 
                  
                  etc. 

CIRCUMVENTION2: 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). 

2007-04-09  - APAR 2400033  (was unpublished problem 2007085A)

       APAR:  2400033_R  
     STATUS:  CLOSED
  OPEN_DATE:  2007-04-03
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-04-09
 SERVICE(S):  PING console command processing
  MANDATORY:  YES
 ORIGIN/REF:  240_NBG
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  REFRESH (due to 2400032 requirements)
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

   OVERVIEW:  See problems.

    PROBLEM1: An 0198 ABEND (NASHALT) can occur when PING dmyname
              is entered and the REMOTE identified by dmyname has
              FAC=NONE or CUD=NONE specified.

    PROBLEM2: Bogus data can be transmitted when PING dmyname is
              entered and the REMOTE identified by dmyname has
              DTEADDR=NONE or DCEADDR=NONE specified.

DESCRIPTION1: When FAC=NONE or CUD=NONE is specified, internally
              it is remembered by X'FF' as the FAC= or CUD= string
              length. X'FF' can be used because the FAC= and CUD=
              strings are limited to 63 (X'3F') bytes of data.
              Unfortunately, the PING command 'forgot' that X'FF'
              meant NONE and instead used the X'FF' as a valid
              string length.  This caused the next buffer in the
              buffer pool to be overlaid which resulted in the
              0198 ABEND.  Note that the buffer length is not
              checked to ensure that PING data will fit because
              the minimum buffer size for the PING XOT packet was
              was established to accommodate the maximum FAC= and
              CUD= string lengths.

DESCRIPTION2: When DTEADDR=NONE or DCEADDR=NONE is specified,
              internally it is remembered by X'FF' as the first
              byte of the DTEADDR= or DCEADDR= string.  The string
              length is actually the first nibble of the first byte.
              Like PROBLEM1, the PING command failed to recognize
              X'FF' as meaning NONE and used the value as a bad
              length.  This resulted in corrupted data being sent
              in the Call Request packet.

   SOLUTION1: The PING command processor has been modified to
              process FAC=NONE and CUD=NONE correctly.

   SOLUTION2: The PING command processor has been modified to
              process DTEADDR=NONE and DCEADDR=NONE correctly.

CIRCUMVENTION1: Manually code valid FAC= and CUD= values on the
                REMOTE named dmyname.

CIRCUMVENTION2: Manually code valid DTEADDR= and DCEADDR= values
                on the REMOTE named dmyname.

 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).  

2007-04-09  - APAR 2400032  (was problem 2005118A)

       APAR:  2400032_RE  
     STATUS:  CLOSED
  OPEN_DATE:  2005-04-28
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-04-09
 SERVICE(S):  Console MRMT LOGTAB= and USSTAB= reload enhancement.
  MANDATORY:  NO, but recommended.
 ORIGIN/REF:  230_AXA
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

    OVERVIEW: See problem.

    PROBLEM:  Customer modifies LOGTAB while HNAS is running but
              modified member is not loaded by MRMT LOGTAB=lgtbname
              command.

DESCRIPTION:  Currently, the way MRMT LOGTAB=lgtbname works is that if
              the LOGTAB name is already known to HNAS when the MRMT
              command is given (via LOGTAB= in the CDF), the original
              version is used.  HNAS keeps one copy in memory and
              searches all references for it so does not have to load
              a second copy into memory.  Only when the name is new
              is it loaded in.  Thus, the existing logic will not
              allow a modified LOGTAB (or USSTAB or NRITAB) to be
              dynamically loaded if it was loaded from the CDF.

   SOLUTION:  The MRMT command has been modified to accept the new
              reload option for the LOGTAB=, USSTAB= and NRITAB=
              operands.

              Syntax: MRMT rmtname LOGTAB=lgtbname-R
                      MRMT rmtname USSTAB=ustbname-R
                      MRMT rmtname OPTIONS=NRITAB=nrtbname-R

              When the -R follower is omitted, the old logic is used.
              That is, the given lgtbname, ustbname or nrtbname is
              compared against all LOGTAB=, USSTAB= or NRITAB= names,
              respectively, currently is use.  If the name found, the
              given LOGTAB=, USSTAB= or NRITAB=  is copied from the
              found REMOTE to the specified REMOTE.  If the name is
              not found, the given LOGTAB=, USSTAB= or NRITAB= is
              LOADed in.

              When the -R follower is specified, the given table is
              loaded in unconditionally even if it is already present.
              The new version of the table is propagated to all other
              REMOTEs that share the table.

              Note1: Because the transmission of a USSMSG in a USSTAB
                     can span task dispatches (and TCPIP interrupts),
                     HNAS will refuse to reload a USSTAB if it is
                     currently being used for a USSMSG transmission.
                     In this case, the following message is issued:

                     NASC031W USSTAB ISTINCDT IS CURRENTLY IN USE,
                              RETRY MRMT COMMAND LATER

                     This is the case because of a potential ABEND
                     that can result due to an addressing exception
                     if the new table alters USSMSGs currently being
                     transmitted.

                     Further, if you attempt to load a table that is
                     not appropriate for the specified operand, for
                     example a USSTAB for a LOGTAB (LOGTAB=ISTINCDT),
                     the following message is issued:

                     NASC030E LOGTAB ISTINCDT HAS INVALID FORMAT,
                              MRMT COMMAND ABORTED

              Note2: The following message is also issued if you
                     specify the wrong table in the CDF, for example
                     a USSTAB for a LOGTAB (LOGTAB=ISTINCDT):

                     NAS1311E REMOTE mchname LOGTAB=ISTINCDT IS NOT
                              A VALID LOGON TABLE, REQUIRED

                     THIS NEW MESSAGE WILL PREVENT HNAS FROM STARTING.

                     Prior to this APAR, you would not have known that
                     a bad table was specified until it was accessed
                     during call setup.

                     For a bad USSTAB=, the following message is
                     issued and the call is cleared:

                     NAS5702E LU sluname  ADDRESSES INV USSTAB

                     For a bad LOGTAB= value, no action is taken
                     (treated as if no LOGTAB= value was specified).
                     In this case USSTAB= is used.  If the USSTAB=
                     operand is (also) missing, the following message
                     is issued and the call is cleared:

                     NAS5703E LU sluname  MISSING USSTAB

              Note3: Effective with APAR 2400032, most console error
                     messages will now include the name of the command
                     that generated the message.  For example:

                     NASC013E UNSUPPORTED FUNCTION,
                              cmdname COMMAND ABORTED

              In addition to the MRMT change, the DRMT command has
              been modified to display the time and date that a
              LOGTAB, USSTAB or NRITAB is loaded in.  This allows the
              operator to tell whether the table was loaded in when
              the CDF was scanned (HNAS start time) or subsequently
              via the MRMT command.

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). 

2007-03-29  - APAR 2400031  (was problem 2007015B) 

       APAR:  2400031_E  
     STATUS:  CLOSED
  OPEN_DATE:  2007-01-15
 CLOSE_DATE:  2007-29
 SERVICE(S):  VTAM Alert Messages
  MANDATORY:  NO
 ORIGIN/REF:  240_CMB
     CPTECH:  PRT
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400031.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2007-03-03
              With APAR: 2400028 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHRSP
  SOURCE(S):  N/A

   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:  Sense data has been added to the NAS3711 alert message.
              In addition the severity code will be 'W' if HNAS will
              terminate the VTAM session because of the -RSP and 'I'
              otherwise.

              NAS3711{I|W} LU lu-name RECEIVED -RSP SENSE=xxxxxxxx
                        FROM PLU plu-nm LUBST1/2=yyyy LUBSST1/2=zzzz

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). 

2007-03-09  - APAR 2400030  (was unpublished problem 2007043A)

       APAR:  2400030  
     STATUS:  CLOSED
  OPEN_DATE:  2007-02-12
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-03-09
 SERVICE(S):  Console PING/MON TAP Command SYSCONS Messages
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400030.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400028 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  NASTCP,   XFWTO
  OBJECT(S):  CONSALRM, CONSPING, CONSPRNT, CONSSHOW, CONSTALL,
              CONSTPRT, CONSTRTR, CONSVARY, NASUTIL

   OVERVIEW:  See Problem

    PROBLEM:  NAS251xM MON TAP and NAS261xM PING messages are
              displayed on SYSCONS when they should not be.

DESCRIPTION:  Logic introduced by APARs 2400021 and 2400022 that
              allows monitor messages to be routed to SYSCONS using
              ALRMFLTR=(...,NAS2***M(FC),...) has a side affect that
              allows these messages to go to SYSCONS when ALRMFLTR=
              is omitted.  This is because the default alarm action
              is ALLOW when ALRMFLTR= is not specified.  When ALLOW
              is in effect, the SHOW state is then used to filter
              alarm messages.  The default SHOW state is SHOWERR
              which prevents severity I (Informational) and severity
              M (Monitor) alarms from going to SYSCONS but allows
              severity W (Warning), E (Error) and S (Severe Error)
              to be routed to SYSCONS.

              MON TAP and PING messages are issued using the XFWTO
              macro with FLOW=BISYNC which allows messages to be
              processed as console command output and as alarm
              messages.  When FLOW=BISYNC is specified, the message
              severity is erroneously set to W (Warning) instead
              of M (Monitor).  Since the message severity is set
              W, it passes the SHOWERR test and is written to
              SYSCONS.

   SOLUTION:  The XFWTO interface has been modified to set the
              message severity for MON TAP and PING messages to
              M (Monitor) so that they will be prevented from
              going to SYSCONS when ALLOW is the default ALRMFLTR=
              action.  These messages will only be routed to
              SYSCONS when the (FC) or (FU) action override is
              used for the monitor messages in the ALRMFLTR=
              message list.

CIRCUMVENTION: Specify ALRMFLTR=(SUPPRESS)

 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).  

2007-03-07  - APAR 2400029  (was problem 2006247B)

       APAR:  2400029_E 
     STATUS:  CLOSED
  OPEN_DATE:  2006-09-04
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-03-07
 SERVICE(S):  Configuration, AMNF generation - GATE
  MANDATORY:  NO
 ORIGIN/REF:  230_ZAG
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400029.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400028 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CNFGVTAM, NASCNFG

   OVERVIEW:  See problems.

    PROBLEM1: Currently, VTAM parameters (parms) that are specified
              on an MCH are not propagated to the GATE control
              session SLUs defined on APPL statements in the AMNF
              during a FASTRUN execution.

    PROBLEM2: Currently, VTAM parameters (parms) that are specified
              on an MXT associated with a PVC SLU are not propagated
              to the SLU defined on the APPL statement in the AMNF
              during a FASTRUN execution.

DESCRIPTION1: HNAS will propagate MCH VTAM parms for GATE data
              session SLUs but NOT for GATE control session SLUs.
              For the latter, the configuration will force only
              DLOGMOD=INTERACT,EAS=1 as VTAM parms when the APPL
              statements are created during a FASTRUN execution.

DESCRIPTION2: HNAS will propagate MCH VTAM parms for a PVC SLU but
              NOT MXT VTAM parms when an MXT is associated with a
              PVC SLU, e.g., :

                PVC=(...,sluname/llc/apid/lcn/ifnm/rmtnm/mxtnm,...

              The VTAM parms on the MXT named mxtnm are ignored for
              a PVC SLU.

   SOLUTION1: The HNAS configuration has been modified to pass MCH
              VTAM parms to the GATE control session SLUs as is done
              now for the GATE data session SLUs when the AMNF is
              generated during FASTRUN execution.

              In a FUTURE enhancement, we will consider allowing an
              MXT to be associated with the control session SLUs so
              that VTAM parms specified on the MXT could be used to
              override the VTAM parms on the MCH for control session
              SLUs only.  This would allow separate VTAM parms for
              control and data session SLUs.  THIS CHANGE IS NOT
              INCLUDED WITH THIS APAR.

   SOLUTION2: The HNAS configuration has been modified to pass MXT
              VTAM parms to a PVC SLU when the AMNF is generated
              during FASTRUN execution if an MXT is associated with
              the SLU in the PVC operand.  This makes PVC AMNF
              processing consistent with SVC0 and SVC5 processing.

CIRCUMVENTION1: Manually code VTAM parms in the AMNF for GATE control
                session SLUs if the default values are not correct.

CIRCUMVENTION2: Manually code VTAM parms in the AMNF for PVC SLUs
                if the MCH values are not correct.

 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).   

2007-03-05  - APAR 2400028  (was problem 2006163A & unpublished 
                                 problems 2007046A, 2007057A)
       APAR:  2400028_R  +E
     STATUS:  CLOSED
  OPEN_DATE:  2006-06-12 for problem 2006163A
              2007-02-15 for problem 2007046A
              2007-02-26 for problem 2007057A
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-03-03
 SERVICE(S):  Configuration and Console processing for LOCAL,
              REMOTE and SLU INIT= parameter and other related
              console command processors.
  MANDATORY:  NO, but recommended.
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD/PRT
  PTF_CLASS:  STANDARD-APAR also includes enhancements
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

    OVERVIEW: This APAR contains a collection general maintenance
              bug fixes, console VARY LCL abend fix as well as
              product enhancements.  See Problems:

    PROBLEM1: V sluname {ON|OFF} console command allows an SLU to
              be varied offline and back online but there is no CDF
              operand that allows SLU to be configured initially
              offline.

    PROBLEM2: An ABEND can occur when RTEIN= pointer is referenced
              after V lclname LCL {ON|OFF} command is issued.

    PROBLEM3: DLU and DVC commands do not distinguish between
              dedicated SVC callout SLUs and PVC SLUs in display
              output.

    PROBLEM4: The wrong error message is generated when the specified
              vclmt value for PVC= or SVCi= operand exceeds the array
              size.

    PROBLEM5: NAS7719T FOR SPU (QLLC) CALLOUT (TRCMCH OCR message)
              contains bad characters for the LU name when the call
              is placed on behalf of a QLLC SPU.

DESCRIPTION1: See problem.

DESCRIPTION2: V lclname LCL {ON|OFF} command processor modifies a
              field in the LOCAL configuration area (LCOPT6OF)
              but erroneously uses the offset into the REMOTE
              configuration area (RMOPT6OF) which happens to be
              the RTEIN= pointer in the LOCAL.  The result is
              that the RTEIN= pointer is corrupted which causes
              an ABEND the next time it is referenced.

DESCRIPTION3: The DLU command display for dedicated SVC callout SLUs
              and PVC SLUs shows 'P' (permanent) in the LUOPT column.
              Unless the SLU name is known to be a PVC, there is no
              way to know if the SLU is an SVC callout SLU or a PVC
              SLU.

DESCRIPTION4: When the vclmt value that is specified for the PVC= and
              SVCi= operands exceed their respective array sizes, the
              following error message is generated (for example):

              NAS1321E ERROR: REMOTE   PVC=(256,

              The appropriate message should be:

              NAS1303E LIMIT: REMOTE   PVC=(256,

              When the vclmt value is too large subsequent, PVC=
              and/or SVCi= values will get the NAS1321E value because
              the vclmt value has not been set.  The maximum vclmt
              values are as follows:

              PVC   SVC0   SVC3   SVC4   SVC5
              255    511    255    511    511

DESCRIPTION5: See PROBLEM 5.

   SOLUTION1: HNAS has been modified to accept an initial state value
              after the sluname in the LUNAME=, PVC= and SVCi=
              operands.  Syntax: SVCi=(...,sluname-{A|I}/.....)
              -A is for active and -I is for inactive or idle with
              active being the default.

   SOLUTION2: V lclname LCL {ON|OFF} command processor has been
              modified to update LCOPT6OF instead of RMOPT6OF.

   SOLUTION3: The DLU command processor has been modified to prefix
              the VCN for a PVC with the character 'P' to indicate
              that the SLU is for a PVC.  The VCN that follows the
              'P' can range from 000 to 255.  For an SVC, the VCN
              column will show a 4 character VCN that can range
              from 0000 to 4095.

   SOLUTION4: The PVC= and SVCi= processors have been modified to
              generate the NAS1303E message rather than the NAS1321E
              message when their respective vclmt value is too large.

   SOLUTION5: Logic corrected to display the QLLC SPU name when the
              callout is for an HNAS QLLC SPU.

CIRCUMVENTION1: N/A

CIRCUMVENTION2: N/A

CIRCUMVENTION3: Refer to the configuration file to determine if
                the resource is configured as a PVC or SVC.

CIRCUMVENTION4: N/A

CIRCUMVENTION5: 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).  

2007-02-21  - APAR 2400027  (includes unpublished problem 2007045A)  

       APAR:  2400027
     STATUS:  CLOSED
  OPEN_DATE:  2007-02-14 for problem 2007045A
REVISE_DATE:  2007-mm-dd
 CLOSE_DATE:  2007-02-21
 SERVICE(S):  Console subsystem, queued commands.
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400027.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400024, 2400022, 2400021, 2400017, 2400016
              and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  NASTCP, XFNASWA
  OBJECT(S):  CONSDMCH, CONSEXEC, CONSMLCL, NASCONS, NASUTIL

    OVERVIEW: See problems.

    PROBLEM1: After APAR 2400016 is applied, EXEC (cmd1,...,cmdn)
              no longer executes cmd1 through cmdn, but only
              executes cmdn.

    PROBLEM2: The DLU command that results from the DMCH FMT3
              command can be executed out of order if DMCH FMT3
              is part of a command list.

    PROBLEM3: The VARY lclname LCL ON|OFF command that results from
              the MLCL lclname INIT=ACTIVE|IDLE command can be
              executed out of order if MRMT lclname INIT=ACTIVE|IDLE
              is part of a command list.

    PROBLEM4: The EXEC cmdlist command that results from the TRCTRAP
              TRAPACTION=(EXEC=ddname) operand can be executed out
              of order if trace trap occurs when a command list is
              already running.

DESCRIPTION1: Logic introduced with APAR 2400016 resets queued
              counts before each command in the inline command
              list is processed which causes each command in the
              list to be placed at the beginning of the queue.
              Since cmdn is the last command in the list, it
              becomes the only command in the queue.

DESCRIPTION2: The DMCH FMT3 command schedules the DLU command by
              enqueing it in the queued command area.  The problem
              can occur because the enqueue is FIFO and not LIFO
              which means the DLU command is queued after all
              other queued commands in the list.

DESCRIPTION3: Same reason as Problem #2, that is, the VARY command
              is enqueued FIFO instead of LIFO.

DESCRIPTION4: Same reason as Problem #2, that is, the EXEC command
              is enqueued FIFO instead of LIFO.  This can delay the
              processing of the new command list that is intended to
              be executed immediately when a trace trap hit occurs.

   SOLUTION1: The EXEC console command processor has been modified
              to reset the queued command counts before the command
              list is processed and not between commands in the list.

   SOLUTION2: The DMCH FMT3 command has been changed to enqueue the
              DLU command in a LIFO manner so that it immediately
              follows the DMCH command.

   SOLUTION3: The MRMT lclname INIT=ACTIVE|IDLE command has been
              changed to enqueue the VARY command in a LIFO manner
              so that it immediately follows the MRMT command.

   SOLUTION4: The trace trap logic has been modified to enqueue the
              EXEC command in a LIFO manner so that it is executed
              immediately on a trace trap hit.

CIRCUMVENTION1: N/A

CIRCUMVENTION2: N/A

CIRCUMVENTION3: N/A

CIRCUMVENTION4: 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).  

2007-02-08  - APAR 2400026

       APAR:  2400026  
     STATUS:  CLOSED
  OPEN_DATE:  2007-02-08
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-02-08
 SERVICE(S):  PFXWTO command fix after APAR 2400014 applied
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400026.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400014 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CONSPWTO

   OVERVIEW:  See problem.

    PROBLEM:  The PFXWTO command can be rejected when 'text' is given
              followed by another PFXWTO command.

DESCRIPTION:  Due to changes introduced by APAR 2400014, the following
              sequence (which appears in the HNAS console subsystem
              documentation) no longer works.

              PFXWTO pfxtext PFXWTO OFF PFXWTO CONS ON

              This sequence now generates the following error message:

              NASC512E PARAMETERS DUPLICATED, REQUIRED

              The error occurs because the second occurrence of PFXWTO
              in the command string is being interpreted as another
              pfxtext value.

  SOLUTION:   The PFXWTO command processor has been modified to
              terminate parsing and execute the parameter data
              already collected when it decodes the string PFXWTO.
              The second occurrence of PFXWTO will be executed as
              separate PFXWTO command.

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).  

2007-02-01  - APAR 2400025  (was unpublished problem 2007030A)

       APAR:  2400025  
     STATUS:  CLOSED
  OPEN_DATE:  2007-01-30
 CLOSE_DATE:  2007-02-01
 SERVICE(S):  CALLOUT
  MANDATORY:  YES
 ORIGIN/REF:  240_SDD
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
------------
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400025.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2006-10-02
              With APAR: 2400007 applied.
              Users who have not installed 2400015 should consider
              a REFRESH.
 SUPERSEDES:  N/A
  OBJECT(S):  XOTBXM
  SOURCE(S):  N/A

    PROBLEM:  HALT AT LOC xxxxxx IN XOTBXM  : INV VC

DESCRIPTION:  When multiple routers are used for outbound HNAS call
              requests (RTEOUT=(R1,R2,R3)) the above HALT can occur
              if a session terminated RPL completion:
              RECV RPL COMP, R15=04 R0=0C FDB2=0B
              is posted while HNAS is in the middle of the RTEOUT=
              list.  The error occurs because the session terminated
              completion can release the HNAS LU.  After the release,
              if a clear is received from router R1 HNAS will retry the
              call using router R2.  The HALT occurs when the call
              request packet builder detects that the VC has no LU.
              The session terminated RPL completion can be posted when
              the program owning the PLU is canceled.

   SOLUTION:  Logic corrected so that the callout operation ends
              correctly when a session terminated is posted.

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).  

2007-01-31  - APAR 2400024

       APAR:  2400024  
     STATUS:  CLOSED
  OPEN_DATE:  2007-01-31
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-01-31
 SERVICE(S):  MLCL command fix after APAR 2400021 applied
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400024.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400021 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CONSMLCL

   OVERVIEW:  See problem.

    PROBLEM:  The MLCL command does not update NEWDEFN CDF correctly
              after APAR 2400021 is applied.

DESCRIPTION:  Due to changes to the XFCNFGWA macro for APAR 2400021
              which were not picked up by assembling the CONSMLCL
              module, the NEWDEFN file is not updated correctly
              when MLCL lclname RTEIN=mchname/dteaddr is entered.
              This causes bogus information to be displayed when
              the DNWDF lclname LOCAL command is entered.

  SOLUTION:   The MLCL command processor has been assembled to pick
              up the changes to XFCNFGWA for APAR 2400021.

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).  

2007-01-30  - APAR 2400023

       APAR:  2400023  
     STATUS:  CLOSED
  OPEN_DATE:  2007-01-29
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-01-30
 SERVICE(S):  DMAP trace entry list display
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400023.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400021 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CONSDMAP

   OVERVIEW:  DMAP display can give erroneous information for some
              modules.

    PROBLEM:  The DMAP command does not always display the correct
              value in the LGTM column when TRIDxxxx is displayed
              in the REFID column.

DESCRIPTION:  For example, when DMAP NASTCP is entered, the following
              is displayed:

              MODULE  ADDRESS  SIZE ASMDATE   REFNO REFOF REFID   LGTM
              NASTCP  0005FC30 9A80 2007/01/30   01  964A TRIDDBUG  NO
                                                 02  8A2E TRIDIBFR YES
                                                 03  868C TRIDIPRM YES
                                                 04  8B5C TRIDRBFR  NO
                                                 05  8758 TRIDSBFR YES
                                                 06  8D22 TRIDTDAT YES
                                                 07  88EE TRIDTDAT  NO
                                                 01  3EE6 2400004
                                                 02  0410 2400022

              The LGTM column in the above display is incorrect for
              the NASTCP module.  The correct display is as follows:

              MODULE  ADDRESS  SIZE ASMDATE   REFNO REFOF REFID   LGTM
              NASTCP  0005FC30 9A80 2007/01/30   01  964A TRIDDBUG YES
                                                 02  8A2E TRIDIBFR YES
                                                 03  868C TRIDIPRM YES
                                                 04  8B5C TRIDRBFR  NO
                                                 05  8758 TRIDSBFR  NO
                                                 06  8D22 TRIDTDAT  NO
                                                 07  88EE TRIDTDAT  NO
                                                 01  3EE6 2400004
                                                 02  0410 2400022

              The error occurs because of bad address arithmetic
              while locating the trace flags in modules that are
              greater than X'7FFF' in length.

  SOLUTION:   The DMAP command processor has been modified to correct
              the address arithmetic that is used to locate the trace
              flags.

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).  

2007-02-01  - APAR 2400022  (was problem 2006342A)

       APAR:  2400022_E  
     STATUS:  CLOSED
  OPEN_DATE:  2006-12-07
REVISE_DATE:  2007-02-01 - remove WIP notation
PRVCHG_DATE:  2007-01-30
 CLOSE_DATE:  2007-01-30
 SERVICE(S):  Console PING/MON TAP Command SYSCONS Message Option
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400022.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400014 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  NASTCP
  OBJECT(S):  CONSPING

    PROBLEM
ENHANCEMENT:  Would like to be able to route NAS2xyyM PING and MON TAP
              monitor status messages to SYSCONS as well as SYSPRINT.

DESCRIPTION:  PING dmyname will now produce monitor status messages
              for SYSPRINT that can also (optionally) be displayed
              on the SYSCONS.

              NAS2613M PINGING SOCKET=a.b.c.d(port) FOR consname
              NAS2613M         DTEADDR=lddd...ddd DCEADDR=lddd...ddd
              NAS2613M         FAC=xx...xxx
              NAS2613M         CUD=xx...xxx
              NAS2615M PING COMPLETED FOR consname, CLEAR REQUEST
                       RECEIVED, CAUSE/DIAG=ccdd
              NAS2617M PING COMPLETED FOR consname, CALL ACCEPT
                       RECEIVED
              NAS2611M PING TIMED OUT FOR consname

              MON rmtname TAP will continue to generate standard
              TAP monitor status messages for SYSPRINT that can also
              (optionally) be displayed on the SYSCONS.

              NAS2513M CLIENT=010.117.056.100(02190)
                       SOCKID=0002 PCEID=000B NAME=R1CNIN
              NAS2513M XOT TAP SEQUENCE IS STARTING,
                       TRANSMITTING CALL REQUEST
              NAS2513M PKT=0000001010010B000001000000C8D5C1E2E3C1D7
              NAS2515M CLIENT=010.117.056.100(02190)
                       SOCKID=0002 PCEID=000B NAME=R1CNIN
              NAS2515M XOT TAP SEQUENCE IN PROGRESS,
                       RECEIVED CLEAR REQUEST
              NAS2515M PKT=000000051001130342
              NAS2513M CLIENT=010.117.056.100(02190)
                       SOCKID=0002 PCEID=000B NAME=R1CNIN
              NAS2513M XOT TAP SEQUENCE IN PROGRESS,
                       TRANSMITTING CLEAR CONFIRM
              NAS2513M PKT=00000003100117
              NAS2517M CLIENT=010.117.056.100(02190)
                       SOCKID=0002 PCEID=000B NAME=R1CNIN
              NAS2517M XOT TAP SEQUENCE COMPLETED SUCCESSFULLY

   SOLUTION:  HNAS has been modified to allow new PING messages of the
              form NAS261xM to be routed to SYSPRINT and optionally
              to SYSCONS using the ALRMFLTR= (FU) mechanism as follows:

              ALRMFLTR=(...,NAS261*M(FU),...) on BUILD or

              ALARM FILTER=(...,NAS261*M(FU),...) console command.

              HNAS has been modified to allow MON TAP messages of the
              form NAS251xM to be routed to SYSCONS using the ALRMFLTR=
              operand as follows:

              ALRMFLTR=(...,NAS251*M(FU),...) on BUILD or

              ALARM FILTER=(...,NAS251*M(FU),...) console command.

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). 

2007-01-27  - APAR 2400021  (was problem 2006334D and unpublished
                            problem 2006020A)                   
       APAR:  2400021_E  
     STATUS:  CLOSED
  OPEN_DATE:  2006-01-20 for problem 2006020A
              2006-11-30 for problem 2006334D
REVISE_DATE:  2007-01-27 - Memo updated.
PRVCHG_DATE:  2007-01-26
 CLOSE_DATE:  2007-01-26
 SERVICE(S):  Heartbeat alarm message and SYSCONS alarm routing
  MANDATORY:  NO
 ORIGIN/REF:  230|240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400021.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400018 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  SYSLIN, XFBLK, XFCNFGWA, XFMODMAP, XFNASWA, XFXTRN
  OBJECT(S):  CNFGAFLT, CNFGPLSE, CNFGPVC,  CNFGSVC0, CNFGSVC3
              CNFGSVC5, CONSALRM, CONSDMAP, CONSDNWD, CONSMRMT
              NASCNFG, NASUTIL

    OVERVIEW: This Enhancement APAR addresses the following console
              and debugging improvements:

    PROBLEM1: Requirement for a new CDF parameter and console
              command capable of generating a heartbeat or pulse
              message at a designated interval.

    PROBLEM2: Require the ability to route Information messages
              to SYSCONS that are normally only logged to SYSPRINT
              due to current SHOW state.

DESCRIPTION1: Customer reported a five hour hung condition between
              router and HNAS.  The HNAS SYSPRINT log shows a five
              hour time gap when normal session event activity
              should be present.  It was as if HNAS is not being
              dispatched.  It appears that the CPU or task
              initiator has been stopped or HNAS has been swapped
              out for a higher priority task (HNAS is supposed to
              run non-swappable with the same dispatch priority as
              TCPIP and VTAM).

              Once the SYSPRINT log activity resumed, sessions
              that were previously connected during the unusual
              stop or hung condition encountered Clear response
              timeout indications.  Customer cannot explain the
              five hour gap in the SYSPRINT log file and claims
              that the CPU and initiator were not stopped.

              During the 'gap' period, customer reports that 2000
              callin sessions failed.  There is no record as to
              why the calls failed in the HNAS SYSPRINT log (HNAS
              did not see them).

              Note that the same router used by this HNAS was
              operating correctly with other HNAS images.

              If HNAS would have been issuing heartbeat alarm
              messages at regular intervals, their absence from
              absence from the SYSPRINT log would prove that HNAS
              was not being dispatched and this would explain the
              2000 callin failures.

DESCRIPTION2: Would like the ability to route specific Informational
              alarms messages to SYSCONS without having to set the
              SHOWON start parameter or SHOW ON console command.

   SOLUTION1: HNAS has been modified to accept the new PULSE operand
              on the BUILD definition statement.  The syntax is as
              follows:

                     |<-------------------- pulse start time (PST)
                     |
                     |        |<----------- pulse end time (PET)
                     |        |
                     |        |        |<-- pulse frequency (PR)
                     |        |        |
                     V        V        V
              PULSE=(hh:mm:ss,hh:mm:ss,seconds)

              The pulse (or heartbeat) message will be issued every
              PR seconds between the times of PST to PET.  PET may
              be smaller than PST in which case the pulse interval
              wraps through midnight.  If PST=PET, pulsing will be
              continuous.  The pulse alarm message has the
              following form:

              NAS0299I HNAS PULSE TAKEN AT ff:mm:ss ON yyyy/mm/dd

              The purpose of the message is to provide an indication
              that HNAS is being dispatched on a regular basis.
              The SYSPRINT log file will contain the NAS0299I
              message.  The message can also be sent to SYSCONS if
              ALRMFLTR=(...,NAS0299I(FU),...) is also specified on
              BUILD or if the ALARM FILTER=(...,NAS0299I(FU),...)
              console command is issued (see problem2 for new
              ALRMFLTR= suffix values.

              The PULSE operand can also be modified dynamically
              using the ALARM PULSE=(hh:mm:ss,hh:mm:ss,seconds)
              console command.

   SOLUTION2: HNAS has been modified to accept new suffix values for
              the ALRMFLTR= operand.  In addition to existing override
              actions of (A), (S) and (P), HNAS now accepts (FC) for
              force conditionally and (FU) for force unconditionally.

              (FC) specifies that the filtered alarm message is to be
              sent to SYSCONS subject to the current SHOW state.

              For example, if ALRMFLTR=(...,NAS2020I(FC),...) is
              specified, the NAS2020I alarm messages will be sent
              to SYSCONS except when SHOWOFF is effect.

              (FU) specifies that the filtered alarm message is to be
              sent to SYSCONS regardless of the current SHOW state.

              For example, if ALRMFLTR=(...,NAS0299I(FU),...) is
              specified, the NAS0299I alarm messages will be sent to
              SYSCONS even when SHOWOFF is in effect.

CIRCUMVENTION1: N/A

CIRCUMVENTION2: 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).  

2007-01-18  - APAR 2400020  (was unpublished problem 2007011A)  

       APAR:  2400020  
     STATUS:  CLOSED
  OPEN_DATE:  2007-01-11
   REV_DATE:  2007-01-18 - ZIP file repackaged to correct ASM library.
                           Do not use 2007-01-17 *.zip file.  
 CLOSE_DATE:  2007-01-17 - edistribution correct as of this date.
 SERVICE(S):  QLLC
  MANDATORY:  RECOMMENDED
 ORIGIN/REF:  230_CPA (2300205)
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400020.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2006-08-30
              With APAR: 2400003 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  VCCLEAR
  SOURCE(S):  N/A

    PROBLEM:  HALT AT LOC xxxxxx IN VCRCLR  : QLLC CLEAR LOGIC ERR
              due to an unusual timing sequence.

DESCRIPTION:  This problem is a result of a logic error in the HNAS
              QLLC receive Clear routine.  At our lab the problem
              occurred when a QLLC session was terminated with a
              VTAM command while HNAS was shutting down.

   SOLUTION:  Clear logic corrected.

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).  

2007-01-15  - APAR 2400019

       APAR:  2400019  
     STATUS:  CLOSED
  OPEN_DATE:  2006-12-21 - Problem 1
              2007-01-12 - Problem 2
REVISE_DATE:  N/A
 CLOSE_DATE:  2007-01-15
 SERVICE(S):  Console Alarm Messages
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400019.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400017, 2400016, 2400014 and associated APAR chains.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CONSSHOW, CONSTALL, CONSTRTR, NASPRNT

   OVERVIEW:  This APAR is an extension to APAR 2400016 (1) and a
              correction to APAR 2400017 (2).

   PROBLEM1:  Some forced alarm messages can be filtered out when
              they should not be.

   PROBLEM2:  Two independent alarm messages use the same message
              ID of NAS0111W.

DESCRIPTION1: For example:

              NAS0204E SYSPRINT LOG FILE IS FULL, LOGGING TERMINATED

              This message is important because it tells the operator
              the HNAS SYSPRINT logging has been stopped. Operator
              can then either restart HNAS or open a new SYSPRINT log
              file (see PRNT console command for details).

              Messages like the above are subject to filtering when
              they should not be because the message severity
              defaults to 'E' (the last character of the message ID).

DESCRIPTION2: Prior to APAR 2400017, the NAS0111W alarm message
              was reserved for ALARMS LOST notification.  With
              the introduction of the PRNT and SHOW command alarm
              messages in enhancement APAR 2400017, the NAS0111W
              message ID was inadvertently used for the SHOW OFF
              alarm.

  SOLUTION1:  Messages that deal with SYSCONS and SYSPRINT problems
              are now issued with MSGSEV=U (unconditional) rather
              with MSGSEV= defaulting to the last character of the
              message ID.  This prevents them from being filtered
              using the BUILD ALRMFLTR= operand.  These messages
              are considered critical and must not be allowed to be
              filtered out.

  SOLUTION2:  The SHOW alarm message IDs have been changed from
              NAS011xs to NAS012xs in order to avoid conflicts.

CIRCUMVENTION1: N/A

CIRCUMVENTION2: 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).  

2007-01-18  - APAR 2400018  (was problem 2006254A & 2300204)

       APAR:  2400018  
     STATUS:  CLOSED
  OPEN_DATE:  2006-12-20
   REV_DATE:  2007-01-18 - ZIP file repackaged to correct ASM library.
                           Do not use 2007-01-13 *.zip file.  
 CLOSE_DATE:  2007-01-13 - edistribution correct as of this date.
 SERVICE(S):  Configuration: CDF parsing, IDLETO= operand processing
              and new information messages
  MANDATORY:  YES
 ORIGIN/REF:  230/240_CPA,240_CPT
     CPTECH:  PRT/SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400018.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2006-12-28
              With APAR: 2400017 applied.
 SUPERSEDES:  N/A
  SOURCE(S):  N/A
  OBJECT(S):  CNFGIDTO , CNFGPVC  , CNFGSVC0 , CNFGSVC3 , CNFGSVC5 ,
              CNFGTYPE , CONSDRMT , CONSMRMT , MCHHL0RQ , MCHHL5RQ ,
              MCHPVCI  , NASCNFG  , NASUTIL  , QLSSCP   , VCUT1    ,
              XOTFCDC  , XOTGTCC  , XOTRCV

    OVERVIEW: This APAR addresses the following configuration,
              runtime and alert message problem issues:

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

    PROBLEM2: NASHALT 0198 ABEND can occur during TYPE= operand
              processing.

    PROBLEM3: Configuration messages cannot be filtered from the
              SYSPRINT log.

    PROBLEM4: It is not always obvious which MCH operands are
              overridden by those from an MXT that is associated
              with a PVC= or SVC0/3/5= operand entry.

DESCRIPTION1: Customer is having problems with hung LLC0 LUs.  The
              LUs are unaware that the TCP/IP session is gone. The
              problems 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.  Using VTAM to INACT/ACT
              the HNAS SLU with lost session also corrects the problem.

              This situation occurs when a SVC0=, SVC3= or SVC5=
              string on a TYPE=MCH REMOTE addresses a TYPE=MXT REMOTE
              coded without an IDLETO= parameter.  When this is done
              a 0 IDLETO value is recorded for the MXT and this value
              incorrectly overrides the IDLETO= value coded on BUILD
              or on the TYPE=MCH REMOTE.

DESCRIPTION2: If the TYPE= operand is specified on the same record
              as another operand and the operands are separated by
              a space character rather than a comma, the TYPE= value
              will not be decoded properly.  This results in the
              NASHALT in the CNFGRTYP subroutine.  This ABEND can
              also occur if an invalid TYPE= operand value is
              specified.

DESCRIPTION3: Heretofore, HNAS specifically prevented configuration
              messages (NAS1xxxs) from being filtered using the
              BUILD ALRMFLTR= operand.  This prevents the user from
              deleting repetitive (although potentially interesting)
              messages from the SYSPRINT log.

DESCRIPTION4: When a user associates an MXT with a PVC= or SVC0/3/5=
              operand entry, he is asking HNAS to override operands
              on the root MCH with those from the MXT.  In some cases,
              this can lead to confusion if one does not remember to
              review the HNAS documentation to see which operands can
              be overridden based on the associated resource type.

   SOLUTION1: The configuration logic has been modified so that run
              time code can detect that no IDLETO= value was coded on
              an MCH/MXT/SPU REMOTE.  HNAS call setup logic will set
              the IDLE timeout interval using the SPU value (if coded),
              the MXT value (if coded), the MCH value (if coded) and
              lastly, the BUILD value (with a zero default).

   SOLUTION2: The configuration logic has been modified to allow a
              space as well as a comma to be used as an operand
              separator character (this is the case in V2R3 but
              was erroneously changed for V2R4).  In addition,
              HNAS will now default to TYPE=XTP if an invalid
              TYPE= operand value is specified.  This will almost
              surely cause HNAS to terminate at the end of the
              CDF scan with RC=12.  However, error messages will
              be issued instead of an ABEND so the problem can be
              easily corrected.

   SOLUTION3: HNAS has been modified to allow configuration messages
              to be filtered using the BUILD ALRMFLTR= operand.
              Filtering will commence as soon as the ALRMFLTR=
              operand is processed.  This logic was added primarily
              for the new NAS1391I message (see below).

   SOLUTION4: The configuration logic has been modified to display,
              for each SLU or SPU defined in the PVC= or SVC0/3/5=
              operands with an associated MXT (or SVC), those MXT
              operands that will override operands of the same name
              on the root MCH.

              Not all MXT operands are valid overrides for all SLUs
              or SPUs.  For example, IDLETO= is a valid override
              when specified for an MXT that is associated with
              a SVC0/5= SLU but is not used for a PVC SLU.

              MXT override messages are listed at the end of the CDF
              scan in NAS1391I messages.  Only those MXT operands
              that are specified and, of these, only those that are
              valid as overrides for an SLU or SPU are displayed.
              If an MXT operand is not listed, it is because it was
              either omitted from the MXT (an hence cannot override
              the MCH operand) or, if specified, is not valid as
              an override for the SLU or SPU resource.  Consider
              the following configuration example:

              MCH1     REMOTE TYPE=MCH
                             IDLETO=2
                             PAD=INTEG
                             PADPARM=(1/1,
                                      2/1,
                                      13/7,
                                      21/0,
                                      110/0)
                             PVC=(3,
                             MCH1P001/5/255/01/SERIAL0-1/R2CNOT1/MXT0,
                             MCH1P002/5/255/02/SERIAL0-1//MXT2,
                             MCH1P003/5/255/03/SERIAL0-1)
                             SVC0=(2,
                             MCH10011/1234-X1234-<MXT1>T01/MXT0
                             MCH10012/1234-<MXT0>-X1234T1)
                             SVC5=(2,
                             MCH15001/1234-X1234-<MXT1>T01/MXT0
                             MCH15002/1234-<MXT0>-X1234T1)
                             SVC3=(1,Q1990100//MXT0)
                             :
              MXT0     REMOTE TYPE=MXT
                             CUD=(01111111)
                             DCEADDR=1111
                             DTEADDR=9999
                             FAC=(420808
                                  430404)
                             IDLETO=15
                             PADPARM=(1/1,
                                      2/1,
                                      3/2,
                                      4/0,
                                      5/2,
                                      7/2,
                                      12/1,
                                      13/7,
                                      21/0,
                                      110/0)
              MXT1     REMOTE TYPE=MXT
                             CUD=(01222222)
                             DCEADDR=2222
                             FAC=(0101420A0A430202)
                             PADPARM=(1/1,
                                      2/1,
                                      7/2,
                                      12/1,
                                      13/7,
                                      21/0,
                                      110/0)
              MXT2     REMOTE TYPE=MXT
                             CUD=(01222222)
                             DCEADDR=2222
              Q1990100 REMOTE TYPE=SPU
                             LUNAME=(,
                             Q1990102/201/201/1/PVCMXT,
                             Q1990103)
                             DTEADDR=20361234
                             DCEADDR=20364321
                             FAC=420707430707
                             CUD=C3000000
                             IDBLK=199
                             IDNUM=00001
                             :

              Based on this configuration, the following messages
              are generated at the end of the CDF scan.

NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH1P001 (DEFINED ON MCH MCH1
NAS1391I AS PVC ENTRY 000) COME FROM MXT MXT0     RATHER THAN THE MCH
NAS1391I --> FAC=420808430404
NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH1P002 (DEFINED ON MCH MCH1
NAS1391I AS PVC ENTRY 001) COME FROM MXT MXT2     RATHER THAN THE MCH
NAS1391I --> NO OVERRIDES
NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH10011 (DEFINED ON MCH MCH1
NAS1391I AS SVC0 ENTRY 0000) COME FROM MXT MXT0     RATHER THAN THE MCH
NAS1391I WHEN CONNECTION IS NOT ESTABLISHED VIA A <RMTNAME>
NAS1391I --> CUD=01111111
NAS1391I --> DCEADDR=1111
NAS1391I --> DTEADDR=9999
NAS1391I --> FAC=420808430404
NAS1391I --> IDLETO=00015
NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH10011 (DEFINED ON MCH MCH1
NAS1391I AS SVC0 ENTRY 0000) COME FROM MXT MXT1     RATHER THAN THE MCH
NAS1391I WHEN CONNECTION IS ESTABLISHED VIA <MXT1>
NAS1391I --> CUD=01222222
NAS1391I --> DCEADDR=2222
NAS1391I --> FAC=0101420A0A430202
NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH10012 (DEFINED ON MCH MCH1
NAS1391I AS SVC0 ENTRY 0001) COME FROM MXT MXT0     RATHER THAN THE MCH
NAS1391I WHEN CONNECTION IS ESTABLISHED VIA <MXT0>
NAS1391I --> CUD=01111111
NAS1391I --> DCEADDR=1111
NAS1391I --> DTEADDR=9999
NAS1391I --> FAC=420808430404
NAS1391I --> IDLETO=00015
NAS1391I THE FOLLOWING OPERANDS FOR SPU Q1990100 (DEFINED ON MCH MCH1
NAS1391I AS SVC3 ENTRY 0000) COME FROM MXT MXT0     RATHER THAN THE MCH
NAS1391I WHEN THEY ARE OMITTED FOR THE SPU
NAS1391I --> CUD=01111111
NAS1391I --> DCEADDR=1111
NAS1391I --> DTEADDR=9999
NAS1391I --> FAC=420808430404
NAS1391I --> IDLETO=00015
NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH15001 (DEFINED ON MCH MCH1
NAS1391I AS SVC5 ENTRY 0000) COME FROM MXT MXT0     RATHER THAN THE MCH
NAS1391I WHEN CONNECTION IS NOT ESTABLISHED VIA A <RMTNAME>
NAS1391I --> CUD=01111111
NAS1391I --> DCEADDR=1111
NAS1391I --> DTEADDR=9999
NAS1391I --> FAC=420808430404
NAS1391I --> IDLETO=00015
NAS1391I --> PADPARM=001/001 002/001 003/002 004/000 005/002 007/002 ...
NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH15001 (DEFINED ON MCH MCH1
NAS1391I AS SVC5 ENTRY 0000) COME FROM MXT MXT1     RATHER THAN THE MCH
NAS1391I WHEN CONNECTION IS ESTABLISHED VIA <MXT1>
NAS1391I --> CUD=01222222
NAS1391I --> DCEADDR=2222
NAS1391I --> FAC=0101420A0A430202
NAS1391I --> PADPARM=001/001 002/001 007/002 012/001 013/007 021/000 ...
NAS1391I THE FOLLOWING OPERANDS FOR SLU MCH15002 (DEFINED ON MCH MCH1
NAS1391I AS SVC5 ENTRY 0001) COME FROM MXT MXT0     RATHER THAN THE MCH
NAS1391I WHEN CONNECTION IS ESTABLISHED VIA <MXT0>
NAS1391I --> CUD=01111111
NAS1391I --> DCEADDR=1111
NAS1391I --> DTEADDR=9999
NAS1391I --> FAC=420808430404
NAS1391I --> IDLETO=00015
NAS1391I --> PADPARM=001/001 002/001 003/002 004/000 005/002 007/002 ...

              Note 1: The NAS1391I message for SLU MCH1P001 above only
                      displays the FAC= operand for MXT0 even though
                      other operands were specified.  This is because
                      only the FAC= operand is used as a PVC SLU
                      override operand.

              Note 2: The NAS1391I message for SLU MCH1P002 shows 'NO
                      OVERRIDES' because the FAC= operand for was
                      omitted for MXT2.  Note that no NAS1391I message
                      is issued for SLU MCH1P003 since no MXT was
                      associated with this SLU.

              Note 3: The NAS1391I messages for the SVC3= operand
                      above list MXT overrides when operands are
                      omitted from the SPU.  The order is MXT first,
                      SPU then MCH.  This only applies when SPU
                      connections are established via the MCH and
                      not by IDBLK/IDNUM matching which is MCH
                      independent.

              Note 4: The SVC0= and SVC5= operands above are identical
                      except for the SLU names.  Note that the NAS1391I
                      messages for the SVC0= and SVC5= operands are
                      the same except that the PADPARM= operand is
                      listed for SVC5= SLUs (when specified on the MXT)
                      while it is not for SVC0 SLUs.  This is because
                      only SVC5= SLUs use the PADPARM= operand.

              Note 5: The NAS1391I messages are generated only when an
                      SLU or SPU has an associated MXT as provided in
                      the PVC= or SVC0/3/5= operand.  If you wish to
                      withhold the NAS1391I messages from the SYSPRINT
                      log, specify ALRMFLTR=(...,NAS1391I(P),...)
                      on the BUILD definition statement.

              Note 6: If you plan on filtering NAS1391I messages from
                      SYSPRINT, we highly recommend that you first
                      run a FASTRUN pass without filtering so that
                      these important messages are at least displayed
                      once for your perusal.

CIRCUMVENTION1: When a SVC0/3/5= definition string uses a MXT pointer,
                code IDLETO=value on the named TYPE=MXT REMOTE if idle
                timeout logic is required.

CIRCUMVENTION2: Specify a valid TYPE= value.

CIRCUMVENTION3: N/A

CIRCUMVENTION4: 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).

sum240_2006 

2006-12-28  - APAR 2400017  (were problems 2004301A, 2006055A (DNWD)
                             2006334C and 2006342C)
       APAR:  2400017_E  
     STATUS:  CLOSED
  OPEN_DATE:  2006-12-21
REVISE_DATE:  N/A
 CLOSE_DATE:  2006-12-28
 SERVICE(S):  Console modifier/display and debug enhancements
  MANDATORY:  NO
 ORIGIN/REF:  230|240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400017.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400016 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSALRM, CONSDNWD, CONSEXEC, CONSPRNT, CONSQUIT,
              CONSSHOW, CONSTPRT, NASCNFG, NASUTIL
  SOURCE(S):  NASMAIN, XFBLK, XFCNFGWA, XFGBLS

    OVERVIEW: This Enhancement APAR addresses the following console
              and debugging improvements:

    PROBLEM1: HNASXEQ changes for DNWDF command which was deferred
              from APAR 2400014 is now provided.

    PROBLEM2: PRNT ON|OFF console command does not write command
              action alarm message to SYSCONS which can cause
              confusion if command is entered from a remote
              console.

    PROBLEM3: SHOW ON|OFF console command does not write command
              action alarm message to SYSCONS which can cause
              confusion if command is entered from a remote
              console.

    PROBLEM4: Enhancement allowing console command '# comments' to
              be displayed in SYSPRINT HNASCMD-> output.

DESCRIPTION1: See problem.

DESCRIPTION2: See problem.

DESCRIPTION3: See problem.

DESCRIPTION4: There are 3 ways to write single line # comments
              to SYSPRINT:

              1 - via the modify interface:

                  /f jobname,# comments

              2 - via the BUILD CONCMDQ=(# comments',...)

                  HNASCMD-> # comments

              3 - via CMDLISTs (EXEC cmdlist)

                  'hlq.HNASCNTL(PINGIT)'

                  # PINGIT command list start
                  PING PINGRTR1
                  PAUSE
                  PING PINGRTR2
                  PAUSE
                  # router 3 is currently offline, ping will timeout.
                  PING PINGRTR3
                  # PINGIT command list end

                  In either case the SYSPRINT log will display:

                  HNASCMD-> # comments

                  Command list will also generate this message:

                  HNASCMD-> # router 3 is offline, ping will timeout.


   SOLUTION1: DNWDF command has been modified to echo it's execution
              parameters like all other commands.

   SOLUTION2: PRNT command processor has been modified to issue the
              following alarm messages when PRNT ON|OFF is issued:

              For ON:

              NAS0210I SYSPRINT LOGGING ENABLED BY consname

              For OFF:

              NAS0211W SYSPRINT LOGGING DISABLED BY consname

              Note: PRNT ON is forced when HNAS SHUTDOWN is requested
                    via the QUIT command so that JOB ending console
                    command output will be logged in SYSPRINT.
                    Starting with this APAR, the DNAS and ALARM LOG=?
                    commands will both be executed during SHUTDOWN
                    processing.  Prior to this APAR, only ALARM LOG=?
                    was executed at SHUTDOWN.  This is done to provide
                    needed information for Comm-Pro problem diagnosis
                    should it become necessary.

   SOLUTION3: SHOW command processor has been modified to issue the
              following alarm messages when PRNT ON|OFF|ERR is issued:

              For ON:

              NAS0110I SYSCONS ERROR AND INFO ALARM OUTPUT
                       ENABLED BY consname

              For OFF:

              NAS0111W SYSCONS NON-FORCED ALARM OUTPUT
                       DISABLED BY consname

              For ERR:

              NAS0112I SYSCONS ERROR ALARM OUTPUT
                       ENABLED BY consname

   SOLUTION4: The console command decoder has been modified to look
              for a # character in record column 1 and treat it and
              what follows as a comment record.  The comment record
              will be displayed in the HNASCMD-> command display.


CIRCUMVENTION1: N/A

CIRCUMVENTION2: N/A

CIRCUMVENTION3: N/A

CIRCUMVENTION4: 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). 

2006-12-13  - APAR 2400016  (was problem 2006341A)

       APAR:  2400016  
     STATUS:  CLOSED
  OPEN_DATE:  2006-12-07
REVISE_DATE:  N/A
 CLOSE_DATE:  2006-12-13
 SERVICE(S):  Console Command Processing (under APAR 2400014)
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400016.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400014 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CONSDLU, CONSDMCH, CONSDPCE, CONSDVC, CONSEXEC,
              CONSMMEM, NASCONS, NASUTIL
  SOURCE(S):  N/A

   OVERVIEW:  Enhancement APAR 2400014 introduced a number of
              new and useful features into the HNAS console
              subsystem, chief among which was the echoing
              of command execution parameters and modifiers
              (HNASXEQ->) In spite of exhaustive testing, some
              anomalies and problems were also introduced.
              This APAR remedies these issues.

   PROBLEM1:  NASC054E EXEC cmdlist FILE EXCEEDS QUEUED COMMAND
              LIMIT, COMMAND LIST IGNORED message generated.

   PROBLEM2:  MMEM echo message suppressed when ECHOXEQ NO is in
              effect can cause confusion with ENTER YES or NO
              message.

   PROBLEM3:  Some default parameters are not echoed for the
              DLU, DMCH, DPCE and DVC commands.

DESCRIPTION1: See problem.

              Logic changes introduced in APAR 2400014 causes the
              multi-element command list to terminate.

              While this doesn't affect the operation of HNAS it
              can cause some user defined command lists to end
              prematurely.

              This bug only affects EXEC command lists and does
              not affect multiple console commands on a single
              command line.

              Bug occurs because the command queue is not being
              re-initialized when a new command list is processed.
              This results in the new command list being appended
              to the end of the command queue which will eventually
              result in the NASC054E message.

DESCRIPTION2: The following message was pulled when the HNASXEQ
              logic was added because it duplicated the HNASXEQ
              message.

              NASCONS MMEM ADDRESS=dddddddd DATA=xx...xx

              However, when ECHOXEQ NO is in effect no data is
              displayed before the following message:

                           ENTER: N=ABORT, Y=APPLY

              This can cause confusion.

DESCRIPTION3: The problem is caused by the fact that parameters are
              displayed only if their associated flag is set ON.  For
              some parameters, flag OFF is also a valid state.  That
              is, the same flag is used for two actions or parameters.
              For example, for the SHOWNAME|SHOWADDR parameter, flag
              ON=>SHOWADDR and OFF=>SHOWNAME.  Since the echo logic
              only displays parameters when its associated flag is
              ON, SHOWNAME will not be displayed.

  SOLUTION1:  The EXEC command list processor has been modified to
              re-initialize the command queue area prior to
              populating it with the new command list.

  SOLUTION2:  The original question message has been restored which
              will only be issued when ECHOXEQ NO is in effect.

  SOLUTION3:  The DLU, DMCH, DPCE and DVC command echo logic has
              been changed to allow parameters with OFF state flags
              to be displayed.

 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-12-13  - APAR 2400015  (was unpublished problem 2006344A)

        APAR:  2400015  
      STATUS:  CLOSED
   OPEN_DATE:  2006-11-30
 PRVCHG_DATE:  2006-12-05
 REVISE_DATE:  2006-12-13
  CLOSE_DATE:  2006-12-05
  SERVICE(S):  Console MRMT Processing
   MANDATORY:  YES
  ORIGIN/REF:  230_SDD
      CPTECH:  SFD
   PTF_CLASS:  STANDARD-APAR
    PTF_TYPE:  REFRESH
     PTF_LOC:  Contact Support Services for Refresh E-distribution.

    PROBLEM1: S0C4 ABEND in MCHSOL with R1=X'40404040' can occur due
              to a bug in the MRMT logic.

    PROBLEM2: The MRMT command can be rejected with a NASC313E
              message when an MXT name is being added to an SVC0=
              or SVC5= entry.

DESCRIPTION1: LLC0 LU HAS X'40404040' LUMXT field.  The ABEND results
              when this value is used as an address.  The SVC0=
              string for the resource (addressed via LUCNFGPT) has
              the X'40404040' value at the SVC0MXT offset.

              Problem caused by the use of the MRMT command to add a
              new LU to the SVC0= operand list.  No MXT was specified
              with the new LU name so the MXT name (SVC0MXT) was set
              to blanks.  When the new LU was selected at session
              setup time, MCHSOL was called to process application
              selection.  The invalid SVC0MXT field was used because
              it was not zero which is required when an MXT is not
              associated with an SVC0= LU entry.

              Note: This problem also exists for the SVC5= operand.

DESCRIPTION2: Due to a bad test on the REMOTE type, the MXT that is
              named in an SVC0= or SVC5= update request is rejected
              even though it really is an MXT.  The wrong base
              register was being used to perform the REMOTE type
              test.  The MRMT command is rejected and the following
              error message is issued:

              NASC313E REMOTE MXT1 IS NOT TYPE=MXT, REQUIRED

   SOLUTION1: The MRMT console command processor has been modified
              to set SVCiMXT=0 when a new LU is added to the SVCi=
              operand.  If an MXT name is specified either at the
              same time or at a later time, the SVC0MXT field will
              be set to the correct MXT address.

   SOLUTION2: The MRMT console command processor has been modified
              to use the correct base register when testing the
              REMOTE type.

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). 

2006-12-05  - APAR 2400014  (was problem 2005277B, 2006055A and 2006118B)

       APAR:  2400014_ER  
     STATUS:  CLOSED
  OPEN_DATE:  2005-10-04 for 2005277B
              2006-02-24 for 2006055A
              2006-04-29 for 2006118B
PRVCHG_DATE:  2006-12-04
REVISE_DATE:  2006-12-05 (ECHOXEQ=MIN Default)
 CLOSE_DATE:  2006-12-05
 SERVICE(S):  Console modifier processing and display enhancements
  MANDATORY:  NO
 ORIGIN/REF:  230_SDD,230_SIK,230|240_CPT
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

     PROBLEM: This Enhancement APAR addresses the following console
              improvements:

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

    PROBLEM2: Currently, there is no command line history of what
              modifiers and default operands are in effect when a
              command is executed other than the optional right
              side temporary modifiers that are echoed when the
              command is entered.

    PROBLEM3: DLU, DMCH and DVC displays are currently set up to
              display header information for XTP resources (IBM
              routers) when most customers use XOT resources
              (Cisco routers).

    PROBLEM4: DPCE command displays OFLN for a LOCAL or REMOTE
              resource that is defined with INIT=IDLE or after
              VARY INACT|OFF is entered.

    PROBLEM5: No error message is generated for commands like ALARM
              and EXEC when no command parameters are specified.

DESCRIPTION1: 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.

DESCRIPTION2: See PROBLEM2.

DESCRIPTION3: DLU, DMCH and DVC header displays can be confusing for
              Cisco router environments even though Console Subsystem
              documentation clearly identifies what XOT information
              is displayed in an XTP column.

DESCRIPTION4: The DPCE command displays OFLN (for OFFLINE) when
              INIT=IDLE is specified or VARY INACT|OFF is entered
              but configuration does not allow INIT=OFFLINE to be
              specified in the CDF.

DESCRIPTION5: When ALARM or EXEC is entered with no parameters,
              the commands essentially NOP and the console prompt
              is issued.  An error message is more appropriate in
              this instance to indicate that a command argument is
              required for these commands.  For other commands that
              are entered without arguments, a default parameter is
              set which allows the command to be executed.  For
              example, TRCPRNT entered by itself is treated as
              TRCPRNT ON as indicated by the HNASXEQ response.

              HNASCMD-> TRCPRNT
              HNASXEQ-> TRCPRNT ON


   SOLUTION1: For console commands that utilize remembered modifier,
              a new option operand (BPM - bypass permanent modifiers)
              has been added so that all remembered modifiers will
              be ignored when the command is executed.  With this
              new option, the user will not have to display the
              current parameters using the DPARM command to see
              what values are enabled.  The console operator can
              simply specify the right hand modifiers that are
              appropriate for the specific command.

              For example, if RNM=MCH1 and LUNM=MCH10001 are
              specified as remembered modifiers and the operator
              wants to display all LUs on MCH2, he would enter:

              DLU BPM MCH2

              Prior to this enhancement, the operator would have
              to enter:

              DLU RNM=MCH2 LUNM=

              In addition, the HELP command now displays common
              command parameters after the HELP header message.
              For example, when HELP ? is entered the following
              following is displayed:

HNASCMD-> HELP ?
HNASXEQ-> HELP HELP

COMMAND DESCRIPTION (* => PRIVILEGED)
        COMMON PARAMETERS FOR ALL COMMANDS: cmdnm parm
        parm=? to display help for cmdnm.
             BPM to bypass permanent modifiers for cmdnm.

HELP    DISPLAY CONSOLE COMMAND HELP INFORMATION
        ENTER> HELP {SHOWALL|command}

        General notes for the HELP command:

        1) HELP with no arguments will display a one line
           description for each command.
        2) HELP command will display a verbose description
           for the given command.
        3) HELP SHOWALL will display a verbose description
           for all commands.


   SOLUTION2: HNAS has been modified to display the command modifiers
              and parameters (HNASXEQ-> response) that will be used
              when the command is executed immediately before command
              execution so that the user can see what global filters
              are in effect when the command was executed.

              All valid HNAS commands will yield a HNASCMD-> and
              HNASXEQ-> response.  HNAS modifiers entered either as
              standalone or prefixing a command (left side) won't
              generate a HNASXEQ-> response because modifiers aren't
              commands.

              Note: The DNWDF command was not included in the HNASXEQ
                    change.  HNASXEQ support for the DNWDF command
                    will be added at a future time.

              Under this new logic, the customer does not have to
              enter 'DPARM MODIFIERS' and look in the DOC to see
              what was set and how it relates to the given command.
              command.

              In addition to the HNASXEQ echo logic, the new ECHOXEQ
              command was added to control how much data is echoed
              when a command is entered:

              ECHOXEQ MAX causes all applicable command modifiers
              and parameters to be echoed on multiple lines (if
              necessary) with the HNASXEQ-> prefix for each line.
              Data at the end of one line is continued on the next
              with an ellipsis (...) suffix as an indication that
              more information exists.

              ECHOXEQ MIN causes all applicable command modifiers
              and parameters to be echoed on a single line.  If
              more information exists than can be displayed on
              one line, an ellipsis (...) will terminate the line.
              ECHOXEQ MIN is the default that is established when
              the console session is started.

              ECHOXEQ NO causes the echoing of command modifiers
              and parameters to be inhibited.

              For example: when DRMT MCH1 is entered, the following
              is echoed back (note that ECHOXEQ MIN is the default).

HNASCMD-> DRMT MCH1
HNASXEQ-> DRMT RNM=MCH1 APPLNAME CONNECT CTCP CUD CUD0 DCEADDR DF...
RMTNAME  OPERAND  TYPE
MCH1     00831EAC MCH
         APPLNAME=MCHSOL     (000)
         :

              If you wish to display all modifiers and parameters
              for each command, enter ECHOXEQ MAX.  For the
              DRMT MCH1 example above:

HNASCMD-> ECHOXEQ MAX
HNASXEQ-> ECHOXEQ MAX
HNASCMD-> DRMT MCH1
HNASXEQ-> DRMT RNM=MCH1 APPLNAME CONNECT CTCP CUD CUD0 DCEADDR DF...
HNASXEQ->      LNAME DFXNAME DTEADDR FAC GATE HOME IDBLK IDNUM ID...
HNASXEQ->      LETO IFNUM INIT IPADDR LLC0 LLC3 LLC4 LLC5 LOGTAB ...
HNASXEQ->      LUNAME MAXDATA MBITCHN OPTIONS PACE PAD PADPARM PK...
HNASXEQ->      TSIZ PORT PROTOCOL PVC PWPROT SUBADDR SUBD SVC0 SV...
HNASXEQ->      C3 SVC4 SVC5 SYSL TAP TRAN TYPE USSTAB VCLMT
RMTNAME  OPERAND  TYPE
MCH1     00831EAC MCH
         APPLNAME=MCHSOL     (000)
         :

              The ECHOXEQ option will stay in effect until changed
              or until the console session is ended.


   SOLUTION3: The DLU, DMCH and DVC commands have been modified to
              display header information for both XTP and XOT
              resources.  For example, the header for the DLU
              command was changed

From:

PID  IFN  CID      VCN  RTRNAME  LUOPT STAT TYPE SLUNAME  PLUNAME
001E      00000000               L  N  IDLE PCNE MCH10001

To:

     IFN|
MPID RPID CID      VCN  RTRNAME  LUOPT STAT TYPE SLUNAME  PLUNAME
001E      00000000               L  N  IDLE PCNE MCH10001

              The new MPID column displays the PID for the MCH PCE
              that owns the displayed SLUNAME.  The IFN|RPID column
              identifies either the XTP MCH interface number (REMOTE
              TYPE=XTP,IFNUM=xx,...) or the PID for the XOT router
              PCE (REMOTE TYPE=XOT) over which the SLU is connected.


   SOLUTION4: The configuration process has been modified to accept
              INIT=ONLINE as an alternate for INIT=ACTIVE and
              INIT=OFFLINE as an alternate for INIT=IDLE.  This was
              done to provide consistency with V2R4 console displays.


   SOLUTION5: The following new console error message will be
              generated for commands that require parameters
              which are not specified:

              NASC531E PARAMETER DATA OMITTED, REQUIRED

              In addition, when parameters are specified but are
              invalid for the given command, the following new
              message is generated:

              NASC532E PARAMETER DATA INVALID, REQUIRED

              The NASC532E message above replaces the following
              message which has been retired:

              NASC522E INPUT DATA INVALID, REQUIRED

CIRCUMVENTION1: 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.

CIRCUMVENTION2: Use right side modifier overrides to reset permanent
                left side (or standalone) modifiers.

CIRCUMVENTION3: Consult Console documentation for description of
                column data.

CIRCUMVENTION4: N/A

CIRCUMVENTION5: 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).  

2006-11-24  - APAR 2400013
 
       APAR:  2400013  
     STATUS:  CLOSED
  OPEN_DATE:  2006-11-20
 CLOSE_DATE:  2006-11-24
 SERVICE(S):  SYSPRINT trace logging support
  MANDATORY:  YES
 ORIGIN/REF:  240_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400013.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  NASMAIN, XFNASWA

    PROBLEM:  A System 0C4-10 ABEND can occur while trace entries
              are being logged to SYSPRINT and ALARM messages are
              generated for a remote console session.

DESCRIPTION:  The ABEND can occur if the following combination of
              conditions are met:

              1) ALL traces are active (TRCBST, TRCSUBR, etc) and
                 TRCPRNT is active.

              2) A remote console is connected and is conditioned
                 to receive alarm messages.

              3) The SYSPRINT log increases in size due to the trace
                 entries being logged which forces the following
                 alarm message to be generated for the local SYSCONS
                 and RMTCONS:

                 NAS0200W xxxx SYSPRINT LOG RECORDS WRITTEN

              The ABEND occurs because the HNAS savearea chain
              reaches it's end while processing all this SYSPRINT
              activity.  This is not an illegal loop scenario.
              It is a legitimate sequence, albeit an unusual set
              of conditions.

   SOLUTION:  HNAS has been modified to increase the number of
              pre-allocated saveareas in order to handle the
              sequence of events described above.

CIRCUMVENTION: Reduce the number of traces that are active and/or
               do not use the remote console in alarm mode.

 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-11-21  - APAR 2400012


       APAR:  2400012    
      STATUS:  CLOSED
  OPEN_DATE:  2006-11-21
 CLOSE_DATE:  2006-11-21
 SERVICE(S):  Console Subsystem SHUTDOWN processing
  MANDATORY:  YES
 ORIGIN/REF:  240_OVR
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400012.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  2400010
 SUPERSEDES:  N/A
  OBJECT(S):  NASCONS
  SOURCE(S):  N/A

    PROBLEM:  SHUTDOWN hangs when QUIT command is issued if TCPIP
              server component(s) fail to complete initialization.

DESCRIPTION:  If an invalid IP address is specified for a LOCAL
              definition statement and INIT=ACTIVE is in effect,
              the LOCAL will not be bound to the stack.  This
              prevents the server initialization from completing.
              If /P HNAS or /F HNAS,Qx is entered to shutdown HNAS,
              SHUTDOWN will hang because of a bad test in the
              console shutdown completion logic.

              The following error message can be generated if
              HNAS successfully connects to the stack but cannot
              complete the BIND because of the bad IP address:

              NAS2231W SERVER=010.117.056.218(01998)
                       SOCKID=0000 PCEID=0007 NAME=LXOT
              NAS2231W BIND REQUEST FAILED, RC=FFFFFFFF 00000031

              Note that this message is not generated if HNAS has
              not connected to the stack.  The indication that
              HNAS has connected to the stack is signaled by the
              following message:

              NAS2050I SERVER=010.117.056.218(01998)
                       SOCKID=0000 PCEID=0007 NAME=LXOT
              NAS2050I API CONNECTION TO TCPIP HAS BEEN ESTABLISHED

   SOLUTION:  The console processor has been modified to detect
              when the SHUTDOWN process is hung due to the failed
              server initialization so the SHUTDOWN will complete.

CIRCUMVENTION: Cancel HNAS via the SDSF DA or ST menu with 'C' in
               the NP column as follows:

 NP  JOBNAME  JobID    Owner    Prty Queue      C  Pos  SAff  ASys ...
 C   LDNAS240 JOB01644 SFD         9 EXECUTION  A             SYS1
     :

 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-11-16  - APAR 2400011  (was unpublished problem 2006283A)

       APAR:  2400011_R  
     STATUS:  CLOSED
  OPEN_DATE:  2006-11-09
 CLOSE_DATE:  2006-11-16
 SERVICE(S):  DATAFONO
  MANDATORY:  NO but recommended if Datafono resources used.
 ORIGIN/REF:  240_CCS
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

    PROBLEM:  Customer would like to use custom translate table
              for Datafono sessions.

DESCRIPTION:  The Datafono translate table (which was provided by
              IBM Spain) is in CSECT XAICDTFT which is in
              hlq.HNASOBJ(MCHUT2).  MCHUT2 contains more that the
              XAICDTFT CSECT.

   SOLUTION:  This APAR facilitates replacement of the XAICDTFT CSECT
              by placing it in a separate hlq.HNASOBJ member named
              XAICDTFT.  A custom Datafono table is installed as
              follows:

              Non-SMP/E installations:
              Copy your version of XAICDTFT to hlq.HNASOBJX(XAICDTFT)
              and then run the HNASMNT job to rebuild the HNAS load
              module in hlq.HNASLOAD.  To remove the custom translate
              table delete the hlq.HNASOBJX XAICDTFT member and rerun
              HNASMNT (the Comm-Pro version of XAICDTFT will still be
              in hlq.HNASOBJ).

              SMP/E installations:
              After the TSORECV job has been run the rrrr.LNS0240.F4
              relfile PDS has the HNAS object members used to build
              HNAS.  Preserve the LNSCDTFT member and then install
              your custom XAICDTFT as member LNSCDTFT in
              rrrr.LNS0240.F4 (relfile member names must start with
              the LNS prefix (assigned to Comm-Pro by IBM)).  Your
              custom XAICDTFT can also be installed as a USERMOD.
              If this is done the MCS ++MOD statement must use the
              LNSCDTFT name.

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).   

2006-11-14  - APAR 2400010  (was unpublished problem 2006297A)

       APAR:  2400010_ER  
     STATUS:  CLOSED
  OPEN_DATE:  2006-10-24
 CLOSE_DATE:  2006-11-14
 SERVICE(S):  MRMT console command enhancement
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  240_CPA
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

    PROBLEM:  Enhancement to allow IPADDR= and PORT= values for a
              TYPE=XOT REMOTE to be modified dynamically using
              the MRMT console command.

DESCRIPTION:  Prior to this enhancement, the IPADDR= and PORT=
              values could only be changed dynamically for
              TYPE=DMY REMOTEs.  For TYPE=XOT REMOTEs, the
              IPADDR= and PORT= values could only be changed by
              stopping HNAS, updating the CDF then restarting
              HNAS.

   SOLUTION:  The MRMT console command processor has been modified
              to allow the IPADDR= and/or the PORT= values to be
              changed dynamically without having to stop HNAS.

              In order to allow this change, the target TYPE=XOT
              REMOTE must be in the offline state.  This can be
              done in the CDF by specifying INIT=IDLE or during
              execution using the VARY FORCE command.

              For example, assume that the TYPE=XOT REMOTE named
              R1CNIN was configured with IPADDR=10.117.56.100 and
              INIT=ACTIVE.  To change the IP address from its
              current value of 10.117.56.100 to 10.117.56.201,
              for example, the following command sequence would
              have to be entered:

              RNM=R1CNIN                 <- set remembered RMT name
              VARY FORCE NOPR            <- vary R1CNIN offline
              MRMT IPADDR=10.117.56.201  <- change IP address
              VARY ON NOPR               <- vary R1CNIN back online

              Notes: 1) The commands above could have been entered
                        with a temporary REMOTE name as a right side
                        modifier, e.g., VARY R1CNIN FORCE NOPR

                     2) If the MRMT command above is issued while
                        the REMOTE is online, the command will be
                        rejected and the following message issued:

                        NASC022W RESOURCE ONLINE,
                                 MUST BE OFFLINE (USE VARY)

                     3) If the MRMT command attempts to change a
                        dynamic IP address (IPADDR=DYNAMIC), the
                        command will be rejected and the following
                        message issued:

                        NASC312E RNM=rmtname CONFIG INVALID, REQUIRED

CIRCUMVENTION: Stop HNAS, change IPADDR= in CDF for respective 
               TYPE=XOT REMOTE (R1CNIN in this case) then restart 
               HNAS.

 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). 

2007-01-19  - APAR 2400009  (was problem 2006254A (2300203)
                             and APAR 2300181 & 2300189)

       APAR:  2400009  
     STATUS:  CLOSED
  OPEN_DATE:  2006-09-11
   REV_DATE:  2007-01-19 - ZIP file retired, refresh required.
                           Do not use 2006-10-23 *.zip file.  
 CLOSE_DATE:  2006-10-23 - edistribution correct as of this date.
 SERVICE(S):  GATE FC, USSTAB, USSMSG (MCHSOL)
  MANDATORY:  YES
 ORIGIN/REF:  240_ZAG,230_BMO,230_ATO
     CPTECH:  CPT,PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400009.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  Distribution dated after: 2006-10-02
              With APAR: 2400007 applied.
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHL4RQ , MCHSOL
  SOURCE(S):  N/A


    PROBLEM 1:  NAS3799I LU lu-nm ENDING SESSION ON MCH mch-nm
                HNAS CAUSE/DIAG=000/217 (00/D7) DIAGX=0007

DESCRIPTION 1: The above session end can result when fields in a 
               GATE Fast Connect data session LU are not properly
               refreshed after the PLU UNBINDs the session.

   SOLUTION 1: HNAS UNBIND logic corrected.


    PROBLEM 2: USSMSG 3 (EXTRANEOUS PARAMETER) message issued when
               keyword parameter from remote not in any USSPARM
               entry following the selected USSCMD entry.

DESCRIPTION 2: For details please see APAR 2300181 memo.

   SOLUTION 2: Logic for APAR 2300181 incorporated into V2R4M0.


    PROBLEM 3: HNAS erroneously sends USSMSG when SUPP=ALWAYS is
               specified.

DESCRIPTION 3: See PROBLEM 3.

   SOLUTION 3: Logic for APAR 2300189 incorporated into V2R4M0.


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). 

2006-10-10  - APAR 2400008  (was problem 2005018A)

       APAR:  2400008  
     STATUS:  CLOSED
  OPEN_DATE:  2005-01-18
 CLOSE_DATE:  2006-10-06
 SERVICE(S):  1) GATE (LLC4) MRMT LUNAME=* modify support 
              2) PVC NEWDEFN interface service
  MANDATORY:  NO but recommend
 ORIGIN/REF:  230_BNP,240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400008.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  APAR 2400007 and associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  CNFGPVC, CONSMRMT, NASCNFG
  SOURCE(S):  XFNASWA

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

   PROBLEM2:  PVC= entry in NEWDEFN CDF contains invalid character
              for the MCH interface name.

DESCRIPTION1: 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

DESCRIPTION2: The MCH interface name in a PVC= operand entry can
              contain a hyphen (-) as a proxy for the forward slash
              (/) character that is normally present in an interface
              name.  The hyphen proxy is required because the CDF
              treats a forward slash as a suboperand separator for
              an operand that supports multiple suboperands.  When
              the PVC entry is processed, the hyphen is replaced
              with the forward slash before it is saved in the
              NEWDEFN CDF.  The result is that if the NEWDEFN CDF
              is used as the //CONFIG CDF in a subsequent HNAS
              run, an error will occur when the PVC= operand is
              processed because of the forward slash that replaced
              the original hyphen (it is treated as a separator).

              This bug was found during testing of the MRMT LUNAME=
              enhancement for a GATE MCH that also had PVCs defined.

  SOLUTION1:  HNAS has been modified to allow the asterisk to be
              removed from or added to the pluname suboperand
              of the LUNAME= operand for a TYPE=MCH|XTP REMOTE
              definition statement to be modified using the MRMT
              console command.

              To remove, enter: MRMT {RNM=}V115 LUNAME=V115A/GTMW4000

              To add, enter: MRMT {RNM=}V115 LUNAME=V115A/GTMW4000*

              Note that you can also use this command to change
              the pluname.

  SOLUTION2:  HNAS has been modified to save the NEWDEFN CDF record
              for PVC= operand entries before the hyphen substitution
              takes place so that the NEWDEFN CDF contains the exact
              same PVC= statement as the original CDF.

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).  

2006-10-02  - APAR 2400007  (was problem was problem 2006215A and 2006115A)

       APAR:  2400007  
     STATUS:  CLOSED
  OPEN_DATE:  2006-08-03
 CLOSE_DATE:  2006-10-02
 SERVICE(S):  PVC
  MANDATORY:  YES
 ORIGIN/REF:  230_FIS/230_CSP
     CPTECH:  PRT/SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX and (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400007.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  APAR 2400006, 2400003, 2400001
              and their associated APAR chains.
 SUPERSEDES:  N/A
  OBJECT(S):  FOR PROBLEM 1 & 2: VCRESET, XOTBXM
              FOR PROBLEM 3: CNFGCNCT, CNFGLGTB, CNFGOPTS, CNFGPRSW,
                             CNFGRTIN, CNFGRTOT, CNFGSVC0, CNFGSVC3,
                             CNFGSVC4, CNFGSVC5, CNFGTRTR, CNFGTYPE,
                             CNFGUSTB, CONSEXEC, CONSMRMT, CONSPRNT,
                             CONSTRTR, NASCNFG, NASNETV, NASUTIL
  SOURCE(S):  FOR PROBLEM 3: NASMAIN, XFCNFGWA, XFNASWA

  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

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

  PROBLEM 3:  NAS1201W LOCAL RTEIN|RTEOUT OMITTED, REQUIRED
              message is being generated when only PVCs are
              specified in the CDF.

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).

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.

DESCRIPTION3: PVCs do not require RTEIN= for inbound connections
              or RTEOUT= for outbound connections because all the
              information necessary to establish PVC connections
              is provided in the PVC= operand on an MCH.  However,
              for SVCs, RTEIN= and RTEOUT= are required to provide
              routing information for inbound and outbound calls,
              respectively.  When no SVCs are configured, there is
              no need to specify RTEIN= and/or RTEOUT=.  Therefore
              the NAS1201W message shown above should be withheld.

 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.

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

 SOLUTION 3:  HNAS has been modified to detect the absence of SVC
              definitions (CONNECT=NO, SVC0=NONE, SVC3=NONE,
              SVC4=NONE and SVC5=NONE is in effect for all MCHs
              in the CDF).  If this is the case, the NAS1201W
              LOCAL RTEIN/RTEOUT OMITTED messages will not be
              generated.  Note that in this case, the PVC= operand
              on all MCHs must specify valid PVC information.
              An MCH with no PVC or SVC definitions will cause
              HNAS to terminate after the CDF is scanned.

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). 

2006-09-19  - APAR 2400006  

       APAR:  2400006  
     STATUS:  CLOSED
  OPEN_DATE:  2006-09-18
 CLOSE_DATE:  2006-09-19
 SERVICE(S):  Console Subsystem, Remote Console SIMATTN Support
  MANDATORY:  YES
 ORIGIN/REF:  230_CPT
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400006.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  NASUTIL
  SOURCE(S):  N/A

    PROBLEM:  An 0C1 ABEND can occur when the remote console output
              reaches the scroll line limit which is controlled by
              the LNCT= modifier (defaults to 23 lines).

DESCRIPTION:  When the LNCT= value is reached during console command
              output, a simulated attention (SIMATTN) condition is
              set.  The SIMATTN input processor will abort output if
              the console operator enters an 'A' character.  It will
              resume output if any other data is entered (normally
              a null line).  The 0C1 ABEND occurs because of a blown
              base register in the SIMATTN processor.

CIRCUMVENTION: N/A

   SOLUTION:  HNAS has been modified to correct the blown register
              that is passed to SIMATTN processor.

 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).   

2007-01-19  - APAR 2400005  (was unpublished problem 2006250A)

       APAR:  2400005  
     STATUS:  CLOSED
  OPEN_DATE:  2006-09-07
   REV_DATE:  2007-01-19 - ZIP file retired, refresh required.
                           Do not use 2006-09-08 *.zip file.  
 CLOSE_DATE:  2006-09-08 - edistribution correct as of this date.
 SERVICE(S):  GATE
  MANDATORY:  RECOMMENDED
 ORIGIN/REF:  230_ZAG (2300201)
     CPTECH:  PRT
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (OBJ) HNASOBJX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400005.ZIP file)
              SMP/E PTFs are provided via user request because the
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  MCHHRQ, MCHNRQC
  SOURCE(S):  N/A

  PROBLEM 1:  REQSESS operations for GATE control and Fast Connect
              (FC) data sessions are not retried when the PLU is not
              active.

  PROBLEM 2:  Enhancement to provide a NASxxxxI alert message to
              indicate that a GATE control session has been bound.

DESCRIPTION1: The HNAS LUs for GATE control sessions and GATE FC
              data sessions should always be in session with the PLU
              if the PLU name is defined in the HNAS CDF.  In order
              to establish these sessions HNAS uses a VTAM REQSESS
              macro to ask the PLU for a bind.  If the PLU is not
              active the REQSESS fails.  A NAS3702W alert is issued
              with SENSE=0857xxxx.  HNAS should retry the REQSESS
              based on the MCHTMR value (default=60 seconds).
              Because of an error in the REQSESS completion routine
              the REQSESS is not retried.

 SOLUTION 1:  REQSESS completion routine corrected so that REQSESS
              is retried.

 SOLUTION 2:  NAS3797I LU lu-nm RECEIVED BIND FROM PLU plu-nm

              The above alert message will be issued when a GATE
              control session is bound.  Previously this alert
              was only used for BINDs received for PVC LUs.

              This will eliminate the requirement to view the HNAS
              DLU command display output to confirm that the GATE
              control session is active.

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). 

2006-09-07  - APAR 2400004  

       APAR:  2400004 
     STATUS:  CLOSED
  OPEN_DATE:  2006-09-05
 CLOSE_DATE:  2006-09-07
 SERVICE(S):  TCP/IP interface support
  MANDATORY:  YES
 ORIGIN/REF:  230_NBK (2300200)
    CP_TECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  (SRC) HNASMACX
    PTF_LOC:  FTP Server Directory /hnas_maint/hnas240m/apars/
              (Complete FIX is contained in the 2400004.ZIP file)
              SMP/E PTFs are provided via user request because the 
              Comm-Pro supplied MCS is unique to each customer.
   COREQ(S):  N/A
  PREREQ(S):  N/A
 SUPERSEDES:  N/A
  OBJECT(S):  N/A
  SOURCE(S):  NASTCP

    PROBLEM:  NAS2211W CLOSE REQUEST FAILED error message erroneously
              generated due to bad socket number being passed to the
              socket CLOSE processor condition can lead to depletion
              of sockets.

              The following messages are generated when an inbound
              socket connection is received from a non-configured
              router:

              NAS2261W SERVER=010.117.056.170(01998) SOCKID=0000
                       PCEID=0007 NAME=XOTSRVR
              NAS2261W ACCEPT REQUEST FAILED, RC=EEEEEEEE FFFFFFFF
              NAS2211W SERVER=010.117.056.170(01998) SOCKID=0000
                       PCEID=0007 NAME=XOTSRVR
              NAS2211W CLOSE REQUEST FAILED, RC=FFFFFFFF 00000403
              NAS2262W SERVER=010.117.056.170(01998) SOCKID=0000
                       PCEID=0007 NAME=XOTSRVR
              NAS2262W REMOTE=010.117.056.100(51973) NOT CONFIGURED,
                       CONNECTION REJECTED

DESCRIPTION:  The NAS2261W and NAS2262W messages are correctly issued
              when an inbound socket connection is received for a
              non-configured router but the NAS2211W message is not.
              This message is being generated due to a bad socket
              number being passed the the socket CLOSE processor
              (TCPCLS).

              In addition to the erroneous NAS2211W message, the
              allocated socket remains allocated because the CLOSE
              request failed.  This means that a new connection will
              not reuse the same socket but will allocate a new one.
              If the problem persists, it is theoretically possible
              to run out of sockets which can only be corrected by
              stopping and restarting HNAS.

CIRCUMVENTION: Add a TYPE=XOT|XTP REMOTE definition statement with
               the IPADDR= operand set to the value displayed in
               in the NAS2262W message or set IPADDR=DYNAMIC.

   SOLUTION:  HNAS has been modified to correct the blown register
              that is passed to TCPCLS.

 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-08-30  - APAR 2400003  (was problem 2006054A)

       APAR:  2400003_ER  
     STATUS:  CLOSED
  OPEN_DATE:  2006-02-23
 CLOSE_DATE:  2006-08-30
 SERVICE(S):  LLC0/5 callout & callin (SVC0|5=)
  MANDATORY:  NO, but recommended
 ORIGIN/REF:  230_CCS
     CPTECH:  SFD/PRT
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

    PROBLEM:  Enhancement to associate a separate TYPE=MXT REMOTE
              with each callout and callin DTE address.

DESCRIPTION:  Prior to this enhancement, an LLC0 callout resource
              with multiple destination addresses was specified
              as follows:

                REMOTE TYPE=MCH|XTP
                       SVC0=(n,
                             sluname/dteaddr1-dteaddr2-dteaddr3{O|T}
                                    /mxtname/cud,
                             :

              When the SLU is bound by a PLU, a Call Request packet
              is generated using dteaddr1 as the called DTE address.
              If this call fails (Clear received or no response to
              Call Request packet), a call is then placed to dteaddr2
              and, if necessary, to dteaddr3.

              When a dteaddri value is specified, the MXT identified
              by mxtname above becomes the REMOTE that is associated
              with the SLU for the entire LU/VC session.  The dteaddri
              value is used as the called DTE address while the named
              MXT supplies the calling DTE address (DCEADDR= operand),
              facilities data (FAC= operand), call user data (CUD=
              operand) and for PAD calls, PAD parameters (PADPARM=
              operand).  When multiple dteaddri values are coded,
              all outbound Call Request packets will carry the same
              calling DTE address, facilities data and call user
              data because there is only one MXT pointer.

   SOLUTION:  HNAS has been modified to allow the name of an MXT
              (short for a TYPE=MXT REMOTE) or the new SVC (short
              for a TYPE=SVC REMOTE) to be specified in place of
              the dteaddri suboperands.

              When an MXT or SVC is specified as a rmtname in place
              of a dteaddri value, it becomes the REMOTE that is
              associated with the SLU for the duration of the LU/VC
              session.  In this case, it will be the REMOTE that
              provides the called DTE address (DTEADDR= operand),
              calling DTE address (DCEADDR= operand), facilities
              data (FAC= operand) and call user data (CUD= operand).
              These four operands provide all the information
              necessary to create a unique Call Request packet.

              For PAD calls that require PADPARM= values to override
              those on the root MCH, an MXT rather than an SVC should
              be used in place of a dteaddri value.  This is because
              the SVC REMOTE does not support the PADPARM= operand.

              If PADPARM= values are not required, we recommend using
              an SVC rather than an MXT for call processing.  The SVC
              control block uses less memory than the MXT.  The SVC
              control block is X'178' (376) bytes in length while the
              MXT control block is X'480' (1152) bytes in length.

              Note that when an MXT or SVC is specified in place
              of a dteaddri value, the MXT identified by mxtname
              will be ignored for the duration of the LU/VC session.
              However, if specified, this MXT will be used to supply
              VTAM parameters for the SLU during AMNF generation via
              the FASTRUN process.  If this MXT is not specified,
              VTAM parameters come from the root MCH.

              If the direction indicator at the end of the dteaddri
              list is a 'T' instead of an 'O' (twoway support) and a
              dteaddri list entry is a rmtname instead of a dteaddri,
              the named REMOTE will be used for inbound as well as
              outbound connections.  If the direction indicator is
              an 'I' and a dteaddri list entry is a rmtname instead
              of a dteaddri, the named REMOTE will be used for inbound
              connections only.   For inbound calls, the DTEADDR=
              value is used like a dteaddri value from dteaddri list.
              If the calling DTE address from the inbound Call Request
              packet matches the DTEADDR= operand value, the SLU will
              be allocated for the inbound call.

              The new syntax for the REMOTE SVC0= and SVC5= operands
              is as follows:

                REMOTE TYPE=MCH|XTP
                       SVCx=(n,
                             sluname/dteid1-dteid2-dteid3{T|O|I}
                                    /mxtname/cud,
                             :

              The new syntax for the MRMT SVC0= and SVC5= parameters
              is as follows:

                MRMT mchname
                     SVCx=sluname/dteid1-dteid2-dteid3{T|O|I}
                                 /mxtname/cud

                Where: dteidi = dteaddri (dd...dd)  (for T|O|I)
                              = Xidnumi (Xdd...dd)  (for T|I)
                              = <rmtnamei>          (for T|O|I)
                            x = 0 for SVC0 or 5 for SVC5

                CDF example to specify a dteaddr, Xidnum and <rmtname>
                value for the same SLU:

                MCH1 REMOTE TYPE=MCH
                            SVC0=(20,
                                  MCH10011/1234-X1234-<SVC1>T01/MXT0,
                                  :

                SVC1 REMOTE TYPE=SVC
                            DTEADDR=10981000,DCEADDR=20351000
                            FAC=420909430707,CUD=C0000000

                MXT0 REMOTE TYPE=MXT
                            DTEADDR=10991000,DCEADDR=20361000
                            FAC=420707430303,CUD=C0000000

                MXT1 REMOTE TYPE=MXT
                            DTEADDR=10991001,DCEADDR=20361001
                            FAC=420808430303,CUD=C0000000

                MRMT example to modify the Xidnum and <rmtname> value
                while leaving the dteaddr value alone:

                MRMT MCH1 SVC0=MCH10011/-X6789-<MTX1>

                Note that when a hyphen is entered without a preceding
                value, it acts as a place holder preserving the value
                of the skipped dteidi list entry (1234 in this case).

                DRMT example to review MRMT change:

                DRMT MCH1 SVC0=MCH10011

                RMTNAME  OPERAND  TYPE
                MCH1     0084F4E8 MCH
                         SVC0=0020
                              MCH10011/1234-X6789-<MXT1>T01/MXT0


                Notes: 1) Up to 3 dteidi values may be specified for
                          any direction identifier (T|O|I).  Xidnumi
                          values are only used for inbound connections
                          while dteaddri and <rmtnamei> values can be
                          be used for inbound and outbound connections.
                          For inbound connections, the SLU is allocated
                          if a match occurs for any dteidi value in the
                          list.

                       2) The rmtnamei in the dteidi list must be
                          enclosed in non-equivalence symbols <>.
                          The MXT|SVC addressed by an <rmtnamei>
                          operand is used for the duration of the
                          call.  That is, an MXT coded after the
                          dteidi list (/mxtname) is not used when
                          a dteidi <rmtnamei> entry is used.

                       3) A dd...dd value prefixed with an 'X' is
                          used as an IDNUM value to be matched against
                          IDNUM value that is carried in the CUD field
                          of an inbound Call Request packet.  If a
                          match occurs, the SLU is allocated to the
                          inbound call.  The  Xdd...dd value can
                          contain up to 14 paired hex digits.

                       4) A dd...dd value without the 'X' represents
                          a DTE address that is used as the called
                          DTE address in an outbound Call Request
                          packet OR is matched against the calling
                          DTE address from an inbound Call Request
                          packet.  If a match occurs, the SLU is
                          allocated to the inbound call.  The dd...dd
                          value can contain up to 15 decimal digits.

                       5) Multiple dteidi values may also be specified
                          when the direction identifier is I.  In this
                          case, inbound dteaddri or Xidnumi matching
                          will look at up to 3 values.  If <rmtnamei>
                          is specified as a dteidi value, the dteaddri
                          will come from the DTEADDR= operand on the
                          named MXT|SVC.

                       6) Xidnum values are not supported in the
                          DTEADDR= operand on a TYPE=MXT REMOTE.
                          An Xidnum value may only be specified as a
                          dteidi value.

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). 

2006-08-21  - APAR 2400002  

       APAR:  2400002_R  
     STATUS:  CLOSED
  OPEN_DATE:  2006-08-18
 CLOSE_DATE:  2006-08-21
 SERVICE(S):  Configuration BFRSIZ= processing
  MANDATORY:  NO
 ORIGIN/REF:  240_CPT
     CPTECH:  SFD
  PTF_CLASS:  STANDARD-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

    PROBLEM:  HNAS buffer header size was increased by 16 bytes which
              requires a change to the BFRSIZ= value.

DESCRIPTION:  Starting with the V2R4M0 release of HNAS, the buffer
              header was increase from 52 to 68 bytes which means if
              you specified a value that used to allow one full packet
              to fit into a single buffer, it will now require two (2)
              buffers.  This means that the value specified for BFRLMT=
              might now be too small which can cause buffer slowdown
              mode to be entered.

   SOLUTION:  HNAS has been modified to detect whether the new buffer
              header size is being used when the BFRSIZ= operand is
              processed.  If not, HNAS will automatically increase
              the BFRSIZ= value by 16 bytes and the following message
              will be issued:

              NAS1121D BUILD BFRSIZ=dddd AUTOMATICALLY INCREASED TO
                       dddd, DEBUG FIELD ADDED

              The BFRSIZ= value will not be increased by 16 bytes
              and this message will be withheld if the value you
              code for BFRSIZ= already accounts for the new 68 byte
              packet header, that is, it is one of the following
              values:

               196 = 68 + 128
               324 = 68 + 256
               580 = 68 + 512
              1092 = 68 + 1024
              2116 = 68 + 2048
              4164 = 68 + 4096
              9362 = TCPIP transfer limit

              Note that the X.25 packet size is always given as a
              power of 2 via facility code 42 therefore intervening
              values do not have to be tested.

CIRCUMVENTION: Increase the value specified for BFRSIZ= by 16 bytes.

 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-08-10  - APAR 2400001  (was unpublished problem 2006194B)


       APAR:  2400001_ER
     STATUS:  CLOSED
  OPEN_DATE:  2006-07-07
 CLOSE_DATE:  2006-08-10
 SERVICE(S):  SYSPRINT log management
  MANDATORY:  NO
 ORIGIN/REF:  240_NBG
     CPTECH:  SFD
  PTF_CLASS:  ENHANCEMENT-APAR
   PTF_TYPE:  REFRESH
    PTF_LOC:  Contact Support Services for Refresh E-distribution.

    PROBLEM
ENHANCEMENT:  Ability to dynamically allocate SYSPRINT log files 
              now provided.

DESCRIPTION:  Starting with the V2R4M0 release of HNAS, you can
              statically allocate in JCL and define in the CDF
              multiple SYSPRINT log files using the PRTSWLST=
              operand on the BUILD definition statement which
              employs the following syntax:

              PRTSWLST=({LOOP|STOP},SWITCHAFTERINIT,SWITCHATtime,
                        ddname1,...,ddnamen)

              With this definition, HNAS will switch from ddnamei
              to ddnamej (j=i+1) when an action event occurs
              (e.g., SWITCHAFTERINIT or SWITCHATMIDNIGHT), when the
              current ddnamei dataset becomes full, when the PRTLMT=
              value is reached or when manually requested using
              the PRNT NEXTPRSW console command.  DDNAME switching
              in the PRTSWLST= list will stop when the last DDNAME
              (ddnamen) is used unless LOOP is specified, in which
              case, the first DDNAME (ddname1) will be reused.

              For some users, statically allocated DDNAMEs is
              limiting because datasets can be reused and because
              it requires pre-defining DDNAME statements that may
              or may not actually get used.  To eliminate or
              supplement the need for static DDNAMEs, dynamic
              dataset allocation is required.

   SOLUTION:  HNAS has been modified to allow SYSPRINT log files
              to be dynamically allocated in addition to being
              statically allocated.  The syntax of the PRTSWLST=
              operand has been changed as follows:

              PRTSWLST=({LOOP|STOP},SWITCHAFTERINIT,SWITCHATtime,
                        {ddname1|DYNAMIC=ocls},...
                         ...,{ddnamen|DYNAMIC=ocls})

              PRTSWLST= now specifies a list of static (ddnamei)
              or dynamic (DYNAMIC=outclass) DDNAMEs that will be
              used when a SYSPRINT switch occurs for any of the
              reasons outlined above.  You may specify static
              DDNAMEs and/or request DYNAMIC DDNAME allocation
              in any combination.

              If you specify DYNAMIC= (no output class) or 
              DYNAMIC (no equal sign), class A is assumed.  
              Dynamic SYSPRINT log files are assigned DDNAMEs 
              of the form DYN#xxxx where xxxx=0001, 0002 and 
              so on.  xxxx is incremented by 1 with each new 
              dynamic allocation.  These generated DDNAMEs are
              reserved and must not be defined statically in 
              the HNAS start JCL.

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).

2006-07-22  - APAR 2400000 - Notice 

       APAR:  2400000
     STATUS:  SERVICE_NOTICE-<BEGIN_MAINTENANCE/APAR_CYCLE>
  OPEN_DATE:  2006-07-31
 CLOSE_DATE:  2007-07-31
 SERVICE(S):  ALL_V2R4M0
  MANDATORY:  N/A (PLEASE_READ_THIS_NOTICE)
 ORIGIN/REF:  N/A
   PTF_TYPE:  N/A
  PREREQ(S):  N/A
   MACRO(S):  N/A
  OBJECT(S):  N/A
  SOURCE(S):  N/A

     NOTICE:  HNAS V2M4M0 release is now available.
          
DESCRIPTION:  Standard maintenance/APARs are now provided for
              this distribution level.
 
   SOLUTION:  N/A

 APPLY_INFO:  N/A

2006-05-01  - APAR 240beta - Notice

       APAR:  230beta
     STATUS:  TESTING
  OPEN_DATE:  2005-11-01
 CLOSE_DATE:  2006-05-01
 SERVICE(S):  ALL_V2R4M0

         
DESCRIPTION:  Beta product testing underway (including Datafono).

              
              Please refer to the 240 New Features list for details.

Last Update - June 24, 2013 (combine 2006-2009)