APAR memo entries with PTF_TYPE: (ZAP) designations in the HNAS 22n HTML Maintenance Summaries now contain hyperlinks to their respective APAR Memo's in ASCII (*.txt) format. This will allow for immediate ZAP retrieval without having to access the HNAS userid/password based FTP Server. Please be aware that all PTF_TYPE: SRC (source) and OBJ (object) maintenance is provided on the HNAS FTP Server. Please 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 |
|---|---|---|---|---|
| 2209999 | 12-31-2004 | ALL | Notice | <END_OF_MAINTENANCE/APAR_CYCLE> We no longer issue General Maintenance or APAR's for the HNAS V2R2M0 distribution level. Please refer to the 2209999 for additional information. |
| 220MEMO | 11-10-2004 | ALL | Notice | We recommend that users upgrade to HNAS V2R3M0 for up-to-date product maintenance as well as New Features. |
| Notice | 07-01-2004 | APAR Summary | N/A, Notice | Summary detail entries for APARs 2200001 thru 2200049 are now in descending order along with all other 220 apar entries. |
| 2200093 |
06-04-2004 <Deferred> |
TCPIP |
MEMO ONLY 230_REF |
HNAS does not always process TCPIP stack sever properly. |
| 2200092 |
06-04-2004 <Deferred> |
LLC0-LLC5, CNFG |
MEMO ONLY 230_REF |
A configuration warning messages can be erroneously generated when an SVCi= vclmt value is coded without SLU/SPU components. |
| 2200091 |
06-04-2004 <Deferred> |
QLLC |
MEMO ONLY 230_REF |
Various QLLC fixes. See APAR memo files for details. |
| 2200090 | 05-20-2004 | GATE/GATEFC | OBJ/SRC | GATE control session not properly re- activated when PLU taken down & restarted. Inbound calls are cleared with DIAG=138 (X'8A'). NAS3702W message issued. |
| 2200089 | 05-03-2004 | QLLC | OBJ | Application connection via INIT-SELF or user LOGON data can fail. |
| 2200088 | 04-30-2004 |
Console Subsystem WTOR Support |
OBJ | Non-USEMDFY support - Two WTO replies are outstanding when HNAS starts when USEMDFY parameter is not specified. |
| 2200087 | 04-26-2004 |
CDF CNFG. ALRMFLTR= |
OBJ | ALRMFLTR=type bug causes local console alarm messages to be displayed not purged. |
| 2200086 | 04-21-2004 |
LLC0|LLC3| LLC5 CNFG |
OBJ | LOGTAB and USSTAB for a TYPE=MXT REMOTE definition statement are not resolved (problem introduced with APAR 2200076). |
| 2200085 | 04-21-2004 | QLLC | OBJ/SRC | UNBIND bind forthcoming created by CLSDST OPTCD=PASS is incorrectly processed. |
| 2200084 | 04-16-2004 | TCPIP, TAP= | OBJ/SRC | TAP TCPIP socket can close prematurely when a firewall/router open socket timer expires before the TAP=seconds value. |
| 2200083 | 04-13-2004 | Multi-LOCAL TCPIP, CNFG. | OBJ | Users unable to define multiple LOCAL definition statements with the same IPADDR= and PORT= operand values after APAR 2200075 was applied or included in refresh. |
| 2200082 | 04-06-2004 |
LLC3 USSTAB and LOGTAB |
OBJ | USSTAB for TYPE=SPU REMOTE is not resolved properly when APPLNAME= defaults. |
| 2200081 | 03-30-2004 |
Console Subsystem |
OBJ | PFXWTO option can cause display message truncation on long messages. |
| 2200080 | 03-29-2004 | CDF CNFG. | OBJ/SRC |
FASTRUN AMNF VBUILD statement name origin improvement (APPLNAME= instead of NASNAME=). |
| 2200079 | 03-19-2004 |
HNAS Console APAR List |
OBJ/SRC | DMAP APAR command operation and display limitations corrected. |
| 2200078 | 03-17-2004 | PVC | OBJ | PVCs are not properly restarted after a link failure, HNAS fails to send the PVC Setup packet. |
| 2200077 | 03-09-2004 | QLLC | OBJ | HNAS can ABEND with 0C4 if an SPU is defined but is not referenced in any SVC3= operand. |
| 2200076 | 02-26-2004 |
LLC0|LLC3| LLC5 CNFG |
OBJ/SRC | Configuration error messages can be produced even when no USSTAB support is required. |
| 220Memo | 02-25-2004 | MAINTENANCE | N/A, Notice | Some PC Anti-Virus file scan programs become confused when processing our PC filenames: vrmnnnn.HNAStype.ext |
| 2200075 | 02-20-2004 | TCPIP, CNFG | OBJ | LOCAL resource fails to activate when previously defined LOCAL has same IPADDR= and PORT= address. |
| 2200074 | 02-20-2004 | TCPIP, TAP= | OBJ | TAP processing stops working due to APAR 2200073. |
| 2200073 | 02-16-2004 | ALL, TCPIP | SRC,ASM | TCPIP SELECT request may not complete which can/will result in a failure of XOT services in router and HNAS. |
| 2200072 | 02-16-2004 | ALL, PORT | OBJ | TYPE=XOT|XTP LOCAL or REMOTE can fail to initialize when incorrect PORT value is specified in the CDF. |
| 2200071 | 01-22-2004 | LLC0/LLC5 | OBJ | Configuration process does not accept NULL=value in the SYSL= operand for LLC0 and LLC5 resources. |
| 2200070 | 01-15-2004 | ALL | SRC,ASM | HNAS exit routine rejects BIND with sense= 0805C5E7. Session fails to start (observed Virtel GATE environment). |
| 2200069 | 01-07-2004 |
TCPIP TAP with Callout Support |
OBJ/ SRC,ASM |
TCPIP TAP (Keep Alive) failure does not prevent down router from being used for callout. |
| 2200068 | 01-06-2004 | GATE Callout | OBJ | Incorrect TYPE=XOT REMOTE used for GATE callout causes call request to fail. |
| 2200067 | 01-06-2004 |
TCPIP Shared Socket Pools |
SRC,ASM | TCPIP SOCKET requests begin to fail with error number 27DD after HNAS has been running for awhile or under heavy reconnect activity. |
| 2200066 | 12-15-2003 | LLC3 (QLLC) Clears | OBJ | Alter Clear code from 140 (X'8C') to 00 for normal end UNBIND requests (like NPSI). |
| 2200065 | 12-14-2003 | QLLC | OBJ | QLLC resources can become unavailable after VTAM error condition encountered. |
| 2200064 | 12-12-2003 |
LLC0/LLC5 Callout |
OBJ | NASHALT 0198 ABEND ('INV VC 2') LLC0/LLC5 callout with multiple DTE addresses. |
| 2200063 | 12-08-2003 | CDF config -CUD0= | OBJ | Configuration process does not allow a CUD0 value of FF (255). |
| 2200062 | 11-23-2003 | LLC0, LLC4 & LLC5 Clears | OBJ | Alter Clear code from 140 (X'8C') to 00 for normal end UNBIND requests (like NPSI). |
| 2200061 | 11-21-2003 |
GATE Non- FastConnect |
OBJ | GATE with CONNECT=NO,SUBD=(...) correction for subaddress digits selection sessions. |
| 2200060 | 11-17-2003 | HNAS Console | OBJ | DLU, DMCH, DPCE, DVC ALLID display fix |
| 2200059 | 11-13-2003 | HNAS Console | OBJ | DMCH display output fix for VCLMT. |
| 2200058 | 10-26-2003 | HNAS TRC MINDATA | OBJ | MINDATA/MAXDATA fixes for TRCALL, TRCLU and TRCVC console commands. |
| 2200057 | 10-23-2003 |
CDF config - NULL=n coding LLC0/LLC5 |
OBJ | Configuration process does not detect an invalid delimiter character that follows the NULL keyword of the SYSL= operand for LLC0/LLC5 resources. |
| 2200056 | 10-21-2003 |
Shutdown (HNAS Quit) |
SRC,ASM | Shutdown (/P hnasname or /F hnasname,QSTOP) does not terminate HNAS. Console cancel command must be issued in order to terminate the HNAS job. |
| 2200055 | 10-20-2003 |
Trial Product |
OBJ | HNAS trial distribution initialization delay and CPU cycles consumption due to AUTH year+month decode condition. |
| 2200054 | 10-14-2003 | GATE | OBJ | Inbound GATE calls fail to start, call request response timeout occurs. Diagnostic packets received in GATE sessions (NAS7703W, Cause/Diag= 19/50). |
| 2200053 | 10-03-2003 | QLLC | OBJ | First LU can hang, HNAS fails to send NOTIFY response when NOTIFY request carries POWER ON indication. |
| 2200052 | 08-28-2003 | ALL, TAP= | SRC,ASM |
1) TAP keepalive timeout can erroneously occur when TAP=0 parameter is in
effect. 2) NASHALT 0198 ABEND ('INV VC 2'). |
| 2200051 | 08-24-2003 | ALL | OBJ | Inbound calls are cleared with DIAG=130 (X'82') - calls from router/network. |
| 2200050 | 08-14-2003 | CNFG LLC0|4|5 |
OBJ | HNAS can erroneously generate a default SVC0|4|5 SLU name when specified in the same operand list. |
| - | - | - | - | - |
|
2200049 thru 2200001 |
-> | -> | -> | Matrix summary entries for APARs 2200001 thru 2200049 aren't available. Please refer to the actual apar summary detail entries in this file (manually or via find or search commands) to locate information on APAR#, CLOSE_DATE, SERVICE, PTF_TYPE and PROBLEM descriptions (This reference added 07-01-2004). |
| - | - | - | - | - |
| 220nnnni | mm-dd-yyyy |
GATE/LLCn/ PVC/QLLC/... |
ZAP/SRC/ OBJ/DOC/ CNFG/... |
<-Brief Problem Description-> i=blank-Closed|Pending|Removed R denotes apar entries as superceded (backed out) by another apar or the root apar assignment. |
|
- |
- | <Enhancement> |
<-> |
Depicts an enhancement, not a problem fix. |
| - | <Deferred> |
- |
MEMO ONLY 230_REF |
STATUS: CLOSED_DEFERRED to release V2R3M0- Deferred denotes that problem resolution was deferred to a latter release although an apar memo is present describing the problem and reference. |
mm-dd-2004 - APAR 220nnnn
APAR: 220nnnnP (Problem_ID 2004---A)
STATUS: PENDING
END:
03-22-2004 - APAR 2209999*
APAR: 2209999
STATUS: SERVICE_NOTICE-<END_OF_MAINTENANCE/APAR_CYCLE>
OPEN_DATE: ----------
CLOSE_DATE: 12-31-2004
SERVICE(S): ALL_V2R2M0
MANDATORY: NO, (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: V2R2M0 General Maintenance/APAR's no longer provided.
DESCRIPTION: We no longer issue standard maintenance for this
HNAS distribution level.
If you are unable to find a problem description in
the V2R2M0 APAR logs we suggest that you review the
V2R3M0 APAR logs for potential problem resolution.
Comm-Pro will make every effort to provide emergency
support for this distribution level although you may
be required to upgrade to a newer level to resolve
the problem.
SOLUTION: Refer to the HNAS V2R3Mn or higher maintenance logs
and upgrade to a latter release (as required) which
provides the corrective logic or enhancement.
APPLY_INFO: Upgrade HNAS distribution to V2R2Mn or higher.
01-17-2005 - APAR 220MEMO_2004-11-10
APAR: 220MEMO_2004-11-10
STATUS: SERVICE_NOTICE-<Maintenance Recommendation - Upgrade>
OPEN_DATE: 11-10-2004
CLOSE_DATE: 11-10-2004
SERVICE(S): Maintenance
MANDATORY: NO, (PLEASE_READ_THIS_NOTICE)
ORIGIN/REF: 220
PTF_TYPE: N/A
NOTICE: V2R2M0 General Maintenance/APAR's recommendation.
DESCRIPTION: We no longer issue general maintenance or enhancements
for the HNAS V2R2M0 distribution level.
If you are unable to find a problem description in
the V2R2M0 APAR logs we suggest that you review the
V2R3Mn APAR logs for potential problem resolution.
Comm-Pro will make every effort to provide emergency
support for this distribution level although you may
be required to upgrade to a newer HNAS level in order
to resolve the problem.
SOLUTION: Refer to the HNAS V2R3Mn or higher maintenance logs
and upgrade to a latter release (as required) which
provides the corrective logic or enhancement.
APPLY_INFO: Upgrade HNAS distribution to V2R3Mn or higher.
06-04-2004 - APAR 2200093
APAR: 2200093
STATUS: CLOSED_DEFERRED to release V2R3M0
OPEN_DATE: 06-04-2004
CLOSE_DATE: 06-04-2004
SERVICE(S): TCPIP INTERFACE
MANDATORY: N/A
ORIGIN/REF: 230
PTF_TYPE: N/A
PTF_LOC: N/A
COREQ(S): N/A
PREREQ(S): N/A
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: This APAR documents TCPIP problems that have been
fixed in our V2R3M0 release.
An upgrade to V2R3M0 is required to resolve these
problems. For additional information please see
the appropriate 23000xx apar description:
DESCRIPTION: 2300042 -
HNAS does not always process TCPIP stack sever
properly.
2300043 -
HNAS does not perform Keep Alive service even when
a value is specified for the TAP= operand. This
problem was caused by logic introduced in APAR
2300042.
2300044 -
HNAS will not SHUTDOWN if a server (LOCAL) is taken
offline when HNAS cannot bind its IP address to the
stack. This problem was caused by logic introduced
in APARs 2300042/2300043.
SOLUTION: Upgrade to V2R3M0
CIRCUMVENTION: N/A
APPLY_INFO: N/A
06-04-2004 - APAR 2200092
APAR: 2200092
STATUS: CLOSED_DEFERRED to release V2R3M0
OPEN_DATE: 06-04-2004
CLOSE_DATE: 06-04-2004
SERVICE(S): LLC0|LLC3|LLC5 CONFIGURATION
MANDATORY: N/A
ORIGIN/REF: 230
PTF_TYPE: N/A
PTF_LOC: N/A
COREQ(S): N/A
PREREQ(S): N/A
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: This APAR documents an SVCi configuration problem
that has been fixed in our V2R3M0 release.
An upgrade to V2R3M0 is required to resolve this
problem. For additional information please see
the appropriate 23000xx apar description:
DESCRIPTION: 2300035 -
A configuration warning message can be generated if
the vclmt value in the SVCi= operand is specified
but no SLU/SPU entries are provided.
SOLUTION: Upgrade to V2R3M0
CIRCUMVENTION: N/A
APPLY_INFO: N/A
06-04-2004 - APAR 2200091
APAR: 2200091
STATUS: CLOSED_DEFERRED to release V2R3M0
OPEN_DATE: 06-04-2004
CLOSE_DATE: 06-04-2004
SERVICE(S): QLLC
MANDATORY: N/A
ORIGIN/REF: 230
PTF_TYPE: N/A
PTF_LOC: N/A
COREQ(S): N/A
PREREQ(S): N/A
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: This APAR documents QLLC problems as well as some
enhancements that have been fixed or implemented
in our V2R3M0 release.
An upgrade to V2R3M0 is required to resolve these
problems. For additional information please see
the appropriate 23000xx apar description:
DESCRIPTION: 2300028 (=2200089) -
Logon data from INIT-SELF not passed to VTAM.
2300029 -
The wrong MCH name is displayed in the NAS3798I
alert message and displayed in the HNAS trace
table when an SLU ACB is opened for an SPU.
2300030 -
PLU cannot acquire QLLC printers.
2300031 -
Following message issued, QLLC session hangs:
NAS7601W MCH mch-nm LU lu-nm DECODE RC=20
TH/RH=2C000102 00010BB0 A0021030 3C1280C6
2300033 (ENHANCEMENT) -
If there is a gap in the LOCADDR values for the
SLUs on an SPU, commas must be used as place
holders for the unused LOCADDR values in the
LUNAME= operand on TYPE=SPU REMOTE definition
statement. This can cause the wrong LOCADDR
to be assigned if care is not taken.
2300034 -
QLLC session hang (HNAS pace error).
2300038 -
QLLC callout generates NASHALT in VTMLUFM routine
with the message 'LU DIRTY'
2300039 -
NAS8000I QLLC VC session start message does not
display the calling or called DTE address or the
direction of call.
2300040 -
Remote sends RESET to HNAS which disconnects QLLC
LUs using the virtual circuit. RESET caused by
HNAS which can send RR packets in the wrong order.
2300041 -
QLLC session ended by SLU TERM-SELF PIU. Problem
is invalid IPR (Isolated Pacing Response) sent by
HNAS.
SOLUTION: Upgrade to V2R3M0
CIRCUMVENTION: N/A
APPLY_INFO: N/A
05-20-2004 - APAR 2200090
APAR: 2200090 (Was PROBLEM_ID 2004084A)
STATUS: CLOSED
OPEN_DATE: 03-24-2004
CLOSE_DATE: 05-20-2004
SERVICE(S): GATE and GATE Fast Connect (FC) Support
MANDATORY: YES for GATE users
ORIGIN/REF: 220_NMP
PTF_TYPE: (SRC and OBJ) HNASMACX and HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200090.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
SUPERSEDES: 2200035
OBJECT(S): MCHSTRT, MCHNRQC
SOURCE(S): VTMTR
PROBLEM: GATE control sessions and GATE FC data sessions not
properly reactivated when PLU taken down and restarted.
Inbound calls are cleared with DIAG=138 (X'8A'), which
means the GATE control session was not bound. NAS3702W
message issued.
DESCRIPTION: When a GATE PLU is terminated HNAS can receive a NOTIFY
request which takes down the HNAS SLU. After a time
delay (OPTIONS=MCHTMR=xx on the TYPE=MCH REMOTE)
a GATE control session or FC data session LU's ACB is
reopened and a REQSESS is sent to the PLU (assuming
a PLU name was coded in the HNAS CDF). If the REQSESS
fails, HNAS waits for the PLU to acquire it's SLUs.
The acquire operation results in HNAS receiving a BIND
which activates the HNAS session. If no BIND is
received, all inbound calls requiring the control
session will fail and no FC data session LUs will be
available for GATE FC inbound call request processing.
Thus, CTCPs that do not acquire their SLUs will not
be useable after the PLU takedown / restart sequence.
SOLUTION: HNAS modified to retry the REQSESS operation based
on the OPTIONS=MCHTMR=xx parameter. The ACB remains
open so that a BIND from the PLU will be accepted.
With this APAR on all REQSESS failures are reported
(APAR 2200035 removed, APAR ID 2200035R assigned
and viewable via DMAP APAR / DNAS APAR display).
If your installation leaves HNAS active while CTCP
PLUs are not up you will see an increased number of
NAS3702W messages.
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).
05-03-2004 - APAR 2200089
APAR: 2200089 (PROBLEM_ID 2004112A)
STATUS: CLOSED
OPEN_DATE: 04-21-2004
CLOSE_DATE: 05-03-2004
SERVICE(S): QLLC SUPPORT
MANDATORY: YES
ORIGIN/REF: 220_ITL
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200089.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200065
OBJECT(S): MCHNRQC and QLSSCP
SOURCE(S): N/A
PROBLEM: Application connection via INIT-SELF or user LOGON
data can fail.
DESCRIPTION: LOGON data from INIT-SELF PIU is being truncated
resulting in missing data being passed to VTAM
causing eventual session connect failure. HNAS
extracts the PLU name from the INIT-SELF PIU and
passes it to VTAM in the REQSESS request. HNAS
ignores any other data that may be present.
In addition, a REQSESS failure due to an invalid PLU
application name or invalid LOGON data carried in an
INIT_SELF or via USSTAB processing causes subsequent
logon attempts to fail. REQSESS failure forces the
LU to be deactivated (DACTLU) but does not close the
LU ACB. When a subsequent connection is attempted,
the ACB open routine is called, but because the
LU ACB is still open, the OPEN fails with RC=0858
and USSMSG7 is transmitted before the DACTLU occurs.
Problem was seen when INIT_OTHER was processed.
SOLUTION: The INIT-SELF PIU processing logic has been modified
so that all data is passed to VTAM in the REQSESS
request.
The REQSESS failure routine has been modified to
close the LU ACB before the DACTLU is scheduled.
This will allow subsequent login attempts that
reopen the ACB to work properly.
APPLY_INFO: This problem FIX is applied like an APAR.
See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-30-2004 - APAR 2200088
APAR: 2200088
STATUS: CLOSED
OPEN_DATE: 04-30-2004
CLOSE_DATE: 04-30-2004
SERVICE(S): CONSOLE - WTOR SUPPORT (NON-USEMDFY)
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: 220_POR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200088.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200079 and 2200087
OBJECT(S): NASUTIL
SOURCE(S): N/A
PROBLEM: Two WTO replies are outstanding when HNAS starts when
USEMDFY parameter is not specified.
DESCRIPTION: Due to logic introduced by APAR 2200079, 2 WTO replies
will be outstanding after HNAS starts because the
reply from the DMAP APAR command is not remembered
after HNAS initialization completes. The result is
that a second console WTOR prompt is issued.
SOLUTION: The HNAS WTO interface routine has been modified to
withhold the WTOR that is issued as part of the
DMAP APAR command. This will allow only one WTOR
to be issued after HNAS initialization completes.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-26-2004 - APAR 2200087
APAR: 2200087
STATUS: CLOSED
OPEN_DATE: 04-22-2004
CLOSE_DATE: 04-26-2004
SERVICE(S): CONFIGURATION/CONSOLE - ALARM FILER PROCESSING
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: 230_SWC
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200087.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200084
OBJECT(S): CNFGAFLT, CONSALRM and NASUTIL
SOURCE(S): N/A
PROBLEM: The ALRMFLTR= operand value is not always being
propagated to the local console which resulted
in alarm messages being displayed that should have
been purged or suppressed.
DESCRIPTION: When ALRMFLTR=(PURGE) is specified, the local
console PCE still defaults to ALRMFLTR=(ALLOW).
This is due to the fact that the ALRMFLTR= operand
value is only propagated when filters are present.
When a default disposition (first suboperand) only
is specified, the value is not propagated.
SOLUTION: The ALRMFLTR= operand processor has been corrected
to propagate the ALRMFLTR= operand even when only
one value (the default disposition) 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).
04-21-2004 - APAR 2200086
APAR: 2200086
STATUS: CLOSED
OPEN_DATE: 04-20-2004
CLOSE_DATE: 04-21-2004
SERVICE(S): LLC0|LLC3|LLC5 - HNAS CONFIGURATION PROCESSING
MANDATORY: YES, IF USSTABs AND/OR LOGTABs ARE REQUIRED
ORIGIN/REF: 220_GME
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200086.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200076
OBJECT(S): CNFGLGTB and CNFGUSTB
SOURCE(S): N/A
PROBLEM: The LOGTAB and USSTAB for a TYPE=MXT REMOTE definition
statement are not resolved (problem introduced with
APAR 2200076).
DESCRIPTION: Logic introduced with APAR 2200076 prevents the LOGTAB=
and USSTAB= operands on a TYPE=MXT REMOTE definition
statement from being resolved. APAR 2200076 introduced
a test to ensure that MCHSOL was specified as one of
APPLNAME= operand values before testing the LOGTAB= and
USSTAB= operands. Problem occurs because APPLNAME= is
not a valid TYPE=MXT operand but LOGTAB= and USSTAB=
are.
SOLUTION: The HNAS configuration process has been corrected
to bypass the APPLNAME=MCHSOL test for a TYPE=MXT
REMOTE definition statement thus allowing the
LOGTAB= and USSTAB= operands to be resolved.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-21-2004 - APAR 2200085
APAR: 2200085 (PROBLEM_ID 2004085A)
STATUS: CLOSED
OPEN_DATE: 03-24-2004
CLOSE_DATE: 04-21-2004
SERVICE(S): QLLC SUPPORT
MANDATORY: N/A
ORIGIN/REF: 220_ITL
PTF_TYPE: (SRC and OBJ) HNASOBJX and HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200085.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHHL3RQ, MCHRL3RR, MCHHRQ
SOURCE(S): VTMSND1, VTMSND2
PROBLEM: HNAS does not treat the sequence UNBIND (bind
forthcoming), BIND correctly. The second BIND is
rejected with sense 0805FFFF and the NAS4704W warning
message is issued. The QLLC session fails to start.
UNBIND bind forthcoming is created by CLSDST
OPTCD=PASS. VTAM error messages will refer to this
operation.
DESCRIPTION: See problem.
SOLUTION: HNAS modified to properly process the UNBIND bind
forthcoming request from the PLU.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-16-2004 - APAR 2200084
APAR: 2200084
STATUS: CLOSED
OPEN_DATE: 04-02-2004
CLOSE_DATE: 04-16-2004
SERVICE(S): TCPIP SUPPORT - TAP PROCESSING
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: 230_SWC
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200084.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200073 and 2200081
OBJECT(S): NASUTIL
SOURCE(S): NASTCP
PROBLEM: HNAS TAP TCPIP socket can close prematurely (prior
to delivery of TAP request) when a firewall or router
open socket timer expires before the TAP=seconds
value.
DESCRIPTION: Existing TAP logic opens a TCPIP socket then waits
for the TAP timeout value to expire before sending
the TAP request (XOT Call Request or Clear Request
if the TAPWITHCLR option is in affect). If the
target router is behind a firewall, the firewall
can close the socket before the TAP request is
actually sent (the firewall starts a data timer when
the socket is opened and if the data timeout interval
is shorter than the TAP value, the timeout condition
will occur). This condition may also occur with some
router configurations although firewall timers values
are typically shorter than the router default timer
values. When the socket is closed prematurely it
will void out the TAP processing and may lead to a
HNAS Keep Alive failure although this wasn't observed.
SOLUTION: HNAS TAP logic has been modified to defer opening the
TAP socket until the TAP timeout value expires and
the TAP request is ready to send. This eliminates
all delays between socket opening and data transfer.
This will ensure that firewall data transfer timeouts
or router open socket timeouts will not occur.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-13-2004 - APAR 2200083
APAR: 2200083
STATUS: CLOSED
OPEN_DATE: 04-08-2004
CLOSE_DATE: 04-13-2004
SERVICE(S): Multi-LOCAL Support, TCPIP CNFG.
MANDATORY: YES
ORIGIN/REF: 220_RBS
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200083.ZIP file)
COREQ(S): N/A
PREREQ(S): 2200075
OBJECT(S): CNFGIPAD
SOURCE(S): N/A
PROBLEM: Users unable to define multiple LOCAL definition
statements with the same IPADDR= and PORT= operand.
DESCRIPTION: When multiple LOCAL definition statements with the
same IPADDR= and PORT= operand values are specified,
the following error message is generated and HNAS
terminates after the CDF has been entirely scanned:
NAS1321E REMOTE IPADDR/PORT DUPLICATED,
INVALID CONFIGURATION
Some customers use 2 LOCAL statements with identical
IPADDR= and PORT= operand values but different names
in order to be able to use 2 different RTEOUT=
operands without providing any DTE address values.
Each RTEOUT= operand points at different routers.
One router can be used for ISDN and the other for
X.25 traffic. In this way, the selected SLUNAME
determines if the outgoing call is leaving via
ISDN or X.25.
With APAR 2200075 applied, LOCAL resources will
fail to activate if a previously defined LOCAL has
the same IPADDR= and PORT= operand values and
the TCPIP SHAREPORT option is not in affect. This
will result in the following alarm message being
generated:
NAS2231W SERVER=... NAME=local-name
NAS2231I BIND REQUEST FAILED, RC=FFFFFFFF 00000030
SOLUTION: The HNAS configuration process has been corrected
to restore the original logic prior to APAR 2200075
which allows multiple LOCALs with the same IPADDR=
and PORT= operand values. This requires that the
SHAREPORT option must be specified in the TCPIP
PROFILE.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-06-2004 - APAR 2200082
APAR: 2200082
STATUS: CLOSED
OPEN_DATE: 04-06-2004
CLOSE_DATE: 04-06-2004
SERVICE(S): LLC3 - HNAS CONFIGURATION PROCESSING
MANDATORY: YES, IF USSTABs AND/OR LOGTABs ARE REQUIRED
ORIGIN/REF: 220_ITL
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200082.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200076
OBJECT(S): CNFGAPNM
SOURCE(S): N/A
PROBLEM: The USSTAB for a TYPE=SPU REMOTE definition statement
is not always resolved (problem introduced with APAR
2200076).
DESCRIPTION: When the APPLNAME= operand is omitted from a TYPE=SPU
REMOTE definition statement, MCHSOL is assumed.
MCHSOL is required to process the USSTAB= and LOGTAB=
operands. However, the remembrance of MCHSOL is only
set when it is specifically coded in the APPLNAME=
operand and not when it is set by default.
CIRCUMVENTION: Specify APPLNAME=MCHSOL instead of omitting the
APPLNAME= operand when the USSTAB= and/or LOGTAB=
operands are specified for a TYPE=SPU REMOTE
definition statement.
SOLUTION: The HNAS configuration process has been corrected
to set the MCHSOL remembrance when the APPLNAME=
operand is omitted for a TYPE=SPU REMOTE 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).
03-30-2004 - APAR 2200081
APAR: 2200081
STATUS: CLOSED
OPEN_DATE: 03-30-2004
CLOSE_DATE: 03-30-2004
SERVICE(S): CONSOLE SUBSYSTEM - PFXWTO PROCESSING
MANDATORY: YES
ORIGIN/REF: 220_RBS
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200081.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200049, 2200055, 2200074, 2200079
OBJECT(S): NASUTIL
SOURCE(S): N/A
PROBLEM: HNAS alarm messages can be truncated causing loss of
display information.
DESCRIPTION: When the PFXWTO option is in affect, HNAS alarm messages
are copied into a WTO area so that the NASNAME= operand
value can be added to the message. The WTO copy area
is 101 bytes in length (which includes space for the
NASNAME= operand value). This causes message that are
longer than 91 (101-10) characters in length to be
truncated. For a message like the NAS7717W, which is
107 bytes in length, the result is that the last 16
characters of information will be lost.
SOLUTION: The copy WTO area has been extended to 126 bytes which
is the WTO macro limit. This will accommodate all HNAS
alarm messages. For NAS7717W, all data will now 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).
03-29-2004 - APAR 2200080
APAR: 2200080
STATUS: CLOSED
OPEN_DATE: 03-15-2004
CLOSE_DATE: 03-29-2004
SERVICE(S): CONFIGURATION FASTRUN
MANDATORY: NO, BUT RECOMMENDED ENHANCEMENT
ORIGIN/REF: 220_NMP
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200080.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2200079
OBJECT(S): CNFGAPNM and NASCNFG.
SOURCE(S): XFNASWA and XFXTRN.
PROBLEM: The name for the AMNF VBUILD statement, produced by
(ENHANCEMENT) the FASTRUN process, comes from the NASNAME= operand
instead of it's own unique operand.
DESCRIPTION: The FASTRUN process will produce the HNAS AMNF if the
//MAJNODE DD statement is present in the HNAS start
JOB. The name used for the VBUILD statement comes
from the NASNAME= operand when it should come from
its own unique BUILD definition statement operand
for improved flexibility.
SOLUTION: The HNAS configuration process has been modified to
allow the APPLNAME= operand to be coded on the BUILD
definition statement. The APPLNAME= operand will be
used to supply a name for the VBUILD statement in the
AMNF.
If APPLNAME=NONE is specified, the VBUILD statement
will be generated without a name.
If the APPLNAME= operand is omitted, the name for the
VBUILD statement will come from the NASNAME= operand.
If the NASNAME= operand is also omitted, the VBUILD
statement will be generated without a name.
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).
03-19-2004 - APAR 2200079
APAR: 2200079
STATUS: CLOSED
OPEN_DATE: 03-15-2004
CLOSE_DATE: 03-19-2004
SERVICE(S): CONSOLE SUBSYSTEM
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: 220_CP
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200079.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CONSDMAP,CONSDNAS,MCHINI,NASCONS,NASUTIL
SOURCE(S): XFBST,XFNASWA,XFXTRN
PROBLEM: DMAP APAR command operation and display limitations.
DESCRIPTION: The DMAP APAR command can take a long time to complete
because delays are deliberately introduced so that
other HNAS tasks have an opportunity to run while the
DMAP APAR command executes. Under V2R2M0 with current
maintenance level (2200079) applied, the DMAP APAR
command takes approximately 35 seconds to list all of
the modules containing maintenance. This delay may be
unacceptable for some customers wanting to know all
the maintenance that is on their system.
SOLUTION: HNAS logic has been changed so that the DMAP APAR
command automatically executes at initialization time
with no delays. The output of the command is logged
in the HNAS SYSPRINT so that the maintenance can be
viewed using an SDSF panel.
ADDITIONAL
ENHANCEMENT: Additionally, during the initialization pass, the
DMAP APAR command creates a table that is sorted in
APAR ID order so that it can be displayed using the
new DNAS APAR command.
Note that you can still use the DMAP APAR command
to display APARs but command output is in module name
order rather than APAR ID order. Note also that the
DMAP APAR command issued by the SYSCONS or TSO console
operator will still take approximately 35 seconds to
complete.
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).
03-17-2004 - APAR 2200078
APAR: 2200078 (PROBLEM_ID 2004049A)
STATUS: CLOSED
OPEN_DATE: 02-17-2004
CLOSE_DATE: 03-17-2004
SERVICE(S): PVC support
MANDATORY: YES, if PVCs used
ORIGIN/REF: 220_NBG
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200078.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): XOTBXM, XOTXMTC
SOURCE(S): N/A
PROBLEMs: 1) HNAS PVCs are not properly restarted after a link
failure identified by TAP logic.
2) HNAS fails to send a PVC Setup packet when a TYPE=XOT
REMOTE for the PVC session is identified in the PVC=
operand.
DESCRIPTIONs:1) When a link failure occurs HNAS does not notify the
PLU. The PLU will receive data when an if a new PVC
session is started.
2) The tests for an available PCE control block to be
used for transmission of a PVC setup contain were not
updated for changes that were part on the 220 release.
As a result PVC Setup packets were not sent.
SOLUTIONs:1) HNAS corrected to send a PVC Setup when one is
called for.
2) HNAS changed to close the session's ACB when the link
fails. The PLU will receive a NOTIFY to inform it
of the session loss. A new session will start when
the PVC reactivates.
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).
03-09-2004 - APAR 2200077
APAR: 2200077 (PROBLEM_ID 2004055A)
STATUS: CLOSED
OPEN_DATE: 02-24-2004/03-08-2004
CLOSE_DATE: 03-09-2004
SERVICE(S): QLLC SUPPORT
MANDATORY: YES, IF QLLC SUPPORT IS REQUIRED
ORIGIN/REF: 220_NBG,220_ITL
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200077.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: HNAS can ABEND with 0C4 if an SPU is defined but is not
referenced in any SVC3= operand.
DESCRIPTION: In 220, an SPU and its SLUs are initialized when HNAS
start logic interrogates all SVC3= operands on all MCHs.
If an SPU is defined in the CDF but is not referenced
in any SVC3= operand, it will not be initialized
correctly. At run time, if the un-initialized SPU is
selected via IDBLK/IDNUM matching, an 0C4 ABEND will
occur because the LU control blocks (LUBs) for the
SLUs defined in the LUNAME= operand for the SPU will
not have been resolved.
If you actually did intend to specify all SPUs in some
SVC3= operand(s) but the record containing the SPU
name was in error, the record will be ignored and the
following warning message will be generated:
NAS1041W DECODE FAILURE, RECORD FOLLOWS
In this case, the SPU identified on the invalid record
will appear undefined in the SVC3= operand and the
result will be the same, that is, the 0C4 ABEND will
occur.
SOLUTION: The HNAS fix for this SPU problem is to force the
configuration process to terminate after the entire
CDF is scanned by changing the severity code in the
NAS1041 message from 'W' to 'E' (NAS1041W -> NAS1041E).
This will allow the problem to be corrected before
an 0C4 ABEND can occur.
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).
02-26-2004 - APAR 2200076
APAR: 2200076
STATUS: CLOSED
OPEN_DATE: 02-26-2004
CLOSE_DATE: 02-26-2004
SERVICE(S): LLC0|LLC3|LLC5 - HNAS CONFIGURATION PROCESSING
MANDATORY: YES, IF USSTABs NOT REQUIRED
ORIGIN/REF: 220_ETL
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200076.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CNFGAPNM,CNFGLGTB,CNFGUSTB,CONSMRMT
SOURCE(S): XFNASWA
PROBLEM: The following HNAS configuration error message can be
produced even when no USSTAB support is required:
NAS1052W ISTINCDT MODULE NOT FOUND IN VTAMLIB DATASET,
IGNORED, AC=00000306 RC=0000000C
Note: This message can be generated even when MCHSOL
is specified when HNAS is loaded from an APF
registered dataset but one of the datasets in
//VTAMLIB DDNAME concatenation is not APF
authorized.
DESCRIPTION: The configuration process erroneously attempts to
load the default USSTAB (ISTINCDT) even though MCHSOL
has not been specified in any APPLNAME= operand in
the CDF.
USSTABs (and LOGTABs) are only required when MCHSOL
processing is invoked for non-GATE resources. This
processing is requested when the MCHSOL keyword is
specified as an element within an APPLNAME= operand
list.
SOLUTION: The HNAS configuration process has been corrected
to detect the absence of MCHSOL in the CDF and as a
result inhibit the loading of the default USSTAB.
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).
02-25-2004 - 220MEMO_2004-02-25
APAR: 220MEMO_2004-02-25
STATUS: CLOSED
OPEN_DATE: 02-25-2004
CLOSE_DATE: 02-25-2004
SERVICE(S): HNAS APAR DISTRIBUTION PC FILENAME FORMAT
MANDATORY: N/A
ORIGIN/REF: 220_CP,OVR
PTF_TYPE: N/A
PTF_LOC: N/A
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: Some PC Anti-Virus file scan programs become confused
when processing our vrmnnnn.HNAStype.ext PC filenames.
DESCRIPTION: We have been notified that some PC Anti-Virus scan
programs become confused or erroneously isolate the
the HNAS PTF maintenance files into quarantine when
the filename structure contains more than one period.
In an effort to provided the widest possibly support
we have change or PC filename structure to avoid this
condition.
SOLUTION: The HNAS APAR maintenance PC filename structure was
changed as follows to eliminate the condition:
From: vrmnnnn.HNAStype.ext
To: vrmnnnn_HNAStype.ext
This new PC filename assignment begins at 2200075.
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.
APPLY_INFO: N/A
02-20-2004 - APAR 2200075
APAR: 2200075
STATUS: CLOSED
OPEN_DATE: 02-20-2004
CLOSE_DATE: 02-20-2004
SERVICE(S): HNAS CONFIGURATION PROCESSING
MANDATORY: YES
ORIGIN/REF: 220_CP
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200075.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CNFGIPAD
SOURCE(S): N/A
PROBLEM: LOCAL resource fails to activate when previously
defined LOCAL has same IPADDR= and PORT= address.
DESCRIPTION: The configuration process erroneously allows multiple
LOCAL definition statements with the same IPADDR= and
PORT= operand values.
The configuration process does not reject multiple
LOCAL definition statements with common IPADDR= and
PORT= operand values. This is an invalid configuration
that must be flagged. Each LOCAL must represent a
unique HOME socket for the TCPIP network.
The following alert messages were observed:
NAS2231W SERVER=... NAME=local-name
NAS2231I BIND REQUEST FAILED, RC=FFFFFFFF 00000030
SOLUTION: The HNAS configuration process has been corrected to
detect this condition and if detected, the following
error message will now be generated:
NAS1221E LOCAL IPADDR/PORT DUPLICATED,
INVALID CONFIGURATION
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).
02-20-2004 - APAR 2200074
APAR: 2200074
STATUS: CLOSED
OPEN_DATE: 02-19-2004
CLOSE_DATE: 02-20-2004
SERVICE(S): HNAS TCPIP PROCESSING
MANDATORY: YES, if APAR 2200073 is on and tapping is used.
ORIGIN/REF: 220_CP
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200074.ZIP file)
COREQ(S): N/A
PREREQ(S): 2200073
OBJECT(S): NASUTIL
SOURCE(S): N/A
PROBLEM: TAP processing stops working.
DESCRIPTION: APAR 2200048 added a test to the TAP initialization
logic that required PCECLK=0. PCECLK is the field
in the HNAS Process Control Element (PCE) that is
used by HNAS to provide subtask timeout service.
When PCECLK is non-zero in a TAP PCE, it indicates
that a CANCEL request is active as part of socket
CLOSE processing. There is no point in scheduling
a TAP request when the socket was being closed.
This is the only time that PCECLK can be non-zero
in a TAP PCE unless APAR 2200073 is applied.
With APAR 2200073 on, PCECLK is non-zero when a TAP
PCE SELECT command is active. The SELECT is part of
receive processing for all client sockets and is the
active command almost all the time. Since PCECLK
is non-zero when the SELECT command is active, the
TAP request is not scheduled.
SOLUTION: The HNAS TAP scheduler has been modified to test
for an active SELECT when PCECLK is non-zero. If
a SELECT is the active command, the TAP request
will be scheduled.
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).
02-16-2004 - APAR 2200073
APAR: 2200073 (PROBLEM_ID 2004021B)
STATUS: CLOSED
OPEN_DATE: 01-21-2004
CLOSE_DATE: 02-16-2004
SERVICE(S): TCPIP SELECT processing
MANDATORY: YES
ORIGIN/REF: 220_BIC_01-21-2004
PTF_TYPE: (SRC) HNASMACX MEMBER(S)
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in 2200073.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): N/A
SOURCE(S): NASTCP,XFCLC,XFNQDQ,XFPOST,XFRTMR,XFSTMR,XFWAIT
PROBLEM: TCPIP SELECT request may not complete which can/will
result in a failure of Router and HNAS XOT services.
From the perspective of HNAS Alerts/traces, it appears
that the Stack is ignoring or loosing requests and that
sockets are being lost. The following alert messages
may also be seen:
NAS3799I Clear CAUSE/DIAG=000/049 (00/31)
NAS7715W CLEAR DIAG=130 (82)
NAS7703W DIAG FROM ...
NAS7799I PKT=1000F132 1001
From the perspective of the router's debug alerts, it
appears as if the XOT services are hung because XOT
Call Request's and Clear Request's timeout (Clear
diagnostic codes 000/049 (00/31), etc. and attempts
to open sockets timeout:
XOT open failed
Serial1/1: X.25 O R1 Clear (5) 8 lci 1
Cause 0, Diag 0 (DTE originated/
No additional information)
Serial1/1: X.25 O R1 Clear (5) 8 lci 7
Cause 9, Diag 0 (Out of order/
No additional information)
Serial1/1: X.25 O R1 Clear (5) 8 lci 8
Cause 0, Diag 49 (DTE originated/
Time expired for Call)
Serial1/1: X.25 O R1 Clear (5) 8 lci 8
Cause 19, Diag 50 (Local procedure error/
Time expired for Clear)
...
DESCRIPTION: We have observed (currently under z/OS V1R3 only) that
the SELECT command that HNAS executes on a SERVER socket
to monitor for inbound connections or on a CLIENT socket
to monitor for input, does not always end.
The SELECT normally ends when inbound socket activity
is detected or when a TCPIP managed timeout occurs.
The timeout is set to 60 seconds by HNAS when the
SELECT command is issued. Thus, a SELECT should always
end when either input is queued (new connection for a
SERVER socket or data for a CLIENT socket) or when the
TCPIP timeout expires.
For the timeout ending, the SELECT is simply retried
after a forced delay. For input on a SERVER socket,
an ACCEPT command is executed to receive a new CLIENT
connection. For input on a CLIENT socket, a RECEIVE
command is executed to read any queued data.
When a SELECT does not end either by input or timeout,
it is, for all intents and purposes, hung. HNAS will
not be able to accept new connections on the SERVER
socket or any input data on the CLIENT socket. From
the router's perspective, it will appear as though
packets directed at HNAS are being lost or simply not
answered. For Cisco routers, this is an XOT hang
condition.
We have observed the 'lost SELECT interrupt' at only
one customer site running z/OS V1R3. According to
IBM, the stack for z/OS V1R3 is the same as it is
for z/OS V1R2. We have not seen this problem for
z/OS V1R4, although we do not want to rule it out
as a possibility.
SOLUTION: PMRs 82217, 82661 and 82706 have been opened with
IBM to resolve the 'apparent' SELECT hang condition.
We have gathered many traces and other documentation
that IBM is currently reviewing. The ultimate
solution will be determined by what IBM finds.
CIRCUMVENTION: HNAS logic has been modified to run an independent
SELECT timeout. A timeout that is managed by HNAS,
not TCPIP. The TCPIP SELECT timeout has been reduced
from 60 to 30 seconds while the new HNAS timeout is
set to 60 seconds.
When a SELECT hang is detected by the HNAS timeout for
a SERVER socket, the hung SELECT command is cancelled
and the SELECT is then retried. This new logic allows
the SERVER to resume processing of inbound CLIENT
connections. The following message is also generated:
NAS2252E SERVER=ipaddr(port) SOCKID=xxxx PCEID=xxxxx
NAME=lclname
NAS2252I SELECT REQUEST INTERRUPT LOST, RETRY WILL BE
ATTEMPTED
When a SELECT hang is detected by the HNAS timeout for
a CLIENT socket, the hung SELECT command is cancelled
and the socket is closed. This new logic allows the
CLIENT socket to be released so that it can be used
for another connection. The following message is also
generated:
NAS2252E CLIENT=ipaddr(port) SOCKID=xxxx PCEID=xxxxx
NAME=rmtname
NAS2252I SELECT REQUEST INTERRUPT LOST, SOCKET MUST BE
CLOSED
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).
02-16-2004 - APAR 2200072
APAR: 2200072
STATUS: CLOSED
OPEN_DATE: 02-04-2004
CLOSE_DATE: 02-16-2004
SERVICE(S): HNAS CONFIGURATION PORT= OPERAND
MANDATORY: YES
ORIGIN/REF: 220_LFT,BCM
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200072.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CNFGPORT
SOURCE(S): N/A
PROBLEM: TYPE=XOT|XTP LOCAL or REMOTE can fail to initialize
when an incorrect PORT value is specified in the CDF.
DESCRIPTION: The configuration process does not check to ensure
that correct PORT value is specified for TYPE=XOT|XTP
LOCAL|REMOTE definition statements, respectively.
When a LOCAL PORT value other than 1998 (XOT) or 3095
(XTP) or a REMOTE PORT value other than 1998|DYNAMIC
(XOT) or 3095 (XTP) is specified, HNAS erroneously
allows the bad value to be used.
For a LOCAL, this will cause the wrong IPADDR/PORT
combination to be bound to the TCPIP stack and
will prevent REMOTE socket connections from being
established.
For a REMOTE, this will cause the wrong IPADDR/PORT
combination to be used as the target for outbound
connections and will prevent the REMOTE socket
connections from being established.
Note that if the PORT field is omitted the correct
port addresses will be generated for non-DYNAMIC
environments.
SOLUTION: The HNAS configuration process has been modified
to replace a specified PORT value with 1998 (XOT)
or 3095 (XTP) if the given value is not valid for
the type of LOCAL or REMOTE 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).
01-22-2004 - APAR 2200071
APAR: 2200071
STATUS: CLOSED
OPEN_DATE: 01-22-2004
CLOSE_DATE: 01-22-2004
SERVICE(S): HNAS CONFIGURATION FOR LLC0 AND LLC5
MANDATORY: YES IF NULL= IS CODED ON SYSL=
ORIGIN/REF: 220_JPM
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200071.ZIP file)
COREQ(S): N/A
PREREQ(S): SUPERCEDES APAR 2200057
OBJECT(S): CNFGSYSL
SOURCE(S): N/A
PROBLEM: Configuration process does not accept NULL=value in
the SYSL= operand for LLC0 and LLC5 resources.
DESCRIPTION: When the NULL=value is specified, it will generate
an error message because the accepted syntax is
NULL/value.
SOLUTION: Because the HNAS documentation had, for quite some
time, indicated that NULL=value was correct syntax
even though it was not, we have decide to modify the
SYSL= operand parser to treat NULL=value and
CUD=NULL/value as though NULL/value were specified.
All three flavors of the NULL keyword will be treated
in the same way.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-15-2004 - APAR 2200070
APAR: 2200070 PROBLEM_ID 2004010A). STATUS: CLOSED OPEN_DATE: 12-15-2003 CLOSE_DATE: 01-15-2004 SERVICE(S): ALL MANDATORY: YES ORIGIN/REF: 220_ETL_12-05-2003 PTF_TYPE: (SRC) HNASMACX members PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/ (Complete FIX is contained in 2200070.ZIP file) COREQ(S): N/A PREREQ(S): N/A OBJECT(S): N/A SOURCE(S): VTMEXIT, VTMRCV1. PROBLEM: HNAS exit routine rejects BIND with sense=0805C5E7. Session fails to start. DESCRIPTION: When the PLU uses a BIND, UNBIND (bind pending), BIND sequence, HNAS can incorrectly reject the second BIND. The VIRTEL GATE support CTCP uses the above sequence. The problem occurs when the UNBIND and BIND occur at nearly the same time. If the BIND exit is driven before the HNAS task level has processed the UNBIND then the LU appears already bound to the BIND exit routine. Since multiple sessions are not supported the new bind is rejected with the above sense. SOLUTION: HNAS corrected to not reject a BIND in the above situation. APPLY_INFO: See Chapter 6 (Product Maintenance Installation section) from the HNAS Guide and Reference Manual for instructions on how to install PTF's (Object, Source and ZAPs) or Refresh/Upgrade maintenance. Corrective logic included in distributions created after CLOSE_DATE. Otherwise, apply maintenance as directed in the APPLY_INFO (PTF).
01-07-2004 - APAR 2200069
APAR: 2200069
STATUS: CLOSED
OPEN_DATE: 12-12-2003
CLOSE_DATE: 01-07-2004
SERVICE(S): TCPIP (TAP WITH CALLOUT SUPPORT)
MANDATORY: YES, IF TAP AND CALLOUT ARE USED
ORIGIN/REF: 220_BAO_12-12-2003
PTF_TYPE: (SRC) HNASMACX AND (OBJ) HNASOBJX MEMBER(S)
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in 2200069.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CONSDPCE, XOTUT1
SOURCE(S): NASTCP
PROBLEM: TCPIP TAP (Keep Alive) failure does not prevent down
router from being used for callout.
DESCRIPTION: When 2 consecutive Keep Alive failures are detected for
a router, all the socket connections to the router are
closed and the router is marked down. This should
prevent the down router from being selected during
RTEOUT= scan process so that another available router
in the RTEOUT= list can be used for the callout request.
The problem occurs because the Process Control Element
(PCE) allocation routine does not test the router down
flag. This results in a idle PCE on the down router
being used rather than an idle PCE on an active router.
SOLUTION: HNAS logic has been corrected to test the router down
flag which causes the RTEOUT= scan process to bypass
the PCEs on the down router in the list. This will
allow an available PCE on an active router to be found.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-06-2004 - APAR 2200068
APAR: 2200068
STATUS: CLOSED
OPEN_DATE: 12-24-2003
CLOSE_DATE: 01-06-2004
SERVICE(S): GATE Callout
MANDATORY: YES (to ensure proper operation of GATE callout)
ORIGIN/REF: CFO (220)
PTF_TYPE: (OBJ) HNASOBJX MEMBERS
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200068.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): XOTFCDC, XOTGTCC
SOURCE(S): N/A
PROBLEM: Incorrect TYPE=XOT REMOTE used for GATE callout.
DESCRIPTION: When OPTIONS=REPDCEADDR and DCEADDR=xxx are coded
HNAS replaces an omitted calling DTE address in an
outbound GATE Call Request packet with the xxx value.
The Call Request packet from the CTCP is processed
against the RTEOUT= list (for callout REMOTE selection)
before the calling DTE address insertion has been made.
Thus the RTEOUT= processor will not use the calling DTE
address provided by DCEADDR=. This can result in the
call being sent to the wrong router or in call failure
because no router was located (NAS7720W message).
SOLUTION: HNAS modified to perform the DTE address insertion
before calling the RTEOUT= 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).
01-06-2004 - APAR 2200067
APAR: 2200067 (PROBLEM 2003346A)
STATUS: CLOSED
OPEN_DATE: 12-12-2003
CLOSE_DATE: 01-06-2004
SERVICE(S): TCPIP (SHARED SOCKET POOLS)
MANDATORY: YES, IF SHARED SOCKET POOLS ARE USED
ORIGIN/REF: 220_CFF_12-12-2003
PTF_TYPE: (SRC) HNASMACX MEMBER(S)
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in 2200067.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: TCPIP SOCKET requests begin to fail with error number
27DD after HNAS has been running for awhile.
DESCRIPTION: Callout SOCKET requests can fail with the following
error message being issued after HNAS has been running
for some time or when there is considerable inbound
and outbound VC connect activity.
NAS2201W CLIENT=ipaddr(port) SOCKID=001E PCEID=xxxxx
NAME=lclname
NAS2201I SOCKET REQUEST FAILED, RC=FFFFFFFF 000027DD
The problem occurs because the socket number that
HNAS provides to the stack in the SOCKET request is
also used by another active socket. The 27DD error
number says 'the requested socket number is a
duplicate'. Normally, if a duplicate socket number
is given to the stack in the SOCKET request, the stack
will provide an unused socket number when the SOCKET
request ends. HNAS always uses the socket number that
the stack provides regardless of the value it requests.
It now appears that some levels of the stack require
that the requested socket number always be unused.
HNAS gets into this situation over time because the
requested socket number that is assigned to the TCPIP
Process Control Elements (PCEs) during the CDF scan
can be overlaid when a new inbound connection is
received. Since the same PCE can be used for both
inbound and outbound connections (when shared socket
pool support is defined via PORT=1998 operand), the
overlaid requested socket from a previous inbound
connection is used for an outbound connection. If
this overlaid socket number is already in use, the
27DD error will be generated.
CIRCUMVENTION: Specify separate inbound and outbound socket pools,
with the inbound pool (PORT=DYNAMIC) configured
before the outbound socket pool (PORT=1998).
SOLUTION: HNAS logic has been corrected to always provide an
unused socket number for the TCPIP SOCKET request.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-15-2003 - APAR 2200066
APAR: 2200066 (PROBLEM 2002337A)
STATUS: CLOSED
OPEN_DATE: 12-03-2002
CLOSE_DATE: 12-15-2003
SERVICE(S): LLC3 (QLLC) HNAS Clear diagnostic byte.
MANDATORY: No although recommended for improved NPSI emulation.
ORIGIN/REF: NBG (220)
PTF_TYPE: (OBJ) HNASOBJX MEMBER(S)
(ZAP) Optional - included in this APAR memo.
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200066.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHRL3RR
SOURCE(S): N/A
PROBLEM: When HNAS receives an UNBIND from the PLU a CLEAR X.25
packet is sent to terminate the call. The diagnostic
byte in the packet is 140 (X'8C'). Under the same
conditions NPSI clears with a diagnostic of 0.
APAR 2200062 was the original APAR for this problem.
MCHRL3RR, a QLLC module, was mistakenly omitted
from 2200062.
DESCRIPTION: See problem.
SOLUTION: HNAS modified to use 0 as the diagnostic byte when
clearing is caused by an UNBIND.
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).
ZAP_INFO: The following ZAP is optional.
This ZAP is provided for users whom prefer to
temporarily apply this logic fix bypassing the
standard PTF installation for this APAR until
permanent installation occurs at a later time
(installing replacement members as outlined in
the standard PTF installation for this APAR).
* December 15, 2003
*
* APAR 2200066.
*
* ZAP TO clear with diagnostic 0 when PLU terminates session
* with UNBIND.
*
* ZAP FOR V2R2M0
*
NAME NASMAIN MCHRL3RR
VER 049E 008C
REP 049E 0000
*
12-14-2003 - APAR 2200065
APAR: 2200065 (PROBLEM 2003203A)
STATUS: CLOSED
OPEN_DATE: 07-22-2003
CLOSE_DATE: 12-14-2003
SERVICE(S): QLLC
MANDATORY: YES
ORIGIN/REF: 220_NBG
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: When remote QLLC resources start and stop, session
resources can get in a state where new sessions for
specific LUs cannot be started. The NAS3799I session
end message is issued with CAUSE/DIAG=000/220.
DESCRIPTION: When a QLLC session is stopped and restarted, the HNAS
LU control block is not properly refreshed. This can
lead to VTAM operations ending in error. The VTAM
error condition can cause session starts to fail.
Problem occurs during execution of SESSIONC for SDT
response. The VTAM return codes of 04/14/7C says
OPTCD=USERRH coded on SESSIONC, dirty RPL expected.
SOLUTION: HNAS logic corrected to refresh the LU control block
before starting a new session.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-12-2003 - APAR 2200064
APAR: 2200064
STATUS: CLOSED
OPEN_DATE: 12-11-2003
CLOSE_DATE: 12-12-2003
SERVICE(S): LLC0, LLC5 callout with multiple DTE addresses.
MANDATORY: YES
ORIGIN/REF: 220_BAO
PTF_TYPE: (OBJ) HNASOBJX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): XOTBXM, XOTFCDC, XOTGTCC, XOTXMTC
SOURCE(S): N/A
PROBLEM: User 198 ABEND with the following message:
NASHALT HALT AT LOC xxxxxxxx IN XOTXMTC : INV VC 2.
The NASHALT follows a NAS2271I CONNECT REQUEST FAILED
message.
DESCRIPTION: The timer value used to timeout a Call Accept from a
remote is shorter that the retry timer valued used at
the TCP/IP level. If multiple callout DTE addresses
are defined the system can start a second call request
while the first request is still active at the TCP/IP
level. The result is that the VC has sessions with
2 sockets at the same time. An internal validity
check detects this and issues the NASHALT.
SOLUTION: HNAS modified to not start the Call Accept timeout
until the TCP/IP level notifies the VC level that the
Call Request packet has been successfully sent. This
keeps the Call Accept timer from starting until a
TCP/IP connect has been successful and a Call Request
successfully transmitted.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-08-2003 - APAR 2200063
APAR: 2200063
STATUS: CLOSED
OPEN_DATE: 12-05-2003
CLOSE_DATE: 12-08-2003
SERVICE(S): HNAS CONFIGURATION CUD0=
MANDATORY: YES IF CUD0=FF IS REQUIRED
ORIGIN/REF: 220_BTP,220_CP
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CNFGCUD0
SOURCE(S): N/A
PROBLEM: Configuration process does not allow a CUD0 value of
FF (255).
DESCRIPTION: A CUD0 value of FF is erroneously rejected even though
it is a legitimate value. The configuration process,
heretofore, reserved FF as the NULL value. This is
not required because the NULL value is recorded at the
end of the CUD0 array which frees up FF so it can be
used as a non-NULL value.
SOLUTION: The CUD0= operand parser has been modified to allow
a CUD0= operand value of FF in addition to 0 through
FE and 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). 11-24-2003 - APAR 2200062
APAR: 2200062 (PROBLEM 2002337A)
STATUS: CLOSED
OPEN_DATE: 12-03-2002
CLOSE_DATE: 11-23-2003
SERVICE(S): LLC0, LLC4 & LLC5 HNAS Clear diagnostic byte.
MANDATORY: No although recommended for improved NPSI emulation.
ORIGIN/REF: BNP (211)
PTF_TYPE: (OBJ) HNASOBJX MEMBER(S)
(ZAP) Optional - included in this APAR memo.
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200062.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHHL0RQ, MCHHL4RQ, MCHHL5RQ
SOURCE(S): N/A
PROBLEM: When HNAS receives an UNBIND from the PLU a CLEAR X.25
packet is sent to terminate the call. The diagnostic
byte in the packet is 140 (X'8C'). Under the same
conditions NPSI clears with a diagnostic of 0.
DESCRIPTION: See problem.
SOLUTION: HNAS modified to use 0 as the diagnostic byte when
clearing is caused by an UNBIND.
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).
ZAP_INFO: The following ZAP is optional.
This ZAP is provided for users whom prefer to
temporarily apply this logic fix bypassing the
standard PTF installation for this APAR until
permanent installation occurs at a later time
(installing replacement members as outlined in
the standard PTF installation for this APAR).
* November 23, 2003
*
* APAR 2200062.
*
* ZAP TO clear with diagnostic 0 when PLU terminates session
* with UNBIND.
*
* ZAP FOR V2R2M0
*
NAME NASMAIN MCHHL0RQ
VER 044E 008C
REP 044E 0000
VER 0462 008C
REP 0462 0000
NAME NASMAIN MCHHL4RQ
VER 05EA 008C
REP 05EA 0000
VER 0602 008C
REP 0602 0000
NAME NASMAIN MCHHL5RQ
VER 0738 008C
REP 0738 0000
VER 074C 008C
REP 074C 0000
*11-21-2003 - APAR 2200061
APAR: 2200061
STATUS: CLOSED
OPEN_DATE: 11-21-2003
CLOSE_DATE: 11-21-2003
SERVICE(S): GATE with CONNECT=NO,SUBD=(...)
MANDATORY: NO
ORIGIN/REF: 220_BTP
PTF_TYPE: (OBJ) HNASOBJX MEMBER(S)
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the 2200061.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHINI, VCCLRQ
SOURCE(S): N/A
PROBLEM: Selection of a GATE CTCP by subaddress digits for a
non-Fast-Connect session does not work as described
in the manual (subaddress digits do not select CTCP).
DESCRIPTION: See above.
SOLUTION: Module changes required for this new V2R2M0 feature
were not applied to the distribution libraries.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
11-17-2003 - APAR 2200060
APAR: 2200060
STATUS: CLOSED
OPEN_DATE: 11-14-2003
CLOSE_DATE: 11-17-2003
SERVICE(S): HNAS CONSOLE - DLU, DMCH, DPCE and DVC display fix
MANDATORY: NO (recommended if customer performs HNAS DLU, DMCH
DPCE and/or DVC console display operations).
ORIGIN/REF: 220_BNP
PTF_TYPE: (OBJ) HNASOBJX MEMBER(S)
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 11-13-2003 (see DNAS) with
APAR 2200059 applied.
OBJECT(S): CONSDLU, CONSDMCH, CONSDPCE, CONSDVC
SOURCE(S): N/A
PROBLEM: The DLU, DMCH, DPCE and DVC console command displays
are restricted to the REMOTE specified by the RNM=
modifier even though ALLID is specified as a command
argument.
DESCRIPTION: While the ALLID argument temporarily overrides any
ID= values that have been set, it does not also
temporarily override the RNM= value while executing
the command. If an RNM= value is set, the command
output is restricted to the named REMOTE even though
ALLID is entered.
SOLUTION: The DLU, DMCH, DPCE and DVC command processors have
been modified to temporarily treat RNM= as omitted
if ALLID is specified as a command argument so that
the command operates on all REMOTEs. Note that for
DLU, the ALLID argument also temporarily overrides
the LUNM= modifier if it has been set.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
11-13-2003 - APAR 2200059
APAR: 2200059
STATUS: CLOSED
OPEN_DATE: 11-13-2003
CLOSE_DATE: 11-13-2003
SERVICE(S): HNAS CONSOLE - DMCH display fix
MANDATORY: NO (recommended if customer performs HNAS DMCH console
display operations).
ORIGIN/REF: 220_BNP
PTF_TYPE: (OBJ) HNASOBJX MEMBER(S)
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 06-30-2003 (see DNAS) with
APAR 2200037 applied
OBJECT(S): CONSDMCH, MCHINI
SOURCE(S): N/A
PROBLEMS: The DMCH console command displays the VCLMT value
(VCLM column) incorrectly for both TYPE=XTP and
TYPE=MCH REMOTE definition statements.
DESCRIPTION: The VCLMT value for an XTP REMOTE displays four (4)
times larger than it should be while the VCLMT value
for an MCH REMOTE is always displayed as a constant
value of four (4).
SOLUTION: The DMCH command processor has been modified to
display the correct VCLMT value for both types of
MCH REMOTEs.
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). 10-27-2003 - APAR 2200058
APAR: 2200058
STATUS: CLOSED
OPEN_DATE: 10-25-2003
CLOSE_DATE: 10-26-2003
SERVICE(S): HNAS CONSOLE - TRCALL, TRCLU and TRCVC MINDATA fixes
MANDATORY: NO (recommended if customer performs HNAS tracing
operations). See Circumvention:
ORIGIN/REF: 220_CP
PTF_TYPE: (OBJ) HNASOBJX MEMBER(S)
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 08-04-2003 (see DNAS) with
APAR 2200047 applied
OBJECT(S): CONSTALL, CONSTLU, CONSTVC
SOURCE(S): N/A
NOTE: TRCLU|VC is short for TRCLU or TRCVC.
PROBLEMS: 1) The TRCALL STOP and TRCLU|VC STOP|ALLOFF commands
erroneously reset the global TRCLU|VC MINDATA|MAXDATA
buffer data logging option forcing NODATA instead.
2) The TRCALL STRT and TRCLU|VC ALLON commands
erroneously force the global TRCLU|VC MAXDATA buffer
data logging option.
DESCRIPTION: Starting with APAR 2200047, the MINDATA|MAXDATA|NODATA
arguments of the TRCLU|VC command no longer force the
TRCLU|VC ON function as well. The buffer data logging
types were separated from the ON|OFF function so that
the type of data logging could be specified when a
single LU is being traced.
The TRCALL STOP and TRCLU|VC STOP|ALLOFF commands
erroneously set the TRCLU|VC NODATA function when the
buffer data logging state should remain unchanged.
In addition, the TRCALL STRT and TRCLU|VC ALLON commands
erroneously set the TRCLU|VC MAXDATA function when the
buffer data logging state should remain unchanged.
SOLUTION: The TRCALL STRT|STOP and TRCLU|VC ALLON|ALLOFF|STOP
command processors have been modified to leave the
TRCLU|VC MINDATA|MAXDATA|NODATA state alone.
CIRCUMVENTION: The default MINDATA state can be manually reenabled
using the TRCVC MINDATA and TRCLU MINDATA console
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).
10-23-2003 - APAR 2200057
APAR: 2200057
STATUS: CLOSED
OPEN_DATE: 10-22-2003
CLOSE_DATE: 10-23-2003
SERVICE(S): HNAS CONFIGURATION FOR LLC0 AND LLC5
MANDATORY: YES IF NULL IS CODED ON SYSL=
ORIGIN/REF: 220_JPM
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CNFGSYSL
SOURCE(S): N/A
PROBLEM: Configuration process does not detect an invalid
delimiter character that follows the NULL keyword
of the SYSL= operand for LLC0 and LLC5 resources.
DESCRIPTION: When the NULL value is specified, it can optionally
be followed by a forward slash (/) and a APPLNAME=
operand index value. Due to a parsing error, if
the NULL text is followed by anything other than a
forward slash, comma, right parenthesis or blank
(for example, NULL=2 instead of NULL/2), the
APPLNAME=operand index value will be ignored and a
default values of zero (0) will be used. No error
message is generated even though the users intended
value has been usurped by a default.
***NOTE: HNAS documentation erroneously depicted NULL=0 as
a SYSL= operand value in the sample CDF. This is
an invalid specification. It should actually be
NULL/0. The configuration process failed to
detect this error and thus the documentation was
not corrected. Subsequent to this APAR, the HNAS
documentation has been modified to reflect NULL/0
as the correct specification.
If your organization received a custom CDF from
Comm-Pro or used the example provided in the HNAS
documentation to create your own CDF, you should
ensure that NULL= is replaced with NULL/ if this
specification is present in any SYSL= operand in
your CDF. The NULL=0 value was incorrectly coded
on the sample TYPE=MCH REMOTE definition statements
named MCHCONS and MCH2CON.
SOLUTION: The SYSL= operand parser has been modified to scan
for accepted follower characters ' ,)/'. If any
other character immediately follows the NULL text,
an error message will be generated and HNAS will
terminate after the entire CDF has been processed.
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).
10-22-2003 - APAR 2200056
APAR: 2200056
STATUS: CLOSED
OPEN_DATE: 10-15-2003
CLOSE_DATE: 10-21-2003
SERVICE(S): TCPIP, SHUTDOWN
MANDATORY: YES, if APAR 2200048 and 2200052 are applied.
ORIGIN/REF: 220_BNP|NBK
PTF_TYPE: (SRC) HNASMACX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
PREREQ(S): Distribution dated after: 08-27-2003 (see DNAS)
With APAR: 2200052 applied.
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: HNAS SHUTDOWN (via /P hnasname or /F hnasname,QSTOP)
does not terminate HNAS. Console cancel command
must be issued in order to terminate the HNAS job.
DESCRIPTION: HNAS shutdown quiesce logic does not complete because
the server resource still appears busy after it and
all client sockets are closed. Logic introduced by
APAR 2200052 marks the LOCAL Process Control Element
(PCE) as idle after, rather than before, the test for
idle is made. The result is that HNAS 'thinks' that
sockets are still active which prevents shutdown
processing from completing.
SOLUTION: TCPIP socket close processing that marks the PCE idle
has been restored to the logic prior to APAR 2200052.
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). 10-21-2003 - APAR 2200055
APAR: 2200055
STATUS: CLOSED
OPEN_DATE: 10-14-2003
CLOSE_DATE: 10-20-2003
SERVICE(S): HNAS AUTHORIZATION FILE PROCESSING
MANDATORY: YES (for trial users)
ORIGIN/REF: 220_NBK
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): NASUTIL
SOURCE(S): N/A
PROBLEM: An HNAS trial distribution can take approximately 6
minutes to complete its initialization during which
it can consume significant CPU cycles.
DESCRIPTION: This problem occurs when the expiration year and month
are the same as the current year and month. The HNAS
authorization logic erroneously does not take into
consideration a zero delta year+month value before
computing delta days. This results in a BCT loop
going from zero to zero. Depending on the machine
type and speed, this can take approximately 6 minutes
to execute before the authorization check logic
completes.
SOLUTION: The AUTHCHK logic has been modified to simply compute
delta days using the target day minus the current day
when delta year+month=0.
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).10-14-2003 - APAR 2200054 (ref: problem 2003281A)
APAR: 2200054
STATUS: CLOSED
OPEN_DATE: 10-07-2003
CLOSE_DATE: 10-14-2003
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: 220_SIK
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHHL4RQ
SOURCE(S): N/A
PROBLEM: Diagnostic packets received (NAS7703W) in GATE
sessions. Inbound GATE calls fail to start,
call request response timeout occurs.
DESCRIPTION: Under some circumstances HNAS can get a VC control
block in a state where an inbound call will not be
accepted or cleared. A router timeout will clear
with Cause/Diag=19/50 and HNAS (when in this state)
will not respond to the clear. Subsequently the
router sends a diagnostic packet.
SOLUTION: HNAS modified so that the invalid VC state is not set.
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).
10-03-2003 - APAR 2200053 (ref: problem 2003272A)
APAR: 2200053
STATUS: CLOSED
OPEN_DATE: 09-27-2003
CLOSE_DATE: 10-03-2003
SERVICE(S): HNAS QLLC PROCESSING
MANDATORY: YES
ORIGIN/REF: 220_CET
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: HNAS fails to send NOTIFY response when NOTIFY
request carries POWER ON (PON) indication.
DESCRIPTION: This problem was introduced with APAR 2200021 which
was issued to prevent USSMSG10 from being transmitted
successively following an ACTLU response that carries
PON and a subsequent NOTIFY request that also carries
PON. A test was added to see if the SLU is already
active at the time the NOTIFY request is received.
If it is not (=> the previous ACTLU carried the POWER
OFF (POFF) indication), USSMSG10 is transmitted. If,
however, the SLU is already active when the NOTIFY
request is received, a second USSMSG10 transmission
is inhibited. Unfortunately, the same path that
created USSMSG10 also generated a positive response
for the NOTIFY request. This is why the NOTIFY
response is not returned.
SOLUTION: The logic introduced with APAR 2200021 has been
modified to first schedule the NOTIFY response
and then test the SLU state to see if USSMSG10
is required.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF). 08-29-2003 - APAR 2200052
APAR: 2200052
STATUS: CLOSED
OPEN_DATE: 08-26-2003
CLOSE_DATE: 08-27-2003
SERVICE(S): TCPIP, TAP=
MANDATORY: YES, if APAR 2200048 is applied.
ORIGIN/REF: 220_CPT
PTF_TYPE: (SRC) HNASMACX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
PREREQ(S): Distribution dated after: 08-01-2003 (see DNAS)
With APAR: 2200048 applied.
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEMS: 1) A Keep Alive failure can occur for a router even
though TAP=0 was specified on its TYPE=XOT REMOTE
definition statement.
2) A NASHALT 0198 ABEND ('INV VC 2') can occur in the
XOTXMTC module during socket close processing.
DESCRIPTIONS: 1) When TAP=0 is specified for a TYPE=XOT REMOTE
definition statement, Keep Alive processing is
supposed to be inhibited (the TAP= operand value
can be set dynamically using the MRMT console
command which will initiate Keep Alive processing).
Due to a bug that was introduced with APAR 2200048,
Keep Alive processing can be initiated for a router
even though TAP=0 is in effect. If the router or
XOT services of the router becomes inaccessible
to TCPIP, the Keep Alive attempt will fail and the
router will be placed in restart mode pending re-
acquisition of contact. If any socket connections
are active at the time of the Keep Alive failure,
they will be terminated. New socket connections
will be inhibited (Call Requests rejected) until
router contact is reestablished via a successful
Keep Alive response.
The following messages will be generated:
NAS2501W CLIENT=ipaddr(1998) SOCKID=x PCEID=y NAME=nm
NAS2501W CLIENT=ipaddr(1998) SOCKID=x PCEID=y NAME=nm
NAS2501W ROUTER KEEP ALIVE FAILURE 01 OF 02
NAS2501W CLIENT=ipaddr(1998) SOCKID=x PCEID=y NAME=nm
NAS2501W ROUTER KEEP ALIVE FAILURE 02 OF 02
NAS2502E CLIENT=ipaddr(1998) SOCKID=x PCEID=y NAME=nm
NAS2502E ROUTER CONTACT LOST
2) The internally generated Clear Request that was
introduced with APAR 2200048 presents the Clear to
the HNAS XOT component before the TCPCLS routine is
called to close the TCPIP socket. The Clear Request
causes the LU/VC/PCE connection to be broken (note
that the PCE is the TCPIP socket control block).
When the TCPCLS routine receives control, it purges
any transmit packets that were queued for delivery
to the remote. Each queued packet points at the VC
and PCE that own it. Because of the cleanup done by
the internal Clear Request, it is possible for the
disconnected VC to get reconnected to another TCPIP
PCE before the TCPCLS routine is called. In this
case, the pointer to the owning PCE within the
transmit packet(s) no longer match the PCE that the
VC is now connected to. This mismatch results in
the 198 ABEND.
SOLUTIONS: 1) The HNAS Keep Alive logic has been restored to check
for TAP=0 before automatically attempting to connect
to the router. This will prevent Keep Alive
processing from being initiated until the TAP=
operand value is set using the MRMT console command.
2) The internal Clear Request generation logic that was
introduced with APAR 2200048 has been move after the
call to TCPCLS. This will ensure that all pointers
are valid when queued transmit packets are purged.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF). 08-25-2003 - APAR 2200051
APAR: 2200051 (was Problem 2003218A)
STATUS: CLOSED
OPEN_DATE: 08-04-2003
CLOSE_DATE: 08-24-2003
SERVICE(S): ALL
MANDATORY: YES
ORIGIN/REF: 220_KWT/NBK
PTF_TYPE: (OBJ) HNASOBJX MEMBER
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
PREREQ(S): N/A
OBJECT(S): MCHTMR
SOURCE(S): N/A
PROBLEM: Inbound calls are cleared with DIAG=130 (X'82').
DESCRIPTION: This problem occurs when a new call arrives and there
are no LU control blocks available for use. This will
happen if all the LUs in an SVCx= list are in use.
When the following sequence occurs an LU can become
permanently unavailable:
Call arrives
HNAS allocates LU
Issues REQSESS to ask PLU for a BIND (normal complete)
10 sec timer started to ensure bind received
Timer expires, LU and VC detached, call cleared with
DIAG=143 (X'8F').
BIND received
At this point the LU is bound but has no VC session.
If the PLU does a SEND, error status will be returned
and the session will be reset.
If the PLU waits for input the LU is effectively lost.
This problem was caused by an unusual time delay
sequence where the PLU took longer than 10 seconds
to provide a BIND in response to HNAS's REQSESS.
Delays of greater than 10 seconds are indicative
of a host problem.
SOLUTION: HNAS logic corrected to release the LU control block
when the above timeout is occurs.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF). 08-14-2003 - APAR 2200050
APAR: 2200050
STATUS: CLOSED
OPEN_DATE: 08-14-2003
CLOSE_DATE: 08-14-2003
SERVICE(S): CONFIGURATION (LLC0|4|5) LU name generation.
MANDATORY: YES (unless all LU names are hard coded in CDF).
ORIGIN/REF: 220_CP
PTF_TYPE: (OBJ) HNASOBJX MEMBERS
PTF_LOC: FTP Server Directory /hnas_maint/hnas220m/apars/
(Complete FIX is contained in the @apar.ZIP file)
PREREQ(S): Distribution dated after: 12-20-2002
With APAR: 2200009 applied.
OBJECT(S): CNFGSVC0, CNFGSVC4, CNFGSVC5
SOURCE(S): N/A
PROBLEM: HNAS can erroneously generate a default SVC0|4|5 SLU
name that has already been specified in the same operand
list.
DESCRIPTION: HNAS generates a default SLU name for each SVC0|4|5
operand entry based on the MCH name, LLC type and
entry index as follows: NNNNijjj
where: NNNN is the first 4 characters of the REMOTE name
i is the LLC value (0|4|5)
jjj is the SVC0|4|5 operand index (0 to vclmt-1)
The generated name is used when the SLU name is omitted
for an operand entry. The problem is that HNAS does
not currently check to see if the generated name matches
a name already specified in the same operand list. This
can result in the same SLU name being used for more than
one operand entry.
Note that the SLU names that HNAS generates may not
always be appropriate for the host application. In the
cases where the host application must 'know' SLU names,
we recommend specifying the SLU names in the SVC0|4|5
operand lists rather than allowing HNAS to generate
default names.
SOLUTION: HNAS has been modified to check the generated name to
ensure that it is not already in use. If it is, a new
default and unique name will be created.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-11-2003 - APAR 2200049
APAR: 2200049
STATUS: CLOSED
OPEN_DATE: 08-10-2003
CLOSE_DATE: 08-11-2003
SERVICE(S): HNAS Trace Processing
MANDATORY: NO, But Recommended
ORIGIN/REF: 220_CPT
PTF_TYPE: (OBJ/SRC) <-On FTP Server hnas_maint/hnas220m/apars/
PREREQ(S): Distribution dated after: 08-01-2003 (see DNAS)
With APARs: 2200047 and 2200048 applied.
MACRO(S): N/A
OBJECT(S): CONSPRNT, NASUTIL
SOURCE(S): XFNASWA
PROBLEM: HNAS erroneously issues the following runtime warning
message when trace data is being logged to SYSPRINT.
NAS0111W ddddd ALARM MESSAGES LOST DURING LAST
ttt SECOND INTERVAL
DESCRIPTION: The trace logging message ID (NAS0000I) is being treated
as an informational alarm message rather than a trace
record. This can result in the informational alarm
bucket count reaching its limit (established by the
ALRMLMT operand) when it should not be. The NAS0000I
messages are generated when TRCPRNT ON is enabled.
SOLUTION: HNAS has been modified to ignore the NAS0000I message
ID when counting informational alarms. This change will
prevent NAS0111W warning messages from being generated
for non informational trace events.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
OBJ (HNASOBJX) OBJECT INSTALLATION VIA FTP:
SRC (HNASMACX) SOURCE INSTALLATION VIA FTP:
APPLY_INFO: SRC and OBJ fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200049.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
08-11-2003 - APAR 2200048
APAR: 2200048
STATUS: CLOSED
OPEN_DATE: 08-05-2003
CLOSE_DATE: 08-08-2003
SERVICE(S): HNAS TCP/IP COMPONENT - SOCKET CLOSE/LU HANG FIXES
TAP= XOT PROTOCOL LEVEL KEEP ALIVE LOGIC (TIMER DELAY
FIX, NAS2502I ALERT MESSAGE, OPTIONS=TAPWITHCLR).
MANDATORY: YES
ORIGIN/REF: 220T_KWT,220_CPT
PTF_TYPE: (OBJ/SRC) <-On FTP Server /hnas_maint/hnas220m/apars
PREREQ(S): Distribution dated after: 08-01-2003 (see DNAS)
With APAR: 2200047 applied.
OBJECT(S): CNFGOPTS, CONSDRMT CONSMRMT, CONSHELP, NASUTIL
SOURCE(S): NASMAIN, NASTCP, XFBLK, XFNASWA, XFNQDQ, XFPCE
PROBLEMS: 1) Host applications are not always notified when a
TCPIP socket connection is closed. This can result
in a hung LU session and can also cause subsequent
connect attempts to be rejected (Clear diagnostic
130 (X'82').
2) TAP keep alive failures take a long time to discover
even when a small TAP= operand value is specified.
This can result in TCPIP socket, LU and VC resources
to be in a hung state for a long period of time.
DESCRIPTIONS: 1) When a client connection is closed, either by the
remote router or the result of 2 consecutive keep
alive failures (ROUTER CONTACT LOST), HNAS initiates
TCPIP socket CLOSE processing. This causes all
outstanding TCPIP commands to be terminated and the
socket to be released. In addition, any output
that is queued for network delivery is marked as
undeliverable and is returned to the XOT transmit
terminator for cleanup service. Part of the cleanup
processing involves scheduling an UNBIND for the LU
which makes it available for another VC connection.
The hung LU problem occurs when no pending output is
queued at the time the remote disconnect is detected.
In this case, there are no output buffers around to
tell the XOT component that the connection is gone.
The result is that the socket is closed but the LU
remains connected to the host application. From
HNAS's point of view, the LU is unavailable for
another connection.
Normally, XOT sessions are terminated when a Clear
Request is received from the remote or an Unbind
is receive from the host application. It is very
unusual to encounter Socket Close conditions that
aren't precipitated by inbound Clear Requests.
The hung LU will become available upon expiration
of an application session inactivity timer or when
the LU is recycled (HNAS AMNF VARY LU INACT/ACT).
2) The HNAS TAP socket connect timer is erroneously
reset when the TCPIP CONNECT command is started.
This timeout is designed to abort the CONNECT
command and is treated as a keep alive failure
because it indicates that the router cannot be
contacted. The keep alive failure is eventually
detected because the TCPIP stack also times out
the CONNECT but its timeout value is much longer
than that of HNAS.
SOLUTIONS: 1) The HNAS CLOSE scheduler has been modified to
create an internal Clear Request packet when the
Socket Close disconnect condition is detected. The
Clear Request packet is passed to the XOT receive
processor which provides LU/VC cleanup processing.
LU/VC cleanup results in an UNBIND of the LU. This
will allow the LU to be released and made available
for a subsequent VC connection.
2) The HNAS CONNECT scheduler has been corrected to
prevent the HNAS connect timer from being reset.
This means that a connect failure will be detected
and error recovery started much sooner than before.
When 2 consecutive 'KEEP ALIVE' failures occur, the
failing router is taken offline, all active socket
connections are closed, all associated LU/VC sessions
are ended and the following message is displayed:
NAS2502I ROUTER CONTACT LOST
HNAS continues to perform the TAP function attempting
to reacquire contact with the router. When contact
is reestablished, the following message is displayed:
NAS2503W ROUTER CONTACT REAQUIRED
The severity code for this message has been changed
from 'I' to 'W' to ensure that the message is written
to the master console even when the SHOWERR option
is in affect. This message can be suppressed, if
desired, via message filtering using the ALRMFLTR=
operand.
Some router configurations cause the standard HNAS
TAP Call Request packet to be propagated to the
connected X.25 network which is an undesirable side
effect. Normally, the router simply 'eats' the
HNAS Call Request and returns a Clear Request which
satisfies the HNAS TAP requirement. In order to
eliminate this side effect and still permit the
HNAS TAP logic to function, a new option has been
added that will condition HNAS to use a Clear Request
rather than a Call Request as the TAP request packet.
For installations that prefer, and can use a Clear
Request as the TAP request, the following option may
be used for the TYPE=XOT REMOTE definition statement:
OPTIONS=TAPWITHCLR
This option can also be set using the MRMT console
command (issue HELP MRMT for details).
Note that in previous releases of HNAS, a Clear
Request was used as the TAP request but this was
changed because the IOS for some Cisco routers do
not respond to Clear Requests. This can make an
otherwise functioning router appear down. This is
why the TAP request was changed to a Call Request
which ensures a response from the router when it
and it's XOT component is both active.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
SRC (HNASMACX) SOURCE INSTALLATION VIA FTP:
OBJ (HNASOBJX) OBJECT INSTALLATION VIA FTP:
APPLY_INFO: SRC and OBJ fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200048.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
The corrected module (NASTCP) is a TCPIP dependent
module. The source for the module must be assembled
using your installation's TCPIP macro library.
08-05-2003 - APAR 2200047
APAR: 2200047
STATUS: CLOSED
OPEN_DATE: 08-01-2003
CLOSE_DATE: 08-04-2003
SERVICE(S): HNAS CONSOLE - COLLECTION OF TRACE FIXES
MANDATORY: YES IF APAR 2200047 IDENTIFIED TRACING IS REQUIRED
ORIGIN/REF: 220_NBG
PTF_TYPE: (OBJ/SRC) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): Distribution dated after: 08-01-2003 (see DNAS)
OBJECT(S): CONSDPRM, CONSHELP, CONSTALL, CONSTLU, CONSTLUQ,
CONSTMCH, CONSTMCX, CONSTVC, CONSTVCQ
SOURCE(S): NASMAIN
NOTE: TRCLU|VC is short for TRCLU or TRCVC.
PROBLEMS: 1) The TRCLU|TRCVC MAXDATA|MINDATA|NODATA start
parameters and console commands do not allow
data logging to be restricted to a single
isolated LU.
2) LU|VC traces that are started by the TRCLU|TRCVC
command are stopped when the LU|VC connection
terminates rather than by another TRCLU|TRCVC
command or TRCALL STOP.
3) The TRCALL STOP command can leave trace flags set
in the LU|VC control blocks because of a bad register
value.
4) The TRCALL STOP command can end in error ('NASCONS
INPUT ERROR, RE-ENTER') when an LUNM= value has
been specified.
DESCRIPTIONS:1) The TRCLU|TRCVC MAXDATA|MINDATA|NODATA start
parameters and console commands initiate global
LU and VC tracing, respectively, and also set
LU|VC data logging requirements. By combining
LU|VC global trace initiation and data logging,
it is not possible to limit data logging for an
individual LU|VC.
2) The TRCLU|VC ALLOFF and TRCALL STOP commands do not
reset the 'non-permanent' trace flag in the LU|VC
control blocks when a trace is stopped.
The non-permanent trace flag is used to record traces
that have been propagated from the VC to the LU and
vice versa, when a connection is initiated. The
result is that the actions of subsequent TRCLU|VC
commands are not treated as permanent. The trace
flags for an LU|VC are reset when the connection is
terminated rather than by another TRCLU|VC or
TRCALL STOP command.
3) See problem 3 above.
4) See problem 4 above.
SOLUTIONS: 1) TRCLU|VC command processors have been modified to
separate the start trace function from the data
logging function. This means that it will now be
possible to restrict data logging to a single LU|VC.
In order to start/stop global tracing, new TRCLU|VC
command arguments are provided.
TRCLU|VC STRT will start global tracing but will not
change the data logging requirement.
TRCLU|VC STOP will stop global tracing but will not
change the data logging requirement.
Note that the TRCLU|VC MAXDATA|MINDATA|NODATA start
parameters will continue to operate as before, that
is, they will both start global tracing and identify
the type of data logging to be performed. The
following table lists the differences between the
LU|VC start parameters and their console command
counterparts.
Start Parm Console Command
----------------- ------------------------------
TRCLU|VC MAXDATA TRCLU|VC MAXDATA TRCLU|VC STRT
TRCLU|VC MINDATA TRCLU|VC MINDATA TRCLU|VC STRT
TRCLU|VC NODATA TRCLU|VC NODATA TRCLU|VC STRT
TRCLU|VC OFF TRCLU|VC ALLOFF
TRCLU|VC ON TRCLU|VC MINDATA TRCLU|VC STRT
2) The TRCLU|VC ALLON|ALLOFF command processors which
are executed as part of the TRCALL STOP command stack
have been modified to reset the 'non-permanent' trace
flag so that the function that they perform will not
be altered when an LU|VC connection is terminated.
3) The TRCALL STOP command processor has been modified
to eliminate a 'blown' register that caused the trace
flags to be left on. Specifically, the register that
was used to hold the mask was not loaded when the
TRCLU|VC ALLON|ALLOFF commands were processed as
part of the TRCALL STOP command stack. This resulted
in trash being used as a mask which could be correct
sometimes and wrong others.
4) The TRCALL STOP command processor has been modified
to reset the LUNM= value so that all LUs are
processed. NOTE that the TRCALL STRT|STOP command
processors reset all command modifiers, not just
LUNM=. This means that a subsequent DPARM command
will show the command modifiers in their null state.
SRC (HNASMACX) SOURCE INSTALLATION VIA FTP:
OBJ (HNASOBJX) OBJECT INSTALLATION VIA FTP:
APPLY_INFO: SRC and OBJ fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200047.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
08-01-2003 - APAR 2200046
APAR: 2200046
STATUS: CLOSED
OPEN_DATE: 08-01-2003
CLOSE_DATE: 08-01-2003
SERVICE(S): HNAS CONFIGURATION
MANDATORY: YES
ORIGIN/REF: 220_CP
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CNFGVTAM
SOURCE(S): N/A
PROBLEM: Configuration process does not complete because of
a tight loop during CDF scan processing.
DESCRIPTION: Problem occurs when EAS=value is coded on a TYPE=MCH|XTP
REMOTE definition statement. EAS= is one of two VTAM
operands that HNAS decodes. The other is DLOGMOD.
Normally, any operand that is NOT decodable is treated
as a VTAM operand. EAS= and DLOGMOD= are special
because HNAS will provide default values when they are
omitted during generation of the Application Major Node
File (AMNF) by the FASTRUN process.
The tight loop occurs because of a bad branch in EAS=
post decode logic.
SOLUTION: The VTAM operand processor has been modified to correct
the bad branch.
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200046.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
07-23-2003 - APAR 2200045
APAR: 2200045 (Problem# 2003178A)
STATUS: CLOSED
OPEN_DATE: 06-27-2003
CLOSE_DATE: 07-23-2003
SERVICE(S): HNAS ALERT MESSAGE SUPPORT (NAS2121I/NAS2121W)
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: AUD,220_BNP(JPM)
PTF_TYPE: N/A
PREREQ(S): N/A
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: During HNAS socket close processing, a TCPIP CANCEL
command is used to 'knock' down the active TCPIP
command (normally a SELECT or RECEIVE). We have
observed that for some levels of the TCPIP stack
(for example, z/OS V1R4), the CANCEL command sometimes
ends in error and the following message is displayed:
NAS2121W SERVER=ipaddr(port) SOCKID=xxxxx PCEID=xxxxx
NAME=lclname
NAS2121I CANCEL REQUEST FAILED, RC=FFFFFFFF 00000071
DESCRIPTION: We believe that this condition occurs and these messages
are being generated because the TCPIP stack is making
a mistake. HNAS CANCEL logic has not changed since
V2R1M1 which added support for z/OS V1R2. Similarly,
the TCPIP API has remained the same since z/OS V1R2.
Our assumption is that the CANCEL command failures were
introduced by maintenance applied to the TCPIP stack.
The particular error number that HNAS receives for
the CANCEL command (00000071) indicates that the TCPIP
socket descriptor is invalid. This cannot be true
because if it were all other TCPIP commands would fail
but they do not.
Since we believed this to be a stack error, we opened
up a PMR with IBM (#55214). We were able to recreate
problem in our lab with HNAS and TCPIP stack traces
running. We passed the TCPIP stack trace on to IBM
and it revealed a timing problem. Apparently, after
HNAS receives a Clear, the remote end can take the
socket down before HNAS can (a TCP FIN is received
almost immediately after the Clear is received). The
result is that the socket is essentially closed by
the time HNAS is attempting to close it but due to
timing HNAS has not yet detected this. The ERNO=71
is wrong for this error, which IBM acknowledges.
ERNO=71 says 'invalid socket descriptor' which is
misleading (seems to be a catchall). An ERNO that
says 'socket is already closed' would have been more
appropriate. IBM has APARed this and will fix it in
a later release of the TCP stack.
SOLUTION: HNAS has been modified to treat the ERNO=71 as normal
ending status for a CANCEL command. This has no other
affect other than suppressing the NAS2121W error
message.
Since the CANCEL failure does not impact the subsequent
socket close processing, this action is appropriate.
As soon as IBM has incorporated their APAR into a later
release of the TCPIP stack, we will amend HNAS to use
the new error number value that IBM will provide.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: The corrected module (VTMUT1) is a VTAM dependent
module. The source for the module must be assembled
using your installation's VTAM macro library.
SRC (HNASMACX) SOURCE INSTALLATION VIA FTP:
SRC fixes are available for this APAR. See Chapter 6
Maintenance Information for instructions on to install
this maintenance from the 2200045.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions for
OBJ and SRC fixes.
07-23-2003 - APAR 2200044
APAR: 2200044
STATUS: CLOSED
OPEN_DATE: 06-18-2003
CLOSE_DATE: 07-18-2003
SERVICE(S): HNAS Run Time, Configuration Processing (MSGLMT=)
MANDATORY: YES
ORIGIN/REF: 220_VWG
PTF_TYPE: N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: A TCPIP slowdown condition can occur when the MSGLMT=
operand value is reached. This problem can manifest
itself in slow performance and/or outbound call request
timeouts. This problem can only occur if a user
specifies a MSGLMT= operand value that is less than
the default value which HNAS computes based on the
total number of TCPIP sockets that are configured.
DESCRIPTION: When the MSGLMT= value is set too low, HNAS may be
forced to wait for outstanding TCPIP commands to end
before new ones can be started. This can result in
sluggish performance and make TCPIP resources appear
idle when the should be available.
In the latter case, HNAS VC callout logic will not be
able to find an available TYPE=XOT REMOTE socket for
the callout connect attempt. This, in turn, will
result in a NAS7717W message being generated with a
cause and diagnostic code of 000/197. This cause and
diagnostic code indicate a Call Accept has not been
received within 30 seconds after a Call Request has
been scheduled. Note that the timeout is started when
the Call Request is scheduled rather than when it is
actually sent, that is, before the TCPIP socket is
allocated and the Call Request is passed to the stack.
HNAS issues the following warning (W) alert message
when an outbound Call Request timeout occurs.
NAS7717W LU lunm CALL TO DTE ADDR lddd...ddd VIA
REMOTE rmtnm FAILED CAUSE/DIAG=000/197 (00/C5)
- or -
NAS7717W OUTBOUND GATE CALL REQUEST VIA MCH mchnm
FAILED CAUSE/DIAG=000/197
This timeout can also occur for a 'real' failure. For
example, if the called DTE address is wrong, the X.25
network may not generate a Clear Request which would
be a valid, albeit unwanted, response to an HNAS Call
Request.
SOLUTION: To ensure optimum performance and to avoid the NAS7717W
error message when a MSGLMT= value is specified that is
too low, HNAS has been modified to force the use of the
default value. This will ensure that a Call Request
timeout will not occur because TCPIP service has to be
deferred.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200044.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
07-17-2003 - APAR 2200043
APAR: 2200043 (Problem# 2003134A)
STATUS: CLOSED
OPEN_DATE: 05-14-2003
CLOSE_DATE: 07-17-2003
SERVICE(S): QLLC
MANDATORY: YES
ORIGIN/REF: 220_POR_04-30-2003
PTF_TYPE: (SRC) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): N/A
SOURCE(S): VTMRCV1
PROBLEM: QLLC session can hang after an exchange of a few
messages.
DESCRIPTION: When the QLLC PLU sends a null FMD PIU to HNAS, an
incorrect RECEIVE macro is issued. If the PLU has
done a SEND for the next FMD PIU, the HNAS RECEIVE
effectively discards the new PIU and the session hangs.
SOLUTION: Code modified to correct HNAS RECEIVE logic.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: The corrected module (VTMRCV1) is a VTAM dependent
module that must be assembled using your installation's
VTAM macro library.
SRC (HNASMACX) SOURCE INSTALLATION VIA FTP:
SRC fixes are available for this APAR. See Chapter 6
Maintenance Information for instructions on to install
this maintenance from the 2200043.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions for
OBJ and SRC fixes.
07-12-2003 - APAR 2200042
APAR: 2200042
STATUS: CLOSED
OPEN_DATE: 07-11-2003
CLOSE_DATE: 07-12-2003
SERVICE(S): HNAS Configuration Processing
MANDATORY: YES, if APFXEQ/APFMEMSP= high memory support in use.
ORIGIN/REF: 220_SIK
PTF_TYPE: N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: When high memory subpools are used for HNAS memory
allocation, HNAS can generate an 0198 ABEND (NASHALT)
even when virtual storage is available regardless
of the order in which subpools are specified in the
APFMEMSP= start parameter. This problem seems to
occur only for very large configurations.
DESCRIPTION: HNAS is able to allocate its configuration, buffer and
PCE areas but fails when attempting to allocate the
MCH, VC and LU areas. The following NASHALT message
is generated:
HALT LOC 8003C02C IN MCHGETMI: GETMAIN UNABLE TO
ALLOCATE VC/LU STORAGE
The problem occurs because the HNAS GETMAIN macro is
invoked with LOC=(RES,ANY) instead of LOC=(ANY,ANY).
SOLUTION: HNAS has been modified to invoke GETMAIN with
LOC=(ANY,ANY).
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200042.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
07-11-2003 - APAR 2200041
APAR: 2200041
STATUS: CLOSED
OPEN_DATE: 07-11-2003
CLOSE_DATE: 07-11-2003
SERVICE(S): HNAS Configuration Processing
MANDATORY: NO
ORIGIN/REF: 220_CPT
PTF_TYPE: N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: When high memory subpools are used for HNAS memory
allocation, the FASTRUN process produces an erroneous
REGION size that is displayed in the SYSPRINT log
at the end of the STORAGE REQUIREMENT summary. The
incorrect REGION size value may cause customers to
over estimate memory requirements for the REGION=
size or APFMEMSP= subpool requirements.
DESCRIPTION: When HNAS allocates memory from high memory subpools,
the subpool number is saved as the first byte of each
fullword length value. The error occurs because HNAS
computes the REGION size by adding all the fullword
memory sizes instead of using just the 3 low order
bytes of each fullword.
SOLUTION: HNAS has been modified to compute the REGIONS size by
adding only the 3 low order bytes of each fullword
length value.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200041.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
07-10-2003 - APAR 2200040
APAR: 2200040
STATUS: CLOSED
OPEN_DATE: 07-09-2003
CLOSE_DATE: 07-10-2003
SERVICE(S): HNAS Configuration Processing
MANDATORY: NO
ORIGIN/REF: 220_CFO
PTF_TYPE: N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: HNAS issues the following error (E) configuration
message when it detects a syntax error or when it
cannot properly decode an operand or suboperand value.
NAS1x21E ERROR: deftype badvalue
Where: x = 1, 2 or 3 for BUILD, LOCAL or REMOTE.
deftype = BUILD, LOCAL or REMOTE.
badvalue = operand or suboperand value in error.
This message also sets RC=8 which forces HNAS to
terminate once the initial configuration scan
completes.
DESCRIPTION: This message can also be issued if an operand or
suboperand value is otherwise valid but is followed by
a non-printable character on the same CDF record. The
HNAS configuration process will attempt to decode values
that are non-blank when they are encountered on a CDF
record up to the semicolon (;) that starts a comment.
It is normally difficult to produce a non-printable
character when creating the HNAS CDF. However, it is
possible. This can be done using ISPF/PDF editor via
the HEX ON display or by replacing a text string with
HEX data (for example: CHANGE ABC X'010203').
SOLUTION: To avoid this error message when inadvertent HEX data
appears on a CDF record, HNAS has been modified to
translate all non-printable characters to blanks before
a CDF record is parsed.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200040.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
07-09-2003 - APAR 2200039
APAR: 2200039 (Problem# 2003143A)
STATUS: CLOSED
OPEN_DATE: 05-23-2003
CLOSE_DATE: 07-09-2003
SERVICE(S): GATE sessions stop working.
MANDATORY: YES
ORIGIN/REF: 220_AUD
PTF_TYPE: OBJ <-On FTP Server /hnas_maint/hnas220m/apars
PREREQ(S): N/A
OBJECT(S): MCHSTRT, MCHNRQC, XOTGTCC, XTPGTCC
SOURCE(S): N/A
PROBLEM New GATE sessions (callin and/or callout) cannot be
started. The NAS7717W and NAS7715W messages with
DIAG=130/X'82' may be issued. HNAS must be restarted.
DESCRIPTION: When a GATE callout operation fails the data session
LU allocated for the call may not be released. When
this happens HNAS can run out of GATE data session LUs
(these are defined by the SVC4= REMOTE operand). The
result is that new GATE sessions cannot be started.
SOLUTION: Modules corrected to release the data session LU.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: OBJ load module fixes are available for this APAR.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200039.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
07-08-2003 - APAR 2200038
APAR: 2200038 (Problem# 2003183A).
STATUS: CLOSED
OPEN_DATE: 07-02-2003
CLOSE_DATE: 07-07-2003
SERVICE(S): 220 Transparent PAD (XPAD) logic.
MANDATORY: NO
ORIGIN/REF: 220_BNP
PTF_TYPE: OBJ
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CNFGPADP, MCHHL5RQ, XOTBXM, XOTRCV, XTPBXM, XTPRCV
SOURCE(S): N/A
PROBLEM: When an LLC5 transparent PAD call-in session starts
and MCHSOL is used to select the PLU name for the
session, HNAS sends the NPSI default PAD parameters
to the remote PAD. These parameters should not be
sent when PAD=TRANSP has been coded.
DESCRIPTION: See problem.
SOLUTION: This APAR corrects HNAS so that the default NPSI PAD
parameters are not sent when PAD=TRANSP is coded.
The NPSI defaults are: 1/0, 7/21, 8/0.
Additionally, with this APAR applied PADPARM= may be
coded on a TYPE=MCH REMOTE with PAD=TRANSP. When this
is done, HNAS will send the specified parameters.
The ability to send parameters provides a feature not
available with NPSI. If you do not want parameters
sent by HNAS in an XPAD session then omit the PADPARM=
parameter.
APPLY_INFO: OBJ load module fixes are available for this APAR.
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200038.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
06-30-2003 - APAR 2200037
APAR: 2200037
STATUS: CLOSED
OPEN_DATE: 06-29-2003
CLOSE_DATE: 06-30-2003
SERVICE(S): HNAS TCP/IP SUPPORT
MANDATORY: NO
ORIGIN/REF: 220_CP
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHINI, NASUTIL
SOURCE(S): NASTCP, XFNASWA
PROBLEM: An 0C4-10 ABEND can occur during callout testing.
DESCRIPTION: An 0C4-10 ABEND can occur when a test program starts a
callout request before HNAS has connected to the TCPIP
stack. The problem occurs because a client SOCKET
request is performed before HNAS issues the TCPIP
INITAPI request. This means that the Task Information
Element (TIE) that is used for the client socket call
has not been properly initialized and registered with
the stack.
SOLUTION: HNAS TCPIP logic has been modified to delay the
client SOCKET request until HNAS has connected to
the TCPIP stack via the INITAPI request.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: SRC and OBJ fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200037.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
06-26-2003 - APAR 2200036
APAR: 2200036 (Problem# 2003157A)
STATUS: CLOSED
OPEN_DATE: 06-06-2003
CLOSE_DATE: 06-26-2003
SERVICE(S): HNAS QLLC SUPPORT
MANDATORY: YES
ORIGIN/REF: 220_NBG_05-13-2003 (WAS PROBLEM# 2003157A)
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: HNAS clears a QLLC VC call immediately after the
connection is established with DIAG=53.
DESCRIPTION: After a QLLC VC is established, HNAS sends an XID
request to the remote PU to solicit an XID response
that carries, among other things, the IDBLK/IDNUM
values that are required to select the correct
TYPE=SPU REMOTE for the VC. HNAS, by default,
assumes the role of primary link station.
The call is being cleared with DIAG=53 because HNAS
receives an XID request instead of a response and the
request has no I-field. The call is also cleared with
DIAG=53 when HNAS receives an XID response that has no
I-field. HNAS is actually in error for a number of
reasons. First, it should allow for the receipt of an
XID request when a response is expected (XID collisions
are allowed in the QLLC protocol). Second, it should
allow a null I-field in the XID request it receives.
Third, it should retry its XID request when it receives
an XID response with no I-field. An XID response with
an I-field is required to provide IDBLK/IDNUM values
for SPU allocation.
SOLUTION: The HNAS QLLC logic has been modified to allow for
an XID request that is received when a response is
expected and the request need not contain an I-field.
In this case, HNAS will ignore the XID request and
continue to wait for an XID response. HNAS will
also retry its XID request if it receives an XID
response with no I-field. It will continue to retry
its XID request until an XID response is received
that contains an I-filed for IDBLK/IDNUM matching.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200036.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
06-25-2003 - APAR 2200035
APAR: 2200035
STATUS: CLOSED
OPEN_DATE: 06-19-2003
CLOSE_DATE: 06-25-2003
SERVICE(S): GATE
MANDATORY: NO
ORIGIN/REF: 220_CAJ
PTF_TYPE: (SRC/OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHNRQC
SOURCE(S): VTMTR
PROBLEM: Following message issued when HNAS issues REQSESS to
start a GATE DATA session:
NAS3702W REQSESS FROM SLU slu-nm TO PLU plu-nm FAILED
R15=04 R0=10 FDB2=12 SENSE=0805000B
This failure is treated as an error and the call is
cleared with DIAG=143 (X'8F').
DESCRIPTION: The HNAS REQSESS operation requests a BIND from the
PLU which starts a GATE data session. If the PLU
has gotten far enough in it's own connection processing
the HNAS REQSESS is rejected and the PLU sends the BIND
that HNAS was asking for.
This error was seen for the first time using a file
transfer program called EDITRAN (a CICS application).
SOLUTION: Code modified so that the when a GATE data session
REQSESS fails with the above completion codes HNAS
ignores the error and waits for a BIND from the PLU.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: One of the corrected modules (VTMTR) is a VTAM
dependent module. The source for VTMUT1 must be
assembled using your installation's VTAM macro library.
SRC (HNASMACX) SOURCE AND OBJ INSTALLATION VIA FTP:
SRC and OBJ fixes are required for this APAR.
See Chapter 6 Maintenance Information for instructions
on installing this maintenance from the 2200035.ZIP
in /hnas_maint/hnas220m/apars
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions for
OBJ and SRC fixes.
06-21-2003 - APAR 2200034
APAR: 2200034
STATUS: CLOSED
OPEN_DATE: 06-19-2003
CLOSE_DATE: 06-21-2003
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: ENT
PTF_TYPE: (SRC) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): N/A
SOURCE(S): VTMUT1
PROBLEM: GATE control session LU slow to set up session with
the CTCP.
DESCRIPTION: If the VTAM drives the HNAS TPEND exit for a GATE
control session LU the LU field containing the PLU
name from the LUNAME= operand on the REMOTE statement
is set to blanks (=unknown). When the LU is
reactivated (based on OPTIONS=MCHTMR=xx on the REMOTE)
the PLU name is no longer known so the HNAS LU waits
for a BIND from the CTCP. When the name is known HNAS
issues a REQSESS to ask for a CTCP BIND. When REQSESS
is not issued the delay before the CTCP sends a BIND
is controlled by the CTCP. The delay can be large.
SOLUTION: Code modified so that the LU field is not reset.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: The corrected module (VTMUT1) is a VTAM dependent
module. The source for the module must be assembled
using your installation's VTAM macro library.
SRC (HNASMACX) SOURCE INSTALLATION VIA FTP:
SRC fixes are available for this APAR. See Chapter 6
Maintenance Information for instructions on to install
this maintenance from the 2200034.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions for
OBJ and SRC fixes.
06-10-2003 - APAR 2200033
APAR: 2200033*
STATUS: CLOSED_DEFERRED_V2R3M0_FIX
OPEN_DATE: 06-10-2003
CLOSE_DATE: 06-10-2003
SERVICE(S): HNAS Configuration Processing
MANDATORY: NO,INFO
ORIGIN/REF: NBG_220
PTF_TYPE: N/A
PREREQ(S): N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: HNAS issues the following configuration warning message
if TYPE=SPU REMOTE definitions are defined before they
are referenced in the SVC3= operand on a TYPE=MCH
REMOTE definition:
NAS1321W REMOTE SVC3 xxxx SPUNAME name DUPLICATED,
WILL BE ALLOCATED FCFS
DESCRIPTION: The configuration process attempts to ensure that all
resource names specified in the CDF are unique. For
the LUNAME=, PVC=, SVC0=, SVC4= and SVC5= operands,
the specified SLU names may only be referenced once.
For the SVC3= operand, SPU names can be referenced
multiple times. In the case described above, the
warning message can be issued on the first reference
of an SPU name in an SVC3= operand if the TYPE=SPU
REMOTE precedes the TYPE=MCH REMOTE in the CDF.
Although the warning message is issued, it will not
affect HNAS performance.
SOLUTION: For now, to avoid the warning message, code all TYPE=SPU
REMOTE definitions after all TYPE=MCH REMOTE definitions
in the CDF.
APPLY_INFO: This problem will be fixed in V2R3M0.
* - Denotes APAR only, no PTF issued.
06-09-2003 - APAR 2200032
APAR: 2200032
STATUS: CLOSED
OPEN_DATE: 06-06-2003
CLOSE_DATE: 06-09-2003
SERVICE(S): ALL
MANDATORY: YES
ORIGIN/REF: INT_220
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHBFR, NASUTIL, XOTBXM, XTPBXM
SOURCE(S): N/A
PROBLEM: HNAS loop.
DESCRIPTION: If the TCPIP socket is taken down while the HNAS buffer
allocator is processing HNAS console buffer service
requests a buffer can be released twice. This leads
to an HNAS loop.
SOLUTION: Code modified to remove this logic error.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
With this apar on the following messages may be issued:
NAS0105S BUFFER=addr RELEASE REJECTED, BAD ADDRESS
NAS0106S BUFFER=addr RELEASE REJECTED, ALREADY FREE
After the messages HNAS terminates with a USER 198
ABEND. Save all output from the HNAS JOB and contact
Comm-Pro for support.
APPLY_INFO: OBJ load module fixes are available for this APAR.
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from 2200032.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
05-08-2003 - APAR 2200031
APAR: 2200031
STATUS: CLOSED
OPEN_DATE: 04-28-2003
CLOSE_DATE: 05-08-2003
SERVICE(S): HNAS CONSOLE SUBSYSTEM
MANDATORY: YES
ORIGIN/REF: RWG
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CONSTALL
SOURCE(S): N/A
PROBLEM: The TRCALL STRT and TRCALL STOP console commands
are being rejected.
DESCRIPTION: The TRCALL STRT and TRCALL STOP console commands are
designed to start and stop tracing for all HNAS PCE,
MCH, MCHX, VC and LU resources.
For TRCALL STRT, this is accomplished by internally
executing TRCALL ON, TRCMCH ALLON, TRCMCHX ALLON,
TRCLU ALLON, TRCLUQ ALLON, TRCVC ALLON and
TRCVCQ ALLON.
For TRCALL STOP, this is accomplished by internally
executing TRCALL OFF, TRCMCH ALLOFF, TRCMCHX ALLOFF,
TRCLU ALLOFF, TRCLUQ ALLOFF, TRCVC ALLOFF and
TRCVCQ ALLOFF.
The TRCALL STRT and TRCALL STOP commands are being
rejected because of a syntax error in the internal
command structure that was introduced in V2R2M0.
SOLUTION: The TRCALL STRT and TRCALL STOP console command
processors have been modified to correct the invalid
syntax.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200031.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
ZAP (IMASPZAP) INSTALLATION VIA FTP APAR MEMO:
1) Create a backup copy of NASMAIN in QQQQ.HNASLOAD.
2) Install the following ZAP in the ZAP step of the
HNASMNT job and then run the HNASMNT job to rebuild
HNASMAIN with the corrective logic.
ZAP file is also located on our FTP server:
directory: hnas_maint/hnas220m/apars/
zip file: 2200031.zip
binary file: 2200031.hnaszap.bin (EBCDIC)
This member is provided for users who prefer to
transfer only the zap control (NAME, VER/REP data)
to their mainframe. Otherwise use the zap control
in this memo file.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 05-08-2003 APAR 2200031
*
* CORRECT SYNTAX ERROR FOR TRCALL STRT AND TRCALL STOP
* INTERNAL COMMAND STRUCTURE.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN CONSTALL
VER 021B 7EC1
REP 021B 40C1
VER 0229 7EC1
REP 0229 40C1
VER 0235 7EC1
REP 0235 40C1
VER 0242 7EC1
REP 0242 40C1
VER 024E 7EC1
REP 024E 40C1
VER 025B 7EC1
REP 025B 40C1
VER 0321 7EC1
REP 0321 40C1
VER 0330 7EC1
REP 0330 40C1
VER 033D 7EC1
REP 033D 40C1
VER 034B 7EC1
REP 034B 40C1
VER 0358 7EC1
REP 0358 40C1
VER 0366 7EC1
REP 0366 40C1
/*
05-09-2003 - APAR 2200030
APAR: 2200030
STATUS: CLOSED
OPEN_DATE: 04-15-2003
CLOSE_DATE: 05-09-2003
SERVICE(S): GATE
MANDATORY: NO
ORIGIN/REF: SIK
PTF_TYPE: OBJ <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): XOTTR
SOURCE(S): N/A
PROBLEM: APAR 2200011 added additional information to the
NAS7716W message. The additional information caused
the message to be truncated when displayed. The
NAS7716W message is issued when a GATE CTCP responds
to a call request packet with a clear packet. Because
of the truncation, the cause and diagnostic bytes from
the CTCP are not displayed.
DESCRIPTION: See problem.
SOLUTION: Code modified to display the message on two lines.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: OBJ load module fixes are available for this APAR.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200030.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
05-27-2003 - APAR 2200029
APAR: 2200029
STATUS: CLOSED
OPEN_DATE: 04-03-2003
CLOSE_DATE: 05-27-2003
SERVICE(S): QLLC
MANDATORY: YES
ORIGIN/REF: POR
PTF_TYPE: (ZAP-OR-OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): XOTBXM2
SOURCE(S): N/A
PROBLEM: QLLC session hangs after an exchange of a few
messages.
DESCRIPTION: When an outbound non-FMD PIU (like BID) starts a pacing
window HNAS fails to set the PACE bit in the RH.
When a full window has been sent, HNAS waits for a
pacing response before more data can be sent. Since
the remote device did not see a pacing window open,
no pacing response is sent and the session hangs.
During testing for this APAR it was observed that HNAS
sends an Isolated Pacing Response with an RU field
after the RH. This APAR also corrects this problem.
SOLUTION: Code modified to correctly set the pace bit and
to insure that an IPR does not have an RU field.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: ZAP or OBJ load module fixes are available for this
APAR.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200029.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
ZAP (IMASPZAP) INSTALLATION VIA FTP APAR MEMO:
1) Create a backup copy of NASMAIN in QQQQ.HNASLOAD.
2) Install the following ZAP in the ZAP step of the
HNASMNT job and then run the HNASMNT job to rebuild
HNASMAIN with the corrective logic.
ZAP file is also located on our FTP server:
directory: hnas_maint/hnas220m/apars/
zip file: 2200029.zip
binary file: 2200029.hnaszap.bin (EBCDIC)
This member is provided for users who prefer to
transfer only the zap control (NAME, VER/REP data)
to their mainframe. Otherwise use the zap control
in this memo file.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 05-27-2003 APAR 2200029
*
* SET PACE BIT IN OUTBOUND NON-FMD PIU THAT STARTS WINDOW.
* ENSURE ISOLATED PACING RESPONSE HAS NO RU.
*
* (TEST_DATE: 04-21-2003)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN XOTBXM2
VER 048A 4310,519D
REP 048A 47F0,A768
VER 05E4 9200,8004,4300,5140
REP 05E4 4110,8003,47F0,A600
VER 0768 0000,0000,0000,0000,0000,0000,0000,0000
REP 0768 BF11,519D,4770,A48E,9601,8001,47F0,A48E
/*
04-02-2003 - APAR 2200028
APAR: 2200028
STATUS: CLOSED
OPEN_DATE: 04-02-2003
CLOSE_DATE: 04-02-2003
SERVICE(S): HNAS Configuration Process
MANDATORY: NO
ORIGIN/REF: BBK
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: The message description and severity code for duplicate,
invalid and conflicting LOCAL and REMOTE names is too
ambiguous to allow quick error diagnosis.
DESCRIPTION: The NAS1221D (duplicate LOCAL name), NAS1211D (invalid
LOCAL name), NAS1321D (duplicate and conflicting REMOTE
name) and NAS1311D (invalid REMOTE name) error messages
allow a default name to be substituted for the name in
error and permits HNAS to continue running. This can
result in errors in other CDF operands and makes it
more difficult to diagnose the cause of the errors.
SOLUTION: The message severity code for these error messages has
been changed from 'D' to 'E' which will cause HNAS to
terminate after the CDF has been scanned. This will
allow the user to correct the error(s) and restart
HNAS. In addition, a default name will no longer be
substituted for the name in error. This means that
a valid name must specified in order for HNAS to
execute properly.
The following list describes the old and new messages
identified by this APAR:
old: NAS1221D LOCAL NAME badname DUPLICATED,
newname ASSUMED
new: NAS1221E LOCAL NMAE badname DUPLICATED,
REQUIRED
old: NAS1211D LOCAL NAME badname INVALID,
newname ASSUMED
new: NAS1211E LOCAL NAME badname INVALID,
REQUIRED
old: NAS1321D REMOTE NAME badname CONFLICTS,
newname ASSUMED
new: NAS1321E REMOTE NAME badname CONFLICTS
WITH ANOTHER REMOTE NAME, REQUIRED
old: NAS1321D REMOTE NAME badname DUPLICATED,
newname ASSUMED
new: NAS1321E REMOTE NAME badname DUPLICATED,
REQUIRED
old: NAS1311D REMOTE NAME badname INVALID,
newname ASSUMED
new: NAS1311E REMOTE NAME badname INVALID,
REQUIRED
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200028.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
04-01-2003 - APAR 2200027
APAR: 2200027
STATUS: CLOSED
OPEN_DATE: 04-01-2003
CLOSE_DATE: 04-01-2003
SERVICE(S): ALL
MANDATORY: NO
ORIGIN/REF: CP_220
PTF_TYPE: REFRESH_ONLY
PREREQ(S): 2200016
MACRO(S): N/A
OBJECT(S): MCHHRQ
SOURCE(S): N/A
PROBLEM: APAR 2200016 created a new HNAS warning message:
NAS4702W LU lu-name REJECTING NEW BIND (xxxx).
The NAS4702 message id was already assigned.
DESCRIPTION: See DESCRIPTION.
SOLUTION: Message id in the 'REJECTING NEW BIND' message changed
to NAS4704W.
APPLY_INFO: N/A
03-26-2003 - APAR 2200026
APAR: 2200026
STATUS: CLOSED
OPEN_DATE: 03-26-2003
CLOSE_DATE: 03-26-2003
SERVICE(S): HNAS Console Subsystem - Remote Console DMAP Command
MANDATORY: N/A
ORIGIN/REF: CP_220
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): CONSDMAP
SOURCE(S): CONSDMAP
PROBLEM: The DMAP APAR|TRACE command hangs when issued by a
remote console user.
DESCRIPTION: The DMAP command uses a timer interval to pause between
searching for modules with APAR or TRACE entries. For
remote console connections, the timer is never started
which results in the hang condition. Console terminal
user input will reset the hung condition.
SOLUTION: Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR. See
Chapter 6 - Maintenance Information for instructions on
how to install this maintenance from @2200026.ZIP file.
HNASBook (HNAS Guide and Reference Manual) or Chapter 6
Documentation manual revision date of March 25, 2003
contains the revised APAR maintenance instructions.
03-19-2003 - APAR 2200025
APAR: 2200025
STATUS: CLOSED
OPEN_DATE: 03-18-2003
CLOSE_DATE: 03-19-2003
SERVICE(S): HNAS CONFIGURATION
MANDATORY: NO
ORIGIN/REF: CP
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG, CNFGHOME
SOURCE(S): N/A
PROBLEM: When the HOME= operand is omitted from a TYPE=XOT REMOTE
definition statement, a default LOCAL name is set by the
configuration process for connect-in REMOTE resources
(PORT=DYNAMIC) as well as shared connect-in/connect-out
REMOTE resources (PORT=1998). This is unnecessary and
somewhat confusing because the actual LOCAL name for
connect-in REMOTE resources is set when the connection
is established.
Contrast this to shared connect-in/connect-out REMOTE
sessions whose HOME LOCAL must be set at configuration
time either explicitly or by default because these
resources require a source IP address and TCP socket
for connect-out operations.
DESCRIPTION: The default HOME LOCAL is being set for connect-in
REMOTE resources because the configuration process
does not distinguish between connect-in and connect-out
when resolving the default HOME= operand value.
SOLUTION: The configurator has been modified to provide a default
HOME LOCAL for shared connect-in/connect-out REMOTE
resources only. No default message will be issued for
connect-in REMOTE resources.
APPLY_INFO: OBJ load module fixes are available for this APAR.
In the following, QQQQ is your HNAS high level DSN
qualifier.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
1) To preserve your existing NASMAIN load module,
rename NASMAIN in QQQQ.HNASLOAD.
2) If QQQQ.HNASOBJX has members, create a backup copy
of this library so that this APAR may be easily
removed. The members listed under the OBJECT(S)
section above are required for this OBJ distribution.
3) Download hnas_maint/hnas220m/apars/2200025.zip
from our FTP server to a file named 2200025.zip on
a staging PC.
4) UNZIP this file to reveal the APAR text memo file
2200025.hnasmemo.txt|bin in ASCII and EBCDIC as
well as the stream file 2200025.hnasobjx.str.
5) Upload 2200025.hnasobjx.str to your host using a
BINARY file transfer and place it in a dataset
name STREAM.HNASOBJX.
Any name will do (its only use is in Step 6 below).
Do not use QQQQ.HNASOBJX which is a PDS.
Dataset attributes: BLKSIZE=3200, LRECL=80, DSORG=PS
RECFM=FB. SPACE=(TRK,(5,5)) will be sufficient.
6) Issue RECEIVE DATASET('STREAM.HNASOBJX').
When restore parameters are requested enter
DSN('QQQQ.HNASOBJX').
This will load the PDS members referenced in Step 2.
7) Run the HNASMNT JOB in QQQQ.HNASCNTL.
Since QQQQ.HNASOBJX is concatenated in front of
QQQQ.HNASOBJ in the linkedit step that builds the
NASMAIN load module in QQQQ.HNASLOAD, the members
loaded by Step 6 will be included in the new
NASMAIN.
03-11-2003 - APAR 2200024
APAR: 2200024
STATUS: CLOSED
OPEN_DATE: 03-11-2003
CLOSE_DATE: 03-11-2003
SERVICE(S): HNAS CONFIGURATION
MANDATORY: YES
ORIGIN/REF: CP
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: Configuration process does not complete because of
a tight loop during CDF prescan processing.
DESCRIPTION: Problem occurs when a sublist is started but is not
ended. A sublist operand is opened by a left
parenthesis and is closed by a right parenthesis.
The suboperands of a sublist can span multiple CDF
records.
For example: RTEOUT=(R2CNOT1/99, <- ( opens sublist
R2CNOT1/10T,
R2CNOT2/10,
R2CNOT3/10,
R2CNOT4) <- ) closes sublist
In this example, if the record containing the right
parenthesis is missing or inadvertently commented out,
CDF scan logic will continue reading the CDF until it
finds a record with a right parenthesis. Every CDF
record up to the point where the right parenthesis is
discovered is considered part of the same sublist.
This means, of course, that operands on the same or
subsequent definition statements are considered part
of the original sublist.
The tight loop occurs because HNAS eventually gets
'lost' so that it continues to operate on the same CDF
record in a loop instead of reading the next record
until the end of the CDF is reached.
SOLUTION: The CDF scanner has been modified to look for a loop
while processing the same CDF record over and over
again. The result is that the CDF scan will complete
with an error allowing the user to correct the invalid
CDF record and re-submit HNAS for execution.
The following are typical of the messages that this
APAR will cause to be generated:
NAS1000I CONFIGURATION DATA FILE PRESCAN IN PROGRESS
NAS1203S LOCAL TYPE=XOT REQUIRES REMOTE TYPE=MCH
BUT NONE WAS SPECIFIED
NAS1303S REMOTE TYPE=XOT REQUIRES REMOTE TYPE=MCH
BUT NONE WAS SPECIFIED
NAS1000S CONFIGURATION ERROR SUMMARY, COUNTS FOLLOW
NAS1000S INFO=0002 WARNING=0000 ERROR=0000 SEVERE=0002
NAS0021A CONFIGURATION FAILURE, RC=12
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR.
In the following, QQQQ is your HNAS high level DSN
qualifier.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
1) To preserve your existing NASMAIN load module,
rename NASMAIN in QQQQ.HNASLOAD.
2) If QQQQ.HNASOBJX has members, create a backup copy
of this library so that this APAR may be easily
removed. The members listed under the OBJECT(S)
section above are required for this OBJ distribution.
3) Download hnas_maint/hnas220m/apars/2200024.zip
from our FTP server to a file named 2200024.zip on
a staging PC.
4) UNZIP this file to reveal the APAR text memo file
2200024.hnasmemo.txt|bin in ASCII and EBCDIC as
well as the stream file 2200024.hnasobjx.str.
5) Upload 2200024.hnasobjx.str to your host using a
BINARY file transfer and place it in a dataset
name STREAM.HNASOBJX.
Any name will do (its only use is in Step 6 below).
Do not use QQQQ.HNASOBJX which is a PDS.
Dataset attributes: BLKSIZE=3200, LRECL=80, DSORG=PS
RECFM=FB. SPACE=(TRK,(5,5)) will be sufficient.
6) Issue RECEIVE DATASET('STREAM.HNASOBJX').
When restore parameters are requested enter
DSN('QQQQ.HNASOBJX').
This will load the PDS members referenced in step 2.
7) Run the HNASMNT JOB in QQQQ.HNASCNTL.
Since QQQQ.HNASOBJX is concatenated in front of
QQQQ.HNASOBJ in the linkedit step that builds the
NASMAIN load module in QQQQ.HNASLOAD, the members
loaded by Step 6 will be included in the new
NASMAIN.
03-08-2003 - APAR 2200023
APAR: 2200023
STATUS: CLOSED
OPEN_DATE: 03-01-2003
CLOSE_DATE: 03-08-2003
SERVICE(S): HNAS CONFIGURATION FASTRUN (only)
MANDATORY: NO
ORIGIN/REF: CP
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: AUTH=(ACQ,PASS) is specified for the CTCP SLU APPL
statement that is created during FASTRUN execution
of HNAS.
DESCRIPTION: AUTH=(ACQ,PASS) is unconditionally added to the APPL
statement that HNAS produces during the FASTRUN pass
for every MCH SLU name specified in the LUNAME=
operand on a TYPE=XTP|MCH REMOTE definition statement.
ACQ tells the CTCP PLU to use OPNDST OPTCD=ACQUIRE
when the APPL is opened to force a BIND of the control
session SLU. PASS tells the CTCP PLU that it can use
CLSDST OPTCD=PASS to initiate a new control session
without terminating the existing control session via
an UNBIND with BIND pending.
Because of HNAS OPTIONS=MCHTMR= operand logic, which
generates a REQSESS to the CTCP PLU for GATE control
sessions, there is no need for the AUTH=(ACQ,PASS)
operand. The REQSESS will always solicit a BIND from
the CTCP PLU via OPNDST OPTCD=ACCEPT.
SOLUTION: The FASTRUN processor within the NASCNFG module has
been modified to remove the AUTH=(ACQ,PASS) operand.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR.
In the following, QQQQ is your HNAS high level DSN
qualifier.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
1) To preserve your existing NASMAIN load module,
rename NASMAIN in QQQQ.HNASLOAD.
2) If QQQQ.HNASOBJX has members, create a backup copy
of this library so that this APAR may be easily
removed. The members listed under the OBJECT(S)
section above are required for this OBJ distribution.
3) Download hnas_maint/hnas220m/apars/2200023.zip
from our FTP server to a file named 2200023.zip on
a staging PC.
4) UNZIP this file to reveal the APAR text memo file
2200023.hnasmemo.txt|bin in ASCII and EBCDIC as
well as the stream file 2200023.hnasobjx.str.
5) Upload 2200023.hnasobjx.str to your host using a
BINARY file transfer and place it in a dataset
name STREAM.HNASOBJX.
Any name will do (its only use is in Step 6 below).
Do not use QQQQ.HNASOBJX which is a PDS.
Dataset attributes: BLKSIZE=3200, LRECL=80, DSORG=PS
RECFM=FB. SPACE=(TRK,(5,5)) will be sufficient.
6) Issue RECEIVE DATASET('STREAM.HNASOBJX').
When restore parameters are requested enter
DSN('QQQQ.HNASOBJX').
This will load the PDS members referenced in step 2.
7) Run the HNASMNT JOB in QQQQ.HNASCNTL.
Since QQQQ.HNASOBJX is concatenated in front of
QQQQ.HNASOBJ in the linkedit step that builds the
NASMAIN load module in QQQQ.HNASLOAD, the members
loaded by Step 6 will be included in the new
NASMAIN.
03-03-2003 - APAR 2200022
APAR: 2200022
STATUS: CLOSED
OPEN_DATE: 02-27-2003
CLOSE_DATE: 03-03-2003
SERVICE(S): ALL
MANDATORY: YES
ORIGIN/REF: STE
PTF_TYPE: (ZAP-OR-OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHSOL
SOURCE(S): N/A
PROBLEM: Text displayed for USS message is missing blanks.
DESCRIPTION: When USSMSG BUFFER=bfr-addr is used to define a USS
message HNAS incorrectly assumes OPT=BLKSUB. This
causes a string of blanks to be sent as a single blank.
SOLUTION: Code modified to use the correct default when BUFFER=
used to define the text in a USS message.
sessions.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: ZAP or OBJ load module fixes are available for this
APAR.
In the following, QQQQ is your HNAS high level DSN
qualifier.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
1) To preserve your existing NASMAIN load module,
rename NASMAIN in QQQQ.HNASLOAD.
2) If QQQQ.HNASOBJX has members then create a backup
copy of the library so that this APAR may be easily
removed. The members listed under the OBJECT(S)
section above are required for this OBJ
distribution version.
3) Download hnas_maint/hnas220m/apars/2200022.zip
from our FTP server to a file named 2200022.zip
on a staging PC.
4) UNZIP this file to reveal the APAR text memo file
2200022.hnasmemo.txt|bin in ASCII and EBCDIC as
well as the stream file 2200022.hnasobjx.str.
(file vrmnnnn.hnaszap.bin may also be present if
a ZAP was provided. See ZAP section of APAR for
installation instructions, as required.)
5) Upload 2200022.hnasobjx.str to your host using a
BINARY file transfer and place it in a dataset
name STREAM.HNASOBJX.
Any name will do (its only use is in Step 6 below).
Do not use QQQQ.HNASOBJX which is a PDS.
Dataset attributes: BLKSIZE=3200, LRECL=80, DSORG=PS,
RECFM=FB. SPACE=(TRK,(5,5)) will be sufficient.
6) Issue RECEIVE DATASET('STREAM.HNASOBJX').
When restore parameters are requested enter
DSN('QQQQ.HNASOBJX')
This will load the PDS members referenced in step 2.
7) Run the HNASMNT JOB in QQQQ.HNASCNTL.
Since QQQQ.HNASOBJX is concatenated in front of
QQQQ.HASOBJ in the linkedit step that builds the
NASMAIN load module in QQQQ.HNASLOAD, the members
loaded by step 6 will be included in the new
NASMAIN.
ZAP (IMASPZAP) INSTALLATION VIA FTP APAR MEMO:
1) Create a backup copy of NASMAIN in QQQQ.HNASLOAD.
2) Install the following ZAP in the ZAP step of the
HNASMNT job and then run the HNASMNT job to rebuild
HNASMAIN with the corrective logic.
ZAP file is also located on our FTP server:
directory: hnas_maint/hnas220m/apars/
zip file: 2200022.zip
binary file: 2200022.hnaszap.bin (EBCDIC)
This member is provided for users who prefer to
transfer only the zap control (NAME,VER/REP data)
to their mainframe. Otherwise use the zap control
in this memo file.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 03-02-2003 APAR 2200022.
*
* DEFAULT OPT=NOBLKSUP WHEN BUFFER= USED FOR USSMSG TEXT.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN MCHSOL
VER 1364 4740,A0E8
REP 1364 47F0,A3E8
VER 1678 0000,0000,0000,0000,0000,0000,0000,0000
REP 1678 4740,A0B2,9104,B000,4710,A0B2,47F0,A0D8
*
03-03-2003 - APAR 2200021
APAR: 2200021
STATUS: CLOSED
OPEN_DATE: 02-27-2003
CLOSE_DATE: 03-03-2003
SERVICE(S): HNAS QLLC PROCESSING
MANDATORY: YES
ORIGIN/REF: STE
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: USSMSG 10 sent to a QLLC SLU can be garbled, unreadable
or appear to overlay itself.
DESCRIPTION: USSMSG 10 is transmitted when a normal ACTLU response is
received carrying the 'power on' indication. USSMSG 10
is also transmitted when a NOTIFY request is received
that also carries the 'power on' indication. This
NOTIFY request normally only flows when a normal ACTLU
response is received carrying the 'power off' indication.
This NOTIFY informs the SSCP (which HNAS emulates)
that the device is now active. Duplicate USSMSG 10
transmissions can occur if both an ACTLU response
'power on' and NOTIFY request 'power on' are received
together. While this is not an illegal combination of
events, it is unusual and not really necessary. This
sequence of PIUs causes the problem described above.
Since the data in all USSMSGs is SNA character string,
screen control is based on blanks and carriage control
characters in the data stream rather than SBA orders.
Characters are written serially to the display starting
at the current cursor position rather than a selected
screen (buffer) position.
SOLUTION: The NOTIFY request processor within the QLSSCP module
has been modified to detect that the SLU is already
powered on which means that USSMSG 10 has already been
transmitted. This will eliminate multiple copies of
USSMSG 10 from being transmitted.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR.
In the following, QQQQ is your HNAS high level DSN
qualifier.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
1) To preserve your existing NASMAIN load module,
rename NASMAIN in QQQQ.HNASLOAD.
2) If QQQQ.HNASOBJX has members, create a backup copy
of this library so that this APAR may be easily
removed. The members listed under the OBJECT(S)
section above are required for this OBJ distribution.
3) Download hnas_maint/hnas220m/apars/2200021.zip
from our FTP server to a file named 2200021.zip on
a staging PC.
4) UNZIP this file to reveal the APAR text memo file
2200021.hnasmemo.txt|bin in ASCII and EBCDIC as
well as the stream file 2200021.hnasobjx.str.
5) Upload 2200021.hnasobjx.str to your host using a
BINARY file transfer and place it in a dataset
name STREAM.HNASOBJX.
Any name will do (its only use is in Step 6 below).
Do not use QQQQ.HNASOBJX which is a PDS.
Dataset attributes: BLKSIZE=3200, LRECL=80, DSORG=PS
RECFM=FB. SPACE=(TRK,(5,5)) will be sufficient.
6) Issue RECEIVE DATASET('STREAM.HNASOBJX').
When restore parameters are requested enter
DSN('QQQQ.HNASOBJX').
This will load the PDS members referenced in step 2.
7) Run the HNASMNT JOB in QQQQ.HNASCNTL.
Since QQQQ.HNASOBJX is concatenated in front of
QQQQ.HNASOBJ in the linkedit step that builds the
NASMAIN load module in QQQQ.HNASLOAD, the members
loaded by Step 6 will be included in the new
NASMAIN.
02-24-2003 - APAR 2200020
APAR: 2200020
STATUS: CLOSED
OPEN_DATE: 02-21-2003
CLOSE_DATE: 02-24-2003
SERVICE(S): HNAS CONSOLE SUBSYSTEM
MANDATORY: NO
ORIGIN/REF: SMC
PTF_TYPE: (OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CONSTMCH, CONSTMCX
SOURCE(S): N/A
PROBLEM: The ALLOFF argument for the TRCMCH and TRCMCHX console
console commands does not stop global MCH and MCHX
tracing, respectively.
DESCRIPTION: The TRCMCH and TRCMCHX console commands were designed
to start and stop traces for specific resources (local
traces) while the TRCMCH and TRCMCHX start parameters
start traces for ALL MCH and MCHX resources (global
traces). Prior to this APAR, the only way to stop
MCH and MCHX global tracing was to use the TRCALL STOP
console command. Understandably, this has led to some
confusion.
SOLUTION: The TRCMCH and TRCMCHX console command processors have
been modified to perform the global and local stop trace
function for the ALLOFF argument. In addition, both
global and local tracing will be started by the ALLON
argument. Note that this will make the TRCMCH and
TRCMCHX console commands behave the same way as the
TRCLU and TRCVC console commands which currently start
and stop both global and local tracing with the ALLON
and ALLOFF arguments, respectively.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: OBJ load module fixes are available for this APAR.
In the following, QQQQ is your HNAS high level DSN
qualifier.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
1) To preserve your existing NASMAIN load module,
rename NASMAIN in QQQQ.HNASLOAD.
2) If QQQQ.HNASOBJX has members, create a backup copy
of this library so that this APAR may be easily
removed. The members listed under the OBJECT(S)
section above are required for this OBJ distribution.
3) Download hnas_maint/hnas220m/apars/2200020.zip
from our FTP server to a file named 2200020.zip on
a staging PC.
4) UNZIP this file to reveal the APAR text memo file
2200020.hnasmemo.txt|bin in ASCII and EBCDIC as
well as the stream file 2200020.hnasobjx.str.
5) Upload 2200020.hnasobjx.str to your host using a
BINARY file transfer and place it in a dataset
name STREAM.HNASOBJX.
Any name will do (its only use is in Step 6 below).
Do not use QQQQ.HNASOBJX which is a PDS.
Dataset attributes: BLKSIZE=3200, LRECL=80, DSORG=PS
RECFM=FB. SPACE=(TRK,(5,5)) will be sufficient.
6) Issue RECEIVE DATASET('STREAM.HNASOBJX').
When restore parameters are requested enter
DSN('QQQQ.HNASOBJX').
This will load the PDS members referenced in step 2.
7) Run the HNASMNT JOB in QQQQ.HNASCNTL.
Since QQQQ.HNASOBJX is concatenated in front of
QQQQ.HNASOBJ in the linkedit step that builds the
NASMAIN load module in QQQQ.HNASLOAD, the members
loaded by Step 6 will be included in the new
NASMAIN.
02-28-2003 - APAR 2200019
APAR: 2200019
STATUS: CLOSED
OPEN_DATE: 02-20-2003
CLOSE_DATE: 02-21-2003 <06-24-2003> See updated comments.
SERVICE(S): ALL
MANDATORY: YES
ORIGIN/REF: SRP
PTF_TYPE: (ZAP-OR-OBJ) <-On FTP Server /hnas_maint/hnas220m/apars
COREQ(S): HNASOBJX fix: APAR 2200016 is required and is included
in this OBJ distribution. It is not a problem if
2200016 is already on.
ZAP fix: NO COREQ
The ZAP for 2200019 may be applied to any V2R2M0
system whether or not 2200016 is applied.
PREREQ(S): N/A
OBJECT(S): MCHHRQ (2200016 and 2200019)
MCHHL0RQ, MCHHL3RQ, MCHHL4RQ, MCHHL5RQ (2200016)
SOURCE(S): N/A
PROBLEM: HNAS sessions can contain large numbers of null PIUs.
<06-24-2003> Under certain timing conditions an HNAS non-QLLC
session can hang as a result of this problem.
DESCRIPTION: In previous versions HNAS discarded NULL PIUs from the
PLU. For QLLC, null PIUs must be sent to the remote
because the PIU's RH contains information that may be
required by the remote. The new logic was applied to
all session types when V2R2M0 was introduced.
SOLUTION: Code modified to restore the earlier logic for non-QLLC
sessions.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: ZAP or OBJ load module fixes are available for this
APAR.
In the following, QQQQ is your HNAS high level DSN
qualifier.
OBJ (HNASOBJX) LOAD MODULE INSTALLATION VIA FTP:
1) To preserve your existing NASMAIN load module,
rename NASMAIN in QQQQ.HNASLOAD.
2) If QQQQ.HNASOBJX has members then create a backup
copy of the library so that this APAR may be easily
removed. The members listed under the OBJECT(S)
section above are required for this combined OBJ
distribution version (This implementation ensures
that all required 2200016 OBJ code is present for
both APARs due to 2200019 MCHHRQ requirements).
3) Download hnas_maint/hnas220m/apars/2200019.zip
from our FTP server to a file named 2200020.zip
on a staging PC.
4) UNZIP this file to reveal the APAR text memo file
2200019.hnasmemo.txt|bin in ASCII and EBCDIC as
well as the stream file 2200019.hnasobjx.str.
(file vrmnnnn.hnaszap.bin may also be present if
a ZAP was provided. See ZAP section of APAR for
installation instructions, as required.)
5) Upload 2200020.hnasobjx.str to your host using a
BINARY file transfer and place it in a dataset
name STREAM.HNASOBJX.
Any name will do (its only use is in Step 6 below).
Do not use QQQQ.HNASOBJX which is a PDS.
Dataset attributes: BLKSIZE=3200, LRECL=80, DSORG=PS,
RECFM=FB. SPACE=(TRK,(5,5)) will be sufficient.
6) Issue RECEIVE DATASET('STREAM.HNASOBJX').
When restore parameters are requested enter
DSN('QQQQ.HNASOBJX')
This will load the PDS members referenced in step 2.
7) Run the HNASMNT JOB in QQQQ.HNASCNTL.
Since QQQQ.HNASOBJX is concatenated in front of
QQQQ.HASOBJ in the linkedit step that builds the
NASMAIN load module in QQQQ.HNASLOAD, the members
loaded by step 6 will be included in the new
NASMAIN.
The APAR 2200019 distribution file also contains APAR
2200016. There is no conflict if you already have
2200016 on your system via an earlier refresh.
ZAP (IMASPZAP) INSTALLATION VIA FTP APAR MEMO:
1) Create a backup copy of NASMAIN in QQQQ.HNASLOAD.
2) Install the following ZAP in the ZAP step of the
HNASMNT job and then run the HNASMNT job to rebuild
HNASMAIN with the corrective logic.
ZAP file is also located on our FTP server:
directory: hnas_maint/hnas220m/apars/
zip file: 2200019.zip
binary file: 2200019.hnaszap.bin (EBCDIC)
This member is provided for users whom prefer to
transfer only the zap control (NAME, VER/REP data)
to their mainframe. Otherwise use the zap control
in this memo file.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 02-21-2003 APAR 2200019.
*
* DO NOT CREATE NULL X25 PACKET WHEN PLU SENDS A NULL PIU.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN MCHHRQ
VER 072A 47F0,A8CE
REP 072A 47F0,A998
VER 0998 0000,0000,0000,0000,0000,0000,0000,0000,0000,0000
REP 0998 9514,50CD,4780,A8CE,BF0F,50C8,4770,A8CE,47F0,A732
*
02-13-2003 - APAR 2200018
APAR: 2200018
STATUS: CLOSED
OPEN_DATE: 01-28-2003
CLOSE_DATE: 02-13-2003
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: BBK
PTF_TYPE: (ZAP-or-ORDER REFRESH)
Old Format PTF, OBJ|SRC not provided on FTP Server
although ZAP memo file is. /hnas_maint/hnas220m/apars
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): MCHHGTRQ
SOURCE(S): N/A
PROBLEM: HNAS rejects BIND for GATE control session with sense
0821E009.
DESCRIPTION: The NPSI manual specifies that the GATE control session
must be bound in contention mode. If the HDX/FF bit
is set in the BIND image the BIND is rejected with
the sense shown above.
We have received a request to remove the contention
mode requirement on GATE control session BINDs.
SOLUTION: Code that rejects the HDX/FF control session bind
removed. HNAS can operate the session in HDX/FF
mode.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: The following ZAP may be applied to implement this
APAR.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 02-13-2003 APAR 2200018
*
* ALLOW HDX/FF GATE CONTROL SESSION BIND.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN MCHHGTRQ
VER 00A4 4710,A0DC
REP 00A4 4700
VER 00AC 4780,A0D8
REP 00AC 4700
*
02-12-2003 - APAR 2200017
APAR: 2200017
STATUS: CLOSED
OPEN_DATE: 01-28-2003
CLOSE_DATE: 02-12-2003
SERVICE(S): ALL
MANDATORY: GATE
ORIGIN/REF: BBK
PTF_TYPE: (ORDER_SOURCE_MEMBER-or-ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): VTMRCV1
PROBLEM: Data from CTCP to GATE SLU rejected (sense=0821) and
diagnostic message "INVALID GATE CTCP CMD BYTE" sent
to the CTCP.
DESCRIPTION: The above sequence can occur if a GATE CTCP sends a
null PIU to HNAS. Such PIUs may be used to convey
SNA information such as bracket end. HNAS incorrectly
assumes that FMD from a CTCP must contain data (at
least a valid GATE command byte).
SOLUTION: Logic corrected so that HNAS correctly processes a
null PIU from the CTCP.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: The fix for this problem involves a change to the
VTMRCV1 HNAS module. VTMRCV1 uses IBM VTAM macros
that are installed on your system. To install a
revised VTMRCV1 take the following steps:
1) Obtain a revised VTMRCV1 macro from Comm-Pro.
It will be sent as an email attachment.
2) Install VTMRCV1 in the QQQQ.HNASMACX library.
3) Run the HNASMNT job to assemble VTMRCV1 (using
your installation's VTAM macros) and rebuild
the NASMAIN load module.
02-13-2003 - APAR 2200016
APAR: 2200016
STATUS: CLOSED
OPEN_DATE: 02-05-2003
CLOSE_DATE: 02-13-2003
SERVICE(S): ALL
MANDATORY: YES
ORIGIN/REF: POR
PTF_TYPE: (ORDER_OBJECT_MODULES-or-ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): MCHHRQ, MCHHL2RQ, MCHHL3RQ, MCHHL4RQ, MCHHL5RQ
SOURCE(S): N/A
PROBLEM: HNAS terminates with a USER 198 ABEND and the message
"HALT AT LOC xxxxxx IN MCHHRQ: BIND TO ACTIVE LU"
DESCRIPTION: When HNAS receives a BIND to an LU that already has
a session the above failure occurs. The error
indicates a state mismatch between the PLU and HNAS's
SLU. This can happen if the PLU believes that HNAS
supports parallel sessions. The correct response
is to issues an alarm, reject the new bind with
sense=0821FFFF and to CLOSE the ACB for the LU with
failure.
SOLUTION: Code corrected to provide the above logic. The
alarm message is as follows:
NAS4702W ACTIVE LU lu-name REJECTING NEW BIND (xxxx)
lu-name is the name of the LU.
xxxx is diagnostic information for Comm-Pro.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: A ZAP is not available for this fix. Refresh your
HNAS system or request revised object code from
customer support.
02-12-2003 - APAR 2200015
APAR: 2200015
STATUS: CLOSED
OPEN_DATE: 02-05-2003
CLOSE_DATE: 02-12-2003
SERVICE(S): ALL
MANDATORY: QLLC ONLY
ORIGIN/REF: POR
PTF_TYPE: (ORDER_SOURCE_MEMBER-or-ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): VTMRCV1
PROBLEM: When HNAS receives an UNBIND with BIND pending from
the PLU, the UNBIND is not sent to the remote.
DESCRIPTION: See PROBLEM.
SOLUTION: Logic corrected so that an UNBIND with BIND pending
is forwarded to the QLLC remote.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: The fix for this problem involves a change to the
VTMRCV1 HNAS module. VTMRCV1 uses IBM VTAM macros
that are installed on your system. To install a
revised VTMRCV1 take the following steps:
1) Obtain a revised VTMRCV1 macro from Comm-Pro.
It will be sent as an email attachment.
2) Install VTMRCV1 in the QQQQ.HNASMACX library.
3) Run the HNASMNT job to assemble VTMRCV1 (using
your installation's VTAM maclib) and rebuild the
NASMAIN load module.
02-05-2003 - APAR 2200014
APAR: 2200014
STATUS: CLOSED
OPEN_DATE: 02-05-2003
CLOSE_DATE: 02-05-2003
SERVICE(S): HNAS Initialization Processing
MANDATORY: NO, if NASMAIN assembly uses HOST=OS390
ORIGIN/REF: POR
PTF_TYPE: (ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): NASMAIN
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: An 0C4 ABEND will occur if the assembly of the
NASMAIN module during the HNASRCV job uses HOST=ZOS
instead of HOST=OS390.
DESCRIPTION: If the assembly of the NASMAIN module uses HOST=ZOS
instead of HOST=OS390, required logic is omitted
from the assembled module. The omitted logic is
required to initialize the TCP/IP control blocks
for the macro API (EZASMI). This logic is required
for both OS390 and ZOS but is erroneously only
included for OS390.
SOLUTION: Ensure that HOST=OS390 is specified for the NASMAIN
and NASTCP assemblies in the HNASRCV job even when
your host system environment is actually ZOS.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
02-12-2003 - APAR 2200013
APAR: 2200013
STATUS: CLOSED
OPEN_DATE: 02-05-2003
CLOSE_DATE: 02-12-2003
SERVICE(S): ALL
MANDATORY: NO
ORIGIN/REF: SMC
PTF_TYPE: (ZAP-or-ORDER REFRESH)
Old Format PTF, OBJ|SRC not provided on FTP Server
although ZAP memo file is. /hnas_maint/hnas220m/apars
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): MCHLUIN
SOURCE(S): N/A
PROBLEM: APAR 2100013 created a new warning message:
NAS3720S LU lu-name INBOUND X25 MESSAGE COULD NOT BE
DELIVERED BY THE LU BUFFER LIST.
Under some circumstances the message is issued when
the buffer list was not full and there was no error.
DESCRIPTION: See PROBLEM.
SOLUTION: Logic corrected so that the message is not issued
unless error condition exists (the BUILD statement
LUBLTCNT= should be used to increase the LU buffer
list size).
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: The following ZAP may be applied to the NASMAIN load
module in QQQQ.HNASLOAD using the sample HNASZAPL
JOB in the QQQQ.HNASCNTL library as a temporary
patch or applied as a permanent patch using the ZAP
step in the HNASMNT JOB as referred to in Chapter 6.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 02-05-2003 APAR 2200013
*
* ENSURE THAT MESSAGE IS NOT ISSUED UNLESS ERROR CONDITION.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN MCHLUIN
VER 08D0 47F0,A8EC
REP 08D0 47F0,A9D0
VER 09D0 0000,0000,0000
REP 09D0 1B77,47F0,A8EC
*
02-04-2003 - APAR 2200012 *_See_Reason_1)
APAR: 2200012 *
STATUS: 1_CLOSED_DEFERRED_V2R2M1_CIRCUMVENTION
2_CLOSED
OPEN_DATE: 02-04-2003
CLOSE_DATE: 02-04-2003
SERVICE(S): HNAS QLLC Configuration and QLLC run time processing
MANDATORY: YES
ORIGIN/REF: POR
PTF_TYPE: (ZAP-ITEM_2,ORDER_REFRESH-ITEM_1,ITEM_2)
Old Format PTF, OBJ|SRC not provided on FTP Server
although ZAP memo file is. /hnas_maint/hnas220m/apars
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: 0C4 ABEND in QLSSCP module when XID response received
from remote SPU with incorrect HNAS configuration.
DESCRIPTION: An 0C4 ABEND can occur when an XID response is
received if the HNAS SPU configuration block is not
initialized correctly. This can occur for 2 reasons:
1) A TYPE=SPU REMOTE definition statement appears in
the HNAS CDF but is not referenced in the SVC3=
operand list for some TYPE=MCH REMOTE definition
statements. An SPU cannot be initialized unless
it is identified in an SVC3= operand list entry.
2) A TYPE=SPU REMOTE definition statement appears in
the HNAS CDF and is also referenced in the SVC3=
operand list for some TYPE=MCH REMOTE definition
statements but the SVC3= operand list count is too
small to accommodate the SPU entry. In this case,
the following error message is produced:
NAS1303W LIMIT: REMOTE ... entry ...
SOLUTION: For 1) above, the fix will be included in the next
release of HNAS. For V2R2M0, you must make sure
that all TYPE=SPU REMOTE definition statements are
referenced as an SVC3= operand entry.
For 2) above, the fix is to force HNAS to terminate
after the CDF is completely processed so the error
can be corrected by specifying a larger VCLMT value
for the SVC3= operand. Note that this logic also
applies to the PVC=, SVC0=, SVC4= and SVC5= operands.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: The following ZAP may be applied to the NASMAIN load
module in QQQQ.HNASLOAD using the sample HNASZAPL
JOB in the QQQQ.HNASCNTL library as a temporary
patch or applied as a permanent patch using the ZAP
step in the HNASMNT JOB as referred to in Chapter 6.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 02-04-2003 APAR 2200012
*
* FORCE HNAS TO TERMINATE IF ARRAY LIMIT EXCEEDED (ITEM 2)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN NASCNFG
VER 2824 BF04,AE40
REP 2824 BF04,AE52
VER 287C E6
REP 287C C5
*
01-22-2003 - APAR 2200011
APAR: 2200011
STATUS: CLOSED
OPEN_DATE: 01-09-2003
CLOSE_DATE: 01-22-2003
SERVICE(S): LLC0, LLC4 and LLC5 callout
MANDATORY: NO
ORIGIN/REF: SWC,RBG
PTF_TYPE: (ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): VCCLEAR, MCHTMR, XOTTR, XOTFCDC, XOTGTCC
XTPTR, XTPFCDC, XTPGTCC
SOURCE(S): N/A
PROBLEM: When an outbound HNAS call request fails HNAS message
NAS7717W is issued. Since the message does not include
the IP address of the router or the name of the TYPE=XOT
HNAS REMOTE statement, locating a misconfigured router
can be difficult.
Prior to this APAR the NAS7717W message was only issued
for GATE sessions. With this APAR applied the message
is issued any time HNAS receives a clear in response
to a call request.
DESCRIPTION: See PROBLEM.
SOLUTION: The text associated with NAS7716W, NAS7717W and NAS6717W
has been changed. The new text is shown below.
========================================================
NAS7716W INBOUND GATE CALL REQ FROM ip-addr
TO MCH mch-nm FAILED, CTCP CLR'D VIA
LU lu-nm CAUSE/DIAG=DDD/DDD (XX/XX)
A GATE CTCP sent HNAS a clear in response to a HNAS XOT
call request.
ip-addr is the IP address the call request was received
from.
mch-nm is the name of the TYPE=XOT remote that the call
was routed to.
lu-nm is the LU name of the HNAS LU that received the
clear from the CTCP.
========================================================
NAS7717W LU lu-nm CALL TO d...d ON rmt-nm FAILED
CAUSE/DIAG=DDD/DDD (XX/XX)
A clear was received in response to a HNAS XOT call
request.
lu-nm is the name of the HNAS LU that generated the
call. This will be an LLC0, LLC5 or GATE control
session LU.
d...d is the called DTE address.
rmt-nm is the name on the TYPE=XOT,PORT=1998 REMOTE
statement used for the call. The IP address can be
found on the named remote statement.
========================================================
NAS6717W LU lu-nm CALL TO DTE ADDR d...d VIA REMOTE
rmt-nm FAILED CAUSE/DIAG=DDD/DDD (XX/XX)
An HNAS call request to an XTP router failed.
lu-nm is the HNAS LU that generated the call request.
It will be an LLC0, LLC5 or GATE control session LU.
For XTP, the LU is associated with a TYPE=XOT REMOTE.
The IP address of the router that sent the clear may
be found on the named REMOTE statement.
d...d is the called DTE address.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
APPLY_INFO: N/A
12-20-2002 - APAR 2200010
APAR: 2200010
STATUS: CLOSED
OPEN_DATE: 12-19-2002
CLOSE_DATE: 12-20-2002
SERVICE(S): HNAS LLC0 and LLC5 callout
MANDATORY: NO
ORIGIN/REF: CP
PTF_TYPE: (ZAP-or-ORDER REFRESH)
Old Format PTF, OBJ|SRC not provided on FTP Server
although ZAP memo file is. /hnas_maint/hnas220m/apars
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): XOTBXM, XTPBXM
SOURCE(S): N/A
PROBLEM: Outbound calls cleared by router with Cause=19,
Diag=68.
DESCRIPTION: If DCEADDR=NONE is coded on a TYPE=MCH or TYPE=XTP
REMOTE statement HNAS generates an invalid calling
DTE address containing an address digit with the
value X'F'. This is invalid because called address
digits must be decimal.
SOLUTION: HNAS logic corrected to properly process the
DCEADDR=NONE specification on TYPE=MCH/XTP REMOTE
statements.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in APPLY_INFO.
This problem may also be corrected by omitting the
DCEADDR=NONE operand on the TYPE=MCH/XTP REMOTE
statement..
APPLY_INFO: The following ZAPs correct this problem.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 12-20-02 APAR 2200010
*
* PROCESS DCEADDR=NONE ON TYPE=MCH/XTP REMOTE CORRECTLY.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NAME NASMAIN XOTBXM
VER 01AA 4780,A1B4
REP 01AA 47F0,AD88
VER 0D88 0000,0000,0000,0000,0000,0000,0000,0000
REP 0D88 4780,A1B4,95FF,1030,4780,A1B4,47F0,A1AE
*
*
NAME NASMAIN XTPBXM
VER 015C 4780,A166
REP 015C 47F0,AA20
VER 0A20 0000,0000,0000,0000,0000,0000,0000,0000
REP 0A20 4780,A166,95FF,8030,4780,A166,47F0,A160
*
12-20-2002 - APAR 2200009
APAR: 2200009
STATUS: CLOSED
OPEN_DATE: 12-19-2002
CLOSE_DATE: 12-20-2002
04-02-2003 - References changed as follows:
rmtname changed to ownrname
index changed to ownrname
mxtname changed to trgtname
SERVICE(S): HNAS Configuration Processing
MANDATORY: NO
ORIGIN/REF: CP
PTF_TYPE: (ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): CNFGSVC0, CNFGSVC3, CNFGSVC5
SOURCE(S): CNFGSVC0, CNFGSVC3, CNFGSVC5
PROBLEM: HNAS issues the following warning (W) configuration
message when the MXT name specified in an SVC0=, SVC3=
or SVC5= operand cannot be resolved.
NAS1311W REMOTE ownrname SVCi subopnum RMTNAME trgtname
NOT FOUND, IGNORED
This message also sets RC=4 which allows HNAS to
continue to run when it should not be allowed to.
Subsequent processing that assumes the existence of
the MXT will not function correctly. The message
severity should be set to error (E) and RC=8 set to
force HNAS to terminate so that the error can be
corrected.
DESCRIPTION: For a TYPE=MCH|XTP REMOTE definition statement, when
an MXT name that is specified in the SVC0, SVC3= or
SVC5= operand cannot be resolved, the above message
is issued and RC=4 is set. This means that HNAS
treats the unresolved MXT as though no MXT were
specified. Since the user specifically coded an MXT
name, it must be required to supply optional callout
data, for example, DTEADDR=. Usually, this error
occurs because of a 'typo' which causes the MXT name
to be misspelled.
SOLUTION: To avoid run time problems that can occur when an MXT
name cannot be resolved, the SVC0=, SVC3= and SVC5=
operand processors have been modified to generate an
error configuration message and set RC=8. This will
cause HNAS to terminate after the entire CDF has been
processed. The misspelled MXT name must be corrected
before HNAS can be restarted. New error message:
NAS1311E REMOTE ownrname SVCi subopnum RMTNAME trgtname
NOT FOUND, REQUIRED
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
12-20-2002 - APAR 2200008
APAR: 2200008
STATUS: CLOSED
OPEN_DATE: 12-18-2002
CLOSE_DATE: 12-20-2002
SERVICE(S): HNAS Configuration Processing
MANDATORY: NO
ORIGIN/REF: CP
PTF_TYPE: (ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): CNFGSVC0, CNFGSVC3
SOURCE(S): CNFGSVC0, CNFGSVC3
PROBLEM: HNAS issues the following default configuration
message when the SVC3= operand is omitted with
GATE=NO,PAD=NO even though the SVC0= operand is
specified.
NAS1301D REMOTE SVC3 OMITTED, 32 VCS WILL BE
RESERVED FOR QLLC
The same situation is true for SVC0= processing
although the NAS1301D message text refers to
SVC0= and PCNE instead of SVC3= and QLLC.
DESCRIPTION: For a TYPE=MCH REMOTE definition statement, when
GATE=NO is specified, only LLC0, LLC3 and/or LLC5
resources are allowed. When PAD=NO is also
specified, only LLC0 and/or LLC3 resources are
allowed. When either LLC0 or LLC3 resources are
specified, the other, is not required. Hence,
the above messages should not be issued when
either LLC0 or LLC3 resources are specified via
the SVC0= or SVC3= operands, respectively.
SOLUTION: The SVC0= and SVC3= operand processors have been
modified to check for the other being specified.
If the other operand is specified, the default
configuration message is withheld.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
Note that the default message could also be
suppressed by coding either SVC0=NONE or SVC3=NONE,
but not both.
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
12-13-2002 - APAR 2200007*
APAR: 2200007*
STATUS: CLOSED_DEFERRED_V2R2M1_CIRCUMVENTION
OPEN_DATE: 12-13-2002
CLOSE_DATE: 12-13-2002
SERVICE(S): HNAS Configuration Processing
MANDATORY: NO
ORIGIN/REF: SMB,OVR
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: HNAS issues a configuration summary message containing
a count for the number of messages issued during the
configuration processing based on their severity:
informational (INFO= for RC=0), warning (WARNING= for
RC=4), error (ERROR= for RC=8) and sever error (SEVERE=
for RC=12).
NAS1000x CONFIGURATION ERROR SUMMARY, COUNTS FOLLOW
NAS1000I INFO=dddd WARNING=dddd ERROR=dddd SEVERE=dddd
DESCRIPTION: Because configuration messages with a Default (D)
severity code result in the setting of RC=4 just as
those with a severity code of warning (W), they are
counted in the WARNING= accumulation. Hence, you
may see a non-zero WARNING= count value even if no
warning messages were generated during configuration
processing.
SOLUTION: A 220 solution is to allow generation of the defaults
then code the appropriate values in the HNAS CDF so
that the default values will no longer be generated.
You can also simply treat the WARNING= count as a
count of both warning and default messages issued.
APPLY_INFO: This problem will be fixed in V2R2M1.
* - Denotes APAR only, no PTF issued.
12-13-2002 - APAR 2200006
APAR: 2200006
STATUS: CLOSED
OPEN_DATE: 12-13-2002
CLOSE_DATE: 12-13-2002
SERVICE(S): HNAS QLLC Interface
MANDATORY: YES
ORIGIN/REF: FDK
PTF_TYPE: (ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): QLSSCP
SOURCE(S): QLSSCP
PROBLEM: ACTLU response containing error sense of X'0806'
(resource unknown) is being retried indefinitely.
This continuously generates error messages which
can eventually fill the HNAS log dataset (SYSPRINT).
DESCRIPTION: When an SLU is defined in the LUNAME= operand on a
TYPE=SPU REMOTE definition statement, it is assigned
a local address (LOCADDR) based on its position in the
LUNAME= operand list. HNAS will attempt to activate
every SLU named in the LUNAME= operand list. If an
SLU name is specified for which there is no SLU at the
remote SPU, the SPU will return a exception response
for the ACTLU containing the X'0806' sense indication.
SOLUTION: The ACTLU response processor and ACTLU retry timer
processor have been modified to detect the X'0806'
sense condition to prevent the ACTLU from being
retried. The next release of HNAS will allow the
ACTLU to be retried based on a console command.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
12-13-2002 - APAR 2200005
APAR: 2200005
STATUS: CLOSED
OPEN_DATE: 12-13-2002
CLOSE_DATE: 12-13-2002
SERVICE(S): HNAS QLLC Interface
MANDATORY: YES
ORIGIN/REF: FDK
PTF_TYPE: (ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): QLSSCP
SOURCE(S): QLSSCP
PROBLEM: XID response containing IDBLK/IDNUM values that do not
match any values in the CDF can cause an 0C4 ABEND.
DESCRIPTION: The register used to address the TCP/IP Process Control
Element (PCE) for the QLLC session was not loaded for
the call to the TCPWTO subroutine. TCPWTO uses the PCE
to build a WTO message containing the IPADDR=, SOCKID=
and PCEID= values for the error message. The ABEND
occurs because an invalid address is in the PCE base
register.
SOLUTION: The XID response processor has been modified to set the
PCE address in the PCE base register prior to calling
the TCPWTO subroutine.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
12-10-2002 - APAR 2200004
APAR: 2200004
STATUS: CLOSED
OPEN_DATE: 12-06-2002
CLOSE_DATE: 12-10-2002
SERVICE(S): HNAS Console Subsystem - Remote Console Find Command
MANDATORY: N/A
ORIGIN/REF: CP_220
PTF_TYPE: (ZAP-or-ORDER REFRESH)
Old Format PTF, OBJ|SRC not provided on FTP Server
although ZAP memo file is. /hnas_maint/hnas220m/apars
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): CONSFIND
SOURCE(S): CONSFIND
PROBLEM: The FIND command hangs when issued by a remote console
user.
DESCRIPTION: The FIND command uses a timer interval to pause between
successive 256 byte searches. For remote console
connections, the timer is never started which results
in the hang condition. Console terminal user input will
reset the hung condition.
SOLUTION: Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: This condition can be avoided by applying the following
ZAP.
Apply the following ZAP to the CONSFIND module in the
HNAS object library then rebuild the HNAS load module.
//ZAP JOB acctinfo
//ZAP EXEC PGM=AMASPZAP
//SYSLIB DD DSN=hnasobj,DISP=OLD
//SYSIN DD *
NAME CONSFIND CONSFIND
VER 04A0 D703,9024,9024
REP 04A0 47F0,A6A8,0600
/*
If you want to ZAP the existing HNAS load module rather
than the CONSFIND module in the HNAS object library,
change the SYSLIB DD statement above to point at the
HNAS load library and change the NAME statement to
NAME NASMAIN CONSFIND.
11-21-2002 - APAR 2200003
APAR: 2200003
STATUS: CLOSED
OPEN_DATE: 11-20-2002
CLOSE_DATE: 11-21-2002
SERVICE(S): HNAS TCP/IP Interface
MANDATORY: Required for callout support.
ORIGIN/REF: LGD
PTF_TYPE: (ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): NASTCP
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: Outbound call requests are rejected with an internally
generated clear request (DIAG=X'C3'=195).
DESCRIPTION: Timing error introduced with shared socket support
caused the Call Request packet to be rejected by HNAS
TCP/IP interface immediately after a socket was
opened by the XOTOPN routine to handle the call.
The problem occurs because the HNAS TCP/IP Process
Control Element (PCE) is left in an idle state which
causes the transmit buffer enqueue routine (TCPXMT)
to think that the socket is not active to process the
transmit buffer. The transmit buffer is marked with
the 'lost contact' return code. This causes the
internal clear to be generated.
SOLUTION: The HNAS XOTOPN routine has been modified to set the
PCE to initialization state when the TCP/IP socket is
opened. This will prevent the TCPXMT routine from
rejecting the Call Request packet.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
11-21-2002 - APAR 2200002
APAR: 2200002
STATUS: CLOSED
OPEN_DATE: 11-18-2002
CLOSE_DATE: 11-21-2002
SERVICE(S): HNAS LLC determination when SUBADDRESS=YES coded.
MANDATORY: YES
ORIGIN/REF: EPY_2110018
PTF_TYPE: (ORDER_ZAP-or-ORDER_REFRESH)
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): VCCLRQ
SOURCE(S): N/A
PROBLEM: Inbound calls fail to connect. The calls are cleared
with a HNAS diagnostic like X'83', X'89', or X'C8'.
DESCRIPTION: APAR 2110018 changed HNAS so that the LLC type for an
inbound call was set by processing call user data
byte 0 (CUD0) before examining the subaddress digit
(last digit in the called DTE address). If CUD0 did
not set the LLC then the subaddress digit used in
conjunction with the LLC0=, LLC4= and LLC5= operands
to set the LLC type. Subaddress logic requires
GATE=GENERAL and SUBADDRESS=YES on the REMOTE
statement.
Further investigation has shown that the original
logic (subaddress first if SUBADDRESS=YES, then CUD0)
was correct.
SOLUTION: HNAS modified to restore original logic.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: A ZAP is available for this problem.
11-13-2002 - APAR 2200001
APAR: 2200001
STATUS: CLOSED
OPEN_DATE: 11-13-2002
CLOSE_DATE: 11-13-2002
SERVICE(S): HNAS Configuration Processing - Gate FC Resources
MANDATORY: N/A
ORIGIN/REF: 2110021
DESCRIPTION: APAR Applied before initial product distribution.
(see APAR 2110021 for details)
SOLUTION: N/A
APPLY_INFO: N/A
11-11-2002 - APAR 2200000 - Notice
APAR: 2200000
STATUS: SERVICE_NOTICE-<BEGIN_MAINTENANCE/APAR_CYCLE>
OPEN_DATE: 11-11-2002
CLOSE_DATE: ----------
SERVICE(S): ALL_V2R2M0
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 V2M2M0 release is now available.
DESCRIPTION: Standard maintenance/APARs are now provided for
this distribution level.
SOLUTION: N/A
APPLY_INFO: N/A
11-11-2002 - HNAS V2R2M0 officially released.
08-01-2002 - General Availability sometime in 4th Qtr 2002.
The initial release of this product was delayed because several
new features were included that were previously slated for V2R3.03-01-2002 - Pre-release for some HNAS components currently available.
Last Update - March 22, 2005