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.
| APAR# | CLOSE_DATE | SERVICE |
PTF_TYPE |
PROBLEM |
|---|---|---|---|---|
|
240nnnn 240nnnn_D 240nnnn_E 240nnnn_I 240nnnn_M 240nnnn_P 240nnnn_R 240nnnn_U |
yyyy-mm-dd-> |
(blank) <Deferred> <Enhancement> <Internal> <Circumvention> <Pending> <Refresh> <Upgrade> |
---> ---> ---> ---> ---> ---> ---> ---> |
Denotes a Standard APAR. Fix/Enhancement deferred to later (future) release. A new function has been added by this APAR. Internal utility maintenance (not fix or enhancement) Circumvention is available, see APAR memo. APAR type pending assignment. Refresh up to/above this APAR number required. Upgrade to denoted HNAS VnRnMn has to be installed. |
| - | - | - | - | - |
|
2400nnn thru 2400112 |
<Link forward> | - | - |
HNAS V2R4M0 - 2014 MAINTENANCE SUMMARY (Link to APARs 2400112 thru 2400nnn) |
| + | + | + | + | + |
|
No APARs assigned in 2013 |
- | - | - |
HNAS V2R4M0 - 2013 MAINTENANCE SUMMARY (APARs 2400nnn down thru 2400nnn below) |
| + | + | + | + | + |
| 2400111 down thru 2400111 | - | - | - |
HNAS V2R4M0 - 2012 MAINTENANCE SUMMARY (APARs 2400111 down thru 2400111 below) |
| + | + | + | + | + |
| 2012-11-12 |
VTAM |
OBJ/SRC |
LU session ended by -RSP 2002 when brackets are started by the PLU & the SLU at the same time. |
|
| + | + | + | + | + |
| 2400110 down thru 2400106 | - | - | - |
HNAS V2R4M0 - 2011 MAINTENANCE SUMMARY (APARs 2400110 down thru 2400106 below) |
| + | + | + | + | + |
| 2011-05-19 |
PVC |
OBJ |
NASHALT AT LOC xxxxxxxx IN MCHLXBA : VTAM REQ LOST due to a very unusual condition during a PVC session restart condition where the remote does not respond to the first two packets in 90 seconds. |
|
| 2011-04-04 |
TCP/IP |
OBJ/SRC |
Sessions occasionally end with Clear CAUSE/DIAG=00/C3 indicating link transmit failed in environments where IPADDR=DYNAMIC is coded for a REMOTE. |
|
| 2011-03-09 |
Trace and |
OBJ/SRC |
Trace filtering & debugging changes introduced for
improved debugging associated with problem 2011060A
and general troubleshooting. |
|
|
2400107_R |
2011-01-15 |
Trial Product |
<Trial |
Fixes for minor problems introduced by APAR 2400106. |
|
2400106_R |
2011-01-06 |
Trial Product |
<Trial |
Changes implemented allowing Trial product distribution expiration dates to be extended dynamically and the ability to dynamically convert a trial distribution to a permanent distribution. Note: Documentation completed, Will be available in early January 2011. |
| + | + | + | + | + |
| 2400105 down thru 2400099 | - | - | - |
HNAS V2R4M0 - 2010 MAINTENANCE SUMMARY (APARs 2400105 down thru 2400099 below) |
| + | + | + | + | + |
|
2400105_E |
2010-11-15 |
TCPIP Debug |
OBJ/SRC |
Additional diagnostic logic is required to help solve the 'TCPIP REPLY ID FAILURE' ABEND problem which is enabled by the 'DBUG TCP' option - now a default option. |
|
2400104_R |
2010-10-29 |
Cons-Subsystem |
<Refresh Required> |
DNAS command does not show missing maintenance when there are holes in the APAR sequence due to a bug introduced by APAR 2400103. |
|
2400103_RE |
2010-09-21 |
Cons-Subsystem |
<Refresh Required> |
Enhancement providing DNAS display output regardless of the FASTRUN CC-rc and added z/OS level displays. |
|
2400102_+E |
2010-04-28 |
TCPIP Debug and General Maint. |
OBJ/SRC |
This APAR contains 1 fix and 3 enhancements for the following
conditions: |
| 2010-04-07 |
PVCs via sysplex distributor |
OBJ |
When one of 2 HNASs in a SD (sysplex distributor) is shutdown some PVCs do not migrate to the working HNAS LPAR. |
|
|
2400100_E |
2010-04-02 |
NASAUTH |
OBJ |
HNAS has been modified to check all HNASAUTH file fields after an error is detected and report all errors before ABENDing to improve the debugging process. |
| 2010-01-15 |
DTF (Datafono) |
OBJ |
HALT AT LOC xxxxxxxx IN MCHPQ : ELEMENT NOT FOUND. |
|
| + | + | + | + | + |
|
2400098 thru 2400000 |
<Link back> | - | - |
HNAS V2R4M0 - 2006-2009 MAINTENANCE SUMMARY (Link to APARs 2400000 thru 2400098) |
| + | + | + | + | + |
| - | - | - | - | - |
| 240nnnn_i | yyyy-mm-dd |
GATE/LLCn/ PVC/QLLC/... |
ZAP/SRC/ OBJ/DOC/ CNFG/... Refresh |
<-Brief Problem\Enhancement Description-> 240nnnn_i= APAR Type - (blank) Denotes as a Standard APAR. _D - Deferred to a later release. Memo only, no PTF (fix) issued. Corrective logic or support will be provided in a future release. _E - Enhancement-APAR assignment. Denotes enhancement introduced after initial product release date. A new function has been added by this APAR. _I - Internal Comm-Pro utility maintenance changes or improvements not directly related to standard product fixes or enhancements. Updated code included in the next HNAS Refresh edistribution. _M - Circumvention available (C reserved for custom identification). _P - Pending assignment. _R - Refresh edistribution required. To benefit from this APAR, a refresh release, up to this APAR number or most recent, has to be installed. _U - Upgrade required to the designated release. Memo only, no PTF (fix) issued. See link vrmnnnn_i table for an expanded description. |
| - | <Deferred> |
- |
<-> |
Denotes that problem resolution was deferred to a latter release although an apar memo is present describing the problem/reference. |
|
- |
- | <Enhancement> |
<-> |
Depicts an enhancement, not a problem fix. |
Please refer to the X.25 HostNAS (HNAS) Product Notices web page
section HNAS V2R4M0 - Release Status for additional information.
2013-12-31 - No APARs issued in 2013
2012-11-12 - APAR 2400111 (was problem 2012048A)
APAR: 2400111
STATUS: CLOSED
OPEN_DATE: 2012-02-17
CLOSE_DATE: 2012-11-12
SERVICE(S): VTAM
MANDATORY: RECOMMENDED
ORIGIN/REF: 240_GAD
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 2400111.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): MCHHRQ
SOURCE(S): LUD , VTMSND2
PROBLEM: LU session ended by -RSP 2002 when brackets are started
by the PLU & the SLU at the same time.
DESCRIPTION: Sequence:
1) HNAS receives data from remote.
2) HNAS sends OIC PIU to PLU with BB & CD
3) PLU sends PIU with BC EB BB to HNAS
4) HNAS rejects PIU with -RSP 0813 (bkt bid rej)
5) PLU sends PIU with EC (std error recovery ends chain)
6) HNAS rejects PIU with -RSP 2002 (chaining error)
7) PLU UNBINDs
This problem was observed under an LLC-0 session.
SOLUTION: When HNAS rejects the FIC PIU from the PLU it must set
up a chain flush mode. In this mode PLU PIUs are
discarded until the LIC PIU is received (and discarded).
CIRCUMVENTION: This problem can be circumvented by increasing the PLU
RU send size so that the PIU in step 3) is sent OIC
(BC+EC).
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).
2011-05-20 - APAR 2400110 (was problem 2011133A)
APAR: 2400110
STATUS: CLOSED
OPEN_DATE: 2010-05-13
CLOSE_DATE: 2010-05-19
SERVICE(S): PVC
MANDATORY: RECOMMENDED
ORIGIN/REF: 240_pgs
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 2400110.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: 2011-01-17
With APAR: 2400107
SUPERSEDES: N/A
OBJECT(S): VCRESET
SOURCE(S): N/A
PROBLEM: NASHALT AT LOC xxxxxxxx IN MCHLXBA : VTAM REQ LOST
DESCRIPTION: HNAS sending an M-bit chain to the remote using a PVC
session. The remote does not respond to the first two
packets in 90 seconds. The PLU sends a SIGNAL then
(a little later) an UNBIND. When HNAS restarts the
PVC session information in the VC control block that
should have been cleared when the RESET was sent causes
the NASHALT. This is a very unusual condition.
SOLUTION: PVC UNBIND / reset 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).
2011-04-04 - APAR 2400109 (was unpublished problem 2011060A)
APAR: 2400109
STATUS: CLOSED
OPEN_DATE: 2011-03-01
CLOSE_DATE: 2011-04-04
SERVICE(S): TCPIP support
MANDATORY: YES
ORIGIN/REF: 240_SRP
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 2400109.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) Previous distribution at APAR level 2400108.
SUPERSEDES: N/A
OBJECT(S): CONSDPCE, CONSMON, CONSMRMT, NASCNFG,
NASUTIL, XOTBXM, XOTUT1
SOURCE(S): NASTCP
OVERVIEW: See problem.
PROBLEM: Sessions occasionally end with Clear CAUSE/DIAG=00/C3
indicating link transmit failed.
DESCRIPTION: When the PCE control blocks are generated for a REMOTE,
the PCETAPPT pointer in every PCE for the REMOTE (up to
the VCLMT value) addresses the first PCE for the REMOTE.
When IPADDR=DYNAMIC is coded for a REMOTE, the first
PCE is just another available TCP/IP socket. When a
real IPADDR is specified for a REMOTE, the first PCE
is the TAP PCE. The TAP PCE can never be used for a
normal TCP/IP session for a VC/LU pair.
The first PCE is used for TCP/IP session statistics
regardless of whether it is the TAP PCE or an available
socket PCE. A problem occurs when the first PCE for
an IPADDR=DYNAMIC REMOTE is used for both a VC/LU
session and erroneously as the TAP PCE.
The problem occurs during processing for a REMOTE
with IPADDR=DYNAMIC because of tests that assume the
current PCE is the TAP PCE because it's address matches
the address contained in PCETAPPT (i.e., RPCE=PCETAPPT).
This test is insufficient because PCETAPPT does not
point at the TAP PCE for a IPADDR=DYNAMIC REMOTE. An
additional (or rather replacement) test is required.
The FLG1TAP flag in PCEFLGS1 is only set in the TAP PCE.
Instead of testing RPCE=PCETAPPT, logic should test
FLG1TAP to see if the current PCE is the TAP PCE.
SOLUTION: HNAS has been modified to test FLG1TAP to determine
if the current PCE is the TAP PCE. For a REMOTE with
IPADDR=DYNAMIC, this flag will never be set so the
first PCE will not also be treated as the TAP PCE.
This will eliminate the spurious Clear C3 condition.
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).
2011-03-09 - APAR 2400108
APAR: 2400108
STATUS: CLOSED
OPEN_DATE: 2011-03-01
CLOSE_DATE: 2011-03-09
SERVICE(S): Trace support
MANDATORY: YES, for improved debugging
ORIGIN/REF: 240_SRP
CPTECH: SFD
PTF_CLASS: STANDARD-APAR with diagnostic ENHANCEMENT
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas240m/apars/
(Complete FIX is contained in the 2400108.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) Previous distribution at APAR level 2400107 or above.
SUPERSEDES: N/A
OBJECT(S): CNFGTRTR, CONSSTAT, CONSTBFR, CONSTDAT, CONSTDSP,
CONSTIO, CONSTSUB, CONSTRTR, NASUTIL
SOURCE(S): NASMAIN, NASTCP, XFBLK, XFNASWA
OVERVIEW: Trace filtering & debugging changes introduced for
improved debugging associated with problem 2011060A
and general troubleshooting.
PROBLEM1: The ALRMLIST=(msgid/msgdata/msgoff) operand of the
TRCTRAP CDF operand and the TRCTRAP console command
do not allow msgdata to be specified as a quoted
string, i.e., as 'msgdata'.
DESCRIPTION1: If msgdata contains a forward slash (/), the slash will
be treated as a delimiter making the data that follows
it being treated as the msgoff suboperand. This can
cause the entire ALRMLIST value to be ignored and an
error condition to be set. For example, when the
following TRCTRAP console command is entered:
TRCTRAP ALRMLIST=(NAS3799I/DIAG=000/195)
the following error message is issued and the request
is rejected:
NASC532E PARAMETER DATA INVALID: IAG=000/195)...,
TRCTRAP COMMAND ABORTED
This is occurring because the msgdata value DIAG=000/195
contains a forward slash making the 195 that follows the
slash treated as a msgoff value. Since 195 is too large
for a msgoff value, the command is rejected.
SOLUTION1: The TRCTRAP CDF operand processor and the TRCTRAP
console command processor have been modified to accept
the msgdata suboperand of the ALRMLIST operand as a
quoted string so that ALL data within the string is
treated as data. This includes spaces, forward slashes
and so on. For the ALRMLIST operand described above,
the following is now allowed:
TRCTRAP ALRMLIST=(NAS3799I/'DIAG=000/195')
In this case, the forward slash in DIAG=000/195 is no
longer treated as an suboperand separator but as part
of the message data.
Note1: If msgdata does not contain spaces or a forward
slash, it does not have to be specified within
quotes, but can be if you wish. ABCDEF and
'ABCDEF' are treated the same.
Note2: msgdata may not include embedded quotes. For
example, ABC'DEF or ABC''DEF or 'ABC'DEF' or
'ABC''DEF' are not permitted.
CIRCUMVENTION1: N/A
PROBLEM2: Additional diagnostic logic is required to help solve
the Clear C3 (195) diagnostic code problem described
in the problem memo for problem 2011060A.
DESCRIPTION2: The Clear C3 problem requires running TRCPCE ALLON
traces as well as TRCSUBR ON subroutine call traces but
the later generates too much non-required information.
When TRCSUBR is in effect, every subroutine within
HNAS logs a number of trace entries. Some are very
useful but others just provide unwanted 'noise'.
What is necessary to eliminate unwanted TRCSUBR entries
is the ability to filter subroutine calls based on the
event(s) being processed. The TRCPCE command is used
to log TCP/IP related events. To coordinate TCP/IP
subroutine calls with these events requires filtering
TRCSUBR traces for TCP/IP related calls only.
SOLUTION2: HNAS has been modified to allow the TRCSUBR start
parameter and TRCSUBR console command to accept an
event filter list. Currently, HNAS waits on the
following 6 events:
TCP - TCP/IP interrupt completions
VTAM - VTAM interrupt completions
MCH - REMOTE TYPE=MCH service
NETV - NETVIEW interrupt completions
CONS - CONSOLE interrupt completions
PCE - Miscellaneous task service
The TRCSUBR start parameter and the TRCSUBR console
command will now accept one or more of these events to
be specified so that subroutine call traces are logged
only when the selected event(s) are being processed.
This means that only subroutine calls associated with
the selected event(s) will generate trace entries.
The syntax for the TRCSUBR start parameter and console
command is as follows:
TRCSUBR {ON|OFF} {ALLEVENTS|NOEVENTS}
{TCP|VTAM|MCH|NETV|CONS|PCE}
The following display is produced when TRCSUBR ? or
HELP TRCSUBR is entered:
TRCSUBR *SUBROUTINE CALL TRACE CONTROL
ENTER> TRCSUBR {ON|OFF} {eventlist}
eventlist = {ALLEVENTS|NOEVENTS} or
{CONS|NETV|TCP|VTAM|MCH|PCE}
General notes for the TRCSUBR command:
1) Enter ON to initiate global subroutine
call tracing.
2) Enter OFF to terminate global subroutine
call tracing.
3) Enter ALLEVENTS to set the subroutine call
trace event filter to all events.
4) Enter NOEVENTS to reset the subroutine
call trace event filter to no events.
5) Enter CONS, NETV, TCP, VTAM, MCH and/or
PCE to set the subroutine call trace filter
to specific events. You may enter NOEVENTS
followed by a list of events to first clear
then repopulate the subroutine call trace
event filter.
6) ON is assumed if TRCSUBR is entered with
no argument.
7) If NOEVENTS is in effect when ON is set,
ALLEVENTS is forced.
8) Tracing requires additional CPU cycles.
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).
2011-01-17 - APAR 2400107
APAR: 2400107
STATUS: CLOSED
OPEN_DATE: 2011-01-11
CLOSE_DATE: 2011-01-17
SERVICE(S): DNAS display processing and EOMKEY/EOTKEY generation.
MANDATORY: NO, BUT RECOMMENDED IF RUNNING UNDER 2400106.
ORIGIN/REF: 240_CPT
CPTECH: SFD
PTF_CLASS: STANDARD-APAR.
PTF_TYPE: REFRESH
PTF_LOC: N/A, provided in all trial edistributions effective
with this APAR.
OVERVIEW: Fixes for minor problems introduced by APAR 2400106.
PROBLEM1: The DNAS AUTHCHK display shows the wrong trial
expiration date (AUTHEXDT) when an EOTKEY or
EOMKEY is applied.
DESCRIPTION1: When an EOTKEY or EOMKEY is applied via the start
parameter or via the MMEM console command for a
trial distribution, the DNAS AUTHCHK display will
show the most recent trial expiration date. The
original shipped trial expiration date should be
displayed.
SOLUTION1: The DNAS AUTHCHK display logic has been corrected
so that the original trial expiration date is
displayed for AUTHEXDT. This will provide
additional information for HNAS support personnel.
The following is a sample display for DNAS AUTHCHK
after an EOMKEY has been to a trial distribution
turning it into a permanent distribution.
HOST NAS INFORMATION FOLLOWS
HNAS VERSION=V2R4M0 DIST=NON-SMP
HNAS PROGRAM RUNNING UNDER z/OS 01.11.00
HNAS PRODUCT INSTALLED UNDER z/OS 01.11.00
HNAS PRODUCT CREATED UNDER z/OS 01.11.00
DNAS COMMAND ENTERED AT 10:22:01 ON 2011/01/14
HNAS PROGRAM STARTED AT 10:19:44 ON 2011/01/14
HNAS PRODUCT INSTALLED AT 11:56:00 ON 2011/01/06
HNAS PRODUCT CREATED AT 13:21:17 ON 2010/12/31
HNAS PRODUCT CREATED WITH MAINTENANCE THROUGH APAR 2400107
MOST RECENT MAINTENANCE APPLIED IS APAR 2400107
AUTH=000 SHIPID=1100000011199999 EMKYID=1100000011199999
CUSTID=SFD_99999
CUSTINFO=COMM-PRO ASSOCIATES
MAINTENANCE/USE ANNIVERSARY DATE IS 2010/12/31*
DATAFONO SUPPORT IS INCLUDED
EOMKEY=4962030747980516 IS IN EFFECT
APARID MAINTENANCE STATUS
ALL MAINTENANCE ON THROUGH MOST RECENT APAR 2400107
NAS9210I AUTHNCDT=04324653 AUTHDCDT=20101231 AUTHDCKY=67177575
NAS9210I AUTHNCLM=2474 AUTHDCLM=003M AUTHEXDT=20110331
NAS9210I AUTHNCID=3343224833913123 AUTHDCID=1100000011199999
NAS9210I AUTHNCVR=662 AUTHDCVR=240
NAS9210I DNASSHID=1100000011199999 DNASSHVR=V2R4M0
NAS9210I AUTHNCEK=4962030747980516 AUTHDCEK=0201012311199999
NAS9205I HNAS AUTHORIZATION IS PERMANENT
NAS9206S HNAS MAINTENANCE/USE ANNIVERSARY DATE EXPIRED 0014 DAYS
NAS9206S HNAS MAINTENANCE/USE ANNIVERSARY DATE (EOMDATE) HAS EXPIRED
NAS9206S CONTACT YOUR HNAS PROVIDER IMMEDIATELY TO EXTEND YOUR EOMDATE
NAS9206S BY RENEWING YOUR MAINTENANCE/USE LICENSE AND ORDERING ONE OF
NAS9206S THE FOLLOWING EOMDATE SOLUTIONS:
NAS9206S 1) A REFRESH DISTRIBUTION WITH A NEW EOMDATE
NAS9206S 2) AN EOMKEY TO EXTEND YOUR EXPIRED EOMDATE
NAS9206S FORCED TERMINATION OF HNAS WILL OCCUR IN 031 DAYS
Note that the data in the NAS9010I messages above
comes from the original trial authorization file
while the data in the base DNAS display are
modified by the application of the EOMKEY.
PROBLEM2: The scramble index that is used to encode and decode an
EOMKEY or EOTKEY is always set to zero.
DESCRIPTION2: The scramble index is supposed to be generated randomly
so that the encoded EOMKEY or EOTKEY will likely be
different for the same key parameters each the key
generation job is run.
SOLUTION2: The scramble index generation logic has been corrected
so that a random value is used each time a key
generation job is run.
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).
2011-01-08 - APAR 2400106
APAR: 2400106
STATUS: CLOSED
OPEN_DATE: 2010-11-11
CLOSE_DATE: 2011-01-06
SERVICE(S): Trial/Permanent Distribution Authorization Processing
MANDATORY: NO
ORIGIN/REF: 240_CPT
CPTECH: SFD,PWB
PTF_CLASS: STANDARD-APAR also includes enhancements
PTF_TYPE: REFRESH
PTF_LOC: N/A, provided in all trial edistributions effective
with this APAR.
OVERVIEW: A requirement exists that will allow the expiration
date for a trial distribution to be extended dynamically
or allow a trial distribution to be converted to a
permanent distribution dynamically without having to
install a new distribution at a customer site.
PROBLEM: Currently, the only way to extend a trial distribution
authorization file expiration date or to convert a
trial distribution to a permanent distribution is to
send the customer completely new distribution files.
DESCRIPTION: Due to the fact that a new distribution is the only
way to extend a trial distribution expiration date
or to convert a trial distribution to a permanent
distribution, we normally do not send a trial
distribution to a new SMP/E customer. SMP/E users
receive a 'pseudo-temporary' distribution which is
actually a permanent distribution with a short EOMDATE
that can then be lengthened dynamically using an EOMKEY.
This is done to avoid having to install an SMP/E PTF
simply to extend a trial expiration date or to convert
from a trial to a permanent distribution.
New logic (see SOLUTION below) now allows a trial
distribution to be sent to SMP/E users as well as
non-SMP users.
SOLUTION1: HNAS has been modified to allow the EOTDATE (end of
trial expiration date) to be updated 'on the fly' using
the new MMEM EOTKEY=dd...dd console command and/or the
new PARM=(...,EOTKEY=dd...dd,...) HNAS start parameter.
The console command is provided so that HNAS does not
have to be stopped and restarted in order to extend
the EOTDATE. 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 EOTDATE update. The start
parameter makes the new EOTDATE permanent so long as
the EOTKEY start parameter is specified. The EOTDATE
will revert to it's original distribution value if the
EOTKEY start parameter is not specified or the console
command is not issued.
When a new EOTDATE is extended using an EOTKEY, the
DNAS display will reflect this using an asterisk (*)
after the date when the new EOTDATE record is written.
For example:
TRIAL PERIOD EXPIRATION DATE IS 2011/01/28*
In addition, the AUTH= value in the DNAS display will
be updated to reflect the new EOTDATE.
Notes: 1) The EOTKEY 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
EOTKEY string contains a new EOTDATE 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 EOTKEY as
well as other identifying information. The
given EOTKEY will then have to be copied and
pasted as a MMEM console command argument or
a start parameter. The new EOTKEY file has
the following format:
EOTKEY=4961000737880526
HNAS EOTKEY CREATED AT 08:17:02 ON 2010/11/29
TRIAL PERIOD EXPIRATION DATE IS 2011/01/28
CUSTID=SFD_99999
CUSTINFO=COMM-PRO ASSOCIATES
ETKYDC=0201101281199999
3) If an invalid dd...dd string is specified,
HNAS will issue an error message but will
continue running.
4) The EOTDATE is automatically checked by HNAS
at midnight every day after the following
message is generated:
NAS0910I 3 BELLS AND ALL IS WELL AT 00:00:00
ON yyyy/mm/dd
Additional NAS9xxxs alarm messages are issued
as the EOTDATE approaches expiration.
As part of this APAR, the following new error messages
are provided:
NAS9203W HNAS EOTKEY IS INVALID, CUSTID DOES NOT
MATCH, IGNORED
NAS9203W ETKYCID=99990 HNASCID=99999
NAS9203W HNAS EOTKEY IS INVALID, EOTDATE IS TOO
LOW, IGNORED
NAS9203W ETKYEOT=20110128 HNASEOT=20110301
The messages above are issued if the supplied EOTKEY
contains a CUSTID value in error or an EOTDATE that
is less than the EOTDATE currently in effect (shown
in the DNAS 'TRIAL PERIOD EXPIRATION DATE' display).
For trial distributions, the DNAS display will have the
following form:
HOST NAS INFORMATION FOLLOWS
HNAS VERSION=V2R4M0 DIST=SMP/E 1
HNAS PROGRAM RUNNING UNDER z/OS 01.11.00 2
HNAS PRODUCT INSTALLED UNDER z/OS 01.11.00 3
HNAS PRODUCT CREATED UNDER z/OS 01.11.00 4
DNAS COMMAND ENTERED AT 18:54:01 ON 2010/12/01 5
HNAS PROGRAM STARTED AT 18:54:01 ON 2010/12/01 6
HNAS PRODUCT INSTALLED AT 08:12:00 ON 2010/11/29 7
HNAS PRODUCT CREATED AT 08:19:12 ON 2010/11/28 8
HNAS PRODUCT CREATED WITH MAINTENANCE THROUGH APAR 2400106 9
MOST RECENT MAINTENANCE APPLIED IS APAR 2400106 10
AUTH=032D SHIPID=1100000011199999 11
CUSTID=SFD_99999 12
CUSTINFO=COMM-PRO ASSOCIATES 13
TRIAL PERIOD EXPIRATION DATE IS 2010/12/31 14
DATAFONO SUPPORT IS INCLUDED 15
16
17
APARID MAINTENANCE STATUS 18
ALL MAINTENANCE ON THROUGH MOST RECENT APAR 2400106 19
If EOTKEY=4961000737880526 (for example) is used to
extend the EOTDATE, DNAS display lines 11, 14 and 16
will be modified as follows:
AUTH=060D SHIPID=1100000011199999 ETKYID=1100000011199999 11
TRIAL PERIOD EXPIRATION DATE IS 2011/01/28* 14
EOTKEY=4961000737880526 IS IN EFFECT 16
Note that AUTH=060D reflects the new EOTDATE.
AUTH=EOTDATE-CREATEDATE=2011/01/28-2010/11/29=60Days.
SOLUTION2: HNAS has been modified to allow a trial distribution
to be converted to a permanent distribution 'on the fly'
using the existing MMEM EOMKEY=dd...dd console command
and/or the existing PARM=(...,EOMKEY=dd...dd,...) HNAS
start parameter. The console command is provided so
that HNAS does not have to be stopped and restarted
in order to perform the conversion. 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 form of conversion.
The start parameter makes the conversion permanent so
long as the EOMKEY start parameter is specified. The
distribution will revert back to trial with the original
EOTDATE value if the EOMKEY start parameter is not
specified or the console command is not issued.
When a trial distribution is converted to a permanent
distribution using an EOMKEY, the DNAS display will
reflect this by changing the DNAS display records 11,
14 an 16 above as follows:
AUTH=000 SHIPID=1100000011199999 EMKYID=1100000011199999 11
MAINTENANCE/USE ANNIVERSARY DATE IS 2010/12/31* 14
EOMKEY=4962030747980516 IS IN EFFECT 16
Note that AUTH=000 reflects the new permanent status.
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=4962030747980516
HNAS EOMKEY CREATED AT 16:00:19 ON 2010/11/28
MAINTENANCE/USE ANNIVERSARY DATE IS 2010/12/31
CUSTID=SFD_99999
CUSTINFO=COMM-PRO ASSOCIATES
EMKYDC=0201012311199999
3) If an invalid dd...dd string is specified,
HNAS will issue an error message but will
continue running.
4) The EOMDATE is automatically checked by HNAS
at midday every day after the following
message is generated:
NAS0910I 3 BELLS AND ALL IS WELL AT 12:00:00
ON yyyy/mm/dd
Additional NAS9xxxs alarm messages are issued
as the EOMDATE approaches expiration.
CIRCUMVENTION: Install a product refresh distribution to extend
the EOTDATE or to convert the trial distribution
to a permanent distribution.
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).
2010-11-15 - APAR 2400105 (created to help solve problem 2009111A)
(new PMR #23825 opened for this problem)
APAR: 2400105
STATUS: CLOSED
OPEN_DATE: 2010-11-09
CLOSE_DATE: 2010-11-15
SERVICE(S): TCP/IP interface support
MANDATORY: YES, for improved debugging
ORIGIN/REF: 240_SRP
CPTECH: SFD
PTF_CLASS: STANDARD-APAR with diagnostic ENHANCEMENT
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas240m/apars/
(Complete FIX is contained in the 2400105.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) Previous distribution at APAR level 2400103 or above.
SUPERSEDES: N/A
OBJECT(S): NASUTIL
SOURCE(S): NASMAIN, NASTCP, XFBLK, XFNASWA, XFPCE
PROBLEM: Additional diagnostic logic is required to help solve
the 'TCPIP REPLY ID FAILURE' ABEND problem which is
enabled by the 'DBUG TCP' option - now a default
option.
DESCRIPTION: The 'TCPIP REPLY ID FAILURE' ABEND problem seems to be
related to the SELECT background timeout condition.
At one of our current customer sites, it appears that
that after HNAS has been running for 13 days with no
no problems, suddenly the customer starts seeing
'NAS2252E SELECT INTERRUPT LOST' messages. This seems
to occur early in the morning (2:08am) when one might
expect not much to be going on. No one at the customer
site can tell us what the system was doing during this
period. These NAS2252E messages are generated when the
SELECT background timer expires.
HNAS always runs a background timer on SELECT commands.
SELECTs are conditioned to end either when something
is received from the network (a new call for a LOCAL
or data for a REMOTE) or when a TCPIP stack timeout
occurs. The stack timeout is set for 60-seconds while
the HNAS background timer is set for 90-seconds. The
logic being that if everything is working properly
when no input is received, the stack timer will 'pop'
before the HNAS background timer does. At 2:08am at
the customer site, the stack timer does not go off to
end the SELECT so the HNAS background timer does. This
is disturbing. The stack should ALWAYS end a SELECT.
The 'TCPIP REPLY ID FAILURE' ABEND occurs, we believe,
because HNAS is receiving an ending for a new SELECT
command that really was for a previous SELECT command.
After a SELECT background timeout occurs, a new SELECT
is issued. The interrupt that HNAS receives for the new
SELECT is the one for the previous SELECT (i.e., the one
that HNAS timed out). We do not know what would cause
the stack to postpone presenting the ending for the
previous SELECT. Logic was added for APAR 2400102 that
allows HNAS to ignore the 'TCPIP REPLY ID FAILURE'
condition in order to prevent the ABEND from occurring.
This logic was enabled by specifying 'DBUG TCP' as a
start parameter (the 'DBUG TCP' start parameter was
added for APAR 2400102 and is now the default for
APAR 2400105). Instead of the ABEND, the following
alarm message will be generated:
NAS2110S INVALID TCPIP INTERRUPT REPLY ID, IGNORED
FOR cmdname
Where cmdname is the command receiving the invalid
TCPIP REPLY ID.
Note that the SELECT background timeout logic was added
many years ago for another HNAS customer. In that case
once a SELECT failed to end, it was permanent condition
unlike what appears to be happening at the current
customer site. A SELECT that never ends puts HNAS in
a 'hung' state, unable to accept new calls or user
input. IBM was involved with the original problem and
most likely made changes to the stack that now cause
the timed out SELECT to eventually end. However, we
were never informed by IBM regarding any potential
changes that they made to the stack.
SOLUTION: We now believe that it is probably necessary for HNAS
to always wait for a SELECT to end rather than trying
to CANCEL it and starting a new SELECT when the HNAS
background timer expires. This, hopefully, will
eliminate the 'TCPIP REPLY ID FAILURE' ABEND problem.
Instead of cancelling and restarting a SELECT when the
HNAS background timer expires, HNAS will now issue an
alarm message and then wait some more. Based on what
we have observed, the original SELECT should eventually
end, albeit much later than expected.
HNAS has been modified to issue the following alarm
messages when a SELECT or CANCEL background timeout
occurs. The 'DBUG TCP' start parameter must be in
effect and is set by default by this APAR.
For a LOCAL SELECT:
NAS2252E SERVER=172.029.127.220(01998) SOCKID=0000
PCEID=0009 NAME=LXOT
NAS2252E SELECT SHOULD HAVE ENDED 00nnn SECONDS AGO,
WAITING
If, after this message is issued 10 consecutive times
(840 seconds), HNAS assumes that the SELECT will not
successfully end and the following message is generated:
NAS2252E SERVER=172.029.127.220(01998) SOCKID=0000
PCEID=0009 NAME=LXOT
NAS2252E SELECT INTERRUPT LOST, RETRY WILL BE ATTEMPTED
For a REMOTE SELECT:
NAS2252E CLIENT=010.117.056.100(01128) SOCKID=0001
PCEID=000C NAME=R1CNIN
NAS2252E SELECT SHOULD HAVE ENDED 00nnn SECONDS AGO,
WAITING
If, after this message is issued 10 consecutive times
(840 seconds), HNAS assumes that the SELECT will not
successfully end and the following message is generated:
NAS2252E CLIENT=010.117.056.100(01128) SOCKID=0001
PCEID=000C NAME=R1CNIN
NAS2252E SELECT INTERRUPT LOST, SOCKET MUST BE CLOSED
For a LOCAL CANCEL:
NAS2152E SERVER=172.029.127.220(01998) SOCKID=0000
PCEID=0009 NAME=LXOT
NAS2152E SELECT SHOULD HAVE ENDED 00nnn SECONDS AGO,
WAITING FOR SELECT
If, after this message is issued 10 consecutive times
(300 seconds), HNAS assumes that the CANCEL will not
successfully end and the following message is generated:
NAS2152E SERVER=172.029.127.220(01998) SOCKID=0000
PCEID=0009 NAME=LXOT
NAS2152E CANCEL INTERRUPT LOST, NORMAL COMPLETION
ASSUMED FOR SELECT
For a REMOTE CANCEL:
NAS2252E CLIENT=010.117.056.100(01128) SOCKID=0001
PCEID=000C NAME=R1CNIN
NAS2152E SELECT SHOULD HAVE ENDED 00nnn SECONDS AGO,
WAITING FOR SELECT
If, after this message is issued 10 consecutive times
(300 seconds), HNAS assumes that the CANCEL will not
successfully end and the following message is generated:
NAS2252E CLIENT=010.117.056.100(01128) SOCKID=0001
PCEID=000C NAME=R1CNIN
NAS2152E CANCEL INTERRUPT LOST, NORMAL COMPLETION
ASSUMED FOR SELECT
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).
2010-11-03 - APAR 2400104
APAR: 2400104
STATUS: CLOSED
OPEN_DATE: 2010-10-28
CLOSE_DATE: 2010-10-29
SERVICE(S): DNAS logic to detect missing APAR(s).
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: 240_CPT
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: REFRESH
PTF_LOC: Contact Support Services for Refresh E-distribution.
PROBLEM: DNAS command does not show missing maintenance when
there are holes in the APAR sequence.
DESCRIPTION: Due to a bug introduced by APAR 2400103, the DNAS
command does not list missing APARs. This can only
occur if a user applies maintenance subsequent to
installing the HNAS product and there are gaps between
the highest APAR number shipped and the last APAR
number applied.
SOLUTION: HNAS has been modified to detect and display missing
APAR numbers. For example, the following is displayed
when APARs 2400002, 2400012 and 2400072 have not been
applied.
HOST NAS INFORMATION FOLLOWS
HNAS VERSION=V2R4M0 DIST=NON-SMP
HNAS PROGRAM RUNNING UNDER z/OS 01.11.00
HNAS PRODUCT INSTALLED UNDER z/OS 01.11.00
HNAS PRODUCT CREATED UNDER z/OS 01.11.00
DNAS COMMAND ENTERED AT 08:06:39 ON 2010/10/29
HNAS PROGRAM STARTED AT 18:29:32 ON 2010/10/28
HNAS PRODUCT INSTALLED AT 08:07:00 ON 2010/10/15
HNAS PRODUCT CREATED AT 07:08:18 ON 2010/09/16
HNAS PRODUCT CREATED WITH MAINTENANCE THROUGH APAR 2400000
MOST RECENT MAINTENANCE APPLIED IS APAR 2400104
AUTH=000 SHIPID=1100000011199999
CUSTID=SFD_99999
CUSTINFO=COMM-PRO ASSOCIATES
MAINTENANCE/USE ANNIVERSARY DATE IS 2010/09/31
DATAFONO SUPPORT IS INCLUDED
APARID MAINTENANCE STATUS
2400002 NOT INSTALLED
2400012 NOT INSTALLED
2400072 NOT INSTALLED
CIRCUMVENTION: Issue DNAS APAR command to see an ordered list
of all APARs on the HNAS system.
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)
2010-09-24 - APAR 2400103
APAR: 2400103
STATUS: CLOSED
OPEN_DATE: 2010-09-10
CLOSE_DATE: 2010-09-21
SERVICE(S): FASTRUN DNAS processing and DNAS z/OS display info.
MANDATORY: NO
ORIGIN/REF: 240_CNS
CPTECH: SFD
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: REFRESH
PTF_LOC: Contact Support Services for Refresh E-distribution.
OVERVIEW: Execution of DNAS unconditionally for FASTRUN processing
would allow quicker problem diagnosis.
PROBLEM: Customer FASTRUN fails when Datafono resources are coded
in the CDF but user expected no errors because Datafono
support was supposed to be included.
DESCRIPTION: The distribution that Comm-Pro provided to the customer
was supposed to include Datafono support but CDF errors
were generated during a FASTRUN execution when Datafono
resources were specified. Because the DNAS command was
not executed during FASTRUN, the Datafono support flag
could not be examined in the SHIPID line in the DNAS
display. When the customer specified FASTRUN CONCMDQ
as a start parameter, the DNAS command was still not
executed because of the configuration errors (RC>4
causes FASTRUN CONCMDQ to terminate without DNAS
execution). In order to verify whether or not the
Datafono support flag was set, the customer had to
remove all Datafono resources from the CDF then
re-execute HNAS with FASTRUN CONCMDQ.
SOLUTION: HNAS has been modified to force execution of the DNAS
command for FASTRUN regardless of the severity of the
configuration errors.
Note: FASTRUN is now treated the same as FASTRUN CONCMDQ
In addition, the DNAS command display has been enhanced
provide additional diagnostic information.
The following DNAS output is effective as of this APAR.
HOST NAS INFORMATION FOLLOWS
HNAS VERSION=V2R4M0 DIST=NON-SMP
HNAS PROGRAM RUNNING UNDER z/OS 01.10.00
HNAS PRODUCT INSTALLED UNDER z/OS 01.10.00 <- new line
HNAS PRODUCT CREATED UNDER z/OS 01.10.00
DNAS COMMAND ENTERED AT 07:33:27 ON 2010/09/16
HNAS PROGRAM STARTED AT 07:33:26 ON 2010/09/16 <- new line
HNAS PRODUCT INSTALLED AT 07:29:00 ON 2010/09/16
HNAS PRODUCT CREATED AT 07:08:18 ON 2010/09/16
HNAS PRODUCT CREATED WITH MAINTENANCE THROUGH APAR 240BETA
MOST RECENT MAINTENANCE APPLIED IS APAR 2400103
AUTH=000 SHIPID=1100000011199999
CUSTID=SFD_99999
CUSTINFO=COMM-PRO ASSOCIATES
MAINTENANCE/USE ANNIVERSARY DATE IS 2010/09/31
DATAFONO SUPPORT IS INCLUDED
ALL MAINTENANCE ON THROUGH MOST RECENT APAR 2400103
The following DNAS output is prior to this APAR.
HOST NAS INFORMATION FOLLOWS
HNAS VERSION=V2R4M0 DIST=NON-SMP
ASMDATE=2009/08/12 ASMHOST=ZOS <--- deleted
RUNNING UNDER z/OS 01.10.00
DNAS COMMAND ENTERED AT 12:54:50 ON 2010/09/20
HNAS PROGRAM STARTED AT 12:54:50 ON 2010/09/20
HNAS PRODUCT CREATED AT 19:35:30 ON 2009/08/12
CREATED WITH MAINTENANCE THROUGH APAR 240BETA
MOST RECENT MAINTENANCE APPLIED IS APAR 2400102
AUTH=000 SHIPID=1100000011199999
CUSTID=SFD_99999
CUSTINFO=COMM-PRO ASSOCIATES
MAINTENANCE/USE ANNIVERSARY DATE IS 2010/09/31
DATAFONO SUPPORT IS INCLUDED
ALL MAINTENANCE ON THROUGH MOST RECENT APAR 2400102
CIRCUMVENTION: Remove Datafono resources and specify FASTRUN CONCMDQ
to force DNAS execution.
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).
2010-04-28 - APAR 2400102 (created to help solve problem 2009111A)
(new PMR #23825 opened for this problem)
APAR: 2400102_+E
STATUS: CLOSED
OPEN_DATE: 2010-04-06
CLOSE_DATE: 2010-04-28
SERVICE(S): TCP/IP interface support, PULSE support
MANDATORY: NO, but recommended for improved debugging.
ORIGIN/REF: 240_FIS
CPTECH: SFD
PTF_CLASS: STANDARD-APAR with diagnostic ENHANCEMENTS
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas240m/apars/
(Complete FIX is contained in the 2400102.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) Previous distribution at APAR level 2400100 or above.
Note: Due to the large number of PREREQs, we
recommend a REFRESH distribution to pickup
this enhancement APAR.
SUPERSEDES: N/A
OBJECT(S): CNFGBFSZ, CNFGLGTB, CNFGOPTS, CNFGUSTB,
CONSDLU, CONSDMCH, CONSDVC, CONSMRMT,
CONSPING, CONSTLU, CONSTLUQ, CONSTMCH,
CONSTMCX, CONSTVC, CONSTVCQ, MCHINI,
NASCNFG, NASUTIL, QLSSCP, XTPRCV
SOURCE(S): NASMAIN, NASTCP, XFBLK, XFNASWA, XFPCE
OVERVIEW: Minor fixes are provided by this APAR as well as
additional diagnostic logic to help solve the invalid
TCPIP reply ID ABEND problem.
PROBLEM1: Specified PULSE frequency value is being erroneously
increased by one before counting down.
DESCRIPTION1: When a PULSE frequency of 60 (for example) is specified
(PULSE=(hh:mm:ss,hh:mm:ss,60)), it is actually treated
as 61. To have the PULSE message (NAS0299I) issued once
per minute, you have to specify 59 as the frequency.
SOLUTION1: HNAS has been modified to use the specified frequency
value as is rather than adding one (1) to it.
CIRCUMVENTION1: Specify a PULSE frequency value one less than the
frequency you actually want.
PROBLEM
ENHANCEMENT2: Enhancement that allows an alarm message to be issued
when CANCEL command timeout occurs.
DESCRIPTION2: Unlike the NAS2252E message that is issued when a
SELECT background timeout occurs, no equivalent message
is generated when a CANCEL background timeout occurs.
This can hide the fact that there is a problem with
the processing of the CANCEL sequence. While it is
possible to discern that a CANCEL background timeout has
occurred by looking at the TCPIP external interrupt
table, there is no record of it written in the HNAS
SYSPRINT.
SOLUTION2: HNAS has been modified to issue the following alarm
message when a CANCEL background timeout occurs:
NAS2152E CANCEL REQUEST INTERRUPT LOST, NORMAL
COMPLETION ASSUMED FOR command
Note: In addition to this new alarm message, the CANCEL
background timeout has been extended from 15 to
30 seconds.
CIRCUMVENTION2: N/A
PROBLEM
ENHANCEMENT3: Enhancement that logs diagnostic information within
each TCPIP external interrupt data record (additional
logic supplements logic added for APAR 2400042).
DESCRIPTION3: 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 are 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.
SOLUTION3: 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.
This new logic will provide almost the same information
as standard HNAS TCPIP tracing but without the added
CPU overhead associated with event tracing. It is
expected that the new TCPIP external interrupt entry
data will show why this failure is occurring (see
problem 2009111A for more information).
Note: This enhancement allows the TCPIP request return
code plus start and end timestamps to be included
in each interrupt table entry.
CIRCUMVENTION3: Disable LU, MCH and VC traces and start global PCE
traces: TRCALL OFF TRCPCE ALLON
PROBLEM
ENHANCEMENT4: Diagnostic enhancement that allows the TCPIP REPLY ID
ABEND to be bypassed.
DESCRIPTION4: It is possible that HNAS can survive when an invalid
TCPIP reply ID is received although it is difficult
to predict what will happen after this condition is
ignored.
SOLUTION4: HNAS has been modified to ignore an invalid TCPIP reply
ID as well as a TCPIP interrupt that occurs with no
request (command) active. This new processing will
only take place if the new 'DBUG TCP' option is
specified as an HNAS start parameter.
If this new option is specified, rather than ABENDing,
the following new alarm messages are issued based on
when an invalid TCPIP interrupt occurs. HNAS continues
to run rather than terminating.
The following alarm message is issued when a TCPIP
interrupt occurs that is not expected (no command
is running which implies that no command ending
interrupt is expected). Normally, this would cause
a 'TCPIP INTERRUPT UNEXPECTED' 0198 ABEND.
NAS2109S CLIENT=010.117.056.100(04545) SOCKID=0001
PCEID=000C NAME=R1CNIN
NAS2109S UNEXPECTED TCPIP INTERRUPT, IGNORED
NAS2109S IPARM=0001850200000024001300FAD5C1E2E3F0E3E2D6
0000D740004EA808004EAB900000000000508C00
0000000001000000001348352413483533
The following alarm message is issued when a TCPIP
interrupt occurs with an invalid reply ID (does not
match the reply ID for the currently active command).
Normally, this would cause a 'TCPIP REPLY ID FAILURE'
0198 ABEND.
NAS2110S SERVER=172.029.127.220(01998) SOCKID=0000
SOCKID=0000 PCEID=0009 NAME=LXOT
NAS2110S INVALID TCPIP INTERRUPT REPLY ID, IGNORED
FOR SELECT
NAS2110S EXPECTED=0000001D PRESENTED=0000001C
NAS2110S IPARM=000185020000001C001300FAD5C1E2E3F0E3E2D6
0000D740004E8C18004E8FA000000000005187E0
00000000000000001209175512101732
Note: The IPARM value specified in both the NAS2109S
and NAS2110S messages above is the actual TCPIP
external interrupt table entry at the time of
the error, that is, the one that caused the
problem.
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).
2010-04-07 - APAR 2400101 (was problem 2009295A)
APAR: 2400101
STATUS: CLOSED
OPEN_DATE: 2009-10-22
CLOSE_DATE: 2010-04-07
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 2400101.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): Installations below the 2400095 level should order a
refresh distribution at the 2400101 level.
For installations at or above 2400095 the 2400097 and
2400099 APARs are PREREQs for this APAR.
SUPERSEDES: N/A
OBJECT(S): VCCLRQ , MCHHRSP , MCHTMR , XOTRCV , VCRESET , XOTXMTC
SOURCE(S): N/A
OVERVIEW: See problem
PROBLEM: When one of 2 HNASs in a SD (sysplex distributor) is shut
down some PVCs do not migrate to the working HNAS LPAR.
DESCRIPTION: The SD balances the sessions between 2 HNAS LPARS. When
one HNAS is shut down some PVC sessions do not migrate
to the working LPAR. This is caused by a timing problem.
When an XOT PVC activates (PVC Setup packet exchange)
the PLU session is activated (VTAM REQSESS operation).
The router sends a CAUSE=0F RESET to indicate that the
PVC is operational. If the PLU is first speaker and it
sends the first message while the CAUSE=0F reset is in
transit then the first message is discarded at the remote
end (which is in RESET sent state). The PLU 'hangs'
waiting for a response to the first message.
SOLUTION: HNAS will not activate the PLU until the PVC operational
RESET is received. If the reset does not arrive in 2
minutes then a CAUSE=0F RESET is sent to the remote by
HNAS and the PLU session is activated.
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).
2010-04-02 - APAR 2400100
APAR: 2400100_E
STATUS: CLOSED
OPEN_DATE: 2010-03-30
CLOSE_DATE: 2010-04-02
SERVICE(S): Authorization File (NASAUTH) message processing
MANDATORY: NO
ORIGIN/REF: 240_CBG
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 2400100.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 2400098 and their
associated APAR chains applied.
SUPERSEDES: N/A
OBJECT(S): NASUTIL
SOURCE(S): N/A
PROBLEM: HNAS does not report all possible errors when a NASAUTH
file validation failure occurs.
DESCRIPTION: When HNAS detects an error in a NASAUTH authorization
file, it stops processing the file and issues an
appropriate alarm message before ABENDing with 0198.
It would be more informative if HNAS postponed the
ABEND until the entire NASAUTH file was processed.
This would report all errors in the NASAUTH file if
more than one is present. This would then provide
additional information as to whether the NASAUTH file
became corrupted or was simply the wrong file for
current distribution. The latter usually occurs
because the //AUTH DD statement points at the wrong
library.
SOLUTION: HNAS has been modified to check all NASAUTH file
fields after an error is detected and report all
errors before ABENDing.
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).
2010-01-15 - APAR 2400099 (was problem 2009352A)
APAR: 2400099
STATUS: CLOSED
OPEN_DATE: 2009-12-18
CLOSE_DATE: 2010-01-15
SERVICE(S): DATAFONO
MANDATORY: YES if DATAFONO resources.
ORIGIN/REF: 240_CAM
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 2400099.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 APARs: 2400095 through 2400098 applied.
Refresh recommended.
SUPERSEDES: N/A
OBJECT(S): MCHNRQC MCHTMR VCCLEAR VCDAT
SOURCE(S): N/A
PROBLEM: HALT AT LOC xxxxxxxx IN MCHPQ : ELEMENT NOT FOUND
DESCRIPTION: Pseudo leased LU left on a real MCH's MCHLUIQ when the
LU was moved to the system MCH (to make it available for
leased allocation).
The problem occurs under the following circumstances:
1) Pseudo leased LU configured with OPTIONS=(DATAF,EMSGE,
RETPIU).
2) EMSGE sent to remote (no PLU response to message from
the remote in 16 seconds).
3) Remote clears the call.
4) Because of the RETPIU option, HNAS waits for the PLU
to send an 'L' message. When the 'L' is received
the first message not sent to the PLU is returned to
the PLU with a leading '?' character. An error in
the RETPIU logic causes the HALT.
SOLUTION: RETPIU 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).
Last Update - June 24, 2013 (combine 2010-2013)