1991 thru 1998 - SHIP25 MAINTENANCE SUMMARY
SHIP25 MAINTENANCE SUMMARY
--------------------------
Date: December 31, 1998 (1991 - 1998)
Memorandum
To: All Comm-Pro Users at the SHIP25 Distribution Levels.
All references to SHIP25 also includes support for SHIP25 Mod 1
(SHIP25M1) and SHIP25 Mod 2 (SHIP25M2) unless otherwise noted.
The following is a summary of SHIP25 maintenance (APARs, etc.)
issued as of the noted dates. This summary is provided as a
reference for problem resolution or preventative maintenance.
The summary record contains the following information:
APAR - Assigned Comm-Pro APAR number (S25nnn)
REF/NOTE - Comm-Pro internal identification (R_name) for
miscellaneous fixes and enhancements.
CP_NOTE - Comm-Pro product or support issues.
IBM_NOTE - IBM product or support issues, including early
warning of IBM PTF/APAR or error conditions.
COMPONENT - The Comm-Pro package or resource type that the
corrective logic addresses.
DATE - For APARs and Enhancements, this date reflects
when the actual corrective logic was applied
to the standard Comm-Pro SHIP25 distribution
libraries.
For all others, this date reflects when the item
was added to the summary.
DESCRIPTION - Brief description of the problem. Refer to the
actual APAR Memo for additional information
and corrective logic, if available.
Please refer to the SHIP25 documentation manual in APPENDIX F
(Maintenance) for additional information.
SHIP25 Maintenance Summary Detail
-----------------------------------------------------------------------------
APAR/REF - COMPONENT
DATE DESCRIPTION
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- 1991 -- SUMMARY FOLLOWS
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
S25001 - NAS X.25 users,
12-10-91 001B ABEND at offset '0F16' in module XFXPKT due to an invalid
packet level state during our CLEAR CONFIRMATION timer
processing. Memo format PTF not issued for this APAR.
S25002 - ITI NCP/NEO users,
12-10-91 Session may become hung if a BREAK is received from the remote
device during transmission of a chained RU from CICS. Memo
format PTF not issued for this APAR.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- 1992 -- SUMMARY FOLLOWS
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
S25003 - ITI EP users,
01-06-92 0951 ABEND at offset X'0A1C' in IBM module CYKCAIS due to an
error in our command to command processor. Memo format PTF
not issued for this APAR.
S25004 - EPMPX or BX25 users,
01-09-92 Resources can fail to connect to Host due to a potential POOL
pointer addressing error. A cumulative maintenance (CUME)
tape is required for appropriate corrective logic. Memo
format PTF not issued for this APAR.
NOTE - APAR's S25001 thru S25004,
01-09-92 Memo format PTF's not issued, CUME tape required.
S25005 - EPMPX or BX25 users,
01-27-92 Host may issue a CLEAR REQUEST when an RR Packet is received
before the CALL ACCEPT Packet during resource allocation.
S25006 - ITI EP Call Initiation (DIALOUT) users,
02-03-92 001B ABEND at offset X'918' in module XFXITI (LAR = offset
X'75C' in module XFUTCM) can occur due to a logic error caused
by our new logic for SHIP25 NEO NMVT support.
S25007 - EPMPX or BX25 users,
02-14-92 0953 ABEND at offset X'246C' in module XFMSVC because of a new
POOL base register USING statement error.
001B ABEND at offset X'239E' in module XFMSVC due to a logic
error in our revised VCN disconnect logic.
S25008 - ITI NCP/NEO users,
02-14-92 Hung ITI NEO resource can occur if a BREAK Packet (BREAK or
ATTENTION key depressed by user) is received during reception
of a HOST PIU with PACING in use. Discrepancy in the IBM FAPL
manual concerning how to treat PACING window after an error
condition.
S25009 - All NCP/NEO users,
02-26-92 Data that flows to the SSCP in the SSCP/SLU session can erron-
eously go into the Host with FIC (First in Chain) indication
when OIC (Only in Chain) is required. This error is due to a
BUFFER/PIU boundary condition that occurs when a large Packet
sequence (>255 byte) is received from the user.
S25010 - ITI EP Call Initiation (DIALOUT) users,
03-05-92 001B ABEND at offset X'8DE' in module XFXITI (LAR = offset
X'584' in module XFNDIL) can occur due to a logic error caused
by our new logic for SHIP25 NEO NMVT support.
S25011 - ITI EP Call Initiation (DIALOUT) users,
03-09-92 Default POOL options will not be sent if USE sub operand PATH=
netpath_name is not specified on the X.25 GROUP or LINE.
This is due to a register usage error that was introduced
during implementation of the new support for DPTTY=POOL_NAME.
S25012 - ITI EP users,
03-16-92 Remote TPAD or X.25 Network may become confused when Comm-Pro
sends an M-BIT (More data indicator) packet that is partially
filled. This may cause a Packet level RESET from the Network.
S25013 - DSP users,
03-18-92 NDF generation error messages can occur on DSP NCP resources
due to an error in our CU and DEVICE macro logic. Error
occurred when consecutive CU or DEVICE macro statements
contained ADDR=C9 followed by ADDR=4A in the Comm-Pro Stage 1
input. Bug was introduced when enhancements were added for
SHIP25.
S25014 - DSP EP or EPMPX/BX25 users,
03-25-92 001B ABEND can occur in our DSOEOD logic due to a register
usage error. Abend was detected in our SHIP21X 3705
distribution. APAR is being issued to circumvent a potential
ABEND in SHIP25.
S25015 - 3745 STAT (Statistics Gathering Facility) users,
04-02-92 An error in our STAT logic can cause the 3745 CCU to become
stuck in a tight level 3 loop.
S25016 - NAS NCP/NEO users,
04-02-92 A 0951 ABEND at offset X'1400' in module CXDCG02 can occur due
to a blown Savearea register. The faulty register is passed
from our FMDR750 to the NCP release routine. Logic was added
to SHIP25 routine FMDR750 to release a PIU element if it is
empty, but savearea register was not primed before release.
The FMDR750 logic has been superceded by APAR S25009 which
correctly performs the same function for empty PIU elements.
S25017 - ITI NCP/NEO users,
04-15-92 This APAR addresses the following ITI NCP/NEO conditions:
- Correct Cancel logic to insure that the FMD that follows
CANCEL PIU does not go into host as LIC but as FIC. Bug can
cause our 'READ ABORTED, DATA LOST' message to be sent out.
- A 001B ABEND can occur at offset X'1022' in module XNFSVL
due to a blown End Character test register.
- Change Protocol ID in outgoing CALL REQUEST packet from
1 to 0.
- Correct logic for ETB Packet so that our XFNSLUXT logic
can end a Paced MIC PIU correctly. XFNSLXT logic normally
NOPs until a complete packet sequence has been transmitted.
S25018 - NAS NCP/NEO users,
04-15-92 Errors in the VTAMLST MAJOR NODE resource can occur when Comm-
Pro NCP/NEO LINE resources are produced without the associated
GROUP definitions. Our LINE macro is missing a test to insure
that the user has defined a USE=NCP/NEO GROUP in front of the
USE=NCP/NEO LINE definition.
SHIP25M1 - NCP 5.4 and EP Rel 9 users,
05-01-92 SHIP25 Mod 1 is now available. This release supports NCP 5.4
and EP Rel 9 and is not downward compatible with the NCP or EP
releases supported in our SHIP25 (Mod 0) base distribution.
Future Comm-Pro releases (SHIP25 Mod 2 or SHIP26) will be
downward compatible with the NCP/EP releases supported in the
SHIP25 base distribution.
S25019 - EP 3745 users,
05-07-92 Comm-Pro Stage 1 sysgen erroneously flags an error when the
LOCHAN/HICHAN subchannel values are specified correctly.
Solution is to allow LOCHAN to be any value between 0 and 255
and HICHAN to be any value between LOCHAN and 255 for 3745's.
Note that for all other CCU's:
0 <= LOCHAN = 0MOD(16) <= 240 ;
LOCHAN <= HICHAN = 3MOD(4) <= 255
R_ITINEOXLT - ITI NCP/NEO users,
05-07-92 Translate tables changes for Macro - XFNSVL.
Change Input translate table LUINXLT to map:
---------------------------------------------
ASCII 5B TO EBCDIC AD (Left Square Bracket)
ASCII 5D TO EBCDIC BD (Right Square Bracket)
Change Output translate table LUXSXLT to map:
---------------------------------------------
EBCDIC AD TO ASCII 5B
EBCDIC BD TO ASCII 5D
S25020 - All Comm-Pro users,
05-14-92 001B ABEND will occur in module XFUTCM if a scanner disconnect
occurs on a scanner with an active Comm-Pro console attached
via a real async line interface. (Consoles attached via X.25
access lines are not subject to this problem).
SIT traces started via the TOPT 3xabcde console command can
cause an ABEND.
S25021 - NAS X.25 TYPE=X25LINK,USE=(,NEO..) users,
05-26-92 ACTLU PIU directed at our X.25 NEO LU component is rejected
with 081C sense. This is because the SHIP25 code now rejects
an ACTLU PIU if the GATE and DATE option is omitted. (Our GATE
and DATE support will be available at a later date).
The corrective logic for this APAR will force inclusion of
ISTATUS=INACTIVE on the NEO X.25 link VTAM LU element that is
generated without the GATE and DATE option. This NEO LU does
not require activation since no FMD data will flow without
DATE support.
S25022 - ITI NCP/NEO DIAL=NO (Dedicated) users,
06-03-92 Host CONTACT PIU is rejected with an 8002 SENSE code because
our internal control block flags indicate that the resource is
Switched (DIAL=YES) when it should be Non-Switched (DIAL=NO).
An error in our Stage 1 Macro can cause the EPVIRT,USE=NCP CCB
for a DIAL=NO resource to be generated with a DIAL=YES flag.
R_QLLCINOP - QLLC and PSH users,
06-03-92 Force INOP PIU instead of REQDISCONT PIU when the X.25 network
clears calls (CLEAR REQUEST) for DIAL=YES resources. DIAL=NO
resources will continue to receive a REQDISCONT PIU.
S25023 - NAS D-Bit (Packet Level Delivery Confirmation) users,
06-16-92 An error in our D-Bit logic can cause device input to be
deleted during D-Bit input processing. This unusual timing
sequence can occur when at least one complete D-Bit input
packet sequence is already staged for host delivery while the
previous D-Bit packet sequence is being processed. Note that
very few X.25 networks or PADs use or enable the D-Bit support.
So far this error has been observed at only one site.
S25024 - BPAD users,
06-25-92 001B ABEND at offset X'720' in module XFBPSC (MSGI030) caused
by an improperly formatted buffer header.
S25025 - BPAD users,
06-25-92 001B ABEND at offset X'5AA' in module XFBPSC (RECV232) can
occur if a BPAD message with an embedded ETB character is
received.
S25026 - NAS PVC (Permanent Virtual Circuit) users,
06-25-92 001B Abend at offset '5FE' or '610' in module XFXITI (ITICN910
or ITICN950) can occur due to incorrect error recovery in our
PVC connect logic. The problem was encountered during excessive
Q-Bit (Contains Control Data - Data Qualifier) packet activity.
S25027 - NAS X.25 users,
06-25-92 Loop on an X.25 link line can occur if a frame is sent that
causes the remote network or Pad to reject our I-FRAME (In-
formation Frame) with a FRMR (Frame Reject). NAS continues to
resend the frame upon reception of the FRMR. This causes a
link level loop which prevents traffic from flowing on the
X.25 circuit.
Solution is for NAS to purge the error frame that caused the
FRMR. The logical channel associated with the frame will then
be disconnected with a CLEAR REQUEST containing diagnostic
code X'45'. This will prevent the loop that could have been
caused by a simple packet size mismatch.
Resetting the link via the Comm-Pro console command 'CNET idlmt
RESET' or modem reset (power off/on) will clear the condition.
(Note that this procedure will disconnect all of the users from
the problem X.25 link).
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This APAR contains relocatable code, the PTF cannot be supplied
in APAR Memo format. Please order a no cost CUME (Cumulative
Maintenance) Distribution tape should you require this fix.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
S25028 - NAS X.25 users,
06-26-92 An I-FRAME (Information Frame) can be sent out-of-sequence and
cause the network or Pad to respond with an REJ (Reject Frame)
thus rejecting our I-FRAME. This is a timing problem and can
only occur when we have to re-transmit an I-FRAME that was lost
on the line (line error), in the network or pad.
S25029 - NAS X.25 TYPE=X25LINK,USE=(,NEO..) users,
06-30-92 4F00 ABEND at offset '132E' in module XFNEON (FMDX070) can
occur when an SSCP FMD PIU is directed at an X25LINK NEO LU
component. This resource should not receive any FMD data,
solution is to reject FMD PIUs with an 0831 Sense code.
S25030 - NAS X.25 PVC users,
07-15-92 001B ABEND at offset X'EE6' in module XFXSUP (LKRST110) can
occur during 37xx FEP IPL (Initial Program Load) when the Comm-
Pro Stage 1 input contains fewer EPVIRT,USE=EP,LNCTL=SS lines
than the total number of PVC's defined across all of the X.25
links. (PVC count is coded on the VCLMT= parameter on each of
the TYPE=X25LINK lines).
Solution is to force error return CC=8 in the Comm-Pro Stage1
gen when the PVC count is greater than the number of defined
EPVIRT lines.
S25031 - EPMPX or BX25 Call Initiation (DIALOUT) users,
07-24-92 0951 ABEND at offset X'86E' in module XFNSUP due to zero being
used as the Pool pointer. This is because our XFMSVC Dial logic
fails to initialize the pool pointer in our CXB control block.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This APAR contains relocatable code, the PTF cannot be supplied
in APAR Memo format. Please order a no cost CUME (Cumulative
Maintenance) Distribution tape should you require this fix.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
S25032 - All Comm-Pro Contention Line users,
07-27-92 0951 ABEND at offset X'B02' in module CYLTRC can occur due to
an invalid CCB control block CHCB pointer. The pointer can be
improperly initialized out of sysgen.
The ABEND will occur when a Level 3 trace is started on a line
subchannel address for a Contention line.
NOTE - APAR's S25019 thru S25032,
07-30-92 Memo format PTF's not issued, CUME tape required.
S25033 - QLLC users,
08-12-92 0951 ABEND at offset X'19CA' in module XFQLLC (RCVL1A00) due
to an un-initialized pointer. This condition can occur when
multiple QLLC messages are on the Input Queue awaiting service.
The pointer is used to reverse thread priority packets from the
Input Queue.
S25034 - 3745 users,
08-12-92 Potential problems can arise if line 1080 is defined as an
EPVIRT line resource in the Comm-Pro Stage 1 Gen. Line address
1080 is the Reserved Interrupt Handler for 3745's and must not
be used for Comm-Pro resources. (Note that 3725 reserves line
address 256).
Solution is to reject EPVIRT line definition during Comm-Pro
Stage 1 processing if line 1080 is defined.
Line addresses 1104 thru 1120 are reserved for SIT activity.
SHIP25 has always rejected any of these lines if defined in
the Comm-Pro Stage 1 Input.
S25035 - EPMPX or BX25 users,
08-13-92 EPVIRT,USE=EP,TERM=3270MPX LINE can fail to connect sessions
to the Host even though the X.25 link and Host subchannel
address are active.
This will occur when the TERM=3270MPX LINE address is defined
as the highest line number in the Comm-Pro Stage 1 input.
An error in our EPMPX LNVT scan causes the last entry to be
ignored.
Another solution is to insure that some other type of line is
sysgened above (higher line address) the last EPMPX/BX25 line.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This APAR contains relocatable code, the PTF cannot be supplied
in APAR Memo format. Please order a no cost CUME (Cumulative
Maintenance) Distribution tape should you require this fix.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
S25036 - NAS X.25 TYPE=X25LINK,USE=(,NEO..) users,
08-14-92 Tight Level 4 Program loop can occur in XFNTLKTM logic after an
X.25 link goes into disconnect "DISC" state (Line errors/error
recovery exhaustion) then goes back into active "ACT" state.
The loop occurs because our LKTMPUMN timer appendage does not
reset the CCLTMAPP flag after it has been dispatched. The bug
was a result of new NMVT logic introduced in SHIP25.
S25037 - All Comm-Pro Console Subsystem NCP/NEO Trace users,
08-18-92 Console Subsystem processor is unable to start (TOPT 2____)
NEO trace for more than one nalist network address at a time.
Problem occurs because of a change that was added for NMVT
support that redefined the table delimiters.
S25038 - QLLC and PSH users,
08-19-92 Pacing responses can be returned to Host prematurely. Our NAS
NEO logic will return a pacing response to the Host for a
request PIU that carries the Pacing indicator when the pacing
window limit is reached. This is correct for ITI & DSP NEO
sessions where pacing is simulated by NAS. It is not correct
for PSH & QLLC resources whose pacing must be controlled by
the remote LU.
Solution is to defer the pacing response for Host until one
is received from the network (remote LU).
S25039 - All Comm-Pro Console Subsystem X25LINK Trace users,
08-26-92 The wrong NCB (Network Control Block) is located by the TOPT
330NN command when NETID's are assigned via the new SHIP25
feature USE=(NETID=XX on the X25LINK LINE macro. This can cause
the wrong X.25 link to be traced.
Problem occurs because the TRNET trace logic uses the passed
NETID as the index into the NCB chain rather than scanning the
NCB's for a matching NETID value.
Solution is to find the NCB by comparing the passed NETID value
to the value in the NCB instead of the indexed NCB.
S25040 - All Comm-Pro NAS X.25 users,
08-31-92 Confusion can occur in user assignment of our NETID= parameter
and can sometimes lead to an incorrect X.25 link routing. The
NETID assigned to our X25LINK LINE is assumed to be Hexadecimal
while all other decodes are in decimal.
This logic enhancement will make all decodes and displays of
the NETID in hexadecimal. The NETID value that you code on the
LINE, CU, DEVICE or POOL macro is now treated as a Hexadecimal
number in all cases.
S25041 - All Comm-Pro 3745 Console Subsystem SIT Trace users,
09-02-92 0951 ABEND at offset X'3C' in module CYKSIT due to invalid
Register data being passed to the STARTTRC routine from TRITGO
in module XFLNTR.
Solution is to reset SIT flags before trace flags are passed
to the trace routine for virtual lines.
S25042 - DSP NCP/NEO users,
10-08-92 Comm-Pro Stage 3 Step NDFVTAM can receive error message
'INVALID LOCADDR' on every LU with a LOCADDR > 255. An error
in our logic is preventing the LOCADDR from being reset after
each DSP LINE or CU (PU) is encountered.
S25043 - EPMPX or BX25 users,
10-13-92 001B ABEND at offset X'F16' in XFXPKT can occur when a Packet
is received from the X.25 Network for an LCN (logical channel
number) in state P7 (DCE CLEAR state).
The logic validity check is the result of an unusual timing
condition encountered at only one of our EPMPX sites.
The solution is to schedule a CLEAR CONFIRMATION when the
logical channel state is P7 on behalf of the EPMPX Host when
Disable is processed. This will prevent the potential timing
condition encountered in state P7.
S25044 - EPMPX or BX25 users,
10-29-92 001B ABEND at offset X'AEA' in module XFNSUP can occur when
a CLEAR REQUEST packet is received from the network for an
ITI LCN with data queued for Host delivery. Problem occurs
because our Poll logic in module XFMSVC is not clearing the
BFRLSTMS field of the new first queue element.
This only occurs when the EPMPX packet level window is open
by less than the number of packets already enqueued on CCXIQ.
S25045 - All NAS X.25 Users and 3745 Users,
11-09-92 Part 1 - 953 Abend at offset X'E2' in module CYKSTCHG due to
a conflict with the new EP CCBOPT3 option field.
Solution is to move our CCLCUTOF field to CCBCAC and CCBSVSTC
so that it does not conflict with CCBOPT3. This is required
because a CUTOFF value >15 causes the V25BIS flag to be set in
the CCBOPT3 FIELD. EP logic in CYKSTCHG reacts to this flag
and attempts to modify fields in an AUTOCALL CCB that does not
exist. Result of this action causes the Abend.
Part 2 - 974 Abend at offset X'45E' in EP module CXDPEP for
3745 CCU models due to a unique hardware timing condition.
Solution is to provide an additional 51 cycle delay (61 total)
before the EXIT in routine XFFCSWT. This appears to be
required when the 3745-610 is in Hot Standby mode only (not
in Twin Dual mode) machine looses a Cycle Steal interrupt and
reports it as an unresolved Program Level 3 Channel Adapter
interrupt which results in the Abend.
An additional 58 cycle delays was added after the CAIOH 60 in
the HIO logic to prevent Unresolved Program Level 3 Interrupts.
This condition was observed at one of our customer sites that
uses HIO (Halt I/O) to knock down Host READ commands when it
wants to WRITE, simulating FDX (Full Duplex) support on a HDX
(Half Duplex) subchannel.
S25046 - EPMPX, BX25 or DSP EP Cycle Steal (CHNPRI=HIGH) Users,
11-30-92 Host Channel Checks can occur after a HIO (halt Input/Output)
is issued to a Subchannel that is on the Level 3 Cycle Steal
(CS) Queue.
Problem can occur when a HIO is detected as an Initial Select
Interrupt. This can only occur during the time between the CS
enqueue request (XFFCSST) and the CS Transfer Start (XFFCSAS).
The current logic sets the CCBSIFD flag in CCBLRI and resets
the HIO Interrupt via OUTPUT 60 then exits. The HIO remem-
brance (CCBSIFD) is supposed to be tested by higher level
routines. This test is missing from the new CS Level 3 logic
in this situation. This APAR provides the missing test.
Note that when the HIO is received as a Data Service Inter-
rupt (After the CS Transfer has been started), the existing
logic is correct. The HIO is handled properly.
S25047 - DSP UCN users,
12-22-92 951 ABEND at offset X'876' in module XFNSUP can occur during
timer processing for DSP resources supporting multiple User
Circuit Numbers per Logical Channel Number.
Problem due to new SHIP25 enhancement that fetches the OPTIONs
pointer via the POOL instead of directly addressing OPTIONs.
The DSP Logical Device control block does not address a POOL.
Solution is to bypass option lookup when no pool pointer is
present.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- 1993 -- SUMMARY FOLLOWS
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
S25048 - DSP users,
01-20-93 DSP CALL REQUEST packet using Connection Request Mode 1/2
(CRM-1/CRM-2) can be cleared with a X'8X' Diagnostic Code.
CRM is located in the Call User Data and is used to control
mapping of remote Control Unit and Device Address to the
Host resource.
CRM-3 and CRM-4 are not affected by this bug because these
CRM types do not employ LCUA/LDVA matching. Most Comm-Pro DSP
users run with CRM-3, this allows users to logon at different
times of the day and share resources.
Problem is due to a mismatch in the Logical Control Unit and
Device Address (LCUA/LDVA) caused by a uninitialized register.
Bug was introduced with the SHIP25 DSP Quick Switch logic.
S25049 - ITI/EP users,
01-28-93 ITI/EP session can become hung if the Break key (Packet Level
Indication of Break) is received during a Packet Level M-Bit
(More data indication) Write sequence. Problem occurs because
the Level 1 Resume Output packet cannot be built. This is due
to the fact that a purged Level 0 request (DPRQ value of 0) is
not being stepped over so that a Level 1 Resume Output request
can be detected.
Solution is to step over the Level 0 request and allow the
Level 1 request that follows it to be process in the normal
manner. In the case of the Resume Output request, an empty
Level 0 packet is sent to end the M-Bit sequence followed by
the Level 1 Resume Output packet.
S25050 - NAS X.25 users,
02-28-93 001B ABEND at offset X'948' in module XFXSUP can occur during
X.25 link error recovery. Problem occurs during X.25 Link Abort
processing when NETUAIC > 0 (Current Unacknowledged Information
Frame Count) and NETL2XCQ = 0 (Level 2 Transmit Completed Queue
Element) .
This situation occurs because logic in XFXLKXA is called with
an S-Frame (Supervisory) in flight and an I-Frame (Information)
are on the NETL2XRQ (Level 2 Transmit Ready Queue). Before
LKL2QU (level 4 logic) can move the I-Frame on NETL2XRQ to
NETL2XCQ, the S-Frame completes and Program Level 2 starts the
I-Frame on NETL2XRQ. LKL2QU logic ABENDs when NETUAIC does not
match the number of frames on NETL2XCQ. This is a very unusual
timing condition.
Solution is to move the NETL2XRQ Frames to NETL2XCQ before
XFXLKXA is called. If an I-Frame is active at this time, it is
returned to LKL2QU so that it can be placed on NETL2XCQ. If
I-Frame has completed and hence is no longer active, it is
already on NETL2XCQ as the result of a Program Level 2 enqueue
via BFXT logic.
S25051 - DSP UCN users,
03-01-93 This APAR addresses the following DSP UCN (User Circuit Number)
conditions caused when the DSP Quick Switch Support was added
to SHIP25.
- 001B ABEND at offset X'1E7E' in module XFTSNT. Problem
occurs because we are attempting to Clear a Multi UCN call
with R2 (Register 2) pointing at a UDVB (User Device block)
instead of the LDVB (Logical Device Block). This is due to
the fact that R2 is set to the UDVB address for a call to
routine XFNGOPT to fetch parameters for DSP Quick Switch
support. R2 is not restored to the LDVB address before call
to XFTNDVDC which causes the Abend. This only fails in a
Multi UCN Environment when a single UCN per LCN is used
LDVB=UDVB so restoring R2 is not required.
Solution: Always restore R2.
- 001B ABEND at offset X'0878' in module XFTSNT. Problem
occurs because we are attempting to process a Call Accept
build request for an LDVB (Logical Device Block) with
DVBPCBPT=0. Abend occurs because of an XJUMP (Device Type
Test) failure thru XFBCTYP for the PCB's CXB.
Since LDVB's do not have PCB sessions, solution is to ignore
Call Accept processing for LDVB. The failure does not occur
when a Single UCN (User Circuit Number) per LCN (Logical
channel Number) is used since DVBPCBPT is correct in the
UDVB.
S25052 - QLLC/PSH DIAL=YES users,
03-03-93 Comm-Pro Stage 1 Step can loop and eventually exhaust the ACTR
counter or SYSUT1 Dataset which can cause the Assembler ABEND.
The error was introduced when support for new VTAM parsmeters
ASLENT, ASLTAB, MDLENT, MDLTAB and NPACOLL) were added to our
standard distribution on August 1, 1992. Solution is to correct
faulty branch to location.
S25053 - DSP/EP, EPMPX and BX25 users,
03-12-93 001B or 0951 ABEND can occur due to register(s) usage errors
caused when Cycle Steal logic enhancements were made.
Problem 1 occurs because a register containing the number of
bytes transferred from the Host via Cycle Steal has been blown.
This problem only occurs when transfer is in Non-Transparent
Mode.
Problem 2 occurs because register 1 (Address of WRTTOMX, Decode
Text Mode Output Data Routine) is not preserved when dialog is
in Host Transparent Write Remember Mode (Transparency) and a
SYN character is decoded from Host. SYN character caused call
to DSISEL routine that stores register 1 in CCBL2, Abend occurs
when the next character is processed.
S25054 - ITI/NCP CALLOUT Support and TYPGEN=VM Users,
04-13-93 This APAR addresses two separate problems:
Item 1 - ITI/NCP CALLOUT Support,
---------------------------------
VTAM error messages can occur when the Major Node is activated
with CONNOUT resources. The errors occur because LINEAUT and
LINEADD parameters were moved from GROUP to the LINE macros
for DIAL=YES resources. These parameters are only allowed on
the GROUP statements. This bug was introduced with SHIP25
VTAM parameter support. In prior releases a GROUP statement
was produced for every LINE statement with LINEAUT and LINEADD
added for CALLOUT support. In SHIP25, a GROUP statement is
produced its NEO GROUP macro counterpart in the COMM-PRO Gen.
The LINEAUT and LINEADD parameters were added on the LINE only
when NETADDR= was coded. Now these parameters will be produced
unconditionally on the GROUP statements when DIAL=YES is
specified.
Item 2 - TYPGEN=VM,
-------------------
Correct VM Stage 3 run time error by refining Return Code
tests. Corrective logic will delete the test for MAXRC>4 in
VM Stage 3 EXEC at label XFR90: so that balance of EXEC
executes even when NDF detects errors. This is required
because NDF sets RC=1 as an overall RC (=> GENDECK Errors)
even when warning messages with internal RC=4 are generated.
We cannot use overall RC=1 for conditional execution. Note
that if severe errors are detected, the NDFPLI program will
fail and this will abort the balance of EXEC processing. If
this is not done, a warning message can cause an otherwise
valid SYSGEN to be terminated early (I.E., before the Table 1,
LKED and NOGOTEST steps have completed).
S25055 - ITI/NCP, QLLC & PSH CALLOUT Support and ITI/NCP CALLIN Users,
04-27-93 This APAR addresses three separate problems:
Item 1 - ITI/NCP, PSH & QLLC CALLOUT Support,
---------------------------------------------
ABEND can occur in our CONNOUT logic due to an invalid CXB (CCB
Extension) register when XFBPOOL pointer is to be set during
the CALL REQUEST packet build. Error is due to new logic that
has a 'USING' instruction which causes the wrong base register
R7 to be used instead of R2.
Solution is to use an absolute Base/Displacement reference and
bypass the 'USING' default.
Item 2 - ITI/NCP CALLOUT Support,
---------------------------------
Default internal CALLOUT Pool Options pointer not initialized
properly. The internal default Pool was overlooked when the
Option pointer was moved in all sysgen Pools. This bug prevents
the default SET & READ packet (X.29 pad parameters) from being
sent to the network after the CALL ACCEPT packet is received.
Solution is to move options pointer to front of default CONNOUT
Pool so structure matches all sysgen Pools.
Item 3 - ITI/NCP CALLIN Support,
--------------------------------
Packet level loop sending a Forward Abort message can occur due
to a scheduling error in modules XFNSSL and XFNSVL. Problem
occurs when the Host issues a CANCEL command to abort an FMD
(Function Management Data) chain. The CANCEL is translated into
a packet with ENQ as the last character. Routine XFNSLUXS sees
ENQ and calls routine XFNSLUAN to send Abort Message ("*XF*,
WRITE ABORTED, OUTPUT TERMINATED"). Routine XFNSLUAN then
calls routine XFNSMSG WHICH CALLS routine XFNSLUXS, hence the
loop.
Solution is to have routine XFNSLUXS schedule the Subtask when
an ENQ is detected. Subtask will then call routine XFNSLUAN.
S25056 - ITI PVC (X.25 USE=(,DCE ...)) Users,
05-07-93 An error in our X.25 link reset logic prevents PVC (Permanent
Virtual Circuit) logical channels from being reinitialized.
This only occurs when the Comm-Pro X.25 link is defined as a
DCE. The error manifests itself as a logical channel RESET
the first time data is received because the 37XX thinks as PS
(Packet send sequence) value of zero is in error.
Solution is to save and test for an X.25 Link reset initiated
PVC disconnect request by checking the NETRSTRM byte. This
byte will contain the original NETRSTRQ value at entry to the
NETLRS routine in module XFNSUP. This byte is reset at exit
from the NETLRS logic so that subsequent XFNDISC calls for a
PVC will not cause logical channel controls to be reset.
S25057 - ITI/NCP Users,
05-07-93 An error in our LU input processor logic causes input from the
remote ITI/NCP devices to be rejected. The problem only occurs
when multiple input packets are received and SNA Brackets are
not used. The error manifests itself as a logical channel
RESET if the rejected packet carries the D-bit, not M-bit.
Solution is to go to FMDR450 routine in module XFLULU instead
of FMDR500 when Bracket protocol is not used so that ECI (End
chain indicator) bit can be tested. This will prevent the SLU
(Secondary Logical Unit) input active flag from remaining set
and prevent the next BCI (Begin Chain Indicator) FMD (Function
Management Data) from being rejected.
S25058 - Comm-Pro NCP NEO (ITI/NCP, DSP/NCP, PSH and QLLC) Users,
06-01-93 This APAR addresses two separate problems:
Comm-Pro ITI/NCP, DSP/NCP, PSH and QLLC Support,
------------------------------------------------
Error in our FMDNQ, FMDDQ and FMDPQ RR/RNR (Receiver Ready/
Receiver Not Ready) logic causes an ITC (Invitation to Clear)
packet to be sent to the network when it should not be. Problem
occurs because the ITC is sent when 'W' (W=packet level window
size) packets are received after RNR sent (RNR is sent when the
PIU (Path Information Unit) threshold is reached). The RR/RNR
logic must allow for the reception of 'W' packets after an RNR
is sent.
Solution is to change FMDNQ logic to not send ITC until W+1
packets are received after an RNR is sent. FMDDQ and FMDPQ are
also changed to not send RR until queued PIU count is W+1 less
than threshold.
Comm-Pro ITI/NCP OPTIONS=(,XPRDAT=YES) Support,
-----------------------------------------------
Error in our LUIN (Logical Unit Input) transparent data logic
(Form 4 Pool OPTIONS=(,XPRDAT=YES) prevents the last character
in data from being tested as LIC (Last In Chain) FMD (Function
Management Data) character. Problem occurs because only the
first character in a buffer is fetched during packet trans-
lation processing. At exit from the translate logic, LO1
register is assumed to contain the last packet character which
it does not in transparent mode.
Solution is to change the LUIN logic to fetch but not translate
all buffer characters when transparent mode is active so that
LO1 register will contain the last character at the end on the
translation loop.
For true transparency, OPTIONS=(,CHAREC=NOMORE) should be
defined to bypass message end data character decode. NOMORE
option will set LIC or OIC (Only In Chain) indicator whenever
a non M-bit packet is received.
S25059 - All Comm-Pro ITI/NCP DIAL=YES Users,
05-25-93 An error in our VTAM parameter support that was introduced in
SHIP25 can cause the NDF step to fail with errors. The OWNER
parameter is invalid for a PU definition for DIAL=YES LINE
definitions.
OWNER is only valid on LEASED PU definitions although it can
be specified for leased or switches LINE(s).
Solution is to remove the OWNER parameter from the PU resource.
S25060 - Comm-Pro ITI/NCP D-bit (Delivery Confirmation) Users,
05-26-93 An error in module XFLULU routine CMCKIN logic can cause a
lockout condition. This is because the logic allows multiple
FMD PIU's to be delivered to the Host without an intervening
response when Definite Response protocol is in effect. CMINCK
receives control from FMDX logic as input and output are inter-
leaved. This error is normally not a problem unless D-bit
packets are being used. In this case, multiple FMD's can cause
incorrect manipulation of CCXDBCNT.
For example if two D-BIT, ªM-BIT (More Data Indicator) packets
are passed to the Host without an intervening response,
CCXDBCNT will never be set back to zero. This will cause the
PKIN logic in module XFXPKT to defer RR (Receiver Ready)
propagation.
Subsequent packets received when CCXDBCNT>0, even if they carry
an M-bit, will not be acknowledged. The result is a lockout
condition that will ultimately result in a packet level Reset
from the X.25 Network or TPAD (Terminal Packet Assembler/
Disassembler) due to a Time-out.
The solution is to make routine CMINCK defer input processing
if a response is owed to a previous input sequence.
S25061 - Comm-Pro Console Subsystem Command=DBNN Users,
06-01-93 0951 ABEND in module XFCONXcc (cc=OBJQUAL in BUILD) can occur
near label DBNN660 due to a bad QCB base register. The register
is corrupted because of incorrect logic in routine DBNNSTPX.
The test for NLB³NLX uses NLXTYPE in the QCB which is correct
for NEO resources but not for real NCP resources.
Routine DBBNSTPX wrongly treats an NCP LCB (QCB for real line)
as an NLX (NLXTYPE=20 in LCB is greater than NLBTYPE=04). This
causes routine DBNNSTPX to step to the next NLX by adding the
value at offset NLXOFSET (NLXOFSET=03 in LCB) resulting in bad
NLX pointers being set in MBNNNLX and MBNNQCB. Since the RVT
and RRT still point at the entry for the LCB, an addressing
exception occurs near routine DBNN660 when the ACB pointer is
fetched from LCBACBP in the bad QCB.
Solution is to test QCB type in DBNN decode.
S25062 - Comm-Pro NAS X.25 TYPE=X25LINK,USE=(,LAPB,TAP....) Users,
06-07-93 Unusual timing condition encountered with our USE=(,LAPB,TAP
shoulder TAP logic. Problem manifests itself as a X.25 link
going up and down (DISC/INIT/ACT state). Problem does not
occur when users data activity is present. This problem occurs
because the NETCLOCK counter is not being reset when an RR/
F-bit is received in response to an RR/P-bit that was trans-
mitted.
Module XFXLNE will set NETCLOCK=NETT1 anytime it sends an X.25
frame that carries an address of our Primary (LAPB shoulder
Tap polls with an RR Command so that the P-bit can be used to
force a response. The shoulder tapping is used to monitor the
X.25 link for absence of any activity from the network or
remote Pad).
Module XFXSUP clears NETCLOCK when an I-FRAME is received but
not when an RR response is received. This means that after
every RR/P-bit is sent, the X.25 link goes into timer recovery
because NETCLOCK expires. After N2 of these, the link goes
into DISC (Disconnect) mode which causes all of the connected
LCN's (Logical Channel Number) users to be disconnected from
the X.25 link. The link comes back up after initialization is
completed.
Solution is to reset NETCLOCK when an RR/F-bit is received.
S25063 - Comm-Pro ITI/NCP Binary CALLOUT Users,
06-07-93 Error in our LUCR logic for Binary Dial (CONNOUT) fails to set
the EOD (End Of Data) offset in our Call Request packet. The
default EOD offset is at the end of the packet which results
in an invalid CUD (Call User Data) being transmitted. The
remote X.25 Network or Pad will the issue a Clear Request to
disconnect the session due to the invalid CUD.
This logic error was introduced with the SHIP25 NMVT support.
Solution is to set the EOD pointer prior to LUCR exit.
S25064 - DSP UCN Users,
07-07-93 Special corrective logic for custom UCN resources hung in
"connect" state.
S25065 - ITI/NCP Users,
06-24-93 This APAR addresses two separate problems:
Comm-Pro ITI/NCP CALLOUT users,
-------------------------------
Users can experience data handling, session connect and run
time problems due to a bug in our new DPTTY logic that causes
default POOL OPTIONS to be used instead of the user supplied
values on DPTTY POOL.
Our LUCR logic looks for a sysgened supplied CALLOUT POOL hung
off of the NETPATH macro using a POOL definer type of XFCPNCP.
The POOL definer type should be XFCPPCNE for ITI/NEO support.
Comm-Pro ITI/NCP (Bound - Half Duplex Contention Mode) users,
-------------------------------------------------------------
HDX/CTN (Half Duplex/Contention) Mode session without Bracket
or CDI (Change Direction Indicator) can become hung in PLU
(Primary Logical Unit) Transmit State when two consecutive
input messages are received from a remote user. First message
is successfully delivered to the Host application, second
message sits on the input queue awaiting a Host response
message to the previous input message.
Change FMDR logic to not set LUBSTCDM on LIC (Last in Chain)
for HDX/CTN protocol. This restores logic to its original
state and "WILL" most certainly result in multiple chains
being passed to the Host, If a PLU FMD (Function Management
Data) should be transmitted while an SLU (Secondary Logical
Unit) FMD is being transferred, it will be rejected if the SLU
is the contention winner. This original logic was changed to
set LUBSTCDM to prevent two consecutive FMDs from being passed
to the Host without an intervening Host FMD precisely to avoid
having to reject the Host FMD. Some applications cannot
handle this exception response.
Solution is to change XFNSLURU logic to ignore state of CDI
and test for PGM=VM³CICS unconditionally, old code was
commented out. Changed the flow control selection tests to
ensure that HDX/CTN is not sometimes treated as HDX/FF (Half
Duplex/Flip Flop), previous logic did not account for other
flags in common FM (Function Management) protocols.
S25066 - Comm-Pro Console Subsystem Users,
06-24-93 Logic changes were made to our Console Subsystem support to
address discrepancies in some of the command responses.
Accept period in front of the resource name to indicate that
name should not be tested for HEX (hexadecimal) data before
it is processed as an RRT (Resource Resolution Table)
element. This will allow the command to process resource
names that contain only HEX characters (EG, DA01).
Correct XFLKUP logic to "NOT" return RI=DLMCHAR if the DLM
is from routine LKUPDLT. RI=DLMCHAR will continue to be
returned when the DLM character is a CR (Carriage Return) or
SPACE (Some command processors need to refetch DLM
character). This change is required so that commands that
parse for text of the form A=B work properly. For example,
without this change, the CNET command USE=PKTSZ=128 would
be rejected while USE=PKTSZ 128 would be work. Now both
versions will work.
Take RB=0 exit with LO7=0 if CR is detected before any
command is decoded (companion change to XFCONX is required).
This change is required so that commands that parse for text
of the form A=(B) will work properly. For example, without
this change a CNET command that ended with a right paren-
thesis (EG, USE=(DTE)) would result in a Console error
message even though the command completed normally. The
problem occurred because routine XFLKUP would step past the
DLM (Delimiter) character to the CR character.
S25067 - Reserved. - ** See 1994 APAR Summary **
S25068 - ITI Users,
07-07-93 001B ABEND at offset X'0454' in XFXPKT can occur due to an
unusual timing condition. ABEND occurs because a CLEAR packet
request for an LCN (Logical Channel Number) is being scheduled
after the LCN has disconnected (Flag CCXLCN=0). This occurs
because routine XFNDISC is being called during X.25 Link RESET
processing to clear all LCN connections. Routine XFNDISC calls
routine XFNPRMQ to purge the Input Queue and routine XFNPRMQ
schedules a CLEAR packet because it detects flag L4MSCLR set
in CCXL4MF1.
Solution is to clear CCXL4MF1 flags in routine XFNDISC before
routine XFNPRMQ is called.
S25069 - QLLC and PSH CALLOUT Users,
08-02-93 0953 ABEND at offset X'D46' in module XFQLLCcc (cc=OBJQUAL in
BUILD) can occur due to a register usage error. ABEND occurs
when QLLC CALLOUT resources are activated (ISTATUS=ACTIVE or
manual activation).
Solution is to initialize the PUB address before the packet
address overlays the base register used for fetching the PUB.
S25070 - DSP/NCP DEVICE ADDR=..,NETID=NONE,NETADDR=(digits) Users,
08-02-93 Inbound DSP Call Request packets can be Cleared by Comm-Pro
with a DIAG=88 reason code due to a register usage and logic
error in our CRM (Connect request mode) decode for DEVICE
macro NETADDR mapping support.
The register usage error can prevent CRM-2 connections from
matching valid CU/DEVICE addresses which is done before the
NETADDR decode. The logic error prevented CRM-1 and CRM-3
connections from participating in the NETADDR decode. Problem
was introduced with the DSP Quick Switch Logic in SHIP25.
Solution is to restore R5 work register with DVBLCUA value
and allow CRM-1 and CRM-3 connections to participate in the
NETADDR mapping, bypassing branch to LUALFDVB if not CRM-2.
The CRM-3 connection will allocate based on NETADDR matches
only, non-specific device type mapping is ignored. The CRM-1
and CRM-2 connections must match the logical CU and DEVICE
addresses prior to the NETADDR lookup.
S25071 - Comm-Pro BPAD, ITI EP and EPMPX (BX25) Call-Out Users,
08-11-93 Users can experience data handling, session connect and run
time problems due to a bug in our new DPTTY and DPBPAD logic
that prevents the default POOL OPTIONS from being initialized.
This APAR is not required for resources that use the new DPTTY
or DPBPAD parameters. Only resources that used the standard
default OPTIONS require this corrective logic. Following are
the CALL REQUEST packet POOL OPTIONS that are used as defaults
by NAS as a function of the logical channel type.
LC POOL
Type OPTIONS Description
______________________________________________
BPAD SETMODE=0 No EIB
EPMPX FWD=(NO,CR) IP3=2,IP4=0
DEVCTL=NO IP5=0
BRK=ATTN IP7=21
ITI/EP FWD=(NO,CR) IP3=2,IP4=0
DEVCTL=NO IP5=0
BRK=ATTN IP7=21
TEXTTO=28 28 second READ timeout
Solution is to move the OPTIONS pointer to the head of the
default internal POOL to match DSECT so that local options
are used by routine XFNRFCOK.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
A PTF Object ZAP or Macro UPDATE is not available for this
APAR because the corrective logic contains relocatable code.
Please order a no cost CUME (Cumulative Maintenance)
Distribution tape should you require this fix. A simple
solution is to code the noted default OPTIONS on the POOLs
used for CALL-OUT and define the NETPATH support for DPTTY
or DPBPAD support.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
S25072 - Comm-Pro DSP CRM (Connection Request Mode) Type 4 Users,
08-12-93 0951 ABEND at offset X'19C0' in module XFTSNT due to a bad NCB
(Network Control Block) base register for CRM4 connect request.
Problem occurs because the connect data in a CRM4 Call Request
packet has not been initialized from the associated Display's
Circuit Enable packet. The connect data which is composed of
the NETID (Network ID) , LCN (Logical Channel Number ) and
UCN (User Circuit Number) for the Display is being passed to
NAS as all zeroes. In SHIP25, all non-X25 NCB's use a NETID of
zero, hence a match occurs on the first non-X25 NCB (XFTSNCB).
Because this NCB differs in form from an X25 NCP (No AVT), the
the associated DVB (Device Block) pointer comes up as trash
which causes the ABEND.
The solution is to reject a CRM4 that carries a NETID=0.
S25073 - Comm-Pro NCP/NEO (TYPGEN=NCP or PEP) Users,
08-18-93 0953 ABEND at offset X'578' in module CXDCG02 due to an
exhausted savearea chain. An IBM savearea Lease routine
initializes the next available savearea end pointer address
to X'FFFFFF' when the end of the chain is reached. The next
routine to request a savearea chain pointer is passed the end
pointer which will cause an ABEND when the end pointer is
addressed. Problem was observed at one site running NCP and
NEO resources with NCP V5R4 while processing a VR (Virtual
Route) HELD timeout condition. Register 6 is set to a local
Level 4 Savearea (XFQLSV) before the NCP release macro is
executed to return all owned PIU (Path Information Units)
buffers to the free pool. ABEND occurs because the local
savearea chain is only 10 deep which apparently is too short
for the NCP release logic.
The solution is to extend the savearea chain from 10 to 30 to
accommodate the unusually large savearea Lease chains.
S25074 - Comm-Pro NAS (Network Access Software) X.25 Users,
08-25-93 An X.25 link can get hung in an REJ (Frame level Reject) loop
because of an unusual timing condition encountered in our
ERP (Error Recovery Processing) logic. Problem is exacerbated
when X25LINK GROUP/LINE option T1=2 is coded in the Comm-Pro
SYSGEN (stage 1 source). When the T1 timer expires, we send
a polling I-frame (Information frame with P-bit set) which
demands an F-bit (Final) response. In the mean time data,
an RR (Receiver Ready) or RNR (Receiver Not Ready) frames
received from the X.25 network are used to acknowledge
outstanding I-frames.
The problem occurs because our polling I-frame is rejected
by the X.25 network because it is received (or processed)
after the network has acknowledged all of our transmitted
frames. The REJ (Reject) carries the F-bit and the NR
(receive sequence number) of the last transmitted frame +1
which is valid. We SABM (Set Async Balance Mode) when we
get the REJ because we think the NR value is incorrect. We
think it is incorrect because NETNS (Network Send Seq #) was
reset to the NS value in the last polling I-frame that we
transmitted. After we send a SABM, we receive an I-frame
before the UA (Unsequenced Acknowledgment) which we reject.
This is wrong for LAPB and is what causes the REJ loop, we
should ignore I-frames in INIT (Initialization) mode.
The solution is to not change NETNS when a polling I-frame
is transmitted but to update NETNS as I-frames are being
acknowledged in timer recovery mode, I.E., P-bit set in
frame that is being acknowledged. We must also ignore all
non-NS (Data, RR, etc) in INIT mode for LAPB circuits.
S25075 - DSP UCN Users,
09-10-93 Network reset loop (1B0002) can occur on when a RR request is
processed by the UDVB instead of the LDVB. This can result in
hung printer sessions.
Solution is to add logic to our CDVB subroutine to set LCD=C0
in the UDVB and LCD=C4 in the LDVB (XFBSLCB=04) which will
condition the resource to process the request on the correct
resource.
S25076 - Comm-Pro 3745 Users, .
09-15-93 Physical Lines on a 3745 scanner can hang in SETMODE state.
ACTLINK on NCP lines will fail to complete. This problem can
occur when a DISABLE command is running on a Contention Line.
The scenario is as follows:
1) Modem on a Contention Line that is SYSGENED with DIAL=YES
has a hot DSR (Data Set Ready) lead.
2) XFLNCM issues a DSBL (DISABLE) IOH (Adapter Input/Output)
and starts an 11-second DSBL timer (Note that the 3745
CSP (Communication Scanner Processor) is also running a
25-second DSBL timer whose value cannot be overridden
via a SETMODE command according to IBM).
3) DSBL will not end because the DSR signal will not go down,
hence our DSBL timer expires.
4) The DSBL timeout processor calls routine XFRSLN which
knocks the DSBL down with an HALTI IOH then reissues
another DSBL IOH. This is what caused the problem
because the time between the HALTI IOH and the DSBL IOH
is less than 200 MS, the 3745 scanner will not recycle
past the Contention Line to service the other lines on
the scanner. This is only a problem on the 3745 that
results from the scanner disconnect/reconnect logic.
The solution is to enforce a short delay (2-seconds)
between the HALTI IOH and the second DSBL IOH so that the
scanner has time to service its other lines.
S25077 - Comm-Pro DSP/NEO Users,
10-06-93 SDT (Start Data Traffic) PIU from host can end with incorrect
sense data 881C251C (other combinations possible) if it is
processed when the SLU (Secondary Logical Unit) is not
connected. Note that the 881C SDT EXCR caused the SLU to be
taken out of service. The correct status for 0831 is supposed
to tell CICS to UNBIND the session and wait for the Notify,
Power On indicator before it acquires the SLU again. This
problem occurred after the physical X.25 link went down due to
leased line carrier problem.
Problem occurs because the status register contains the status
value and not the address of the status value for the command
reject ender (LUALFL). This error is the result of a change
that was missed when the extended EXCR status support was
implemented.
The solution is to initialize the status register with the
correct status processor address.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*-1994-- SUMMARY NOT AVAILABLE
*
*-1995-- SUMMARY NOT AVAILABLE
*
* All users,
* CUME Tape Distribution reminder,
* We suggest that you order a Cume refresh tape if your existing
* Comm-Pro software TCD (Tape Creation Date) is older than
* December 31, 1995
*
* Please refer to the 'CUME Tape Distribution' section, Appendix
* F (Maintenance) in your documentation manual for additional
* information, including TCD determination.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- 1996 -- SUMMARY FOLLOWS
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
R_DACTLU - Comm-Pro NEO/NCP users,
01-26-1996 Newer VTAM maintenance levels can cause a change in the host
DACTLU RU length which causes Comm-Pro to reject the PIU with
1002 error sense (RU size was increase from 1 to 3 bytes).
Solution was to change our maximum RU size from fixed 1 to
open (no size limit) on our DACTLU decode.
R_BX25TRC - Enhancement - SHIP25 Mod 2 EPMPX (BX25) March Project users,
02-19-1996 Feature: BX25 RESTART Request Trace Support (Activation/
Deactivation) of physical X.25 link(s). Logic added to trace
all RESTART requests so that customer support technician(s)
can expeditiously identify over which UTS host a BX25 LINK
RESTART (Activation/Deactivation) was requested. A simple
review of history entries logged can identify the host domain
(CA#/SUBCH) that requested which physical X.25 link (NETID) is
to be activated.
A BX25 RESTART Request Trace entry will be generated in the EP
trace table each time a BX25 RESTART request is received from
the host application. There are no Comm-Pro console commands
required to start the trace. You will need to issue the 'DTRC'
command to display the history trace entries. Please refer to
the Comm-Pro console subsystem 'DTRC' display EP trace table
command for additional information.
R_EVLXF25 - DSP ONLY Environments (No ITI EPVIRT/Contention lines) users,
03-17-1996 X.25 link(s) fail to activate after 37XX IPL because a call to
XFL4IH is missing that services the DISABLE timer. X25 link
would appear hung and not come up because the DISABLE timeout
was not being processed.
Note: The customer that encountered this problem actually
erroneously neglected to include ITI or local line console
support which is generally required and circumvents this
problem.
Solution is to ensure that 'BAL R6,XFL4IH' instruction is
produced in XFFL4IH by changing the AIF from (&CTN+&ITI EQ 0)
to (&CTN+&EVL EQ 0). &EVL is the number of TYPE=EPVIRT lines
specified in the sysgen while &ITI is the remembrance of a
POOL with DEVTYPE=TTY coded.
R_L+FALRM - Console Alarm Subsystem users,
06-06-1996 Bypass 'WTO OVERRUN, ALARMS LOST' message and count WTO buffer
allocation failures in the hour byte position of the last
ready WTO buffer (number of missed messages displays when the
hour value is > = 25 decimal). Incrementing stops when count
reaches 99. Overrun WTO message is no longer displayed. The
alarm delivery interval was also changed from 3 to 1 seconds
in an effort to increase the alarm delivery rate.
These enhancements will prevent the continual display of
'ALARMS LOST' messages when more alarms are being generated
than can be buffered or delivered to the console device.
R_ITCTO - Enhancement - NAS X.25 users,
06-07-1996 Invitation-to-Clear (ITC) - timer support added to our logical
channel timer code that will start a timer (internal fixed
value INACTO=120) in the absence of any other timer when a
disconnect request is issued by the host for a logical channel
that has a connection (P4D1-Data Transfer Flow Control Ready).
If time-out expires before a CLEAR request is received, the
timer will check for ITC state and clear the call without
waiting for a CLEAR from the network. The 2 minute time-out is
more than adequate for X.25 networks that support ITC and
short enough for those that don't.
This enhancement is to prevent hung/unavailable resources that
can occur when the network or remote TPAD fails to respond to
our ITC with a CLEAR request.
R_VRAC - Enhancement - Comm-Pro NEO/NCP users,
06-07-1996 Virtual Route Alarm Activity Counter - Enhancement to count
NAS Virtual Route Hold and Release alarms. Logic will count
VR Held and Release conditions and display the current counts
in the ANS WTO SNA alarm. Counts are also available in a local
history counter.
This enhancement is a diagnostic aid that will help reveal
virtual route congestion or excessive pacing activity.
Excessive counter activity may reveal that the virtual route
pacing window size is set too low.
R_BP/BFP - Enhancement - 3745 X.25 users,
06-07-1996 X.25 Buffer High Memory Support - Enhancements for 3745
environments (NCP V5R4 and above) that will allow the Comm-Pro
X.25 Receive and Transmit buffer pools to reside above the
previously restricted 4MB boundary. (Sysgen buffer creation
logic was also redesigned to punch 1 output record per buffer
pool instead of several records per buffer).
This enhancement will better utilize available memory for 3745
FEP(s) and allow larger configurations, especially those that
require fixed, non-contention resource definitions such as
DSP/NCP.
R_RRT - Enhancement - 3745 X.25 users,
06-07-1996 RRT High Memory Support - Enhancements for 3745 environments
(NCP V5R4 and above) that will allow the Resource Resolution
Table ($RRT) to reside above the previously restricted 4MB
boundary. (An image of the $RRT is copied into the load module
for use by our DBNN console command).
This enhancement provides the same benefits as the Buffer High
enhancement R_BP/BFP.
R_V7R4_V7R5 - NCP Version 7 Release 4 and 5 Support,
07-07-1996 Support included in our standard SHIP25 Mod 2 release.
R_STG1 - MVS users,
08-01-1996 Our CPSTG3 (Comm-Pro Stage 3) step NDFPLI step can encounter
errors due to inadequate temporary work space defined for the
XFNDTB1 work file. Solution was to increase the default value
20 to 100 TRK's.
R_ALRMWTO - Console Alarm Subsystem users,
09-23-1996 Default Build, WTOBFCT= was change from 10 to 25 to allow for
greater alarm event capacity.
R_NDFPLI - RRT High Support for TYPGEN=NCP users,
10-30-1996 The RRT was not being moved into high memory in NCP only
environments due to an incorrectly positioned insert location
which caused $NEOMHI to go undetected for TYPGEN=NCP which
resulted in the $RRT not being properly positioned. Note that
we include a copy of the $RRT for our DBNN console command.
Solution was to move PL1 logic that scans for $NEOMHI after
label INCL_DDNM_SCAN_SKIP so that it will be detected in an
NCP only sysgen.
R_GIDPID - NCP/NEO CONNOUT (Switched Major Node) users,
11-26-1996 VTAM error messages encountered during activation of our
Switched Major Node after a newer VTAM level was installed.
The default GID=0 and PID=0 values on the PATH= macro are no
longer valid. The values must now be in the range of 1-255.
Solution was to change our default value from 0 to 1.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- 1997 -- SUMMARY FOLLOWS
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Note All users,
01-01-1997 CUME Tape Distribution reminder,
We suggest that you order a Cume refresh tape if your existing
Comm-Pro software TCD (Tape Creation Date) is older than
December 31, 1996
Please refer to the 'CUME Tape Distribution' section, Appendix
F (Maintenance) in your documentation manual for additional
information, including TCD determination.
R_XFSETUP - VM/CMS Environment - Comm-Pro Product Installation,
01-15-1997 Conditional execution logic added to the XFCOMMPRO EXEC.
Exec user will be prompted to allow XFSETUP to execute or
to NOP. Note that XFSETUP is shipped as a "sample' setup
EXEC which requires customization at each site. Additional
XFSETUP information was added to our SHIP25 documentation
manual on May 19, 1997.
R_XFCOMMPRO - VM/CMS Environment - Comm-Pro Product SYSGEN Support,
01-20-1997 XFCOMMPRO EXEC was modified to report an error condition if
the Comm-Pro Stage 1 input file is not RECFM=F. This condition
was previously causing our EXEC to 'get lost' when it scanned
our BUILD macro. Logic was also added to detect unusual XFR90
and XFBR14 set-up to prevent our Stage 3 Table 1 and Table 2
assemblies from failing because IHR90 cannot be found.
R_ALIGN4 - 3745 MVS Environments - Comm-Pro Product SYSGEN Support,
03-17-1997 Newer SSP libraries no longer support the ALIGN4 link edit
parameter. Comm-Pro Stage 3 and 4 LKED step encounters error
message encountered 'IEW2020E OPTION NAME ALIGN4 IS INVALID.
OPTION IGNORED.' Solution removed the ALIGN4 parameter from
our LKED step parameter list.
R_BUILDJC - MVS and DOS/VSE Environments - Comm-Pro Product SYSGEN Support,
04-18-1997 Logic added to force our JOBCARD=YES option for TYPXEQ=AUTO
environments. This will prevent submission of the Stage 3 job
stream without a jobcard.
R_NEO-SNI - Users of Comm-Pro NEO Products Across SNI FAT Links,
05-04-1997 Comm-Pro DSP resources routed over an SNI FAT Link instead of
the Channel Adapter encountered buffer header data in with the
user data due to a secondary buffer boundary condition.
Solution is to change FMDX700 logic to apply the buffer offset
(U1OFFSET) when forming the SOD (Start of Data) pointer in the
secondary buffer.
S25098 - DSP, Network Address System Select Pool (Form 6) users,
07-01-1997 Introduction of our X.25 Buffer High Support on 06/17/1996
distribution caused us to reject the Network Address System
Select Call Request with a Clear Diagnostic 7F.
Solution is to disable unnecessary X.25 transmit and receive
buffer location debugging validity check logic that previously
required the Call Request packet buffer to be located between
the X.25 Receive and Transmit buffer header. Note that our
Buffer High Support relocates the buffer pool's, not the buffer
headers.
R_TNUNCT - DSP users,
Enhancement added to count DSP Response Undelivered events.
This global fullword counter will allow us to monitor and
identify the frequency or magnitude of the Response Undelivered
activity. Counter located via Comm-Pro Console display 'DCSA'
at entry XFTNUNCT.
R_RACXF25 - NAS NEO/NCP users,
07-01-1997 VRHELD and VRREL global fullword counters can now be located
via the Comm-Pro Console display 'DCSA' at entry XFSWTOCT.
S25099 - ITI/EP users,
07-29-1997 001B ABEND at offset X'50A' in module XFNSSC (RDTO200) due to
an unusual timing condition where input arrives after the
timeout expires but before CCBCLOCK is reset. A window exists
in XFNNQRMQ (Level 4 routine) that allows CCBCLOCK to continue
to run after a packet is enqueued to (CCXIQ) input queue.
CCBCLOCK is not reset for approximately 15 instruction cycles
after the enqueue. If the Level 3 input timer expires during
this window, the ABEND will occur at Level 3.
Solution is to change the Level 3 timeout logic to simply
ignore this condition which will allow the logic to correctly
handle the input sequence.
R_JC234XF25 - MVS and DOS/VSE Environments - Comm-Pro Product SYSGEN Support,
10-07-1997 We now provide users the ability to define unique jobcard JCL
for the Comm-Pro Stage 1 - 4 generation process.
R_NDFPLI900 - 3746-900 Attachment - Comm-Pro Product SYSGEN Support,
12-31-1997 Comm-Pro Stage 3 (NDFPLI Step) Sysgen, **ERROR** 'LINE ADDRESS
0 (DECIMAL) DEFINED AS NCP RESOURCE IN NDF AND EP RESOURCE IN
XF GEN'. Note that for logical ODLC lines (LOGICAL=1,OLDC=1),
NDF sets RLNUM=0 which is what we key on to set the NCP lines
in use indicator. It turns out that when real line address 0
is used in the Comm-Pro Stage 1 source (CPSTG1) we appear
(erroneously) to have a conflict.
Solution is to test for LOGICAL=1 when we decode the CXTACB
macro and, if found, simply bypass the macro.
Note that Comm-Pro resources are not currently supported on
the model 900.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- 1998 -- SUMMARY FOLLOWS
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
R_ACTLUNTFY - DSP NEO users,
R_ACTLUIPL Enhancements were made to our ACTLU Request and Response logic
01-05-1998 that reduces the overhead encountered during 37mm IPL (Load)
and VTAM resource activation.
IBM_NOTE - NAS NCP/NEO Environments - Stage 3 Product Sysgen Support,
02-18-1998 Undefined Opcode XCXTSN2 is encountered in some of the CPSTG3
(Comm-Pro Stage 3) sysgen steps due to an incorrect reference
in IBM macro XCXTSNP. This macro is provided for programmed
resources such as Comm-Pro's NEO or IBM's NPSI products.
This error was introduced when IBM included a portion of some
new logic for future support. This condition was observed at
site's running NCP V7R5 and V7R6.
Please refer to IBM PTF IR37176/UR49533 for corrective logic.
R_NCP_V7R6 - NCP Version 7 Release 6 Support,
03-06-1998 Support included in our standard SHIP25 Mod 2 release. V7R6 is
now the default value in our Stage 1 (CPSTG1) BUILD, VERSION=
parameter.
S25100 - ITI/NCP users,
03-13-1998 BID rejected with 0814 Sense, Change logic so that Bracket
indicators are used when an RTR expected remembrance is set.
Corrective logic will eliminate the unusual timing condition
that caused the BBI (Begin Bracket Indicator) to be sent
before the "owed" RTR was scheduled.
S25101 - NAS X.25 users,
03-25-1998 An X.25 link initialization anomaly was observed during link
*.TXT start-up which can cause the first I-frame to be scheduled on
*.ZIP our primary before a UA is sent on our secondary in response
to a SABM (link activation request) from the network. This
condition causes a momentary delay when the I-frame must be
resent due to rejection by the remote secondary component
pending UA confirmation.
Solution is to change LKOT logic to bypass XCTL to PRXI when
NETXFBFA=0 and SXRSUA=1. This will prevent I-frame from beating
the UA response for the SABM. This change is primarily for LAPB
networks where a SABM from either end initializes both. For LAP
nets which have independent primary and secondary components,
the affect is a momentary delay to outbound transfers.
R_2ITCTO - NAS X.25 PVC users,
04-07-1998 An error introduced in our 06/07/1996 Invitation-to-Clear
(ITC) timer support enhancement can prevent PVC resources from
connecting to the host resources. Condition occurs because the
PVCACT (PVC Connection Attempt) timer fails to initialize.
For BX25 (March Project) PVC resources, the UNIX host reported
a 'PVC OUT' error condition. Comm-Pro console alarms (CPCONS)
reports event ITI LCTMR, DIAG=1C on PVC resources because the
Invitation-to-Clear timer expires in lieu of the PVC connect
timer.
This bug was introduced on 06/07/1996, users with a TCD (Tape
creation Date) prior to this date do not require corrective
logic.
Solution is to check for PVC connection and bypass the ITC
inactivity timer if so.
R_ACTPU - Comm-Pro NEO/NCP users,
06-15-1998 ACTPU from host rejected with 1002 error sense due to new
*.TXT RU length exceeding our 9 byte length limit. VTAM V4R4 or
*.ZIP OS/390 V2R4 host maintenance update changes ACTPU RU length
from 9 to 12 bytes.
Solution is to accommodate the new RU length by setting the
maximum RU size to open.
NODATE_ - NDFPLI output results under year 2000 test system date,
08-01-1998 - Program can display a garbled date when our NDFPLI program
is executed on a system with a test date greater than
December 31, 1999. This is because the precompiled version
of our NDFPLI program was compiled under PL/I Version 2.1
which does not display the YYMMDD PL1 (BUILTIN) DATE format
correctly. Note that our NDFPLI (nor any other Comm-Pro
programs or utilities) do not use the system date for any
computational functions. The 'TODAYS DATE: MM/DD/YY' was
being displayed in the report output for comment purposes
only and is not required.
Solution is to recompile the NDFPLI program with the newer
PL1 libraries that generate the date field correctly.
We decided to remove the cosmetic 'TODAYS DATE:' display
from our source and recompile the program to eliminate any
potential confusion.
Note: Currently our standard PL1 utilities are compiled
under Version 2.1 of the PL1 optimizing compiler for back-
wards compatibility. We also provide an optional CP25UT
tape for MVS environment with the PL1 utilities compiled
under 5668-910 IBM OS PL/I Optimizing Compiler Ver 2 Rel 3
Mod 0 which correctly displays the cosmetic 'TODAYS DATE:
MM/DD/YY' display under Year 2000 system dates.
CP_NOTE - IBM OS/390 LE (Language Environment) PL1 Comm-Pro users,
08-27-1998 OUR NEOBLD OR NDFPLI program execution can abort with an
S000, U4000 due to changes in the PL1 run time libraries
for the MVS OS/390 LE PL1 environment. Some PL1 levels
under the newer LE environment require that the primary
STEPLIB reference SYS1.LINKLIB instead of SYS1.PLIBASE
or SYS1.SIBMBASE.
Solution is to simply code PL1LIB=dsn.LINKLIB on the CPSTG1
(Comm-Pro Stage 1 source) BUILD macro parameter and rerun
the sysgen. You can use our PL1 PLITEST program to confirm
that your new LE environment supports the new run time
library without having to run a Comm-Pro sysgen to verify
proper LE library specification.
----------------------------------------------------------------------------
SHIP25 Maintenance Summary Detail End
Last Update - March 15, 1999