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. 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 start-up which can cause the first I-frame to be scheduled on 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 RU length exceeding our 9 byte length limit. VTAM V4R4 or 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 *END-OF-FILE* (THIS FILE BEST VIEWED WITH A FIXED FONT SUCH AS COURIER)