Patch-ID# 100308-01 Keywords: snap2p appc p2p v3r2 Synopsis: SunLink SNA peer-to-peer 6.0 patches Date: May-30-1991 SunOS release: 4.0.x, 4.1, 4.1.1 Unbundled Product: SunLink SNA Peer-to Peer Unbundled Release: 6.0 Topic: SunLink SNA Peer-to-Peer 6.0 BugId's fixed with this patch: 1039512 1039530 1039833 1040324 1040327 1040544 1041248 1043223 1043224 1040647 1046173 1057922 1022937 1059125 Architectures for which this patch is available: sun3, sun4 Patches which may conflict with this patch: 100197-04, 100277-01 100288-01 Obsoleted by: Release 7.0 Problem Description: This is SNAP2P Version V6.8.4 1) APPC responds to a BIS request with a BIS request instead of response Bug #1039512 The appc gateway incorrectly responds to the remote's Bracket Initiation Stopped (BIS) request with a BIS request instead of a response. Subsequent UNBIND request from remote causes problems for the gateway. 2) test_p2p only allows 5 character EBCDIC TP names when calling mc_allocate - Bug #1039530 The test_p2p test program allowed only 4 bytes for EBCDIC TP names (plus the terminating 0x40, which gives 5 bytes) because the [mc_]allocate_proc verbs only allowed 4 bytes. The patch makes the allowable EBCDIC TP name length the same as for the ASCII TP name length (MAX_TP_NAME). ***One important change to note is that the array containing the EBCDIC TP name must terminate the TP name with an 0x40 *and* 0x00. See test_p2p.c for an implementation of that change. 3) appc coredumps if the 2 byte record length is split across 2 frames Bug #1039833 If an appc record (format: LL, where LL is a two-byte field containing the record length, including the length bytes, and is the data portion of the record) has the first byte of the record length as the last byte of an SNA frame, and records are being retrieved with the mc_receive_and_wait verb, appc coredumps. 4) cnos.h not included on distribution tape - Bug #1040324 The responsible makefile did not copy cnos.h to the distribution directory. 5) After BIS request, an incoming UNBIND does not return all resources Bug #1040327 Not all session resources are returned when an incoming UNBIND is processed. Subsequent incoming bind for that LU uses a reference to the previous binding. 6) No way to find out which LU an incoming allocate is using - Bug #1040544 This is a problem for the TP that only gets back the conversation id from the tp_wait_remote_start() verb. If all incoming allocates specify the same TP name, there is no distinguishing characteristic other than the local_lu_address (or maybe the mode). An addition to the display_local_lu() verb has been made so that it returns an array of the active conversation ids using that lu_local_address. It's sort of a roundabout way to find your conversation's local lu address; you have to call display_local_lu() for each lu_local_address (an entry under the :DEFINE_LOCAL_LU: verb in the p2pconf input file) until you find your conversation id in the returned array. However, applications aren't really supposed to know which LU its conversation is using. 7) Conversation-Level Security added Four new verbs, s_tp_listen, s_tp_wait_remote_start, s_allocate, and mc_s_allocate, were added to provide conversation-level security for customers that requested it. 8) send_error in rsp to send_data (confirm) crashes gateway - Bug #1041248 9) Core dumps when calls made to an unknown gateways - Bug #1043223 apilib.o routines did not check if the gateway fd (socket for communicating with the gateway) or the err_file fd (for error output) were nil before using them, causing SEGV errors. 10) TP goes into strange state after tp_end-ing to an unknown gateway Bug #1043224 The tp_end verb did not check if the gateway fd was nil before close()ing it. 11) startp2p script is not working correctly - Bug #1040647 The start script resulting from the rfe for Bug #1022654 did not work right when the serial port was on the MCP. The start and stop scripts have been rewritten, but are only available in the 7.0 release. 12) receive_and_wait doesn't return all data after a request_to_send Bug #1046173 While the local TP is receiving data, it issues a request_to_send. The remote side sends a few more data frames before responding to the signal. The remote then continues to send more data. Only one data record is returned after the local TP returns from the request_to_send call and issues another receive_and_wait. The TP doesn't return from the subsequent receive_and_wait. Problem was incorrect requeuing of "leftover" data (in this case, the next data record). 13) VTAM V3R2/3 compatibility Adds XID negotiation and (outgoing from Sun) extended bind support. p2pconf has new parameters to obsolete sp_flags and xid. 14) APPC DFC is not handling stray SIGNALs correctly. Bug #1057922 APPC is getting a "late SIGNAL" positive response, and instead of discarding it (as it should architectually), it is treating it as a protocol violation, and sending an UNBIND. 15) SNAP2P can not support extended BIND on host-PU2.1 connection Bug #1022937 Our current SNAP2P product can not handle (or negotiate) extended BIND from the host. Extended BIND is used in the latest VTAM release 3.2 to communicate with a SNA station in LU6.2-PUT2.1 environment. 16) Appc core dumps when TP is killed - Bug #1059125 If a TP exited (^c or kill) while sending a large record (e.g., 32K) to the gateway and then subsequently restarted (thereby sending another tp_start() verb), the TP would not get properly connected to the gateway and the gateway would core dump when the second execution of the TP exited through a ^c or kill. Also added is the ability to specify a maximum length of the trace file. In the p2pconf configuration input file, under the :DB_MSG: verb section, add: db_max_trc_sz = n where 'n' is an integer value indicating the maximum number of megabytes for the size of the trace file. The trace file will be circular, so there will not be loss of tracing information when the log "rolls over". The actual size of the trace file will usually exceed the 'n' megabytes by some number of bytes (less than a few hundred) as the size check is made after the current event is logged. INSTALL: first backup all the files under the following directory: /usr/sunlink/snap2p then restore the patch in a patch directory then cd to the patch directory # cp -r sun{3,4} /usr/sunlink/snap2p Rebuild the kernel, i.e. re_install appc. Lastly,recompile all the Transaction Programs. There are sample configuration files provided with this patch. The definitions are for MVS only. IBM configuration files: PU.DEFINITIONS VTAM.APPLID.DEFINITIONS VTAM.LOGMODE.DEFINITIONS VTAM.SSCP.ATCSTR00 - VTAM startup filename. SUN configuration file: sample_config.vtam.v3r2 Estimated Size of this patch: 3099 KB