APAR memo entries with PTF_TYPE: (ZAP) designations in the HNAS 23n HTML Maintenance Summaries now contain hyperlinks to their respective APAR Memo's in ASCII (*.txt) format. This will allow for immediate ZAP retrieval without having to access the HNAS userid/password based FTP Server. Please be aware that all PTF_TYPE: SRC (source) and OBJ (object) maintenance is provided on the HNAS FTP Server. Please contact your HNAS support representative to request that an FTP userid account be set-up for your organization if you haven't already done so.
| APAR# | CLOSE_DATE | SERVICE |
PTF_TYPE |
PROBLEM |
|---|---|---|---|---|
|
230nnnn 230nnnn_D 230nnnn_E 230nnnn_M 230nnnn_P 230nnnn_R 230nnnn_U |
mm-dd-yyyy-> |
(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 2300174 | <Link forward> | - | - |
HNAS V2R3M0 - 2006 MAINTENANCE SUMMARY (Link to APARs 2300174 thru 2300nnn) |
| - | - | - | - | - |
| 12-28-2005 |
TAP |
OBJ/SRC |
1) NAS2502E can occur when TAP=10
(5 second response t/o) is enabled during callout session testing. |
|
| 12-23-2005 |
GATE |
OBJ |
HNAS time interval when waiting for GATE PLU to UNBIND can be 3 seconds when 10 seconds is the correct value. |
|
| 12-21-2005 |
GATE |
OBJ |
HALT AT LOC addr IN XOTGTDC INV VCLCST during unusual delay for GATE call accept activity. |
|
| 12-21-2005 |
TCPIP Interface |
SRC |
Unusual timing condition causes NASHALT U198 ABEND when HNAS is running and the TCP/IP Stack is forced down. |
|
|
2300169_E |
12-19-2005 |
Console - WTOR |
OBJ/SRC |
HNAS WTOR console interface default is outdated and causes the majority (if not all users) to override with the USEMDFY start parameter. |
|
2300168 |
12-16-2005 |
Console -
DNAS Display Output |
N/A |
Enhancement to include the Host Operating System and Version (retrieved from system's nucleus) and execution start time and date in the DNAS display output. |
|
2300167_E |
12-13-2005 |
Console -
QLLC Alarm Display |
OBJ/SRC |
Customer would like PRNTQLLC feature (like PRNTVC OFF) |
| 12-02-2005 |
PVC |
OBJ |
HNAS U198 ABEND with the message: HALT AT LOC addr IN VTMRSPC : BFR REQ'D due to a validity check in HNAS VTAM RECEIVE logic for a PVC session. |
|
| 11-29-2005 |
Cons-Subsystem |
OBJ/SRC |
Customer reports that DPARM trace parameter display can be confusing as related to TRCtyp followers (ALLON|ALLOFF vs. ON|OFF). |
|
| 11-29-2005 |
Cons-Subsystem |
OBJ |
TRCPCE ALLON|ALLOFF manipulates all global trace flags not just PCE trace flags that can interfere with the users intended global settings. |
|
| 11-18-2005 |
Netview |
OBJ/SRC |
Customer reports that he is unable to route HNAS alarm messages (unsolicited/asynchronous WTOs) to the NETLOG instead of the SYSLOG. |
|
| 2300162_R | 10-28-2005 |
SMP/E Install or Maintenance Assemblies |
N/A Refresh Required |
The NASMAIN & NASTCP assembly steps can end with CC=4 instead of CC=0 during SMP/E install processing, HOST= OS390|ZOS type can further confuse the issue. |
|
2300161 +_E_R |
10-26-2005 | Cons-Subsystem Command/Help Improvements <Enhancement> |
N/A Refresh Required |
1) DPARM command always displays start parameters with console command modifiers. 2) Some console commands (MON TAP blank) are treated as ALLON when error message should be generated. 3) Most console subsystem enhancements affect the CONSHELP module when they should not. |
| 2300160 | 10-22-2005 | GATEFC/GATE | OBJ |
1) HALT AT LOC stor-addr IN XOTFCDC : INV FC VCLCST for GATEFC
sessions. 2) Gate alert message issued without NASnnnni prefix. |
| 2300159 | 10-13-2005 | LLC5 (PAD) Set&Read X29 |
OBJ |
HNAS uses SET & READ packet to send parameters to an X.25 PAD (NPSI uses SET). |
| 2300158 | 10-13-2005 |
ALL LLCs Bracket States |
OBJ | HNAS incorrectly rejects PIU with SENSE=2003 (bracket error). |
| 2300157 | 10-11-2005 |
QLLC Bid processing |
OBJ | QLLC session hangs when BID response from remote device is not sent to the PLU. NAS7601W alert message with RC=0C may also be issued. |
| 2300156_E | 09-29-2005 | Cons-Subsystem VARY LCL|RMT ACT|INACT <Enhancement> |
OBJ/SRC | Enhancement to improve the lack of symmetry in the way 'V LCL OFF' and 'V RMT OFF' operate with regard to closing active REMOTE sockets. Force operand now provided. |
| 2300155_E | 09-09-2005 | Cons-Subsystem DRMT|MRMT MON TAP (MONTAP)<Enhancement> |
OBJ/SRC |
1) DRMT does not display and MRMT will not modify TAP= operand if it omitted or specified as TAP=0 in CDF. 2) New MON TAP console command (MONTAP start parameter) enhancement generates NAS251xM monitor messages permitting monitoring of TAPping (XOT Keep Alive) processes without having to run TCPIP traces. |
| 2300154 | 08-31-2005 | PCNE/GATE/PAD CDF/CNFG | OBJ | Error introduced with APAR 2300138 causes an invalid array index to be displayed when an error is detected in the SVC0=, SVC4= and/or SVC5= operands. |
| 2300153_E | 08-30-2005 | Cons-Subsystem TRCMCH ICLR|OCLR <Enhancement> |
OBJ/SRC | TRCMCH ICLR|OCLR enhancement implemented to generate NAS7795T inbound|outbound clear trace messages for all clear packet activity. |
| 2300152_E | 08-23-2005 | PAD
(LLC5) Translate Tables <Enhancement> |
OBJ/SRC |
1)
HNAS has been modified to accept additional TRAN= operand values that
allows standard NPSI translate tables to be used instead of the HNAS
default tables which were built from the NAS37xx product. TPE
applications appear to require native NPSI translate tables. 2) MRMT command now accepts the original as well as the new TRAN= operand values allowing 'on the fly' translate tables type reassignment. |
| 2300151_E | 08-16-2005 | PVC
Support Improvements <Enhancement> |
OBJ/SRC |
1) Revised HNAS PVC Setup Status Codes improving router
PVC Setup retry (general improvement). 2) New and improved PVC trace records via TRCMCH OCR|ICR. 3) New alert messages improve PVC status reporting. 4) Resets 029/115 & 001/000 (network/link out-of-order) received by HNAS now reported to the PLU via NOTIFY. 5) DVC display now provides PVC session Setup state. |
| 2300150 | 08-09-2005 | TCPIP Interface, BIND Processing | OBJ/SRC | LOCAL IPADDR/PORT BIND processing can take an unusually long time (minimally 5 minutes) to complete if a BIND failure occurs. |
| 2300149 | 08-03-2005 |
Start Parameter Display (DPARM) |
OBJ/SRC | DPARM console command incorrectly displays PRNTON followed by PRNTOFF at SYSCONS operator console when SHOWCONS is active and PRNTOFF is in effect. |
| 2300148 | 08-03-2005 | HNAS Trace Support | OBJ | LU, MCH, MCHX and/or VC tracing is reset if an invalid argument is provided after the TRCLU, TRCLUQ, TRCMCH, TRCMCHQ, TRCVC or TRCVCQ commands, respectively. |
| 2300147 | 07-25-2005 |
QLLC PVC/SVC Support |
OBJ | NASHALT (0198 ABEND INV LU) can occur when HNAS schedules a PVC Setup packet for a QLLC PVC or a Call Request packet for a QLLC SVC and the router connection is down. |
| 2300146 | 07-19-2005 |
VTAM - LLC0, LLC4 and LLC5 |
OBJ | BIND can be rejected with SENSE=08210C0F. |
| 2300145 | 06-30-2005 |
QLLC, VTAM SESSLIM=YES |
OBJ | NAS4704W ACTIVE LU lu-nm REJECTING NEW BIND (0C000000) alert message issued when BIND queued by session manager is delivered to HNAS. |
|
2300144 +_E |
06-29-2005 |
VTAM, IMS <Enhancement 2)> |
OBJ/SRC |
1) HNAS IMS LLC0 session aborts when HNAS rejects PLU request PIU with 0813
sense. 2) NAS3705W message added. |
| 2300143 | 06-29-2005 | GATE | OBJ |
Hung resource, GATE data session LU not available for new calls. |
| 2300142 | 06-28-2005 |
GATE FTAM sessions |
OBJ | FTAM sessions ending with DIAG=221 (DD) indicating that a CTCP did not UNBIND after receiving a clear or clear confirm from HNAS. The ending is triggered by a 3 second HNAS timer. |
| 2300141 | 06-20-2005 | QLLC VTAM | OBJ | NASHALT (0198 ABEND) can occur when ACTLU Power On is received because XMT RPL is busy executing a previous SETLOGON request when a new SETLOGON is attempted. |
| 2300140 | 06-14-2005 | VTAM | OBJ/SRC | LU session hangs (data not sent to PLU) after SIGNAL. |
| 2300139_E | 06-13-2005 | CDF/CNFG 1) PARM= decode 2) FASTRUN AMNF <Enhancement> |
OBJ/SRC |
1) AMNF generated during FASTRUN even though RC=8. 2) Blank value after PARM= and before intended startup parameters prevents user defined values from being used during HNAS initialization. |
| 2300138_E | 06-10-2005 | CDF/CNFG SVC0=,SVC4= and SVC5= SLUnames <Enhancement> |
OBJ |
The SVC0=, SVC4= and SVC5= operand processors have been modified to generate SLU names based on a prefix text value, suffix start value and count value defined as the first, second and third operand entry, respectively. |
| 2300137 | 06-08-2005 | QLLC (LLC3) USSMSG | OBJ | Garbage data can be sent at the end of a large USSMSG for a QLLC resource. |
| 2300136 | 05-19-2005 | QLLC | OBJ |
1) NASHALT in QLALOG subroutine in QLSSCP module due to a bug
that surfaced during an unusual timing sequence. 2) XFRUDC can reject INIT-SELF or TERM-SELF PIUs. |
| 2300135 | 05-19-2005 | TAP | OBJ/SRC | Consecutive TAP Keep Alive failures do not detect lost contact with a router. |
| 2300134 | 05-19-2005 | PVC | OBJ | PVC IMS application regularly getting calls reset with DIAG=219 (X'DB') when HNAS receives -RSP from the PLU. |
| 2300133 | 05-18-2005 |
CDF/CNFG PVC/SVC |
OBJ |
1) NASHALT can occur when many PVCs are configured. 2) NAS1730I REMOTE SVCi PROCESSED message issued even when SVCi=NONE or is omitted. |
| 2300132 | 05-12-2005 | CDF/CNFG APPLNAME/LOGAPPL. | OBJ | Configuration error message NAS1041W erroneously generated when APPLNAME= and LOGAPPL= are specified during FASTRUN processing. |
| 2300131 | 04-28-2005 | ALL, MCH Timer | OBJ | System 0C1 ABEND can occur during unusual timer error recovery processing. |
| 2300130 | 04-25-2005 | Cons-Subsystem MRMT SVC3 |
OBJ |
1) System 0C4 ABEND can occur when attempt is made to modify an
SVC3= operand entry. 2) Unable to change SVC3=NONE to SVC3=ALLOW so that QLLC support can be activated for an MCH. |
| 2300129 | 04-23-2005 |
GATE PFXDCEADDR |
OBJ | System 0C4 ABEND in MCHRSBF routine (MCHBFR module) when OPTIONS=PFXDCEADDR used and GATE CTCP provides an invalid call request packet with no called/calling address lengths byte. |
| 2300128 | 04-21-2005 | PVC | OBJ |
1) PVC ses ends with NAS3799I,
CAUSE/DIAG=000/143 (00/8F) 2) PVC ses does not restart after TCP/IP disconnect, NAS5704W, CAUSE/DIAG=000/242 (00/F2) issued. 3) PVC ses ended by RESET CAUSE/DIAG=0F/00 causes NAS3799I, CAUSE/DIAG=000/216 (00/D8) DIAGX=0005 (incorrect CAUSE/DIAG) |
| 2300127 | 04-19-2005 | GATE Callout | OBJ | Alert message: NAS4702W TIMER RELEASED IDLE LU lu-nm condition. |
| 2300126 | 04-07-2005 | Cons-Subsystem CLG|CLDADDR= modifier (Ping) |
OBJ | 0C1 ABEND can occur when 15 digit CLGADDR= or CLGADDR= modifier is entered explicitly or via 'Ping dteaddr'. |
| 2300125_R | 04-06-2005 | Cons-Subsystem DNAS DISP= |
N/A - Refresh Required. |
The DNAS command displays DISP=SMP/E for non-SMP/E distributions created after 02-24-2005. |
| 2300124 | 03-28-2005 | TCPIP | SRC | VC disconnect due to a TCPIP socket close can have an inconsistent CAUSE/DIAG=00/F2 or 00/C3 code. |
| 2300123_E | 03-28-2005 | Cons-Subsystem Vary ID= socket <Enhancement> |
OBJ/SRC | The VARY console command has been enhanced to allow single or multiple sockets to be manipulated in addition to the existing remote level support. |
| 2300122 | 03-21-2005 | QLLC | OBJ/SRC |
1) REQDISCONT and NMVT PIUs are rejected with NAS8141W message followed by a Clear Request. 2) ACB OPEN will fail when INIT-SELF arrives for an SLU that is configured to be ACQUIREd. 3) INIT-SELF(0) and TERM-SELF(0) PIUs are being rejected. 4) INIT-SELF(1) and TERM-SELF(1) PIUs are being rejected. |
| 2300121_E | 03-10-2005 |
Maintenance <Enhancement> |
SRC | Some customers would like extended change control information provided in all macro/source updates because ISPF change control is not available. |
| 2300120 | 03-10-2005 | Cons-Subsystem MRMT/DRMT |
OBJ | D23-10040007 ABEND occurs during DRMT display after multiple DTE addresses were added via the MRMT command. |
| 2300119 | 03-08-2005 | TCPIP | SRC |
1) 0C4-10 ABEND can occur in the client TCPIP SELECT timeout
processor due to bad base register. 2) The internally generated Clear that HNAS generates when a socket connection is lost erroneously uses a non-zero cause code (09). |
| 2300118_E | 03-04-2005 | PVC
and LU Bind Failures <Enhancement> |
OBJ |
1) Enhancement to issue an information message when a
PVC resource is bound. 2) Enhancement to issue an alert message and VTAM sense code when a BIND from a PLU is rejected. |
| 2300117 | 03-04-2005 |
Cons-Subsystem Remote Console |
OBJ | Remote console VC is randomly cleared while executing some display commands (like DMAP NASTCP) due to a bug in the output scheduler when the windowsize is 7. |
| 2300116 | 03-03-2005 | QLLC | OBJ/SRC |
1) SPU call rejected because the SPU is already in use.
OPTIONS=REUSEBSYSPU developed for this condition. 2) SPU QXID request timing out condition. 3) INIT-SELF that is received before ACTLU response is being processed when it should be rejected. |
| 2300115 | 03-01-2005 | QLLC | OBJ | QLLC session ends unexpectedly with DACTLU and a VTAM RECEIVE failed message in SYSPRINT. |
| 2300114 | 03-02-2005 |
Install under OS/390 (HLASM) |
OBJ/SRC | NASMAIN and NASTCP assembler steps can end with CC=12 when using the older high level assembler (HLASM). |
| 2300113 | 02-25-2005 |
Cons-Subsystem LNCT=n, DPARM |
OBJ |
1) Setting the remote HNAS console LNCT=n to 1 can cause
remote console input to be rejected. 2) DPARM command display output can contain a {box} character at the end of some display lines. |
| 2300112_R,E | 02-25-2005 | Cons-Subsystem
DNAS Display <Enhancement> |
N/A - Product Refresh Required. |
Enhancement to DNAS command display output to better identify whether a distribution was created using SMP or non-SMP or if a custom MACLIB and/or OBJLIB was required for the distribution. <This enhancement APAR is only available via a product refresh or upgrade.> |
| 2300111 | 02-22-2005 | PVC | OBJ | PVC session can fail to reactivate (see NAS5705W) when the host application is taken down and reactivated. |
| 2300110_E | 02-21-2005 | Cons-Subsystem
Trace Services <Enhancement> |
OBJ/SRC | TRCALL OFF command does not stop MCH tracing which can cause confusion (update to operate as TRCALL STOP), add new TRCPCE command and consname TRC alarm message field. |
| 2300109 | 02-17-2005 | QLLC | OBJ/SRC | QLLC SLU BIND can be rejected with 0815 sense (function active) due to an unusual timing condition. Alarm message NAS3799I issued. |
| 2300108 | 02-15-2005 |
SMP/E Install or Maintenance Assemblies |
SRC | SMP/E assembly of the NASMAIN and NASTCP macros result in assembler return code of 4 instead of 0 which can cause unnecessary concern for users. |
| 2300107 | 02-10-2005 | PVC Connect Out |
OBJ/SRC | PVC session fails to activate (see NAS7704W/NAS7707W) when HNAS initiates the PVC Setup with packet and window size values that don't match the network requirements. |
| 2300106 | 02-10-2005 | Cons-Subsystem MRMT
SVC0/SVC5 dteaddr/Xidnum |
OBJ | Logic introduced by enhancement APAR 2300083 which allows the SVC0= and SVC5= operands to specify SLUs as callin (I) or callout (O) and twoway (T) causes errors (NASC522E)during CDF and MRMT processing. |
| 2300105 | 01-31-2005 | Cons-Subsystem MRMT LLC0/LLC5 | OBJ | When a MRMT (modify remote) command is used to change an LLC5/LLC0 resource from callout to callin, the modified resource may no longer be useable and may also terminate abnormally with an ABEND 0198 (NASHALT) Alert 'NAS0106S BUFFER=bfr-addr RELEASE REJECTED' condition. |
| 2300104 | 01-24-2005 | LLCn Outbound Call Request Processing | SRC | Callout requests randomly fail, NAS7720W alarm message is issued for this unusual timing problem. |
| 2300103 | 01-19-2005 | LLC5 (PAD) | OBJ |
Reset packets sent by router when HNAS sends invalid P(R) packet during unusual PAD X.3 Q packet exchange. |
| 2300102 | 01-17-2005 |
LLC3 (QLLC) QXID alarm message process |
OBJ | NAS8101W, NAS8102W, NAS8103W and NAS8104W alarm message IDs erroneously changed to a common ID of NAS8201W. |
| 2300101 | 01-13-2005 | Cons-Subsystem DLU | OBJ | HNAS DLU console command does not correctly display QLLC SLUs when RNM=mchname is specified. |
| 2300100 | 01-12-2005 | LLC0/LLC5 PVC Configuration | OBJ | Default PVC= applid value is not being set to 255 (ACQUIRE) when omitted, can cause configuration error message 'NAS1311W ...' to be generated. |
| 2300099 | 01-11-2005 |
LLC3 (QLLC) DRMT or DLU Console Commands |
OBJ |
0C4-10 ABEND can occur when DRMT or DLU is used to display the SLUs for a QLLC SPU. |
| 2300098 | 01-07-2005 | TRCPRNT Processing | OBJ | NAS0210W/NAS0211I TRACE SYSPRINT LOGGING ENABLED/DISABLED messages are not always displayed at SYSCONS. |
| 2300097 | 01-07-2005 |
LLC3 (QLLC) ACTLU Processing |
OBJ | ACTLUs fail with 8004 sense (Unrecognized Destination Address) when SLU is defined in CDF but not in the remote SPU. |
| 2300096 | 01-07-2005 | LLC3 (QLLC) USSMSG Processing | OBJ | Unusual USSTAB logon problem, see problem description. |
| 2300095 | 01-04-2005 | LLC0
(PCNE) CALLOUT CUD= |
OBJ | Application interprets initial exchange data as invalid when LLC0 (PCNE) callout session contains LLC5 (PAD) default CUD= value of 01000000 instead of C0000000. |
| 2300094 thru 2300000 | <Link back> | - | - |
HNAS V2R3M0 - 2004 MAINTENANCE SUMMARY (Link to APARs 2300094 thru 2300000) |
| - | - | - | - | - |
| 230nnnn_i | mm-dd-yyyy |
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.
12-28-2005 - APAR 2300173 (was problem 2005328D and 2005349A)
APAR: 2300173
STATUS: CLOSED
OPEN_DATE: 11-24-2005 for 2005328D
12-15-2005 for 2005349A
CLOSE_DATE: 12-28-2005
SERVICE(S): TAP (XOT Keep Alive) configuration and runtime
MANDATORY: NO, but recommended
ORIGIN/REF: 230_CSP, 230_CPT
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 2300173.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300170, 2300155, 2300095, 2300071
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): CNFGCUD, CNFGDCAD, CNFGDTAD, CNFGFAC, CNFGTAP
SOURCE(S): NASTCP
PROBLEM1: NAS2502E can occur when TAP=10 is enabled during
callout session testing.
PROBLEM2: NAS1301D default messages are being generated when
the CUD=, DCEADDR=, DTEADDR= and/or FAC= operands
are omitted and TAP=0 is in effect for a TYPE=XOT
REMOTE.
DESCRIPTION1: TAP appears to be working most of the time when
TAP=10 is specified (the minimum) but has failed
at one customer site because the TAP response
interval of TAP/2 (=5) was not long enough for
the TAP response to be returned (their router
test environment had excessive response delays
causing TAPping error recovery conditions:
NAS2501W ROUTER KEEP ALIVE FAILURE
NAS2502E ROUTER CONTACT LOST
DESCRIPTION2: When TAP=0 is specified or is set by default, the
absence of the CUD=, DCEADDR=, DTEADDR= and/or FAC=
operands should be ignored. Due to logic added by
APAR 2300155, the missing TAP operands are flagged
even though TAPping is turned off.
SOLUTION1: HNAS has been modified to force TAP response timer
to be the same as TAP request timer which can have
a minimum value of 10 seconds. We recommend a
TAP=value between 60-120.
SOLUTION2: The configuration process has been modified to
withhold TAP configuration default messages when
TAP=0 is in effect.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-23-2005 - APAR 2300172 (was unpublished problem 2005328C)
APAR: 2300172
STATUS: CLOSED
OPEN_DATE: 11-24-2005
CLOSE_DATE: 12-23-2005
SERVICE(S): GATE
MANDATORY: RECOMMENDED
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 2300172.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 06-28-2005
With APARs: 2300142 applied.
SUPERSEDES: N/A
OBJECT(S): MCHNRQC
SOURCE(S): N/A
PROBLEM: HNAS time interval when waiting for GATE PLU to UNBIND
can be 3 seconds when 10 seconds is the correct value.
DESCRIPTION: When APAR 2300142 (changes wait for UNBIND GATE timeout
from 3 to 10 seconds) was developed a path using the 3
second value was overlooked. The path is seldom used
and the error has not been reported.
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).
12-21-2005 - APAR 2300171
APAR: 2300171
STATUS: CLOSED
OPEN_DATE: 12-21-2005
CLOSE_DATE: 12-21-2005
SERVICE(S): GATE (non Fast Connect)
MANDATORY: YES
ORIGIN/REF: 220_BBK
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 2300171.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 08-30-2005
With APAR: 2300153 applied.
SUPERSEDES: N/A
OBJECT(S): XOTGTDC
SOURCE(S): N/A
PROBLEM: HALT AT LOC addr IN XOTGTDC INV VCLCST
DESCRIPTION: HNAS logic error creates a situation where HNAS
believes that the logical channel is inconsistent
with the GATE data session LU state. The error is
triggered when there is a delay between scheduling
of an XOT call accept packet and the completion of
the TCP send operation that indicates the packet
has been delivered to the network.
SOLUTION: HNAS logic corrected.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-21-2005 - APAR 2300170 (was problem 2005321A)
APAR: 2300170
STATUS: CLOSED
OPEN_DATE: 11-17-2005
CLOSE_DATE: 12-21-2005
SERVICE(S): TCP/IP interface support
MANDATORY: YES
ORIGIN/REF: 230_CCS
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 2300170.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300162 and all associated APAR PreReq chains
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: NASHALT U198 ABEND when HNAS is running and the TCP/IP
Stack is forced down.
DESCRIPTION: INITAPI is being rejected with erno=1036 and a subsequent
NASHALT results after successful GETIBMOPT request that
indicates that stack is up.
The INITAPI erno=1036 says 'TCP/IP is not installed'.
INITAPI will not be executed unless GETIBMOPT shows that
named stack is installed and active. Since the GETIBMOPT
in this case showed the stack to be active, the INITAPI
failure should not have occurred. The NASHALT results
because the successful GETIBMOPT and the failed INITAPI
are mutually exclusive. Normally, if the stack is down,
the GETIBMOPT will show this and will be retried after a
1-minute forced delay. This will continue indefinitely
until the stack comes up so that the INITAPI can then
be attempted.
CIRCUMVENTION: N/A
SOLUTION: HNAS has been modified to treat the INITAPI failure
with erno=1036 like a GETIBMOPT that shows that the
stack is down to prevent the ABEND. However, a real
fix would be to determine why the GETIBMOPT showed that
the stack was up when, in fact, it appears to be down
due to the INITAPI failure.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-19-2005 - APAR 2300169 (was problem 2005157A)
APAR: 2300169_E
STATUS: CLOSED
OPEN_DATE: 06-06-2005
CLOSE_DATE: 12-19-2005
SERVICE(S): Start parameter default change: USEMDFY
MANDATORY: NO
ORIGIN/REF: 230_ECI
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 2300169.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300167
and their associated APAR chains
OBJECT(S): CONSDPRM
SOURCE(S): NASMAIN, XFNASWA
PROBLEM: HNAS WTOR console interface default is outdated
and causes the majority (if not all users) to
override with the USEMDFY start parameter.
DESCRIPTION: Historically, WTOR has been the default interface
for HNAS console input. When no PARM= values are
specified, HNAS will use WTOR and the system will
reject commands entered via the MODIFY interface
(e.g., /F hnas,command).
SOLUTION: HNAS has been updated to make USEMDFY a default
start parameter and by extension the MODIFY
interface as the default method for console
input. USEMDFY OFF or USEWTOR {ON} is
required to force use of the WTOR interface.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-16-2005 - APAR 2300168
APAR: 2300168_E_R
STATUS: CLOSED
OPEN_DATE: 12-14-2005
CLOSE_DATE: 12-16-2005
SERVICE(S): Console, DNAS command display support
MANDATORY: NO, but recommended
ORIGIN/REF: 230_CPT
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX
PTF_LOC: Refresh required
COREQ(S): N/A
PREREQ(S): 2300163, 2300162
and their associated APAR chains
OBJECT(S): CONSDNAS
SOURCE(S): XFBLK
PROBLEM: DNAS displays the HOST parameter from NASMAIN assembly
but not the version of the system that HNAS is running
under.
DESCRIPTION: The DNAS display shows (among other things), the HNAS
version (e.g., V2R3M0), distribution type (SMP/E or
NON-SMP), CONSDNAS module assembly date and the HOST
system type for the NASMAIN assembly. However, DNAS
does not display the real HOST type and version level
that HNAS is actually running under.
SOLUTION: HNAS has been modified to display the real HOST name
and version level by extracting this information from
system's nucleus. The STARTED time and date field
was also added so that execution start information
is provided in the DNAS output. The DNAS display
will now appear as follows:
changed ----> VERSION=V2R3M0 DIST=NON-SMP ASMDATE=12/16/05 ASMHOST=ZOS
new --------> RUNNING UNDER z/OS 01.04.00
new --------> STARTED AT 10:54:50 ON 12/16/2005
CREATED AT 10:11:31 ON 12/16/2005
CREATED WITH MAINTENANCE THROUGH APAR 2300168
MOST RECENT MAINTENANCE APPLIED IS APAR 2300168
SHIPID=9999999999999999 AUTH=00
moved ------> CUSTMAC=COMM1.TEST.HNASMAC
moved ------> CUSTOBJ=COMM1.TEST.HNASOBJ
new blank -->
APARID MODULE (MAINTENANCE STATUS)
ALL MAINTENANCE ON THROUGH MOST RECENT APAR 2300168
Note: In this example the product was generated and
installed on the same date. The 'CREATED AT'
date and ASMDATE date are normally the same
because the CONSDNAS module is assembled as
part of the distribution creating job.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-13-2005 - APAR 2300167 (was problem 2005088A)
APAR: 2300167_E
STATUS: CLOSED
OPEN_DATE: 03-29-2005
CLOSE_DATE: 12-13-2005
SERVICE(S): Console, QLLC alarm display support
MANDATORY: NO, but recommended
ORIGIN/REF: 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 2300167.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300165, 2300163, 2300161
and their associated APAR chains
OBJECT(S): CONSDPRM, CONSPRNT, NASUTIL
SOURCE(S): NASMAIN, XFNASWA
PROBLEM: Customer would like PRNTQLLC feature (like PRNTVC OFF)
to restrict NAS8xxxx messages.
DESCRIPTION: Currently, QLLC messages of the form NAS8xxxx are
controlled by the PRNTVC option which also controls
NAS5xxxx and NASAxxxx messages. This means that
the only way to eliminate NAS8xxxx messages without
also eliminating NAS5xxxx and NASAxxxx messages from
SYSPRINT is to specify ALRMFLTR=(...,NAS8****(P),...)
on the BUILD definition statement.
SOLUTION: HNAS has been modified to accept PRNTQLLC {ON|OFF} as
a start parameter and PRNT QLLC ON|OFF as a console
command so that NAS8xxxx messages can be allowed or
filtered from the HNAS log file independently from
standard VC alarm messages.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
12-02-2005 - APAR 2300166 (was problem 2005325A)
APAR: 2300166
STATUS: CLOSED
OPEN_DATE: 11-21-2005
CLOSE_DATE: 12-02-2005
SERVICE(S): PVC
MANDATORY: YES
ORIGIN/REF: 230_HVB
CPTECH: PRT
PTF_CLASS: STANDARD-APAR, refresh required if 2300161 not on.
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300166.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 10-26-2005
With APAR: 2300161 applied.
SUPERSEDES: N/A
OBJECT(S): VCCLRQ
SOURCE(S): N/A
PROBLEM: HNAS U198 ABEND with the message:
HALT AT LOC addr IN VTMRSPC : BFR REQ'D
DESCRIPTION: This HALT is a result of a validity check in HNAS
VTAM RECEIVE logic. The problem occurs because of
an unusual timing problem related to the operation
of PVC sessions. When a PVC session is unbound
with a receive operation active a flag is not
reset to indicates that the VTAM session is over.
When the PVC session is restarted the validity
check occurs.
SOLUTION: HNAS PVC 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).
11-29-2005 - APAR 2300165 (was problem 2005320A)
APAR: 2300165
STATUS: CLOSED
OPEN_DATE: 11-16-2005
CLOSE_DATE: 11-29-2005
SERVICE(S): Console, DPARM display and TRCtyp followers.
MANDATORY: NO, RECOMMENDED.
ORIGIN/REF: 230_BNP
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 2300165.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300163, 2300161
OBJECT(S): CONSDPRM
SOURCE(S): NASMAIN
PROBLEM: Customer reports that DPARM trace parameter display
can be confusing as related to TRCtyp followers.
DESCRIPTION: Confusion results from the fact that when the same
trace flag is manipulated by an equivalent console
command using the ALLON|ALLOFF arguments, the
DPARM display shows ON|OFF instead of ALLON|ALLOFF.
For example, when TRCMCH ALLON is entered followed
by DPARM, the DPARM display for TRCMCH is ON
instead of ALLON.
SOLUTION: The DPARM display processor has been modified to
display ALLON or ALLOFF for those trace parameters
that have an equivalent console command that
accepts the ALLON and ALLOFF arguments.
In addition, ALLON and ALLOFF will now also be
accepted as followers for the TRCLU, TRCVC, TRCMCH,
TRCMCHX, TRCBFR, TRCDATA, TRCDISP and TRCIO start
parameters and will be treated identically to the
ON and OFF followers which are currently supported
in the PARM= operand.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
11-29-2005 - APAR 2300164
APAR: 2300164
STATUS: CLOSED
OPEN_DATE: 11-29-2005
CLOSE_DATE: 11-29-2005
SERVICE(S): Console Subsystem, TRCPCE ALLON|ALLOFF command
MANDATORY: NO
ORIGIN/REF: 230_CPT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300164.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300161 and all associated APAR chains.
OBJECT(S): CONSTPCE
SOURCE(S): N/A
PROBLEM: TRCPCE ALLON|ALLOFF manipulates all global trace
flags not just PCE trace flags.
DESCRIPTION: All global trace flags (PCE, LU, MCH, MCHX and VC)
are turned on by ALLON and off by ALLOFF. Need
to exclude LU, MCH, MCHX and VC trace flags from
ALLON|ALLOFF logic.
SOLUTION: The TRCALL command processor has been modified to
exclude LU, MCH, MCHX and VC trace flags from the
global ALLON|ALLOFF requests. Only PCE trace flags
will be manipulated.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
11-18-2005 - APAR 2300163 (was problem 2005312A)
APAR: 2300163
STATUS: CLOSED
OPEN_DATE: 11-08-2005
PRVCHG_DATE: 11-15-2005
CHANGE_DATE: 05-05-2006 - WTOROUTCDE addeded to service description.
CLOSE_DATE: 11-18-2005
SERVICE(S): Netview alarm message processing - WTOROUTCDE
MANDATORY: YES if alarm messages are to be routed to NETLOG
but not to SYSLOG
ORIGIN/REF: 230_CEC
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 2300163.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300162, 2300161, 2300155, 2300152, 2300116
OBJECT(S): CNFGOPTS, NASCNFG, NASUTIL
SOURCE(S): NASMAIN, XFBLK, XFGBLS, XFIDR, XFNASWA
PROBLEM: Customer reports that he is unable to route HNAS alarm
messages (unsolicited/asynchronous WTOs) to the NETLOG
instead of the SYSLOG.
DESCRIPTION: Customer has tried using the Netview ASSIGN command as
recommended by Comm-Pro but this does not seem to work.
ASSIGN MSG=NAS*,PRI=OPER1
ASSIGN MSG=NAS*,COPY=OPER1
This requires that OPER1 be defined as a Netview console
and that SHOWON or SHOWERR option is active. We suspect
that the ASSIGN failed because they used the example in
Appendix D of the HNAS documentation and OPER1 was not
defined as a console. Netview consoles are defined in
the DSIOPF member of the NETVIEW.DSIPARM dataset. Most
sample versions of DSIOPF have OPER1 defined but this
can be changed by the customer.
Customer also tried modifying the Netview automation
table as follows which did work and allowed HNAS alarm
messages to go to NETLOG. The problem is that the same
alarms also go to SYSLOG which they do not want.
IF MSGID= 'NAS' . THEN
BEGIN;
ALWAYS
DISPLAY(Y) NETLOG(Y) SYSLOG(N)
END;
SYSLOG(N) should have prevented alarms from getting to
SYSLOG. We have determined that the reason that all
HNAS alarms are going to NETLOG and SYSLOG is because
SYSLOG is defined as a HARDCOPY console where messages
are logged before they can be filtered by the Netview
automation table where SYSLOG(N) is specified.
This is occurring because all HNAS WTOs use ROUTCDE=8
(teleprocessing control) which cannot be omitted from
HARDCOPY routing.
SOLUTION: HNAS has been modified accept a WTO routing code as a
configurable option. The BUILD definition statement
now supports the following new options:
OPTIONS=(...,WTOROUTCDE(ALRM)=value, <- for alarm WTOs
WTOROUTCDE(CONS)=value, <- for console WTOs
--- or ---
OPTIONS=(,...WTOROUTCDE=value,...) <- for both
For example, to prevent alarm messages from going to
SYSLOG, do the following:
1) Specify OPTIONS=WTOROUTCDE(ALRM)=11 (programmer
information) on the BUILD definition statement.
2) Change the ROUTCODE parm in the SYSLOG HARDCOPY
section of the CONSOLxx member in SYS1.PARMLIB
to exclude routing code 11. For example, from
ROUTCODE(ALL) to ROUTCODE(1-10,12-128). This
will required an IPL.
To temporarily modify the HARDCOPY routing until
the next system IPL, use the VARY command as
follows:
VARY SYSLOG,HARDCPY,DROUT=(11)
Note: When SHOWCONS is in effect, console output
will always be routed to the HARDCOPY device
because the output is marked as a response.
The only way to prevent this and allow a
response to be filtered by routing code is
to specify CMDLEVEL(NOCMDS) for the HARDCOPY
device. However, it may not be possible to
use the NOCMDS option in all environments.
For more information, please refer to the
discussion of the CONSOLxx member in the
MVS Initialization and Tuning Reference
(SC28-1752).
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
10-28-2005 - APAR 2300162 (related to APAR 2300108)
APAR: 2300162_R
STATUS: CLOSED
OPEN_DATE: 10-27-2005
CLOSE_DATE: 10-28-2005
SERVICE(S): SMP/E Distribution, installation processing
MANDATORY: YES
ORIGIN/REF: 230_CPT
PTF_CLASS: STANDARD-APAR.
PTF_TYPE: (OBJ) HNASOBJ and (SRC) HNASMAC (refresh required)
PTF_LOC: N/A - Product refresh required for this correction.
COREQ(S): N/A
PREREQ(S): N/A (refresh required)
OBJECT(S): CONSDNAS
SOURCE(S): NASMAIN, NASTCP, XFIDR, XFGBLS
PROBLEM: The NASMAIN & NASTCP assembly steps can end with CC=4
instead of CC=0 during SMP/E install processing.
DESCRIPTION: The problem occurs because USING statements for the
assembly steps are treated differently when HOST=OS390
or HOST=ZOS are specified because of differences in
the OS assembler and the HNAS installation assembly
processes between SMP/E and non-SMP/E environments.
History: APAR 2300108 was issued in an attempt to
eliminate the CC=4 error messages in SMP/E
installation environments. Confusion arose
after this APAR because the HOST=ZOS assembly
option parameter was used to bypass (suppress)
the error messages while the HOST=OS390 option
still generated the messages which continued
to cause confusion.
SOLUTION: The logic was revised to eliminate the CC=4 condition
regardless of the HOST=OS390|ZOS value.
The HNASRCV JOB was modified to use HOST=ZOS as the
default ASSEMBLY parameter because almost all HNAS
users are now running under Z/OS. Existing OS/390
users can continue to use HOST=OS390 as instructed
in the HNASRCV job.
The DNAS command has been modified to display the
HOST= operand from the NASMAIN assembly instead of
HOST=OS390|ZOS to properly reflect the real operating
system environment.
CIRCUMVENTION: Specifying HOST=ZOS in the SMPAMAIN and SMPATCP
files causes the XFIDR macro for the NASMAIN and
NASTCP assemblies to set USING limits (for example,
USING (TCPCLS,TCPCLSND),RBASE) which restricts the
USINGs so that they do not overlap and thus prevents
assembler warning messages that set CC=4.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
10-26-2005 - APAR 2300161 (was problem 2005091A and 2005256A)
APAR: 2300161+_E_R
STATUS: CLOSED
OPEN_DATE: 04-01-2005 (2005091A)
09-13-2005 (2005256A)
CLOSE_DATE: 10-26-2005
SERVICE(S): Console Subsystem, commands & modifiers
MANDATORY: NO
ORIGIN/REF: 230_CPT
PTF_CLASS: STANDARD-APAR and ENHANCEMENT-APAR.
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX
PTF_LOC: N/A - Product refresh required for this correction.
COREQ(S): N/A
PREREQ(S): 2300156, etc (too many to list)
Note: Due to the large number of PreReqs, we
require a product maintenance refresh
to pick up this APAR.
OBJECT(S): CONSxxxx (all), NASCONS
SOURCE(S): XFBLK, XFXTRN
PROBLEM1: DPARM command always displays start parameters
with console command modifiers.
PROBLEM2: Some console commands (MON TAP blank) are treated
as ALLON when error message should be generated.
PROBLEM3: Most console subsystem enhancements affect the
CONSHELP module when they should not.
DESCRIPTION1: Would like the ability to list console command
modifiers without start parameters when 'DPARM
MODIFIERS' is entered. This provides symmetry
with the 'DPARM EXEC' command which lists start
parameters without command modifiers.
DESCRIPTION2: For the case when MON TAP is entered without a
follower, ON is assumed. When RNM= is omitted
and ID=0, the MON TAP flag is set in all PCEs.
That is why 'M' appears in the DPCE display.
The use of ID=0 for all PCEs predates the
addition of RNM=. This is an unwelcome side
affect of ID=0 but it is well documented in
the console section. ID=0 must be treated
differently than ID= omitted so that a console
error message can be issued when ID= is not
initialized. Note that in the case of MON TAP,
an error message should be issued when RNM= and
ID= are both omitted. RNM= omitted and ID=0
should start TAP monitoring for all tapping
REMOTEs. In this case, the user has entered
ID=0 so there is no ambiguity to it's intent.
DESCRIPTION3: Many console enhancements require the addition of
or change to command arguments. This requires
updating to the command's HELP text. Since all
HELP text is contained in the CONSHELP module, it
necessarily also must be updated.
SOLUTION1: The DPARM command processor has been modified to
'MODIFIERS' as an argument so that the display can
be restricted to command modifiers only. Invoke
'DPARM MODIFIERS'. This will allow users to
quickly view all command action/display parameters.
Z230ZOS0> dparm modifiers
COMMAND MODIFIERS FOLLOW
CID=
CLDADDR=
CLGADDR=
ID=
IFN=
IPADDR=
LNM=
LNCT=0023
LUN=
LUNM=
RNM=
VCN=
Modifiers that have not been set will be displayed
with null values. Assume that the following command
sequence was entered:
Z230ZOS0> ID=0 CID=1-2 LUN=1-7 LNM=LXOT DPARM MODIFIERS
The following display will be produced.
COMMAND MODIFIERS FOLLOW
CID=00000001-00000002
CLDADDR=
CLGADDR=
ID=0000
IFN=
IPADDR=
LNM=LXOT
LNCT=0023
LUN=01-07
LUNM=
RNM=
VCN=
SOLUTION2: Numeric modifiers like ID= will now be treated as
omitted when they are un-initialized. If zero is
specified for a numeric modifier, it will imply a
request for 'all' related resources. This will
allow HNAS to issue an error message if a command
that requires either ID= or RNM= and both are
omitted (MON TAP for example).
Further, specifying ID=0 will also generate an
error message if a valid ID=value is required for
a command (ID=lo{-hi} VARY for example). For
commands that treat ID=0 as 'all' PCEs, they will
now process all PCEs if ID=0 or ID= (omitted) is
specified. If a zero (0) value is entered for a
numeric modifier, it must be entered as the only
value (0-0 is not permitted).
SOLUTION3: HELP text for all console commands has been moved
from the CONSHELP module to each individual command
processing module. The HELP text is now referenced
by CONSHELP as an external symbol. This means that
when a command modification also requires it's HELP
text to be modified, it can be done in the same
module thus preventing CONSHELP from having to be
updated as well.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
10-22-2005 - APAR 2300160 (was problem 2005276A)
APAR: 2300160
STATUS: CLOSED
OPEN_DATE: 10-03-2005
CLOSE_DATE: 10-22-2005
SERVICE(S): GATEFC (GATE Fast Connect) and GATE
MANDATORY: YES (GATEFC)
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 2300160.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 08-30-2005
With APAR 2300153 applied.
SUPERSEDES: N/A
OBJECT(S): MCHTR , XOTFCDC
SOURCE(S): N/A
PROBLEM1: HALT AT LOC stor-addr IN XOTFCDC : INV FC VCLCST for
GATEFC sessions.
PROBLEM2: GATE alert message issued without NASnnnni prefix.
DESCRIPTION1: HNAS incorrectly processes a CTCP reset packet request
when it arrives at the same time as an inbound reset
packet from the remote. This problem only occurs on
GATE Fast Connect (FC) sessions.
DESCRIPTION2: When HNAS receives an invalid packet from the CTCP a
message like the one shown below can be generated
without a NAS alert header. The message is displayed
only if TRCPRNT ON is set. The message indicates that
HNAS is sending a GATE diagnostic packet to the CTCP.
Most CTCPs silently discard the packet.
lu-name LU 007C8800 SENDING DIAG PKT :FMD INV ON
FC GATE CTL SES BFR NEXT
SOLUTION1: HNAS GATE FC reset logic corrected.
SOLUTION2: When HNAS is sending a diagnostic packet to the CTCP
an alert message with the following form is issued:
NAS4710W lu-nm LU st-addr SENDING DIAG PKT :text
BFR NEXT
Values for 'text' are shown below. BFR NEXT indicates
the buffer that triggered the error is displayed in
SYSPRINT.
text: INVALID CTCP GATE CMD BYTE
HNAS has received an invalid GATE message from a GATE
CTCP control session PLU.
text: FMD INV ON FC GATE CTL SES
HNAS has received an FMD PIU from a GATE FC PLU.
FC GATE control session do not send FMD PIUs.
text: INVALID CTCP DATA SES CMD BYTE
HNAS has received an invalid GATE message from a GATE
CTCP data session PLU.
text: GT FC LN ER
HNAS has received a PIU from a GATE FC PLU that is too
short to be valid.
text: GT DS LN ER
HNAS has received a PIU from a GATE PLU that is too
short to be valid.
The most likely cause of NAS4710W is that the PLU is
not a GATE CTCP.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
10-13-2005 - APAR 2300159 (was problem 2005236A)
APAR: 2300159
STATUS: CLOSED
OPEN_DATE: 08-24-2005
CLOSE_DATE: 10-13-2005
SERVICE(S): LLC-5 (PAD)
MANDATORY: YES
ORIGIN/REF: 230_CUK
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 2300159.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 08-30-2005
With APAR: 2300153 applied.
SUPERSEDES: N/A
OBJECT(S): XOTBXM
SOURCE(S): N/A
PROBLEM: HNAS uses SET & READ packet to send parameters to an
X.25 PAD (NPSI uses SET).
DESCRIPTION: The HNAS SET & READ packet used to send the PADPARM=
parameter string to a remote pad conflicts with NPSI
and causes an extra Q-bit packet (Parameter Indication
is the SET & READ response) to flow at session start.
Transparent PAD users should be aware of the fact that
the extra Q packet was passed to the PLU. With this
APAR on the PLU will no longer see this packet. In a
NPSI environment the packet did not exist so we do not
anticipate problems.
SOLUTION: HNAS corrected to use a SET packet.
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).
10-13-2005 - APAR 2300158 (was problem 2005236B)
APAR: 2300158
STATUS: CLOSED
OPEN_DATE: 08-24-2005
CLOSE_DATE: 10-13-2005
SERVICE(S): ALL, HNAS bracket state management error.
MANDATORY: YES
ORIGIN/REF: 230_CUK
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 2300158.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 10-06-2004
With APAR: 2300078 applied.
SUPERSEDES: N/A
OBJECT(S): MCHLUIN
SOURCE(S): N/A
PROBLEM: HNAS incorrectly rejects PIU with SENSE=2003 (bracket
error).
DESCRIPTION: When a packet is received from the remote and HNAS
is in End Bracket Pending (EBP) state a new bracket
is begun (PIU with Begin Bracket sent to the PLU).
When EBP state ends (response to PIU carrying End
Bracket sent to PLU) the bracket state is set to
between brackets. This means that HNAS is between
brackets and the PLU is in brackets. When the PLU
tries to end the bracket with a PIU carrying End
Bracket, HNAS rejects the PIU with SENSE=2003.
SOLUTION: HNAS logic changed to defer starting a new bracket
when in EBP state.
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).
10-18-2005 - APAR 2300157 (was problem 2005249A/2005252A)
APAR: 2300157
STATUS: CLOSED
OPEN_DATE: 09-06-2005
CLOSE_DATE: 10-11-2005
REVISE_DATE: 10-18-2005 - Problem 2005252A description/reference
(Memo description only) added to this APAR memo.
SERVICE(S): QLLC
MANDATORY: YES
ORIGIN/REF: 230_HVB
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 2300157.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 06-20-2005
With APAR: 2300141 applied.
SUPERSEDES: N/A
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: QLLC session hangs when BID response from remote device
is not sent to the PLU.
10-18-2005 NAS7601W alert message with RC=0C may be issued.
DESCRIPTION: Sniffer traces show that BID response was sent by the
remote. The response is not delivered to the PLU.
When certain conditions are met HNAS can build a buffer
chain where the X25 packet type byte and the TH are
recorded in separate buffers. When this happens, an
incorrect test for the TH end bit leads HNAS to
treat two packets as a part of a segmented TH. This
erroneously combines two PIUs.
10-18-2005 If the combined packets are both FMD then the NAS7601W
alert is issued because of a PIU sequence error (caused
by the HNAS error).
SOLUTION: HNAS logic corrected to properly process the unusual
buffer condition.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
09-29-2005 - APAR 2300156 (related to problem 2005026A)
APAR: 2300156_E
STATUS: CLOSED
OPEN_DATE: 01-26-2005
CLOSE_DATE: 09-29-2005
SERVICE(S): CONSOLE VARY LCL|RMT ENHANCEMENT
MANDATORY: NO
ORIGIN/REF: 230_SIK
CPTECH: SFD
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 2300156.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300155, 2300123
(and associated APAR chains)
Note: Due to the large number of PreReqs, we
recommend a product maintenance refresh
to pick up this APAR if your distribution
is earlier than 2300155.
SUPERSEDES: N/A
OBJECT(S): CONSVARY, CONSHELP
SOURCE(S): NASTCP, XFBLK
PROBLEM: There is a lack of symmetry in the way V LCL OFF and
V RMT OFF operate with regard to closing active REMOTE
sockets.
DESCRIPTION: The V LCL OFF console command closes the LOCAL socket
but not the REMOTE sockets for which the LOCAL is HOME.
The LOCAL is marked offline and stops LISTENing on its
IP address and Port.
The V RMT OFF console command closes all active REMOTE
sockets and marks the REMOTE offline preventing
subsequent outbound connections from being established
and causing subsequent inbound connections to be
rejected. Inbound connections can still occur if the
HOME LOCAL is LISTENing on its socket.
The behavior of these two commands should be consistent
so far as the closure of REMOTE sockets is concerned.
SOLUTION: The VARY console command processor has been modified
to accept the FORCE adverb to be used in conjunction
with the OFF verb.
For V LCL OFF (without FORCE), the LOCAL server socket
is closed and the LOCAL is marked offline but active
REMOTE client sockets associated with the LOCAL remain
active. This is how the command has always worked.
For V LCL OFF FORCE, the LOCAL server socket is closed
and the LOCAL is marked offline and, in addition, all
active REMOTE client sockets associated with the LOCAL
are closed. The REMOTE sockets, however, remain online.
For V RMT OFF (without FORCE), the REMOTE is simply
marked offline. All active REMOTE client sockets
remain active. This is a change in behavior for
this command.
For V RMT OFF FORCE, the REMOTE is marked offline and
all active REMOTE client sockets are closed. This is
the way the command used to work without the FORCE
argument.
Note: ACT and INACT are alternate verbs for ON and OFF,
respectively.
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).
09-09-2005 - APAR 2300155 (was problem 2004253B)
APAR: 2300155_E
STATUS: CLOSED
OPEN_DATE: 09-09-2004
CLOSE_DATE: 09-09-2005
SERVICE(S): CONSOLE, DRMT/MRMT and TAP (XOT Keep Alive) Monitoring
MANDATORY: NO, RECOMMENDED
ORIGIN/REF: 230_SDD
CPTECH: SFD
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 2300155.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300153, 2300152, 2300150, 2300149, 2300135, 2300110
(and associated APAR chains)
Note: Due to the large number of PreReqs, we
recommend a product maintenance refresh
to pick up this APAR.
SUPERSEDES: N/A
OBJECT(S): CNFGTAP, CONSDPCE, CONSDPRM, CONSHELP, CONSMON,
CONSMRMT, NASUTIL
SOURCE(S): NASMAIN, NASTCP, XFBLK, XFNASWA, XFPCE
PROBLEM1: DRMT does not display and MRMT will not modify TAP=
operand if it omitted or specified as TAP=0 in CDF.
PROBLEM2: TAP processing cannot be monitored easily via SYSPRINT.
DESCRIPTION1: When the TAP= operand is omitted or specified as TAP=0,
the associated REMOTE is not marked as a TAPping router
even though a valid IPADDR= and PORT= operand value are
provided. This causes the DRMT command to not display
the null TAP= value and prevents the MRMT command from
allowing the TAP= value to be changed.
DESCRIPTION2: Currently, the only way to 'see' if TAPping is active
and working is to run an HNAS TCPIP trace on the TAP
PCE or looking at a router trace. This can be more
cumbersome than most users are willing to deal with.
SOLUTION1: The TAP= operand processor has been modified to mark
a REMOTE with a valid IPADDR= and PORT= value as a
TAPping router even when TAP= is omitted or TAP=0 is
specified. This will allow the DRMT and MRMT commands
to process the TAP= operand correctly.
SOLUTION2: HNAS has been modified to accept MONTAP as a global
start parameter and the MONITOR console command
processor has been modified to accept MON TAP {ON|OFF}
as a local PCE parameter. The MONTAP start parameter
will cause the TAPping process for all TAPping REMOTEs
to be logged in SYSPRINT.
The MON TAP ALLON console command provides the same
function as the MONTAP start parameter.
The MON TAP ON console command will cause the TAPping
process for only the REMOTEs identified by the RNM=
or ID= console modifiers to be logged in SYSPRINT.
The following new monitor log entries are now provided:
NAS2511M CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2511M XOT TAP TIMEOUT, RESPONSE NOT RECEIVED FOR
CONNECTION SETUP
-or - CALL REQUEST
-or - CLEAR REQUEST
NAS2513M CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2513M XOT TAP SEQUENCE IS STARTING,
TRANSMITTING CALL REQUEST
NAS2513M PKT=0000001010010B000001000000C8D5C1E2E3C1D7
NAS2515M CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2515M XOT TAP SEQUENCE IN PROGRESS,
RECEIVED CLEAR REQUEST
NAS2515M PKT=000000051001130342
NAS2513M CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2513M XOT TAP SEQUENCE IN PROGRESS,
TRANSMITTING CLEAR CONFIRM
NAS2513M PKT=00000003100117
NAS2517M CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2517M XOT TAP SEQUENCE COMPLETED SUCCESSFULLY
General notes for the TAP monitor process:
1) The TAP monitor will display all packets sent
and received during a single TAP interval.
2) The TAP monitor will work for XTP and XOT REMOTEs
For an XOT REMOTE, OPTIONS=TAPWITHCLR can be
enabled or disabled.
3) The global TAP monitoring state can be displayed
with the DPARM EXEC console command.
4) The global TAP monitoring state can be changed
using the MON TAP {ALLON|ALLOFF} console command.
5) The MON TAP {ALLON|ALLOFF} console command ignores
the setting of the RNM= and ID= modifiers.
6) The local TAP monitoring state can be displayed
with the DPCE console command. In this case,
the 5th character under the NASOPT column will
show blank if the TAPping PCE is not being
monitored or as 'M' if it is.
7) The local TAP monitoring state can be changed
using the MON TAP {ON|OFF} console command.
8) The MON TAP {ON|OFF} console command uses the
setting of the RNM= and/or ID= modifiers to
locate the PCEs to be monitored.
9) The NAS251xM monitor messages are only written
to SYSPRINT.
10) Most NAS251xM monitor messages contain an
English description of the packet that was
transmitted or received as well as the first
24-bytes of the raw packet (starting with the
XOT packet length of 4-bytes). If a packet is
less than 24-bytes in length, the display will
be truncated.
11) The NAS251xM monitor messages can be filtered
from SYSPRINT by the ALRMFLTR= operand or the
ALARM FILTER= console command using the PURGE
(P) action.
12) The NAS251xM monitor messages are in addition
the existing Keep Alive alarm messages which
are written to both SYSPRINT and the SYSCONS.
NAS2501W CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2501W ROUTER KEEP ALIVE FAILURE xx OF 02
NAS2502E CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2502E ROUTER CONTACT LOST
NAS2503W CLIENT=010.117.056.100(02630) SOCKID=0001
PCEID=0008 NAME=XOTCLNT1
NAS2503W ROUTER CONTACT REACQUIRED
CIRCUMVENTION1: Specify a non-zero TAP= value in the CDF.
CIRCUMVENTION2: Use the HNAS TCPIP trace facility to monitor the
TAP (Keep Alive) process.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-31-2005 - APAR 2300154
APAR: 2300154
STATUS: CLOSED
OPEN_DATE: 08-31-2005
CLOSE_DATE: 08-31-2005
SERVICE(S): PCNE/GATE/PAD Configuration
MANDATORY: NO
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300154.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300138
(and associated APAR chains)
OBJECT(S): CNFGSVC0, CNFGSVC4, CNFGSVC5
SOURCE(S): N/A
PROBLEM: Error introduced with APAR 2300138 causes an invalid
array index to be displayed when an error is detected
in the SVC0=, SVC4= and/or SVC5= operands.
DESCRIPTION: Problem occurs because the array index remembrance
is being incorrectly initialized.
SOLUTION: The SVC0=, SVC4= and SVC5= operand processors have
been modified to initialize the array index value
correctly.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-30-2005 - APAR 2300153 (was problem 2004349A)
APAR: 2300153_E
STATUS: CLOSED
OPEN_DATE: 12-14-2004
CLOSE_DATE: 08-30-2005
SERVICE(S): CLEAR DIAGNOSTIC TRACE ALERT MESSAGES
MANDATORY: NO, but recommended
ORIGIN/REF: 230_CLY,MAT,CPT
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300153.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 08-16-2005
With APAR: 2300151 applied.
OBJECT(S): CONSDMCH, CONSHELP, CONSTMCH, MCHSVCI, VCCLEAR,
XOTBXM, XOTFCDC, XOTGTCC, XOTGTDC, XOTTR,
SOURCE(S): MCHD, VTMUT1
PROBLEM: HNAS doesn't currently have a trace message that
is generated whenever a Clear is sent or received.
DESCRIPTION: HNAS provides session end information in a number of
ways. For example, NAS3799I (session end message)
provides cause and diagnostic information when the
session's VTAM ACB is closed. This enhancement APAR
provides the ability to monitor Clear packet activity
on a system wide or specific MCH basis so that unusual
events can be observed.
SOLUTION: When a TRCMCH ICLR or TRCMCH OCLR console command
is entered HNAS will issue a NAS7795T alert when
a Clear packet is received from a remote (ICLR)
or when a Clear packet is sent to a remote (OCLR).
NAS7795T ip-addr {INBOUND | OUTBOUND} CLEAR.
MCH mchname {LU | SPU} name
CAUSE/DIAG=ddd/ddd (xx/xx)
ip-addr = IP address for the session being cleared.
mchname = name of the TYPE=MCH remote for the session.
LU name = name of HNAS SLU used for LLC0/4/5 calls.
SPU name = name of the HNAS TYPE=SPU REMOTE used for
an LLC3 call.
******** is displayed if 'name' is not
known (e.g. has not yet been assigned).
CAUSE/DIAG= clear cause and diagnostic values in
decimal (ddd) and hexadecimal (xx).
The NAS7795T message is sent to SYSPRINT (only)
regardless of the setting of TRCPRNT.
CONCMDQ=(...,'TRCMCH ICLR','TRCMCH OCLR') may be
coded on the BUILD statement to automatically
activate clear trace messages.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-23-2005 - APAR 2300152 (was problem 2004300A)
APAR: 2300152_E
STATUS: CLOSED
OPEN_DATE: 10-26-2004
CLOSE_DATE: 08-23-2005
SERVICE(S): PAD (LLC5) Translate Tables
MANDATORY: NO
ORIGIN/REF: 230_SDD
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300152.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300139, 2300133, 2300130, 2300123, 2300120
(and associated APARs PREREQ chains)
Note: Due to the large number of PreReqs, we
recommend a product maintenance refresh
to pick up this APAR.
OBJECT(S): CNFGTRAN, CONSDRMT, CONSHELP, CONSMRMT, MCHINI,
MCHTTBLS, NASCNFG
SOURCE(S): XFNASWA, MCHTTBLS
PROBLEM: Customer reports that PAD terminals cannot communicate
with TPE host application.
DESCRIPTION: PAD terminals are unable to effectively communicate
with certain host applications like TPE because
special ASCII characters are not being translated
correctly for their application.
SOLUTION: HNAS has been modified to accept additional TRAN=
operand values that allow standard NPSI translate
tables to be used instead of standard HNAS translate
tables. We have found that for TPE (and possibly
other applications) the NPSI tables eliminate the
communications problems.
Note that standard HNAS tables were taken from
Comm-Pro's 37XX FEP NAS program product rather than
NPSI. In most cases, these tables work fine but in
some cases, as with TPE, the NPSI tables are more
appropriate and are actually required.
In addition to the originally accepted TRAN= operand
values of USER, SPACE, MARK, ODD and EVEN which select
standard HNAS translate tables, HNAS will now accept
NPSISPACE, NPSIMARK, NPSIODD and NPSIEVEN to select
standard NPSI translate tables.
Prior to this enhancement APAR, a customer had to
manually rename the MCHTTBL1 member in the HNASOBJX
object library to MCHTTBLS in order to pick up the
NPSI translate tables. This, however, overlaid the
HNAS translate tables so that the original TRAN=
operand values could be used to select the NPSI
tables in lieu of the HNAS tables. The new TRAN=
operand values allow both the HNAS and NPSI tables
to be co-resident and CDF selectable.
In addition to the CDF changes mentioned above, the
MRMT command processor has been modified to accept
the original as well as the new TRAN= operand values.
This will allow translate tables to be changed/set
'on the fly'. Prior to this APAR, translate tables
were fixed via the CDF.
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).
09-19-2005 - APAR 2300151 (was problem 2005208A)
APAR: 2300151_E
STATUS: CLOSED
OPEN_DATE: 02-27-2005
CLOSE_DATE: 08-16-2005
REVISE_DATE: 09-19-2005 (Memo typo, XOTRR changed to XOTTR)
SERVICE(S): PVC
MANDATORY: YES
ORIGIN/REF: 230_CP
CPTECH: PRT
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (SRC) HNASMACX and (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300151.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 06-14-2005
With APAR: 2300140 applied.
SUPERSEDES: N/A
OBJECT(S): CONSDVC , MCHPVCI , MCHTMR , MCHUT1 , VCCLRQ ,
VCRESET , XOTBXM , XOTRCV , XOTTR , XOTUT1
SOURCE(S): VCDD
PROBLEM: Enhancement APAR to improve operation of PVCs.
SUMMARY: This APAR addresses the following issues:
1) Revised HNAS PVC Setup Status Codes improving router
PVC Setup retry (general improvement)
2) New and improved PVC trace records via TRCMCH OCR|ICR
3) New alert messages improve PVC status reporting
4) Resets 029/115 & 001/000 (network/link out-of-order)
received by HNAS now reported to the PLU via NOTIFY
5) DVC display now provides PVC session Setup state
DESCRIPTION: 1) New status codes used by HNAS to reject inbound
SETUP packets. Codes greater than X'0F' cause the
router to never retry the setup. The new codes
allow the router to retry the setup every 5 minutes,
as appropriate.
X'13' = no such destination interface is now X'0C'.
This code is used when the router has an incorrect
HNAS MCH name.
X'14' = destination interface not up is now X'08'.
This code is used when a SETUP is received when HNAS
is coming down.
X'16' = no such destination PVC is now X'0D'.
This code is used when a SETUP is received for an
HNAS MCH but the setup's LCN has not been defined
in HNAS.
X'19' = can't support flow control values, is now
X'09.
This code is used when a SETUP is received specifying
a window size > 7 or a packet size > 4096.
X'1A' = PVC setup protocol error, is now X'0E'.
This code is used when a SETUP is received for a
PVC that already has a session.
Please refer to RFC1613 and the HNAS Messages and
Codes PVC Status Field Sense Codes section for
additional information.
2) When TRCMCH ICR or TRCMCH OCR has been specified for
a TYPE=MCH REMOTE, trace records will be created in
SYSPRINT when a call request or PVC setup packet is
received (ICR) or sent (OCR).
For setup packets, messages have the following form:
NAS7718T ip-addr(port) PVCSETUP TO MCH mch-nm
PLU=plu-nm REMOTE=rmt-nm
NAS7719T OUTBOUND PVCSETUP GENERATED FOR LU lu-nm
PLU=plu-nm REMOTE=rmt-nm
After NAS7718T or NAS7719T the setup packet's fields
are displayed:
NAS7798T PVC STATUS=00 INIT LCN:NM lcn:mch-nm
RESP LCN:NM lcn:rtr-intface-nm
NAS7798T (SENDER) IN.WIN=sz OUT.WIN=sz IN.PSZ (2**N)=psz
OUT.PSZ (2**N)=psz
These fields show the values provided for the initiator
(INIT) and responder (RESP). For a detailed description
of PVC setup fields please see RFC 1613.
3) When a remote responds to an HNAS PVC setup packet
with a socket close (FIN) the following alert is
now issued:
NAS7774W PVCSETUP FAILED - REMOTE rmt-nm CLOSED TCP
SESSION IN RESPONSE TO SETUP FROM LU lu-nm
MCH mch-nm
4) Changes to PVC reset packet processing:
When a reset is received for an LLC0 or LLC5 PVC
with a cause/diagnostic of 029/115 (network/link
out of order) or 001/000 (out of order) then the
plu will be will be notified of the error by a
NOTIFY request generated when the HNAS ACB for
the session is closed.
When a reset request other than 015/000 or 000/000
(network/device operational) is received for an
an LLC3 session all LUs associate with the VC's
PU are be taken down.
5) The DVC command has been changed to show whether
or not a PVC setup exchange has occurred.
The following is output from a DVC command:
PID IFN VCN CID SLUNAME VCOPT VCST LLC CLGADDR
0049 0001 00000000 MCH1P001 V PN DATA PAD
|
'P' indicates VC is a PVC _______|
For PVCs the next character indicates the state:
'D' = PVC setup not complete (PVC down).
'I' = PVC received reset indicating link
or device is inoperable.
'N' = Setup complete, session has network
connection to the router.
Tests have indicated that a PVC setup completes
normally even though the serial interface X.25
link with the PVCs is down or not attached to
the router.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-09-2005 - APAR 2300150 (was unpublished problem 2005179A)
APAR: 2300150
STATUS: CLOSED
OPEN_DATE: 06-28-2005
CLOSE_DATE: 08-09-2005
SERVICE(S): TCPIP INTERFACE, BIND FAILURE PROCESSING
MANDATORY: NO, but recommended
ORIGIN/REF: 230_BIC
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 2300150.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300135
(and associated APARs PREREQ chains)
OBJECT(S): CNFGINIT
SOURCE(S): NASTCP
PROBLEM: LOCAL IPADDR/PORT BIND processing can take an unusually
long time (minimally 5 minutes) to complete if a BIND
failure occurs.
DESCRIPTION: If HNAS is stopped and restarted very quickly OR if
the same LOCAL IPADDR= and PORT= values are used by
different HNAS images running under the same stack
when the TCPIP SHAREPORT option is NOT in effect, the
following alarm message is generated and the BIND is
retried after the delay specified by the DELAYTIME=
suboperand of the INIT= operand.
NAS2231W SERVER=010.117.056.170(01998) SOCKID=0000
PCEID=0007 NAME=LXOT
NAS2231W BIND REQUEST FAILED, RC=FFFFFFFF 00000030
The RC value indicates that the TCPIP socket is either
currently in use or was in use and the 'linger timeout'
has not expired in the stack.
When this particular BIND failure is detected, the
'linger timeout' is reset but the DELAYTIME= timer
is then started. If the DELAYTIME= operand is omitted,
a default delay of 5-minutes is enforced before the
BIND is retried. From the operator's perspective,
this could appear as if HNAS were hung.
SOLUTION: 1) HNAS has been modified to reset the 'linger timeout'
before the initial BIND is executed. This should
minimize the probability of a RC=FFFFFFFF 00000030
BIND failure.
2) The default DELAYTIME= value has been changed from
5=minutes to 1-minute. Should a BIND failure occur,
the shorter default delay will allow the BIND to be
retried more quickly. Note that the DELAYTIME=
value has a 1-minute resolution so the new default
value is its minimum.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-03-2005 - APAR 2300149
APAR: 2300149
STATUS: CLOSED
OPEN_DATE: 07-30-2005
CLOSE_DATE: 08-03-2005
SERVICE(S): Start parameter display (DPARM)
MANDATORY: NO, but recommended
ORIGIN/REF: CP
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 2300149.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300139, 2300113
(and associated APARs PREREQ chains)
OBJECT(S): CONSDPRM
SOURCE(S): NASMAIN
PROBLEM: DPARM EXEC console command incorrectly displays PRNTON
followed by PRNTOFF at SYSCONS operator console when
SHOWCONS is active and PRNTOFF is in effect.
DESCRIPTION: When PRNTOFF is in effect, DPARM should only display
PRNTOFF at the SYSCONS when SHOWCONS is also in effect.
In addition all start parameters should be logged in
SYSPRINT when HNAS is started regardless of the PRNT
option that was specified in the PARM= operand.
DESCRIPTION: HNAS initialization logic has been modified to always
log initial start options in SYSPRINT and the DPARM
console command has been modified to display PRNTOFF
by itself when PRNTOFF is in effect.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-03-2005 - APAR 2300148
APAR: 2300148
STATUS: CLOSED
OPEN_DATE: 07-30-2005
CLOSE_DATE: 08-03-2005
SERVICE(S): HNAS Trace Support
MANDATORY: NO, but recommended for correct trace results.
ORIGIN/REF: CP
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300148.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CONSTLU, CONSTLUQ, CONSTMCH, CONSTMCX, CONSTVC, CONSTVCQ
SOURCE(S): N/A
PROBLEM: LU, MCH, MCHX and/or VC tracing is reset if an invalid
argument is provided after the TRCLU, TRCLUQ, TRCMCH,
TRCMCHQ, TRCVC or TRCVCQ commands, respectively.
DESCRIPTION: Due to a bad register, tracing is terminated for the
resources identified by the console command modifiers
currently in effect if an invalid command argument is
given for the commands listed in the PROBLEM overview.
Examples:
TRCLU DLU will reset LU tracing then display the LUs.
TRCLU XXX will reset LU tracing and cause the
following message to be generated:
NASC011E DECODE FAILURE, RE-ENTER
A non-decodable argument is supposed to be processed
as a chained console command (e.g. DLU in the first
example above) so that the the given command is
processed as if no argument was provided. For all
the trace commands listed above, ON is the default
argument when no argument is given so that a resource
trace should be started if it is not already active.
When a supplied trace command follower is not a valid
argument or a valid console command, the NASC011E
message is appropriate and should be generated.
SOLUTION: The trace command processors have been modified to
treat a non-decodable follower as a missing argument
so that the default argument of ON is always used.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
08-02-2005 - APAR 2300147
APAR: 2300147
STATUS: CLOSED
OPEN_DATE: 07-22-2005
CLOSE_DATE: 07-25-2005
SERVICE(S): QLLC PVC/SVC support
MANDATORY: YES
ORIGIN/REF: 230_IZB
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300147.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300128
(and associated APARs PREREQ chains)
OBJECT(S): XOTXMTC
SOURCE(S): N/A
PROBLEM: A NASHALT (0198 ABEND) can occur in the VTMLUPQ routine
(INV LU) when HNAS schedules a PVC Setup packet for a
QLLC PVC or a Call Request packet for a QLLC SVC and
the router connection is down.
DESCRIPTION: During HNAS initiated QLLC SPU session establishment,
a PVC Setup packet is created for a PVC or a Call
Request packet is created for an SVC. If the router
connection is down when the corresponding packet is
scheduled for transmission, the TCPIP layer (TCPXMT)
will return the packet to the XOT layer (XOTXMTC)
marked as undeliverable with the 'lost contact'
completion code. This causes XOTXMTC to perform VC/LU
cleanup which includes calling the VTMLUPQ routine.
For a QLLC VC, there is no LU associated with the
VC at SPU session establishment time. When VTMLUPQ
receives control to purge the non-existent LU from
all queues, it issues the NASHALT because it expects
an LU control block (LUB) address to be passed to it
in Register 5 (R5). For QLLC, R5=0 at entry to
VTMLUPQ.
SOLUTION: XOTXMTC has been modified to bypass the call to
VTMLUPQ when the VC type is QLLC (LLC3). This will
allow only the VC to be cleaned up and released when
the 'lost contact' condition is detected during QLLC
session establishment.
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).
07-19-2005 - APAR 2300146 (was unpublished problem 2005192A)
APAR: 2300146
STATUS: CLOSED
OPEN_DATE: 07-11-2005
CLOSE_DATE: 07-19-2005
SERVICE(S): VTAM LLC0/LLC4/LLC5
MANDATORY: NO
ORIGIN/REF: 230_CUK
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 2300146.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 05-04-2004
with APAR: 2300024 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHGTRQ , MCHHL0RQ , MCHHL4RQ , MCHHL5RQ
SOURCE(S): N/A
PROBLEM: BIND rejected with SENSE=08210C0F
DESCRIPTION: HNAS requires the BINLUP BIND field (LU Presentation
Services Profile) to have a value less than 2. If
this requirement is not met the PLU's bind is
rejected.
HNAS only validates the BINLUP field (there is no
other use). NPSI does not validate this BIND field.
SOLUTION: BINLUP checking removed from HNAS to mirror NPSI
emulation.
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).
06-30-2005 - APAR 2300145 (was unpublished problem 2005171A)
APAR: 2300145
STATUS: CLOSED
OPEN_DATE: 06-20-2005
CLOSE_DATE: 06-30-2005
SERVICE(S): QLLC, VTAM, SESSLIM=YES
MANDATORY: YES
ORIGIN/REF: 230_NBG
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 2300145.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 02-17-2005
With APARs: 2300109 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHRQ
SOURCE(S): N/A
PROBLEM: NAS4704W ACTIVE LU lu-nm REJECTING NEW BIND (0C000000)
alert message issued when BIND queued by session
manager is delivered to HNAS.
DESCRIPTION: The session manager is used to allow QLLC access to
selected PLUs. When users connect the session manager
screen is seen first. After the secondary PLU name is
known the session manager issues a CLSDST PASS to cause
an UNBIND BIND forthcoming to be issued. This passes
control to, for example, CICS.
In order regain control at session end the session
manager uses SIMLOGON to queue (in VTAM) a BIND request
for the SLU. When CICS UNBINDs the queued BIND is
delivered to HNAS. This BIND is incorrectly rejected
with the above alert message.
The error code (0C000000) indicates that HNAS is
rejecting the BIND because the LU is processing an
UNBIND.
This problem was introduced by APAR 2300109 which was
created to handle problems with CLSDST PASS operation.
When BINDs are to be queued in VTAM for HNAS SLUs,
SESSLIM=YES must be coded on HNAS APPL statements for
LUs used by the session manager. This keeps VTAM from
sending the session manager bind in the middle of an
existing session.
Prior to APAR 2300109 a mid-session BIND was rejected
in the HNAS BIND exit routine. The customer's session
manager recovered from this. APAR 2300109 introduced
logic to pass mid-session QLLC BINDs to HNAS. BIND
processing code at the task level determined if the
BIND could be accepted. An error in this new code
incorrectly rejects a new BIND received while HNAS
is processing an UNBIND.
SOLUTION: Correct HNAS logic so that the session manager's
queued bind can be processed.
SESSLIM=YES is required on the APPL statement for
LUs controlled by a session manager that queues
BINDs in VTAM.
CIRCUMVENTION: If APAR 2300109 is on the system then the following
ZAP may be used:
* JUNE 25, 2005 APAR 2300145
* ZAP TO ALLOW PROCESSING OF QUEUED SESSION MANGER BIND
* AFTER UNBIND PROCESSING FOR PREVIOUS PLU COMPLETES.
*
NAME HNAS MCHHRQ
VER 0A2C 95025134,4770A370
REP 0A2C 92025134,4700
/*
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).
06-29-2005 - APAR 2300144 (was problem 2005116A)
APAR: 2300144
STATUS: CLOSED
OPEN_DATE: 04-26-2005
CLOSE_DATE: 06-29-2005
SERVICE(S): VTAM, IMS
MANDATORY: YES
ORIGIN/REF: 230_GAD
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 2300144.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 03-21-2005
With APAR: 2300140 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHRQ
SOURCE(S): VTMSND2
PROBLEM: HNAS IMS LLC0 session aborts when HNAS rejects PLU
request PIU with 0813 sense.
DESCRIPTION: When HNAS receives a PIU with begin bracket from
the PLU and there is data from the remote already
queued for delivery to the PLU, HNAS rejects the
PLU's request with 0813 (bracket bid reject).
The OPTION=INHIBITBIDREJECT keeps HNAS from rejecting
a BID when there is data queued. The failure occurs
because the INHIBITBIDREJECT logic was omitted from
the path which processes an FMD PIU with begin bracket
bit.
There is no alert message issued when the PIU is
rejected so it is difficult to determine the reason
for the session end.
SOLUTION: Begin bracket logic corrected. When HNAS rejects a
PIU the follow alert is now issued:
NAS3705W LU lu-name REJECTING cmd #nbr SENSE=xxxxxxxx
LUBST1/2=aabb LUBBST1/2=ccdd REQ-RH=qqrrrrrr
lu-name = HNAS SLU name
cmd = command being rejected (DATA, BID, etc)
nbr = VTAM sequence number
xxxxxxx = sense data (08130000 for bid reject)
aabbccdd = internal state flags
qq = internal command index
rrrrrr = 3 byte RH for command (from 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).
06-29-2005 - APAR 2300143 (was problem 2005123A)
APAR: 2300143
STATUS: CLOSED
OPEN_DATE: 05-03-2005
CLOSE_DATE: 06-29-2005
SERVICE(S): GATE
MANDATORY: YES
ORIGIN/REF: 230_SWD
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 2300143.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 04-19-2005
With APARs: 2300127 applied.
SUPERSEDES: N/A
OBJECT(S): VCCLEAR
SOURCE(S): N/A
PROBLEM: Hung resource, GATE data session LU not available
for new calls.
DESCRIPTION: Event sequence:
Remote starts an X25 M-bit packet sequence. Clear
cause=09 (out of order) sent by remote.
When the above sequence happens, HNAS queues the
clear packet for delivery to the CTCP. The clear
follows the M-bit packet that preceded it. The
failure occurs because the queue service routine
incorrectly waits for the X25 packet m-bit chain
to complete.
SOLUTION: When the clear is received, the packets on the
input queue will be made ready for delivery to the
PLU. The 09 clear will be delivered to the CTCP.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
06-28-2005 - APAR 2300142 (was problem 2005145A)
APAR: 2300142
STATUS: CLOSED
OPEN_DATE: 05-25-2005
CLOSE_DATE: 06-28-2005
SERVICE(S): GATE
MANDATORY: RECOMMENDED
ORIGIN/REF: 230_SWD
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 2300142.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 04-21-2005
With APAR: 2300128 applied.
SUPERSEDES: N/A
OBJECT(S): MCHNRQC
SOURCE(S): N/A
PROBLEM: FTAM sessions ending with DIAG=221 (DD).
DESCRIPTION: This ending indicates that a CTCP did not UNBIND
after receiving a clear or clear confirm from HNAS.
The ending is triggered by a 3 second HNAS timer.
SOLUTION: HNAS modified to wait 10 seconds for the CTCP UNBIND.
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).
06-20-2005 - APAR 2300141 (was problem 2005145B)
APAR: 2300141
STATUS: CLOSED
OPEN_DATE: 05-25-2005
CLOSE_DATE: 06-20-2005
SERVICE(S): QLLC VTAM interface
MANDATORY: YES
ORIGIN/REF: 230_HVB
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300141.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300136
(and associated APARs PREREQ chains)
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: NASHALT (0198 ABEND) can occur when ACTLU Power On
is received because XMT RPL is busy executing a
previous SETLOGON request when a new SETLOGON is
attempted.
DESCRIPTION: A SETLOGON request is normally ended immediately.
In the ABEND case, the SETLOGON does not end so
that when a second SETLOGON is requested, the XMT
RPL is still busy executing the first one. In a
trace supplied by the customer, 14 hours have
elapsed between the first SETLOGON that does not
end and the second SETLOGON that caused the ABEND.
The reason for the non-ending of the SETLOGON
cannot be explained.
SOLUTION: Logic has been added to recycle the SLU when the
busy XMT RPL is detected. This includes closing
the ACB reformatting the SLU which will reset XMT
RPL bust, reopening the ACB then issuing the new
SETLOGON request.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
06-14-2005 - APAR 2300140 (was problem 2005138A)
APAR: 2300140
STATUS: CLOSED
OPEN_DATE: 05-18-2005
CLOSE_DATE: 06-14-2005
SERVICE(S): VTAM
MANDATORY: YES
ORIGIN/REF: 230_SWD
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and/or (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300140.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 03-21-2005
With APAR: 2300122 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHRQ , VCRESET
SOURCE(S): VCDD
PROBLEM: LU session hangs after SIGNAL sent by PLU.
DESCRIPTION: HNAS SIGNAL processing generates an X25 RESET packet
(which is incorrect). The reset leads to difficulties
if delivery of a multiple element chain to the PLU is
in progress.
SOLUTION: This problem arises because HNAS does not conform to
NPSI processing of SIGNAL and X25 RESETs.
The customer's PLU sent the SIGNAL to inform HNAS that
it could not accept a multiple element RU chain.
When HNAS receives a SIGNAL PIU a +RSP will be returned
to the PLU. For LLC5 sessions an IOB (indication of
break) Q packet will be sent to the remote. For other
LLC types SIGNAL does not cause X25 side activity.
This processing conforms to NPSI operation.
RESET packets generated by HNAS indicate that events
on the X25 line side (invalid packet sequence number,
etc) have made the integrity of the data stream suspect.
Events of this type are very rare. In a NPSI system
the call is cleared. HNAS will now also clear with
diagnostic=211 (X'D3') when a reset is generated.
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).
06-13-2005 - APAR 2300139 (was problems 2005146A and 2005157B)
APAR: 2300139_E
STATUS: CLOSED
OPEN_DATE: 05-26-2005 for 2005136A
06-06-2005 for 2005157B
CLOSE_DATE: 06-13-2005
SERVICE(S): Start parameter and configuration processing
MANDATORY: NO, but recommended
ORIGIN/REF: 230_ECI, 230_IZB, 230_IBMTW
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300139.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300138, 2300123
(and associated APARs PREREQ chains)
OBJECT(S): NASCNFG
SOURCE(S): NASMAIN
PROBLEM1: AMNF generated during FASTRUN even though RC=8.
PROBLEM2: Blank value after PARM= and before intended startup
parameters prevents user defined values from being
used during HNAS initialization.
DESCRIPTION1: Documentation says that AMNF is only generated during
FASTRUN when RC<8. Actual code does not adhere to the
documentation.
DESCRIPTION2: Customer inadvertently left a blank character after the
equal sign in PARM= and before the parenthesis that
opens the parameter string (e.g., PARM= '...text...').
The JCL scanner interprets this as a null PARM= string
which is then passed to HNAS. Since no parameters are
provided, HNAS simply reverts to its defaults. Since
WTOR is the default for console input, the use of the
MODIFY interface is rejected as well as other defaults
or options the customer intended to override or enable.
SOLUTION1: HNAS configuration processing has been modified to
prevent AMNF from being generated and storage estimates
from being displayed when RC>=8. CDF must be modified
and all errors corrected in order for these FASTRUN
functions to be provided.
SOLUTION2: An Warning message will now be generated indicating
that no PARM= values were specified which will make it
easier to identify a potential coding error. When no
PARM= operand value is coded, the following message will
be generated prior to the 'NAS0011I OPTIONS IN EFFECT'
message:
NAS0001W PARMLIST OMITTED, DEFAULT OPTIONS WILL BE USED
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).
06-13-2005 - APAR 2300138 (was problem 2005041B)
APAR: 2300138_E
STATUS: CLOSED
OPEN_DATE: 02-10-2005
CLOSE_DATE: 06-10-2005
SERVICE(S): PCNE/GATE/PAD Configuration Enhancement
MANDATORY: NO
ORIGIN/REF: 230_SDD
PTF_CLASS: ENHANCEMENT APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300138.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300132, 2300107, 2300035
(and associated APAR chains)
OBJECT(S): CNFGSVC0, CNFGSVC4, CNFGSVC5, NASCNFG
SOURCE(S): N/A
PROBLEM: The SVC0=, SVC4= and SVC5= operands do not currently
(ENHANCEMENT) allow an SLU prefix text value, suffix start value and
count value to be specified to generate SLU names like
the LUNAME= operand does for GATEFC SLUs.
DESCRIPTION: See problem/solution.
SOLUTION: The SVC0=, SVC4= and SVC5= operand processors have been
modified to generate SLU names based on a prefix text
value, suffix start value and count value defined as the
first, second and third operand entry, respectively.
Currently, the first SVCi= entry is the vclmt and the
subsequent entries are SLU names. Missing SLU names are
replaced by default SLU names which are created using
the first 4-characters of the REMOTE name followed by a
0|4|5 for the LLC type followed by the SVCi= index
number (001, 002, 003, etc).
Current: SVCi=(vclmt,slunm1,slunm2,...)
Alternate: SVCi=(pfxlu,sfxst,vclmt)
The current and alternate specifications will both be
accepted. The alternate specification is appropriate
when no additional suboperands need to be associated
with each SLU name. For the alternate specification:
The pfxlu value must be the first SVCi= suboperand
and may be any valid assembler language symbol up
to 7-characters in length starting with either an
alpha character (A,B,C,...,Z) or an accepted special
character (@, #, $ or %). This suboperand is REQUIRED
to indicate that the alternate specification is being
used.
The sfxst value must be the second SVCi= suboperand
and must be a hexadecimal number (without the framing
characters X'') between 0 and F when the pfxlu length
is 7, between 0 and FF when pfxlu length is 6, ...,
between 0 and FFFFFFF when the pfxlu length is 1.
If sfxst is omitted (,,), a default value of 0 will be
used.
The vclmt value must be the third SVCi= suboperand
and must be a decimal number between 0 and 511 (the
SVCi= array size). This suboperand is REQUIRED.
As is the case with the LUNAME= operand, the SLU names
that HNAS generates from the pfxlu, sfxst and vclmt
values will always be 8-characters in length with zero
(0) pad characters between the last pfxlu character
and the suffix value.
Examples:
If SVC0=(TT,1,3) is specified, the generated SLU
names would be TT000001, TT000002, TT000003.
If SVC0=(TTTTT,0,3) is specified, the generated SLU
names would be TTTTT000, TTTTT001, TTTTT002.
If sfxst and/or vclmt yield a suffix that is invalid
for the pfxlu length, the corresponding value will be
rejected. For example if SVC0=(ABCDEFG,F,2) is coded,
the NAS1311E configuration error message will be
displayed when the vclmt value is decoded as follows:
NAS1300I REMOTE SVC0=(ABCDEFG, <- ok so far
NAS1300I REMOTE F, <- ok so far
NAS1999E
NAS1321E ERROR: REMOTE 2) <- too large
This occurs because the vclmt value of 2 yields a
suffix of 10 that when appended to the pfxlu value
of ABCDEFG creates an 9-character name of ABCDEFG10
which is an invalid assembler language symbol.
If a pfxlu value is specified but the sfxst and/or
vclmt value is not set, the following configuration
error message will be generated:
NAS1311E REMOTE SVCi SPECIFICATION ERROR, REQUIRED
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
06-08-2005 - APAR 2300137
APAR: 2300137
STATUS: CLOSED
OPEN_DATE: 06-02-2005
CLOSE_DATE: 06-08-2005
SERVICE(S): LLC3 (QLLC) USSMSG processing.
MANDATORY: YES if APAR 2300096 is on.
ORIGIN/REF: 230_NBG
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300137.ZIP file)
COREQ(S): N/A
PREREQ(S): 2300096 (and associated APAR chains)
OBJECT(S): MCHSOL
SOURCE(S): N/A
PROBLEM: Garbage data can be sent at the end of a large USSMSG.
DESCRIPTION: Logic introduced by APAR 2300096 that prevented line
control from being added for QLLC SLUs sets the wrong
end of data field in the buffer so that the entire
buffer is sent even if only 1-byte of USSMSG data is
present. The erroneous logic sets the BFRSODOF field
instead of the BFREODOF field. If the buffer has never
been used before, the extra data will be all zeroes.
If the buffer has been recycled, the extra data will
be unpredictable.
SOLUTION: The HNAS USSMSG processor has been modified to set
BFREODOF instead of BFRSODOF so that only 'real'
USSMSG data is sent to QLLC SLUs.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
05-19-2005 - APAR 2300136 (was problem 2005112A)
APAR: 2300136
STATUS: CLOSED
OPEN_DATE: 04-21-2005
CLOSE_DATE: 05-19-2005
SERVICE(S): QLLC SUPPORT
MANDATORY: YES
ORIGIN/REF: 230_HVB
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300136.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300129, 2300122
(and associated APARs PREREQ chains)
OBJECT(S): MCHBFR, QLSSCP
SOURCE(S): N/A
PROBLEM 1: NASHALT in QLALOG subroutine in QLSSCP module.
PROBLEM 2: XFRUDC can reject INIT-SELF or TERM-SELF PIUs.
DESCRIPTION1: When OPTIONS=CLOTINITYP=BIND is in affect, the first
BIND received from an SLU on an SPU will initiate an
outbound Call Request for the SPU. During the time
that the call setup process is in progress, all BINDs
are supposed to be remembered in the LUSVFREQ field
of LU control blocks (LUBs) associated with the SPU.
When an SLU comes active (Power On indicated in an
ACTLU response or a subsequent NOTIFY request), a
remembered BIND is then sent.
When a VC is allocated for an outbound Call Request,
the LUVC field is set to zero. When the XID exchange
is completed, the LUVC field is set to the active VC
address signaling that the SPU has been identified.
If a BIND arrives when LUVC=0 (=> SPU has not been
connected), the BIND is recorded for later delivery
in LUSVFREQ. However, if LUVC>0 (=> SPU connected),
the BIND is enqueued for delivery to the SLU.
Because of a timing problem and a logic error, the
enqueued BIND is half processed. The scheduler sets
BIND pending state (LUBST1=LUBSTBN) but the BIND PIU
builder discards the BIND request because the SLU is
not yet Powered On. When the Power On indication is
finally received, the QLALOG routine in the QLSSCP
module performs validity check to ensure that the LU
state (LUBSTBN=BIND_pending) matches the remembered
BIND request in LUSVFREQ. The NASHALT 0198 ABEND
occurs because the LUSVFREQ field is zero rather
than BIND remembered (LURQBIND).
DESCRIPTION2: When the RU field for a PIU spans buffers, the XFRUDC
decode routine cannot do a proper command lookup.
The result is that the SLU command is rejected with
SENSE=1003 and the following alarm message is issued.
NAS8241W INVALID REQ FOR LU XXXXXXXX ON PU XXXXXXXX
RH/RU=XXXXXXXX XXXXXXXX RC=16
SOLUTION1: HNAS has been modified to detect whether the SLU has
completed the activation sequence when LUVC>0.
If it has, the BIND can be scheduled as is normal.
If it has not, the BIND must be remembered in
LUSVFREQ for a subsequent Power On indication via
an ACTLU response or NOTIFY request.
SOLUTION2: The QLRCV routine now calls the MCHBCOM2 compress
routine before the XFRUDC routine so that the entire
RU will be copied into the first buffer of a multi-
buffer PIU. This will ensure that XFRUDC will be
able to decode the command correctly.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
05-19-2005 - APAR 2300135
APAR: 2300135
STATUS: CLOSED
OPEN_DATE: 05-17-2005
CLOSE_DATE: 05-19-2005
SERVICE(S): TCPIP TAP Keep Alive processing
(Problem observed durung PVC error recovery testing)
MANDATORY: YES, PRIORITY
ORIGIN/REF: 230_CSP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300135.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300124, 2300117, 2300114, 2300088
(and associated APARs PREREQ chains)
Note: Due to the large number of PreReqs, we recommend
a refresh upgrade to pick up this APAR.
OBJECT(S): NASUTIL
SOURCE(S): NASTCP, XFBLK, XFPCE
PROBLEM: Consecutive TAP Keep Alive failures do not detect lost
contact with a router.
DESCRIPTION: Changes made for APAR 2300108 required movement of
instructions so that USING limits could be employed.
This was done to avoid non-zero assembler Return Codes
for the NASTCP and NASMAIN assemblies during HNAS
installation processing. In the case of NASTCP, the
moved opcodes caused the TAP retry counter (PCETAPRC)
to be reset to zero for a new TAP request following a
Keep Alive failure. This occurs because PCETAPRC was
equated to another field (PCEIPPID) as the result of
logic added for APAR 2300043. This logic propagates
the PCEIPPID field from the HOME LOCAL PCE to the TAP
REMOTE PCE. This means that a second consecutive
Keep Alive failure will be treated as the first.
Since two consecutive Keep Alive failures are required
to take a router offline and close all active sockets
to the router, the router will always appear active
to HNAS even when it has disconnected from the network.
For PVCs, this can cause HNAS and the router to get out
of synch when the router is reconnected to the network.
SOLUTION: The PCETAPRC field has been moved so that it is no
longer equated to PCEIPPID or any other previously
used field. This allows the TAP retry count to
be incremented properly after a Keep Alive failure
so that lost contact with a router will be detected.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
05-19-2005 - APAR 2300134 (was problem 2005090A)
APAR: 2300134
STATUS: CLOSED
OPEN_DATE: 03-31-2005
CLOSE_DATE: 05-19-2005
SERVICE(S): PVC (IMS Application)
MANDATORY: RECOMMENDED
ORIGIN/REF: 230_HVB
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 2300134.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
SUPERSEDES: N/A
OBJECT(S): MCHHRSP
SOURCE(S): N/A
PROBLEM: PVC IMS application regularly getting calls reset
with DIAG=219 (X'DB').
DESCRIPTION: DIAG=219 indicates that HNAS received a -RSP from
the PLU. This usually indicates an SNA error.
The following alarms were issued:
NAS3799I LU lu-nm ENDING SESSION ON MCH mch-nm
HNAS CAUSE/DIAG=000/219 (00/DB) DIAGX=0000
NAS5705W RESET SCHEDULED ON MCH mvc-nm VC vc-addr
lu-nm LU lu-addr CAUSE/DIAG=000/219 (00/DB)
DIAGX=0000
A trace showed that a -RSP SENSE=0826 was being sent
when IMS received an inbound message when the IMS
databases were not up. PVCs can do this often.
SOLUTION: HNAS modified to not end the LU session when a PVC
receives a 0826 -RSP. This eliminates unnecessary
session end and session start messages.
The remote will still receive the 219 RESET to
indicate that the inbound message was rejected.
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).
05-18-2005 - APAR 2300133
APAR: 2300133
STATUS: CLOSED
OPEN_DATE: 05-16-2005
CLOSE_DATE: 05-18-2005
SERVICE(S): PVC/SVC CONFIGURATION support
MANDATORY: YES
ORIGIN/REF: 230_CSP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300133.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300107, 2300099
(and associated APARs PREREQ chains)
OBJECT(S): MCHINI, MCHSVCI
SOURCE(S): N/A
PROBLEM1: NASHALT can occur when many PVCs are configured.
PROBLEM2: NAS1730I REMOTE SVCi PROCESSED message issued even
when SVCi=NONE or is omitted.
DESCRIPTION1: 0198 ABEND can occur and the following message is
generated if many PVCs are configured.
HALT AT LOC xxx IN MCHGETMN: MCH STORAGE BLOCK EXHAUSTED
The problem results from the fact that the BUILD
VCLMT= operand value (or default) is used to compute
the number of VC control blocks (VCBs) to be created.
This count includes all PVCs and SVCs. Memory for
MCHs, VCs and LUs is allocated in a single GETMAIN
call. The amount of memory is computed based on the
number of MCHs, VCs and LUs defined in the CDF. The
required memory size is then rounded to the next 1M
boundary. The MCHINI routine allocates VCBs based on
the BUILD VCLMT= value. However, the MCHPVCI also
allocates a VCB for each SLU in the PVC= operand.
Because the VC storage only accounts for the BUILD
VCLMT= value, not enough can be available for the
MCHPVCI VC allocation even with the rounded memory
size. This results in the NASHALT.
DESCRIPTION2: See PROBLEM.
SOLUTION1: HNAS has been modified so that MCHINI allocates VCBs
for SVCs only so that memory is available for MCHPCVI
VCB allocation. In other words, MCHINI reduces its
VC count by the number of PVCs defined in the CDF.
If the CDF contains only PVCs, the following new
warning message is generated:
NAS1708W SVC'S ARE NOT SUPPORTED
SOLUTION2: HNAS has been modified so that MCHSVCI withholds
the NAS1730I information message when SVCi=NONE is
specified or the SVCi= operand is omitted.
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).
05-12-2005 - APAR 2300132 (was unpublished problem 2005129A)
APAR: 2300132
STATUS: CLOSED
OPEN_DATE: 05-09-2005
CLOSE_DATE: 05-12-2005
SERVICE(S): CONFIGURATION support (APPLNAME/LOGAPPL)
MANDATORY: NO, but recommended
ORIGIN/REF: 230_NBK
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300132.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300107 (and associated APARs PREREQ chains)
OBJECT(S): NASCNFG
SOURCE(S): N/A
PROBLEM: The following configuration error messages are
generated when APPLNAME= and LOGAPPL= are specified
during FASTRUN:
NAS1311W DUPLICATE: REMOTE LOGAPPL=A04CICF
NAS1041E DECODE FAILURE, RECORD FOLLOWS
NAS1000C LOGAPPL=A04CICF
DESCRIPTION: APPLNAME= and LOGAPPL= are different names for the
same operand. The NAS1311W message is expected when
both names are used for the same MCH. However, the
NAS1041W message should not be generated.
SOLUTION: HNAS has been modified to withhold the NAS1041W
message in this situation.
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).
04-28-2005 - APAR 2300131
APAR: 2300131
STATUS: CLOSED
OPEN_DATE: 04-28-2005
CLOSE_DATE: 04-28-2005
SERVICE(S): ALL, MCH timer processing.
MANDATORY: YES
ORIGIN/REF: 230_BNP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300131.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300111 (and associated APARs PREREQ chains)
OBJECT(S): MCHTMR
SOURCE(S): N/A
PROBLEM: System 0C1 ABEND can occur during unusual timer error
recovery processing (ERP).
DESCRIPTION: HNAS had been running for 12 days when system problems
caused HNAS to enter timer recovery processing to
cleanup control blocks and release buffers. ABEND
occurred because a bad branch address was being used
during timer ERP. This logic is executed only in
rare cases.
SOLUTION: The timer error logic has been modified to use the
correct branch address.
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).
04-25-2005 - APAR 2300130
APAR: 2300130
STATUS: CLOSED
OPEN_DATE: 04-25-2005
CLOSE_DATE: 04-25-2005
SERVICE(S): Console Subsystem MRMT command processing for SVC3.
MANDATORY: NO unless there is a requirement to alter an SVC3=
operand.
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300130.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300122 (and associated APARs PREREQ chains)
OBJECT(S): CONSMRMT
SOURCE(S): N/A
PROBLEM1: 0C4 ABEND can occur when attempt is made to modify
an SVC3= operand entry.
PROBLEM2: Unable to change SVC3=NONE to SVC3=ALLOW so that
QLLC support can be activated for an MCH.
DESCRIPTION1: An 0C4 ABEND can occur when searching the SVC3=
operand for an SPU name because the same register
is used to address an SVC3= array entry and the
SVC3= array count. When the first entry is
address, the count becomes corrupted. If the entry
Name does not exist, the SVC3= scan loop exits the
SVC3= array resulting in an address violation.
DESCRIPTION2: The MRMT console command processor decode rejects
SVC3=ALLOW when SVC3=NONE is specified preventing
QLLC support from being enabled dynamically for an
MCH.
SOLUTION1: The SVC3= update routine has been modified to use
different registers to address an SVC3= entry and
the SVC3= array count.
SOLUTION2: The SVC3= update routine has been modified to accept
SVC3=ALLOW when SVC3=NONE is in effect.
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).
04-23-2005 - APAR 2300129
APAR: 2300129
STATUS: CLOSED
OPEN_DATE: 04-22-2005
CLOSE_DATE: 04-23-2005
SERVICE(S): GATE, PFXDCEADDR Option
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 2300129.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 06-18-2004
With APAR: 2300046 applied.
This APAR includes 2300115.
SUPERSEDES: N/A
OBJECT(S): MCHBFR, XOTFCDC, XOTGTCC
SOURCE(S): N/A
PROBLEM: System 0C4 ABEND in MCHRSBF routine (MCHBFR module)
when OPTIONS=PFXDCEADDR used and GATE CTCP provides
an call request packet with no called/calling or with
an invalid lengths byte.
DESCRIPTION: The PFXDCEADDR option requires HNAS to insert bytes
into the middle of a call request packet. This
requires shifting data in the call request packet.
If the call request packet does not contain a
called/calling DTE address lengths byte, or if the
lengths byte indicates that there are digits that
are not present in the packet (both conditions are
packet format errors) then the buffer shift routine
has a logic error that can cause a S0C4 ABEND or
an incorrect call request packet to be built.
SOLUTION: HNAS logic corrected to account for the error.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-21-2005 - APAR 2300128 (was problem 2005069B)
APAR: 2300128
STATUS: CLOSED
OPEN_DATE: 03-10-2005
CLOSE_DATE: 04-21-2005
SERVICE(S): PVC
MANDATORY: YES
ORIGIN/REF: 230_ITL,230_CPT
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: Standard Apar, REFRESH recommended.
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300128.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: Feb 22, 2005
With APARs: 2300111 applied.
SUPERSEDES: N/A
OBJECT(S): MCHNRQC, XOTXMTC
SOURCE(S): N/A
PROBLEMS: 1) PVC ses ends with NAS3799I, CAUSE/DIAG=000/143
(00/8F)
2) PVC ses does not restart after TCP/IP disconnect,
NAS5704W, CAUSE/DIAG=000/242 (00/F2) issued.
3) PVC ses ended by RESET CAUSE/DIAG=0F/00 causes
NAS3799I, CAUSE/DIAG=000/216 (00/D8) DIAGX=0005
(incorrect CAUSE/DIAG)
DESCRIPTION1: When a PVC is defined with an application index of 255
(PLU name not known, wait for BIND) the following
error messages can be issued:
NAS3799I LU lu-nm ENDING SESSION ON MCH mch-nm
HNAS CAUSE/DIAG=000/143 (00/8F) DIAGX=0000
NAS5705W RESET SCHEDULED ON MCH mch-mn VC vc-addr
lu-nm LU lu-addr CAUSE/DIAG=000/143 (00/8F)
DIAGX=0000
The 143 DIAG code indicates that a REQSESS operation
(used to request a BIND from a PLU) failed. HNAS
should not issue a REQSESS when the appl index is 255.
The above messages result because a logic error leaves
a REQSESS timer running when no REQSESS was issued.
When the timer expires, the above messages are issued.
SOLUTION 1: HNAS REQSESS timer logic corrected.
DESCRIPTION2: PVC sessions fail to restart after a link disconnect.
The following messages appear:
If apar 2300119 is on:
NAS5704W RESET RECEIVED FOR MCH mch-nm VC vc-addr
lu-nm LU lu-addr CAUSE/DIAG=000/242 (00/F2)
DIAGX=0000
If apar 2300119 is not on:
NAS5704W RESET RECEIVED FOR MCH mch-nm VC vc-addr
lu-nm LU lu-addr CAUSE/DIAG=009/242 (09/F2)
DIAGX=0000
NAS7707W XOT PVC SETUP FROM ip-addr CAN'T START
SESSION STATUS=1A
NAS7708W XOT PVC SETUP INIT=rtr-int-name
RESP=SERIAL-mch-nm
The reset messages indicate that the TCP/IP socket was
unexpectedly closed. HNAS does not properly end the
PVC session so when a new SETUP packet is sent by the
router is is reported as a setup error (STATUS=1A).
(indicating the TCP/IP socket was closed) the PVC
becomes unusable.
SOLUTION 2: HNAS logic corrected to properly end the PVC session
when the session end reset is reported,
DESCRIPTION3: A RESET with CAUSE/DIAG 0F/00 (remote out of order)
indicates the remote device is not connected. In
order to inform the PLU of the failure the VTAM
session is ended and a NAS3799I message is issued.
The cause/diag and diagx in the message (00/216/0005)
indicate that an UNBIND failed. The correct values
are 00/146/0000 (HNAS unbound PLU).
SOLUTION 3: Correct the codes passed to the session end message
routine.
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).
04-19-2005 - APAR 2300127
APAR: 2300127
STATUS: CLOSED
OPEN_DATE: 04-19-2005
CLOSE_DATE: 04-19-2005
SERVICE(S): GATE Callout
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 2300127.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 12-08-2004
With APARs: 2300092
SUPERSEDES: N/A
OBJECT(S): VCCLEAR
SOURCE(S): N/A
PROBLEM: Alert message: NAS4702W TIMER RELEASED IDLE LU lu-nm
DESCRIPTION: The above message will follow:
NAS7717W LU gate-lu-nm CALL TO DTE ADDR dte-addr
VIA REMOTE rmt-nm FAILED
NAS7717W CAUSE/DIAG=013/064 (0D/40) DIAGX=0000
When a GATE callout is performed HNAS allocates a
data session LU for the call. The LU is activated
(ACB opened) after the call accept from the remote
is passed to the CTCP on the control session LU.
If the call fails (NAS7717W messages) the data
session LU is not activated. The remote's clear
packet is delivered to the CTCP via the control
session.
Because of an error introduced by APAR 2300092, the
data session LU is not properly freed.
NAS4702 message is issued when timer logic detects
the lost data session LU (no PLU session, no X25
session) and returns the LU to the available queue.
SOLUTION: Clear processing corrected to release the LU.
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).
04-07-2005 - APAR 2300126
APAR: 2300126
STATUS: CLOSED
OPEN_DATE: 04-07-2005
CLOSE_DATE: 04-07-2005
SERVICE(S): DTE address console command modifier processing and
PING command processing.
MANDATORY: YES
ORIGIN/REF: 230_IZB
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300126.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300021 (and the associated APARs PREREQ chains)
OBJECT(S): CONSCLD, CONSCLG, CONSPING
SOURCE(S): N/A
PROBLEM: 0C1 ABEND can occur when 15 digit CLGADDR= or CLGADDR=
modifier is entered explicitly or via 'Ping dteaddr'.
DESCRIPTION: Customer was attempting to PING using a called DTE
address value that was 15-digits in length. The DTE
address is saved in a local savearea that is 8-bytes
in length which includes a length digit and a maximum
of 15 DTE address digits. The ABEND occurs because
the DTE address convert logic requires a PAD byte at
the end of the 8-byte savearea. This PAD byte was
missing which caused a real instruction to be
overlayed. The 0C1 ABEND occurs when the overlayed
opcode is executed.
This problem can occur when a 15-digit DTE address
is entered for the CLDADDR= or CLGADDR= modifiers
or as a PING command argument.
SOLUTION: The DTE address convert savearea has been increased
from 8-bytes to 9-bytes so that the PAD byte is
present for the conversion routine. This will
prevent the opcode overlay and eliminate the ABEND.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
04-06-2005 - APAR 2300125 (was unpublished problem 2005095A)
APAR: 2300125_R
STATUS: CLOSED
OPEN_DATE: 04-06-2005
CLOSE_DATE: 04-06-2005
SERVICE(S): NON-SMP/E Distributions
MANDATORY: NO
ORIGIN/REF: 230_IZB
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: N/A - Product refresh required for this correction.
COREQ(S): N/A
PREREQ(S): APAR 2300112
(and associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): CONSDNAS
SOURCE(S): N/A
PROBLEM: The DNAS command displays DISP=SMP/E for non-SMP/E
distributions created after 02-24-2005.
DESCRIPTION: The DNAS command was modified on 02-24-2005 as part
of APAR 2300112 to display the distribution type
(DIST=SMP/E or DIST=NON-SMP/E) as part of the DNAS
display output. The text for the DIST= parameter
was set to 'SMP/E' in the CONSDNAS assembly prototype
statement so that SMP/E distribution jobs would not
have to be modified. For non-SMP/E distribution jobs,
DIST=NON-SMP/E would be passed in the SYSIN for the
CONSDNAS assembly. This was tested using temporary
SYSIN. Once tested, the CONSDNAS assembly SYSIN for
the standard non-SMP/E job was modified in the
HLQ.VVRRMM.SHIPMAC(INASMDNS) file which is used to
create non-SMP/E distributions. Unfortunately,
instead of INASMDNS invoking CONSDNAS with
DIST=NON-SMP/E, it was actually passing DIST=SMP/E
which is already the default.
SOLUTION: The INASMDNS members have been modified to pass
DIST=NON-SMP/E as required.
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).
03-29-2005 - APAR 2300124 (related to problem 2005069B)
APAR: 2300124
STATUS: CLOSED
OPEN_DATE: 03-26-2005
CLOSE_DATE: 03-28-2005
SERVICE(S): TCPIP interface logic
MANDATORY: YES
ORIGIN/REF: 230_CP
CPTECH: SFD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300124.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300122
(and associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: VC disconnect due to a TCPIP socket close can have
an inconsistent CAUSE/DIAG code.
DESCRIPTION: When a TCPIP socket is closed due to a disconnect
that occurs without a VC Clear (TCPIP RECEIVE ends
with 'lost contact' for example), the VC is detached
from the socket with a CAUSE/DIAG=00/F2 or 00/C3.
The inconsistent CAUSE/DIAG code should always be
00/C3 in this case. The problem occurs because of
an error introduced by APAR 2300088.
SOLUTION: The HNAS TCPIP socket close logic has been corrected
so that CAUSE/DIAG=00/C3 is always generated when a
VC is disconnected because of a TCPIP error rather
than a Clear Request.
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).
03-28-2005 - APAR 2300123
APAR: 2300123_E
STATUS: CLOSED
OPEN_DATE: 03-24-2005
CLOSE_DATE: 03-28-2005
SERVICE(S): VARY console command support
MANDATORY: NO
ORIGIN/REF: 230_CP
CPTECH: SFD
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 2300123.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300122, 2300116, 2300110
(and their associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): CONSHELP, CONSPID, CONSVARY
SOURCE(S): NASMAIN, XFNASWA
PROBLEM: The VARY console command does not allow a single socket
to be manipulated.
DESCRIPTION: The VARY console command requires the RNM=rmtname
modifier with the RMT argument (the default) and the
LNM=lclname with the LCL argument. Because the RNM=
modifier can name router REMOTE, all sockets on the
named router are varied either ON or OFF. There is no
way to restrict the command so that it only operates
on a single socket or small group of sockets. During
in-house testing, it is helpful to be able to close
individual sockets on a particular REMOTE while
leaving other sockets alone.
SOLUTION: The HNAS VARY console command processor has been
modified to accept a range of PCE IDentifiers which
will only be used when the RNM= and LNM= modifiers
are not active. This will permit a single REMOTE
socket or a group of sockets on the named REMOTE to
be manipulated without affecting the entire router.
In addition, the VARY console command processor now
displays the command arguments and asks for a
confirmation before actually performing the VARY
change. This should prevent an accidental change
that could affect production users.
Example: REMOTE named XOTCLNT1 is configured with
INIT=IDLE,VCLMT=4. Note that 5 sockets are
displayed when VCLMT=4 because an additional
socket is generated for TAP (Keep Alive)
processing. See documentation for details.
RNM=XOTCLNT1 DPCE <- establish RNM= and display sockets
PID NAME NASOPT TYPE TYPQ PROT STAT SUBST IPADDR ...
0008 XOTCLNT1 TCP RMT XOT IDLE T 010.117...
0009 XOTCLNT1 TCP RMT XOT CLSD 010.117...
000A XOTCLNT1 TCP RMT XOT CLSD 010.117...
000B XOTCLNT1 TCP RMT XOT CLSD 010.117...
000C XOTCLNT1 TCP RMT XOT CLSD 010.117...
VARY RNM= ID=9 ON <- reset RNM= (temp) and identify PCE
VARY PARMS: ACTION=ON TYPE=N/A ID=0009-0009
ENTER: N=ABORT, Y=EXECUTE
Y <- Execute VARY command
DPCE <- display router (RNM=XOTCLNT1 still set)
PID NAME NASOPT TYPE TYPQ PROT STAT SUBST IPADDR ...
0008 XOTCLNT1 TCP RMT XOT IDLE T 010.117...
0009 XOTCLNT1 TCP RMT XOT IDLE 010.117...
000A XOTCLNT1 TCP RMT XOT CLSD 010.117...
000B XOTCLNT1 TCP RMT XOT CLSD 010.117...
000C XOTCLNT1 TCP RMT XOT CLSD 010.117...
VARY <- vary entire router active (ACTION=ON,TYPE=RMT
are the defaults)
VARY PARMS: ACTION=ON TYPE=RMT RNM=XOTCLNT1
ENTER: N=ABORT, Y=EXECUTE
Y <- Execute VARY command
DPCE <- display router (RNM=XOTCLNT1 still set)
PID NAME NASOPT TYPE TYPQ PROT STAT SUBST IPADDR ...
0008 XOTCLNT1 TCP RMT XOT IDLE T 010.117...
0009 XOTCLNT1 TCP RMT XOT IDLE 010.117...
000A XOTCLNT1 TCP RMT XOT IDLE 010.117...
000B XOTCLNT1 TCP RMT XOT IDLE 010.117...
000C XOTCLNT1 TCP RMT XOT IDLE 010.117...
VARY OFF <- vary entire router inactive.
VARY PARMS: ACTION=OFF TYPE=RMT RNM=XOTCLNT1
ENTER: N=ABORT, Y=EXECUTE
Y <- Execute VARY command
DPCE <- display router (RNM=XOTCLNT1 still set)
PID NAME NASOPT TYPE TYPQ PROT STAT SUBST IPADDR ...
0008 XOTCLNT1 TCP RMT XOT IDLE T 010.117...
0009 XOTCLNT1 TCP RMT XOT CLSD 010.117...
000A XOTCLNT1 TCP RMT XOT CLSD 010.117...
000B XOTCLNT1 TCP RMT XOT CLSD 010.117...
000C XOTCLNT1 TCP RMT XOT CLSD 010.117...
The VARY HELP display has also been updated. The
following is produced when VARY ? is entered.
COMMAND DESCRIPTION (* => PRIVILEGED)
VARY *VARY RESOURCE STATE
ENTER> ID=lo{-hi} V {action}
OR> RNM=rmtname V {RMT} {action}
OR> LNM=lclname V {LCL} {action}
action = {ON|OFF} = {ACT|INACT}
General notes for the VARY command:
1) Enter RNM=rmtname modifier when RMT argument is
specified. RMT argument is assumed if omitted and
RNM=rmtname is active. When RNM=rmtname is used
and rmtname identifies an XOT router, for example,
all sockets for the router are varied ON or OFF.
2) Enter LNM=lclname modifier when LCL argument is
specified. LCL argument is assumed if omitted and
LNM=lclname is active but RNM=rmtname is not active.
3) Enter ID=lo{-hi} when neither RNM=rmtname or
LNM=lclname are active. This allows a single
resource or a group of resources to be varied ON
or OFF. When ID=xx identifies an XOT socket, for
example, that socket is varied ON or OFF.
ID=0 (=> global change) is not permitted.
4) ON (=ACT) is the default VARY action when omitted.
5) The VARY command operates on XTP|XOT LOCAL resources
and XTP|XOT|SPU REMOTE resources.
6) The VARY command requires the ID=, RNM= or LNM=
modifier.
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).
03-21-2005 - APAR 2300122 (was problem 2004247A, 2005049A, 2005052A)
APAR: 2300122
STATUS: CLOSED
OPEN_DATE: 09-03-2004 for 2004247A
02-18-2005 for 2005049A
02-22-2005 for 2005052A
CLOSE_DATE: 03-21-2005
SERVICE(S): QLLC support
MANDATORY: YES
ORIGIN/REF: 230_RWE,230_IZB
CPTECH: SFD
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 2300122.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300121, 2300116, 2300107
(and their associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): CONSMRMT, QLSSCP
SOURCE(S): NASMAIN, NASTCP, VCDD
PROBLEM1: REQDISCONT and NMVT PIUs are rejected with NAS8141W
message followed by a Clear Request.
PROBLEM2: ACB OPEN will fail when INIT-SELF arrives for an SLU
that is configured to be ACQUIREd.
PROBLEM3: INIT-SELF(0) and TERM-SELF(0) PIUs are being rejected.
PROBLEM4: INIT-SELF(1) and TERM-SELF(1) PIUs are being rejected.
DESCRIPTION1: HNAS does not decode REQDISCONT or NMVT but issues
a NAS8141W message and clears the call instead. The
REQDISCONT logic ultimately leads to Clear anyway
after DACTLU, DACTPU and DISCONT PIUs would have
been exchanged. The rejected NMVT also clears the
call when it should not.
DESCRIPTION2: When a QLLC SLU is configured to have an associated
applid that maps to an APPLNAME= operand value of
ACQUIRE, the ACB is opened and a SETLOGON (but not
a REQSESS) is passed to VTAM when the Power On
indication is received. This indicator is carried in
in the ACTLU response or NOTIFY request PIU. The
action taken for an ACQUIRE allows the SLU to be
passive, simply waiting to be bound. If an INIT-SELF
arrives while the SLU is waiting for a BIND request,
an attempt is made to open the ACB again in order to
pass a REQSESS to VTAM. The second ACB open is
rejected because the ACB is already opened. The
following alarm message is generated:
NAS3701W mchname OPEN FAILED FOR sluname ACB.
R15=08 ACBERFLG=00
DESCRIPTION3: INIT-SELF(0) and TERM-SELF(0) PIUs may be rejected with
SENSE=1002 when unusual buffer segmentation occurs and
the following alarm messages are issued:
NAS8241W CLIENT=002.241.202.250(01178) SOCKID=0001
PCEID=0032 NAME=XOTCNOT1
NAS8241W INVALID REQ FOR LU MTA31B10 ON PU MTA31PUR
RH/RU=0B800001 06810000 RC=1C
The RC=1C says 'RU size error'. This is occurring
because the INIT-SELF(0) and TERM-SELF(0) PIUs span
buffers and the RU decode routine expects a minimum
amount of the RU to be contained in the first
buffer a buffer chain. This can be happening if
there is a lot of TCPIP stream input that must be
broken up into individual PIUs or if the input spans
consecutive TCPIP RECEIVE operations. Although the
PIU data is segmented, it is otherwise correct.
The RC=1C 'RU size error' is incorrect.
DESCRIPTION4: INIT-SELF(1) and TERM-SELF(1) PIUs are rejected with
SENSE=1003 and the following alarm messages are issued:
NAS8241W CLIENT=002.241.202.250(01178) SOCKID=0001
PCEID=0032 NAME=XOTCNOT1
NAS8241W INVALID REQ FOR LU MTA31B10 ON PU MTA31PUR
RH/RU=0B800081 06810000 RC=20
The RC=20 says 'RU decode error'. This is occurring
because the INIT-SELF(1) and TERM-SELF(1) PIUs decode
logic was missing.
SOLUTION1: HNAS has been modified to inhibit the NAS8141W PIU
reject message for REQDISCONT and NMVT and process
these PIUs as required.
SOLUTION2: HNAS has been modified to test for an already open
ACB before attempting to open it again.
SOLUTION3: HNAS has been modified to ensure that the TH, RH
and RU for a PIU are moved into the first buffer of
a multi-buffer PIU so that the decode routine will
work properly.
SOLUTION4: HNAS has been modified to inhibit the NAS8241W PIU
reject message for INIT-SELF(1) and TERM-SELF(1) and
process these PIUs as required.
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).
03-10-2005 - APAR 2300121 (was unpublished problem 2005062A)
APAR: 2300121_E
STATUS: CLOSED
OPEN_DATE: 03-03-2005
CLOSE_DATE: 03-10-2005
SERVICE(S): MAINTENANCE (Enhanced Change Control)
MANDATORY: NO
ORIGIN/REF: 230_POR
CPTECH: SFD
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300121.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300119, 2300116, 2300114, 2300110, 2300088,
2300065, 2300056, 2300004
(and their associated APARs PREREQ chains)
Note: Due to the large number of PreReqs, we recommend
a refresh upgrade to pick up this optional APAR.
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): NASMAIN, NASTCP, XFBLK, XFBST, XFCNFGWA, XFGBLS,
XFIDR, XFNASWA, XFPCE, XFWTO, XFXTRN
PROBLEM: Some customers would like extended change control
information provided in all macro/source updates
because ISPF change control is not available.
DESCRIPTION: Members in HNASMAC and HNASMACX will show the same
'change date' when listed from ISPF no matter when
or how often they have been updated.
When a macro or source member is to be APARed for
the first time it is copied from HNASMAC or HNASSRC,
respectively, to HNASBASE using ISPF. This establishes
the base for subsequent updates and sets the creation
(=change) date for the base member.
Changes to a macro or source in HNASBASE are then
updated into the appropriate target library (HNASMAC
or HNASSRC) using the IEBUPDTE utility. IEBUPDTE
does not, however, also update the 'change date' but
instead copies the original ISPF stats from HNASBASE
to HNASMAC or HNASSRC.
If a subsequent problem fix then updates a macro in
HNASMAC, the updated macro in HNASMACX will also have
the same ISPF stats from HNASBASE. When displayed
using ISPF, it will appear that no change had been
done based on the 'change date'. You have to open
the macro to actually see the changes.
Because IEBUPDTE executes as a batch utility, the
'change date' cannot be updated at the same time as
the macro is updated because ISPF Library Management
Services are not available to programs that run in
TSO or MVS background.
The alternative to ISPF Stats 'change date' controls
is to provide additional change control documentation
as comments within the affected macro(s) in HNASMAC
and/or HNASMACX.
SOLUTION: Change control content (Date, APAR/Problem ID and
Comments) will now be added to all 'Maintenance
Record' areas so that users can easily identify a
higher level of change control then currently
provided using DNAS APAR or DMAP APAR.
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).
03-10-2005 - APAR 2300120 (was unpublished problem 2005069A)
APAR: 2300120
STATUS: CLOSED
OPEN_DATE: 03-09-2005
CLOSE_DATE: 03-10-2005
SERVICE(S): DRMT console command processing (after MRMT)
MANDATORY: YES
ORIGIN/REF: 230_NBG
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300120.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300107 (and the associated APARs PREREQ chains)
OBJECT(S): CONSDRMT
SOURCE(S): N/A
PROBLEM: D23-10040007 ABEND occurs during DRMT display after
multiple DTE addresses were added via the MRMT command.
DESCRIPTION: Customer was modifying an SVC0= SLU entry to add
multiple DTE addresses using the MRMT command. After
modification, the customer entered a DRMT command to
display his changes. He started by adding 1 DTE
address and the DRMT display confirmed this. He then
added 2 DTE addresses and the DRMT command again
confirmed his change. He finally entered 3 DTE
addresses and the subsequent DRMT command caused the
ABEND.
This D23 ABEND says "parmlist validity error, mutually
exclusive functions". This is reminiscent of an error
we were getting while debugging the Console Subsystem
NETVIEW support.
After reviewing ABEND DUMP, it now appears that ABEND
is occurring because the DRMT processor is overlaying
flags in the extended format WTO when it formats the
3 DTE addresses. The area reserved for formatting was
never increased when logic was added that allowed for
3 DTE addresses plus an outbound CUD to be specified.
This bug was introduced in V2R2M0 on 08-09-2002.
SOLUTION: The DRMT console command processor has been modified
to allow for larger displays thus preventing the WTO
flags from being overlaid which will prevent the
D23 ABEND.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
03-08-2005 - APAR 2300119 (was problem 2005032B, ref 2005048A)
APAR: 2300119
STATUS: CLOSED
OPEN_DATE: 02-01-2005
CLOSE_DATE: 03-08-2005
SERVICE(S): TCPIP SELECT timeout processing and
Socket connection lost Clear indication.
MANDATORY: YES
ORIGIN/REF: 230_POR,230_SNC
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300119.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300108 (and associated APARs PREREQ chains)
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM1: 0C4-10 ABEND can occur in client TCPIP SELECT timeout
processor due to bad base register.
PROBLEM2: The internally generated Clear that HNAS generates
when a socket connection is lost erroneously uses a
non-zero cause code (09).
DESCRIPTION1: Logic added by APAR 2200073 (V2R2M0) to recover from
a lost SELECT interrupt starts a timer when SELECT is
issued for a socket to detect pending input data. If
the timer expires, it indicates that the TCPIP stack
'forgot' to signal the end of the SELECT. In this
case HNAS issues a CANCEL which then forces the
stack to end the SELECT. This timeout is normally
a very rare condition. The ABEND is occurring because
a transmit operation is also running before the SELECT
timer expires. The transmit processor changes the
active base register value so when the timeout processor
receives control it is no longer using the base register
value that it had established but is instead using that
of the transmit processor. This wrong base register
is what causes the ABEND.
Additionally, it appears that the SELECT timeout is
occurring because the timer is not aborted when the
SELECT ends normally. This means that the timeout
processor is being dispatched for a non-event.
DESCRIPTION2: When a lost socket connection is reported via a
NAS2401W RECEIVE REQUEST FAILED, RC=FFFFFFFF 00000036
alarm message, HNAS TCPIP logic generates an internal
Clear Request so that higher levels can do the required
VC/LU cleanup associated with a received Clear. The
internally generated Clear that is generated carries
a non-zero cause code of 09 (10011309F2). The special
cause code assignment was done to differentiate this
unusual condition from other types but ultimately
caused confusion because HNAS does not generate any
other non-zero clear cause codes as denoted in the
documentation. This condition was observed while
debugging unpublished problem 2005048A.
SOLUTION1: 1) The SELECT timeout processor has been corrected to
restore its own base register before continuing its
execution. This will prevent the 0C4 ABEND.
2) The SELECT timer is now stopped when a SELECT ends
normally. This will prevent the timeout processor
from getting control when it should not.
SOLUTION2: The HNAS TCPIP error logic has been modified to
generate an internal Clear Request with a zero cause
code when a socket connection is lost. The Clear will
now be 10011300F2. The diagnostic code of F2 remains
the same which indicates 'disconnect, abnormal'.
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).
03-04-2005 - APAR 2300118 (was unpublished problem 2005060A)
APAR: 2300118_E
STATUS: CLOSED
OPEN_DATE: 03-01-2005
CLOSE_DATE: 03-04-2005
SERVICE(S): PVC and LU Bind Failures
MANDATORY: RECOMMENDED
ORIGIN/REF: 230_HVB
CPTECH: PRT
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: REFRESH
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300118.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 02-17-2005
With APAR: 2300109 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHRQ
SOURCE(S): N/A
Problem 1: HNAS does not issue an information message when a
PVC resource is bound.
Problem 2: HNAS does not issue an alert message when a BIND from
a PLU is rejected.
DESCRIPTION 1: Because PVCs are always active, HNAS tries to establish
a session with the PLU using a REQSESS macro (asks PLU
for a BIND) issued by timer logic. There can be many
hours between the NAS3798I session starting message and
the time when the PLU sends a BIND to start the session.
With this APAR on, the following message (Solution 1)
is issued when the BIND is received:
DESCRIPTION 2: See PROBLEM 2.
SOLUTION 1: The following message is issued when a BIND activating
a PVC session is received:
NAS3797I LU lu-name RECEIVED BIND FROM PLU plu-name
SOLUTION 2: The following message is issued when HNAS rejects a
BIND from the PLU.
NAS4706W LU lu-name REJECTING BIND FROM PLU plu-name
SENSE=xxxxxxxx
In the above xxxxxxxx is the bind failure sense code.
These codes are described in the Alert Messages
section of the HNAS Messages and Codes manual.
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).
03-04-2005 - APAR 2300117
APAR: 2300117
STATUS: CLOSED
OPEN_DATE: 03-03-2005
CLOSE_DATE: 03-04-2005
SERVICE(S): REMOTE CONSOLE support
MANDATORY: NO
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300117.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300110 (and associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): NASCONS, NASUTIL
SOURCE(S): N/A
PROBLEM: Remote console VC is randomly cleared while executing
a display command like DMAP NASTCP.
DESCRIPTION: When the remote console VC output window size is set
to its maximum value of 7 and the number of lines in a
display is an exact multiple of 7 and window rotations
are slow to be received, a Clear with CAUSE/DIAG=00/82,
DIAGX=14 can be generated. This occurs when the
console prompt message is scheduled at the end of the
display. This is because the XOTXMT routine limits
the number of queued data packets to 7. The console
prompt message becomes the eight packet in the queue.
The VCLXHCT field counts the queued packets. The
VCLXHLM field is its limit which is set to 7 when the
VC comes active. VCLXHCT is incremented when a packet
is queued by XOTXMT. It is decremented when packets
are transmitted and then acknowledged by received RRs.
SOLUTION: The console subsystem logic has been modified to set
VCLXHLM=2*W+1 when the remote console PCE is allocated
to the VC. This prevents the Clear described above.
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).
03-03-2005 - APAR 2300116 (was problem 2005012A and 2005028A)
APAR: 2300116
STATUS: CLOSED
OPEN_DATE: 01-12-2005 for 2005012A
01-28-2005 for 2005028A
REVISE_DATE: N/A
CLOSE_DATE: 03-03-2005
SERVICE(S): LLC3 (QLLC) support
MANDATORY: NO, recommended.
ORIGIN/REF: 230_CIN,230_IZB
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300116.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300114, 2300107, 2300106, 2300102, 2300060
(and associated APARs PREREQ chains)
Note: Due to the large number of PreReqs, we recommend
a refresh upgrade to pick up this APAR.
OBJECT(S): CNFGOPTS, CONSDRMT, CONSMRMT, QLSSCP
SOURCE(S): XFNASWA
PROBLEM1: Customer reports that an SPU call is rejected because
the SPU is already in use.
PROBLEM2: Customer reports that an SPU QXID request is timing out.
PROBLEM3: INIT-SELF that is received before ACTLU response is
being processed when it should be rejected.
DESCRIPTION1: When a call is received for an SPU that is already
active, the following alarm message is generated:
NAS8102W PU FOR DTEADDR=DDDDDDDDDDDDDDD
IDBLK/IDNUM=XXXXXXXX
ON MCH XXXXXXXX
NAS8102W WAS IN USE WHEN SELECTED
This should not occur unless HNAS has not received
a notification that the previous call was terminated.
Customer indicates that an SNA server is acting as
the QLLC PAD and that the problem only occurs in
one of two HNAS partitions that are configured
identically in so far as the SPUs are concerned.
This situation is reminiscent of a problem that
occurred on the FEP running the 270x Emulator
Program. When an EP (eg, BTAM) host application
terminated abnormally and was subsequently
restarted, the application would come up issuing
ENABLE commands to all its subchannels. However,
because the application terminated abnormally,
no DISABLE commands were issued to deactivate
the subchannels when the application was going
down. The EP still recorded the subchannels as
being enabled. This caused the subsequent ENABLE
commands to be rejected. A mismatch thus existed
between the EP and the host application. The
solution was to treat an ENABLE command to an
already enabled subchannel as a DISABLE/ENABLE
sequence.
DESCRIPTION2: From traces collected by the customer, it appears that
the SPU is returning a QXID request as a response
to a QXID request that HNAS sends. HNAS ignores SPU
QXID request and a timeout occurs even though the SPU
QXID request carries a valid IDBLK/IDNUM value. The
timeout causes following alarm message to be issued:
NAS8191W CLIENT=002.241.202.250(01178) SOCKID=0001
PCEID=0032 NAME=XOTCNOT1
NAS8191W XID TIMEOUT FOR PU MTA31PUR
HNAS retries the QXID request 3 times and eventually
clears the call with CAUSE/DIAG=000/089.
A NPSI trace of the same SPU revealed that the QXID
request from the SPU is treated as a response by NPSI
thus satisfying the QXID request that NPSI sends.
Apparently, a QXID request 'collision' is treated as
as response by both ends.
Note that this situation occurs in HNAS no matter how
the SPU is configured (PEER|PRI|SEC) because the SPU
is not examined until after the QXID exchange is
complete. The QXID exchange is required in order to
retrieve the IDBLK/IDNUM value that is used to
identify the SPU within the HNAS configuration.
DESCRIPTION3: The HNAS log also shows that HNAS is receiving
INIT-SELF requests for SLUs that are still waiting
for their ACTLU response. HNAS should reject these
requests but does not. The INIT-SELF (or any other
request in ACTLU pending state) violates the rules
for Immediate Response Mode protocol.
SOLUTION1: HNAS has been modified to allow OPTIONS=REUSEBSYSPU
for an SPU which allows a new Call to an already
connected SPU to be treated as a Clear/Call sequence
much like the EP scenario described above. The old
SPU call is cleared to allow the new call to continue.
SOLUTION2: HNAS has been modified to treat an QXID request as a
response if the SPU is configured for PEER or SEC.
SOLUTION3: HNAS will now reject any request received from an
SLU before the ACTLU completes with 200D error sense
(Response Owed Before Sending Request).
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
03-01-2005 - APAR 2300115
APAR: 2300115
STATUS: CLOSED
OPEN_DATE: 02-24-2005
CLOSE_DATE: 03-01-2005
SERVICE(S): QLLC
MANDATORY: YES
ORIGIN/REF: 230_IZB
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 2300115.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 05-12-2004
With APAR: 2300031 applied.
SUPERSEDES: N/A
OBJECT(S): MCHBFR
SOURCE(S): N/A
PROBLEM: QLLC session ends unexpectedly with DACTLU and a VTAM
RECEIVE failed message in SYSPRINT.
Description: When the error occurs the following message is logged
in SYSPRINT:
mch-nm VC vc-addr lu-nm LU lu-addr RPL=rpl-addr
RECV SPEC (SYN) R15=04 R0=14 FDB2=1E
The 04/14/1E RECEIVE ending indicates that HNAS has
passed a bad address or count field in an RPL. This
is caused by incorrect logic used when the HNAS buffer
size is smaller than the X25 packet packet size. The
error is for QLLC sessions only.
SOLUTION: HNAS modified to properly chain and fill buffers when
multiple buffers are required to contain an X25 packet
for a QLLC session.
CIRCUMVENTION: Code a buffer size (BUILD statement BFRSIZ= parm)
large enough to contain an X25 packet. Because of
packet header overhead the size (for V2R3M0) should
be 52 + the X.25 packet size.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
03-02-2005 - APAR 2300114 (was unpublished problem 2005055A)
APAR: 2300114
STATUS: CLOSED
OPEN_DATE: 02-25-2005
CLOSE_DATE: 03-02-2005
SERVICE(S): HNAS installation for OS/390
MANDATORY: NO, unless you are running OS/390
ORIGIN/REF: 230_IES
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 2300114.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300110, 2300108
(and associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): NASEND (record 2300114 APARID for macro only change)
SOURCE(S): XFBLK, XFIDR, XFNASWA
PROBLEM: NASMAIN and NASTCP assembler steps end with CC=12.
DESCRIPTION: The new BASEND parameter was added by APAR 2300108 so
that limits could be placed in base register USING
extents so that the NASMAIN and NASTCP assemblies
during an SMP/E install completed with CC=0. This
works well for the z/OS version of the high level
assembler (HLASM) but causes problems for the
OS/390 version of HLASM. This condition was observed
under OS/390 V2R5.
SOLUTION: The XFBLK, XFIDR and XFNASWA macros have been modified
to distinguish HOST=OS390 from HOST=ZOS so that the
BASEND= parameter can be used for z/OS systems but
not OS/390. This restores the logic to its previous
state for OS/390. HOST=OS390 will now prevent the
BASEND= parameter from being used.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
02-25-2005 - APAR 2300113 (was unpublished problem 2005052B)
APAR: 2300113
STATUS: CLOSED
OPEN_DATE: 02-23-2005
CLOSE_DATE: 02-25-2005
SERVICE(S): CONSOLE subsystem fixes
MANDATORY: NO
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300113.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300088
(and associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): CONSDPRM, CONSLNCT
SOURCE(S): N/A
PROBLEM1: Remote console session can hang at SIMATTN prompt
when LNCT=1 specified.
PROBLEM2: After TRCALL ON is entered, a 'BOX' character is
displayed at the end of some DPARM entries for a
remote console.
DESCRIPTION1: When line count is set to 1 (LNCT=1) via the remote
console, the operator can no longer enter commands.
14:21:53 Z230ZOS0> lnct=1
14:21:59 Z230ZOS0> *** <- asterisk appears when
enter key is depressed.
LNCT=1 prevents any console command output from being
displayed essentially hanging the remote console
session.
DESCRIPTION2: Due to an error introduced by APAR 2300088, invalid
data (X'1200') is be appended to the end of the
TRCBFR, TRCDATA, TRCDISP and TRCIO displays after
TRCALL is entered. The binary data prints as a
'BOX' character on some terminals. For example:
12:16:28 TRCBFR TMR CONS NETV UTIL TCP XTP XOT {BOX}
12:16:28 TRCDATA TMR CONS NETV UTIL TCP XTP XOT {BOX}
12:16:28 TRCDISP TMR CONS NETV UTIL TCP XTP XOT {BOX}
12:16:28 TRCIO TMR CONS NETV UTIL TCP XTP XOT {BOX}
SOLUTION1: The LNCT= modifier processor has been modified to
reject a value less than 10. This will prevent
the remote console hang condition.
SOLUTION2: The DPARM command processor has been modified to
delete the invalid data at the end of the TRCBFR,
TRCDATA, TRCDISP and TRCIO displays.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
02-25-2005 - APAR 2300112_R (Refresh required)
APAR: 2300112_R_E
STATUS: CLOSED
OPEN_DATE: 02-23-2005
CLOSE_DATE: 02-25-2005
SERVICE(S): CONSOLE DNAS command
MANDATORY: NO
ORIGIN/REF: 230_CP
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: N/A - Product refresh required for this enhancement.
COREQ(S): N/A
PREREQ(S): APAR 2300089
(and associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): CONSDNAS
SOURCE(S): N/A
PROBLEM: It is not not easy to tell using the DNAS command
whether a distribution was created using SMP or
non-SMP or if a custom MACLIB and/or OBJLIB was
required for the distribution.
DESCRIPTION: The DNAS command provides useful information about a
customer's environment including a flag in SHIPID=
that identifies the distribution creation type
(see below) but a text version of distribution type
as custom library names would make it immediately
evident: DIST=SMP/E|NON-SMP, CUSTMAC=dsname and
CUSTOBJ=dsname.
This new information would be in addition to the flags
from the SHIPID= parameter:
SHIPID=distribution-type_CustomUserMod-flags_custref#
0000000011099999 <- sample non-smpe with custom MACX
|||| | and OBJX changes.
|||| |_ n CUSTOMER ID REFERENCE nnnnn.
||||_______ 1 => CUSTOM OBJECT CHANGES INCLUDED
||| 0 => NONE
|||________ 1 => CUSTOM MACRO CHANGES INCLUDED
|| 0 => NONE
||_________ 1 => CUSTOM SOURCE CHANGES INCLUDED
| 0 => 0 NONE
|__________ 1 => SMP/E DISTRIBUTION TYPE
0 => NON-SMP
SOLUTION: The DNAS command processor has been modified to
display the distribution type in the header message
as follows:
VERSION=V2R3M0 HOST=OS390|ZOS ASMDATE=02/23/05 ...
... DIST=SMP/E
--- or ---
VERSION=V2R3M0 HOST=OS390|ZOS ASMDATE=02/23/05 ...
... DIST=NON-SMP
followed by (if custom HNASMACX used)
CUSTMAC=dsname
followed by (if custom HNASOBJX used)
CUSTMAC=dsname
CIRCUMVENTION: N/A
APPLY_INFO: N/A - Product refresh required.
02-22-2005 - APAR 2300111 (was problem 2005034A)
APAR: 2300111
STATUS: CLOSED
OPEN_DATE: 02-03-2005
CLOSE_DATE: 02-22-2005
SERVICE(S): PVC
MANDATORY: YES
ORIGIN/REF: 230_HVB
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 2300111.ZIP file)
PREREQ(S): Distribution dated after: 11-16-2004
With APARs: 2300083 and 2300085 applied.
SUPERSEDES: N/A
OBJECT(S): MCHNRQC, MCHTMR, VCCLRQ
SOURCE(S): N/A
PROBLEM: PVC session fails to reactivate (see NAS5705W) when
the host PLU application is taken down and reactivated.
DESCRIPTION: HNAS uses a VC PVC reconnect timeout to ensure that a
PVC LU is bound to it's PLU if the PLU name is known.
When the timer expires the VCPVCCN (PVC connect to
PLU) routine is called to set up the SLU/PLU session.
The routine assumes that the PVC LU's ACB is not open.
If the assumption is correct the ACB is opened and the
standard SET LOGON, REQSESS sequence is executed to
establish the SLU/PLU session by asking the PLU for
a BIND. If the REQSESS fails because the PLU is not
active a 4 minute PVC reconnect timeout is started.
The HNAS PVC LU's ACB is left open for the next PVC
connect sequence. When the timer expires the VCPVCCN
routine finds the open ACB and incorrectly assumes that
the reconnect sequence is not needed. This keeps the
HNAS SLU to PLU session from being activated.
SOLUTION: HNAS logic corrected so that PVC reconnect is retried.
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).
02-21-2005 - APAR 2300110 (related to unpublished problem 2005047A)
APAR: 2300110_E
STATUS: CLOSED
OPEN_DATE: 02-16-2005
CLOSE_DATE: 02-21-2005
SERVICE(S): CONSOLE subsystem trace commands
MANDATORY: NO, but recommended
ORIGIN/REF: 230_CP,230_BNP
PTF_CLASS: ENHANCEMENT-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300110.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300108, 2300098, 2300094, 2300088,
2300082, 2300061, 2300045, 2300022
(and associated APARs PREREQ chains)
Note: Due to the large number of PreReqs, we recommend
a refresh upgrade to pick up this APAR.
OBJECT(S): CONSDMAP, CONSDPCE, CONSHELP, CONSTALL, CONSTBFR,
CONSTDAT, CONSTDSP, CONSTIO, CONSTPCE, CONSTPRT,
CONSTRTR, NASCONS, NASUTIL
SOURCE(S): NASMAIN, SYSLIN, XFBLK, XFMODMAP, XFWTO, XFXTRN
ORIGINAL
PROBLEM: TRCALL OFF command does not stop MCH tracing.
DESCRIPTION: Customer entered the TRCALL OFF command expecting the
command to stop ALL tracing, however, LU, VC, MCH and
MCHX trace entries continued to be logged. This occurs
because the TRCALL OFF command only stops PCE tracing.
LU, VC, MCH and MCHX traces are started by default when
HNAS is started. To stop LU, VC, MCH and MCHX tracing
(as well as PCE tracing), the TRCALL STOP command should
be used.
TRCALL OFF operates on PCEs only. TRCALL STOP operates
on all resources.
The TRCALL command was originally created for PCEs only.
Subsequently, support was added to start and stop all
resource tracing using the STRT and STOP arguments while
the ON and OFF arguments were still reserved for PCEs.
We recognize that this is confusing and that the PCE
trace functions should have been removed from TRCALL a
long time ago so that the ON and OFF arguments could be
treated identically as the STRT and STOP arguments,
respectively.
SOLUTION: The TRCALL command processor has been modified to
eliminate the PCE only functions for the ON and OFF
arguments. These arguments will now provide the same
functions as the STRT and STOP arguments, respectively.
The PCE trace function is now controlled by the TRCPCE
command as follows:
TRCPCE ON|OFF
will start or stop PCE dispatcher, I/O, buffer and data
tracing for the PCEs identified by the RNM= or ID=
command modifiers with a given RNM= value overriding
any ID= values that are also set. If no RNM= or ID=
values are set, the TRCPCE ON|OFF command operates on
all PCEs.
TRCPCE ALLON|ALLOFF
will start or stop PCE dispatcher, I/O, buffer and data
tracing for all PCEs regardless of the RNM= or ID=
modifier settings.
In addition to the changes for TRCALL and TRCPCE, the
TRCBFR, TRCDATA, TRCDISP and TRCIO command have been
modified to accept the ALLON and ALLOFF arguments.
The processing for the ON and OFF arguments has not
changed but is listed below to show deference for the
ALLON and ALLOFF arguments. The commands operate as
follows:
TRCBFR ON|OFF
will start or stop PCE buffer tracing for the PCEs
identified by the RNM= or ID= command modifiers
with a given RNM= value overriding any ID= values
that are also set. If no RNM= or ID= values are set,
the TRCBFR ON|OFF command operates on all PCEs.
TRCBFR ALLON|ALLOFF
will start or stop PCE buffer tracing for all PCEs
regardless of the RNM= or ID= modifier settings.
TRCDATA ON|OFF
will start or stop PCE data tracing for the PCEs
identified by the RNM= or ID= command modifiers
with a given RNM= value overriding any ID= values
that are also set. If no RNM= or ID= values are set,
the TRCDATA ON|OFF command operates on all PCEs.
TRCDATA ALLON|ALLOFF
will start or stop PCE data tracing for all PCEs
regardless of the RNM= or ID= modifier settings.
TRCDISP ON|OFF
will start or stop PCE dispatcher tracing for the PCEs
identified by the RNM= or ID= command modifiers
with a given RNM= value overriding any ID= values
that are also set. If no RNM= or ID= values are set,
the TRCDISP ON|OFF command operates on all PCEs.
TRCDISP ALLON|ALLOFF
will start or stop PCE dispatcher tracing for all PCEs
regardless of the RNM= or ID= modifier settings.
TRCIO ON|OFF
will start or stop PCE I/O tracing for the PCEs
identified by the RNM= or ID= command modifiers
with a given RNM= value overriding any ID= values
that are also set. If no RNM= or ID= values are set,
the TRCIO ON|OFF command operates on all PCEs.
TRCIO ALLON|ALLOFF
will start or stop PCE I/O tracing for all PCEs
regardless of the RNM= or ID= modifier settings.
In addition to the changes for the above commands, the
following alert messages were changed to display the
name of the console PCE that issued the TRCPRNT, TRCTRAP
TRCALL command.
For TRCPRNT ON
NAS0210W SYSPRINT TRACE LOGGING ENABLED BY consname,
MORE CPU CYCLES REQUIRED
For TRCPRNT OFF
NAS0211I SYSPRINT TRACE LOGGING DISABLED BY consmame
For TRCALL SUSP or TRCTRAP SUSP
NAS0050A TRACING SUSPENDED BY consname
For TRCALL RSME or TRCTRAP RSME
NAS0060W TRACING RESUMED BY consname
For TRCTRAP SNAP
NAS0080A SNAPSHOT DUMP TAKEN BY consname
For TRCTRAP RSMESNAP
NAS0080W SNAPSHOT DUMPING RESUMED BY consname
Where consname is now given, 'COMMAND' used to be
displayed. This change was made so that a SYSCONS
console operator will know if the trace state has
been changed by a REMOTE console operator. For the
local SYSCONS, consname=WAPCECON. For a REMOTE
console, consname=RCONxxxx where xxxx is the number
of the REMOTE console PCE.
CIRCUMVENTION: To stop all LU, VC, MCH and MCHX tracing, enter
TRCALL STOP.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
02-17-2005 - APAR 2300109 (was problem 2005025A)
APAR: 2300109
STATUS: CLOSED
OPEN_DATE: 01-25-2005
CLOSE_DATE: 02-17-2005
SERVICE(S): QLLC
MANDATORY: YES
ORIGIN/REF: 230_CIN
CPTECH: PRT
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and/or (SRC) HNASMACX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300109.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 11-15-2004
With APAR: 2300083 applied.
SUPERSEDES: N/A
OBJECT(S): MCHHRQ, MCHRL3RR, XOTBXM2
SOURCE(S): VTMEXIT, VTMRCV1
PROBLEM: Customer reports that SLU BIND is being rejected with
0815 sense (function active) and the following alarm
message is issued:
NAS3799I LU lu-name ENDING SESSION ON MCH mch-name
HNAS CAUSE/DIAG=000/194 (00/C2) DIAGX=0000
DESCRIPTION: This problem results from an HNAS error in processing
of a PLU's CLSDST OPTCD=PASS operation used to present
an UNBIND (bind forthcoming)-BIND sequence to HNAS.
The unbind and bind indications are usually presented
in the same HNAS service cycle. It is possible for
the BIND to precede the UNBIND and when this happens
HNAS sends a bind to a remote that's already bound.
The remote (correctly) rejects this bind.
SOLUTION: HNAS modified to proper process the above sequence.
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).
02-15-2005 - APAR 2300108 (was unpublished problem 2005043A)
APAR: 2300108
STATUS: CLOSED
OPEN_DATE: 02-12-2005
CLOSE_DATE: 02-15-2005
SERVICE(S): SMP/E distribution installation
MANDATORY: NO, unless assembler return code of 4 is objectionable
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300108.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300107, 2300104, 2300065
(and associated APARs PREREQ chains)
OBJECT(S): N/A
SOURCE(S): NASMAIN, NASTCP, XFIDR, XFNASWA
PROBLEM: SMP/E assembly of the NASMAIN and NASTCP macros
result in assembler return code of 4 instead of 0.
The following assembler error message is also
generated:
** ASMA303W Multiple address resolutions may
result from this USING and the
USING on statement number xxxx
DESCRIPTION: For SMP/E distributions, this condition occurs because
the assembler is invoked with the default option of
USING(NOLIMIT,MAP,WARN(15)).
For non-SMP/E distributions, this condition does not
occur because the assembler is invoked with a specified
option of USING(NOLIMIT,MAP,WARN(11)).
This was done to provide backward compatibility with
older levels of the assembler that allowed a USING for
the same CSECT or DSECT to be set to the highest valued
register without an intervening DROP. The rule was that
the register with the larger metric would always win.
For example, if the following USING is in effect:
USING NASMAIN,R10
and then the following USING is issued
USING NASMAIN,R11
R11 would replace R10 as the NASMAIN base register.
Without the USING(NOLIMIT,MAP,WARN(11)) option, the
assembler now flags the second USING as an error and
the following error message is generated:
** ASMA301W Prior active USING on statement number xxxx
overridden by this USING
As it turns out, both the ASMA303W and ASMA301W errors
can actually be ignored. However, due to the default
USING() options employed by SMP/E, they will be present
in the assembly output for NASMAIN and NASTCP.
SOLUTION: The XFIDR macro has been modified to accept a new
BASEND parameter which is used to limit that range
of a USING. The NASMAIN and NASTCP macros have been
modified to utilize the new XFIDR BASEND parameter so
that their USINGs do not overlap. This will avoid
the need for the USING(NOLIMIT,MAP,WARN(11)) option
an eliminate the ASMA303W message. NASMAIN and NASTCP
have also been modified to use an intervening DROP
between 2 USINGs that set the base for the same
CSECT/DSECT to different registers. This will
eliminate the ASMA301W message.
CIRCUMVENTION: Ignore the RC=4 assembler return code.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
02-16-2005 - APAR 2300107 (was problem 2004089A)
APAR: 2300107
STATUS: CLOSED
OPEN_DATE: 03-29-2004
REVISE_DATE: 02-16-2005 - Correct memo syntax typo in FAC= sample.
Original sample was missing ().
CLOSE_DATE: 02-10-2005
SERVICE(S): PVC SUPPORT
MANDATORY: NO if rmtname omitted from HNAS CDF PVC= string where
only the router initiates the setup. In this case
HNAS defaults to networks values.
YES if HNAS PVC default window sizes (4/4) and packet
sizes (256/256) do not match router configuration and
rmtname is specified on the HNAS CDF PVC string.
ORIGIN/REF: 230_CP,230_BPO,230_HVB
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX and (SRC) HNASMACX members
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300107.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300106, 2300100, 2300095, 2300094,
2300087, 2300073, 2300061, 2300036
(and associated APARs PREREQ chains)
Note: Due to the large number of PreReqs, we recommend
a refresh upgrade to pick up this APAR.
OBJECT(S): CNFGPVC, CNFGSVC0, CNFGSVC3, CNFGSVC5, CONSDRMT,
MCHINI, MCHPVCI, NASCNFG, VCUT1, XOTBXM
SOURCE(S): NASMAIN, VCDD, XFNASWA
PROBLEM: PVC session fails to activate (see NAS7704W/NAS7707W)
when HNAS initiates the PVC Setup with packet and
window size values that don't match the network
requirements.
Customer reported that PVCs setup fails after IMS
is taken down and restarted. PVCs worked prior to
this event which suggests that they were set up by
the router, not HNAS. This is based on the fact
that the following messages are being generated
when IMS is restarted.
NAS7704W REMOTE 223.220.021.099(03796) RESPONDED TO
NAS PVC SETUP W/STATUS=18
NAS7708W XOT PVC SETUP INIT=SERIALBVPVC
RESP=SERIAL4/0
DESCRIPTION: HNAS does not allow the PVC packet and window sizes
to be specified in the CDF. The defaults set by HNAS
are packet size=256 and window size=4 for both inbound
and outbound flow. These values are carried in the
PVC Setup packet sent by HNAS to start the PVC session.
If the values are rejected by the remote because the
remote's configuration has different values then a ZAP
is required to make HNAS agree with the remote.
This problem rarely occurs because in almost all cases
the router starts the PVC establishment process and
HNAS will set the packet and window sizes to the values
provided from the routers PVC Setup packet.
SOLUTION: The PVC operand has been modified to allow an MXT to
be associated with a PVC entry. The packet size and
window size for the PVC will be extracted from the FAC=
operand on the associated MXT via facility 42 and 43,
respectively.
PVC=(...,slunm/llc/applid/ifname/rmtname/mxtname....)
mxtname REMOTE TYPE=MXT ; typical network values
FAC=(420707, ; set packet size to 128
430202) ; set window size to 2
mxtname REMOTE TYPE=MXT ; private network values
FAC=(420A0A, ; set packet size to 1024
430707) ; set window size to 7
Note: In this enhancement, the PVC packetsize and
windowsize are expressed using SVC Facility
Parameter values normally used in Call Request
packets. For PVC's the packet and window sizes
are provided in the PVC Setup packet.
CIRCUMVENTION: ZAP is available (via problem 2004089A) to change
default packet and window sizes to network values.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
02-10-2005 - APAR 2300106
APAR: 2300106
STATUS: CLOSED
OPEN_DATE: 02-09-2005
CLOSE_DATE: 02-10-2005
SERVICE(S): Configuration processing for SVC0/5 operand and/or
Console Subsystem MRMT command processing for SVC0/5.
MANDATORY: NO unless there is a requirement for an SVC0/5 Xidnum
value to contain a 'B' character and the Xidnum value
is delimited by an 'I' type character.
ORIGIN/REF: 230_SDD
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300106.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300087 (and associated APARs PREREQ chains)
OBJECT(S): CNFGSVC0, CNFGSVC5, CONSMRMT
SOURCE(S): N/A
PROBLEM: Logic introduced by enhancement APAR 2300083 which
allows the SVC0= and SVC5= operands to specify SLUs
as callin (I) or callout (O) and twoway (T) causes
errors during CDF and MRMT processing.
DESCRIPTION: When a 'B' character is contained in the Xidnum value
for an SVC0/5 entry and the Xidnum value is delimited
by an 'I' type character, the following error message
is displayed during the CDF scan:
NAS1321E ERROR: REMOTE MCH10001/XDCB710I1
If the same data is entered using the MRMT command,
the following error message is displayed:
NASC522E INPUT DATA INVALID, REQUIRED
Example: MRMT SVC0=MCH10001/XDCB710I0
SOLUTION: The SVC0= and SVC5= operand logic has been corrected
to process the 'I' type character properly when a 'B'
is embedded in the Xidnum value.
CIRCUMVENTION: The Xidnum value and applid value can be set using
the MRMT command if they are provided using separate
commands as follows:
MRMT SVC0=MCH1001/XDCB710
MRMT SVC0=MCH1001/I0
NOTE: There is no circumvention for the CDF error.
If you need to supply both an Xidnum value
containing a 'B' character and an applid value
following the 'I' type, you will need to apply
this APAR or use the successive MRMT commands
described above.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-31-2005 - APAR 2300105 (was unpublished problem 2005024A)
APAR: 2300105
STATUS: CLOSED
OPEN_DATE: 01-24-2005
CLOSE_DATE: 01-31-2005
SERVICE(S): CONSOLE MRMT
MANDATORY: YES
ORIGIN/REF: 230_CIN
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 2300105.ZIP file)
COREQ(S): N/A
PREREQ(S): Distribution dated after: 11-15-2004
With APARs: 2300084 applied.
SUPERSEDES: N/A
OBJECT(S): CONSMRMT, VCDAT
SOURCE(S): N/A
PROBLEM: When a MRMT (modify remote) command is used to change
an LLC5 or LLC0 resource from callout to callin, the
modified resource will not be useable.
When an inbound call for the new resource arrives
the following occurs:
1) If an interpret table was used to locate a PLU for the
new call a NASHALT (USER 198 ABEND) will occur with the
following messages in SYSPRINT:
mch-nm VC vc-addr lu-nm LU lu-addr RPL=rpl-addr REQSESS
SENT TO VTAM, R15=20 R0=29
NAS0106S BUFFER=bfr-addr RELEASE REJECTED, ALREADY FREE
HALT AT LOC loc-addr IN XFBFR : XFBFR FAILURE
2) If an interpret table was not used to locate a PLU for
the new call the call will be cleared diagnostic 143
(REQSESS failed).
DESCRIPTION: When the MRMT command changes a callout ('O') resource
to a callin ('I') resource an LU field is not correctly
reset. This leads to a REQSESS being issued using a
VTAM ACB that is not open. The REQSESS fails and the
call will be cleared (2, above). The ABEND (1, above)
results when an interpret table is used because the
HNAS VTAM error processor (called when the REQSESS
fails) releases the buffer with the inbound text that
was used in conjunction with the interpret table to
select a PLU. The routine that issued the REQSESS
also releases this buffer (logic error).
SOLUTION: HNAS logic corrected.
CIRCUMVENTION: N/A
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-24-2005 - APAR 2300104 (was problem 2005018B)
APAR: 2300104
STATUS: CLOSED
OPEN_DATE: 01-18-2005
CLOSE_DATE: 01-24-2005
SERVICE(S): Outbound Call Request processing (All LLCs)
MANDATORY: YES if callout support is required.
ORIGIN/REF: 230_POR
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (SRC) HNASMACX member
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300104.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300094 (and associated APARs PREREQ chains)
SUPERSEDES: N/A
OBJECT(S): N/A
SOURCE(S): NASTCP
PROBLEM: Callout requests randomly fail and the following alarm
message is issued:
NAS7720W mchname CALL OUT, CAN'T CALL
CALLED ADDR=B071323332260000
CALLING ADDR=C071136596090000
NAS7717W CAUSE/DIAG=000/130 (00/82) DIAGX=0010
DESCRIPTION: This failure is timing related and is more apt to
occur when there is a lot of simultaneous inbound and
outbound connect activity. Based on the HNAS log
provided by the customer after a trace trap that was
set as follows:
TRCTRAP=(ALRMLIST=(NAS7720I),TRCACTION=(SNAP,SUSP)
we were able to discover a timing window where the
allocation of a REMOTE Process Control Element (PCE)
for a callout attempt occurred while the HOME LOCAL
PCE was in a pseudo IDLE state. This state only occurs
after the LOCAL PCE is used to close a temporary socket
that was active during ACCEPT/TAKESOCKET processing.
The LOCAL PCE is in dispatch pending state with
PCESTAT=STIDLE which causes the REMOTE PCE allocator
to 'think' that the HOME LOCAL is inactive when it
really is not.
SOLUTION: The REMOTE PCE allocation routine has been modified
to detect the pseudo IDLE state so that the outbound
call attempt can be completed.
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).
01-19-2005 - APAR 2300103 (was unpublished problem 2004348A)
APAR: 2300103
STATUS: CLOSED
OPEN_DATE: 12-13-2004
CLOSE_DATE: 01-19-2005
SERVICE(S): LLC-5 (PAD)
MANDATORY: YES
ORIGIN/REF: 230_HRT
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 2300103.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
SUPERSEDES: N/A
OBJECT(S): VCDATQ
SOURCE(S): N/A
PROBLEM: Reset packets sent by router when HNAS sends invalid
P(R) packet.
DESCRIPTION: Customer is running a window size of 4 with a remote
HP computer. The problem occurs when 3 data packets
and a Q packet (to set the line delete character --
parm 17) arrive nearly simultaneously. The window is
rotated when the Q packet is released while the 3 data
packets are still waiting for delivery to the PLU.
When the data packets are delivered to the PLU the
RR delivered to the remote is invalid and causes a
RESET. This unusual sequence of multiple Q packet
X.3 parameter activity for a PAD session start-up
process exposed the bug.
SOLUTION: Correct HNAS so that the window is properly updated.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for
instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-17-2005 - APAR 2300102
APAR: 2300102
STATUS: CLOSED
OPEN_DATE: 01-17-2005
CLOSE_DATE: 01-17-2005
SERVICE(S): LLC3 (QLLC) QXID alarm message process
MANDATORY: NO, but recommended if APAR 2300097 has been applied.
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300102.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300097 (and associated APARs PREREQ chains)
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: NAS8101W, NAS8102W, NAS8103W and NAS8104W alarm
message IDs erroneously changed to a common ID
of NAS8201W.
DESCRIPTION: Problem occurred because the NAS8201W ID was used
in the XFWTO call for the 4 IDs above and we were
attempting to standardize the message. The fact
that the NAS8201W text was overlaid by the NAS810xW
IDs were missed.
SOLUTION: The original NAS810xW message IDs have been restored.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-13-2005 - APAR 2300101
APAR: 2300101
STATUS: CLOSED
OPEN_DATE: 01-12-2005
CLOSE_DATE: 01-13-2005
SERVICE(S): CONSOLE SUBSYSTEM DLU COMMAND
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: 230_CAI
PTF_CLASS: STANDARD-APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300101.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300090 (and all associated APARs PREREQ chains)
OBJECT(S): CONSDLU
SOURCE(S): N/A
PROBLEM: The HNAS DLU console command does not correctly display
QLLC SLUs when RNM=mchname is specified.
DESCRIPTION: The DLU command display operates in a hierarchical
fashion as a function of the command modifier(s) that
are provided.
When the LUNM=, RNM= and ID= modifiers are omitted,
the DLU command will display all SLUs defined in the
CDF. This works correctly.
When LUNM=sluname is specified, this modifier overrides
the RNM= and ID= modifiers restricting the SLU display
to the named SLU only. This works correctly.
When LUNM= is omitted but RNM=spuname is specified, this
overrides the ID= modifier restricting the SLU display
to the named SPU only. This works correctly.
When LUNM= is omitted but RNM=mchname is specified, this
overrides the ID= modifier restricting the SLU display
to the named MCH only. This DOES NOT work correctly
for QLLC SLUs that are active on the named MCH. The
problem occurs because of a missing test in the DLU
display processor.
SOLUTION: The DLU command processor has been modified to display
QLLC SLUs that have an active VC connection via the
MCH identified via the RNM=mchname command modifier.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-12-2005 - APAR 2300100
APAR: 2300100
STATUS: CLOSED
OPEN_DATE: 01-12-2005
CLOSE_DATE: 01-12-2005
SERVICE(S): LLC0/LLC5 PVC configuration processing.
MANDATORY: YES, recommended if PVC resources are required.
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300100.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300077 (and associated APARs PREREQ chains)
OBJECT(S): CNFGPVC
SOURCE(S): N/A
PROBLEM: The default PVC= applid value is not being set to 255
(ACQUIRE) when omitted which causes the following
configuration error message to be generated:
NAS1311W REMOTE PVC 001 LLC0 REQUIRES APPLNAME,
VTAM ACCESS CANNOT BE PROVIDED
DESCRIPTION: When the applid suboperand for a PVC= operand entry is
omitted, a default value of 255 (ACQUIRE) is supposed
to be set. Because of a blown register in the decode
logic, the default value is being set to 3. This causes
the configuration processor to test for the existence
of the APPLNAME= operand to satisfy the applid
requirement. When the APPLNAME= operand is omitted
or if the number of entries is less than 3, the error
message is generated. However, if the APPLNAME=
operand is specified and contains more than 2 entries,
an error message may not be generated when the applid
suboperand is omitted. In this case, the configuration
process will not report that an error condition exists.
You will not know of the configuration error until the
PVC activates and the wrong action is taken.
NOTE: When APPLNAME= entries are required for PVC
support, the applid values must not reference
APPLNAME= keywords of MCHSOL or CONSOLE.
These functions are not supported for PVCs.
CIRCUMVENTION: If ACQUIRE is the action required for a PVC SLU,
specify 255 as the applid value instead of letting
it default.
SOLUTION: The PVC= operand applid decode logic has been corrected
so that the register containing the default value of
255 is preserved. This will force the PVC SLU to
be ACQUIRED and obviate the need for the APPLNAME=
operand. The NAS1311W configuration error message
will be suppressed.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-11-2005 - APAR 2300099
APAR: 2300099
STATUS: CLOSED
OPEN_DATE: 01-10-2005
CLOSE_DATE: 01-11-2005
SERVICE(S): LLC3 (QLLC) console processing.
MANDATORY: YES, recommended if LLC3 resources are defined.
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300099.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300084 (and associated APARs PREREQ chains)
OBJECT(S): MCHSVCI
SOURCE(S): N/A
PROBLEM: 0C4-10 ABEND can occur when DRMT or DLU is used to
display the SLUs for a QLLC SPU.
DESCRIPTION: When TYPE=SPU REMOTE(s) are defined but no SVC3=
operand is specified in the CDF (SVC3=NONE is the
default), all SPUs are left uninitialized and no LU
control blocks (LUBs) are allocated for the SPUs.
When a DRMT or DLU console command is issued against
an uninitialized SPU using RNM=spuname, the display
routines ABEND because the LUB pointers in the LUNAME=
operand are unresolved. The SLU names or all spaces
(40404040) are used as LUB addresses. This causes an
addressing exception which then produces the 0C4 ABEND.
Note that because this ABEND occurs only when an
uninitialized SPU is referenced, it cannot occur when
an LLC3 call is received. This is because the call
will be rejected long before any SPU can be allocated.
SOLUTION: SPU initialization logic has been modified to ensure
that all SPU are initialized even when SVC3=NONE is in
effect for all MCHs in the CDF.
In a subsequent HNAS release, you will be able to
specify MRMT SVC3=ALLOW in order to 'turn on' LLC3
processing for an MCH that was configured for
SVC3=NONE. Because SPUs are now initialized
properly, any reference to them or their SLUs will
not cause an ABEND.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-07-2005 - APAR 2300098
APAR: 2300098
STATUS: CLOSED
OPEN_DATE: 01-05-2005
CLOSE_DATE: 01-07-2005
SERVICE(S): TRACE PRINT (TRCPRNT) processing.
MANDATORY: NO, but recommended if APAR 2300081 is applied.
ORIGIN/REF: 230_CP
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300098.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): CONSTPRT
SOURCE(S): N/A
PROBLEM: NAS0210W TRACE SYSPRINT LOGGING ENABLED message and
NAS0211I TRACE SYSPRINT LOGGING DISABLED message are
not displayed at the SYSCONS.
DESCRIPTION: Logic introduced by enhancement APAR 2300081 prevents
the NAS0210W and NAS0211I messages from being sent
to SYSCONS although they are still logged in SYSPRINT.
This occurs because the DEST= operand on the HNAS
XFWTO macro for these messages is missing flags
that APAR 2300081 logic requires for messages to be
delivered to SYSCONS.
SOLUTION: The HNAS TRCPRNT processor has been modified to supply
the correct DEST= operand for the NAS0210W and NAS0211I
XFWTOs so that they will always be routed to SYSCONS
unless SHOWOFF is in effect.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-07-2005 - APAR 2300097 (was unpublished problem 2004351B)
APAR: 2300097
STATUS: CLOSED
OPEN_DATE: 12-16-2004
CLOSE_DATE: 01-07-2005
SERVICE(S): LLC3 (QLLC) ACTLU processing.
MANDATORY: NO, but recommended if ACTLU failures repeatedly occur.
ORIGIN/REF: 230_RBS
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300097.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300086 (and associated APARs PREREQ chains)
OBJECT(S): QLSSCP
SOURCE(S): N/A
PROBLEM: ACTLUs fail with 8004 sense (Unrecognized Destination
Address) when SLU is defined in CDF but not in the
remote SPU.
DESCRIPTION: Customer sees many ACTLU failures with sense 8004
because LOCADDRs defined in the HNAS CDF do not
match the LOCADDRs defined in the remote SPU.
Customer indicates that the SPU allocates LOCADDRs
as needed rather than statically. These ACTLU
failures also occur with NPSI. HNAS, acting as the
SSCP, will reissue the ACTLU after a DACTLU and a
forced delay. This sequence will also generate
alarm messages. The customer acknowledges that this
is not an HNAS problem per se but suggests reducing
the frequency that failed ACTLUs are retried so that
SYSCONS and/or SYSPRINT are not flooded with NAS8211W
('ACTLU FAILED') messages and NAS8291W ('DLAY TIMEOUT')
messages. Both of these messages are generated when an
ACTLU failure occurs.
SOLUTION: HNAS has been modified to extend the ACTLU retry delay
from 10-seconds to 1-minute. The delay imposed after
consecutive ACTLU failures will be increased by doubling
the previous delay until a maximum delay of 16 minutes
is reached (that is, 1,2,4,8,16 minutes of delay after
each failure). At this point, the delay will go back
to 1-minute. This 'slowpoll' delay logic will continue
indefinitely until the ACTLU ends without error.
Note also that the NAS8291W DLAY TIMEOUT message will
no longer be generated since this is redundant
information after a NAS8211W ACTLU FAILED 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).
01-07-2005 - APAR 2300096 (was unpublished problem 2004351A)
APAR: 2300096
STATUS: CLOSED
OPEN_DATE: 12-16-2004
CLOSE_DATE: 01-07-2005
SERVICE(S): LLC3 (QLLC) USSMSG processing.
MANDATORY: NO, but recommended if LOGON problems are experienced.
ORIGIN/REF: 230_RBS
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300096.ZIP file)
COREQ(S): N/A
PREREQ(S): N/A
OBJECT(S): MCHSOL
SOURCE(S): N/A
PROBLEM: USSTAB, logon problem.
DESCRIPTION: User's logon message is being truncated. After
USSMSG10 is transmitted by HNAS, the user enters
'LOGON APPLID(KAMULTI2)' but only 'GON APPLID(KAMULTI2)'
is being delivered to HNAS. Since this input cannot
be processed correctly via the USSTAB, HNAS returns
USSMSG2 ('COMMAND UNRECOGNIZED') to the user. The user
says that 2 hyphens appear in his input area that cannot
be deleted which seems to be causing the problem. It
turns out that because HNAS adds a CR/LF (0D/25) as a
prefix and suffix to the USSMSG text supplied in the
USSTAB, the input area for subsequent user input is
corrupted. This prevents LOGON message from being
presented to HNAS correctly.
SOLUTION: The HNAS USSMSG processor has been modified to not
append a CR/LF to the beginning and end of a USSMSG
for QLLC LUs. The CR/LF will continue to be appended
for LLC0 (PCNE) and LLC5 (PAD) LUs.
APPLY_INFO: See Chapter 6 (Product Maintenance Installation
section) from the HNAS Guide and Reference Manual
for instructions on how to install PTF's (Object,
Source and ZAPs) or Refresh/Upgrade maintenance.
Corrective logic included in distributions created
after CLOSE_DATE. Otherwise, apply maintenance as
directed in the APPLY_INFO (PTF).
01-04-2005 - APAR 2300095 (Was problem 2004356A and 2004364A)
APAR: 2300095
STATUS: CLOSED
OPEN_DATE: 12-21-2004
CLOSE_DATE: 01-04-2005
SERVICE(S): LLC0 (PCNE) CALLOUT
MANDATORY: NO, BUT RECOMMENDED
ORIGIN/REF: 230_IZB
PTF_CLASS: STANDARD APAR
PTF_TYPE: (OBJ) HNASOBJX
PTF_LOC: FTP Server Directory /hnas_maint/hnas230m/apars/
(Complete FIX is contained in the 2300095.ZIP file)
COREQ(S): N/A
PREREQ(S): APAR 2300083, 2300071
(and associated APARs PREREQ chains)
OBJECT(S): CNFGCUD, XOTBXM
SOURCE(S): N/A
PROBLEM: A 'strange' input message is received immediately
after an LLC0 callout session is established which
the host application does not like.
DESCRIPTION: A trace of the callout connection revealed that
after the Call Accept packet was received by HNAS,
the remote DTE sends a Set Parameters (Q-packet)
followed by an input message that contains the
text string 'AIX Version 5 ...'. Because the
VC is PCNE, the message goes into the host
un-translated (raw ASCII). Since the remote DTE
sends a Q-packet at session startup, it seems to
be configured for PAD not PCNE.
When no CUD value is not specified for a PCNE call,
a default value of 01000000 is used. This CUD is
normally used for PAD and conditions the remote DTE
to provide and accept PAD services rather than PCNE
services. The correct default value of C0000000
should be used for PCNE when no CUD is supplied from
the SVC0= operand.
The default CUD of 01000000 sent by HNAS in the Call
Request packet forces the DTE to be PAD instead of
PCNE which it should be. This turns out to be why
the remote DTE sends the 'strange' input message
after the Set Parameters Q-packet.
SOLUTION: HNAS has been modified to use a default CUD value
of C0000000 for PCNE sessions when the CUD value is
omitted from the SVC0= operand for a callout SLU.
CIRCUMVENTION: Code C0000000 as the CUD value for the callout SVC0
entry as follows:
SVC0=(vclmt,
:
sluname/dteaddr1{-dteaddr2-{dteaddr3}}O//C0000000,
:
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 - May 5, 2006