The individual APAR hyperlink *.ZIP files provide all of the necessary SRC (source) and OBJ (object) updates for the respective PTF. Most APARs have PREREQ(S) as designated in the APAR memos (multiple APAR PTF's may be required to install a particular APAR PTF). If a product refresh or upgrade is required you will need to contact your HNAS support representative to order the appropriate edistribution. HNAS product edistributions are provided via our ftp server and build as requested (e-mail attachment can also be provided upon special request). We suggest that you contact your HNAS support representative to request that an FTP userid account be set-up for your organization if you haven't already done so.
| APAR# | CLOSE_DATE | SERVICE |
PTF_TYPE |
PROBLEM |
|---|---|---|---|---|
|
230nnnn 230nnnn_D 230nnnn_E 230nnnn_M 230nnnn_P 230nnnn_R 230nnnn_U |
yyyy-mm-dd |
(blank) Deferred Enhancement Circumvention Pending Refresh Upgrade |
-> -> -> -> -> -> -> |
Denotes a Standard APAR. Fix or Enhancement deferred to a later (future) release. A new function has been added by this APAR. Circumvention is available, see APAR memo. APAR type pending assignment. Refresh up to/above this APAR number has to be installed. Upgrade to denoted HNAS VnRnMn has to be installed. |
| - | - | - | - | - |
| 2300nnn thru 2300204 | <Link forward> | - | - |
HNAS V2R3M0 - 2007 MAINTENANCE SUMMARY (Link to APARs 2300204 thru 2300nnn) |
| - | - | - | - | - |
|
Note |
2006-12-06 |
- |
- |
Enhancement APARs and non-critical APAR fixes (when a circumvention is available) are no longer issued for 230. Refer to 240 for New Features and general fixes. |
| - | - | - | - | - |
| 2006-10-19 |
GATE FC |
OBJ |
USER 198 ABEND with the message: HALT AT LOC xxxx IN VTMRSPC: BFR REQ'D encountered due to a validity check in the VTAM receive processor. |
|
| 2006-09-28 |
PVC VTAM/Resets |
OBJ |
1) IMS to IMS PVC connection receives NAS5705W reset CAUSE/DIAG=000/219. |
|
| 2006-09-08 |
GATE |
OBJ |
1) REQSESS operations for GATE control and Fast
Connect (FC) data sessions are not retried when the PLU is not active. |
|
| 2006-09-07 |
TCPIP |
SRC |
NAS2211W CLOSE REQUEST FAILED error message erroneously generated due to bad socket number being passed to the socket CLOSE processor condition can lead to depletion of sockets. |
|
|
Note |
2006-08-01 |
- |
- |
Now that the HNAS 240 product is Generally Available (as of July 31, 2006) Enhancement APARs will now be issued against 240. Users interested in these enhancements should upgrade to 240. |
| 2006-06-28 |
TCPIP |
SRC |
NASHALT U198 ABEND due to TCPIP interrupt sequence number validity check failure. HALT AT LOC 80047F7E IN NASTCP: TCPIP REPLY ID FAILURE. |
|
| 2006-06-28 |
GATE |
OBJ |
Gate session clears with DIAG=219 (DB) after PLU rejects HNAS FMD with SENSE=100307D1. |
|
| 2006-05-30 |
GATE |
SRC |
GATE control session cannot be started by PLU because |
|
| 2006-05-18 |
PVC 1-3 |
OBJ |
1) HNAS PVC LU resource not active/available (ACB closed, no session with PLU) condition may occur because the expected RESET CAUSE/DIAGNOSTIC 000/000 is not sent by the router after a physical X.25 link restart. |
|
| 2006-05-10 |
Tracing |
OBJ |
When PARM=MCHTRC is specified (or taken as a default) not all MCH trace bits are set resulting in some internal trace records not being created. |
|
| 2006-05-02 |
GATE |
OBJ |
USER 198 ABEND with the message: HALT AT LOC xxxxxx IN VTMRSPC : BFR REQ'D. |
|
| 2006-05-02 |
Cons-Subsystem |
OBJ/SRC |
1) Misleading error message is issued when the VARY or MON
command is entered without RNM= or ID= being set. |
|
|
2300192_R |
2006-04-29 |
Cons-Subsystem |
<Refresh |
DNAS set as default queued command only when CONCMDQ= |
| 2006-04-27 |
CNFG, PVCs |
OBJ |
HALT AT LOC xxxxxxxx IN MCHGETMN: MCH STORAGE BLOCK |
|
| 2006-04-27 |
TCPIP |
OBJ/SRC |
HNAS-TO-HNAS bug fixes/improvements:
|
|
| 2006-04-11 |
VTAM, USSMSG |
OBJ |
HNAS erroneously sends USSMSG when SUPP=ALWAYS specified. |
|
| 2006-04-05 |
Cons-Subsystem |
OBJ/SRC |
When omitted ID= modifier is in effect, TRCxxx ON|OFF is treated the same as ALLON|ALLOFF, respectively when error message should be generated. |
|
| 2006-04-01 |
LLC-0 and LLC-5 |
OBJ |
Customer trace shows that the interval between a callout failure (no call accept or call cleared) and the UNBIND sent to the PLU can be as long as 28 seconds. |
|
| 2006-03-22 |
QLLC PVC & SVC |
OBJ/SRC |
1) NASHALT 0198 ABEND occurs when ACTPU received for QLLC PVC:
HALT AT LOC 8005EACC IN MCHNQ : INV QCB |
|
| 2006-03-22 |
GATE |
OBJ |
NAS4707W LU lu-nm GENERATING ERR/INFO PACKET FOR CTCP plu-nm GATE CMD RCV'D 17 HNAS ERROR CODE 1, 2 or 3 generated while this event doesn't require a warning (like NPSI). |
|
| 2006-03-02 |
2-way LUs (T) |
SRC |
HALT AT LOC xxxx IN VTMSREQS: INV LU due to very unusual timing condition. HALT occurs when HNAS is trying to issue a REQSESS macro to ask the PLU for a BIND to start a session for an inbound call. A validity test ensures that the send RPL is available for the operation. This HALT indicates that the RPL was already busy. |
|
| 2006-02-09 |
Cons-Subsystem |
SRC |
NAS25nnM monitor message filtering occurred when special filter ALRMFLTR=(NAS25**I(P)) was enabled preventing the messages from being displayed. |
|
| 2006-02-09 |
Cons-Subsystem |
OBJ |
NAS0910I '3 BELLS AND ALL IS WELL' message is not being routed to SYSCONS and NETVIEW due to Informational level routing code. |
|
| 2006-02-02 |
USSTAB |
OBJ |
SIM3278 session connect fails to complete after USSMSG 3 (EXTRANEOUS PARAMETER) message issued when keyword parameter from remote not in any USSPARM entry following the selected USSCMD entry. |
|
| 2006-01-29 |
VTAM |
OBJ/SRC |
LU appears hung, following displayed in SYSPRINT: REMOTE rmt-nm lu-nm LU
lu-addr LUIQ TIMEOUT, LUIQ BFR CT=xxxx |
|
| 2006-01-24 |
TCPIP and |
OBJ/SRC |
1) NASHALT IN NASTCP - INVALID TCPIP INTERRUPT occurs after
NAS2201W SOCKET REQUEST FAILED, RC=FFFFFFFF 0000040C |
|
| 2006-01-23 |
GATE FC |
OBJ |
VIRTEL GATE FC control session comes down when 135/001 (Cause/Diagnostic) X25 RESET packet received. |
|
| 2006-01-23 |
VTAM (BID) |
SRC |
Customer is receiving NAS3705W alert messages with SENSE=0814. |
|
|
2300176_E |
2006-01-19 |
LLC-n RTEIN= |
OBJ/SRC |
1) RTEIN= processing now supports calling (=>S) source address in
addition to the existing called DTE target address (=>T) in a manner
similar to the RTEOUT= operand. |
| 2006-01-12 |
Cons-Subsystem Alternate SYSPRINT DCB |
OBJ |
HNAS log records are being truncated when alternate (not SYSOUT=*) dataset is used for SYSPRINT output. |
|
|
Note |
2006-01-11 |
- |
- |
Date formats changed from mm-dd-yyyy to yyyy-mm-dd in this document. |
| 2006-01-02 |
Tracing |
OBJ/SRC |
General cleanup, no runtime or trace problems. |
|
| 2300173 thru 2300095 | <Link back> | - | - |
HNAS V2R3M0 - 2005 MAINTENANCE SUMMARY (Link to APARs 2300095 thru 2300173) |
| 2300094 thru 2300000 | <Link back> | - | - |
HNAS V2R3M0 - 2004 MAINTENANCE SUMMARY (Link to APARs 2300094 thru 2300000) |
| - | - | - | - | - |
| 230nnnn_i | yyyy-mm-dd |
GATE/LLCn/ PVC/QLLC/... |
ZAP/SRC/ OBJ/DOC/ CNFG/... |
<-Brief Problem Description-> 230nnnn_i= APAR Type - (blank) Denotes as a Standard APAR. _D - Deferred to a later release. Memo only, no PTF (fix) issued. Corrective logic or support will be provided in a future release. _E - Enhancement-APAR assignment. Denotes enhancement introduced after initial product release date. A new function has been added by this APAR. _M - Circumvention available (C reserved for custom identification). _P - Pending assignment. _R - Refresh edistribution required. To benefit from this APAR, a refresh release, up to this APAR number or most recent, has to be installed. _U - Upgrade required to the designated release. Memo only, no PTF (fix) issued. See link vrmnnnn_i table for an expanded description. |
| - | <Deferred> |
- |
<-> |
Denotes that problem resolution was deferred to a latter release although an apar memo is present describing the problem/reference. |
|
- |
- | <Enhancement> |
<-> |
Depicts an enhancement, not a problem fix. |
Please refer to the X.25 HostNAS (HNAS) Product Notices web page
section HNAS V2R3M0 - Release Status for additional information.
2006-10-22 - APAR 2300203 (was problem 2006254A)
APAR: 2300203
STATUS: CLOSED
OPEN_DATE: 2006-09-11
CLOSE_DATE: 2006-10-19
SERVICE(S): GATE FC
MANDATORY: YES
ORIGIN/REF: 230_ZAG
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300203.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2006-03-22
With APAR: 2300185 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHL4RQ
SOURCE(S): N/A
PROBLEM: USER 198 ABEND with the message:
HALT AT LOC xxxx IN VTMRSPC : BFR REQ'D
DESCRIPTION: This halt is caused by a validity check in the VTAM
receive processor. An operation has started which
requires a buffer and no buffer is present. This
is an HNAS logic error.
SOLUTION: This HALT is a result of a partial LU refresh performed
when a GATE Fast Connect (FC) PLU sends an UNBIND to an
HNAS FC data session LU. Under some circumstances the
unbound LU can have invalid residual information in it's
VTAM control blocks (RPLs, NIB, ACB). With this fix on
when HNAS receives an UNBIND for a FC GATE data session
LU the LU's ACB is closed, the LU is refreshed, the ACB
is reopened and a new session is set up (HNAS issues
REQSESS if the PLU name is known or waits for the LU to
be acquired by the PLU).
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-09-28 - APAR 2300202 (was problem 2006215A)
APAR: 2300202
STATUS: CLOSED
OPEN_DATE: 2006-08-03
CLOSE_DATE: 2006-09-28
SERVICE(S): PVC
MANDATORY: YES
ORIGIN/REF: 230_FIS
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300202.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2006-05-18
With APAR: 2300196 applied.
SUPERSEDES: N/A
OBJECT(S): VCRESET , XOTBXM
SOURCE(S): N/A
PROBLEM 1: IMS to IMS PVC connection receives reset:
NAS5705W RESET SCHEDULED ON MCH mch-nm VC vc-addr
lu-name LU lu-addr CAUSE/DIAG=000/219 (00/DB) DIAGX=0000
PROBLEM 2: When HNAS is restarted (HNAS-TO-HNAS environment) the
first outbound PLU FMD PIU is not sent by HNAS.
DESCRIPTION1: When HNAS receives a -RSP to a PIU sent to the PLU the
following actions occur:
If the sense is 10xx the NAS3711I alert is issued and
the negative response is ignored (APAR 2300198).
For other sense values:
If the session is not a PVC the VTAM session is ended.
If there is an X25 session it is cleared (DIAG=219/DB).
If the session is a PVC then a RESET DIAG=129 is sent
to inform the remote of the -RSP. The VTAM session is
ended (ACB closed, PLU receives NOTIFY). When the sense
is 0826 (request not supported) there is no reason to
end the VTAM session because the PLU knows that the data
was discarded (this can happen if a data base has been
taken down).
DESCRIPTION2: After APAR 2300107 the VC upper window edge is not set
when a PVC SETUP packet is built. This makes the VC's
X25 transmit window appear closed. Host data must be
deferred until the window is opened.
Most installations will not see this because in most
cases the router sends a RESET DIAG=015 following it's
response to the HNAS PVC SETUP. This reset opens the
X25 window.
SOLUTION 1: HNAS logic modified to not end the VTAM session when
a -RSP SENSE=0826 is received from the PLU on a PVC
session.
SOLUTION 2: HNAS logic modified to properly set the upper window
edge.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-09-08 - APAR 2300201 (was unpublished problem 2006250A)
APAR: 2300201
STATUS: CLOSED
OPEN_DATE: 2006-09-07
CLOSE_DATE: 2006-09-08
SERVICE(S): GATE
MANDATORY: RECOMMENDED
ORIGIN/REF: 230_ZAG
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300201.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-12-23
with APAR 2300172 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHRQ, MCHNRQC
SOURCE(S): N/A
PROBLEM 1: REQSESS operations for GATE control and Fast Connect
(FC) data sessions are not retried when the PLU is not
active.
PROBLEM 2: Enhancement to provide a NASxxxxI alert message to
indicate that a GATE control session has been bound.
DESCRIPTION1: The HNAS LUs for GATE control sessions and GATE FC
data sessions should always be in session with the PLU
if the PLU name is defined in the HNAS CDF. In order
to establish these sessions HNAS uses a VTAM REQSESS
macro to ask the PLU for a bind. If the PLU is not
active the REQSESS fails. A NAS3702W alert is issued
with SENSE=0857xxxx. HNAS should retry the REQSESS
based on the MCHTMR value (default=60 seconds).
Because of an error in the REQSESS completion routine
the REQSESS is not retried.
SOLUTION 1: REQSESS completion routine corrected so that REQSESS
is retried.
SOLUTION 2: NAS3797I LU lu-nm RECEIVED BIND FROM PLU plu-nm
The above alert message will be issued when a GATE
control session is bound. Previously this alert
was only used for BINDs received for PVC LUs.
This will eliminate the requirement to view the HNAS
DLU command display output to confirm that the GATE
control session is active.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-09-07 - APAR 2300200
APAR: 2300200
STATUS: CLOSED
OPEN_DATE: 2006-09-05
CLOSE_DATE: 2006-09-07
SERVICE(S): TCP/IP interface support
MANDATORY: YES
ORIGIN/REF: 230_NBK
CP_TECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300200.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): 2300199 and associated APAR chains
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: NAS2211W CLOSE REQUEST FAILED error message erroneously
generated due to bad socket number being passed to the
socket CLOSE processor condition can lead to depletion
of sockets.
The following messages are generated when an inbound
socket connection is received from a non-configured
router:
NAS2261W SERVER=010.117.056.170(01998) SOCKID=0000
PCEID=0007 NAME=XOTSRVR
NAS2261W ACCEPT REQUEST FAILED, RC=EEEEEEEE FFFFFFFF
NAS2211W SERVER=010.117.056.170(01998) SOCKID=0000
PCEID=0007 NAME=XOTSRVR
NAS2211W CLOSE REQUEST FAILED, RC=FFFFFFFF 00000403
NAS2262W SERVER=010.117.056.170(01998) SOCKID=0000
PCEID=0007 NAME=XOTSRVR
NAS2262W REMOTE=010.117.056.100(51973) NOT CONFIGURED,
CONNECTION REJECTED
DESCRIPTION: The NAS2261W and NAS2262W messages are correctly issued
when an inbound socket connection is received for a
non-configured router but the NAS2211W message is not.
This message is being generated due to a bad socket
number being passed the the socket CLOSE processor
(TCPCLS).
In addition to the erroneous NAS2211W message, the
allocated socket remains allocated because the CLOSE
request failed. This means that a new connection will
not reuse the same socket but will allocate a new one.
If the problem persists, it is theoretically possible
to run out of sockets which can only be corrected by
stopping and restarting HNAS.
CIRCUMVENTION: Add a TYPE=XOT|XTP REMOTE definition statement with
the IPADDR= operand set to the value displayed in
in the NAS2262W message or set IPADDR=DYNAMIC.
SOLUTION: HNAS has been modified to correct the blown register
that is passed to TCPCLS.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-06-30 - APAR 2300199 (was problem 2006118A)
APAR: 2300199
STATUS: CLOSED
OPEN_DATE: 2006-04-28
CLOSE_DATE: 2006-06-28
SERVICE(S): TCP/IP interface support
MANDATORY: YES
ORIGIN/REF: 230_SDDC, 230_LPT
CP_TECH: SFD
PUBLISH: YES
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300199.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300190 and associated APAR chains
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: NASHALT U198 ABEND due to TCPIP interrupt sequence
number validity check failure.
HALT AT LOC 80047F7E IN NASTCP : TCPIP REPLY ID FAILURE
DESCRIPTION: The TCPIP component in question is a Server PCE. It
is running a SELECT and was dispatched with a 'bad'
interrupt buffer. This caused a sequence number
mismatch which resulted in the ABEND. It appears
that the PCE is being posted incorrectly so that
dispatch is pre-mature.
The NASHALT is occurring in the TCPSEL routine due to
a PCE post before the SELECT is started. TCPCLS logic
(TCLS550) will post the HOME server PCE when a client
CLOSE ends if the server PCE is not executing a command.
Due to a very small timing window, it is possible for
the server to be between commands when the client close
completes which makes TCLS550 logic think that the
server needs to be 'woken up'. This is a holdover from
the very earliest HNAS implementation. The server post
by client CLOSE logic effectively ends the server
SELECT before it is started. The server PCE should
always be left alone when the client CLOSE completes.
SOLUTION: HNAS has been modified to leave the server PCE 'as is'
when the client CLOSE completes. The server subtask
will reschedule a new command via timer or subsequent
subtask dispatch.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-06-30 - APAR 2300198 (was problem 2006174A)
APAR: 2300198
STATUS: CLOSED
OPEN_DATE: 2006-06-23
CLOSE_DATE: 2006-06-28
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: 230_LPT
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300198.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-05-19
With APAR: 2300134 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHRSP
SOURCE(S): N/A
PROBLEM: Session clears with DIAG=219 (DB) after PLU rejects
HNAS FMD with SENSE=100307D1.
DESCRIPTION: This problem occurs when an invalid transaction ID is
sent to CICS. After the rejected CICS sends an error
message to the remote, HNAS clears the call because
of the rejected FMD. NPSI does not do this.
SOLUTION: HNAS modified to ignore rejects that have sense=10xx.
The following alert will be issued:
NAS3711I LU lu-name RECEIVED -RSP WITH SENSE=xxxxxxxx
FROM PLU plu-nm LUBST1/2=aaaa LUBBST1/2=bbbb
This will properly emulate NPSI operation.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-05-30 - APAR 2300197 (was problem 2006121A)
APAR: 2300197
STATUS: CLOSED
OPEN_DATE: 2006-05-01
CLOSE_DATE: 2006-05-30
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: 230_BMO
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300197.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-02-17
With APAR: 2300109 applied.
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): VTMRCV1 , VTMSND1
PROBLEM: GATE control session cannot be started by PLU because
the HNAS SLU resource is not available (ACB closed).
DESCRIPTION: When the PLU name for an HNAS GATE control session is
provided in the CDF (LUNAME= parameter) HNAS will try
to establish a GATE control session by issuing a REQSESS
VTAM macro which asks the PLU to BIND the HNAS SLU. If
the REQSESS fails HNAS leaves it's SLU ACB open so the
PLU can ACQUIRE the HNAS SLU to start the control
session. If the PLU has an exit routine which rejects
the CINIT request generated by the HNAS REQSESS then the
HNAS REQSESS completes normally and is immediately
followed by a NOTIFY which informs HNAS that the session
was not started. The notify processor closes the ACB
for the session. Timer logic will reopen the ACB and
retry the REQSESS. The problem is that during the
retry time interval the HNAS LU's ACB is closed so the
PLU is not able to acquire the HNAS resource.
Customer encountered this problem when HNAS was move
from one LPAR to another without restarting/recycling
PLU (CICS in this case). The PLU had an EXIT routine
that noticed the change and rejected HNAS CINIT PIUs
from the new location. The PLU had logic to ACQUIRE
the HNAS SLUs but because the HNAS ACBs were not open
(except to issue a REQSESS the resulted in closure)
the ACQUIRE logic could not set up the GATE control
sessions.
SOLUTION: HNAS logic changed to leave the control session LU ACB
open when a NOTIFY is received after a normal REQSESS
completion. This will allow the PLU to ACQUIRE the
HNAS GATE control session SLU.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-05-18 - APAR 2300196 (unpublished problems 2006107A/108B/128A)
APAR: 2300196
STATUS: CLOSED
OPEN_DATE: 2006-04-17
CLOSE_DATE: 2006-05-18
SERVICE(S): PVC
MANDATORY: YES
ORIGIN/REF: 230_CSK
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300196.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-08-30
With APAR: 2300153 applied.
SUPERSEDES: N/A
OBJECT(S): VCRESET , XOTRCV , XOTTR
SOURCE(S): N/A
PROBLEM 1: HNAS PVC LU resource not active/available (ACB closed,
no session with PLU) condition may occur because the
expected RESET CAUSE/DIAGNOSTIC 000/000 is not sent
by the router after a physical X.25 link restart.
PROBLEM 2: NAS7708W message (PVC SETUP failure alert) does not
contain LCN numbers so that matching the router and
HNAS configuration is more difficult.
PROBLEM 3: When a Cisco router CLEAR XOT|X25 command is used to
reset a PVC the VTAM session is not informed.
PROBLEM 4: Incorrect NAS7718T (trace record) displayed when
PARM='MCHTR,TRCPRNT' coded on the HNAS EXEC statement.
DESCRIPTION 1: When there is a failure of an X25 link with PVCs
the router sends a RESET CAUSE/DIAGNOSTIC 029/115
for each active PVC on the link (non-PVC resources
receive a CLEAR with the same cause and diagnostic).
When this reset is received HNAS ends the PVC's
VTAM session by closing the HNAS SLU's ACB. This
causes a NOTIFY to be sent to the PLU. The ACB
is reopened when a RESET 000/000 is received
(indicating the link is again active). Traces taken
at the customer site show that a RESET 015/000 may
be used instead of a RESET 000/000 to indicate that
the link is active.
DESCRIPTION 2: See Problem 2.
DESCRIPTION 3: When a Cisco 'clear xot|x25 resource-types' command
is issued to a router X.25 or XOT PVC a RESET CAUSE
DIAGNOSTIC 015/122 is sent to the respective HNAS PVC.
The PLU should be informed of this reset because data
may be lost when the command is entered.
DESCRIPTION 4: See Problem 4.
SOLUTION 1: HNAS logic changed to accept RESET CAUSE/DIAGNOSTIC
values 000/000 and 015/000 indicating that the X25
link operation has been established. Tests performed
with our equipment indicate that a 'link up' reset is
not always sent to HNAS. For this reason the PVC VTAM
session will be re-established approximately 1.5
minutes after a link down reset is received.
SOLUTION 2: LCN information added to NAS7708W message. The LCN
is displayed as PVC= to be consistent with router
displays.
NAS7708W XOT PVC SETUP INIT=SERIALMCH1 PVC=003
RESP=SERIAL0/1 PVC=003
SOLUTION 3: RESET CAUSE/DIAGNOSTIC 015/122 will cause the PVC's
VTAM session to end.
SOLUTION 4: Logic corrected so that the NAS7718T message is only
recorded if TRCMCH ICR is active.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-05-10 - APAR 2300195
APAR: 2300195
STATUS: CLOSED
OPEN_DATE: 2006-05-10
CLOSE_DATE: 2006-05-10
SERVICE(S): TRACE
MANDATORY: NO
ORIGIN/REF: 230_CPT
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300195.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-08-23
With APAR: 2300152 applied.
Installing this APAR will also pick up APAR 2300191
if not already present.
SUPERSEDES: N/A
OBJECT(S): MCHINI
SOURCE(S): N/A
PROBLEM: When PARM=MCHTRC is specified (or taken as a default)
not all MCH trace bits are set resulting in some
internal trace records not being created.
DESCRIPTION: See problem.
SOLUTION: Logic corrected.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-05-02 - APAR 2300194 (was unpublished problem 2006111B)
APAR: 2300194
STATUS: CLOSED
OPEN_DATE: 2006-04-21
CLOSE_DATE: 2006-05-02
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: 230_VWG
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300194.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2006-03-22
With APARs: 2300185 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHGTRQ
SOURCE(S): N/A
PROBLEM: USER 198 ABEND with the message:
HALT AT LOC xxxxxx IN VTMRSPC : BFR REQ'D
DESCRIPTION: Gate control session UNBIND processing does not
properly refresh LU. Subsequent (3 seconds later)
BIND SDT discovers the inconsistent LU bits.
This condition was observed in an environment where
the router was generating spurious data sequences
across all interfaces.
SOLUTION: HNAS UNBIND logic for control session LU changed to
close the SLU's ACB, rebuild the SLU's VTAM control
blocks and then reopen the SLU's ACB.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-05-02 - APAR 2300193
APAR: 2300193
STATUS: CLOSED
OPEN_DATE: 2006-04-27
CLOSE_DATE: 2006-05-02
SERVICE(S): VARY and MON console command processing
MANDATORY: NO, but recommended
ORIGIN/REF: 230_CPT
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300193.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): 2300188, 2300161 and their associated APAR chains
OBJECT(S): CONSMON, CONSVARY, NASCONS
SOURCE(S): XFBLK
PROBLEM1: Misleading error message is issued when the VARY or MON
command is entered without RNM= or ID= being set.
PROBLEM2: If VARY OFF is entered followed by VARY OFF FORCE for an
XOT REMOTE socket (RNM=rmtname or ID=lo{-hi}), the FORCE
action is ignored.
DESCRIPTION1: If VARY or MON is entered without RNM= or ID= being set,
the command is rejected and the following error message
is generated:
NASC300E RNM= OMITTED, REQUIRED
Since the VARY and MON command accepts an ID= value
when RNM= is omitted, the message should include the
omitted ID= reference as well.
DESCRIPTION2: The VARY OFF logic marks the target XOT socket as
'pending inactive' which takes effect when the socket is
closed in the normal manner, that is, when the remote
user logs off or disconnects. If VARY OFF FORCE is
entered after the socket is marked 'pending inactive',
the FORCE action is ignored.
SOLUTION1: The VARY and MON command processors have been modified
to reject the command when RNM= and ID= are both omitted
and issue the following error message:
NASC100E ID= OMITTED, REQUIRED WHEN RNM= NOT SET
SOLUTION2: The VARY command processor has been modified to ignore
the 'pending inactive' state and always disconnect the
socket when FORCE is specified. FORCE can now also be
entered without the OFF prefix.
CIRCUMVENTION1: Always specify an ID= value when RNM= is omitted.
CIRCUMVENTION2: Always use FORCE when varying a REMOTE XOT socket
offline.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-04-29 - APAR 2300192
APAR: 2300192
STATUS: CLOSED
CLOSE_DATE: 2006-04-29
SERVICE(S): CONCMDQ=DNAS default fix
MANDATORY: NO, but recommended
ORIGIN/REF: 230_CPT
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX, (OBJ) HNASOBJX and CONSDNAS - REFRESH
PTF_LOC: REFRESH REQUIRED
COREQ(S): N/A
PREREQ(S): 2300188, 2300176, 2300168, 2300161
and their associated APAR chains
Note: Because CONSDNAS is included in this APAR,
a new a product maintenance refresh to pick
up this problem fix IS REQUIRED.
OBJECT(S): CNFGCNCM, CONSDMAP, CONSDNAS, NASCONS
SOURCE(S): NASMAIN, XFNASWA
PROBLEM: DNAS is set as default queued command only when CONCMDQ=
is omitted from BUILD.
DESCRIPTION: When the CONCMDQ=(cmdlist) operand is specified, DNAS
console command must manually be included by user in
CONCMDQ=(DNAS,cmdlist) since the configuration process
does not set DNAS unless CONCMDQ= is omitted. If a
user forgets to include DNAS in the CONCMDQ= string,
the DNAS command will not be executed automatically.
This can make problem diagnosis difficult when we
receive an HNAS log with missing DNAS output.
SOLUTION: HNAS has been modified to execute the DNAS command when
HNAS is started, unconditionally. DNAS no longer has to
be specified in the CONCMDQ= operand and will no longer
be a default queued command if CONCMDQ= is omitted.
Unlike the DNAS command in the CONCMDQ= list which is
executed after the NAS0001I INITIALIZATION COMPLETE
is issued, the new DNAS logic executes as soon as the
CDF scan completes.
NOTE: The DMAP APAR command is also executed after
the CDF scan is complete (before DNAS) in order
to populate the APAR table and find the highest
APAR number on the system which DNAS displays.
Starting with this APAR, the DNAS APAR command
that is executed at startup will no longer write
output to SYSPRINT. If you wish to see DMAP APAR
output, you can enter the command manually or
specify it in the CONCMDQ= operand.
CIRCUMVENTION: Always include DNAS in the CONCMDQ=(DNAS,cmdlist)
operand list.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-04-27 - APAR 2300191
APAR: 2300191
STATUS: CLOSED
OPEN_DATE: 2006-04-24
CLOSE_DATE: 2006-04-27
SERVICE(S): PVC
MANDATORY: RECOMMENDED
ORIGIN/REF: 230_CSK
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300191.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-08-23
With APAR: 2300152 applied.
SUPERSEDES: N/A
OBJECT(S): MCHINI
SOURCE(S): N/A
PROBLEM: HALT AT LOC xxxxxxxx IN MCHGETMN: MCH STORAGE BLOCK
EXHAUSTED can occur as HNAS is starting.
DESCRIPTION: This halt (U198 ABEND) occurs when there is an error
in the calculation of the size of the storage block
required to hold HNAS control blocks. The error
occurs when a large number of PVCs are defined.
This condition was observed at a customer site after
additional PVC resources were added to a previously
operational environment.
SOLUTION: Storage calculation for PVC control blocks corrected.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-04-27 - APAR 2300190
APAR: 2300190
STATUS: CLOSED
OPEN_DATE: 2006-04-07
CLOSE_DATE: 2006-04-27
SERVICE(S): HNAS-TO-HNAS Support Fixes
MANDATORY: NO, but recommended
ORIGIN/REF: 230_CPT
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300190.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): 2300183, 2300176, 2300015
and their associated APAR chains
OBJECT(S): CNFGIPAD, NASCNFG
SOURCE(S): NASTCP
PROBLEM1: ACCEPT failure with EWOULDBLOCK (23) is not being
retried as API doc recommends.
PROBLEM2: 'NAS1321E REMOTE IPADDR INVALID, MUST BE DIFFERENT
THAN LOCAL' message is being generated when IPADDR=
for LOCAL and REMOTE definitions are the same.
PROBLEM3: 'NAS1321E REMOTE NAME CONFLICTS WITH ANOTHER REMOTE'
message is being generated when it should not be.
DESCRIPTION1: ACCEPT failure with EWOULDBLOCK results in SELECT being
issued rather than ACCEPT being re-issued. This can
cause loss of inbound connection. TCPIP API document
recommends re-issuing ACCEPT if EWOULDBLOCK is detected
noting that EWOULDBLOCK is a temporary condition.
DESCRIPTION2: In a HNAS-TO-HNAS environment, where both HNAS are
connected to the same TCPIP stack, the initiator HNAS
contains a REMOTE definition that identifies the HOME
LOCAL in a remote acceptor/responder HNAS. Because
inbound sockets are allocated based on the REMOTE
definitions defined in the CDF, the acceptor/responder
HNAS must contain a REMOTE with the same IPADDR=
value as its HOME LOCAL or must contain a REMOTE with
IPADDR=DYNAMIC which would allow any IP address to be
accepted. In an HNAS-TO-HNAS environment when a common
TCPIP stack is used, the NAS1321E message is incorrect.
DESCRIPTION3: The first 4-characters of the name of a TYPE=MCH|XTP
REMOTE must be unique with respect to all other
TYPE=MCH|XTP REMOTEs in the CDF but not with other
REMOTE types. The NAS1321E message is being generated
when the first 4-characters of an MCH name match the
first 4-characters of an MXT name even though the
complete names are different. The NAS1321E message
is incorrect in this instance.
SOLUTION1: The TCPIP ACCEPT processor has been modified to retry
the ACCEPT if it ends with the EWOULDBLOCK error
condition. The subsequent ACCEPT should end normally.
SOLUTION2: The IPADDR= decode processor will no longer reject a
REMOTE IP address that matches a LOCAL IP address.
A current circumvention would be to define a dynamic
socket pool (REMOTE TYPE=XOT,IPADDR=DYNAMIC).
SOLUTION3: The REMOTE name processor has been modified to only
enforce the 4-character uniqueness rule association
for TYPE=MCH|XTP REMOTEs.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-04-11 - APAR 2300189 (no problem# assigned)
APAR: 2300189
STATUS: CLOSED
OPEN_DATE: 2006-04-11
CLOSE_DATE: 2006-04-11
SERVICE(S): VTAM (USSMSG SUPP=ALWAYS)
MANDATORY: YES
ORIGIN/REF: 230_ATO
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300189.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2006-02-02
With APAR: 2300181
SUPERSEDES: N/A
OBJECT(S): MCHSOL
SOURCE(S): N/A
PROBLEM: HNAS erroneously sends USSMSG when SUPP=ALWAYS is
specified.
DESCRIPTION: See problem.
SOLUTION: HNAS logic added to suppress delivery of a USSMSG
if SUPP=ALWAYS coded.
CIRCUMVENTION: Remove the USSMSG macro with SUPP=YES (references
the suppressed message).
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-04-05 - APAR 2300188 (was problem 2006088A)
APAR: 2300188
STATUS: CLOSED
OPEN_DATE: 2006-03-29
CLOSE_DATE: 2006-04-05
SERVICE(S): Console Trace support
MANDATORY: NO, but recommended
ORIGIN/REF: 230_SDD
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300188.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): 2300174, 2300168, 2300164, 2300161
and their associated APAR chains
Note: Due to the large number of PreReqs, we
recommend a product maintenance refresh
to pick up this problem fix.
OBJECT(S): CONSTLU, CONSTLUQ, CONSTMCH, CONSTMCX, CONSTPCE,
CONSTVC, CONSTVCQ, NASCONS
SOURCE(S): XFBLK
PROBLEM: When omitted ID= modifier is in effect, TRCxxx ON|OFF
is treated the same as ALLON|ALLOFF, respectively.
DESCRIPTION: When the ID= modifier is omitted or is set to zero,
the TRCLU, TRCLUQ, TRCMCH, TRCMCHX, TRCPCE, TRCVC
and TRCVCQ commands act on ALL related resources
when the ON|OFF argument is specified. Since
ALLON and ALLOFF are provided for this function,
the missing ID= value should generate an error
message. ID= omitted and ID=0 should be treated
separately. If ID=0 is specifically entered,
ON|OFF will start local resource tracing for ALL
PCE related resources.
Note that the ID= modifier is only used when the LNM=
RNM= or LUNM= modifiers are not set for a particular
command that requires a resource identifier. For
example, the TRCLU command accepts LUNM= which
overrides RNM= which, in turn, overrides ID=. The
command modifier hierarchy is described in the
Console Subsystem documentation.
SOLUTION: The trace processors have been modified to reject the
command when ID= is not set and the following error
message will be issued:
NASC100E ID= OMITTED, REQUIRED WHEN LNM=, RNM= OR
LUNM= IS NOT SET
The trace command will continue to process the request
when ID=0 is specifically set.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-04-01 - APAR 2300187 (was unpublished problem 2006081A)
APAR: 2300187
STATUS: CLOSED
OPEN_DATE: 2006-03-22
CLOSE_DATE: 2006-04-01
SERVICE(S): LLC0/LLC5 CALLOUT
MANDATORY: YES
ORIGIN/REF: 230_CCS
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300187.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): N/A
SUPERSEDES: N/A
OBJECT(S): MCHSUP
SOURCE(S): N/A
PROBLEM: Customer trace shows that the interval between a
callout failure (no call accept or call cleared)
and the UNBIND sent to the PLU can be as long as
28 seconds.
DESCRIPTION: When an outbound call request fails (clear received
or timeout) an UNBIND request build is scheduled
for the PLU. Because of an error in the MCH work
supervisor the LU's UNBIND request may be deferred.
Any activity on any LU associated with the MCH will
result in the request being serviced. If only one
LU is active a background timer will ultimately
schedule an MCH work cycle that picks up the UNBIND
request.
SOLUTION: MCH work processor logic corrected.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-03-22 - APAR 2300186 (was problem 2006027A and 2006048A)
APAR: 2300186
STATUS: CLOSED
OPEN_DATE: 2006-01-27 for 2006027A
2006-02-17 for 2006048A
CLOSE_DATE: 2006-03-22
SERVICE(S): QLLC PVC and SVC support
MANDATORY: YES
ORIGIN/REF: 230_ITE
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300186.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): 2300182, 2300176, 2300159, 2300157, 2300151, 2300136,
2300107 and their associated APAR chains
Note: Due to the large number of PreReqs, we
recommend a product maintenance refresh
to pick up this problem fix.
OBJECT(S): MCHBFR, MCHPVCI, NASUTIL, QLSSCP, VCCLRQ, VCUT1, XOTBXM
SOURCE(S): LUD
PROBLEM1: NASHALT 0198 ABEND occurs when ACTPU received for
QLLC PVC: HALT AT LOC 8005EACC IN MCHNQ : INV QCB
PROBLEM2: When the XID exchange completes for a PVC, an NAS8102W
message is being generated because the SPU appears busy.
PROBLEM3: A NOTIFY request is being rejected with 200D sense
after a TERM-SELF response is returned to the SLU.
DESCRIPTION1: HNAS is attempting to send ACTLUs to all SLUs on a
QLLC PVC but the transmit QCB (VCLUXBRQ) has been
corrupted.
DESCRIPTION2: PVC SPU is connecting but 'NAS8101W WAS NOT CONFIGURED'
message is being generated because the VCSPUPT field
initialized by MCHPVCI was being reset by VCQLCN in
VCCLRQ.
DESCRIPTION3: HNAS is rejecting a NOTIFY request that is received
after a TERM-SELF request/response exchange because the
NOTIFY request is received before an outstanding DACTLU
response. The following alarm message is also issued:
NAS8241W INVALID REQ FOR LU LA50 ON PU P0AEMERC
RH/RU=0B80008106200C06 RC=34
The NOTIFY request should not be rejected because it
occurs after the TERM-SELF response is transmitted by
HNAS thus satisfying the rules for immediate request
mode protocol for the SLU half-session within the
normal flow. The outstanding DACTLU response, which is
expedited, originates in the SSCP half-session which
should be treated independently. The exception to this
rule is in HDX mode within the SLU/PLU session where a
response to a request must be returned before another
request can be sent. If a violation of the rule occurs
in this state, the 200D sense is appropriate.
SOLUTION1: The MCHPVCI routine has been modified to initialize
the VCLUXBRQ QCB just as the MCHINI routine does.
SOLUTION2: Logic has been changed to ignore SPU busy condition if
SPU is a PVC and IDBLK/IDNUM match. VCQLCN no longer
resets the VCSPUPT field for a PVC.
SOLUTION3: The NOTIFY processor has been modified to ignore the
state of the SSCP (HNAS) half-session and only look
at the SLU half-session when determining if the
immediate request mode protocol is being violated.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-03-22 - APAR 2300185 (was unpublished problem 2006075B)
APAR: 2300185
STATUS: CLOSED
OPEN_DATE: 2006-03-16
CLOSE_DATE: 2006-03-22
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: 230_ATO
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300185.ZIP file)
SMP/E PTFs are provided via user request because the
Comm-Pro supplied MCS is unique to each customer.
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2006-01-23
With APAR: 2300178 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHGTRQ , MCHHL4RQ
SOURCE(S): N/A
PROBLEM: Following alert message received:
NAS4707W LU lu-nm GENERATING ERR/INFO PACKET FOR CTCP
plu-nm GATE CMD RCV'D 17 HNAS ERROR CODE 1, 2 or 3
DESCRIPTION: After APAR 2300178 HNAS issues the NAS4707W alert and
generates an ERR/INFO packet to inform the CTCP of
an error detected by HNAS.
The above alert is issued when HNAS receives a clear
confirmation from the CTCP. This command is not shown
in the CTCP to GATE command diagrams (it is valid on
the GATE to CTCP command flow).
SOLUTION: We have been advised that NPSI silently discards a
clear confirm from the CTCP. HNAS will do the same.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-03-02 - APAR 2300184 (was problem 2006060A)
APAR: 2300184
STATUS: CLOSED
OPEN_DATE: 2006-03-01
CLOSE_DATE: 2006-03-02
SERVICE(S): LLC0/5 2-WAY LUs
MANDATORY: YES
ORIGIN/REF: 230_CPA
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300184.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-08-30
with APAR: 2300153 applied.
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): VTMUT1
PROBLEM: HALT AT LOC xxxx IN VTMSREQS: INV LU
DESCRIPTION: This HALT occurs when HNAS is trying to issue a REQSESS
macro to ask the PLU for a BIND to start a session for
an inbound call. A validity test ensures that the send
RPL is available for the operation. This HALT indicates
that the RPL was already busy.
The LLC0 LU is defined with:
slu-nm/X53...-3110...T1/mxt-nm
When an lu is defined as 2-way the session can be
started with a BIND from the PLU which will trigger a
callout operation using the 3110... dte address. The
session can also be started with an inbound call with
an IDNUM of 53... in CUD. For inbound calls the 1
following the 'T' gives the PLU name (via APPLNAME=).
The LU start sequence is:
1) Open LU's ACB.
2) Issue SETLOGON (using the LU's send RPL) to inform
VTAM that the LU is an SLU.
3) SETLOGON completes (send RPL becomes available).
The above sequence usually completes less than .001
seconds.
At this point HNAS waits for a PLU BIND or for a call
request from a remote.
If a call request arrives that selects a 2-way LU HNAS
will issue a REQSESS asking the PLU for a BIND. This
operation also uses the LU's send RPL.
If a call request arrives between steps 2) and 3)
(above) then the HALT occurs because an RPL cannot be
used for two operations at the same time.
SOLUTION: HNAS corrected to not use 2-way LU for a new inbound
call if the send RPL is active.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-02-09 - APAR 2300183 (related to unpublished problem 2006012A)
APAR: 2300183
STATUS: CLOSED
OPEN_DATE: 2006-01-12
CLOSE_DATE: 2006-02-09
SERVICE(S): MON TAP message filtering
MANDATORY: NO
ORIGIN/REF: 230_CGS
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300183.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300179 and associated APAR chains
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: Customer reports that they cannot filter NAS2513M
(MON TAP) monitor message from SYSPRINT using
ALRMFLTR=(NAS2513M(P)).
DESCRIPTION: The NAS25xxM messages were designed not to be filtered
out because they are considered monitor messages rather
than alarms. Due to a 'loophole' in the HNAS message
filtering logic, monitor messages could be filtered
from SYSPRINT using ALRMFLTR=(NAS25**I(P)) which
defeats the purpose of the MON TAP process to begin
with. Monitor messages, like trace messages (e.g.,
NAS7718T) should never be allowed to be filtered.
CIRCUMVENTION: N/A
SOLUTION: HNAS has been modified so that MON TAP monitor
messages cannot be filtered from SYSPRINT. This
has always been the case for trace messages.
Specifying ALRMFLTR=(NAS****M(P),NAS****T(P)) will
not purge monitor or trace messages from SYSPRINT.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-02-09 - APAR 2300182 (was unpublished problem 2006019A)
APAR: 2300182
STATUS: CLOSED
OPEN_DATE: 2006-01-19
CLOSE_DATE: 2006-02-09
SERVICE(S): NETVIEW (SYSCONS) routing for NAS0910I message
MANDATORY: NO but recommended
ORIGIN/REF: 230_CSG
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300182.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300179 and associated APAR chains
OBJECT(S): NASUTIL
SOURCE(S): N/A
PROBLEM: NAS0910I '3 BELLS AND ALL IS WELL' message is not
being routed to SYSCONS and NETVIEW.
DESCRIPTION: Message destination for NAS0910I message was set to
SYSPRINT only which prevented message from going to
SYSCONS and NETVIEW when SHOWERR is in effect.
Contrast this to the NAS0001I 'INITIALIZATION COMPLETE'
message which does make it to SYSCONS and NETVIEW.
CIRCUMVENTION: N/A
SOLUTION: The message destination for the NAS0910I message has
been changed from SYSPRINT only to SYSPRINT and SYSCONS.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-02-02 - APAR 2300181
APAR: 2300181
STATUS: CLOSED
OPEN_DATE: 2006-02-01
CLOSE_DATE: 2006-02-02
SERVICE(S): USSTAB
MANDATORY: YES
ORIGIN/REF: 230_BMO
CPTECH: CPT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300181.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-06-08
With APAR: 2300137
SUPERSEDES: N/A
OBJECT(S): MCHSOL
SOURCE(S): N/A
PROBLEM: USSMSG 3 (EXTRANEOUS PARAMETER) message issued when
keyword parameter from remote not in any USSPARM
entry following the selected USSCMD entry.
DESCRIPTION: This problem occurs when a USSCMD macro uses the REP=
OPTION to create a LOGON command.
Example:
USSCMD CMD=AAAA,REP=LOGON,FORMAT=BAL
USSPARM P1,REP=APPLID
Inbound command (gets USSMSG 3 without APAR):
AAAA TSO,DATA=BBB
Resulting internal command processed (with APAR):
LOGON APPLID(TSO) DATA(BBB)
SOLUTION: Logic changed so that in the above case USSMSG 3 is
not issued and the DATA= parameter is passed to the
PLU as user data in a REQSESS macro.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-01-30 - APAR 2300180
APAR: 2300180
STATUS: CLOSED
OPEN_DATE: 2006-01-27
CLOSE_DATE: 2006-01-30
SERVICE(S): VTAM
MANDATORY: YES
ORIGIN/REF: 230_BNP
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300180.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2006-01-02
with APAR: 2300174 applied.
SUPERSEDES: N/A
OBJECT(S): MCHTMR
SOURCE(S): VCDD, VTMTR
PROBLEM: LU appears hung, following displayed in SYSPRINT:
REMOTE rmt-nm lu-nm LU lu-addr LUIQ TIMEOUT,
LUIQ BFR CT=xxxx
DESCRIPTION: The above ALERT (which is missing the required
NASxxxxW prefix) is issued when an LU has had data
queued for the PLU for 4 minutes. When this happens
the LU's VTAM session should be ended.
This problem was uncovered at an installation that did
not have APAR 2300143. APAR 143 would have avoided the
problem. This APAR is being issued because the LUIQ
timeout processing is incorrect.
SOLUTION: Timer logic modified to end the LU's VTAM session when
this timeout occurs. A NAS4709W alert is issued (see
above for text). If there is a VC session it will be
cleared with DIAG=212.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-01-24 - APAR 2300179 (was problem 2005341B)
APAR: 2300179
STATUS: CLOSED
OPEN_DATE: 2005-12-07
CLOSE_DATE: 2006-01-24
SERVICE(S): TCPIP interface support and TAP processing
MANDATORY: YES
ORIGIN/REF: 230_BNP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300179.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300173, 2300167 and their associated APAR chains
OBJECT(S): NASUTIL
SOURCE(S): NASTCP
PROBLEM: NASHALT IN NASTCP - INVALID TCPIP INTERRUPT occurs after
NAS2201W SOCKET REQUEST FAILED, RC=FFFFFFFF 0000040C
message is issued.
DESCRIPTION: ERNO=40C in NAS2201W message says that the TCPIP stack
is inactive. NASHALT says that TCPIP socket number
that was provided for the interrupt request was invalid.
Prior to the NAS2201W message above, HNAS received an
indication that the HOME LOCAL's connection to the stack
had been severed resulting in a NAS2102E alarm message.
There are a couple of things wrong in the HNAS TCPIP
logic that this problem has revealed.
1) The routine (TCPSUS) that provides TCPIP socket
number management (decrement request in this case) is
testing for normal SOCKET completion (STTCPSOC+STCMND)
On the SOCKET failure path, STCMND has not been set
so the ABEND occurs due a validity check.
2) When the TCPIP sever is detected for the LOCAL server
(NAS2202E message), subsequent TAP requests for
REMOTEs for which the severed LOCAL is HOME should
be inhibited. This will prevent thrashing NAS2201W
messages.
CIRCUMVENTION: N/A
SOLUTION: 1) HNAS will be modified to ensure that STTCPSOC+STCMND
is set on the SOCKET request failure path to avoid
the ABEND.
2) HNAS will be modified to prevent TAPping for REMOTEs
whose HOME LOCAL is IDLE which is the state set after
a stack sever or when the LOCAL remains idle after
it's socket is closed.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-01-23 - APAR 2300178 (was problem 2005334B)
APAR: 2300178
STATUS: CLOSED
OPEN_DATE: 2005-11-30
CLOSE_DATE: 2006-01-23
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: 230_SDD
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300178.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-12-21
With APAR: 2300171 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHGTRQ, MCHHL4RQ, MCHUT1, XOTFCDC, XOTGTCC, XOTGTDC
SOURCE(S): N/A
PROBLEM: VIRTEL GATE FC control session comes down when 135/001
(Cause/Diagnostic) X25 RESET packet received.
DESCRIPTION: When the 135/001 reset is received it is sent to the
PLU. After the reset is delivered the HNAS data session
LU receives 2 packets with invalid GATE control bytes.
This causes HNAS to generate DIAG packets for the CTCP
(sent via the control session) with the text:
"SENDING DIAG PKT :INVALID CTCP DATA SES CMD BYTE".
The CTCP then sends a CLEAR packet to HNAS on the control
session LU. This is invalid (the FC control session is
only used for DIAG and INFO packets and these only flow
from HNAS to the CTCP).
When HNAS receives the invalid PIU with the Clear,
another DIAG packet with the text "SENDING DIAG PKT :
FMD INV ON FC CONTROL SESSION" is generated and sent to
the CTCP via the control session.
The DIAG packet appears to generate another Clear on the
FC control session LU.
The loop is not infinite. After a period, the control
session sends an UNBIND which terminates the control
session LU and it's related data session LUs.
The DIAG packets were designed to inform the CTCP of
problems via the control session. This now appears to
be a bad idea.
SOLUTION: When HNAS receives an invalid packet on a GATE control
or data session LU a NAS4707W alert message will be
issued and an ERROR/INFORMATION REPORT message (not a
DIAGNOSTIC message) will be sent to the CTCP on the
control session LU. Alert format:
NAS4707W LU lu-nm GENERATING ERR/INFO PACKET FOR CTCP
plu-nm GATE CMD RCV'D=cc, HNAS ERROR CODE=ee
cc = X25 command byte received by HNAS.
ee = Error code: 1 = Invalid cmd on GATE ctl session.
2 = Invalid cmd on FC GATE ctl session.
3 = Invalid cmd on GATE data session.
4 = cmd on FC GATE data session does
not meet minimum length requirement.
5 = cmd on GATE ctl session does not
meet minimum length requirement.
6 = cmd on GATE data session does not
meet minimum length requirement.
When HNAS receives a CLEAR packet on an FC control
session LU a NAS4708W alert message will be issued and
a CLEAR-CONFIRM will be returned to the CTCP. Data
session LUs will not be affected. Alert format:
NAS4708W GATE FC CTL SES LU lu-nm CLEARED BY CTCP plu-nm
CAUSE/DIAG=cc/dd
cc/dd = CTCP's CLEAR cause and diagnostic bytes (in hex).
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-01-23 - APAR 2300177 (was problem 2005298B)
APAR: 2300177
STATUS: CLOSED
OPEN_DATE: 2005-10-25
CLOSE_DATE: 2006-01-23
SERVICE(S): VTAM
MANDATORY: RECOMMENDED
ORIGIN/REF: 230_FDK
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300177.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 2005-06-29
With APAR: 2300144 applied.
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): VTMSND2
PROBLEM: Customer is receiving NAS3705W alert messages with
SENSE=0814.
DESCRIPTION: This alert message indicates that HNAS is rejecting a
PIU from the PLU. The HNAS MsgCodes document mentions
that the 0813 and 0814 (bracket rejects) can be normal.
Documentation is being revised to note that the
INHIBITBIDREJ and NORTRBIDREJ options can be used to
reduce the number of NAS3705W alerts.
This alert was introduced by APAR 2300144.
SOLUTION: Documentation revised, severity character in NAS3705
alert message changed from 'W' to 'I' when the sense
is 0813 or 0814.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-01-19 - APAR 2300176 (was problems 2005279B and 2005348A)
APAR: 2300176_E
STATUS: CLOSED
OPEN_DATE: 2005-10-06 for 2005279B
2005-12-14 for 2005348A
CLOSE_DATE: 2006-01-19
SERVICE(S): RTEIN= operand configuration/run time processing
MANDATORY: NO, but recommended
ORIGIN/REF: 230_OVR,230_BCM
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300176.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300169, 2300166, 2300163, 2300161, 2300151
and their associated APAR chains
Note: Due to the large number of PreReqs, we
recommend a product maintenance refresh
to pick up this APAR.
OBJECT(S): CNFGOPTS, CNFGRTIN, CONSDLDL, CONSMLCL, NASCNFG,
VCCLRQ, XOTUT1
SOURCE(S): MCHD, NASMAIN, XFNASWA
PROBLEM1: Allow RTEIN= processing to be controlled by calling
(ENHANCEMENT) address (=>S) in addition to the existing called DTE
address (=>T) in a manner similar to that used for
the RTEOUT= operand.
DESCRIPTION1: <See Problem1>
SOLUTION1: HNAS modified to accept the following RTEIN= format:
RTEIN=(...,mch-name/addr{S|T},...)
and the new OPTIIONS=BALANCERTEIN value.
Example:
RTEIN=(MCH1/20367777T,MCH2/7796S)
When an inbound XOT call is received elements in the
RTEIN= list are scanned left to right looking for a
virtual MCH for the call.
If a RTEIN entry has a T marker (or if no marker is
coded after the address) the called address in the
inbound call request packet is compared to the
address in the RTEIN= entry.
If a RTEIN entry has an S marker then the calling
address in the inbound call request packet is
compared to the address in the RTEIN= entry.
In either case an n digit RTEIN entry matches an
m digit call request packet if n < m and the first
n digits match.
RTEIN addr 123567 matches call request packet
addresses 1234567, 1234567xx, etc.
Side effect for the STRIPRTEIN option:
This option causes HNAS to strip the RTEIN digits
used for MCH selection from the called address in
the call request packet sent to the CTCP. When
the calling address selects the MCH the packet
sent to the CTCP will have the original called
address (option suppressed).
PROBLEM2: Enhancement to RTEIN= processing to allow inbound
(ENHANCEMENT) calls to be distributed across multiple MCHs
defined by TYPE=MCH REMOTEs.
DESCRIPTION2: Customer requested the ability to distribute inbound
GATE sessions over multiple CTCPs on distinct MCHs
addressed by the LOCAL statement's RTEIN= operand.
Because the LLC type is not known until the MCH is
addressed and processed (MCH operands such as LLC0=,
CUD0= and CTCP= set the LLC TYPE) this enhancement
distributes sessions for all LLC types when the
enabling option is coded.
When OPTIONS=BALANCERTEIN is coded on an XOT LOCAL
(PORT=1998) statement the following actions are
taken when an inbound call is received:
1) the RTEIN= list is processed against the called
and/or calling DTE addresses in the call request
packet. The MCH address in each RTEIN= entry that
could be used for the call is recorded in an internal
table. A RTEIN= entry 'could be used' if there is a
calling or called address match. A RTEIN= entry with
no dte address is treated as the end of the list (even
if there are more entries) and the MCH it names does
participate in the round robin logic.
2a) If no RTEIN= entries are selected by the RTEIN=
scan and RTEIN= does not end with a no DTE address
entry then the inbound call is cleared with DIAG=202.
2b) If no RTEIN= entries are selected by the RTEIN=
scan and RTEIN= ends with a no DTE address entry then
the TYPE=MCH REMOTE addressed by the no DTE address
entry is used for the call.
2c) If one or more RTEIN= entries are selected (tabled)
by the RTEIN= scan then the MCHs addressed by the table
are searched to locate an MCH with a round robin marker
(a flag in the MCH control block). If no marker is
found the first MCH in the table is marked and used for
the call. If a marker is found then it is moved to the
next MCH addressed by the table (possibly after wrapping
to the first table entry) and that MCH is used for the
call.
Examples (OPTIONS=BALANCERTEIN assumed):
RTEIN=(MCH1/7777,MCH2/7777,MCH3/7777,MCH4)
Inbound calls with a called DTE address starting with
7777 will be routed in round robin fashion to MCH1,
MCH2 or MCH3. All other calls go to MCH4.
RTEIN=(MCH1/7777S,MCH2/7777S,MCH3/7777S,MCH4)
Same as above except selection of MCH1/2/3 is based
on the calling DTE address in the call request packet
instead of the called DTE address.
RTEIN=(MCH1/7777,MCH1/6666,MCH2/7777,MCH2/6666,
MCH3/7777,MCH3/6666,MCH4)
Calls with a DTE address starting with 7777 or 6666
will be routed in a round robin fashion to MCH1, MCH2
or MCH3. The first 3 calls with any combination of
the 7777 or 6666 called addresses will be routed to
MCH1, MCH2 and MCH3 (first call to MCH1, second call
to MCH2, etc).
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-01-12 - APAR 2300175 (was problem 2005347B)
APAR: 2300175
STATUS: CLOSED
OPEN_DATE: 2005-10-25
CLOSE_DATE: 2006-01-12
SERVICE(S): CONSOLE - alternate SYSPRINT DCB parameters
MANDATORY: NO but recommended
ORIGIN/REF: 230_FDK (GRK)
CP_TECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300175.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): NASPRNT
SOURCE(S): N/A
PROBLEM: HNAS log records are being truncated when alternate
(not SYSOUT=*) dataset is used for SYSPRINT.
DESCRIPTION: Alternate dataset was allocated with DCB parameters
of RECFM=FBA,LRECL=133,BLKSIZE=3990 but was changed
by HNAS to RECFM=VA, LRECL=135 and BLKSIZE=4054 when
alternate dataset was opened via PRNT CLSOPN ddname.
Not sure that this caused the problem because we were
unable to duplicate the same condition in our lab.
Problem appears to be related to PRNTDATE parameter
which causes Julian date to be appended to beginning
of each print record. For large records, like the
ones reported by the user, last 5-bytes at the end of
the record gets truncated because the print routine
(XFPRNT) enforces a maximum buffer data size of 128
bytes even though the existing DCB parameters specify
RECFM=VA,LRECL=135.
SOLUTION: The print interface routine has been modified to
increase the print buffer size to 133 bytes which
will accommodate the missing 5-bytes of data and the
DCB parameters has been changed to RECFM=VA,LRECL=137
to accommodate the larger print buffer size.
The new buffer and record sizes should be sufficient
for all existing HNAS messages. The real limiting
factor is the WTO text size which is set to 126 by IBM.
The Julian date stamp is not included in the WTO text
count but is included in the PRNT record count. However,
if the message prefix (PFXWTO) is enabled, it will be
added to the WTO text count. Hence, all HNAS messages
should be a maximum of 116 bytes in length. We believe
that BFRSZ=133 and LRECL=137 are now the correct sizes
for all existing HNAS messages.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
2006-01-02 - APAR 2300174
APAR: 2300174
STATUS: CLOSED
OPEN_DATE: 2005-12-30
CLOSE_DATE: 2006-01-02
REV_DATE: 2006-01-11
REV_NOTE: Date format changed from mm-dd-yyyy to yyyy-mm-dd.
SERVICE(S): Trace processing
MANDATORY: NO, but recommended
ORIGIN/REF: 230_OVR
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300174.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300161, 2300153, 2300151, 2300097
and their associated APAR chains
Note: Due to the large number of PreReqs, we
recommend a product maintenance refresh
to pick up this APAR.
OBJECT(S): CONSDMCH, CONSTLU, CONSTLUQ, CONSTMCH, CONSTMCX
CONSTVC, CONSTVCQ
SOURCE(S): LUD, MCHD, MCHXD, QCBD, VCDD
PROBLEM: General code cleanup, no runtime or trace problems.
PROBLEM1: TRCMCH INI option set although flag doesn't actually
control any trace processes (unnecessary option).
PROBLEM2: LU, MCH, MCHX and VC trace flags defined in respective
console command processor module, should be defined in
associated control block.
DESCRIPTION1: MCT1INI flag that is set by TRCMCH INI command is never
tested. Originally designed to trace MCH initialization
processing but was never implemented.
DESCRIPTION2: See problem.
SOLUTION1: TRCMCH command processor has been modified to remove
TRCMCH INI logic. DMCH command processor has been
modified to no longer display TRCMCH INI flag in the
MCHOPT column.
SOLUTION2: LU, MCH, MCHXD and VC trace flags that were defined
locally in respective console command processor
module have been moved to the associated control
block member.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
Last Update - December 29, 2006