DEC TCP/IP UCXECO14-031 TCP/IP V3.1 for OPENVMS VAX/AXP ECO Summary

NOTE: An OpenVMS saveset or PCSI installation file is stored on the Internet in a self-expanding compressed file. The name of the compressed file will be kit_name-dcx_vaxexe for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha. Once the file is copied to your system, it can be expanded by typing RUN compressed_file. The resultant file will be the OpenVMS saveset or PCSI installation file which can be used to install the ECO. Copyright (c) Digital Equipment Corporation 1994, 1995. All rights reserved. PRODUCT: DEC TCP/IP Services V3.1 for OpenVMS VAX DEC TCP/IP Services V3.1 for OpenVMS Alpha OP/SYS: OpenVMS VAX OpenVMS Alpha SOURCE: Digital Equipment Corporation ECO INFORMATION: ECO Kit Name: UCXECO14-031 ECO Kits Superseded by This ECO Kit: UCXECO12-031 UCXECO5-031 ECO Kit Approximate Size: 42,606 Blocks Kit Applies To: OpenVMS VAX V5.5, V5.5-2, V6.0, V6.1 OpenVMS Alpha V1.5, V6.1 System Reboot Necessary: Yes ECO KIT SUMMARY: An ECO kit exists for DEC TCP/IP Services V3.1 on OpenVMS VAX V5.5 and higher and OpenVMS Alpha V1.5 through V6.1. This kit addresses the following problems. If more detailed information is needed, please see the Release Notes in the kit. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 Kernel images ---------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 27-May-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX T3.1-32B o Problem: Access to socket structures is synchronized at IPL 8. Checks were being made during FDT SetMode processing to insure the presence of the Protocol Control Block (PCB) address in the SO$L_PCB field of the socket structure at an IPL lower than 8. This left a window open wherein a connection could be torn down and the SO$L_PCB field zeroed which caused an ACCVIO in SetMode processing and a subsequent system crash. Solution: Moved checks for the presence of the PCB into IPL 8 code. ECO B 24-Jun-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX$INTERNET_SERVICES.EXE UCX$INTERNET_SERVICES_SEC.EXE UCX$INETACP.EXE o Problems: 1. The security driver crashes when the @ip_secvec$l_ip_output routine returns an error status. 2. The security driver swapped R4 and R6 in calls to @ip_secvec$l_ip_input with respect to the V2.0 behavior. 3. The proxy cache was not searched correctly when wildcard proxies were involved. This led to proxies which did not appear to be dynamically loaded, even though they were, and to non-wildcard proxies not being found when similar wildcard proxies existed for different usernames. Solutions: 1. Change a branch destination in INET_IF_VCI.MAR to correct the system crash. 2. Restore V2.0 register usage. 3. Correct two coding errors in the proxy handling routines. ECO C 27-Jun-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX$INTERNET_SERVICES.EXE UCX$INTERNET_SERVICES_SEC.EXE o Problem: When the partner for a TNDRIVER connection became unreachable, the system would hang intermittently (looping at high IPL). Solution: In routine INET_SOSEND, ignore SS$_UNREACHABLE status. ECO 2 Updates: -------------- There were no additional changes to this facility in ECO 2 ECO 3 Updates: --------------- ECO D 19-Jul-1994 Alpha and VAX Images: UCX$INETACP.EXE UCX V3.1-32D o Problems: 1. System crashes occur in INETACP_REXEC_ABORT_AST_CONT due to the referencing an REQCB that had been previously deallocated. 2. System crashes due to misuse of a register, where the same register is used to contain a channel number and the address of a descriptor. 3. System crashes occur during UCX shutdown in an AST delivered to the INET_ACP, where reference is made to the INETCB after it has been deallocated. Solutions: 1. Synchronize the deallocation of the REQCB and avoid the problem. 2. Use a different register for the two purposes. 3. In the AST routines INETACP_QUE_AST_CONT and INETACP_QUE_AST_CONT check for the existence of INETCB before using it. ECO 4 Updates: -------------- ECO E 10-Aug-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32E UCX$INTERNET_SERVICES.EXE UCX V3.1-32E UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32E o Problem: Memory corruption results when ACCEPT completes after ACCEPTER BG device has been deassigned, but before the LISTENER BG device is deassigned. Solution: 1. Create a new UCB field that is used only for ACCEPTER UCBs. The name of that field is UCB$L_BG_ACCEPT_BACKPTR. For this V3.1 ECO, the first longword beyond the end of the BG UCB is used for this purpose, because both for VAX and for Alpha, the INET$C_INET_LENGTH is not a multiple of 16. 2. In INET_ACCESS.MAR, store the address of the LISTENER UCB into the new UCB$L_BG_ACCEPT_BACKPTR field of the ACCEPTER UCB at the time that an IO$_ACCESS!IO$M_ACCEPT QIO is received. 3. In the INET_ACCEPT_RESTART routine in INET_ACCESS.MAR, before writing into the ACCEPTER UCB, verify that it has not been deassigned by comparing the address of the LISTENER UCB to the contents of the ACCEPTER's UCB$L_BG_ACCEPT_BACKPTR. If they are not equal return an error to the user. 4. In the INET_CANCEL_COMMON routine in INET_MAIN.MAR which is passed each time a BG device is deassigned, clear the contents of the UCB$L_BG_ACCEPT_BACKPTR field. This will assure that the verification described in #3 above will fail properly. ECO F 11-Aug-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32F UCX$INTERNET_SERVICES.EXE UCX V3.1-32F UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32F Problems: Setting the minimum number of large buffers too high (more than 13 with FDDI-size buffers, or more than 31 otherwise) could cause memory corruption and a subsequent system crash. Small buffer usage for certain purposes, such as socket names, was incorrectly tracked. When dynamic buffers were used, the dynamic counter was incremented, but when the buffers were later deallocated, the counter for static buffers was decremented. This led to dynamic counts which grew very large, while the static count usually fell below zero and would show up as a number in the 65000 range. Solutions: 1. Check the minimum buffer setting for validity. 2. Decrement the appropriate counter when deallocating small buffers. ECO G 30-Aug-1994 VAX Only Images: UCX$INTERNET_SERVICES.EXE UCX V3.1-32G UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32G UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32G UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32G UCX$INETACP.EXE UCX V3.1-32G o Problem: The TCP initial sequence number was being improperly reset every time a new TCP connection was initiated. This occurred due to an overflow in an internal data structure, which needed 8 bytes but was only allocated 4. The problem was most visible when using the UCX RSH client to repeatedly execute commands on a remote host. Due to the improper sequence number, commands after the first one would be delayed until the first completed, typically about 30 seconds. Solution: Allocate 8 bytes for the data structure, on the OpenVMS VAX platform. This was already done by the linker for Alpha, which allocated a quadword-aligned region. WARNING: Be sure to copy this new UCX$INETACP.EXE image when installing this update. If only the UCX$INTERNET_SERVICES image is used, UCX will not function properly due to shifted data structures. ECO H 7-Sep-1994 Alpha and VAX Images: UCX$INTERNET_SERVICES*.EXE UCX V3.1-32H UCX$BGDRIVER*.EXE UCX V3.1-32H o Problem: The service limit was not properly enforced for UDP NOLISTEN services, such as NFS. This led, on occasion, to the startup of multiple NFS server processes even when the service limit was set to 1. What happened internally was that an incoming packet could arrive in the middle of a transmit operation, during which the NFS server's device socket was temporarily bound to a different remote address/port. Solution: Check the service limit before starting a new process. If the limit has already been reached, return an ICMP port unreachable message and discard the original UDP datagram. ECO 5 Updates: -------------- ECO I 19-Sep-1994 Alpha only Images: UCX$BGDRIVER*.EXE UCX V3.1-32I o Problem: Use of the shutdown() function with a direction code of 0 (receive only) would result in an error being returned, with SS$_ABORT in the OpenVMS-style status and garbage in the UNIX[R]-style errno, even though the function actually worked properly. Solution: Fix an uninitialized variable problem within the driver, so that the spurious error status will no longer be returned. By coincidence, this problem is masked on the VAX platform, because the relevant register happens to be zero. Therefore, the fix is only necessary on OpenVMS Alpha systems. ECO K 3-Oct-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32K (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.1-32K UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32K UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32K UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32K UCX$INETACP.EXE UCX V3.1-32K o Problems: 1. System crash with KRNLSTAKNV. 2. System crash with SPLRSTERR. The spinlock to be conditionally released is not owned. Solutions: 1. On Alpha V6.1, the system crashed in the INETACP process while processing a gethostbyname request. The code that processes this request realizes that it needs more kernel stack than normal to complete its processing and explicitly switches stacks to a P0 allocated stack for this purpose. Unfortunately, it appears that the size of this pre-allocated additional stack was not big enough for the Alpha V6.1 environment and there was not enough left in the stack when an interrupt occurred close to the end of the stack. The solution is to pre-allocate an additional page of stack (i.e., 8KB) for Alpha. This fix is in INETACP_GET.MAR, which contains the code to process gethostbyname and other similar functions. 2. Some code from an earlier test version was left in INET_CKSUM.MAR and it arbitrarily lowered IPL, via an UNLOCK of IOLOCK8, when computing the checksums of large (greater than 1500 bytes) packets. The lowering of IPL at that point was incorrect and could lead to a crash. The crash occurred if an IPL 8 interrupt occurred at that point. ECO L 5-Oct-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32L (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.1-32L UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32L UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32L UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32L o Problem: Simultaneous use of select and attention ASTs on the same UCB will result in a system crash. Solution: Prevent accepting a select request in ANY of the UCBs in any of the lists that has an active ATTN AST request. Note that to implement this fix in the ECO stream, new enhanced select code from V3.2 was incorporated. Therefore, this ECO also introduces the new functionality that supports an indeterminate number of UCBs in a select list. ECO M 20-Oct-1994 Alpha and VAX Images: UCX$INETACP.EXE UCX V3.1-32M o Problems: 1. Disabling an active UDP Listen service, such as BOOTP, could also eliminate the listener device for another service. 2. When using the CASE_INSENSITIVE flag with the RSH service, usernames containing numeric characters were not found in the proxy cache. Solutions: 1. Zero the saved channel number when handing off the listener device to a newly-created server process. 2. Apply consistent logic in handling the possibly-lowercase characters in the proxy cache. ECO 6 Updates: -------------- ECO N 26-Oct-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32N (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.1-32N UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32N UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32N UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32N o Problem: The 'UCX SHOW ROUTE' command can result in a system crash. Solution: A loop in INET_SENSE_ALL_ROUTES was terminated with an AOBLEQ instruction, rather than an AOBLSS instruction. This resulted in one too many passes through the loop. In most cases this was benign, but when the number of ICMP redirect messages received by the system was between 8000 (hex) and FFFF, the result was a crash. The solution is to replace the AOBLEQ with the AOBLSS and eliminate the problem. ECO 7 Updates: -------------- ECO O 16-Nov-1994 Alpha and VAX Images: UCX$INETACP.EXE UCX V3.1-32O o Problem: Adding more than 2048 entries to the communication proxy database causes the system to crash. Solution: Adding entries means shifting existing proxies in memory using a MOVC instruction which is limited to 64 kbytes of data. A new macro, MOVCL3, is designed which uses a loop when necessary to avoid the 64KB limitation. This is a retrofit of a V3.2 fix back to V3.1. ECO P 28-Nov-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX$INTERNET_SERVICES.EXE UCX V3.1-32P UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32P UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32P UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32P o Problems: 1. A system crash may occur in routine INET_SOACCEPT upon reference to the socket structure pointed at by the Listener UCB. 2. A system crash may occur due to corrupted pool when the 'UCX SHOW COMM/MEM' command is used. Solution: 1. By the time that INET_SOACCEPT is called, the socket that belonged to the Listener UCB may already be deassigned. In that case, the UCB$L_BG_SOCKET field in the Listener UCB will be zero and a reference to the structure will cause a crash. New code has been added to check for this possibility and avoid the access violation if the field has been zeroed. 2. In the INET_SENSE_MBUF_COUNTERS routine in INET_SENSEMODE.MAR, some byte arithmetic was incorrect when the byte value was greater than 128 decimal (i.e., 80 hex). 80 hex is a negative integer and, as a result, the size of an allocated pool buffer was calculated incorrectly. That caused more than the allocated amount of space to be used. ECO 9 Updates: -------------- ECO Q 17-Dec-1994 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32Q (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.1-32Q UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32Q UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32Q UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32Q o Problem: If R8 contains zero, a system crash may occur in routine INET_IPINTR+1F3 upon reference to a supposed IF_UCB structure pointed at by R8. Solution: At this point in the code, R8 is pointing to the IF_UCB of the interface over which the current MBUF was received. However, since the loopback interface does not have an IF_UCB structure, if the current MBUF had been received over the loopback interface, then the system may crash. The crash is now prevented by dropping the packet if R8 is zero. ECO R 9-Jan-1995 Alpha Images: UCX$BGDRIVER.EXE UCX V3.1-32R (Alpha) o Problem: Use of the #pragma member_alignment preprocessor option on Alpha has led in one instance to a mis-alignment of data structures between the C code and Macro code. The data structure in question is the inpcb structure. Although it is not certain what all the ramifications of this problem are, it is felt that this bug has probably contributed to several unexplained Alpha crashes, especially those involved with dynamic routing. Solution: An explicit word filler was introduced into the $INPCBDEF in INET_NPGD.SDL, and the INET_SETMODE.MAR module was recompiled after the libraries were rebuilt. This should have re-synchronized the data structures. However, it should be noted that the source for INET_NPGD.SDL is now in the [...SRC_PAT.NET] tree for V3.1 and the a build for ...SRCLIB SRCLIB... was done for the two Alpha streams only. That means that for the VAX side a library rebuild should be avoided during the rest of the life of V3.1 and its ECOs. ECO 10 Updates: -------------- ECO S 12-Jan-1995 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32S (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.1-32S UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32S UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32S UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32S UCX$INETACP.EXE UCX V3.1-32S o Problems: 1. A system crash may occur in the UCX$INET_ROUTED process or while running in UCP during the execution of a 'SHOW INTERFACE' command. 2. A system crash may occur in INETACP at INETACP_SERV_ACCEPT+1B1 in INETACP_CREPROC.MAR. 3. The system may hang hang for between 10 and 15 minutes when FTP is aborted from a remote Macintosh[R]. Solutions: 1. If the local interface, LO0, is deleted through a 'SET NOINTER LO' command, the BGDRIVER database is left in an inconsistent state. The solution is to disallow the deletion of this interface at the driver level. In the INETACP_ETHERNET.MAR module of the INETACP_DELETE_ETHERNET subroutine, a test has been added to determine whether the interface to be deleted is that of LO0 and, if it is, the request is terminated. 2. A failure occurs in accepting a connection because the maximum number of sockets has been surpassed. In cleaning up, a crash occurs after referring to a field, REQCB$L_UCB_2 that has not been initialized in this path. The solution is to initialize this field and also REQCB$W_CHAN_2 when the REQCB is created in INET_REMOTE_ACCEPT in the INET_ACCESS routine. 3. In INET_RCV_XMT.MAR in the INET_ENQ_IO subroutine, if R1 were ever to have a negative number in it, the result would be a long loop, encompassing billions of passes, at elevated IPL. To eliminate this possibility, a sanity check has been introduced into the loop. ECO T 24-Jan-1995 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32T (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.1-32T UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32T UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32T UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32T UCX$INETACP.EXE UCX V3.1-32T o Problem: The system crashes in INET_FREE_MBUF_CHAIN when calling @VCRP$A_DEALLOC_RTN during the deallocation of a VCRP. Solution: In IP_INPUT_VMS.C, explicitly declare several instances of invocations of the "sizeof" function used in comparisons to be of type (int) so as to force the generated code to use signed comparison instructions. Note that the crash was caused by something clearing the VCRP$A_DEALLOC_RTN field, although it was never determined what cleared the field. ECO 13 Updates: -------------- ECO U 21-Mar-1995 Alpha and VAX Images: UCX$BGDRIVER.EXE UCX V3.1-32U (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.1-32U UCX$INTERNET_SERVICES_V6.EXE UCX V3.1-32U UCX$INTERNET_SERVICES_SEC.EXE UCX V3.1-32U UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.1-32U UCX$INETACP.EXE UCX V3.1-32U o Problem: When using SELECT with null lists on a multi-processor, SELECT fails with a strange error code in the IOSB. The routine INET_SELECT_BUILD_LIST, when called with null lists, was not setting a status code into R0. As a result, the previous contents of R0 were retained. On single CPU systems, this previous value was SS$_NORMAL, however on multi-processor systems this value was a system address in the data structure associated with IOLOCK_8. Solution: On entry to INET_SELECT_BUILD_LIST, initialize R0 to SS$_NORMAL. ECO 14 Updates: -------------- ECO V 3-Apr-1995 Alpha and VAX Images: UCX$BGDRIVER_SEC.EXE UCX V3.2-9V (Alpha) UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9V UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9V UCX$INETACP.EXE UCX V3.2-9V o Problem: System crash at INET_SEL_READ_ALL+14 due to the fact that the temporary space allocated for a SELECT has been deallocated. In the preprocessing of a SELECT operation, a test is made to see if the UCB that serves as the head of the SELECT list is already active. If so, a SS$_DEVACTIVE status is returned and the call is terminated. Unfortunately the temporary space associated with the first SELECT call is also deallocated. When an event occurred, the system crashed due to the absence of the temporary list. Solution: In a failure in preprocessing for SELECT, avoid deallocating the temporary space if the space was NOT allocated explicitly during this call. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 UCX$INETDRIVER.EXE ---------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 26-May-1994 Alpha and VAX Images: UCX$INETDRIVER.EXE UCX 3.1-32A o Problem: INET device units are not deleted on final deassignment. Solution: Do not clear UCB$M_DELETEUCB on device creation. Make the device deletion occur on final deassignment. ECO 4 Updates: -------------- ECO B 12-Sep-1994 Alpha and VAX Images: UCX$INETDRIVER.EXE UCX V3.1-32B o Problem: Multi-processor crashes occur on $CANCEL or $DASSGN in INETDRIVER. The bugcheck is either SPLRELERR or SPLIPLLOW. Solution: Manage the INET device lock and IPL properly in INET_CANCEL. ECO 6 Updates: -------------- ECO C 2-Nov-1994 VAX Images: UCX$INETDRIVER.EXE UCX V3.1-32C o Problem: A CPU crash will occur with the KNRLSTAKNV error code. The crash is due to the occurrence of an IPL 3 (RESCHED) interrupt while the SP is at or near a page boundary and the page at the next lower address range has never been modified (i.e., the M bit is clear in the PTE). The problem arises from the inability of some CPUs to handle an M bit trap while pushing the PC/PSL onto the kernel stack. Solution: Pre-modify the pages of the newly allocated kernel stack. ECO 14 Updates: -------------- ECO D 20-Jun-1995 Images: UCX$INETDRIVER.EXE UCX V3.1-32D o Problem: The system will hang when a process, running in a Kernel AST thread, tries to re-acquire the I/O Database Mutex that it already owns. Solution: In the INET_CANCEL routine which calls EXE$CANCELN, explicitly release the I/O Database Mutex before calling EXE$CANCELN and explicitly re-acquire it after the return from EXE$CANCELN. This is done because EXE$CANCELN lowers IPL to 0, thereby leaving it open to being interrupted by an AST that might try to re-acquire the Mutex. INET_CANCEL routine reorganized. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 UCX$TNDRIVER.EXE ---------------------------------------------------------------------------- ECO 4 Updates: -------------- ECO A 1-August-1994 Images: UCX$TNDRIVER.EXE UCX V3.1-32A o Problem: System still crashes on SMP. Reason: Should hold the IODB mutex when a UCB is deleted from the device list. Solution: Include a trigger timer routine that holds the IODB mutex and does the actual UCB deletion. A timer routine was necessary because the mutex was not granted in the context of tn$free_ucb. ECO B 9-August-1994 o Problem: ECO-A was not built correctly, ECO-B fixes this. Telnet.com uses, the command 'libr/replace lib$:ucx$tn_server.olb obj$:ucx$tn_server_*.obj'. When obj$ is a search list, the .obj in [obj_pat] are replaced first but they get overriden by the .obj in [obj]. ECO 11 Updates: -------------- ECO F 26-Jan-1995 Images: UCX$TNDRIVER.EXE UCX V3.1-32F o Problem: The system will crash with a CPUSPINWAIT due to a corrupted TIMER queue. Solution: Synchronize use of UCB based TQE between TN$CANCEL_TIMER and the various timer routines that are invoked. The UCB$L_TN_TIMER_FLAG field is added and is normally set to zero. In TN$CANCEL_TIMER, if the call to EXE$RMVTIMQ does NOT remove the TQE (because it has already been REMQUEd by the system and its thread is presumably looping, waiting to acquire the spinlock) the UCB$L_TN_TIMER_FLAG is set to -1. Then in the three timer routines, TN$DISCONN_TIMEOUT, TN$FREE_UCB_TIMER, and TN$LOGIN_TIMER, the flag is tested and if it is negative, it is cleared and the call is simply dismissed the call, since it was the intention of the caller of the TN$CANCEL_TIMER to cancel the timer in the first place. ECO 13 Updates: -------------- ECO H 3-Mar-1995 Images: UCX$TNDRIVER.EXE UCX V3.1-32H o Problem: The system will crash with an INVEXCEPTN bugcheck due to a sub-negotiation buffer overrun when receiving data from a XYPLEX Terminal Server. Solution: Initialization of the sub-negotiation buffer incorrectly calculated the end of the buffer. When an illegal sequence of thousands of bytes of data arrived the buffer overran and wrote over a pointer that led to a crash. The solution is to correctly limit the size of the sub-negotiation buffer. ECO 14 Updates: -------------- ECO I 14-Apr-1995 Images: UCX$TNDRIVER.EXE UCX V3.1-32I o Problem: The system will crash with a DOUBLDEALO error due to a TNDRIVER UCB overrun into following ORB. Solution: The UCB$T_TEL_REM_HOST_PORT field is filled in by a MOVC3 instruction whose length operand is picked up from the associated BG UCB without verification. New code has been added to verify that the length is no bigger than the size of the field and to limit to the MOVC3 to this upper bound. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 UCX$TELNET.EXE ---------------------------------------------------------------------------- ECO 5 Updates: -------------- ECO C 3-October-1994 Images: UCX$TELNET.EXE UCX V3.1-32C o Problem: Telneting from MEP-VT via a 3270 connection caused an error of "%NONAME-W-NOMSG, Message number 00000000". Reason: SYS$QIO for setting the outbound AST for the character mask was not synchronous (sys$qiow) and status was ss$_normal, but the IOSB status was still "0". Testing: This was reproduced and the problem disappeared when the fix was applied. In order to setup a 3270 connection, perform the following command and then do a telnet: $SET HOST/SNA ALAS/ACCESS=TSO/APPL=CANTH60/CIRCUIT=SNA-0 LOGIN ... ECO 9 Updates: -------------- ECO D 20-Oct-1994 Alpha and VAX Images: UCX$TELNET.EXE o Problem: The PRINT-SCREEN function on Alpha returns "file not found". Solution: In [TELNET]RMSFILEIO.BLI, a new macro ACTUALPOSITION() was added to replace the existing macro ACTUALNUMBER(), which does not function properly due to a compiler bug. Instead of attempting to create the file, it always attempts to append to it. o Problem: If the server requests a print screen, a loop with the error message "file not found" is entered. Solution: In [TELNET]STESCREEN.B32, clear the PRINTING flag to prevent the STE from continuously attempting to print on an error. The error handler unwinds and continues with the flag left clear, preventing the same error from repetitiously occurring. ECO E 20-Dec-1994 Alpha and VAX Images: UCX$TELNET.EXE UCX V3.1-32E o Problem: When using IBM-3278-4 (IBM[R]) model terminals, TN3270 signals the message "network resource not available". Solution: In [TELNET]TELNET$CLIENT_NET.C, the IO$M_NOWAIT modifier to the write $QIO was removed. This allows TELNET to wait for the transmission of the data instead of returning to command mode with a resource problem. ECO G 1-Feb-1995 Images: UCX$TELNET UCX V3.1-32G o Problems: An unprivileged user gets OPER authorized in a subprocess (SPAWN command). Solution: Modified the spawn routine to take away OPER if it is not authorized. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 UCX$BOOTP.EXE ---------------------------------------------------------------------------- ECO 7 Updates: -------------- ECO B 21-Nov-1994 Alpha and VAX Images: UCX$BOOTP.EXE V3.1-32B o Problem: The bootp server is not providing the optional vendor data for the boot file size (i.e., tag type 13 in RFC1497). It is confusing to expect to find the file size in bootp database, because the server looks up the file size directly. Solution: Remove the check for the file size in the bootp database record, and use the size, if any, from the GetFileSize() routine. o Problem: The bootp server is not providing the optional vendor data for Gateways (i.e., tag type 3 in RFC1497). The arguments are transposed in a memcpy() call. Solution: The typographical error was fixed. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 UCX$TFTP.EXE ---------------------------------------------------------------------------- ECO 4 Updates: -------------- ECO A 01-Sep-1994 Alpha and VAX Images: UCX$TFTP.EXE V3.1-32A o Problem: There were poor error handling and multithreading techniques that caused a timeout/resend to fail. Sending to a non-existent destination port appears to produce a -F-PROTOCOL error. Solution: Changed the file name handling to accept UNIX-style file names. This is done mostly by letting the C RTL handle it. Do not force UCX$TFTP_ROOT:[000000] into the filespec. Have UCX$TFTP_STARTUP.COM 'SET DEFAULT' to there instead, and then just do a stat/open on the raw file name. The logging feature was also added so that when LogOn is enabled, (via the UCX$TFTP_EXTLOG logical) then RRQs and are logged WRQs to the log file as are any errors that are encountered. This provides the ip address and file name for diagnosing problems. Convert from UNIX I/O to Standard I/O (open -> fopen, etc.) to avoid a bug in the VAX C runtime library that causes a write to a file created with fixed record format to fail, and to return an C-F-EBADF during a WRQ of an file with mode=octet. The SYS$SETIMR code was fixed because it never worked correctly. Use meaningful text for wait times and convert to binary during init(). Risks/Impacts: This is a significant re-write of much of the multithreading code and the addition of a new module to the MSG component, TFTP$MESSAGE.MSG. The new module may impact error reporting in other components, while the scope of the changes to the TFTP server requires thorough testing, particularly where fault insertion is concerned. Much of the fault handling code did not previously exist. It also changes the basic file I/O mechanism for both reads and writes. Test Procedure: Load and Dump files, both large and small, text and binary, with multiple simultaneous transfers; both VAX and Alpha, UCX V3.1 only. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 UCX$FTP.EXE, UCX$FTPC.EXE, and UCX$FTPD.EXE ---------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 25-May-1994 Alpha and VAX Images: UCX$FTP.EXE UCX V3.1-32A UCX$FTPC.EXE UCX V3.1-32A UCX$FTPD.EXE UCX V3.1-32A o Problem: An extra reply message could be sent by the FTP server during image mode transfers which caused client and server command synchronization loss. Solution: The offending REPLY message has been removed. o Problem: The FTP MGET fails if the full path name is specified. Solution: Fix the FTP client to properly handle full path names with mget. o Problem: If the path name was specified using FTP GET, it would copy the file and use the full pathname as the file name. Solution: Fix FTP client to use the file name only when copying the file. o Problem: FTP does not retrieve files in a subdirectory when performing an mget of a directory which includes a directory file. Solution: Update FTP to correctly handle subdirectories during an mget. o Problem: FTP get was incorrectly expanding wild card characters. Solution: Fixed get so that wild card expansion is only done if VMSPLUS mode is enabled. Otherwise, wild card expansion will only be done by mget. o Problem: Confusion existed about the get and mget capabilities. Solution: Mget was changed to only perform multiple gets, and get only performs single gets (unless VMSPLUS mode is enabled). ECO 5 Updates: -------------- ECO B 29-Sep-1994 Alpha and VAX Images: UCX$FTP.EXE UCX V3.1-32B UCX$FTPC.EXE UCX V3.1-32B UCX$FTPD.EXE UCX V3.1-32B o Problem: Binary files were truncated during File transfer in image (binary) mode between two FTP nodes if the target filespec contained a nodename of a third node. This was caused by the transfer occurring over DECnet on the target side. This problem was only manifested if the file size was not an exact multiple of 512 bytes. In RMS, Binary files record size is 512 bytes. During RECORD I/O 512 bytes are written per single "write" (i.e., a single record). If a fragment is present, it must be written using BLOCK I/O, which allows an arbitrary number of bytes to be written provided they do not exceed the RMS maximum record size. If a switch is made to Block I/O, while writing a file over DECnet, it does not seem to work (the data gets lost) and no error is reported. Solution: The FTP client and server software was modified so that when writing a file over DECnet, before switching to Block I/O, the rab is "DISCONNECTed" from the file I/O stream, a switch is made to block I/O, and then the rab is "reCONNECTed". o Problem: The FTP command line switches /USER, /PASSWORD, and /INPUT were not being recognized or used properly. Solution: The FTP client was fixed so that it will fully parse the command line. o Problem: The FTP system could not be run from a command procedure. Solution: The FTP client was fixed so that it will recognize BATCH_MODE and read from the redirected SYS$INPUT which now points to the command file. o Problem: The "sendport" command fails. Solution: The FTP client was fixed so that it will correctly disable the sending of the "PORT" command. A default data port was added on which the client "listens". The FTP server was modified so that it will use the default data port when no "PORT" command has been received, to establish a connection back to the client during requests requiring data transfer. o Problem: The PASV command hangs up the session. The FTP client session hangs while waiting for a reply from the FTP server. Solution: The FTP server was modified so that it will correctly send the reply to the PASV command back to the FTP client. o Problem: If the /fdl switch was used while doing a "put" or "get" command, a "Link Disconnect" error message was received. This was caused by an ACCVIO at the server, due to a parsing error at the FTP client, which propagated to the FTP server. Solution: The server code was modified to defend against parsing errors making it more robust. The incorrect parsing was fixed at the FTP client. o Problem: The command ": DIR/FULL" produced truncated output. It did not list all the files currently in the directory. This occurred because the initial count of the number of files in the directory was not set to zero before the listing was started in the server. Solution: Initialize the state variables in the FTP server code to zero before starting the listing. o Problem: The FTP server did not properly report RMS errors back to the client, and did not use the proper reply codes according to the RFC. Solution: Code was added to the FTP server to properly report the RMS error and use the recommended error code from the RFC-959. ADDED or CHANGED Functionality: Description: The command "DIR" had been changed to give an output similar to "ls" instead of a "FULL" listing. Due to recommendations from the end users it has been changed back to its original form to produce a "FULL" listing and instead the command line switch "/BRIEF" has been added thus allowing for the option to produce an output similar to "ls". ECO 7 Updates: -------------- ECO C 3-NOV-1994 Alpha and VAX Images: UCX$FTPC.EXE UCX V3.1-32C UCX$FTPD.EXE UCX V3.1-32C o Problem: Get of "Journaling" attribute during "DIR" (LIST) command processing caused numerous "%BAD_ATTR" OPCOM alarm messages to be produced. Solution: No longer get "ATTR$JOURNALING" attribute during "LIST" command processing by commenting that particular attribute out of the attribute item list in the server code. ECO D 17-Nov-1994 Alpha and VAX Images: UCX$FTPC.EXE UCX V3.1-32D o Problem: Using the 'NODE::' syntax produces errors on get and put. Solution: Do not try checking file access or checking whether the file is a directory over the network. Notes: 1) This means that a file that is a directory can be copied, but it will be garbage on the target end. 2) The error if the access is denied is not a privilege error, it is 'Failed to open file'. ECO E 1-DEC-1994 Alpha and VAX Images: UCX$FTPC.EXE UCX V3.1-32E o Problem: 'Rnfr' and 'retr' did not parse and search multi-directory logicals correctly. Solution: The sys$search and sys$parse logic were fixed. o Problem: 'Check_filetype' did not deassign channels. Solution: Deassign was added to the routine. ECO 8 Updates: -------------- ECO C 6-DEC-1994 Alpha and VAX Images: UCX$FTP.EXE UCX V3.1-32B o Problem: FTP$GET strips disk:[dir] off the local filename. This kept the user from accessing a non-default disk:[dir]. Solution: This code was commented out. ECO D 7-DEC-1994 Alpha and VAX Images: UCX$FTP.EXE UCX V3.1-32D o Problem: Even if no bytes get transferred, the user gets a message telling him that a number of bytes were. Solution: Send_data and recv_data were fixed to keep this from occurring. ECO 9 Updates: -------------- ECO E 27-DEC-1994 Alpha and VAX Images: UCX$FTP.EXE UCX V3.1-32E o Problem: A tape needs 14 bytes minimum on a sys$write. Solution: Recv_bin and recv_normal_bin now pad to 14. ECO F 21-DEC-1994 Alpha and VAX Images: UCX$FTPC.EXE UCX V3.1-32f o Problem: RMS write errors occur on writes of less than 14 bytes. Solution: Appe_vms_plus_bin, appe_normal_bin, recv_normal_bin and recv_vms_plus_bin were all modified to make all tape writes more than 14 bytes. Recv_vms_plus_bin and recv_normal_bin were modified to handle tape requests. ECO 10 Updates: -------------- ECO G 10-Jan-1995 Alpha and VAX Images: UCX$FTPC.EXE UCX V3.1-32G o Problem: A file cannot be put to a location that contains a search-list logical. Solution: A problem was fixed in stor. ECO 12 Updates: -------------- ECO H 18-Jan-1995 Alpha and VAX Images: UCX$FTPC.EXE UCX V3.1-32H o Problem: Channel buildup occurs in multiple 'puts' if the target is a search list. Solution The stor, retr, check_filetype routines were modified to deassign channels after parsing. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 SMTP Mail Facility ---------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 9-Jun-1994 Alpha and VAX Images: UCX$SMTP_MAILSHR.EXE UCX$SMTP_RECEIVER.EXE UCX$SMTP_SYMBIONT.EXE UCX$SMTP_PARSESHR.EXE (VAX only) UCX$SMTP_PARSESHR_TV.EXE (Alpha only) UCX$UUENCODE.EXE UCX$UUDECODE.EXE o Problem: A new symbiont memory leak was found. Solution: It has been fixed. o Problem: The SMTP receiver ACCVIOs with an address in the MAIL From:<> command that includes a source route. For example, <@PSUVM.PSU.EDU:owner-acm-l@KENTVM.KENT.EDU> Solution: It has been fixed. o Problem: The SMTP receiver ACCVIOs with an RFC header that exceeds 1000 characters in length. A long To: header was the only known cause of this problem. Solution: UCX SMTP will handle headers that are too long by truncating them. o Problem: If mail was sent to a UCX system with a quoted local-part (i.e., "NODE::USER"@host.com) and the receiving UCX host's SMTP relay option was not enabled, the mail would be accepted by the UCX SMTP receiver and would be bounced later by the symbiont with an RMS "Record Not Found" error. Solution: The SMTP receiver will now immediately refuse the mail with a 551 failure reply code. For example: 551 <"NODE::USER"@host.com> User not local, Relay disabled. Note: If the sending system in this scenario is also a UCX system, the reply text will be transformed into a generic "no such user" text by UCX on the sending system and the bounced mail text will contain this generic "no such user" text. Changing the UCX SMTP sender (i.e., the symbiont) to differentiate between "no such user" and "user not local" will be addressed in a future version. ECO 2 Updates: -------------- There were no additional changes to this facility in ECO 2. ECO 3 Updates: -------------- ECO B 28-Jul-1994 Alpha and VAX Images: UCX$SMTP_MAILSHR.EXE UCX V3.1-32B UCX$SMTP_RECEIVER.EXE UCX V3.1-32B UCX$SMTP_SYMBIONT.EXE UCX V3.1-32B UCX$SMTP_PARSESHR.EXE (VAX only) UCX V3.1-32B UCX$SMTP_PARSESHR_TV.EXE (Alpha only) UCX V3.1-32B UCX$UUENCODE.EXE UCX V3.1-32B UCX$UUDECODE.EXE UCX V3.1-32B o Problem: The SMTP symbiont redefines SYS$SCRATCH in the system table. Solution: The symbiont will be modified by SYS$SCRATCH only if it is not already defined. If it is not defined, the symbiont process's job table modifies it to point to the postmaster directory. o Problem: If an attempt was made to send a file via SMTP with MAIL/NOEDIT *and* any DECnet address was encountered before an SMTP address, an RMS-F-IOP error would occur at the MAIL> prompt. This would happen most commonly if: - An OpenVMS Mail distribution list was used where any DECnet address preceded an SMTP address; - A user in an OpenVMS distribution list had their mail forwarded via DECnet and an SMTP address followed this user in the list; or - The OpenVMS Mail To: field was a DECnet address and the CC: field was an SMTP address. Solution: This has been fixed. o Problem: If SMTP mail came in for a user who had forwarded their mail to SMTP%... *and* the substitute domain was set, then the substitute domain would be added to the relayed mail From and Return-Path RFC headers. In the case of a relay, this would cause problems. Solution: The SMTP symbiont will now correctly leave the From and Return-Path RFC headers alone if mail is being relayed from SMTP to SMTP. ECO 4 Updates: -------------- ECO C 9-Aug-1994 Alpha and VAX o Problem: If the SMTP configuration database relay option is not set, then all incoming SMTP mail to users who have forwarded their mail is bounced. The purpose of the relay option is to stop someone outside from intentionally routing mail through the system and disabling local users from forwarding their mail. Solution: Make enforcement of the SMTP configuration relay option less restrictive. Users are no longer prevented from making use of MAIL SET FORWARD just because the SMTP relay option is not set. o Problem: UCX SMTP is unable to deliver mail to a recipient (i.e., SMTP address local part) that contains a dot. An example of the type of address that would bounce is: To: J.User@xyz_corp.com ^ | +---<--- This dot causes problems. Solution: UCX SMTP now supports this. To allow delivery of mail where the local recipient has a dot in the name, use the OpenVMS MAIL 'SET FORWARD/USER' command to create an inbound "alias" for the username to which the mail should be delivered. For example: MAIL> SET FORWARD/USER=J.User SMTP%"""whatever@someplace.com""" Note that the forwarding address need not be set to use SMTP. Forwarding may be set to any valid forwarding address. For example, MAIL> SET FORWARD/USER=J.User NODNAM::USERNAME; or MAIL> SET FORWARD/USER=J.User USERNAME o Problem: UCX SMTP creates an entirely new block of RFC headers when it relays mail from a user account which has forwarding set. The headers, as they came into the forwarding UCX system, are then lost inside the plain text of the mail. This behavior is incorrect and it also breaks mail loop detection schemes that count Received By headers (including UCX's mail loop detection scheme). Detailed problem statement: When doing SMTP-to-SMTP forwarding, UCX SMTP would formerly treat the mail it was sending out as an entirely new mail message and build a new block of RFC headers for the "new" mail. UCX SMTP would enclose the RFC headers from the inbound mail message inside the plain text of the outbound mail causing the previous inbound RFC headers, including the Received By header, to be lost. Each subsequent hop handled by a UCX system would cause this encapsulation of inbound headers in a new outbound message. For example: 1. SMTP mail came into a UCX system called host2.edu from joe@host1.edu.; 2. The text of the message was one line - "This is a test..."; and 3. Joe on host2 had forwarded his mail to SMTP%"joe@host3.edu". When host2 relayed the mail to host3 it would transmit the message as: Date: Thu, 4 Aug 1994 07:46:43 -0400 Message-Id: <94080407464265@joe@host2.edu> From: joe@host1.edu To: joe@host3.edu Subject: TEST X-VMS-To: SMTP%"joe@host2.edu" "This is a test..." ================== RFC 822 Headers ================== Return-Path: joe@host1.edu Received: by joe@host2.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:46:32 -0400 Date: Thu, 4 Aug 1994 07:46:19 -0400 Message-Id: <94080406471947@host1.edu> From: joe@host1.edu To: joe@host2.edu Subject: TEST X-VMS-To: SMTP%"joe@host2.edu" The above example shows what was *transmitted* from host2 to host3 in the SMTP dialogue. The transmission starts with the "new" RFC headers that were mistakenly created. Following this is the blank line indicating the beginning of the plain text of the message and after that is the text of the message which includes the "=== RFC Headers ===" line and the original block of RFC headers. It is important to remember that these lines of text are all considered as the text of the mail by the receiving system because they follow the blank line. So, the RFC headers contained in the text of the mail after the blank line are "lost" as RFC headers. Assuming that host3 was also a UCX system the above transmission would display the mail as follows: From: SMTP%"joe@host1.edu" To: joe@host3.edu CC: Subj: TEST "This is a test..." ================== RFC 822 Headers ================== Return-Path: joe@host1.edu Received: by joe@host2.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:46:32 -0400 Date: Thu, 4 Aug 1994 07:46:19 -0400 Message-Id: <94080406471947@host1.edu> From: joe@host1.edu To: joe@host2.edu Subject: TEST X-VMS-To: SMTP%"joe@host2.edu" ================== RFC 822 Headers ================== Return-Path: joe@host1.edu Received: by joe@host3.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:47:50 -0400 Date: Thu, 4 Aug 1994 07:46:43 -0400 Message-Id: <94080407464265@joe@host2.edu> From: joe@host1.edu To: joe@host3.edu Subject: TEST X-VMS-To: SMTP%"joe@host2.edu" This example clearly shows the incorrect encapsulation of the first block of RFC headers within the second block. Since the scheme for loop detection depends on counting the number of Received By headers and since the bug in SMTP-to-SMTP forwarding caused header blocks to be lost, looping mail would loop forever. Solution: UCX SMTP no longer creates a new block of RFC headers when forwarding mail. It uses the old ones after adding a Received By header. Correcting this behavior stops UCX SMTP from breaking loop detection schemes that count Received By headers. Detailed solution statement: UCX SMTP will no longer treat a mail being relayed out as a new mail message. It will not create a new block of RFC headers, encapsulating the original RFC headers in the text of the mail itself but will use the inbound RFC headers as the RFC headers for the outbound mail. It *will* tack on a new Received By header to this block of headers. Given the exact same example as above the new UCX SMTP will transmit the following (from host2 to host3): Received: by joe@host2.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:46:32 -0400 Date: Thu, 4 Aug 1994 07:46:19 -0400 Message-Id: <94080406471947@host1.edu> From: joe@host1.edu To: joe@host2.edu Subject: TEST X-VMS-To: SMTP%"joe@host2.edu" "This is a test..." Note that the headers being sent are the ones from host1 with a Received by tacked on by host2. Assuming that host3 is a UCX SYSTEM with the UCX Configuration Database set up to display headers at the bottom of the mail, the mail will be displayed as: From: SMTP%"joe@host1.edu" To: joe@host3.edu CC: Subj: TEST "This is a test..." ================== RFC 822 Headers ================== Return-Path: joe@host1.edu Received: by joe@host3.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:47:50 -0400 Received: by joe@host2.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:46:32 -0400 Date: Thu, 4 Aug 1994 07:46:19 -0400 Message-Id: <94080406471947@host1.edu> From: joe@host1.edu To: joe@host2.edu Subject: TEST X-VMS-To: SMTP%"joe@host2.edu" How this fixes mail looping detection: If joe on host3 had mistakenly forwarded his mail back to joe@host2.edu, looping situation would occur. Assuming host3 was also running the fixed version of UCX SMTP, the inbound RFC headers would be preserved with yet another Received By header tacked on. Taking the example one step further, host3.edu would transmit this back to host2.edu if joe on host3 mistakenly forwards his mail back to joe@host2.edu: Received: by joe@host3.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:47:50 -0400 Received: by joe@host2.edu (UCX V2.0-23) Thu, 4 Aug 1994 07:46:32 -0400 Date: Thu, 4 Aug 1994 07:46:19 -0400 Message-Id: <94080406471947@host1.edu> From: joe@host1.edu To: joe@host2.edu Subject: TEST X-VMS-To: SMTP%"joe@host2.edu" "This is a test..." At this point host2.edu would receive the mail, tack on a new Received By header and send the mail back to host3.edu continuing the mail loop. Eventually the maximum number of hops (specified in the UCX SMTP configuration database - 16 is the default) would be reached as indicated by the number of Received By headers. When this occurs the system discovering this situation will bounce the mail. Caveat for V3.1: Before UCX V3.2 a mail bounced by UCX SMTP due to exceeding the maximum number of hops (i.e., due to having too many Received By headers) will be bounced with the following failure text: ---- Transcript of session follows ---- %NONAME-E-NOMSG, Message number 030ADB32 UCX V3.2 will have the correct failure text: ---- Transcript of session follows ---- %UCX-E-SMTP_EXCMAXHOP, Maximum number of hops exceeded. Mail loop suspected ECO D 23-Aug-1994 Alpha and VAX Images: UCX$SMTP_MAILSHR.EXE UCX V3.1-32D UCX$SMTP_RECEIVER.EXE UCX V3.1-32D UCX$SMTP_SYMBIONT.EXE UCX V3.1-32D UCX$SMTP_PARSESHR_TV.EXE UCX V3.1-32D UCX$UUENCODE.EXE UCX V3.1-32D UCX$UUDECODE.EXE UCX V3.1-32D o Problem: UCX SMTP would sometimes look inside of a quoted local-part of an address when parsing it. It would mistakenly try to parse the quoted local-part as an RFC 822 address and it could think it found one depending on what was in there. The result was that the address was parsed incorrectly and the mail was bounced. The most common manifestation of this error was when a quoted local part contained a '%' character. The particular bug that uncovered this problem was a PSI address inside a quoted local part. For example, "PSI%abcdef.13911551526::somebody"@someplace.xyz_corp.com The incorrect parsing code picked up the '%' in PSI% and thought it had found a case of user%host@someplace.xyz_corp.com. Solution: UCX SMTP will no longer try to parse the contents of a quoted local part of an address. If the domain part indicates the mail is to be delivered locally, then the quotes will be stripped off the local part and the contents will be passed to OpenVMS mail to parse. ECO 5 Updates: -------------- ECO E 30-Sep-1994 Alpha and VAX Images: UCX$SMTP_MAILSHR.EXE UCX V3.1-32E UCX$SMTP_RECEIVER.EXE UCX V3.1-32E UCX$SMTP_SYMBIONT.EXE UCX V3.1-32E UCX$SMTP_PARSESHR_TV.EXE UCX V3.1-32E UCX$UUENCODE.EXE UCX V3.1-32E UCX$UUDECODE.EXE UCX V3.1-32E o Problem: The UCX SMTP symbiont would ACCVIO if the number of lines of text in the RFC header block was greater than 100 *or* if the number of bytes in the RFC header block was greater than 8192. This can be caused when mailing lists are expanded in the To: RFC header line and not truncated by the sender. Solution: Truncate the excess bytes/lines from RFC header block. Change the maximum number of lines to be 200 before truncation of lines occurs. o Problem: UCX SMTP would sometimes get confused when it encountered an address that contained special characters like '<' or '>' inside of a comment string. This could cause an ACCVIO or could make a mail appear to be from an incorrect address. For example: "" Solution: Fix address parsing code so as not to confuse something inside an address comment that looks like an address for the address itself. o Problem: If mail comes in from a non-SMTP mailer to a user who has forwarded their mail via SMTP on the local system, it would be impossible to reply to the VMSmail From line. If the non-SMTP transport from which the mail comes is DECnet, the From line would be enclosed in double quotes. If the non-SMTP transport was MTS, the From line would be enclosed in double quotes and would contain backslashes preceding the inner double quotes in the address. The old code would produce: From: "SOMNOD::SOMEBODY" rather than From: SOMNOD::SOMEBODY or From: "MRGATE::\"MRGATE::SUMNOD::SENDING_USER\"" rather than From: MRGATE::"MRGATE::SUMNOD::SENDING_USER" Solution: This has been fixed. ECO 7 Updates: -------------- ECO F 17-Nov-1994 Alpha and VAX Images: UCX$SMTP_MAILSHR.EXE UCX V3.1-32F UCX$SMTP_RECEIVER.EXE UCX V3.1-32F UCX$SMTP_SYMBIONT.EXE UCX V3.1-32F UCX$SMTP_PARSESHR_TV.EXE UCX V3.1-32F UCX$UUENCODE.EXE UCX V3.1-32F UCX$UUDECODE.EXE UCX V3.1-32F o Problem: UCX SMTP does not recognize mail to be delivered to the domain specified by the substitute domain as local. This required the workaround of defining an alias in the local host database matching the substitute domain. If UCX host "abc.de.com" has an SMTP substitute domain of "de.com" defined and a mail comes onto host "abc.de.com" addressed to "jones@def.com", this mail would not be recognized as local and would not be delivered locally to user jones unless an alias "de.com" for the host "abc.de.com" was defined in the local host database. Solution: This has been fixed. UCX SMTP will now recognize mail sent to the substitute domain as local. In the event this behavior is not desired, define the system logical UCX$SMTP_NO_SUBS_DOMAIN_INBOUND before starting the SMTP mail queue. o Problem: For inbound mail, UCX SMTP would never put anything into the VMSmail CC line. Solution: For inbound mail, UCX SMTP now sets the VMSmail CC line. (See next problem/solution for more information.) o Problem: For inbound mail, UCX SMTP would unconditionally put the RFC To header into the VMSmail To: line. Solution: For inbound mail, UCX SMTP will now put the X-VMS-To RFC header into the VMSmail To: line for inbound mail if an X-VMS-To RFC header is present. If one is not then the RFC To: header will go into the VMSmail To: line. The same is now true for the VMSmail CC: line. That is, if an X-VMS-Cc RFC header is present it will go into the VMSmail CC: line. Otherwise, any RFC CC header will go into the VMSmail CC: line. If it is not desired to put the X-VMS-... headers in the VMSmail To: and CC: lines, then define the system logical UCX$SMTP_INBOUND_NOXVMS before SMTP execution queue startup. ECO 13 Updates: -------------- ECO G 23-Mar-1995 Alpha and VAX Images: UCX$SMTP_MAILSHR.EXE UCX V3.1-32G UCX$SMTP_RECEIVER.EXE UCX V3.1-32G UCX$SMTP_SYMBIONT.EXE UCX V3.1-32G UCX$SMTP_PARSESHR_TV.EXE UCX V3.1-32G UCX$UUENCODE.EXE UCX V3.1-32G UCX$UUDECODE.EXE UCX V3.1-32G o Problem: VRFY and EXPN do not work. Even though the VRFY command is optional in its implementation, some systems rely on it by doing a VRFY on a user or an EXPN on a list before sending mail to it. Solution: This has been fixed. o Problem: The UCX SMTP receiver cannot handle a multi-line reply to the HELO command. Solution: This has been fixed. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 LPD Facility ---------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 9-Jun-1994 Alpha and VAX Images: UCX$LPD_SHR.EXE UCX V3.1-32A UCX$LPD_SMB.EXE UCX V3.1-32A UCX$LPD_RCV.EXE UCX V3.1-32A UCX$LPQ.EXE UCX V3.1-32A UCX$LPRM.EXE UCX V3.1-32A UCX$LPRSETUP.EXE UCX V3.1-32A UCX$TELNETSYM.EXE UCX V3.1-32A Problem: If the SMTP transport was not present and the LPD symbiont tried to send mail notification, the symbiont (i.e., the UCX$LPD_QUEUE) would stop. Solution: This has been fixed. o Problem: The LPD symbiont used to hang if a job was pending in a stopped LPD queue and the queue was started up. Solution: This has been fixed. o Problem: For outbound print jobs, UCX LPD had no "retry" capability. When the LPD print server did not respond or when the connection went down, the job would become "retained on error" and sometimes the LPD queue would stop itself which required restarting the queue. Solution: If a job failed because of problems with the connection (i.e., if the connection did not come up, if it went down once it was up, or if there is a protocol error), then UCX LPD will now requeue the job to be run again later. The amount of time to wait between retries and the total amount of time that a job can be retried before it is considered to be failed can be assigned by two new system logicals. The UCX$LPD_RETRY_INTERVAL system logical defines the interval LPD waits between retries. This logical serves the same purpose as SMTP's retry interval. The only difference is that there is no differentiation here between an "initial" interval and a "retry" interval. The default retry interval if the logical is not defined is 5 minutes. The UCX$LPD_MAXIMUM_INTERVAL system logical defines the maximum amount of time that LPD will continue to retry a job. This logical serves the same purpose as SMTP's maximum interval. The default maximum interval if no logical is defined is 1 hour. Both these logicals must be defined as OpenVMS Delta times. $! $! To tell UCX LPD to retry every minute: $ DEFINE/SYSTEM UCX$LPD_RETRY_INTERVAL "0 00:01:00.00" Notification of retry attempts/failure: - When a job is retried, an OPCOM message is sent if the LPD service's ERROR log option is set. A broadcast message is also sent to the owner of the job. - When a job has reached its retry maximum and so is not requeued, an OPCOM message is sent if the LPD service's ERROR log option is set. A broadcast message is also sent to the owner of the job. - The broadcast messages to the owner of the job are sent regardless of the setting of the LPD service's ERROR log option. - These messages include the job name, entry number, the username of the submitter of the job and the OpenVMS text of the message. For example: LPD Retrying failed job: MYFILE Number: 58 User: USER Status: %SYSTEM-F-REJECT, connect to network object rejected If UCX LPD fails a job after it has passed its maximum interval, the final disposition of the job will be the same as a job that encounters an error and is not retried. If the LPD queue is set to /RETAIN=ERROR, then the job will be retained on error. Otherwise, the job will be lost. o Problem: There are two ways to indicate a Postscript [R] file. Standard LPD uses the 'o' card and Digital's LPD Printserver Extensions (hereafter referred to as the "PS extensions") uses the 'Dpostscript' card. It was not possible to configure LPD to use the standard LPD procedure rather than the equivalent PS Extensions procedure where functional overlap existed. That is, UCX LPD would always send a Dpostscript card for a "PRINT/PARAM=DATA=POST" and there was no way to tell it to use the 'o' card. This made printing Postscript files to systems that did not implement the PS extensions impossible. Solution: Support use of 'o' card. - Outbound jobs (UCX LPD acting as LPD client): * UCX LPD can be configured to use the 'o' or the Dpostscript cards to identify a Postscript file. This is done with the new "ps" field in the printcap entry and the new UCX$LPD_PS_EXT system logical. Note that the only overlap between the PS Extensions and standard LPD is identification of Postscript files. So, the only effect support for standard vs. PS Extensions has is how UCX LPD denotes a Postscript file. - "ps" field for printcap entries: * The new "ps" field for printcap entries provides a printer specific default for use of the PS Extensions. Like the Ultrix "ps" field, the legal values are "non_PS" and "LPS", "non_PS" says not to use the PS Extensions when sending print jobs to the printer and "LPS" says to use them. The following example indicates that printing to a remote printer bogus_p on the remote system hermes should use the PS Extensions. That is, a PRINT/PARAM=DATA=POST will cause a 'Dpostscript' card to be sent: # LOOP_BOGUS_P|loop_bogus_p:\ :lf=/SYS$SPECIFIC/UCX_LPD/LOOP_BOGUS_P.LOG:\ :lp=LOOP_BOGUS_P:\ :ps=LPS:\ :rm=hermes:\ :rp=bogus_p:\ :sd=/SYS$SPECIFIC/UCX_LPD/LOOP_BOGUS_P: The following example indicates that printing to a remote printer bogus_p on the remote system hermes should *not* use the PS Extensions. That is, a PRINT/PARAM=DATA=POST will cause an 'o' card to be sent: # LOOP_BOGUS_P|loop_bogus_p:\ :lf=/SYS$SPECIFIC/UCX_LPD/LOOP_BOGUS_P.LOG:\ :lp=LOOP_BOGUS_P:\ :ps=non_PS:\ :rm=hermes:\ :rp=bogus_p:\ :sd=/SYS$SPECIFIC/UCX_LPD/LOOP_BOGUS_P: - The legal values for the "ps" field are not case sensitive. - If a queue entry does not have a "ps" field or the value is invalid, then a check is made on the UCX$LPD_PS_EXT logical described below to decide whether or not to use the PS Extensions. * Support for the "ps" field has been added to the UCX$LPRSETUP add function. A "ps" field may be added to an existing printcap entry by editing the UCX LPD printcap file. - The UCX$LPD_PS_EXT system logical provides a system-wide default for the use of the PS Extensions. * This new system logical has the same legal values as the "ps" printcap field. It takes effect where the printcap entry for a printer has no "ps" field. * If this logical is not defined and no "ps" field exists for a printer, then the default is to use PS Extensions. This is to retain compatibility with existing LPD configurations. That is, configurations with no UCX$LPD_PS_EXT logical defined and no "ps" fields in the printcap file will continue to work exactly as they always have. * The legal values for the UCX$LPD_PS_EXT logical are not case sensitive. *Note:* When PS extensions are being turned off (with either a "ps" field of non_PS or with the new UCX$LPD_PS_EXT logical) none of the standard OpenVMS Print_paramters other than /PARAM=DATA=POST will have any effect on printing. This is because these parameters (like /PARAM=SIDES=2) can only be passed with the PS extensions. Standard LPD has no way to specify these parameters. - Inbound jobs (UCX LPD acting as LPD server): * UCX LPD now properly handles Postscript files being denoted as such with the standard LPD 'o' card rather than the 'Dpostscript' card. *Note:* When either a 'Dpostscript' or an 'o' card are used in a control file, all of the files in a multi-file print job will be interpreted as Postscript files. UCX LPD does not support only some of the files in a multi-file job being explicitly handled as Postscript files. This is because an inbound LPD job containing more than one file to print where one of the files is a Postscript file, becomes an OpenVMS multi-file print job with a /PARAMETER=DATA_TYPE=POSTSCRIPT. Since /PARAMETER is not a positional qualifier there is no way to associate the /PARAMETER=DATA_TYPE=POSTSCRIPT with any particular file in the job so it must go with all the files in the job. o Problem: Adding printers to printcap would cause the name of earlier printer entries to bleed over into the names of later ones if the earlier printer name was longer than the later one. Solution: This problem has been fixed. o Problem: When printing to a U*ix system with PRINT/PARAM=PRINTER="printer-name" the case of the printer-name was not being preserved. This required a printer synonym (in all upper case) for each destination printer on the target U*ix system. Solution: This problem has been fixed. o Problem: Doing a STOP/QUEUE/RESET on an LPD queue with a job processing in it would cause the symbiont to exit abnormally. Solution: This problem has been fixed. o Problem: Root always needed a proxy account regardless of whether the application proxy was on or off. Solution: This problem has been fixed. o Problem: For inbound jobs, if the remote host from the 'H' control card was not known, the job would end up retained on error in UCX$LPD_QUEUE with a "record not found" error. This would happen regardless of the setting of the LPD service's application proxy flag. The workaround was to define the host manually in the UCX local host database. Solution: If the remote host from the 'H' control card is not known and the application proxy flag is not set, the job will go through. If the application proxy flag is set, the job will be retained on error with a UCX$_LPDBADHOST error. ECO 4 Updates: -------------- ECO B 15-Sep-1994 Alpha and VAX Images: UCX$TELNETSYM.EXE UCX V3.1-32B o Problem: The Telnet print symbiont would cause Form Feeds to appear at the beginning of each job rather than at the end. This caused problems with special print forms for some applications. Solution: Print the inter-job Form Feed at end of job rather than at the beginning. o Problem: There was no way to suppress inter-job form feeds entirely. Solution: The Telnetsym now provides a way to suppress the inter-job FFs entirely. To do so, define UCX$TELNETSYM_SUPPRESS_FORMFEEDS in the system table before queue startup. For example: $ DEFINE/SYSTEM UCX$TELNETSYM_SUPPRESS_FORMFEEDS 1 $ START/QUEUE telnet_q_name The previous fix shifts the inter-job FFs from the beginning of the job to the end of the job. The definition of this logical suppresses the printing of these FFs entirely. Note that this logical is translated once by the symbiont at queue startup time so that to get different values for different queues you only need redefine it before each queue startup command. For example: $ DEFINE/SYSTEM UCX$TELNETSYM_SUPPRESS_FORMFEEDS 1 $ START/QUEUE telnet_q1_name $ DEASS/SYSTEM UCX$TELNETSYM_SUPPRESS_FORMFEEDS $ START/QUEUE telnet_q2_name $ DEFINE/SYSTEM UCX$TELNETSYM_SUPPRESS_FORMFEEDS 1 $ START/QUEUE telnet_q3_name The sequence above causes inter-job FFs to be suppressed for queues telnet_q1_name and telnet_q3_name but *not* to be suppressed for queue telnet_q2_name. o Problem: There was no way to stop the Telnet print symbiont from acting as a "true" Telnet sender, that is, no way to stop it from doubling IAC characters and from doing a Telnet negotiation of binary mode for printing PASSALL files. Solution: The Telnetsym now provides a way to suppress all "Telnet" type modifications of the print output stream. This is for cases where the remote printer/terminal server does not really implement the Telnet protocol and, instead, expects the raw data stream. To suppress "Telnet" activities define UCX$TELNETSYM_RAW_TCP in the system table before queue startup. For example: $ DEFINE/SYSTEM UCX$TELNETSYM_RAW_TCP 1 $ START/QUEUE telnet_q_name This will cause the Telnet print symbiont not to double IAC characters and not to send the Telnet escape sequence to negotiate binary options for files printed /PASSALL. Note that this logical is translated once by the symbiont at queue startup time so that to get different values for different queues you only need redefine it before each queue startup command. See description of UCX$TELNETSYM_SUPPRESS_FORMFEEDS above for an example of how to do this. ECO 5 Updates: -------------- ECO C 30-Sep-1994 Alpha and VAX Images: UCX$LPD_SHR.EXE UCX V3.1-32C UCX$LPD_SMB.EXE UCX V3.1-32C UCX$LPD_RCV.EXE UCX V3.1-32C UCX$LPQ.EXE UCX V3.1-32C UCX$LPRM.EXE UCX V3.1-32C UCX$LPRSETUP.EXE UCX V3.1-32C UCX$TELNETSYM.EXE UCX V3.1-32C o Problem: When the remote LPD client sent the control file before the data file(s), the job would sometimes end up "retained on error" in the UCX$LPD_QUEUE queue with a "file not found" error. Solution: UCX LPD can now handle the control file coming before or after the datafile(s). o Problem: Outbound UCX LPD jobs sometimes fail with "File locked by another user". Solution: The LPD symbiont now retries jobs that fail this way using the new LPD retry mechanism introduced in LPD ECO A. o Problem: UCX LPD proxy mapping does not find proxies where the /REMOTE_USER has been wildcarded. For example, this proxy would not be found: OpenVMS User_name Type User_ID Group_ID Host_name SOMEUSER CD * someplace.xyz.org ^ | Wildcarded remote | user ------->------->--+ Solution: UCX LPD will now find these proxies. o Problem: There was no way to configure the Telnet symbiont to drop a TCP/IP link immediately at the end of a job. The only way the old Telnet symbiont would drop the link was to detect a period of inactivity on the link in excess of the time period specified by the UCX$TELNETSYM_IDLE_TIMEOUT logical. If this logical was undefined, the default link idle timeout was two minutes. While this method is sufficient for some uses, it is not desirable for environments where many systems contend for access to the same printer. In these environments, it is desirable to have the Telnet symbiont release the TCP/IP link as soon as the job is complete to reduce contention by allowing other systems access to the printer resource. Note that the only way to approximate the behavior of releasing the link immediately on job completion was to define UCX$TELNETSYM_IDLE_TIMEOUT to a very low value - a few seconds perhaps. This had the undesirable side-effect of causing jobs to terminate in the middle of the file as the Telnet symbiont does not distinguish between an idle period occurring in the middle of a job due to a slow network and an idle period occurring after a job has completed because no more jobs are in progress. Solution: Change the default behavior of the Telnet symbiont when the logical UCX$TELNETSYM_IDLE_TIMEOUT is undefined at queue startup to drop the TCP/IP link immediately on job completion. That is, the two minute default for an undefined UCX$TELNETSYM_IDLE_TIMEOUT is no longer in effect. If UCX$TELNETSYM_IDLE_TIMEOUT is undefined, the Telnet symbiont now releases the TCP/IP link immediately on job completion. o Problem: Sharing of the Telnet symbiont log among execution queue threads makes logs difficult to read and makes for contention on the log file between threads. Solution: Make a separate log file for each execution queue thread. File name is UCX$TELNETSYM_qname.LOG where "qname" is the name of the execution queue. The log files will be placed in one of three directories as follows: 1. If UCX$TELNETSYM_SCRATCH is defined, the log file is put in this directory. 2. If UCX$TELNETSYM_SCRATCH is not defined and UCX$LPD_SPOOL is defined, the log file is put in this directory. 3. If both UCX$TELNETSYM_SCRATCH and UCX$LPD_SPOOL are undefined, the log file is put in SYS$SPECIFIC:[SYSEXE]. o Problem: Telnet symbiont diagnostics are insufficient for problem diagnosis at customer sites. Solution: Added a new UCX$TELNETSYM_DEBUG logical to supplement the UCX$TELNETSYM_VERBOSE logical and add new diagnostics to the code. UCX$TELNETSYM_DEBUG is a diagnostic logical whose value tells the Telnet symbiont which of a combination of diagnostic message types to write to the log file. The value of this logical is a bit-mapped integer where each bit set in the value indicates a particular logging function is desired. At present there are three options: o Bit 0 - tracks flow of code (e.g., "such-n-such-routine entered") o Bit 1 - tracks allocation of memory (e.g., "about to call malloc", "just freed address 7F0000" o Bit 2 - logs bytes going over TCP/IP link. To set a bit assign the value to the logical whose binary equivalent would have the bit set. For example, to cause the Telnet symbiont to log each buffer it is writing over the TCP/IP link to the log file so that it can be reviewed, $ DEFINE/SYSTEM UCX$TELNETSYM_DEBUG 4 Decimal 4 is binary 100 which has bit 2 set. Note that different combinations can be achieved by setting more than one bit in the value. A value of 3, for example, will set bits 0 and 1 and so cause logging of flow of code and memory allocation diagnostics. UCX$TELNETSYM_DEBUG is translated at queue startup time by the symbiont. To get different values for different queues simply change the logical's value or deassign it between queue startups. If UCX$TELNETSYM_DEBUG is undefined then the Telnet symbiont logs none of the new diagnostics. At the current time, the only type of diagnostic controlled by UCX$TELNETSYM_DEBUG that may be useful to customers in solving problems themselves is the third type - bit 2 (logging of bytes going over TCP/IP link). The other two options (bits 0 and 1) are for use of Digital engineering staff. The description of how to turn these on is provided here only to ensure that you know how to do so if requested to by Digital in the event that you have a problem with the software. o Problem: There is a problem in the form feed suppression code that is invoked when the logical UCX$TELNETSYM_SUPPRESS_FORMFEEDS is defined at queue startup. The last line of a job would end in only a carriage return character with neither a line feed nor a form feed. The result was overstriking of the last line of the job by the first line of the next job. Solution: If form feed suppression is turned on, make the last line of the job end in not just carriage return. o Problem: If the LPD receiver has a problem opening the LOG file (SYS$SPECIFIC:[UCX_LPD]UCX$LPD_RCV_LOGFILE.LOG) it sends diagnostics to the operator console even if the logical to turn on LPD receiver diagnostics is not defined. (LPD_RCV is the LPD receiver diagnostics logical). Solution: The LPD receiver will no longer write diagnostics if the LPD_RCV logical is not defined. ECO 7 Updates: -------------- ECO D 17-Nov-1994 Alpha Images: UCX$LPD_SHR.EXE UCX V3.1-32D UCX$LPD_SMB.EXE UCX V3.1-32D UCX$LPD_RCV.EXE UCX V3.1-32D UCX$LPQ.EXE UCX V3.1-32D UCX$LPRM.EXE UCX V3.1-32D UCX$LPRSETUP.EXE UCX V3.1-32D UCX$TELNETSYM.EXE UCX V3.1-32D o Problem: The LPD receiver signals a protocol error if it receives the "Print any waiting jobs" command. (This command is indicated by a control byte equal to 1.) Solution: The LPD receiver now ignores this command by acknowledging it and continuing. No protocol error occurs. o Problem: If SYS$SCRATCH is not defined in the system table and an inbound print request with a mail notification request comes in, the UCX$LPD_QUEUE symbiont dies with %MAIL-E-OPENOUT, -RMS-F-DEV errors. A previous fix for SMTP stopped the SMTP symbiont from defining SYS$SCRATCH in the system table. Defining SYS$SCRATCH in the system table was not correct behavior for SMTP; however, it had the positive side-effect of covering up this problem in LPD because SYS$SCRATCH was always defined. Solution: Check for the SYS$SCRATCH logical being defined in the LPD symbiont process. If it is not defined then define it to UCX$LPD_SPOOL in the LPD symbiont process's process logical table. o Problem: An inbound job completion OPCOM message is no longer generated even if the LPD service log option LOGOUT is set. Solution: This problem has been fixed. o Problem: LPD_RCV and LPD_DEBUG diagnostics logicals provide no diagnostics to track what the LPD client sends over the link and what the receiver receives. Solution: The LPD_RCV and LPD_DEBUG diagnostics logicals have been enhanced to provide some information more useful to customers in diagnosing problems. For those customers who have used the old LPD diagnostics by defining the system logicals LPD_RCV and LPD_DEBUG to 65535, the new value to get the same effect is 7. Instead of using the following commands: $ DEFINE/SYSTEM LPD_DEBUG 65535 $ DEFINE/SYSTEM LPD_RCV 65535 Use these instead: $ DEFINE/SYSTEM LPD_DEBUG 7 $ DEFINE/SYSTEM LPD_RCV 7 LPD_DEBUG and LPD_RCV are bit-mapped values. The low order three bits are used (hence a value of 7) to give the effect that used to be produced by all the bits being set (old value of 65535). Additionally, a new diagnostic has been added to LPD_DEBUG and LPD_RCV. If the fourth bit is set (value 8) then the LPD symbiont will log each buffer that it sends over the TCP/IP link to the log file and the LPD receiver will log each buffer that it receives from the TCP/IP link to the log file. This provides a way to see see exactly what LPD is sending (for outbound jobs) and receiving (for inbound jobs) in order to diagnose problems. To turn on only this new diagnostic and no other diagnostics, set the fourth bit of the LPD_DEBUG and LPD_RCV logicals by defining them to 8. To get the old diagnostics along with this new one, define LPD_DEBUG and LPD_RCV to 15. Use of these is only recommended in the diagnosis of problems. Leaving the diagnostics on during normal use will greatly slow the performance of LPD and will produce large log files. Note that the LPD_DEBUG and LPD_RCV logicals are independent. LPD_DEBUG applies to outbound jobs (the LPD client) where LPD_RCV applies to inbound jobs (the LPD server). LPD_DEBUG will cause diagnostics to be written to an LPD queue's log file. LPD_RCV will cause diagnostics to be written to the receiver log file UCX$LPD_RCV_LOGFILE.LOG. ECO 9 Updates: -------------- ECO E 9-Jan-1995 Alpha Images: UCX$LPD_SHR.EXE UCX V3.1-32E UCX$LPD_SMB.EXE UCX V3.1-32E UCX$LPD_RCV.EXE UCX V3.1-32E UCX$LPQ.EXE UCX V3.1-32E UCX$LPRM.EXE UCX V3.1-32E UCX$LPRSETUP.EXE UCX V3.1-32E UCX$TELNETSYM.EXE UCX V3.1-32E o Problem: Outbound PRINT/PASSALL of file with embedded carriage control adds extra line feeds. If PRINT/PASSALL of a non-stream LF file that contains embedded carriage control is done to an outbound LPD queue and the embedded carriage control does not end text lines in a line feed, then an extra line feed is inserted for each line. This problem manifests itself as double spaced printing. The most common cause of this is printing a non-stream LF file from an application that ends its text lines with rather than . Solution: This problem has been fixed. If a problem with /PASSALL printing suddenly appears, the old behavior can be regained by doing the following: $ DEFINE/SYSTEM UCX$LPD_STREAM_PASSALL 1 However, this should not be necessary. If the /PASSALL problem is fixed by performing this definition, please report it to Digital. o Problem: Contention over the shared LPD receiver log file (UCX$LPD_RCV_LOGFILE.LOG) makes problem diagnosis more difficult. Solution: All UCX LPD receiver diagnostics are now written to UCX$LPD_RCV_STARTUP.LOG. UCX$LPD_RCV_LOGFILE.LOG is obsolete. o Problem: The receiver fix in ECO C to handle control file before data files broke handling of multiple LPD jobs per session. If multiple jobs are printed in quick succession from U*ix then some jobs are lost by the LPD receiver. Solution: This problem is fixed. o Problem: UCX LPD does not honor OpenVMS flag page print options. * Outbound LPD jobs (client): The only way to suppress flag pages (banner pages in U*ix terminology) is to print with /PARAM=NOFLAG. Since there is no way to set a queue to a /DEFAULT=/PARAM=NOFLAG, there is no way for OpenVMS applications that submit jobs to print queues with $SNDJBC to control printing of flag pages without changing them to submit with /PARAM=NOFLAG. Also, it would be more intuitive for OpenVMS users and system managers if LPD supported PRINT/[NO]FLAG. * Inbound LPD jobs (server): The presence of an 'L' control card in the incoming control file indicates that a flag page is to be printed. However, when the UCX LPD submits an incoming job to the final destination queue it submits the job neither with /FLAG nor /NOFLAG. Thus, it ignores the presence/absence of the 'L' card and leaves the flag page generation up to the default of the destination queue. Solution: There is a new logical UCX$LPD_VMS_FLAGPAGES which, if defined, tells UCX LPD to honor what OpenVMS tells it to do with flag pages for outbound jobs and to submit inbound jobs explicitly with /FLAG or /NOFLAG based on the presence of the 'L' card in the control file. To get the new behavior add the following to UCX$LPD_STARTUP.COM: $ DEFINE/SYSTEM UCX$LPD_VMS_FLAGPAGES 1 * For outbound jobs: - When the logical is defined /PARAM=NOFLAG has no effect. - If the logical is defined, UCX LPD will honor the /FLAG or /NOFLAG qualifiers from the PRINT command and from the /DEFAULT= and the /SEPARATE= settings on the queue itself. - Though the /[NO]FLAG qualifier is a positional qualifier on the OpenVMS print command, it cannot be used that way since the LPD print protocol provides no way to express that one file in a job should receive a banner page and another one should not. This command works: $ PRINT/FLAG/que=outbound-LPDQ file1.txt, file2.dat ^^^^^ while this does not: $ PRINT/que=outbound-LPDQ file1.txt,file2.dat/FLAG ^^^^^ - For inbound jobs: - If the logical is defined, the UCX LPD symbiont (running in the UCX$LPD_QUEUE queue) submits the inbound job as /FLAG if the control file says to print a banner page (i.e., includes an 'L' card) and it submits the job as /NOFLAG if the control file says no banner page (no 'L' card). - This behavior may cause problems for those depending on the old incorrect behavior of FLAG pages for inbound jobs: - If the destination queue is set up with the default being NOFLAG and a job comes in indicating that a flag page is to be printed, then the job will be submitted with a flag page. This could cause difficulties for a site that depended on the old behavior, for example, printing has been working in UCX LPD without suppressing the flag/banner page. It was working (i.e., a flag page is not printing) because UCX LPD did nothing with respect to flag pages and the destination queue happened to be set up with /DEFAULT=NOFLAG. With the new LPD server, an unwanted flag page will print. The only way to get around this is to force the user to print explicitly with flag page suppression. - For both inbound and outbound jobs: - UCX$LPD_VMS_FLAGPAGES is only translated once at symbiont startup. Different behavior on each queue can be obtained by defining the logical before queue startup if the new behavior is desired. If the old behavior should occur, deassign the logical before start-up for that particular queue. - The corresponding UCX$LPRSETUP has been changed for the addition of a remote printer. - Regardless of whether or not the logical is defined, UCX$LPRSETUP now inquires if the default for the new remote queue should be printing with a flag page. If the response is yes, then the queue is created with /DEFAULT=FLAG. The queue startup text in the UCX$LPD_STARTUP.COM file for the queue also contains the /DEFAULT=FLAG. For sites that do not define the new logical, this behavior will be harmless because the symbiont will ignore the /DEFAULT=FLAG. - If use of this new feature is desired, please edit the queue startup commands in UCX$LPD_STARTUP.COM to have a /DEFAULT=FLAG for each outbound LPD queue that should default to printing flag pages. - The old behavior is preserved if the UCX$LPD_VMS_FLAGPAGES logical is not defined. That is, everything will work exactly as it did before. The only way to suppress flag pages is to PRINT/PARAM=NOFLAG ECO 13 Updates: -------------- ECO F 22-Mar-1995 Alpha Images: UCX$TELNETSYM.EXE UCX V3.2-9F o Problem: The very end of files do not print when the link idle timeout logical (UCX$TELNETSYM_IDLE_TIMEOUT) is not defined. Solution: This problem has been fixed. o Problem: There are various problems associated with bringing down the link immediately at the end of each job (i.e., the link idle timeout logical has not been defined). The workaround for these problems was to define the link idle timeout logical. Solution: These problems have been fixed. o Problem: Telnet symbiont process names default to SYMBIONT_nnn after the first process created. Solution: The first Telnet symbiont process creates itself as UCX$TNSYM1. The second calls itself UCX$TNSYM2, etc. o Problem: OPCOM messages sent by Telnetsym do not specify the remote printer for which they are sending information. This makes it impossible to know which execution may have problems. Solution: OPCOM messages now include name of execution queue. o Problem: If there is an idle link to the printer (i.e., no print job is in process and the idle link timeout is configured for the printer but has not yet expired) and the power on the printer is cycled, the telnet symbiont does not recognize that the link has gone away until the next job is printed. This print job fails with NOIOCHAN. Solution: Because the Telnetsym did not keep an outstanding read on the TCP link to the printer, it could not discover the link was gone until it tried to write to the link when the next print job came in. The Telnetsym now keeps an outstanding read on the link at all times so it detects channel loss immediately. Note that in the case where the printer goes dead (i.e., is powered off and on), this will only be recognized as a dead link by the Telnetsym if you have configured Telnetsym keepalive for that execution queue. To configure Telnetsym keepalive, invoke the following DCL command before starting the queue: $ DEF/SYS UCX$TELNETSYM_KEEPALIVE 1 Further, the timing of when the dead link is recognized as such is set by the drop and probe time on the link. The system defaults can can be used for these (visible using the UCX SHO PROTO TCP/PARAM command) or either or both of these values can be set by defining the logicals UCX$TELNETSYM_DROPTIME and UCX$TELNETSYM_PROBETIME. For example, to set the drop time to 20 seconds and the probe time to 15 seconds execute the following commands: $ DEF/SYS UCX$TELNETSYM_KEEPALIVE 1 $ DEF/SYS UCX$TELNETSYM_DROPTIME 20 $ DEF/SYS UCX$TELNETSYM_PROBETIME 15 before starting the queue. (Remember that the drop time must be greater than the probetime.) o Problem: Telnetsym log files are not automatically purged. Solution: The new Telnetsym logical, UCX$TELNETSYM_LOG_KEEP, sets the maximum number of logs to be maintained. Use the following command to let Telnetsym know that no more than 3 copies of a log file should be kept: $ DEF/SYS UCX$TELNETSYM_LOG_KEEP 3 o Problem: Symbiont crashes can take up to 16 execution queues down. This is especially problematic for production environments. Solution: A new Telnetsym logical, UCX$TELNETSYM_STREAMS, sets the number of execution queues that a Telnetsym symbiont process can serve. The legal value for this logical is between 1 and 16, inclusive. This logical can be used to effectively turn the Telnet symbiont into a single threaded symbiont if it is defined to 1. For example: DEF/SYS UCX$TELNETSYM_STREAMS 1 If the logical is going to be used in this way, it makes the most sense to define the logical once and let the value stand for each queue that is started. If Telnetsym is run as a single-threaded symbiont, then a symbiont crash will only bring down the one execution queue in which the crash occurred. This Telnetsym change is obviously only a workaround. For those familiar with modified print symbionts, the value entered for UCX$TELNETSYM_STREAMS is passed to the PSM$PRINT system routine in the "streams" argument. If this logical is not defined, then the behavior of the Telnetsym remains as it was before. It will run with the OpenVMS maximum of 16 execution queues per symbiont process. o Problem: Telnetsym crashes with PSM-F-BADLOGIC if the following sequence of events occurs: 1. A job is printed to a Telnetsym queue but a link cannot be established to the printer because the printer is not responding. The printer may be busy printing another job, be out of paper, etc. 2. This queue is stopped with a STOP/QUEUE/RESET; and 3. A Telnetsym queue (either another queue or the first one) is started and the remote printer pointed to by the queue that is started is available. Solution: This problem has been fixed. o Problem: Another problem like the previous one existed too. If the same sequence occurred, but a DELETE/ENTRY is done on the job rather than a STOP/QUEUE/RESET on the queue, then the queue would hang. Solution: This problem has been fixed. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 Management Control Program (UCP) ---------------------------------------------------------------------------- ECO 2 Updates: -------------- ECO A 01-JUL-1994 Alpha and VAX Images: UCX$UCP.EXE UCX V3.1-32A o Problem: A server list entered via the UCX SET CONFIG NAME/SERVER command was sorted in order of ascending internet address, causing the bind resolver to use an incorrect ordering. Solution: Do not sort the server list, maintain order as input by the user. o Problem: The UCX CONVERT/ULTRIX BIND command did not allow the creation of a reverse domain. Solution: A pointer to the domain structure which was incorrectly defined has been fixed. o Problem: If the destination parameter to the SET MX command could not be found in a host lookup, then an MX record would not be created and no warning was issued. Solution: The UCXCP$$SET_MX_DEST routine no longer returns an error status if the error resulted from a record_not_found error. All other errors are (and would have been) signaled by the routine. The main routine was exiting with an error prior to creating the MX record, due to the error status returned by UCXCP$$SET_MX_DEST. o Problems: 1. Four items in the communication configuration parameters were being ignored by the START COMM/INIT command. 2. The configuration of communication security lists was not working. 3. SET CONFIGURATION COMMUNICATION/REMOTE=NOVIRTUAL did not work. Solution: An index boundary was fixed and the parsing table for a remote terminal was modified to allow for an "ignore" bit. ECO 8 Updates: -------------- ECO A 16-NOV-1994 Alpha and VAX Images: UCX$ACCESS_SHR.EXE UCX V3.1-32A o Problem: The 'gethostby*' routines did not always deallocate memory correctly. This was most noticeable in the SMTP receiver which would run out of memory and stop running. Solution: The corruption problem in the access_shr routine which was causing the problem has been fixed. Note: This image was actually part of the ECO 7 kit, but it did not get installed correctly. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 RPC and XDR routines ---------------------------------------------------------------------------- ECO 4 Updates: -------------- ECO A 11-Aug-1994 Alpha and VAX Images: UCX$RPCXDR_SHR.EXE o Problem: Several RPC and XDR routines were reported as missing from the RPC shareable image, UCX$RPCXDR_SHR.EXE. The specific routines are: xdrmem_create(), xdrrec_create(), xdrrec_skiprecord(), xdrrec_eof(), xdrrec_endofrecord(), clntudp_bufcreate(), get_myaddr_dest(), xdr_deskey(), _seterr_reply(), _authenticate(), _svcauth_null(), _svcauth_unix(), _svcauth_short(), svcfd_create(), svcudp_bufcreate(), xdr_char(), xdr_u_char(), xdr_vector(), xdr_pointer(), clnt_create(), and xdrstdio_create(). Solution: For the most part, the routines were present in the shareable image, but there was no external access to the procedures. For Alpha, the symbol vectors were missing. For VAX, the transfer vectors were missing. ECO B 02-Sep-1994 Alpha and VAX Images: UCX$PORTMAPPER.EXE UCX$RPCXDR_SHR.EXE o Problem: The portmapper logged a message "UNSET_VMS: Unregister ..." when a service successfully registered a port. Another message read "PID-based registration cannot supersede by PID xxxxxxxx", but meant "PID-based registration cannot supersede PID xxxxxxxx". All of the messages that displayed program numbers showed hex only, making it hard to correlate with program numbers specified in RFCs. Solution: The strings have been corrected. o Problem: CLNT_CALL() randomly returns RPC_TIMEDOUT without an explanation with TCP transport handles on Alpha. Solution: Recode the htonx() routines to properly return sign-extended quads on Alpha. This change permits the C compiler's incorrectly optimized quadword comparison algorithm to succeed. ECO 6 Updates: -------------- ECO C 25-Oct-1994 Alpha and VAX Images: UCX$RPCXDR_SHR.EXE o Problem: Improper pointers caused the XDR object pointer to increment in fours, instead of in elsize units in xdr_vector(). Solution: Make eladdr the pointer instead of a pointer-to-pointer like addrp. ECO 7 Updates: -------------- ECO D 22-NOV-1994 Alpha and VAX Images: UCX$RPCXDR_SHR.EXE o Problem: The XDR_VECTOR() addrp argument is an incorrect type. Solution: The definition and usage of the addrp argument have been corrected. ECO 9 Updates: -------------- ECO E 21-DEC-1994 Alpha and VAX Images: UCX$RPCXDR_SHR.EXE ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 RSH ---------------------------------------------------------------------------- ECO 4 Updates: -------------- ECO A 07-Jun-1994 Alpha and VAX Images: UCX$RSH.EXE o Problem: Quotation characters are unconditionally removed from the RSH command line. Solution: A parser which is sensitive to pairs of quotation characters and which does the appropriate change casing was implemented. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 PWIP Driver and ACP ---------------------------------------------------------------------------- ECO 2 Updates: -------------- ECO A 01-Jul-1994 Alpha and VAX Images: UCX$PWIPACP.EXE UCX V3.1-32A UCX$PWIPDRIVER.EXE UCX V3.1-32A UCX$PWIPSHUT.EXE UCX V3.1-32A o Problem/Solution: ACCVIOs (2) that occurred during PWIP shutdown were fixed. The first was caused by a null ucxucb pdcb field and the second was caused by a null pdcb pointer passed in a call to dwn_call_down. Both of these are valid situations. Changed the code to check for valid addresses before processing. Logic was added to explicitly count SS$_SUSPENDED status returns on read (receive) and to explicitly count SS$_SUSPENDED status returns on write (transmit). Check_pwip_disconnect status processing logic was changed. The forced system crash was removed and various transmit/received status counters were added. The logic has been changed so all status processing (except normal client disconnect (SS$_LINKDISCON)) is based upon current socket state. The transmit logic was changed to insure that the proper flag bit (FL$M_AST_WAIT) is set upon UCX transmit suspended (SS$_SUSPENDED). Before this fix, the PWIP driver would attempt to transmit even though it had received an SS$_SUSPENDED status from UCX. ECO 3 Updates: -------------- ECO B 18-Jul-1994 Alpha and VAX Images: UCX$PWIPACP.EXE UCX V3.1-32B UCX$PWIPDRIVER.EXE UCX V3.1-32B UCX$PWIPSHUT.EXE UCX V3.1-32B o Problem/Solution: - The PWIP ACP log was misnamed. The PWIP ACP log file name has been changed from PWIPACP_nodename.LOG to UCX$PWIPACP_nodename.LOG to be more consistent with UCX file naming conventions. - PWIP ACP log file records are lost when the system crashes. The PWIP ACP file logic was changed so that records are flushed to disk after every write. - The PWIP ACP log file on an Alpha system, cannot be read while the ACP is active. The PWIP ACP file logic has been changed so that the log is opened "shr=get". - Crash dump analysis has been enhanced. Logic was added to zero PDCBs upon allocation and to zero PDCB flinks and blinks upon their removal from queues. Additional counters were added to the UCX$SDA (SDA backend) routine displays. - ACCVIO processing of the PCB during Build_CONN_ID has also been enhanced. Build_CONN_IND has been modified to verify that the UCX version of the socket is still known and that, within that socket, the address of the PCB exists before further processing is done. It is possible that between the time that the inbound connect request is queued, requeued and processed, UCX has transitioned the socket to a flavor of closing and in the process deallocated the PCB and possibly even the socket. - Work queue analysis has been enhanced. A DEBUG check of PDCB has been added for work queue status on a close_dev. If the PDCB flink or blink is non-NULL, the system will crash. - Erroneous ACP and driver state machine operations lead to incorrect routine calls, improper BG device interaction, UCX interaction failures, a deallocation race condition leading to intermitent ACCVIOs and other painful errors. If the request primitive and current cb_w_state are a mismatch (i.e., stateOk fails) for a dwn_call_down invocation, insure that the cb_w_tpRequest is not set to -1. Setting this value as it has been in the past can lead to improper processing. The cb_w_tpRequest field should only be set to -1 if stateOk returns success. - Data is unavailable on a return from a UNITDATA request which leads to Pathworks client failure. The SRC_length and SRC_offset fields of the UNITDATA structure are now set up properly during pwip_alloc_udata_ind routine execution. ECO 4 Updates: -------------- ECO C 05-Aug-1994 Alpha and VAX Images: UCX$PWIPACP.EXE UCX V3.1-32C UCX$PWIPDRIVER.EXE UCX V3.1-32C UCX$PWIPSHUT.EXE UCX V3.1-32C UCX$SDA.EXE UCX V3.1-32C o Problems and solutions: - The PWIPdriver shutdown procedure did not work correctly. It could leave the driver in an undefined state leading to ACCVIOs, transport user bugchecks and/or an inability to restart. The following work was done to remedy this: * The longword field, cb_l_cloned, was added to the PDCB structure. For cloned PDCBs, this field is set to TRUE (1), and for non-cloned PDCBs it is set to FALSE (0). This is used during shutdown processing to prevent duplicate T_DISCON_INDs, T_UNBIND_INDs, etc. * A routine to stop the repeating PWIP timer (stop_timer) was created and the necessary BLISS definitions for access to the privileged system routine EXE$RMVTIMQ were added. * If the driver is already active during acp_init execution, return to the ACP in error (SS$_DEVACTIVE). * Two new PWIP driver states have been added: PWIP_SHUTDOWN_ONGOING and PWIP_SHUTDOWN_COMPLETE. They are used during shutdown processing to insure that the ACP and driver are shutdown in a controlled and correct manner. * Code was added to insure that close device processing could only take place while the driver was either active or processing a shutdown request. * Code was added to insure that non-shutdown-related fork thread processing would equate to a NOP once shutdown processing started. * The routine forkShutdownMsgToUser was added for forking messages up to the transport user during shutdown processing. + At shutdown: o Mark the driver as shutdown ongoing. o Stop the repeating PWIP timer. o Clean up the driver work queue. o Clean up the ACP work queue. o For each PDCB, clear the channel, forkcnt and ackcnt fields and empty the write queue to insure that the state of the driver is properly frozen. o Send all UDP sessions and all TCP listener sessions a T_UNBIND_IND message. They will call back with a close device. For TCP listeners, insure that the CICB is cleaned up. o Send all active non-listener TCP sessions a T_DISCON_IND message. They will call back with a T_UNBIND_REQ. A T_OK_ACK will be returned and they will respond with a close device. o For all other TCP sessions, determine the current state and respond appropriately (e.g., an error ack, an ok ack, etc.) and continue processing in a non-destructive manner until the session is closed. o Once all the PDCB processing/interface protocol has successfully completed, mark the driver as shutdown. - The Alpha version of PWIPdriver corrupted the high order word of a longword field in the pdcb containing the channel number (normally a word field) when passing information between the ACP and the driver. The following work was done to remedy this: * Cleaned up the interaction between channel values (which are of length word) and certain storage locations (which are of length longword; e.g., the cb_l_channel pdcb field). That is, the channel argument in all CMKRNL argument lists was increased from word to longword and proper casting was implemented for various word, longword interactions. - Upgraded some of the UCX PWIP SDA backend displays. The following work was done to remedy this: * Added display of the cb_l_cloned PDCB field. * Added display of the CICB queue headers. ECO D 22-Aug-1994 Alpha and VAX Images: UCX$PWIPACP.EXE UCX V3.1-32D UCX$PWIPDRIVER.EXE UCX V3.1-32D UCX$PWIPSHUT.EXE UCX V3.1-32D UCX$SDA.EXE UCX V3.1-32D o Problems and solutions: - The SyncState macro was added to insure that the interface state is synchronized between the transport user and the transport provider before shutdown processing begins for each TCP non-listener connection. There was a remote possibility that PWIP would respond inappropriately at shutdown causing the transport user to crash the system. - The disconReq_ast routine in module PWIPacp_Ucx.C was fixed so that it now correctly passes the status to the driver when an error occurs. - The pwip_check_disconnect routine in module PWIPdriver_Supp.C was modified so that it no longer handles special case errors. It now only sends up a T_DISCON_IND. The resulting UNBIND (sys$dassgn...) will cause UCX to clean up properly. This closes an out-of-state window incurred while processing the internal disconnect request generated by the old logic. - The Build_CONN_IND routine in PWIPDRIVER_ACK.C was fixed. Open comment characters had been introduced into the code without matching close comment characters leading to non-compilation of several lines of code. System crashes were occurring under certain circumstances which were apparently related to the un-compiled code. - Additional conditionally compiled debug statements were added to various routines to facilitate debugging. - The build procedure was upgraded: * OpenVMS platform/version specific system-wide build locations for the Pathworks-provided PWIP SDK files have been created and populated: > Build1$:[Plat_v.Vms_v55.PWIPSDK] > Build1$:[Plat_a.Vms_v15.PWIPSDK] > Build1$:[Plat_a.Vms_v61.PWIPSDK] * The PWIP.COM build procedure was changed to access the proper PWIP SDK files, allow for ECO builds, access the standard system files, no longer create dummy Alpha files since they are no longer needed, etc. * The VAX portion of the Bliss DriverDef file was modified to include certain missing macros thus making it possible to remove the need to access a LIB.L32 file of unknown lineage kept in an internal account and replace the VMS$RESD$ references with SYS$LIBRARY. * The Macro2Hfile.COM procedure was upgraded to properly deal with Macro-32 .IF directives, thus removing the need to redefine certain symbols in other .H files. * Various .H files were changed to accurately redefine certain symbols thus avoiding DECC redefinition warnings at compile time and the resultant Library and Linker warnings. - Some of the UCX PWIP SDA backend displays were upgraded to remove the display of stdCloseCnt and nonstdCloseCnt since they no longer exist. ECO E 16-Sep-1994 Alpha and VAX Images: UCX$PWIPACP.EXE UCX V3.1-32E UCX$PWIPDRIVER.EXE UCX V3.1-32E UCX$PWIPSHUT.EXE UCX V3.1-32E UCX$SDA.EXE UCX V3.1-32E o Problems, solutions and/or enhancements: - On rare occasions, when PWIP Mbuf resource or session limits are exceeded and the transport user decides to abruptly terminate multiple sessions, the PWIPdriver work queue may be corrupted which leads to an ACCVIO and system crash. The code now checks to insure that sessions queued to the driver work queue are properly removed before termination processing proceeds. - PWIPdriver startup and shutdown messages are now posted to OPCOM. - PWIPdriver now dynamically recalculates Mbuf resource/session limits whenever such are exceeded, removing the need to reboot the system in order to pick up UCX large buffer maximum changes. - PWIPdriver now writes a message to OPCOM whenever Mbuf resource/session limits are depleted and/or replenished. ECO 6 Updates: -------------- ECO F 31-Oct-1994 Alpha and VAX Images: UCX$PWIPDRIVER.EXE UCX V3.1-32F o Problems, solutions and/or enhancements: - On rare occasions, Pathworks sends down a mis-typed mblk/dblk/buffer set for transmit. The data in this set is correct, but the type field is not. It should be type M_DATA, but is type M_PROTO. PWIPdriver did not properly deal with this circumstance. It went into a state that effectively blocked all further transmissions on the connection in question. This is a Pathworks inspired problem, and the Pathworks Engineering Group will be providing a fix. They have requested that the type checking for all properly identified transmission sets (which this is) be relaxed, and an assumption made that the type is M_DATA. This ECO allows that assumption to be made. ECO G 08-Nov-1994 Alpha and VAX Images: UCX$PWIPACP.EXE UCX V3.1-32G UCX$PWIPDRIVER.EXE UCX V3.1-32G UCX$SDA.EXE UCX V3.1-32G o Problems, solutions and/or enhancements: - Erroneous backlog enforcement at the PWIP driver level led to unnecessary incoming connect rejection. Backlog is a TCP/IP concept and is already enforced within the UCX kernel. PWIP specific backlog code was removed. - Numerous additional conditionally compiled debug statements were added: * Dump of transmit and receive message contents * The debug history buffer was increased to 10000 records. * Various debug statements were added and modified to facilitate debugging - ResourceWaitsCnt and BlockedXmtsCnt counters were added. - There was a window wherein a disconnect request could intervene between a connect request and a connect confirm which lead to erroneous and conflicting connect confirm processing. Code was added to insure that this case is properly identified and handled. - For connect reject processing, the appropriate interface state was being overwritten with an inappropriate state in routine d_discon_req module PWIPDRIVER_DOWN.C. This lead to inappropriate processing later. The code was changed to insure the proper interface state. - When PWIPdriver was called by UCX to notify it that a connection was no longer suspended, PWIPdriver cleared its FL$M_AST_WAIT bit for the connection in question and then forked a procedure to deal with the queued transmit requests. Timeliness of fork routine processing is not guaranteed. It is possible, especially on SMP machines, for the transport user to call down to PWIP with additional transmit requests before the fork routine is processed. This leads to messages being transmitted out of sequence. This is particularly onerous for TCP connections, as the guaranteed in-order delivery of messages is circumvented. The code was changed to clear the FL$M_AST_WAIT bit in the fork routine, thus closing this out-of-order transmit window. - A window existed wherein connections queued to the PWIPdriver work queue could erroneously be re-queued to the ACP work queue thus corrupting the PWIPdriver work queue. This scenario could only occur when the driver was laboring under Mbuf exhaustion. This is a rare occurrence. The code was changed to defer the queuing of connections to the ACP work queue if the connection is already queued to the PWIPdriver work queue. When the connection in question is dequeued from the PWIPdriver work queue, it is then queued to the ACP work queue for processing. - PWIPdriver uses the UCB$L_TEL_UCB UCB field to store the address of its associated control block (pdcb). There is currently no SDL file describing the UCX UCB extension, so PWIP defines its own C representation of the UCX UCB extension. For OpenVMS VAX and OpenVMS Alpha V6.1, this C representation was incorrect. This does not appear to have led to any problems. The include file (PWIPDRIVER_UCX.H) that describes the UCX UCB extension was reworked so that it will accurately reflect the UCX UCB extension for all supported OpenVMS versions. - The Mbuf transmit throttle algorithm was modified to be more forgiving. The "fudge factor" is now "max((activeSock/8),10)", instead of "max((activeSock/2),10)". - The UCX SDA backend was upgraded to support additional counters, etc. - Zero length transmissions are now supported as called for in the supporting specifications. - Naked M_DATA transmissions on TCP connections are now supported as called for in the supporting specifications. - Check to insure that UCX is running before allowing PWIP to start. If UCX is not running, abort the PWIP ACP startup. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 SNMP_ AGENT ---------------------------------------------------------------------------- ECO 4 Updates: -------------- ECO A 25-Aug-1994 Alpha and VAX Images: UCX$SNMP_AGENT.EXE UCX V3.1-32A o Problem: ACCVIOs occur when a getnext function traverses the Address Translation table (AT). They may also occur when debug is enabled and an OID is printed Solution: The calling sequence to getnext_special_req now passes pointers instead of the address of pointers (*object_class, not object_class). The correct pointer is now passed to moss_oid_to_text(). o Problem: The SNMP Agent reports an IPIOCTLERR - failure to read IP information due to invalid buffer length. Solution: The original code allows for up to 100 routes to be retrieved in a QIO. On systems using dynamic routing, more than 100 routes may exist. The size of this buffer was increased to handle up to 1000 routes, and the buffer is set to zero before the QIO call. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 NFS Server ---------------------------------------------------------------------------- ECO 4 Updates: -------------- ECO A 31-May-1994 Alpha and VAX Images: UCX$SERVER_NFS.EXE UCX V3.1-32A o Problem: Hostname is being handled improperly in the authentication portion of the NFS request. The result is either a crash (of the NFS server) or a loop, depending upon the request which is being made. Solution: The code which handles the null hostname string improperly has been corrected. Clients sending null hostnames will now have their hostnames looked up from the receiving side. o Problem: The NFS server improperly handles the UID and GID in the NFS request under certain circumstances. While the UID and GID values are cleaned up when they are copied from the request buffer into their work cells, there are several checks which are performed using the raw value in the request buffer. This leads to privilege violation errors which should not be generated. Solution: Clean up the UID and GID in the raw NFS request buffer before processing them. This makes all UID and GID processing consistent. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 CFS_SHR.EXE images ---------------------------------------------------------------------------- ECO 5 Updates: -------------- ECO A 20-Jul-1994 Alpha and VAX Images: UCX$CFS_SHR.EXE UCX V3.1-32A o Problem: Large files appeared to have corruption at the end. Solution: The file's size on format conversion was being altered. The resulting UNIX size which was incorrect was being used as the file's absolute size. o Problem: SS$_INVACL was being encountered when processing attributes. Solution: The CHP$_ACL item from the call to $CHKPRO was removed. o Problem: File deletion required the name to end in ".". Solution: A previous fix which was in error was corrected. o Problem: Purge code did not work properly; error in RVN determination was discovered. Solution: The algorithm has been fixed. The call to the purge code has been alerted to the presence of the FIB$V_LOWVER (lower version present) bit on output to any CREATE/ENTER. The RVN determination was changed from 8 to 16 bits. o Problem: A crash can occur if the client changes the directory cookie to a value between 2 and 65535. Solution: Advance the cookie to 1,0 if the value is greater than 0,1. Values from 0,2 through 0,65535 are reserved. o Problem: Directory ACLs are not propagated as expected. Solution: Set FIB$V_DIRACL when creating a directory. o Problem: Internal BFS event monitoring code fails to send a thread exit event. Solution: Clear the status after calling MONITOR so that the proper event is logged. o Problem: VFC print files are not processed properly. Solution: The ordering of the VFC PRINTCC character handling has been changed. The original implementation worked correctly but was erroneously reversed. It has been changed back and now processes correctly. o Problem: The SVTX (``sticky'') bit in a directory's protection mask indicates that the contents can only be deleted by the owner or root. This was being ignored. Solution: The code was modified to behave appropriately. ECO B 02-Sep-1994 Alpha and VAX Images: UCX$CFS_SHR.EXE UCX V3.1-32B o Problem: - The following problems exist in the CFS bitmap management routines: * System hangs caused by problems in the Alpha LIB$FFC and LIB$FFS library routines. The NFS process would hang in EXEC mode in RMS rundown at AST state. This would prevent RMS from properly running down, making the problem look like one with RMS. * Errors in bitmap management were found when the code was reviewed during the search for another problem. * File system crashes may occur during the crossing of bitmap boundaries. The logic was causing bits off the end of one bitmap to be manipulated when they should have been manipulated in the NEXT bitmap. This problem also caused corruption if a buffer or data structure happened to be located after a bitmap buffer in the virtual address space. * The bitmap initialization failed to mark the buffer as modified, causing the cache to discard it. The last known content of the bitmap area were a series of 128 deleted cells. This was the CGIO error. Solution: Make an additional check before attempting to update bits in the existing bitmap cell group on container extension. The previous code (while checking to see if the first_nc and last_nc [first and last new cell number] were in the same cell group) failed to also check if the new cells are represented in the existing bitmap or the new bitmap. As a result, an attempt to manage bits past the end of the existing bitmap would cause either an access violation (possibly manifested in a hang), or environment or container file corruption. When scanning the bitmap in BM_FFC and BM_FFS, be sure to stop the scan at the highest valid bit, instead of allowing it to go to bit 32. Change the FFC and FFS to use built-ins for VAX and a local routine for Alpha. There is a problem in the Alpha LIB$FFx routines which results in an access violation when the bitstring is at the end of a buffer. o Problem: PC clients (several implementations) specify size zero on directory creation. This produces invalid directories on the server. No files or subdirectories can be created in it. Solution: The code that sets the file size was removed from the directory creation code path. o Problem: If ADD EXPORT was done with /OPTIONS=PURGE_VERSIONS, the presence of a file with null name and extension (i.e., .;1) makes the rest of the files in the directory invisible to the ls command. Solution: An additional check for file name length of 1 was added to the decision for stripping the version number from the file name. This prevents confusion from special casing the .;1 file and not stripping the version even though there are not multiple versions. ECO 6 Updates: -------------- ECO C 02-Nov-1994 Alpha Images: UCX$CFS_SHR.EXE UCX V3.1-32C o Problem: If a file containing any form of variable length records is accessed with format conversion enabled, a message of the type "thread exits while holding resources" is written to _OPA0:. Subsequently, the content of the file is not converted and the server may eventually enter a hang or loop condition when an attempt to close the file is made. The problem lies in the file system OPEN and READ services. If a variable length record's length shortword is on an 8KB boundary in the file, the conversion scanning code will exit with an access violation. The locked buffer will remain locked and the message is generated. The problem is that the thread exit code does not properly clean up the lock's context, causing it to remain in a locked state. When an attempt to close the file is made, the locked buffer will cause the server to enter an AST loop. If an attempt to flush the buffer from the cache (via the LRU mechanism) is made, the server can enter a hang condition. Solutions: - Correct the code which cleans up the locked resource. This removes the hang and looping problems. - Correct the code in the OPEN and READ services. This removes the corruption and the console message problems. ECO 9 Updates: -------------- ECO D 16-Dec-1994 Alpha and VAX Images: UCX$CFS_SHR.EXE UCX V3.1-32D o Problem: The file system would crash if the final record of a file crossed the EOF mark. Such a file is (technically) invalid, and RMS-32 would ignore the record. A typical way to recreate this problem would be to SET FILE/END_OF_FILE when the EOF references the middle of a disk block. Note that this (in effect) corrupts the data at the end of the file and may result in unexpected results when reading from or appending to the file. Solution: When scanning the file at access time, stop building the RMAP structure when a record crosses EOF. In addition, do not include the record in the converted size of the file. ECO 11 Updates: -------------- UCX$CFS_SHR.EXE ECO D was removed from the kit. UCX$CFS_SHR.EXE ECO C was included in the kit. ECO 12 Updates: -------------- ECO E 20-Feb-1995 Alpha and VAX Images: UCX$CFS_SHR.EXE o Problem: When building the RMAP, the data buffer descriptor remains in a locked state (with PENDCNT > 0), causing a loop when an attempt to close the file is made. Solution: The lack of a pair of parenthesis resulted in the complementing of the address of the status variable. This caused a premature exit from the BUILD_RMAP, leaving the descriptor with a non-zero pend count. ECO F 01-Mar-1995 Alpha and VAX Images: UCX$CFS_SHR.EXE UCX V3.1-32F o Problem: When `REAL_SIZE' determination is enabled in the UCX$CFS_SHR via logical UCX$CFS_MODUS_OPERANDI mask 512, writes to certain files result in corruption. Solution: An access check in the BFS$OPEN_FH() was in error. Its purpose was to reaccess files for write after they have been accessed for read. When the REAL_SIZE is enabled, a request to read access a file after it is accessed for write should result in a NOP, but instead would reaccess the file in read-only mode. The subsequent write operations would internally result in the error SS$_NOPRIV, which the user did not see. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 PCNFSD ---------------------------------------------------------------------------- ECO 9 Updates: -------------- ECO A 8-Dec-1994 Alpha and VAX Images: UCX$PCNFSD.EXE UCX V3.1-32A o Problem: If the PC client sent a fully qualified host name in its RPC request to print, the PCNFSD constructed a spool subdirectory name in the form of [SPOOLDIR.host.domain1/domain2]. It then failed attempting to create the subdirectory. Solution: If the client sends a fully qualified host name on print_start, throw away the domain name before constructing the name of the spool subdirectory. o Problem: On renaming the print file into the spool subdirectory, if a file by the same name is already queued up for printing, PCNFSD attempts to avoid name collision by appending some random digits during the rename into the spool subdirectory. It was getting confused and appending the digits to the host level spool directory instead of the file name. Solution: The code appending the random number was moved. ---------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.1 DNFC Driver ---------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 26-May-1994 Alpha and VAX Images: UCX$DNFCDRIVER.EXE UCX V3.1-32A o Problem: The UCX$DNFCDriver would not load on Alpha systems. Solution: Insure that the driver image no longer contained demand zero pages by verifying that all data is clustered together. o Problem: The client would hang for no reason in very rare cases. Solution: Review the retransmission code, making appropriate changes to consider rescheduling which could interrupt the flow of control. o Problem: Empty ACLs are reported with SS$_NORMAL instead of the expected SS$_ACLEMPTY return. Solution: Change the return of the FIB$L_ACL_STATUS to SS$_ACLEMPTY instead of SS$_NORMAL. o Problem: A privilege violation is returned by the SET FILE /ENTER command. Solution: Correct a problem in the determination of the file name string length in the NFS protocol. o Problem: The MOUNT /BUFFER=(READ=x, WRITE=y) qualifier is being ignored. Solution: Enforce the values set by the qualifier. INSTALLATION NOTES: In order for the corrections in this kit to take effect, the system must be rebooted. If the system is a member of a VMScluster, the entire cluster must be rebooted. REFERENCES: Postscript is a registered trademark of Adobe Systems Incorporated. UNIX is a registered trademark licensed exclusively by X/Open Company Ltd. Macintosh is a registered trademark of Apple Computer, Inc. IBM is a registered trademark of International Business Machines Corporation.

This patch can be found at any of these sites:

Files on this server are as follows:

ucxeco14-031.README
ucxeco14-031.CHKSUM
ucxeco14-031.CVRLET_TXT
ucxeco14-031.a-dcx_axpexe
ucxeco14-031.a-dcx_vaxexe