Release Notes
for the
VMS/ULTRIX Connection Version 1.2
The VMS/ULTRIX Connection, Version 1.2 contains the following major
functional enhancements:
o Support for the Telnet client and server
o Support for the rlogin server
o Support for the BSD socket programming interface
o Support for DECwindows TCP/IP
The Release Notes are organized as follows:
o Installation
o New Features and Functions
o Problems Corrected
o Restrictions
NOTE
There is no Version 1.1 of the VMS/ULTRIX Connection.
This release (Version 1.2) is a maintenance and
functional update release.
1 INSTALLATION
The following changes have been made to the installation process for
this field test of the VMS/ULTRIX Connection:
o The number of global pages necessary for the Connection
software to function properly has increased from 650 to 1375
global pages.
o The number of global sections necessary for the Connection
software to function properly has increased from 10 to 15.
o The installation procedure checks if the system has enough
global pages and global sections. If not, it instructs the
system manager to increase them.
o A shared message file has been created, containing the
Connection error messages from its various facilities. This
file is copied into SYS$MESSAGE during the installation. The
Page 2
message file is installed as a shared image when you start up
the Connection.
You can access the error message file by entering the
following command:
$ SET MESSAGE SYS$MESSAGE:UCX$MSG.EXE
o During the installation, QIO programming and IPC (socket
interface) programming examples are copied into
SYS$EXAMPLES:[UCX].
2 NEW FEATURES AND FUNCTIONS
This section includes information on new VMS/ULTRIX Connection
features and functions. Information on the following Connection
components is included:
o TELNET
o DECwindows TCP/IP
o UCX Management
o Network File System (NFS)
o Internet
o File Transfer Protocol (FTP) Client
o FTP Server
o Interprocess Communications (IPC)
2.1 TELNET
Support for the TELNET client and server has been added. For more
information, see the VMS/ULTRIX Connection System Manager's Guide.
2.2 DECwindows TCP/IP
Support has been added to use the TCP/IP of the Connection with
DECwindows. If you will only be using the TCP/IP component of the
Connection to display DECwindows applications on a remote host, you do
not need a PAK.
Page 3
2.3 UCX Management
o There was a restriction in Version 1 on how UCX selected the
ULTRIX file ownership record from the PROXY database for the
CREATE CONTAINER, CREATE DIRECTORY, and IMPORT commands.
The only qualifiers available to control access to the
UCX$PROXY database were /USER_NAME and /HOST.
This could cause a problem in the following situation:
VMS user_name UID GID Host
--------------- ------- ------- --------------
user1 23 10 host1
user2 24 20 host1
In this case, it would not have been possible to select an
ULTRIX identity with a GID of 20.
A /UID qualifier has been added to correct the problem.
A second qualifier, /[NO]LOG, has also been added that
describes which record from the UCX$PROXY database was
accessed in order to establish protection.
o The IMPORT command has been changed to allow users to import
files into container files without requiring SYSPRV or BYPASS
privilege.
If the user has SYSPRV or BYPASS privilege, then the
UCX$PROXY database is accessed with a UID of 1 and a GID of 0
by default. The first record in the database having a UID of
1 and GID of 0 is read, and the VMS user name is used as a
reference for VMS environment information.
If the user does not have SYSPRV or BYPASS, then the VMS user
name is taken from the user_name of the process running
UCX$UCP. The UCX$PROXY database is accessed, and the first
record that has a matching VMS user_name field is read. This
record provides the ULTRIX UID and GID.
SYSPRV or BYPASS is required if the VMS user_name selected
from the UCX$PROXY database is not the same as the VMS
user_name of the process running UCX$UCP.
o The /NOCLUSTER qualifier has been added to the SET INTERFACE
command. This qualifier disables cluster processing.
o Command line recall has been added to UCX$UCP. The last 20
commands are stored, and can be accessed with the up and down
arrow keys.
Page 4
o A SPAWN command has been added to UCX$UCP.
o Wildcard support has been added to the SHOW BIND command.
If you do not specify the file system name or enter it as an
asterisk (*), the characteristics of all bound file systems
are displayed.
Standard VMS wildcarding is supported, and you can specify a
list of file system names to be displayed.
o The /FULL qualifier has been added to the SHOW DEVICE_SOCKET
command.
This qualifier enables you to display the counters for the
device socket.
The default for this display is to provide a brief listing of
device sockets.
o Support has been added to the SHOW DEVICE_SOCKET command for
the following new qualifiers that allow you to specify
classes of device sockets:
- /HOST
This qualifier displays specified device sockets
connected to the specified host.
- /PORT
This qualifier displays specified device sockets for the
specified local port number.
- /SERVICE
This qualifier displays specified device sockets
associated with the specified services.
- /TYPE
This qualifier displays specified device sockets
according to the specified socket type.
See the help file for more information on these new
qualifiers.
o The UCX SHOW DIRECTORY command has been enhanced to include
the file specification.
o The UCX SHOW DEVICE command has been enhanced to include
TELNET and RLOGIN server information.
Page 5
o The following counters have been added:
- Current device sockets in your system
- Peak number of device sockets in your system
You can view these counters (along with other information)
with the UCX SHOW COMMUNICATION command.
2.4 Network File System (NFS)
o Version 1 of the Connection allowed any client host to use
only the name that is registered in the PROXY database for
the communication with the NFS server. Any attempt by the
client host to use a legitimate alias as a host name to
communicate with the NFS server would fail and the following
error was written in the error log file:
"UCX$NFS_NOCMAP - failed to find record in the PROXY data base"
The NFS server now allows a client host to use a legitimate
alias name to mount a file system and access files on the NFS
server.
o Version 1 of the Connection did not accept a client host name
specified as an ASCII string representing its Internet
address in the standard format (for example, 128.0.2.20),
unless this name was registered in the PROXY database.
Now NFS accepts that type of the client host name. In
addition to the regular UCX$NFS_MNTSUC message written into
the error log file, the following new message is displayed
during the mount operation:
"UCX$NFS_NODNAM - Host name in the HOST data base = xxxx"
The NFS server finds the host's official name (using the HOST
database) and includes it in the UCX$NFS_NODNAM message.
o Version 1 of the Connection did not allow usage of the null
names by the client hosts (the client's host name is the XDR
"null" string).
Now the NFS server provides this feature. A client host that
uses the "null" name is considered to be "any" node. For
example, in the PROXY database mounted directory has an
asterisk (*) in the "host name" field, then the "null" named
client host will be able to mount this directory.
However, if the PROXY database specifies that the directory
Page 6
being mounted can be mounted only by the specific client host
(or list of hosts), then the "null" named client will not be
able to mount this file system.
The same rule applies for EXPORT database.
o "Stale" file handle processing has been implemented. This
means that if the NFS server detects that a client host is
using a file handle for a file that is no longer valid, NFS
returns the ESTALE NFS error to the client host. (Previously
the NFS server return a no such file message.) This helps the
client host implement correct cache handling by discarding
its cache instead of using obsolete information.
o The UCX$NFSBFSCAL error message has been enhanced to include
the file specification.
2.5 Internet
o In Version 1.0, to perform a non-blocking I/O operation, you
had to set the socket option NBIO explicitly.
In this release, you can issue non-blocking I/O as a modifier
to the read or write QIOs. Additionally, two I/O subfunction
masks, IO$M_NOW and IO$M_NOWAIT, have been added.
You can specify the IO$M_NOW function mask with the
IO$_ACCESS and IO$_DEACCESS I/O functions. The result is an
I/O operation that does not block. Regardless of a QIO or
QIOW, if the IO$M_NOW mask is set and the system detects a
condition that would cause the IO$_ACCESS or IO$_DEACCESS I/O
operation to block, the system completes the I/O operation
and returns the error code SS$_SUSPENDED.
You can specify the IO$M_NOWAIT function mask with the
IO$_READVBLK and IO$_WRITEVBLK I/O functions. The result is
an I/O operation that does not block. Regardless of a QIO or
QIOW, if the IO$M_NOWAIT mask is set and the system detects a
condition that would cause the I/O operation to block, then
the system completes the I/O operation and returns the error
code SS$_SUSPENDED.
o The minimum value for UDP and TCP read/write byte quota for
device sockets has been set to the size of an Internet
internal data buffer.
Page 7
2.6 File Transfer Protocol (FTP) Client
o FTP help has been enhanced to provide better information.
o Certain FTP error messages have been changed to supply
additional information.
o FTP has been changed to default the user name to lowercase.
This change makes it more likely that you can log in to a
ULTRIX system from a VMS system using the default user name.
o The FTP client's directory display has been improved.
In Version 1.0, the FTP client used the 'putc' function for
its directory display function. Now it uses RMS. This
should significantly enhance the performance of the directory
display.
o Support for putting ASCII files to a line printer has been
added.
o Support for command line recall has been added to the FTP
client's interface.
o During file transfer, files are opened in non-sharing mode.
o The QUOTE command has been added to FTP client's user
interface.
o The host_name parameter has been added to the FTP DCL verb.
This parameter enables you to enter a host name on the
command line at the DCL level.
2.7 FTP Server
o The FTP server has been enhanced to abort control connections
that have been idle for 15 minutes.
o The FTP server has been enhanced to disallow logging in to a
captive account.
o In Version 1.0, users could still login into the system after
logins were disabled with the SET LOGIN/INTERACTIVE=0 FTP
SERVER command.
This has been fixed. The FTP server will not allow a user to
following conditions:
- The user's account is disabled
Page 8
- The user's account is a captive account
- The user does not have network access privileges
- System logins are disabled
2.8 Interprocess Communications (IPC)
Gethostbyname and gethostbyaddr return a list of addresses in
the hostent structure to comply with ULTRIX's 4.3BSD. If you
are running VAX C Version 3.0, you must modify the hostent
structure of the netdb.h file as follows:
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses from name server */
#define h_addr h_addr_list[0] /* address, for backward compatibility */
};
3 PROBLEMS CORRECTED
This section provides information on problems that have been corrected
since the last release of the VMS/ULTRIX Connection. Information on
the following Connection components is included in this section:
o UCX$HOST database
o Network File System (NFS)
o Internet
o File Transfer Protocol (FTP) Client
o FTP Server
3.1 UCX$HOST DATABASE
In Version 1.0, you could not define a host that had more than one
Internet address with the UCX SET HOST command. This restriction has
been lifted in this version.
If you want to define multiple Internet addresses for a single host
name, you must convert your present UCX$HOST database. If you do not
Page 9
need support for multiple Internet addresses, then no conversion is
required.
To convert the file, you must perform the following steps using the
UCX CONVERT command. Using the following procedure enables you to
convert the UCX$HOST database without interrupting active Internet
services.
1. Execute the UCX CONVERT/ULTRIX HOST ETC.HOSTS command. If
you would like to see the results of the conversion, specify
the /LOG qualifier. Note, that if you have an up-to-date
etc/hosts formatted file, you don't have to do this step.
2. The system logical name for UCX$HOST must translate to the
latest version of the UCX$HOST database. For example,
SYS$COMMON:[SYSEXE]UCX$HOST.DAT;1. If the current value does
not include the version number, redefine the system logical
name to include the file's version number. For example:
$ DEFINE/SYSTEM UCX$HOST SYS$COMMON:[SYSEXE]UCX$HOST.DAT;1
This step converts your current UCX$HOST database to a file
with the name ETC.HOSTS. This file is an ULTRIX formatted
/etc/hosts file in YP format. The file is placed in your
current directory.
3. Define a process logical name for UCX$HOST that has the value
SYS$COMMON:[SYSEXE]UCX$HOST.DAT. Do not specify a file
version number. For example:
$ DEFINE UCX$HOST SYS$COMMON:[SYSEXE]UCX$HOST.DAT
This process logical name is used to name the new UCX$HOST
database. It is only accessible from your process.
4. Execute the UCX CREATE HOST command.
This command creates a new UCX$HOST database with 1 entry for
localhost. It's created with a file name specified by your
UCX$HOST process logical name.
5. Execute the UCX CONVERT/VMS HOST ETC.HOSTS command. If you
would like to see the results of the conversion, then specify
the /LOG qualifier.
This command reads the ETC.HOSTS file, created in step 1, and
uses it to populate your newly created UCX$HOST database.
6. Redefine the SYSTEM logical name for UCX$HOST to be the file
name of the latest version of the UCX$HOST database. For
this example, the value would be
SYS$COMMON:[SYSEXE]UCX$HOST.DAT;2, as follows:
$ DEFINE/SYSTEM UCX$HOST SYS$COMMON:[SYSEXE]UCX$HOST.DAT;2
At this point, the conversion is complete. Redefining the
system logical name enables all UCX users to access the newly
converted UCX$HOST database. You do not have to stop and
Page 10
restart the Internet software to perform this step.
If you are unsure as to what the version number of the new
UCX$HOST database is, perform a DCL DIR UCX$HOST command.
3.2 Network File System (NFS)
o The MTIME attribute is now correctly returned to the client
when the file is not accessed by the server. This was
previously reported as ATIME.
o ATIME is now properly returned to the client, and reflects
the most reasonable last access time that performance will
allow.
o Version 1.0 allowed certain NFS client implementations to
supercede an existing directory, thereby losing all the files
contained therein.
This has been fixed. Any attempts to create a directory with
the same specification as one that already exists return an
error message.
o In Version 1.0, a SUN client that cached a directory could
return obsolete directory entries (or fail to return new
ones) to its users. This could occur because of the
following:
- On a VMS system, the times on a directory file are not
updated as the directory is modified.
- The NFS ATIME, CTIME, and MTIME for directory files were
returned to the client as the current server time.
This has been fixed. In this release, the current server
time is returned for any VMS directory, flushing the contents
of the client's cache.
o In Version 1.0, if the NFS server received an RPC message
that violated RPC protocol format, the server replied with an
appropriate message to the client, but did not post a receive
QIO to the Internet driver. This caused NFS to stop
receiving requests when improperly formatted RPC messages
were introduced by client hosts. A visible sign of this
situation is an absence of the "wait" state on the "RCV buff"
option in the UCX SHOW DEVICE BGxx display.
NFS now handles improperly RPC formatted messages correctly.
Page 11
o The NFS server was logging incorrect information in the error
log file in the following situations:
- When the NFS server was shutting down
- When the NFS server encountered an Internet QIO failure
This has been changed so that the NFS server now logs the
correct information into the error log file, including the
port or channel number of the failed QIO operation.
o In Version 1.0, NFS would exit with ACCVIO when the client
host issued an RPC message with an authentication type
AUTH_NULL.
The server was changed to reject usage of AUTH_NULL with A
"AUTH_TOOWEAK" error message to the client for all operations
but NFSPROC_NULL.
o In Version 1.0, an exception error would cause the NFS server
to loop indefinitely.
This has been fixed. Now, when NFS detects an exception
error, it is logged to the error log file and and NFS
terminates.
o The NFS server error counter in the server information
display (UCX SHOW NFS) was used as an "event counter" rather
than an "error counter". For example, it was incremented
even for mount and dismount messages.
This has been changed. The server error counter is
incremented only if errors are logged in the error log file
record.
o In several cases the NFS server would abort under non-fatal
conditions (such as errors reading an export file record).
This has been fixed.
o Under some conditions, the NFS server erroneously returned
incorrect error messages to the client following a failure in
the file access operations.
This has been fixed. The server now returns the correct
error code.
o In Version 1.0, the NFS server returned incorrect information
to the client when replying to the read request. In certain
cases, NFS would return a value of "nobody" in the file's
owner identity attribute field.
This error was demonstrated on systems running ULTRIX Version
3.1 and PMAX Version 3.0. On these systems, the error would
Page 12
occur when the client was using the NFS server to read data
from a file residing on VMS.
This has been fixed. Changes have been made to the
VMS-to-UNIX ownership-mapping algorithm to provide the
correct file's owner identity in the reply message.
o In Version 1.0, an incorrect implementation of the access
permission made it possible to mount a directory that is
read-protected.
This has been fixed. Now a read-protected directory cannot
be mounted by the client.
o In Version 1.0, to look into the NFS error log file
(SYS$MANAGER:UCX$NFS_LOGFILE.DAT) you had to invoke the UCX
utility to disable error logging (UCX SET NFS/DISABLE=ERROR)
to be able to read the error log file. Then, you would have
to enable it again (UCX SET NFS/ENABLE=ERROR) to make the
error log file available for writing by NFS.
This has been changed. You can now look at the file using
the VAX Language-Sensitive Editor (LSE) without disabling
error logging.
o In Version 1.0, NFS could provide incorrect file owner
information under certain circumstances.
This has been fixed.
o The file system creation routines now accept the NFS ATIME
and MTIME file attributes on file and directory creation.
This problem was seen during testing with a few non-standard
implementations of NFS clients.
o Directory files on VMS file systems now always return the
various file attribute times as the current time. This is
done to compensate for the fact that VMS does not maintain
these times in a fashion consistent with the needs of NFS.
This corrects problems specifically where NFS clients use a
directory's timestamps to make decisions, the most common
being a directory and file-name or file-handle client cache.
o The CFS SUMMARY screen of the UCX utility (UCX SHOW
CFS/SUMMARY) has been updated. The screen now includes a
subtotal of file system QIO counters, used to determine the
affect the performance of the VMS file system has on the NFS
server (and the demand which the NFS server is placing on the
VMS file system). In addition, the resource counters at the
lower right of the screen are now updated and displayed.
These fields are documented in the documentation set.
o In Version 1.0, the geometry and sizes of the various CFS
file systems as returned by the NFS STATFS request were
reported in such a fashion so as to be displayed correctly by
Page 13
ULTRIX clients, but not by SUN (and possibly other) clients.
This has been corrected in both the Connection and in ULTRIX
Version 3.1.
o In Version 1.0, the file system did not consider the disk
device's ACL when attempting to access a file on the volume,
whether it be in the VMS or the ULTRIX file systems within
UCX.
It is important that the side-effects (i.e. apparent
inconsistent behavior) of using ACLs be fully understood.
Since ACLs are not part of the NFS protocol, they cannot be
passed between the client and the server. The server may
therefore either grant or deny access to a file based on the
ACL. This appears to be inconsistent in that under NFS rules
the files would or would not be accessible based purely on
the owner and the mode (protection mask).
Device ACLs are now supported. It is important to note that
the NFS client still protection checks all accesses using the
file's UID, GID, and mode, even if the server grants access
to the file.
o In Version 1.0, the NFS CREDIR request was rejected with a
privilege error when attempting to create a VMS directory
whose name had an explicit file type.
This has been corrected to accept a file type of `.DIR'
(upper and/or lower-case), but no version number. The VMS
file systems now permit directory files to be created with a
file type. This makes such commands as `cp -r' to VMS file
systems (that would fail in Version 1.0) permissible.
o File EOF (END-OF-FILE) checking problems have been corrected.
Under certain odd circumstances, end-of-file errors have been
returned in the NFS log file. These errors are returned as
NFS I/O errors to the client.
o Locking problems that most often resulted in messages being
logged to the operator have been corrected. The problem,
discovered in the file data cache handling routines, was
related to a race condition in the asynchronous file system
which resulted in the creation of duplicate data structures
which describe the cache buffers. The cache routines would
attempt to release (unlock) the incorrect duplicate,
resulting in messages to the operator and often unpredictable
file system behavior shortly thereafter.
o Sparse writes to data files now initialize the unwritten
portions of the file data to NULLs. When the end-of-file
mark of a file is advanced in such as way as to create
unitialized `holes' in the file, in Version 1.0, the
Connection did not initialize these `holes' as ULTRIX does.
This assumption would lead users to believe that their files
Page 14
were corrupt, believing that the data was improperly written,
when in reality it was not properly initialized.
o Problems where VMS files appeared to be owned by someone else
(another concurrent accessor) have been corrected. This
problem is seen for short periods of time, after which they
appear to correct themselves. During the period of time when
their ownership is incorrect, the files are most often
inaccessible, but this clears when the NFS server actually
deaccesses the file.
o In Version 1.0, files on VMS would often have an imperfect
set of attributes. An error in the attributes handler would
set the file's MAXREC (RMS MRS) to 32767 on writes, when it
was intended to set the RSIZE (RMS LRL) to 32767 and the
MAXREC (RMS MRS) to zero. This has been corrected. Also,
note that as in Version 1.0, VMS file attributes of
pre-existing files are not changed to SEQUENTIAL, STREAM_LF
unless the file is truncated to a size of zero.
o The file system BIND routine has been changed to set the
protection of the two file system logical name tables
correctly. These tables, UCX$CFS_FILESYSTEM_DIRECTORY and
UCX$CFS_PATHNAME_DIRECTORY contain the BIND definitions
needed to translate base pathnames and file-handles back and
forth as needed. The protections are now set to SYSTEM:RWED,
OWNER:RWED, GROUP:R and WORLD:R.
o An inconsistency between the ULTRIX and VMS handing of file
attributes with respect to file protection has been
corrected. VMS requires that a user have READ access to a
file to be able to read its attributes. ULTRIX does not.
The file system code has been changed to allow the attributes
of files to be read without the need to have access to the
file, thereby making it behave as it does in ULTRIX. Note
that this does not create any security problems in that
access to a file's attributes does not provide access to a
file's data. To access the file's data, the user must obey
VMS protection rules.
o In version 1.0, an NFS CREATE from certain vendors' clients
implemented the NFS CREATE operation for all forms of CREATE;
including the `creat(2)' functionality which will truncate
and re-use a file if it already exists. However, the UCX
file system code was incorrect in that it would overwrite the
file's ownership (UID and GID) and change the mode of the
file even though that is not the intention of a truncate
operation. In the ULTRIX file system within UCX, this error
would also change special files into regular ones, making
them no longer special.
These problems around the supercession (re-creation over
existing files) have been corrected.
Page 15
o In V1.0 the server would allow the client to cross the mount
point, although it would still protection check all access to
files above that point.
This has been fixed. Mount points now have an additional
level of security in that they disallow clients to cross the
server's mount points by using the NFS LOOKUP call to find
".." in the mount point directory.
o In Version 1.0, the NFS server had a problem creating links
to special files within the ULTRIX file system. Under
certain circumstances the process would exit.
This has been fixed.
o In Version 1.0, certain positioning errors within a VMS
directory would make files `dissappear', in that they were
not returned by the NFS READDIR response. The problem would
often manifest itself in an attempt to delete a directory
which would appear to be empty, but which the server would
insist is not empty when the client attempts to delete it.
This has been fixed.
o In Version 1.0, a problem with the ULTRIX file system code
would cause a process to terminate, if the container file's
volume ID check fails. Since the container records VMS file
IDs as the mechanism to access the actual files in the VMS
namespace, the container would also record the volume label
as a quick check to determine if the FIDs are properly
matched to the volume what the file system is on. When the
file system code detected a mismatch, it would force the
process to exit in EXECUTIVE mode.
This has been corrected. Note that as documented, the
movement and/or modification of an ULTRIX file system by any
means other than through the UCX utilities or NFS server
requires that the file systems involved be verified and
updated by using the `UCX ANALYZE CONTAINER/REPAIR' command.
o Special files within the ULTRIX file system cannot be copied
(via the UCX EXPORT command) from an ULTRIX file system
because the files are not real VMS files. The ULTRIX file
system maintains VMS files for directories and regular files
only. Special files (character and block), named pipes
(FIFOs), and symbolic links are implemented purely within the
ULTRIX file system's container file. As a result, it is not
possible to export any of these files.
In Version 1.0 the error returned was `no such file'. The
error message has been changed to `invalid media format', to
indicate that such files do not have a VMS equivalent format
and therefore cannot be exported.
Page 16
3.3 Internet
o In Version 1.0, an I/O operation involving a 'socket address
structure' as an input parameter could fail with SS$_BADPARAM
if the last 8 bytes of the socket address structure were not
NULL.
This has been changed. The last 8 bytes of the socket
address structure are now ignored.
o In Version 1.0, the IO$_DEACCESS!IO$M_SHUTDOWN (shutdown)
accepted any value for the shutdown parameter although it
ignored all bits except bits 0, 1, and 2.
This has been changed. Only valid values are allowed for the
shutdown parameter (defined by the SYS$LIBRARY:UCX$INETDEF.*
files). The error SS$_BADPARAM is returned, if the value is
invalid.
o In Version 1.0, the IO$_ACCESS (connect) on a UCX$C_STREAM
(TCP/IP) socket returns an SS$_BADPARAM error if the socket
is not bound to an Internet address and port.
This has been fixed. When the 'connect' is issued to an
unbound socket, the system performs a 'default bind',
associating the socket with the local host and a random port
number.
o In Version 1.0, the system could 'bugcheck' - crash - if a
transmit operation was attempted with an ICMP packet larger
than the maximum size of an IP datagram fragment (1500
bytes). This could happen in particular with ICMP
'echoreply' packets.
This has been changed. The IP fragmentation routine now
accepts fragmentation of ICMP datagrams larger than the
maximum IP fragment size.
o In Version 1.0, IP datagrams could be be dropped as
invalid-length datagrams if the IP datagrams where received
as Trailer protocol packets and the data buffers in which the
datagrams where received had certain boundaries. If this
situation occurred, the IP datagram counter would be in
error, since the counter is incremented with each dropped
datagram.
This has been fixed. IP datagrams packets are no longer
dropped in this situation.
o In Version 1.0, the VMS host that sent an IP or UDP/IP
broadcast packet did not receive that packet.
This has been changed. The sending VMS host always receives
the IP or UDP/IP broadcast packets that it sends.
Page 17
o In Version 1.0, a IO$_READVBLK or IO$_WRITEVBLK I/O operation
ignores the UCX$C_MSG_OOB flag (read or write out-of-band
character). The work-around was to use the IO$M_INTERRUPT
flag instead of the UCX$C_MSG_OOB flag.
This has been fixed.
o In Version 1.0, the system could crash when a $QIO with the
IO$_SETMODE function was issued to set or get socket options
that are not kept in the options field, and the specification
of the value or its memory location when invalid.
This has been fixed.
o In Version 1.0, the system could crash when a $QIO with an
IO$_SENSEMODE function was issued with the UCX$C_IOCTL option
that specified the SIOCGIFCONF command.
This has been fixed.
o In Version 1.0, the last bytes of a stream could be lost when
a TCP/IP connection was closed under the following
conditions:
- The connection was not marked to linger
- The last bytes of the stream were not sent to the remote
host before the close
This could happen because the last bytes of the stream were
sent in the same segment with the RST flag.
This has been fixed.
o In Version 1.0, the system could crash when a $QIO with an
IO$_WRITEVBLK, if P3 specifies an invalid descriptor or
invalid buffer address.
This has been fixed.
o In Version 1.0, a 'connect' operation on a socket bound to
UCX$C_INADDR_ANY (wildcard host) could time out on a VMS host
that is a member of a VMS cluster in which the Internet
cluster is enabled. The socket in such a case is bound to
the 'cluster_name'.
This has been changed. On a host that has a cluster alias
enabled, a socket that binds to 'UCX$C_INADDR_ANY' appears
bound to the VMS host name and not to the VMS cluster alias.
As a result, the host no longer hangs. In Version 1.0, on a
VMS host that had more than one interface,
o In Version 1.0, a bad UCB link could cause the system to
crash with a memory access violation, if the Internet maximum
Page 18
IRP number is reached. The IRPs are internally used by the
Internet software to process I/O requests. Normally if your
system is processing an high number of Internet I/O requests
and the maximum number of IRPs is reached, the current I/O
request is put in a wait state until an IRP is released.
This has been fixed.
3.4 FTP Client
o In Version 1.0, FTP was incorrectly setting the resultant
file's attributes for image transfers to variable-length
records instead of fixed-length records.
FTP has been modified to create files with fixed-length,
512-byte records when image transfers are active, if a /FDL
switch is not specified.
o In Version 1.0, FTP incorrectly set the command line
processing mode to ULTRIX if you switched to VMS command line
processing and subsequently issued a HELP command.
This has been fixed.
o In Version 1.0, sometimes FTP error messages could be
overwritten when the ULTRIX-style command interface was used.
This has been fixed.
o In Version 1.0, quoting user-name input was not always
handled consistently.
This has been fixed.
o In Version 1.0, FTP exited with an access violation if an
OPEN command was given without a host name.
This has been fixed.
o In Version 1.0, FTP did not handle CTRL/C interruptions
properly.
This has been fixed.
o In Version 1.0, the FTP client and server would sometimes
fail to read a complete record during asynchronous RMS
operations. This would result in lost data. The problem was
most frequent when transferring very large files of
variable-length, sequential records.
This has been fixed.
Page 19
o In Version 1.0, the FTP client would hang when the server
sent it replies consisting of multiple lines. This problem
was noticed when an IBM server sent multiple replies during
login processing.
This has been fixed.
o In Version 1.0, the FTP client had a problem copying a remote
file to a local file that had a version limit imposed. FTP
would create an empty new version of the file and purge the
oldest version of the file.
This has been fixed.
o In Version 1.0, the FTP client had a problem sending a file
that does not exist to a remote system. In this case, the
client would try to open the nonexistent file after
establishing the data connection. Since the data connection
was established, the server sent the data. However, the
client could not write to the file, because the file didn't
exist.
This has been fixed. The FTP client now checks to see if the
file exists before opening the data connection.
o In Version 1.0, the FTP client did not respond to `Account
ID' requests from the FTP server. This problem was seen when
communicating with certain IBM systems.
This has been fixed. The FTP client now prompts the user for
Account ID, if the server requests it.
o In Version 1.0, you could not use CTRL/Z to exit from a
command parameter prompt.
This has been fixed.
o In Version 1.0, the FTP CDUP command did not work in the
ULTRIX command interface.
This has been fixed.
o In Version 1.0, FTP did not display an error message if you
pulled a file over to a directory to which you had no write
access privileges.
This has been fixed.
o In Version 1.0, the QUOTE command only took one word in the
ULTRIX command interface.
This has been fixed.
o In Version 1.0, FTP would hang at the prompt after issuing a
verbose command in the ULTRIX command interface.
Page 20
This has been fixed.
o In Version 1.0, if you accepted the default for the username
for the 'user' command while using the ULTRIX interface, the
FTP client would crash causing a traceback.
This has been fixed.
o In Version 1.0, if Internet was not active, the FTP client
would and produce an improper error message.
This has been fixed.
o In Version 1.0, if you did not specify a host with the open
command, you received an error.
This has been changed. Now if you do not specify a host with
the 'open' command, the FTP client connects you to the local
host.
3.5 FTP Server
o In Version 1, the FTP server accepted connections from any
active interface.
The server has been changed for V1.2 so that the system
manager can restrict FTP to accept connections only from a
single interface. To enable this feature, define the logical
name UCX$FTP_HOST in the FTP startup command procedure,
SYS$MANAGER:UCX$FTPD_STARTUP.COM.
o The FTP server has been corrected to disconnect a data
connection if a client's FTP session terminates abnormally.
o The FTP server has been corrected not to abort if it receives
illegal commands.
o In Version 1.0, the FTP server did not translate the 'F'
argument of the STRU command properly. As a result, the
command was not acknowledged.
This has been fixed.
o In Version 1.0, using the RENAME command caused FTP to hang.
This has been fixed.
o In Version 1.0, FTP server replies did not comply with RFC
959.
This has been fixed.
Page 21
o In Version 1.0, the FTP server would not accept a null
password.
This has been fixed.
4 RESTRICTIONS
The following restriction for NFS applies for Version 1.2 of the
VMS/ULTRIX Connection:
o There is a problem in the ULTRIX V3.1 diskless node software
that causes mount operations from /etc/fstab to fail when the
server is running the VMS/ULTRIX Connection software.
To avoid this problem, Digital recommends that you not
include any VMS/Ultrix Connection filesystems in the
/etc/fstab file. Include separate mount statements at the
end of the /etc/rc.local procedure to mount all filesystems
that are served by the VMS/ULTRIX Connection software.