07-01-2001 - V2R1M0 Currently under development, some component's Alpha testing.
09-01-2001 - Development project for V1R1M5 reassigned to V2R1M0. This was
done to provide a more robust product upgrade for our customers.
09-19-2001 - Production release expected 01-01-2002.
02-01-2002 - General Availability 03-01-2002.
03-01-2002 - HNAS V2R1M0 officially released.
03-19-2002 - APAR 2100001
APAR: 2100001
STATUS: CLOSED
OPEN_DATE: 03-19-2002
CLOSE_DATE: 03-19-2002
SERVICE(S): HNAS Configuration Processing
MANDATORY: YES
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): MCHINI
OBJECT(S): N/A
SOURCE(S): MCHINI
PROBLEM: 0C4 ABEND can occur in MCHINI when a non-GATE MCH is being
scanned during the control block allocation process.
DESCRIPTION: MCHINI is processing the LUNAME operand for a non-GATE MCH
because it thinks the non-GATE MCH is actually GATEFC. The
test for the CONNECT operand checks for CONNECT=NO rather
than CONNECT=YES|SUBD|CUD0. The flags that remember the
CONNECT specification, including CONNECT=NO, are only set
for a GATE MCH.
SOLUTION: The test for the CONNECT operand was changed to check
specifically for YES|SUBD|CUD0 rather than NO.
Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
04-04-2002 - APAR 2100002
APAR: 2100002
STATUS: CLOSED
OPEN_DATE: 04-04-2002
CLOSE_DATE: 04-04-2002
SERVICE(S): LLC0 & LLC5 Call-in Processing
MANDATORY: NO
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): XOTBXM
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: Transpac call request to HNAS cleared with CAUSE=19 and
DIAG=74 cleared because HNAS call accept packet contains
the called and calling DTE addresses from the call request
packet.
DESCRIPTION: V2R1M0 includes new logic to conform to the X25 standard
practice of including DTE addresses in the call accept
packet. Transpac does not support this.
SOLUTION: HNAS modified to not install DTE addresses in the call
accept packet. This will be an option in future releases.
Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: The following ZAP corrects the problem:
NAME NASMAIN XOTBXM
VER 03CA 4700
REP 03CA 47F0
04-25-2002 - APAR 2100003 - DEFUNCT
04-17-2002 - APAR 2100004
APAR: 2100004
STATUS: CLOSED
OPEN_DATE: 4-17-2002
CLOSE_DATE: 4-17-2002
SERVICE(S): ALL XOT
MANDATORY: YES
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): VCDD
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: 0C4 ABEND in HNAS MCH timer routine.
DESCRIPTION: V2R1M0 includes logic to wait for the Clear Confirm
response to a Clear sent by HNAS. A timer is started to
ensure the Clear Confirm is received. The timer index
stored is invalid and causes the 0C4 ABEND if the timeout
expires (Clear Confirm not received).
SOLUTION: HNAS modified to install the correct timer index.
Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: The following ZAP corrects the problem:
NAME NASMAIN VCCLEAR
VER 01AC 9528
REP 01AC 9518
NAME NASMAIN XOTXMTC
VER 024C 9228
REP 024C 9218
VER 03B0 9228
REP 03B0 9218
VER 049C 9228
REP 049C 9218
VER 0708 9228
REP 0708 9218
04-18-2002 - APAR 2100005
APAR: 2100005
STATUS: CLOSED
OPEN_DATE: 04-18-2002
CLOSE_DATE: 04-18-2002
SERVICE(S): ALL XOT
MANDATORY: YES
ORIGIN/REF: OVR0002E
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): VCCLEAR
SOURCE(S): N/A
PROBLEM: NASHALT AT LOC xxxxxxxx IN VCRCLRC: INV LU-2
DESCRIPTION: An unusual timing problem can lead to a bad branch when
HNAS processes an inbound Clear Confirm packet.
SOLUTION: HNAS modified to correct Clear Confirm logic.
Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: The following ZAP corrects the problem:
NAME NASMAIN VCCLEAR
VER 042A 5810
REP 042A 5811
04-18-2002 - APAR 2100006
APAR: 2100006
STATUS: CLOSED
OPEN_DATE: 04-18-2002
CLOSE_DATE: 04-18-2002
SERVICE(S): HNAS Configuration Processing
MANDATORY: YES
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): CNFGDCAD
OBJECT(S): N/A
SOURCE(S): CNFGDCAD
PROBLEM: The following error message is generated when the DCEADDR=
operand is specified in conjunction with GATE=GENERAL and
OPTIONS=REPDCEADDR on the REMOTE definition statement:
NAS1311W REMOTE DCEADDR INVALID WHEN CALLOUT NOT USED, IGNORED
DESCRIPTION: Normally the DCEADDR= operand is used for PCNE and/or PAD
callout. But because of this special GATE option, it is
also used for GATE call-in processing.
SOLUTION: The test for callout must be crippled to allow DCEADDR= for
GATE processing.
Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: The following ZAP corrects the problem:
NAME NASMAIN CNFGDCAD
VER 0300 4770,A216
REP 0300 47F0,A216
04-25-2002 - APAR 2100007
APAR: 2100007
STATUS: CLOSED
OPEN_DATE: 04-22-2002
CLOSE_DATE: 04-25-2002
SERVICE(S): ALL
MANDATORY: NO
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): XOTUT1
SOURCE(S): N/A
PROBLEM: When searching for a control block to use for a callout
operation, HNAS does not skip TYPE=XOT REMOTEs that have
been marked INACTIVE.
SOLUTION Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: Apply the following ZAP to the MCHINI module in the HNAS
object library then rebuild the HNAS load module by running
the BLDLMOD (linkedit) step from the installation job.
//ZAP JOB acctinfo
//ZAP EXEC PGM=AMASPZAP
//SYSLIB DD DSN=hnasobj,DISP=OLD
//SYSIN DD *
NAME XOTUT1 XOTUT1
VER 056E 5860,50AC
REP 056E 47F0,A6B8
VER 0AD0 0000,0000,0000,0000,0000,0000,0000,0000
REP 0AD0 5860,50AC,9101,5045,4780,A0A2,47F0,A15A
/*
If you want to ZAP the existing HNAS load module rather than
the MCHINI 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 MCHINI.
04-25-2002 - APAR 2100008
APAR: 2100008
STATUS: CLOSED
OPEN_DATE: 04-22-2002
CLOSE_DATE: 04-25-2002
SERVICE(S): ALL
MANDATORY: NO
ORIGIN/REF: 1140045, OVR0001W
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): MCHINI
SOURCE(S): N/A
PROBLEM: HNAS clears inbound LLC0 or LLC5 call with CAUSE=000,
DIAG=131 (CUD0 invalid for CTCP/LLC selection).
DESCRIPTION: When a TYPE=MCH or TYPE=XTP remote has GATE=GENERAL and
CUD0= omitted or CUD0=ALL then HNAS generates CUD0 to
LLC/CTCP selection tables as described in "NPSI Planning
and Installation". The tables do not have values for
LLC0 or LLC5 selection (correct values for LLC4 & CTCP
selection are present). Since the 'ALL' table is used
to supply values not coded in a user CUD0= table, user
tables may also get invalid clears.
SOLUTION Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: Apply the following ZAP to the MCHINI module in the HNAS
object library then rebuild the HNAS load module by running
the BLDLMOD (linkedit) step from the installation job.
//ZAP JOB acctinfo
//ZAP EXEC PGM=AMASPZAP
//SYSLIB DD DSN=hnasobj,DISP=OLD
//SYSIN DD *
NAME MCHINI MCHINI
VER 069E 92FF,6220,D2FF,6221,6220
REP 069E 5810,AEB4,D2FF,6220,1000
VER 1049 FF
REP 1049 55
VER 1089 FF
REP 1089 55
VER 1099 FF
REP 1099 55
VER 10C9 FF
REP 10C9 55
VER 1108 FF
REP 1108 50
VER 1114 FF
REP 1114 50
VER 114D FF
REP 114D 55
VER 118D FF
REP 118D 55
VER 119D FF
REP 119D 55
VER 11CD FF
REP 11CD 55
VER 120C FF
REP 120C 50
VER 1218 FF
REP 1218 50
/*
If you want to ZAP the existing HNAS load module rather than
the MCHINI 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 MCHINI.
04-23-2002 - APAR 2100009
APAR: 2100009
STATUS: CLOSED
OPEN_DATE: 04-23-2002
CLOSE_DATE: 04-23-2002
SERVICE(S): HNAS Configuration Processing
MANDATORY: YES
ORIGIN/REF: OVR0003S
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): CNFGBFLM
OBJECT(S): N/A
SOURCE(S): CNFGBFLM
PROBLEM: The configuration process says that a BFRLMT value up 65535
is allowed but any value greater than 9999 generates a
configuration error message.
DESCRIPTION: The module that decodes the BFRLMT operand (CNFGBFLM) is
erroneously restricting the BFRLMT value to 4 decimal digits.
This makes it impossible to specify a value greater than 9999.
SOLUTION: The number of digits allowed must be changed from 4 to 5.
Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: Apply the following ZAP to the CNFGBFLM module in the HNAS
object library then rebuild the HNAS load module by running
the BLDLMOD (linkedit) step from the installation job.
//ZAP JOB acctinfo
//ZAP EXEC PGM=AMASPZAP
//SYSLIB DD DSN=hnasobj,DISP=OLD
//SYSIN DD *
NAME CNFGBFLM CNFGBFLM
VER 0072 4100,0004
REP 0072 4100,0005
/*
If you want to ZAP the existing HNAS load module rather than
the CNFGBFLM 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 CNFGBFLM.
04-25-2002 - APAR 2100010
APAR: 2100010
STATUS: CLOSED
OPEN_DATE: 04-25-2002
CLOSE_DATE: 04-25-2002
SERVICE(S): HNAS Configuration Processing
MANDATORY: YES
ORIGIN/REF: CLY, OVR0004S
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): CNFGIPAD
OBJECT(S): N/A
SOURCE(S): CNFGIPAD
PROBLEM: The following error message can be generated when a TYPE=MCH
REMOTE definition statement is specified:
NAS1321E REMOTE LIMIT REACHED, INVALID CONFIGURATION
DESCRIPTION: This message is generated when the count of TCPIP sockets
as computed during configuration processing exceeds 2000.
This limit is for TYPE=XOT|XTP REMOTE definitions only
and should not include TYPE=MCH REMOTE definitions.
SOLUTION: The test for the 2000 socket limit must exclude the TYPE=MCH
REMOTE definitions.
Corrective logic included in distribution mediums created
after CLOSE_DATE. Otherwise, apply maintenance as directed
in the APPLY_INFO (PTF).
APPLY_INFO: Apply the following ZAP to the CNFGIPAD 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 CNFGIPAD CNFGIPAD
VER 0842 47B0,A384
REP 0842 4700,A384
/*
If you want to ZAP the existing HNAS load module rather than
the CNFGIPAD 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 CNFGIPAD.
05-24-2002 - APAR 2100011
APAR: 2100011
STATUS: CLOSED
OPEN_DATE: 02-01-2002
CLOSE_DATE: 05-24-2002
SERVICE(S): HNAS TCP/IP Interface
MANDATORY: Required for z/OS (observed under z/OS V1R2)
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): NASTCP
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: HNAS TCPIP interface logic does not function properly
in a z/OS V1R2 environment. HNAS is unable to establish
server and client connections.
DESCRIPTION: Changes to the TCPIP Application Program Interface (API)
for z/OS V1R2 cause HNAS stack requests to mal-function.
Requests that used to work under z/OS V1R1 and OS/390 V2Rx
now fail under z/OS V1R2.
SOLUTION: HNAS has been modified to accommodate the new API. The
modifications are downward compatible with older versions
of the TCPIP stack for z/OS and OS/390.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: N/A.
05-07-2002 - CUSTOM MOD 210C001
MOD: 210C001
STATUS: CLOSED
OPEN_DATE: 02-14-2002
CLOSE_DATE: 05-07-2002
SERVICE(S): HNAS configuration and run time processing enhancement.
MANDATORY: NO
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): LUD, VTMUT1.
OBJECT(S): CNFGSVC0, CNFGSVC5, CNFGSYSL, CONSDRMT, CONSMRMT,
MCHSVCI, NASUTIL, VCCLRQ, VTMUT1.
SOURCE(S): N/A
DESCRIPTION: Custom modifications for HNAS V2R1M0.
1) Allow an SLU to be selected by CUD data rather
than calling DTE address when a Call Request
packet is received.
2) Allow an SLU connection to a PLU to be 'wired'
together without operator/user input.
SOLUTION: These custom modifications to HNAS V2R1M0 will be
standard in the next release. The following text
summarizes how the modifications work.
1) SLU selection based on 'hex DTE address':
allows a user to select an SLU for a PCNE or
PAD session by CUD 'IDBLK/IDNUM' match rather
than calling DTE address match. A hex IDBLK/
IDNUM value is specified in place of a decimal
DTE address value for an SVC0|5 operand entry
using the following notation:
SVC0=(...,SLUNM/Xdd..ddI/MXTNM,...)
where X, as the first DTE address character,
indicates that the DTE address is given in hex
rather than decimal format. You may enter up to
14 hex digits. You should always code an even
number of digits using zero (0) as the rightmost
pad digit.
When a hex IDBLK/IDNUM value is coded for an SLU
entry, the value is compared against Call User
Data (starting at byte 1) in an incoming Call
Request packet.
For NPSI emulation of CUD IDNUM data which is
5-digits, you would actually code 6-digits, the
last digit being zero. For example, if the CUD
for a PCNE Call Request packet is C0100020, the
IDNUM portion is 10002. In the SVC0 entry, you
would specify the 'DTE address' value as X100020
since the compare is done on CUD bytes 1-3.
SLU allocation is performed left to right in the
SVC0|5 operand list when a Call Request packet is
received as follows:
1) If the SVC0|5 operand entry contains a hex
IDBLK/IDNUM value, it is compared against the
IDBLK/IDNUM value from CUD (byte 1-n, where
n = number of bytes you code). If a match
occurs, the SLU is allocated to the VC. f no
match occurs, the next SVC0|5 operand entry is
examined.
2) If the SVC0|5 operand entry contains a decimal
DTE address value, it is compared against the
calling DTE address in the packet. If a match
occurs, the SLU is allocated to the VC. If no
match occurs, the next SVC0|5 operand entry is
examined.
3) If the SVC0|5 operand entry does not contain
an IDBLK/IDNUM or DTE address value and the
SLU is free and is available for inbound
connections, it is allocated to the VC. For
this reason, you should always specify SLU
entries with IDBLK/IDNUM or DTE address
values before any 'catchall' entries in the
SVC0|5 operand list.
4) If all SVC0|5 operand entries are examined and
no SLU can be allocated, the call is cleared.
NOTE: Because HNAS will allocate an SLU with no
associated IDBLK/IDNUM or DTE address
value, these entries should be specified
after any IDBLK/IDNUM and DTE address
entries or should not be coded at all.
They will then serve as 'catchall' SLUs.
If you want HNAS to perform IDBLK/IDNUM
matching before any DTE address matching,
you should place all IDBLK/IDNUM entries
ahead of any DTE address entries or
simply omit the DTE address entries. The
converse is also true.
2) SLU to PLU wiring:
allows a user to dedicate an SLU to a specific
host application for a PCNE or PAD session by
specifying a system select character after the
DTE address for an SVC0|5 operand entry using
the following notation:
SVC0=(...,SLUNM/dd...ddIc/MXTNM,...)
The system select character 'c' (which follows
the I at the end of the DTE address) must match
a SYSL operand entry that is specified using
the following notation:
SYSL=(...,DATA=c/aid,...)
where 'c' is the system select character and
'aid' is an index into the APPLNAME operand
list.
05-08-2002 - APAR 2100012
APAR: 2100012
STATUS: CLOSED
OPEN_DATE: 05-07-2002
CLOSE_DATE: 05-08-2002
SERVICE(S): XOT Call-out (callout)
MANDATORY: NO
ORIGIN/REF: NBG, 1140046
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): XOTUT1
SOURCE(S): N/A
PROBLEM: 0C4 ABEND IN XOTPCEAL routine (XOTUT1 CSECT).
DESCRIPTION: When an XOT callout operation is initiate and RTEOUT=
is not coded on the TYPE=XOT LOCAL statement the 0C4
results.
SOLUTION: HNAS modified to detect the missing RTEOUT= operand.
Message NAS7710W (CAN'T CALL CALLED ADDRESS=) will
be issued.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: Apply the following ZAP to the named module(s) in
the HNAS object library (hnasobj) then rebuild the
HNAS load module (hnasload).
//ZAP JOB acctinfo
//ZAP EXEC PGM=AMASPZAP
//SYSLIB DD DSN=hnasobj,DISP=OLD
//SYSIN DD *
NAME XOTUT1 XOTUT1
VER 0470 4130,3002
REP 0470 47F0,A6C8
VER 0AE0 0000,0000,0000,0000,0000,0000
REP 0AE0 4130,3002,4780,A0AA,47F0,A05C
/*
If you prefer to ZAP the existing HNAS load module
rather than the named module(s) in the HNAS object
library, change the SYSLIB DD statement above to
point at the HNAS load library and change the NAME
control statement to reflect the module(s) that the
ZAP refers to. i.e. NAME NASMAIN module_name.
05-10-2002 - CUSTOM MOD 210C002
MOD: 210C002
STATUS: CLOSED
OPEN_DATE: 02-14-2002
CLOSE_DATE: 05-10-2002
SERVICE(S): HNAS configuration and run time processing enhancement.
MANDATORY: NO
ORIGIN/REF: GIE
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): MCHD, XFNASWA.
OBJECT(S): CNFGOPTS, MCHINI, MCHTMR.
SOURCE(S): N/A
REQUIREMENT: Reduce or eliminate VC clears with DIAG=X'85'
('GATE: selected CTCP not active').
During MCH timer service, GATE control session SLUs are
interrogated so that those that are idle can be made
active. Normally, GATE SLUs are checked once per minute.
In some instances, this may not be often enough to ensure
that their activation occurs before a Call Request is
received and thus prevent a clear with DIAG=X'85'.
If the GATE SLUs could be monitored more often, the time
during which they are idle could be reduced and this, in
turn, would reduce or eliminate the number of clears
with DIAG=X'85'.
SOLUTION: To force HNAS to interrogate the GATE SLUs at sub-minute
intervals, specify the following option on the MCH REMOTE
definition statement:
OPTIONS=(...,MCHTMR=n,...)
where 'n' is a seconds value in the range of 4 to 60.
For example: OPTIONS=MCHTMR=16 will cause HNAS to check
the GATE SLUs every 16 seconds.
If this option is omitted, the GATE SLUs will be monitored
once per minute.
Note that the monitor interval is not exactly the 'n'
value you code, but is actually a value that is a
multiple of 2 which is 'close' to the 'n' value. This
was done to reduce processing. The following table
shows the mapping of the 'n' value to the actual
monitor interval:
--------------------------
| n | interval |
--------------------------
| 04-07 | 08 |
--------------------------
| 08-23 | 16 |
--------------------------
| 24-39 | 32 |
--------------------------
| 40-55 | 48 |
--------------------------
| 56-60 | 60 |
--------------------------
Note that this custom modification will be standard
support in all future releases of HNAS.
05-17-2002 - APAR 2100013
APAR: 2100013
STATUS: CLOSED
OPEN_DATE: 05-10-2002
CLOSE_DATE: 05-17-2002
SERVICE(S): ALL
MANDATORY: NO
ORIGIN/REF: SRP
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): MCHLUIN
SOURCE(S): N/A
PROBLEM: Inbound GATE file transfer fails (PLU aborts transfer).
DESCRIPTION: An internal table used by HNAS to send data in a chain
of packets to the PLU may not be large enough. When
GATE is in use if the table is not large enough the
result is that data the PLU expects to see in a single
only-in-chain RU is sent in 2 only-in-chain RUs. This
causes the file transfer to abort.
SOLUTION: HNAS modified to detect this very unusual table
overflow condition. If an overflow occurs, HNAS will
generate the following alert message:
NAS3720S LU lu-name INBOUND X25 MESSAGE COULD NOT
BE DELIVERED BY THE LU BUFFER LIST.
The message indicates that our standard buffer list
tables will need to be expanded. Please contact your
HNAS support representative for an enhancement to
expand the tables, if required.
Diagnostic logic included in distributions created
after CLOSE_DATE.
The HNAS V2R2Mn product includes standard support to
generate the NAS3720S alert message and includes a
configuration parameter in the CDF to expand the
buffer list tables.
APPLY_INFO: Refresh HNAS distribution to apply diagnostic logic.
No zap is currently available.
05-14-2002 - APAR 2100014
APAR: 2100014
STATUS: CLOSED
OPEN_DATE: 05-14-2002
CLOSE_DATE: 05-14-2002
SERVICE(S): HNAS Run Time SYSL Processing
MANDATORY: YES
ORIGIN/REF: GIE
PTF_TYPE: N/A
PREREQ(S): 210C001 (custom enhancement)
MACRO(S): N/A
OBJECT(S): Documentation Only
SOURCE(S): N/A
PROBLEM: The following error message can be generated when a
PCNE or PAD call is received and the SYSL list contains
DATA= entries but no SUBD= or CUDx= entries that will
yield a match.
NAS7715W aaa.bbb.ccc.ddd(ppppp) CALL REQ TO MCH mchname
CLEAR DIAG=200 (C8)
DESCRIPTION: This message is generated when no match occurs in the
SYSL list for non-DATA= suboperands. Because of the
way HNAS parses the SYSL list, SUBD= or CUDx= values
that yield a match must be specified even when they
will be overridden by the DATA= values.
SOLUTION: Always code a 'default' SUBD= or CUDx= value that will
yield a match in the Call Request packet even though
the selected application will be overridden by a DATA=
value. For example:
SYSL=(DATA=A/0,DATA=B/1,DATA=C/2,CUD0=C0/0)
APPLY_INFO: N/A
05-16-2002 - APAR 2100015
APAR: 2100015
STATUS: CLOSED
OPEN_DATE: 05-16-2002
CLOSE_DATE: 05-16-2002
SERVICE(S): HNAS Configuration/Run Time Processing - TAP
MANDATORY: NO, RECOMMENDED
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): CNFGTAP
PROBLEM: Router contact lost due to TAP (Keep Alive) failure.
DESCRIPTION: Router interface and socket connection can be brought
down when shoulder tapping Keep Alive failure occurs.
NAS2321W KEEP ALIVE FAILED FOR SOCK=ddd.ddd.ddd...
NAS2322E CONTACT LOST FOR SOCK=ddd.ddd.ddd.ddd(...
We have observed that some Cisco router environments
don't respond to our XOT Clear request with an XOT
Clear Confirm response which prevents our Keep Alive
simulation logic from operating properly. For this
reason we are changing our default tapping value to
TAP=0 which disables the option.
Those who prefer tapping can continue to use the
option by coding their preferred TAP=nnn value on
the respective REMOTE, TYPE=XOT resources.
For new or existing users that would like to enable
this option, we suggest the you test the operation
before implementing into you production environment.
Enable the tapping logic on the designated REMOTE
using a value such as TAP=120. Activate Cisco
event reporting debug x25 event and monitor the
log for XOT tapping activity. You should see an
XOT Clear entry from your HNAS local IP address
every 'tapping' interval (120 seconds in this case)
and a response from the router shortly thereafter.
-Request from HNAS-
[10.117.56.221,2631/10.117.56.100,1998]:,
XOT I P/Inactive Clear (5) 8 lci 1,
Cause 0, Diag 255 (DTE originated/,
Unknown diagnostic)
-Response from Cisco Router-
[10.117.56.221,2631/10.117.56.100,1998]:,
XOT O P7 Clear Confirm (3) 8 lci 1
If you observe that responses are flowing properly
and you are not encountering the NAS2322E or NAS2323I
messages then you should be able to run with this
support in your production environment.
There is really no requirement to run with tapping
enabled if your environment has another form of
network monitoring employed to monitor router
connectivity with the host.
SOLUTION: Default TAP=10 value changed to TAP=0 (none) so that
environments default to no tapping. The new default
will accommodate router environments that do not
properly support our tapping (Keep Alive simulation)
option and allow those that do to define their
preferred tapping value.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: Refresh HNAS distribution or follow circumvention
instructions.
CIRCUMVENTION: Code TAP=0 on REMOTE TYPE=XOT resources to disable
tapping, if necessary.
05-22-2002 - APAR 2100016
APAR: 2100016
STATUS: CLOSED
OPEN_DATE: 05-20-2002
CLOSE_DATE: 05-22-2002
SERVICE(S): HNAS Alarm Processing - Remote Console
MANDATORY: YES
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): XOTUT1, XTPUT1, NASUTIL
SOURCE(S): N/A
PROBLEM: 0198 ABEND can occur in NASTCP (R2=83, R3=04) when
remote console alarm mode is active and a large console
display is in progress.
DESCRIPTION: The ABEND occurs because the socket transmit queue for
the console connection has become corrupted. If an
alarm is generated while an active console display is
in progress, nested calls to the XOTXMT and XTPXMT
subroutines (in XOTUT1 and XTPUT1, respectively) can be
generated from XFWTO logic in NASUTIL. XOTXMT/XTPXMT
pass the buffer containing the alarm to MCHLXDRN in MCHBFR
in a parm list that is serially reusable. If the alarm is
generated while MCHLXDRN is running, XOTXMT/XTPXMT will be
called again. This second call will overlay the buffer
address from the first call in the parm list that is
passed to MCHLXDRN. When control is returned to MCHLXDRN
for the first XOTXMT/XTPXMT call, it will be using the
second buffer, not the first. This means that the same
buffer will be enqueued twice to the socket transmit
queue. This is the reason the queue becomes corrupted
and why the ABEND occurs.
SOLUTION: The parm list in XOTXMT/XTPXMT is made reentrant rather
than serially reusable so that multiple calls cannot
overlay the original buffer address.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: N/A.
05-23-2002 - APAR 2100017
APAR: 2100017
STATUS: CLOSED
OPEN_DATE: 05-23-2002
CLOSE_DATE: 05-23-2002
SERVICE(S): HNAS Alarm Processing - Remote Console
MANDATORY: YES
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): NASUTIL
SOURCE(S): N/A
PROBLEM: D23 ABEND can occur in XFWTO service routine when
remote console alarm mode has been set for multiple
remote consoles and one disconnects without first
exiting alarm mode.
DESCRIPTION: The ABEND occurs because the alarm mode processor dequeues
the disconnected console while processing the next alarm
message and this dequeue corrupts the alarm message
pointer. The bad address is then passed to the system WTO
service routine which causes the ABEND.
SOLUTION: The alarm mode processor must restore the alarm message
address after dequeuing the disconnected remote console.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: N/A.
05-26-2002 - APAR 2100018
APAR: 2100018
STATUS: CLOSED
OPEN_DATE: 05-23-2002
CLOSE_DATE: 05-26-2002
SERVICE(S): HNAS VC Cleanup Processing
MANDATORY: YES
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): MCHUT1
SOURCE(S): N/A
PROBLEM: A VC cleanup error can occur when a socket is closed by
a remote client after it receives a Clear request from
HNAS but before the Clear Confirm response is received
by HNAS.
DESCRIPTION: The socket close processor fails to recognize the DTE
clear state (P6) so it assumes that other events will
trigger the VC cleanup function. This does not occur
because the expected Clear Confirm will not be received.
SOLUTION: The socket close processor must check for DTE clear
state and if set, force the VC cleanup function itself.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: N/A.
05-29-2002 - APAR 2100019
APAR: 2100019
STATUS: CLOSED
OPEN_DATE: 05-28-2002
CLOSE_DATE: 05-29-2002
SERVICE(S): HNAS Console Subsystem - Remote Console
MANDATORY: YES
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): MCHBFR
SOURCE(S): N/A
PROBLEM: Some remote console display commands can cause a
Clear request (Diag=130 '82') to be sent by HNAS
when too many lines of output are generated.
DESCRIPTION: Console command output is staged in a queuing area
waiting for delivery to the end DTE based on the
state of the packet level window. When the queue
depth exceeds the window size, a Clear is generated.
This occurs, erroneously, because the routine that
is supposed to send data when the window is open is
not dequeuing the staged output. The result is that
the queue continues to grow with no possibility of
being gracefully drained. Note that this problem
seems to manifest itself only when the packet level
window is set to 7 (the maximum).
SOLUTION: The buffer transmit processor must check for console
output, and if present, send it until the packet
level window closes.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
APPLY_INFO: N/A.
05-31-2002 - APAR 2100020
APAR: 2100020
STATUS: CLOSED
OPEN_DATE: 05-01-2002
CLOSE_DATE: 05-31-2002
SERVICE(S): HNAS Alert Processing - Alert Message Reassignment
MANDATORY: NO
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): NASTCP
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: Duplicate alert message identifiers can cause
confusion when analyzing event alert message
activity.
DESCRIPTION: The following alert messages were reassigned to
eliminate duplicate assignment and improve group
category classification:
From To Message ID
-------- -------- --------------
NAS2321W->NAS2501W (KEEPALIVE FAILED) (was dup)
NAS2322E->NAS2502E (CONTACT LOST)
NAS2323I->NAS2503I (CONTACT REAQUIRED)
NAS2321W->NAS2401W (RECEIVE FAILED) (was dup)
NAS2331W->NAS2411W (SEND FAILED)
NAS2311W->NAS2331W (IOCTL FAILED)
NAS2281W->NAS2291W (SETSOCKOPT FAILED)
NAS2261W->NAS2281W (GETSOCKNAME FAILED)
NAS2260I->NAS2280I (GETSOCKNAME COMPLETE) (was dup)
SOLUTION: Run with revised Alert message ID assignment to
avoid potential confusion.
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.
No zap is currently available.
06-11-2002 - APAR 2100021
APAR: 2100021*
STATUS: CLOSED_DEFERRED_V2R2M0_CIRCUMVENTION
OPEN_DATE: 06-10-2002
CLOSE_DATE: 06-11-2002
SERVICE(S): HNAS Configuration Processing
MANDATORY: NO
ORIGIN/REF: NBG
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: HNAS gets an 0C1 ABEND at the end of CDF processing.
DESCRIPTION: When the END statement is omitted from the CDF, HNAS
fails to detect the EOD condition and attempts to
continue reading. Since the CDF has been completely
processed, there is nothing more to read.
SOLUTION: Always supply an END statement as the last statement
in the CDF.
APPLY_INFO: This problem is fixed in the HNAS V2R2M0 distribution.
* - Denotes APAR only, no PTF issued.
CIRCUMVENTION: Always supply an END statement in the HNAS CDF.
06-13-2002 - APAR 2100022
APAR: 2100022*
STATUS: CLOSED_DEFERRED_V2R2M0_CIRCUMVENTION
OPEN_DATE: 2002
CLOSE_DATE: 06-13-2002
SERVICE(S): HNAS Activation/Run Time Processing - SHOWERR
MANDATORY: NO
ORIGIN/REF: N/A
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: Excessive Information messages are written to the
operator console even though HNAS PARM=SHOWERR is
enabled.
DESCRIPTION: Excessive Information messages are written to the
operator console during HNAS activation (CDF scan,
initialization, start-up) and runtime. PARM=SHOWERR
isn't eliminating CDF (D)efault and (I)nformation
messages or runtime (I)nformation messages as
documented.
HNAS can generate many event messages at activation
or during normal processing. We suggest that you
filter out unwanted messages using the CDF BUILD
parameter ALRMFLTR= to exclude undesired messages.
SOLUTION: Define alarm filters (ALRMFLTR=) in the HNAS BUILD
to eliminate unwanted messages. See circumvention.
APPLY_INFO: This problem is fixed in the HNAS V2R2M0 distribution.
* - Denotes APAR only, no PTF issued.
CIRCUMVENTION: Code the following alarm filters to eliminate the
unwanted information messages.
For HNAS activation CDF scan/decode filtering
of (I)nformation and (D)efault messages, we
suggest that you apply the following filters
to the ALRMFLTR= parameter:
NAS1***I(S),NAS1***D(S)
We suggest that you employ the PARM=FASTRUN
option to validate the CDF prior to attempting
to activate HNAS. This pre-process step can
also help eliminate un-necessary messages
from being displayed at the operator console.
For start-up and runtime (I)nformation messages,
we suggest that you filter out the following
messages once initial testing is completed:
NAS2200I(S),NAS2210I(S),NAS2260I(S),NAS2270I(S)
You can add other alert message filter ID's
to the list further restricting messages
output.
06-19-2002 - APAR 2100023
APAR: 2100023
STATUS: CLOSED
OPEN_DATE: 06-19-2002
CLOSE_DATE: 06-19-2002
SERVICE(S): LLC0/LLC5 callout
MANDATORY: YES, if callout used.
ORIGIN/REF: FAU
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): None
SOURCE(S): N/A
PROBLEM: NASHALT IN VTMRSPC with the message "BUFFER REQ'D".
DESCRIPTION: The HNAS LU control block used for LLC0 or LLC5 callout
is not properly refreshed when the PLU sends an UNBIND
to HNAS. The NASHALT is a result of the flags that were
not reset at the time of the UNBIND.
SOLUTION: This problem is fixed in distributions created after the
CLOSE date.
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
No zap is currently available.
06-22-2002 - APAR 2100024
APAR: 2100024
STATUS: CLOSED
OPEN_DATE: 06-10-2002
CLOSE_DATE: 06-22-2002
SERVICE(S): ALL
MANDATORY: NO
ORIGIN/REF: SRP,GET
PTF_TYPE: N/A
PREREQ(S): 2100013
MACRO(S): LUD
OBJECT(S): MCHFCI, MCHINI, MCHLUIN, MCHPVCI, MCHSVCI
SOURCE(S): N/A
PROBLEM: Inbound GATE file transfer fails (PLU aborts transfer).
Under CFT a "Invalid FPDU" message may be displayed.
If APAR 2100013 is on then alert message NAS3720S is
issued.
DESCRIPTION: The file transfer failure can occur when our internal
table used to deliver packet data is not large enough
to process all the packets in an m-bit chain. This
unusual condition can occur when extremely large file
message sequence (large m-bit packet sequence) or
excessive TCP/IP fragmentation occurs which causes
HNAS to populate table entries with fragmented
packets requiring more entries than available.
PREREQ APAR 2100013 was issued to generate an alert
message (NAS3720S) when this condition occurs. APAR
2100024 increases the size of the internal table in
an effort to accommodate the large message sequences
preventing demand for more entries than available.
Should you continue to encounter this condition after
installing the HNAS refresh (up through APAR 2100024)
then please contact your support representative for
an expansion of the NAS3720S internal table.
SOLUTION: HNAS modified to use a larger table. For those familiar
with VTAM, the internal table is a VTAM buffer list.
With this APAR applied, the list (which is part of the
HNAS LU) has 40 16 byte slots.
This problem is fixed in distributions created after the
CLOSE date.
APPLY_INFO: Refresh HNAS distribution to apply corrective logic.
No zap is currently available.
07-02-2002 - APAR 2100025*
APAR: 2100025
STATUS: CLOSED_UPGRADE_TO_V2R1M1
OPEN_DATE: 05-14-2002
CLOSE_DATE: 07-02-2002
SERVICE(S): GATE callout.
MANDATORY: NO
ORIGIN/REF: FMP
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: GATE session initiated with control session call request
packet fails to start properly. Eventually the session
is ended with a clear from the remote or from the local
CTCP.
The file transfer program is CFT.
DESCRIPTION: This is a timing problem between HNAS and the CFT CTCP.
A callout session is initiated when the CTCP sends a
call request packet to HNAS on the control session LU.
HNAS sends an X25 call request packet to the remote
device. When the remote returns a call accept HNAS
sends it to the CTCP, again using the control session
LU. When the send completes, a REQSESS is sent to the
PLU to request a BIND to activate the data session LU
for the call. The REQSESS is an expedited PIU which
the CTCP may see before it sees the (non-expedited)
call accept. This can lead to a situation where the
data session is bound but no SEND is done by the PLU
to transfer the first message of the session. The net
result is that the session 'hangs' until a timeout
occurs.
SOLUTION: This problem is fixed in the V2R1M1 release HNAS.
APPLY_INFO: Upgrade HNAS distribution to maintenance release V2R1M1
No zap is currently available.
* - Denotes APAR only, no PTF issued.
07-09-2002 - APAR 2100026*
APAR: 2100026
STATUS: CLOSED_UPGRADE_TO_V2R1M1
OPEN_DATE: 07-03-2002
CLOSE_DATE: 07-09-2002
SERVICE(S): GATE Fast Connect
MANDATORY: Required for Fast Connect Users
ORIGIN/REF: FPO
PTF_TYPE: N/A
PREREQ(S): N/A
MACRO(S): N/A
OBJECT(S): N/A
SOURCE(S): N/A
PROBLEM: GATE Fast Connect data session LUs not available for
use after CTCP is cancelled and restarted.
DESCRIPTION: When the FC GATE CTCP is terminated the HNAS control
session LU and related data session LUs are terminated.
An error in termination logic keeps the ACBs for the
Fast Connect data session LUs from being re-opened.
This makes the data session LUs inoperable.
SOLUTION: This problem is fixed in the V2R1M1 HNAS release.
APPLY_INFO: Upgrade HNAS distribution to V2R1M1 or higher.
07-10-2002 - APAR 2109999*
APAR: 2109999
STATUS: SERVICE_NOTICE-<END_OF_MAINTENANCE/APAR_CYCLE>
OPEN_DATE: ----------
CLOSE_DATE: 07-10-2002
SERVICE(S): ALL_V2R1M0
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: V2R1M0 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 V2R1M0 APAR logs we suggest that you review the
V2R1M1 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 V2R1M1 maintenance log and upgrade
to V2R1M1 or higher, as required.
APPLY_INFO: Upgrade HNAS distribution to V2R1M1 or higher.
APAR Assignment Cross Reference Matrix Summary
Last Update - July 10, 2002