DEC TCP/IP UCXECO8-032 TCP/IP V3.2 for OPENVMS VAX/Alpha 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. *DEC TCP/IP] UCXECO8-032 TCP/IP V3.2 for OPENVMS VAX/Alpha ECO Summary Copyright (c) Digital Equipment Corporation 1995. All rights reserved. PRODUCT: DEC TCP/IP Services V3.2 for OpenVMS VAX DEC TCP/IP Services V3.2 for OpenVMS Alpha OP/SYS: OpenVMS VAX OpenVMS Alpha SOURCE: Digital Equipment Corporation ECO INFORMATION: ECO Kit Name: UCXECO8-032 ECO Kits Superseded by This ECO Kit: UCXECO7-032 ECO Kit Approximate Size: 42,606 Blocks Kit Applies To: OpenVMS VAX V5.5-2, V6.0, V6.1 OpenVMS Alpha V1.5, V6.1 System/Cluster Reboot Necessary: Yes ECO KIT SUMMARY: An ECO kit exists for DEC TCP/IP Services V3.2 on OpenVMS VAX V5.5 through V6.1 and OpenVMS Alpha V1.5 through V6.1. This kit addresses the following problems. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 Kernel images --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 29-Nov-1994 AXP and VAX Images: UCX$BGDRIVER.EXE UCX V3.2-9A (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9A UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9A UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9A UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9A o Problems: 1. A system crash may occur in the INET_SOACCEPT when it refers to the socket structure pointed to by the Listener UCB. 2. A system crash due to corrupted pool may occur if the when the 'UCX SHOW COMM/MEM' command is used. Solutions: 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. Code has been added to look 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). The 80 hex is a negative integer and, as a result, the size of an allocated pool buffer was calculated incorrectly which caused it to use more space than it had allocated. ECO B 4-Jan-1995 AXP and VAX Images: UCX$BGDriver.EXE UCX V3.2-9B (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9B UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9B UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9B UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9B o Problem: When two processes (such as a parent and a child) share a socket, only the actual creator is allowed to perform IO$_DEACCESS QIOs. Solution: The code now performs the following checks: 1. Is the socket is shareable? 2. Does the issuing process have the SHARE privilege? 3. Does the issuer's parent process owns the device. Access is denied only if all these checks fail. When access is disallowed, the SS$_NOPRIV error is returned rather than SS$_ACCVIO. ECO 2 Updates: -------------- ECO C 9-Jan-1995 AXP Images: UCX$BGDriver.EXE UCX V3.2-9C (Alpha) o Problem: Use of the #pragma member_alignment preprocessor option on Alpha has led in one instance to a misalignment 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, this bug has probably contributed to several un-explained 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 resynchronized the data structures. However, the source for INET_NPGD.SDL is now in the [...SRC_PAT.NET] tree for V3.1. A build for ...SRCLIB SRCLIB... was done only for the two Alpha streams. Thus, users who are running VAX systems should avoid doing a library rebuild during the rest of the life of V3.1 and its ECOs. Note: This is the same action that was taken for ECO R of V3.1. ECO D 12-Jan-1995 AXP and VAX Images: UCX$BGDriver.EXE UCX V3.2-9D (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9D UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9D UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9D UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9D UCX$INETACP.EXE UCX V3.2-9D o Problems: 1. A system crash occurs in the INET_IPINTR+1F3 routine when it references the supposed IF_UCB structure pointed to by R8. The crash occurs because R8 contains zero. 2. During the execution of a SHOW INTERFACE command, a system crash may occur. A crash may also occur in the UCX$INET_ROUTED process. 3. A system crash occurs in the INETACP routine at INETACP_SERV_ACCEPT+1B1 in INETACP_CREPROC.MAR. 4. A system may hangs for 10 to 15 minutes when FTP is aborted from a remote Macintosh [R]. Solution: 1. At this point in the code, R8 is pointing at the IF_UCB of the interface over which the current MBUF is received. Since the loopback interface does not have an IF_UCB structure, if the current MBUF has been received over the loopback interface, the system will crash. For now, the crash will be prevented by simply dropping the packet if R8 is set to zero. 2. 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_DELETE_ETHERNET subroutine in the INETACP_ETHERNET.MAR module, a test is made to determine if the interface to be deleted is that of LO0. If it is, the request is terminated. 3. Acceptance of a connection may fail because the maximum number of sockets has been surpassed. During clean-up a system crash occurs after a reference to the REQCB$L_UCB_2 which has not been initialized in this path. The solution is to initialize this field and REQCB$W_CHAN_2 when the REQCB is created in the INET_REMOTE_ACCEPT routine in INET_ACCESS. 4. In the INET_ENQ_IO subroutine in the the INET_RCV_XMT.MAR module, if R1 contains a negative number, 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 4 Updates: -------------- ECO E 24-Jan-1995 AXP and VAX Images: UCX$BGDriver.EXE UCX V3.2-9E (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9E UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9E UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9E UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9E UCX$INETACP.EXE UCX V3.2-9E o Problem: A system crashes occurs in the INET_FREE_MBUF_CHAIN when calling @VCRP$A_DEALLOC_RTN and trying to deallocate a VCRP. Solutions: The IP_INPUT_VMS.C module explicitly declares several instances of invocations of the "sizeof" function used in comparisons to be of the type (int). This would force the generated code to use signed comparison instructions. The problem caused packets to be destroyed with spurious options. *NOTE* The crash was caused by something clearing the VCRP$A_DEALLOC_RTN field and that we never demonstrated how the evident error, which did cause us to mangle a received datagram, actually caused the crash. However, given that the error did cause destruction of data, it is not too much to accept that it also led to the crash. ECO F 17-Feb-1995 AXP and VAX Images: UCX$BGDRIVER_SEC.EXE UCX V3.2-9F (Alpha) UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9F UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9F o Problem: The Security Driver interface is broken. When it calls @ip_secvec$l_ip_input, R8 is supposed to be pointing to the IF structure, not the IF_UCB structure. Solutions: The code has been fixed so that it places the correct value in R8. ECO G 21-Feb-1995 AXP and VAX Images: UCX$BGDRIVER_SEC.EXE UCX V3.2-9G (Alpha) UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9G UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9G UCX$INETACP.EXE UCX V3.2-9G o Problem: 1. Due to a change in behavior for OpenVMS AXP T6.2-FT2, the LOGINOUT.EXE image needs to be specified instead of the DCL.EXE image, when starting a new server process. 2. One code path in the ECO F fix for the Security Driver does not properly setup R8. Solution: 1. The Auxiliary Server uses the LOGINOUT.EXE image. 2. The code problem has been corrected. ECO 5 Updates: -------------- ECO H 21-Mar-1995 VAX / AXP Images: UCX$BGDRIVER_SEC.EXE UCX V3.2-9H (Alpha) UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9H UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9H UCX$INETACP.EXE UCX V3.2-9H o Problem: When using SELECT with null lists on a multi-processor, it fails with a strange error code in the IOSB. When called with null lists, the INET_SELECT_BUILD_LIST routine 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: Initialize R0 to SS$_NORMAL on entry to INET_SELECT_BUILD_LIST. ECO 6 Updates: -------------- ECO I 3-Apr-1995 VAX / AXP Images: UCX$BGDRIVER_SEC.EXE UCX V3.2-9I (Alpha) UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9I UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9I UCX$INETACP.EXE UCX V3.2-9I o Problem: A system crash at INET_SEL_READ_ALL+14 may occur 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 determine if the UCB that serves as the head of the SELECT list is already active. If so, an SS$_DEVACTIVE is returned and the call is terminated. Unfortunately, the temporary space associated with the first SELECT call was also being 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. ECO 7 Updates: -------------- ECO J 10-May-1995 VAX and AXP Images: UCX$BGDriver.EXE UCX V3.2-9J (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9J UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9J UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9J UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9J UCX$INETACP.EXE UCX V3.2-9J o Problem: The following system crashes occur: 1. In SBDROP which calls PANIC due to what appears to be an inconsistent receive socket buffer; and 2. In PWIP, in adjTCPwindow, with an access violation due to referencing a stale UCB. Solution: Both of the above crashes may be triggered when the PWIP application chooses to close a connection before it has deallocated all the MBUFs that have been passed to it. The solution to both of these problems can be achieved by redesigning the mechanism used to handle deferred TCP window adjustment for PWIP. Formerly, two UCB fields, UCB$L_BG_So_cc and UCB$L_BG_So_mbcnt, were used to keep track of the SO_CC and SO_MBCNT values associated with MBUFS passed up to Pathworks or DECnet/OSI. The redesigned mechanism makes use of a new structure, the DWAB (Deferred Window Adjustment Block), to keep track of these quantities. This redesign goes hand in hand with PWIP changes to PWIPDRIVER_READ.C and PWIP_DRIVER_SUPP.C. It is imperative that both changes (i.e., NET and PWIP) be installed simultaneously. ECO 8 Updates: -------------- ECO K 27-Jun-1995 VAX and AXP Images: UCX$BGDriver.EXE UCX V3.2-9K (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9K UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9K UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9K UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9K UCX$INETACP.EXE UCX V3.2-9K o Problems: 1. When an ICMP_NETMASK_REQUEST is issued by a host whose address is 0.0.0.0, it is expected that an ICMP_NETMASK_REPLY will be broadcast in response, providing such a feature is enabled. An initial problem exists in that icmp_input() does not enable broadcasts via the IP_ALLOWBROADCAST flag when it replies through ip_output(). As a result, an EACCESS error is returned by the interface code. 2. The second problem is that this option is supposed to be "settable". No facility currently exists to directly control such a feature. A guideline is that only gateways tend to generate such replies and although a specific host could be so enabled, this is not common. Therefore, this feature will only be enabled for gateways. To enable the feature, issue the command: $UCX SET PROTOCOL ICMP /UNREACHABLE 3. A case of incorrect synchronization in the UCX$INETACP can hang the system with the UCX$INETACP in RWAST state waiting for I/O to rundown on a BG device that the ACP has tried to DEASSIGN. 4. A crash in INETACP_SERV_ACCEPT_CLOSE occurs due to a non-zero value in the REQCB$W_CHAN_2 field. The non-zero value indicated that a valid channel existed and that the corresponding REQCB$L_UCB_2 was valid. 5. A system crash may occur in INET_SEL_READ_ALL with the pointer to the temporary space allocated for select set to zero. Solutions: 1 and 2. Change IP_ICMP_VMS.C to include OpenVMS conditional code which senses the `ipgateway' flag (set by the above command), and calls ip_output() with the IF_ALLOWBROADCAST flag. If the `ipgateway' flag is set to FALSE, broadcasts will not be allowed. Requests from 0.0.0.0 will be rejected by the UCX ethernet layer which returns EACCES. 3. The synchronization error occurs when attempts are made to execute substantive code in an AST thread in the UCX$INETACP. The AST thread was triggered by a Read ATTN completion. Nothing but code should ever be executed to queue a REQCB in the context of the AST. The fix is to do that in the INETACP_USER_INFO_AST routine and to move the substantive code to INETACP_USER_INFO_AST_CONT. 4. The interpretation of the REQCB_W_CHAN_2 field is modified to take into account the fact that this field is overlayed with the REQCB$W_PROTO field. Given that this latter field can only take the values 0 and 1, and given that valid channel numbers are 10, 20, 30, etc., all in hex, a non-zero number is now interpreted with the low bit clear as a valid channel and anything else (e.g., 1) as a non-channel. 5. Upon entry to INET_SELECT, the field that holds the pointer to the temporary space is no longer cleared until after sanity checks are performed. Previously, when the caller passed a bad parameter or called to select upon an already selected device, the pointer to the temporary space allocated for a previous select call was erased. ECO L 7-July-1995 AXP and VAX Images: UCX$BGDriver.EXE UCX V3.2-9L (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9L UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9L UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9L UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9L UCX$INETACP.EXE UCX V3.2-9L o Problem: The system will crash at INETACP_USER_INFO_AST_CONT in the UCX$INET_ACP process, due to a corrupted SERV$L_REXEC_FLNK queue. Solution: In the code added to fix Problem #2 in ECO K, a problem was introduced that corrupted the SERV$L_REXEC_FLNK queue. In an attempt to remove all substantive code from the INETACP_USER_INFO_AST, it was overlooked that, at the time the routine is called, the REQCB in question is already queued on the SERV$L_REXEC_FLNK queue. Then when the same, already queued REQCB is queued to the AQB, the former queue gets corrupted. The solution is to REMQUE the REQCB while still in AST context and before INSQUEing again. ECO M 21-July-1995 AXP and VAX Images: UCX$BGDriver.EXE UCX V3.2-9M (Alpha) UCX$INTERNET_SERVICES.EXE UCX V3.2-9M UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9M UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9M UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9M UCX$INETACP.EXE UCX V3.2-9M o Problem: A system crash may occur in the UCX$INET_ACP process with KRNLSTAKNV. Solution: The source of this problem is that the UCX$INET_ACP process is calling UCX$ACCESS_SHR routines from kernel mode. These routines result in calls to RMS which does not support being called from kernel mode. The solution is to introduce a mechanism that allows the ACP to essentially continue a thread begun in kernel mode into user mode and then back to kernel mode. The implementation includes reorganizing the ACP's use of its kernel mode stack. From now on, the ACP will switch to a private kernel mode stack as soon as it enters kernel mode. When it wants to continue a thread into user mode, it will call the INETACP_CONTINUE_IN_USER_MODE routine which will wrap up its current private stack context, switch back to the normal kernel stack, and return back to user mode where the request will be processed. When the user mode request is finished, a call back to kernel mode at routine INETACP_CONTINUE_KERNEL will be made. Processing will pickup the context left on the private stack and continue. ECO N 11-Aug-1995 AXP and VAX Image: UCX$INETACP.EXE UCX V3.2-9N o Problem: A previous fix (ECO M) had the side effect of causing incorrect offset data to be returned by IO$_ACPCONTROL QIOs in which a HOSTENT_OFFSET or NETENT_OFFSET structure was requested. This problem prevents the NFS client from operating properly. Solution: Update the offsets in the copy of the buffer which will be returned, not in the original buffer written by UCX$ACCESS_GET. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 UCX$INETDRIVER.EXE --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 06-Jan-1995 VAX Images: UCX$INETDRIVER.EXE o Problem: A system crash occurs 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 7 Updates: -------------- ECO B 28-Apr-1995 Images: UCX$INETDRIVER.EXE UCX V3.2-9B o Problem: A PGFIPLHI bugcheck occurs in IOC$VERIFYCHAN when it is called from INET_CANCEL. Solution: Release the forklock before calling IOC$VERIFYCHAN. ECO 8 Updates: -------------- ECO C 20-Jun-1995 Images: UCX$INETDRIVER.EXE UCX V3.2-9C o Problem: A system 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 the process open to being interrupted by an AST that might try to re-acquire the Mutex. The INET_CANCEL routine has been reorganized. o Problem: Thread startup fails to initialize the OP_R_FLAGS. This can lead to problems with asynchrony and I/O completion. Solution: When initializing the thread, clear the OP_R_FLAGS to ensure that the initial context is clear. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 UCX$TNDRIVER.EXE --------------------------------------------------------------------------- ECO 3 Updates: -------------- ECO B 26-Jan-1995 Images: UCX$TNDRIVER.EXE UCX V3.2-9B o Problem: A system crash with CPUSPINWAIT may occur due to a corrupted TIMER queue. Solution: Synchronize the use of UCB-based TQE between TN$CANCEL_TIMER and the various timer routines that are invoked. The UCB$L_TN_TIMER_FLAG field which is normally set to zero has been added. In TN$CANCEL_TIMER, 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 will be set to -1. Then in the three timer routines, TN$DISCONN_TIMEOUT, TN$FREE_UCB_TIMER, and TN$LOGIN_TIMER, the flag is tested. If it is negative, it is cleared and the call is simply dismissed since it was the intention of the caller of the TN$CANCEL_TIMER to cancel the timer in the first place. ECO D 8-Feb-1995 Images: UCX$TNDRIVER.EXE UCX V3.2-9D o Problem: When the UCX TELNET server received both a DO ECHO and a WILL ECHO from the remote host, only the first would get a response. Solution: Set the remote echo flag, rather than the local echo flag, when a WILL ECHO message is received. ECO 5 Updates: -------------- ECO E 3-Mar-1995 AXP AND VAX Images: UCX$TNDRIVER.EXE UCX V3.2-9E o Problem: System crashes with INVEXCEPTN may occur due to 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 destroyed a pointer which led to a crash. The solution is to correctly limit the size of the sub-negotiation buffer. ECO 6 Updates: -------------- ECO F 4-Mar-1995 AXP AND VAX Images: UCX$TNDRIVER.EXE UCX V3.2-9F o Problem: A system crash with DOUBLDEALO 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.2 UCX$IPC_SHR.EXE --------------------------------------------------------------------------- ECO 8 Updates: -------------- ECO A 14-June-1995 AXP AND VAX Image: UCX$IPC_SHR.EXE UCX V3.2-9A o Problem: When one thread is blocked doing I/O, in a multi-threaded environment other threads were intermittently also blocked. Solution: The DECthreads environment does not always correctly handle the case where threads are sharing an event flag and each thread is waiting for it to be set. Modify the UCX socket library so that a new event flag is allocated for each operation, rather than using the same event flag over and over. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 UCX$TELNET.EXE --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 09-Nov-1994 AXP AND VAX Images: UCX$TELNET.EXE V3.2 - 9A o Problem: The PRINT-SCREEN function on AXP returns "file not found". Solution: In [TELNET]RMSFILEIO.BLI, the 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 on VAX, 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 to prevent the same error from occurring over and over again. ECO 6 Updates: -------------- ECO C 2-Feb-1995 Images: UCX$TELNET UCX V3.2-9C o Problem: An unprivileged user may get the OPER privilege authorized in a subprocess (SPAWN commmand). Solution: Modify the SPAWN routine to take away the OPER privilege if it is not authorized. ECO G 06-Apr-1995 AXP/VAX Images: UCX$TELNET.EXE V3.2-09G o Problem: When using IBM-3278-4 model terminals, the TN3270 signals the message "network resource not available". Solution: In [TELNET]TELNET$CLIENT_NET.C, the IO$M_NOWAIT modifier to the write $QIO has been removed. This allows TELNET to wait for the transmission of the data instead of returning to command mode with a resource problem. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 BIND Server --------------------------------------------------------------------------- ECO 7 Updates: -------------- ECO B 16-MAY-1995 Images: UCX$NSLOOKUP.EXE UCX V3.2-9B o Problem: The "mcr ucx$nslookup" command with the wrong bind-server name in command line caused an ACCESS VIOLATION. With the wrong server-name passed, an error loop was invoked which apparently invoked the "perror" call with a null string. VAXC could not handle "perror" when a null string was passed as an argument. Solution: The ACCESS VIOLATION was replaced with an error message. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 BIND resolver --------------------------------------------------------------------------- ECO 7 Updates: -------------- ECO B 03-Apr-1995 AXP/VAX Images: UCX$ACCESS_SHR.EXE UCX V3.2-9B o Problem: When the BIND resolver receives a response from a nameserver indicating that datagram truncation has occurred, then fails to establish a stream (TCP) connection, and finally tries the next server in the list, the resolver uses an excessive timeout in waiting for a response from this second server. If this occurs when the UCX$INETACP process is calling the resolver, the result can be an apparent UCX-wide system hang. Solution: In RES_SEND.C, bounds checking is performed on the timeout calculation. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 UCX$BOOTP.EXE --------------------------------------------------------------------------- ECO 2 Updates: -------------- ECO A 16-Jan-1994 AXP/VAX Images: UCX$BOOTP.EXE V3.2-09A o Problem: The BOOTP server is not providing the optional vendor data for boot file size (i.e., tag type 13 in RFC1497). This is confusing code, that expects to find the file size in the BOOTP database, when in fact the server looks up the file size directly. Solution: Remove the check for file size in the BOOTP database record and just 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). Arguments in a memcpy() call were transposed. Solution: Fix the error. ECO 8 Updates: -------------- ECO C 7-Aug-1995 AXP and VAX Images: UCX$BOOTP.EXE UCX V3.2-09C o Problem: Boot replies are sent to the wrong port on the bootp relay servers. Can't run interactively for testing. ACCVIO when bootp client name isn't defined. Can't find client load file. No client host name in boot reply. Omit file version number in load file name. Obtain all local IP addresses from kernel, and send proper one for each client. Clean up references to 'gateway' when 'relay' is the proper term. Solution: Fix check for relay agent address in giaddr for BOOTREQUEST, not BOOTREPLY op code. Send replies to relay ('gateway') servers' ServerPort. Use the terms 'ClientPort' and 'ServerPort' to be consistent with RFC951. Fix the socket()/bind() problem to appropriately run the bootp server interactively Fix BootRequest() to handle clients that have no host name - this caused an ACCVIO Fix GetFileSize() to properly handle file name construction when there is no HostName. Fix VendHost() to handle null or abbreviated HostName. Move file name to Bootp response in GetFileName, and leave off the file version number. Instead of trusting that gethostname() returns the host name that points to ALL interfaces, read the ifnet structure from the kernel, and build a table of known local IP addresses for outgoing responses to use in Siaddr. Match subnetmasks to select the appropriate address to send. Put the server name in the response packet, according to the the name associated with the interface, (i.e., gethostbyaddr()). Have the Trace routines refer to the relay as a relay, not a 'gateway'. The semantics are confusing enough (RFC 951). It's a relay, not a gateway. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 UCX$TFTP.EXE --------------------------------------------------------------------------- --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 UCX$FTP.EXE. --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 5-Dec-1994 AXP and VAX Images: UCX$FTP.EXE UCX V3.2-9A o Problem: GET strips the device and directory from a local filespec. Solution: This code has been removed. ECO B 7-DEC-1994 VAX/AXP Images: UCX$FTP.EXE UCX V3.2-9B o Problem: The user gets a message saying that a number of bytes transferred even if none did. Solution: Fix send_data and recv_data to eliminate this. ECO 2 Updates: -------------- ECO C 27-DEC-1994 VAX/AXP Images: UCX$FTP.EXE UCX V3.2-9C o Problem: A tape needs 14 bytes minimum on a sys$write. Solution: Fix recv_bin and recv_normal_bin to pad to 14. ECO 7 Updates: -------------- ECO D 11-APR-1994 VAX/AXP Images: UCX$FTP.EXE UCX V3.2-9D o Problem: The disable port does not work. Solution: Fixed initconn to use the correct port if the PORT command is disabled and to add REUSEADDR on control port because it may be used as a dataport. A test of sendport == -1 was changed to sendoport == 1. Sendport cannot be -1. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 UCX$FTPC.EXE and UCX$FTPD.EXE --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 17-Nov-1994 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9A o Problem: Using node:: syntax produces errors on get and put. Solution: Do not attempt to check file access or determine if the file is a directory over the network. Notes: 1) This means that one can copy a file that is a directory, 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 B 30-Nov-1994 AXP/VAX Images: UCX$FTPC.EXE UCX V3.2-9B o Problem: File parsing in rnfr and retr do not correctly handle multi-directory linked logicals. Solution: An error in check_filetype that was leaving assigned was fixed channels. ECO C 2-DEC-1994 AXP/VAX Images: UCX$FTPC.EXE UCX V3.2-9C o Problem: When an even number of subdirectories is involved in checkdir_access, the user gets a 'privilege' error. Solution: Fix btest of NAM$V_DIR_LVLS to check all 3 bits. ECO 2 Updates: -------------- ECO D 21-DEC-1994 AXP/VAX Images: UCX$FTPC.EXE UCX V3.2-9D o Problem: Cannot write to tape at all. Solution: Recv_vms_plus_bin and recv_normal_bin were changed to handle tape requests by not checking access if a tape device is specified. o Problem: A RMS-write error occurs when writing to tape. Solution: Fixed appe_vms_plus_bin, appe_normal_bin, recv_normal_bin and recv_vms_plus_bin to make all tape writes >= 14 bytes. Changed l_print call to dev_cls. Fixed code to write at least 14 bytes to tape (tape driver restriction). o Problem: DIR with node:: does not work. It gives a "NO privilege" and outputs an incorrect string. Solution: Do not perform a checkfl_access (in list). Pass the correct buffer to prntdirinf. ECO E 11-JAN-1995 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9E o Problem: A put cannot be performed to a searchlist logical. Solution: Fixed a problem in stor(). ECO 4 Updates: -------------- ECO F 23-JAN-1995 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9F o Problem: The $parse leaves channels behind if a search list is involved. Solution: Many routines were modified to clean up channels after the $parse. A new routine was added to make the clean-up happen. ECO G 27-FEB-1995 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9G o Problem: A write cannot be performed to a non-directory device (e.g., LTA:, terminal). Solution: Do not check the directory on such devices. ECO 5 Updates: -------------- ECO H 21-MAR-1995 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9H o Problem: A put to a concealed device with a directory of [000000] fails. Solution: Stor no longer pre-checks directory access. ECO 7 Updates: -------------- ECO I 11-APR-1995 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9I o Problem: Sendport (disable port) does not work. Solution: 1. Dataconn was modified to use the correct port if the PORT command is disabled. 2. The connect in dataconn will now retry for 32 seconds. 3. All retry_cnt loops were changed to 32 instead of 30. ECO J 20-APR-1995 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9J o Problem: The checkdir_access is looking for ']' if there are subdirectories in the target specification of a 'put' command. If the angle brackets are used, this search fails, causing a 'protection' error on a 'put'. Solution: Stor does not checkdir_access if an '<' is present. ECO K 25-APR-1995 VAX/AXP Images: UCX$FTPC.EXE UCX V3.2-9K UCX$FTPD.EXE UCX V3.2-9K o Problem: Exclamation points in UCX$FTP_SERVER_ANNOUNCE and UCX$FTP_ANONYMOUS_WELCOME messages caused problems. Solution: The FTP$SERVER_ANONYMOUSD\send_server_message call was modified to sendreply and FTP$SERVER_ANONYMOUSD\send_client_message call was changed to postreply. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 SMTP Mail Facility --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A VAX/AXP Images: UCX$SMTP_MAILSHR.EXE UCX V3.2-9A UCX$SMTP_RECEIVER.EXE UCX V3.2-9A UCX$SMTP_SYMBIONT.EXE UCX V3.2-9A UCX$SMTP_PARSESHR_TV.EXE UCX V3.2-9A UCX$UUENCODE.EXE UCX V3.2-9A UCX$UUDECODE.EXE UCX V3.2-9A o Problem: If mail comes in from a non-SMTP user to a user who has forwarded their mail via SMTP on the local system, the VMSmail From line will reject the reply command. If the non-SMTP transport from which the mail comes is DECnet, the From line is enclosed in double quotes. If the non-SMTP transport is MTS, the From line is enclosed in double quotes and also contains backslashes preceding the inner double quotes in the address. The old code would produce: From: "SOMNOD::SOMEBODY" rather than From: SOMNOD::SOMEBODY; or this: From: "MRGATE::\"MRGATE::SUMNOD::SENDING_USER\"" rather than From: MRGATE::"MRGATE::SUMNOD::SENDING_USER" Solution: This has been fixed. 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. For example, if UCX host "abc.def.com" has an SMTP substitute domain of "def.com" defined and mail goes to host "abc.def.com" addressed to "jones@def.com", this mail would not be recognized as local and delivered locally to user jones unless an alias "def.com" for the host "abc.def.com" was defined in the local host database. Solution: This problem has been fixed. UCX SMTP now recognizes mail sent to the substitute domain as local. In the event that you do not want it to recognize mail sent to the substitute domain as local, define the system logical UCX$SMTP_NO_SUBS_DOMAIN_INBOUND before starting the SMTP mail queue. o Problem: For inbound mail, UCX SMTP will not put anything in to the VMSmail CC line. Solution: For inbound mail, UCX SMTP now sets the VMSmail CC line. (See the next problem/solution for more information.) o Problem: For inbound mail, UCX SMTP will unconditionally put the RFC To header in to the VMSmail To: line. Solution: For inbound mail, UCX SMTP now puts the X-VMS-To RFC header in 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 in to the VMSmail CC: line. Otherwise, any RFC CC header will go in to the VMSmail CC: line. If it is not desireable 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 5 Updates: -------------- ECO B 23-Mar-1995 VAX/AXP Images: UCX$SMTP_MAILSHR.EXE UCX V3.2-9B UCX$SMTP_RECEIVER.EXE UCX V3.2-9B UCX$SMTP_SYMBIONT.EXE UCX V3.2-9B UCX$SMTP_PARSESHR_TV.EXE UCX V3.2-9B UCX$UUENCODE.EXE UCX V3.2-9B UCX$UUDECODE.EXE UCX V3.2-9B o Problem: The VRFY and EXPN commands do not work. Even though the VRFY command is optional in its implementation, some systems rely on it by performing a VRFY on a user or an EXPN on a list before sending mail to it. Solution: This problem has been fixed. o Problem: The UCX SMTP receiver cannot handle a multi-line reply to the HELO command. Solution: This problem has been fixed. ECO 7 Updates: -------------- ECO C 5-Jun-1995 VAX/AXP Images: UCX$SMTP_MAILSHR.EXE UCX V3.2-9C UCX$SMTP_RECEIVER.EXE UCX V3.2-9C UCX$SMTP_SYMBIONT.EXE UCX V3.2-9C UCX$SMTP_PARSESHR_TV.EXE UCX V3.2-9C UCX$UUENCODE.EXE UCX V3.2-9C UCX$UUDECODE.EXE UCX V3.2-9C o Problem: When many inbound SMTP connections are made at the same time, UCX SMTP will sometimes create control file names that are identical for more than one mail. This causes UCX SMTP to deliver one of the versions of the control file multiple times and not to deliver the rest at all. Solution: UCX SMTP is now sensitive to the file version number so that files with the same name are handled appropriately. o Problem: It is impossible to send a file using UCX SMTP with lines greater than 512 characters and less than 1000 characters. UCX SMTP inserts . The SMTP RFC allows up to 1000 characters. Solution: The buffer size has been changed to 1000 (inclusive of the ). Note that this fix applies to outbound mail. For mail received from SMTP and delivered locally via VMS mail, line breaks () must still be added every 255 characters because this size is a VMS mail limit. o Problem: If SYS$SCRATCH is defined to a bad value for the SMTP symbiont process (i.e., a directory where a file cannot be created), the UCX SMTP symbiont cannot deliver any local mail. Solution: RMS Parse now calls to check SYS$SCRATCH directory validity in the mainline of the SMTP symbiont. If it is invalid, then SYS$SCRATCH is redefined to point to the postmaster directory. o Problem: SMTP addresses placed in SMTP mailing list files could not contain comments. This applies to the mailing lists in SYS$SPECFIC:[UCX_SMTP] which contain SMTP addresses and are processed by the SMTP symbiont. This does not apply to VMS mail distribution lists which contain SMTP addresses in the SMTP%"..." format. Solution: This problem has been fixed. o Problem: SET FORWARD/USER=username SMTP%"..." cannot be used to send to multiple SMTP addresses. Solution: SET FORWARD/USER=username SMTP%"..." can now be used to forward mail to multiple recipients. For example, if the following forward is defined on host xyz.com: MAIL> SET FORWAR/USER=HOTLINE SMTP%"""kim@xyz.com, joe@abc.xyz.com""" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | More than one name here -->--->------->-----+ This will cause mail sent to the user HOTLINE to be sent via SMTP to kim@xyz.com and to joe@abc.xyz.com. If mail is being sent to HOTLINE from the host on which the forwarding has been defined that mail can be sent to that username directly like this: MAIL> send To: HOTLINE ... If you are on another host you can send to hotline@xyz.com and UCX SMTP on host xyz will expand the mail to go to kim@xyz.com and to joe@abc.xyz.com. Note that this is limited by maximum length of a VMS mail command line, 256 characters. o Problem: 1. On Alpha systems, ANALYZE MAIL/REPAIR frequently terminates with the "%SYSTEM-F-IVLOGNAM, invalid logical name" message. 2. Mail directories which are specified with "<",">" instead of "[","]" (e.g., dka0:) are not being handled correctly which results in an access violation. 3. Usernames of 12 characters in length are not being handled correctly which results in the following error message in ANALYZE MAIL/REPAIR: %UCX-W-ANA_QUEACC, queue access failure -JBC-F-INVPARLEN, invalid parameter length ..... Solution: This problem has been fixed. o Problem: A control file error occurs when mail is sent from a user whose mail directory is obtained from a concealed logical name. Solution: This problem has been fixed. ECO 8 Updates: -------------- ECO D 28-Jul-1995 VAX/AXP Images: UCX$SMTP_MAILSHR.EXE UCX V3.2-9D UCX$SMTP_RECEIVER.EXE UCX V3.2-9D UCX$SMTP_SYMBIONT.EXE UCX V3.2-9D UCX$SMTP_PARSESHR_TV.EXE UCX V3.2-9D UCX$UUENCODE.EXE UCX V3.2-9D UCX$UUDECODE.EXE UCX V3.2-9D o Problem: ANALYZE MAIL/DELETE submits zero-block control files to the symbiont rather than just deleting them. Solution: Zero block Control files greater than 12 hours old are deleted. o Problem: If a user account exists but the mail directory does not, there is no need to signal a warning/error message. Do not display any error message if a mail directory is not found. This has been suppressed to avoid any unnecessary concerns that may be raised when a message such as this is seen :" .. directory cannot be accessed", "... bad parameter error". Solution: This problem has been fixed. o Problem: Various ANALYZE MAIL/DELETE problems exist. Solution: This problem has been fixed. Note that /DELETE will delete control files as long as they are not already in the queue. If they are, they will be released and the message will be processed. The /DELETE and /REPAIR qualifiers work properly for all cases when they are used together. o Problem: UCX LPD Received: RFC headers were missing a required ";" before the date field. Solution: This problem has been fixed. o Problem: When delivering a mail to MTS (aka Message Router), the symbiont puts "UCX_SMTP" into the From field. If the from field is passed to MTS as intended (i.e., smtp%"user@host") and MTS tries to deliver the mail to VMSmail, MTS will bounce the mail. This is because it has to construct a From address with an SMTP address inside an MTS address which is impossible since VMS mail cannot currently handle the nested double quotes that would result. An innocuous UCX_SMTP value is the used so that the mail goes through, even with an incorrect from field. Note that the from field that should be passed to MTS is preserved in an X-Original-From header. However, there is no need for this work-around when the mail is to be delivered by MTS to All-in-1. The All-in-1 address format can handle this situation and MTS will not bounce the mail. Solution: For sites whose users are forwarding their mail through MTS to All-in-1, the following command should be executed prior to queue start-up: $ DEFINE/SYSTEM UCX$SMTP_MTS_ALLIN1 1 This disables the SMTP symbiont function that makes UCX_SMTP part of the from field. This allows the correct address to be received by All-in-1 mail users. NOTE: If there are VMSmail users on the system, defining this logical will cause their mail to bounce. This workaround was included only to deal with VMSmail's inability to handle nested double quotes and will be removed once VMSmail is updated. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 LPD Facility --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A VAX/AXP Images: UCX$LPD_SHR.EXE UCX V3.2-9A UCX$LPD_SMB.EXE UCX V3.2-9A UCX$LPD_RCV.EXE UCX V3.2-9A UCX$LPQ.EXE UCX V3.2-9A UCX$LPRM.EXE UCX V3.2-9A UCX$LPRSETUP.EXE UCX V3.2-9A UCX$TELNETSYM.EXE UCX V3.2-9A 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 prevented the SMTP symbiont from defining SYS$SCRATCH in the system table which was not correct behavior for SMTP. However it had the positive side-effect of disguising this problem in LPD because SYS$SCRATCH was always defined. Solution: Check to see if the SYS$SCRATCH logical is defined in the LPD symbiont process. If it is not, 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 a 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. So, replace: $ DEFINE/SYSTEM LPD_DEBUG 65535 $ DEFINE/SYSTEM LPD_RCV 65535 with $ 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 previously 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 exactly what the LPD is sending (for outbound jobs) and receiving (for inbound jobs) in order to diagnose problems. To turn on just 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's log file, UCX$LPD_RCV_LOGFILE.LOG. ECO 2 Updates: -------------- ECO B 16-Jan-1994 AXP Images: UCX$LPD_SHR.EXE UCX V3.2-9A UCX$LPD_SMB.EXE UCX V3.2-9A UCX$LPD_RCV.EXE UCX V3.2-9A UCX$LPQ.EXE UCX V3.2-9A UCX$LPRM.EXE UCX V3.2-9A UCX$LPRSETUP.EXE UCX V3.2-9A UCX$TELNETSYM.EXE UCX V3.2-9A o Problem: Outbound PRINT/PASSALL of a file with an embedded carriage control adds extra line feeds. If a PRINT/PASSALL of a non-stream LF file which contains an 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 feed is inserted for each line. This problem manifests itself as doublespaced printing. The most common cause of this is printing a non-stream LF file from an application that ends its text lines with line feed carriage control rather than carriage return line feed. Solution: This problem has been fixed. If a problem occurs with /PASSALL printing, the previous behavior can be returned by doing: $ DEFINE/SYSTEM UCX$LPD_STREAM_PASSALL 1 This should be unnecessary. If a problem with /PASSALL printing is fixed by 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: A receiver fix included in ECO C to handle a control file before data files caused mis-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 has been fixed. o Problem: UCX LPD does not honor OpenVMS flag page print options. Outbound LPD jobs (client): The only way to suppress flag/banner pages 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. It would also 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 access the new behavior, the following should be added to UCX$LPD_STARTUP.COM: $ DEFINE/SYSTEM UCX$LPD_VMS_FLAGPAGES 1 * For outbound jobs: - When this logical is defined /PARAM=NOFLAG has no effect. - If this 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 honored 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 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). - A problem occurs 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 5 Updates: -------------- ECO C 22-Mar-1995 AXP Images: UCX$TELNETSYM.EXE UCX V3.2-9C 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. ECO 8 Updates: -------------- ECO D 28-Jul-1995 AXP Images: UCX$LPD_SHR.EXE UCX V3.2-9D UCX$LPD_SMB.EXE UCX V3.2-9D UCX$LPD_RCV.EXE UCX V3.2-9D UCX$LPQ.EXE UCX V3.2-9D UCX$LPRM.EXE UCX V3.2-9D UCX$LPRSETUP.EXE UCX V3.2-9D UCX$TELNETSYM.EXE UCX V3.2-9D o Problem: If the LPQ or the LPRM command is submitted in a .COM file *or* if a DEFINE/USER of SYS$OUTPUT is pointing output to a file, then output is extended across multiple lines of the .LOG/output file. Solution: This problem has been fixed. o Problem: In the conversion between a network file name (cFA123host.domain.com) and an OpenVMS legal filename (cFA123host_domain.com) the file name is truncated to 32 characters. This is expected behavior. However, if the first character after the truncated filename is a "-", an RMS-F-SYN, file specification syntax error will occur. Solution: Trap for this special case and substitute the "-" with a "_". o Problem: When trying to delete a printcap entry, LPRSETUP sometimes issues the message "Can't unlink spool directory, RMS-F-SYN, file specification error." Solution: This problem has been fixed. o Problem: It is necessary to create separate OpenVMS print queues, each with its own print forms, if print forms for jobs sent to the UCX LPD server are being used. Solution: UCX LPD now supports a new printcap field, "fm", for local printcap entries. This field contains the name of the OpenVMS print form with which the job should be submitted. All that is necessary to create multiple LPD printcap entries with different values for the "fm" field and point the "lp" value to the same local printer. Here are two example printcap entries: BOGUS_P_FORM1|bogus_p_form1:\ :lf=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_FORM1.LOG:\ :lp=SOME_PRINTER:\ :fm=FORM1:\ :sd=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_FORM1: BOGUS_P_FORM2|bogus_p_form2:\ :lf=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_FORM2.LOG:\ :lp=SOME_PRINTER:\ :fm=FORM2:\ :sd=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_FORM2: Jobs sent to printer "BOGUS_P_FORM1" will be printed with FORM1 to the OpenVMS queue SOME_PRINTER. Jobs sent to printer "BOGUS_P_FORM2" will be printed with FORM2 to the OpenVMS queue SOME_PRINTER. Note that the printcap key fields differ so that these printers appear to the LPD client as two printers. However, since they share the same value in their "lp" fields there is only one OpenVMS print queue - SOME_PRINTER. UCX LPD now supports a similar printcap field which says that a job is to be submitted as /PASSALL. This field is the "pa" field and has no value. Its presence in the printcap entry tells the symbiont to submit it /PASSALL. BOGUS_P_FORM2_PA|bogus_p_form2_pa:\ :lf=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_FORM2_PA.LOG:\ :lp=SOME_PRINTER:\ :pa:\ :fm=FORM2:\ :sd=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_FORM2_PA: Jobs printed to this printer will be submitted to the OpenVMS printer SOME_PRINTER with /FORM=FORM2 /PASSALL. Notes: 1. UCX LPRSETUP support for these fields has not yet been added. 2. UCX LPD will not verify the value of the "fm" printcap field. If it is incorrect, then the job will get an error in the final destination print queue. o Problem: LPD clients that do not support the Digital Printserver LPD protocol Extensions cannot make use of the OpenVMS print capabilities provided by PRINT/PARAMETER when printing jobs to the UCX LPD server. Solution: Eight new printcap fields, one for each of the eight available /PARAMETER slots, are now supported for local printcap entries. The fields are p1 through p8 and work in a similar fashion to the new "fm" and "pa" fields. For each one entered, the corresponding PRINT/PARAMETER will be assigned that value. For example: BOGUS_P_LAND|bogus_p_land:\ :lf=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_LAND.LOG:\ :lp=SOME_PRINTER:\ :p1=data=postscript:\ :p2=page_o=landscape:\ :sd=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_LAND: In this example, all inbound LPD print jobs for printer BOGUS_P_LAND will be submitted as: $PRINT file/PARAM=(data=postscript,page_o=landscape)- /QUE=SOME_PRINTER The maximum number of characters for each of these fields is 255. Since the symbiont matches the slot of the printcap field with the corresponding /PARAM value, this can can also be used when printing to queues that are sensitive to having certain data in specific /PARAMETER slots. For example: BOGUS_P_HUH|bogus_p_huh:\ :lf=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_HUH.LOG:\ :lp=SOME_PRINTER:\ :p1=data=postscript:\ :p2=page_o=landscape:\ :p8=huh:\ :sd=/SYS$SPECIFIC/UCX_LPD/BOGUS_P_HUH: In this example, all inbound LPD print jobs for printer BOGUS_P_LAND will be submitted as: $PRINT file/PARAM=(data=postscript,page_o=landscape,,,,,,huh)- $_ /QUE=SOME_PRINTER Notes: 1. UCX LPRSETUP support for this field has not yet been added. 2. UCX LPD will not parse the values in these fields. If they are in error, then the job will get an error in the final destination print queue. o Problem: The UCX LPD retry mechanism sometimes leaves jobs in the "Holding" state rather than in the "Holding until..." state. Solution: This problem has been fixed. o Problem: The value that the UCX$TELNETSYM uses for the PSM$PRINT BUFSIZ parameter is fixed at 256. There is no way to configure the TELNETSYM to use a different value for optimization like one can do with LATSYM. Solution: The TELNET symbiont now supports this with a new logical, UCX$TELNETSYM_BUFSIZ. Define this system logical to any value from 1 to 2048 and the value specified will be sent to the PSM$PRINT routine in the BUFSIZ argument. For more information about this, please see the section in the "VMS Utility Routines Manual" on the PSM$ routines. o Problem: UCX TELNETSYM resets the link idle timer when data comes in from the printer/terminal server. If TELNET implementation in the printer/terminal server keeps sending data then the link will never be released. Solution: Do not reset the link idle timer for incoming data. Only set it for outgoing data. o Problem: When printing with the TELNET symbiont with /HEADER, the Page 1 header would never be printed. Solution: This problem has been fixed. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 Management Control Program (UCP) --------------------------------------------------------------------------- ECO 8 Updates: -------------- ECO B 16-Jun-1995 AXP and VAX Images: UCX$UCP.EXE UCX V3.2-9B o Problem: The /HOLD qualifier is not supported in UCX ANALYZE MAIL/REPAIR even though it is documented. Solution: Provide parser support in UCP for the /HOLD qualifier. The other part of this fix is in SMTP (and is included in ECO A for SMTP images) to provide the rest of the support to place entries on hold after an ANALYZE MAIL /REPAIR has been executed. ECO C 8-AUG-1995 AXP and VAX o Problem: The SET CONFIGURATION INTERFACE cannot add pseudointerfaces with numbers beyond four. The problem occurred due to the insufficient length of one of variables which caused another variable to be changed from the subroutine. Solution: Fix the length of the variable. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 PORTMAPPER --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 16-Dec-1994 AXP and VAX Images: UCX$PORTMAPPER.EXE UCX 3.2-9A o Problem: Portmapper loops writing error messages to a log file when registration fails. Solution: Break from the loop when a matching registration is found and cannot be replaced. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 RPC and XDR routines --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 06-Jan-1995 AXP and VAX Images: UCX$RPCXDR_SHR.EXE UCX$PORTMAPPER.EXE o Problem: Improper pointers cause 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. o Problem: The XDR_VECTOR() addrp argument is an incorrect type. Solution: Correct the definition and usage of the addrp argument. o Problem: Portmapper loops writing error messages to a log file when registration fails. Solution: Break from the loop when a matching registration is found and cannot be replaced. o Problem: CLNT_SPERRNO(), CLNT_SPCREATE_ERROR() and CLNT_SPERROR() are missing VAX transfer vectors and AXP symbol vectors. Solution: Add the appropriate vectors to make the procedures accessible ECO 7 Updates: -------------- ECO B 31-May-1995 AXP and VAX Images: UCX$RPCXDR_SHR.EXE UCX V3.2-9B o Problem: An error in the XDR routine `xdr_float()', caused an assignment instead of a test when decoding an IEEE float from the network into a local F_Float value. Solution: The typographical error has been fixed. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 RSH --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 06-Jan-1995 AXP and VAX Images: UCX$RSH.EXE o Problem: RSH hangs when executing on a non-terminal and redirected output is incorrect. Solution: Check for the device type and handle it correctly. Change the output mechanism. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 PWIP Driver and ACP --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 11-Nov-1994 AXP and VAX Images: UCX$PWIPACP.EXE UCX V3.2-9A UCX$PWIPDRIVER.EXE UCX V3.2-9A UCX$PWIPSHUT.EXE UCX V3.2-9A UCX$SDA.EXE UCX V3.2-9A 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. - The UCX SDA backend has been upgraded to support additional counters, etc. - Zero length transmissions are supported as described in the supporting specifications. - Naked M_DATA transmissions on TCP connections are supported as described in the supporting specifications. - Check to ensure that UCX is running before allowing PWIP to start. If UCX is not running, abort the PWIP ACP startup. - T_addr_req/t_addr_ack processing did not always return the requested information. If the connection in question was a listener, it always returned the local IP address as zero (0). Whether the local system was multi-homed or not, it only returned one (1) local address. The logic has been modified to fix the above deficiencies. ECO B 16-Nov-1994 VAX and AXP Images: UCX$PWIPACP.EXE UCX V3.2-9B UCX$PWIPDRIVER.EXE UCX V3.2-9B o Problem: Premature connect reject failure. If the QIO fails for an incoming connection rejection, do not return an error acknowledgement. Rather, setup and call disconReq_ast to deassign the associated channel. If the deassign completes successfully return a T_DISCON_REQ ok acknowledgement, or return an error acknowledgement. Solution: Change the acp_ok_ack to process the T_CONN_REQ / automatic T_BIND_REQ Pathworks work-around before acquiring IOLOCK8. This removes the need to release and re-acquire the lock later. ECO 7 Updates: -------------- ECO C 18-May-1995 AXP/VAX Images: UCX$PWIPDRIVER.EXE o Problem: The system will crash in PANIC called from SBDROP, due to an inconsistent receive socket buffer showing a non-zero character count with no mbufs hanging off the socket buffer. Solution: This problem is due to premature clearing of the UCB$M_BG_Defer_WinAdj flag in the PWIPDRIVER_SUPP.C pwip_handshake_transport routine. This fix eliminates the clearing of this bit in this routine. ECO D 18-May-1995 AXP/VAX o Problem: Doing arithmetic on fields of a stale UCB causes the system to be in adjTCPwindow. This problem is triggered by an upstream mbuf being freed after the connection has been closed. Previously, mbufs passed upstream had a pointer to the UCB and if the mbuf was not deallocated before the connection disappeared, a stale UCB might be used. Solution: The new structure, DWAB (Deferred Window Adjustment Block), has been created. It is guaranteed to persist until the last mbuf is returned. The mbufs are now pointed to the DWAB instead of at the UCB. Note that this fix entails changes to both PWIPDRIVER and to the NET facility (UCX$INTERNET_SERVICES.EXE for VAX and UCX$BGDRIVER.EXE for ALPHA). --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 SNMP_ AGENT --------------------------------------------------------------------------- --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 NFS Server --------------------------------------------------------------------------- --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 NFS Client --------------------------------------------------------------------------- ECO 8 Updates: -------------- ECO A 3-Mar-1995 AXP and VAX Images: UCX$DNFSACP*.EXE o Problem: Directory updates made locally at the server are delayed in becoming visible at the client, even with small values for the directory cache and attributes cache timeouts. Solution: Zero the finfo->last_read time if the directory cache has timed out this forces CHECK_ACCESS to do a real GETATTR. ECO A 1-Jun-1995 AXP and VAX Images: UCX$DNFSACP*.EXE o Problem: GRPPRV privilege was required to get access to a file owned by a same-group user with group access allowed. Solution: This problem has been fixed. ECO A 28-Jun-1995 AXP and VAX Images: UCX$DNFSACP*.EXE o Problem: Normally, directories do not need and do not have ADF files. However, a SET DIR /VERSION_LIMIT does result in creation of an ADF. This is fine until the directory is deleted. Since a directory is being deleted, an rmdir is attempted on both the directory and the ADF. The ADF deletion fails. Solution: A new parameter has been added to the calling sequence of the Fremove_Init routine to specify whether a directory or regular file is being deleted. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 CFS_SHR.EXE images --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 17-Nov-1994 AXP Images: UCX$CFS_SHR.EXE UCX V3.2-9A 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: 1. Correct the code which cleans up the locked resource. This removes the hang and looping problems. 2. Correct the code in the OPEN and READ services. This removes the corruption and the console message problems. o Problem: If ADD EXPORT was done with /OPTIONS=PURGE_VERSIONS, the presence of a file with a null name and extension (e.g., .;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. o Problem: The file system would crash if the final record of a file crossed the end-of-file (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 3 Updates: -------------- Back to original image UCX$CFS_SHR.EXE UCX V3.2-9 ECO 4 Updates: -------------- ECO B 20-Feb-1995 VAX and AXP Images: UCX$CFS_SHR.EXE UCX V3.2-9B 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 BUILD_RMAP, leaving the descriptor with a non-zero pend count. ECO 5 Updates: -------------- ECO C 01-Mar-1995 VAX and AXP Images: UCX$CFS_SHR.EXE UCX V3.2-9C o Problem: When `REAL_SIZE' determination is enabled in UCX$CFS_SHR (via logical UCX$CFS_MODUS_OPERANDI mask 512), writes to certain files result in corruption. Solution: An access check in BFS$OPEN_FH() was in error. Its purpose was to reaccess files for write after they have been accessed for read. When 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. ECO 8 Updates: -------------- ECO D 28-Jun-1995 VAX and AXP Images: UCX$CFS_SHR.EXE UCX V3.2-9D o Problem: In a directory exported with /option=purge_versions, an ls command may display and purge only the first several files in the directory. Each succeeding ls on the same directory then lists and purges one additional file. This happens because the reply buffer overlays the request arguments. In the case of the wildcard lookup for purge_versions, the file handle is refetched after it has been over-written and the operation terminates with an error (generally ss$_notvolset). Solution: V3.3 was changed to move the file handle to a local variable. This is retrofitted to V3.2. ECO E 12-Jul-1995 VAX and AXP Images: UCX$CFS_SHR.EXE UCX V3.2-9E o Problem: Reading a fixed, sequential file which has an incomplete last record resulted in the loss of the partial record. This fix removes the application of a previous fix from ECO A as it pertains to sequential files containing fixed length records. Solution: Remove the FAT$C_FIXED from the case statement and add in the support for FAT$C_VFC. --------------------------------------------------------------------------- Fixes for DEC TCP/IP Services V3.2 PCNFSD --------------------------------------------------------------------------- ECO 1 Updates: -------------- ECO A 8-Dec-1994 VAX and AXP Images: UCX$PCNFSD.EXE UCX V3.2-9A 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 on the form of [SPOOLDIR.host.domain1/domain2]. Failure occurred during the attempt 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: Code appending the random number was moved. 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: IBM is a registered trademark of International Business Machines. Macintosh is a registered trademark of Apple Computer, Inc. PostScript is a registered trademark of Adobe Systems Incorporated. UNIX is a registered trademark licensed exclusively by X/Open Company Ltd.

This patch can be found at any of these sites:

Files on this server are as follows:

ucxeco8-032.README
ucxeco8-032.CHKSUM
ucxeco8-032.CVRLET_TXT
ucxeco8-032.a-dcx_axpexe
ucxeco8-032.a-dcx_vaxexe