Concurrent Computer Corporation
CXUX 7.1 Release Notes
CXUX_7.1 Products are:
cx_7.1 gdb_7.1 ix25_7.1 svvs_tests_7.1
cx_rt_7.1 gpib_7.1 nfs_7.1 vsx_tests_7.1
dr11w_7.1 hc_7.1 osi_lan_7.1 vt_7.1
================================================================================
CX/UX -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
CX/UX Release 7.1 is a complete new release of the CX/UX
operating system and its optional products. It requires a
complete regeneration of your system. This release
incorporates major system changes and support for new
products.
Please read this entire document and all applicable optional
product release notes before you proceed with the
installation.
The CX/UX Release 7.1 package contains a minimum of two
magnetic tapes: (1) a boot tape marked boot/miniroot, and
(2) a products tape marked products. Each tape is described
briefly in the next two paragraphs.
1.1 Boot/miniroot tape
The boot/miniroot tape is in dd format and contains two
partitions separated by a tape mark. One partition contains
the bootstrap file system, and the second partition contains
the miniroot file system. With the bootstrap file system,
you can format disks and copy files from tape to disk. The
miniroot file system contains a portion of the operating
system and utilities needed to boot the system.
__________
- These release notes cover the following products: cx
- 1 -
CX/UX 7.1 Release Notes
1.2 Products tape
This tape is in cpio format and contains the root, /usr, and
/var file systems plus optional products if purchased. The
root files, /usr files, /var files, and optional products
can be supplied on more than one distribution tape,
depending upon the total number of products.
Together with each distribution tape is a list of products
contained on each distribution tape.
- 2 -
Release Notes 7.1 CX/UX
2. Documentation
The following chart lists the documentation included with
the CX/UX Release 7.1 system:
___________________________________________________________
| Manual Name Pub. Number|
|____________________________________________|_____________|
| CX/UX System Administration Manual | 0890108-110|
| CX/UX Version 7.1 Release Notes | 0890108-7.1|
| CX/UX User's Guide | 0890112-030|
| CX/UX Support Tools Guide | 0890113-060|
| CX/UX Programmer's Guide | 0890114-070|
| Introducing UNIX System V | 0890184-000|
| CX Documentation Roadmap | 0890273-060|
| (KSH) KornShell Release Notes | 0890352-6.2|
| CX/UX POSIX (1003.1) Conformance Guide | 0890361-040|
| Night Hawk Documentation Overview | 0890377-010|
| GDB Documentation Set | 0890393-010|
| CX/UX Release 7.1 Readme First Instructions| 0890440-000|
| CX/UX Harris C Reference Manual | 0891019-060|
| Release 7.1 Summary Information | 0891056-000|
|____________________________________________|_____________|
Additional copies of documentation can be ordered by
contacting the Harris Software Support Center. The toll-free
number for calls within the continental United States is 1-
800-245-6453. For calls outside the continental United
States, the number is 1-305-971-6248.
Customers are encouraged to use the CX Documentation Roadmap
Manual and the Night Hawk Documentation Overview Pamphlet to
get an overview of all the Night Hawk documentation that is
available. An on-line list of manual names and
corresponding publication numbers can be obtained by using
the "man manual" command.
Hardcopy manual pages (man pages) are no longer provided.
However, man pages continue to be available as on-line
documentation. Refer to the section on manual pages in this
document for information on how you can print on-line man
pages. Selected man pages are provided in the CX/UX System
Administration Manual in the event that on-line man pages
cannot be viewed due to system problems.
Certain operating system features that are common to both
the CX/UX and the CX/RT kernels are designed to increase the
determinism and predictability of the operating system and
- 3 -
CX/UX 7.1 Release Notes
improve the process dispatch latency for high-priority
tasks. These features are described in the Real-Time
Documentation Set (0890285). They may be of interest to
real-time users who do not purchase the CX/RT product.
Users may order the Real-Time Documentation Set separately.
In general, release notes are provided with software
products. The release notes you receive will be at the
software revision level at which the associated product last
changed.
- 4 -
Release Notes 7.1 CX/UX
3. Prerequisites
Any prerequisites, if applicable, for running CX/UX Release
7.1 are described in sections 3.1 and 3.2.
3.1 Hardware Prerequisites
Any Series 4000 or Series 5000 system.
Note: Computer series written as "Series 4000-5000" refers
to all Series 4000 through Series 5000 hardware
systems or platforms.
3.2 Software Prerequisites
None.
4. Installation
4.1 Pre-Installation
The installation procedure for CX/UX Release 7.1 replaces
the current contents of your root, /usr, and /var
partitions. You should save any files currently in these
directories that you don't want lost. For example, save:
1. any files which you have modified locally,
2. files which are not distributed by Harris on the
distribution tape,
3. any files which belong to products that are not a part
of the CX/UX Release 7.1 release.
Note: Harris recommends that you back up your /, /usr, and
/var file systems using fdump(1M). You can use
either cpio(1) or tar(1) to perform the backup. The
files you save are to be restored to their original
location after the installation of CX/UX Release 7.1
is completed.
4.2 Installation Procedure
Please refer to the CX/UX System Administration Manual,
Chapter 3, for specific software installation instructions.
- 5 -
CX/UX 7.1 Release Notes
4.3 Post-Installation
After the CX/UX Release 7.1 installation procedure is
completed, proceed to:
1. selectively restore any or all of the previously saved
files.
2. merge any files which contain local modifications. You
should NOT use your locally modified CX/UX 6.2 or
earlier version of any file without merging in the
changes from CX/UX Release 7.1.
3. You should restore any files which are not distributed
by Harris. You should also restore any files belonging
to products which are not a part of the Release 7.1
release.
The setup(1M) program generates a log of products installed
on the system. The log file is located in
/usr/src/PRODUCTS/loaded. It contains the product name, the
revision level of the product, the date it was installed,
and the directory it was installed under if not /.
When optional or updated products are installed at a later
date they are appended to the log, providing a quick
reference as to which software is on the system and at what
revision level the software was installed.
Some optional products have additional installation
requirements. Please review the installation instructions
in all release notes before using setup.
4.4 Disk Partition Sizes
Each release of CX/UX includes new software in the root,
/usr, and /var partitions. Partition sizes that were
appropriate in earlier releases may not be sufficient for a
new release. Before attempting to load new software
products, the administrator should check the disk
requirements to verify that existing partition sizes are
adequate for the products that are to be installed.
CX/UX Release 7.1 kernel changes require a larger amount of
swap space than previous releases. Swap space ordinarily
comes from a set of disk partitions set aside for this
purpose. Exactly one partition must be named in the
kernel's configuration file for use during the boot process.
The remaining partitions are usually named by the swap -f
- 6 -
Release Notes 7.1 CX/UX
command that is executed by the /etc/rc script when the
system enters multi-user mode. In multi-user mode a system
should have at least as much swap space as it has primary
memory, and, in the absence of any knowledge about a
particular system's workload, Harris recommends twice as
much swap space as primary memory.
Some file systems, particularly the /var file system, grow
during daily usage. The system administrator must determine
the amount of space needed for future growth in each file
system, and then add that amount to the specified
requirements. Furthermore, the administrator should assume
that the disk space requirements will continue to increase
in future releases.
Some optional products may be installed in partitions other
than the default root, /usr, and /var partitions. Doing so,
as described below and in the product release notes, will
reduce the disk space requirements of the master pack.
4.5 Installation Cautions
4.5.1 Placement_of_the_/var_Directory
The setup(1M) command of CX/UX Release 7.1 can be directed
to put the /var directory tree in any one of three places:
1. physically within the /usr file system. Using this
option, /var is created as a symbolic link to /usr/var.
This option is most useful when re-installing CX/UX
onto an already existing master pack.
2. on a third partition (which must have been created
previously using format(1M)). When this option is
used, /var is mounted automatically during each boot.
This option is recommended when installing CX/UX onto a
new master pack.
3. on the root partition. Although the most
straightforward of the three choices, this option is
not recommended due to the root partition often being
small.
System administrators must decide where to put /var when
formatting the master disk or, at the latest, before running
setup(1M). See the CX/UX System Administration Manual,
Chapter 3, for details. Whichever file system holds the
/var directory structure must have enough free disk space
for accounting files, log files, spool files, and temporary
- 7 -
CX/UX 7.1 Release Notes
files.
4.5.2 Optional_Products_in_Alternate_Partitions
Systems with small master packs may find it impossible to
load their entire set of optional products in the default
root, /usr, and /var partitions. Certain products,
specifically the xwindows-v11 product and forthcoming
releases of NightView and NightTrace, allow for installation
in alternate partitions.
If you wish to install an optional product in an alternate
location, follow these steps:
1. Review the installation procedures described in the
release notes for the product.
2. Select or create an appropriately sized disk partition.
Partition size information is distributed with the
release tapes and may also be obtained by running the
setup command (without asking setup to load the
product).
3. Mount the partition. Harris recommends subdirectories
of /opt as convenient mount points for optional
products. For example, a partition that will be used
to hold the xwindows-v11 product might be mounted at
/opt/X11. (Remember to mount /, /usr, and /var also.)
4. Change the current directory to the directory where the
product is being installed, for example /opt/X11.
5. Use cpio to obtain the setup command from the release
tape, and run the setup command as usual.
6. Perform other installation procedures as required for
the product, as described in its release notes.
Usually, this will involve running an installation
script.
4.5.3 Latest_Release_of_Optional_Products
Although a product's release level may not have changed with
respect to what a customer is currently using, the customer
is strongly encouraged to use the latest version of the
"shipped" product's object indicated on the products
tape(s). The latest object of a given product should be
used for the following reasons:
- 8 -
Release Notes 7.1 CX/UX
o It has the latest bug fixes incorporated in it.
o It was compiled with the latest versions of the
compilers.
o It was linked with the latest versions of the system
library routines that are used by that product.
o It takes advantage of the latest system services
available in the most recent kernel.
5. Cautions
The following list summarizes the more salient points
discussed in this document. Be sure to read this entire
document to become familiar with all the notes and remarks
that apply to this new release of the CX/UX operating
system.
1. The file system structure provides only a small number
of commands in the root partition. Consequently, very
little can be done until the /usr and /var file systems
are mounted. The /sbin directory contains only those
commands that are helpful in mounting these file
systems.
2. ELF is now the default environment. (See sections 6.3
and 6.4 under ELF.)
3. The capability of creating COFF files may not be
supported in future CX/UX releases. Users should
convert their object files to ELF files. (See section
6.4 under COFF.)
4. The OCS environment should be used when linking and
building programs with 88open compatible compilers
and/or libraries. It may not be supported in future
releases. (See section 6.4 under OCS.)
5. The swap space requirement for CX/UX Release 7.1 is
larger than that for CX/UX Release 6.2. (See section
6.5 last three paragraphs.)
6. COFF programs are link-edited, by default, with the
address space starting in page 16. (See section
7.1.2.)
- 9 -
CX/UX 7.1 Release Notes
7. It is recommended that users recompile applications
that use POSIX.4 interfaces with the libraries in the
current release. (See section 7.3 and also 7.3.3.)
8. The default placement of shared memory shmat(2)
segments and usermap(2) segments in the address space
has changed in this release. (See section 7.6.7 and
7.6.9.)
9. Several routines used by device drivers were changed in
CX/UX Release 7.1. (See section 7.10.)
5.1 Kernel Builds
It is necessary to build kernels as COFF executables. If
you login as root, the SDE_TARGET environment variable is
automatically set to COFF. If, however, you su(1) to root to
build a kernel, you must set and export SDE_TARGET=COFF
before building the kernel. If you fail to do this, the
kernel will not link. To correct the problem if this
happens, do a full config(1m) and make(1) to clean up the
inappropriate files.
5.2 Future Support
Several real-time interfaces that are unique to CX/UX may no
longer be supported in the next major release. In each
case, an alternative POSIX.4 interface is available that
provides the same functionality. Applications that desire
portability to the next major release should be converted to
use the POSIX.4 interfaces.
The interfaces that may be dropped include:
o Harris asynchronous I/O:
aread(2)
awrite(2)
await(2)
acancel(2),
o Harris binary semaphores:
bsemget(2)
bsemfree(2)
bsemwait(2),
bsemwakeup(2)
lockbinsem(3C)
unlockbinsem(3C)
- 10 -
Release Notes 7.1 CX/UX
clockbinsem(3C).
6. New Features in this Release
6.1 Shared Objects and Dynamic Linking
CX/UX Release 7.1 provides shared objects and dynamic
linking. In previous CX/UX releases, programs were
statically linked. With static linking, the link editor
provides a program with all of the code and data it needs to
begin execution. With dynamic linking, only a portion of
the code and data is provided to a program by the link
editor. The remainder of the code and data that the program
requires is available through shared object files and is
dynamically linked into the program's virtual address space
during execution of the program. Dynamic linking provides
three main benefits over static linking.
o The on-disk image of the executable program is smaller,
resulting in disk space savings.
o The code in shared objects is shared among multiple
processes that use that shared object, resulting in
overall systems memory savings.
o A shared object can be updated without having to
recompile the programs that use it.
However, dynamic linking does impose a performance penalty
on running programs because of the use of position-
independent code. How severe the penalty is depends upon a
variety of factors, including the frequency of references to
shared object code, the locality of referenced routines, and
other characteristics of the program.
A new ldd(1) command lists the path names of all shared
objects that would be loaded as a result of executing a
program.
Dynamic linking is not restricted to the dynamic linker. The
system shared object libdl.so provides functions that an
application can use to dynamically link and unlink shared
objects during program execution.
For more information on dynamic linking, static linking, and
shared objects, refer to the CX/UX Support Tools Guide.
- 11 -
CX/UX 7.1 Release Notes
6.2 New Shared Objects
The file /usr/lib/libc.so.1 is the system program
interpreter for dynamically linked programs. This shared
object contains the dynamic linker and commonly used C
library routines.
The file /usr/lib/libdl.so contains user-callable functions
for dynamically linking and unlinking shared objects. The
functions are:
dlclose(3X)
dlerror(3X)
dlopen(3X)
dlsym(3X)
Refer to the man pages for more information.
6.3 ELF and DWARF File Formats
Previous CX/UX releases provided an object file format
called COFF (Common Object File Format). CX/UX Release 7.1
provides a new object file format called ELF (Executable and
Linking Format). ELF files are necessary to accomplish
dynamic linking. While SVR4 uses ELF as a replacement for
COFF, this release of CX/UX supports both object file
formats.
Like COFF files, ELF files specify the contents of object
files and provide information about sections, relocations,
and symbols. ELF files provide additional information about
segments. Core files created during the execution of ELF
programs are themselves ELF files.
Unlike COFF files, the symbol and string tables of ELF files
provide link-time information only. ELF files do not
automatically provide information needed during symbolic
debugging. To overcome this deficiency, CX/UX Release 7.1
adopts the DWARF de facto standard for symbolic debugging
information. DWARF symbolic debugging information is placed
into ELF files when compilation is done with the appropriate
option (e.g., -g for the C compiler). The gdb(1) and
NightView(1) debuggers use DWARF information in their
debugging activities. To hide the low-level details of
DWARF from the programmer, a new interface library
/usr/lib/libdwarf.a is provided.
- 12 -
Release Notes 7.1 CX/UX
Just as the libld.a system library provides a user-level
interface to functions which access COFF files, so a new
libelf.a system library can be used to access ELF files.
ELF and COFF files, in general, are not compatible. Tools
that understand and depend upon the format provided in COFF
will require revision if they are to understand and depend
upon the format provided in ELF. Many UNIXO systems do not
support the mixing of ELF and COFF files in an application.
To effect a smooth transition from COFF to ELF, however,
this release of CX/UX provides limited facilities and
mechanisms for accepting both COFF and ELF files in the
development of an application.
Some system processors, such as ld(1), internally convert
COFF object into ELF object while they are executing. A
cof2elf(1) tool can be used to permanently convert a COFF
file into an ELF file. The use of both COFF and ELF files
in a development setting should be restricted to a
transitional mode while converting an application that uses
COFF files into one that uses ELF files. It is recommended
that object files be permanently converted from COFF to ELF
by recompiling them in the ELF software development
environment (discussed in the following section).
Facilities for converting from ELF to COFF are not
available.
For more information on ELF, DWARF, and COFF, refer to the
CX/UX Support Tools Guide.
NOTE: The capability of creating COFF files may not be
supported in future CX/UX releases. Users should convert
their object files to ELF files.
6.4 Software Development Environments
The construction of a software application or piece of code
requires, at the minimum, compilation of the code. Usually,
debugging and other analysis are done on the software and
resulting object files as they evolve into their final
state. Many factors contribute to the software development
environment, including the base operating system, the object
file format, and compliance with industry standards. The
user must select an environment in which to operate.
This release of CX/UX provides three development
environments.
- 13 -
CX/UX 7.1 Release Notes
COFF This is an older environment, maintained for
compatibility with previous releases of CX/UX.
Compilation systems, debuggers, and object file
tools operate on COFF object files. Some
features typically associated with SVR4, such
as shared libraries and DWARF, are not
available in this environment. The Berkeley
universe is supported, however. The COFF
environment may not be supported in future
releases. Users should convert to the ELF
environment.
OCS This is a variation of the COFF environment
which provides compliance with 88open's BCS
(Binary Compatibility Standards) and OCS
(Object Compatibility Standards).
The OCS environment should be used when linking
and building programs with 88open compatible
compilers and/or libraries. It, too, may not
be supported in future releases.
ELF This is the default environment. Compilation
systems, debuggers, and object file tools
operate on ELF object files. Shared libraries,
dynamic linking, and DWARF symbolic debugging
information are integral parts of this
environment. As much as possible, the
semantics and functionalities of the
compilation systems and tools available in the
COFF environment (discussed next) are preserved
in the ELF environment. Notable exceptions
include the following:
1. The Berkeley universe, which Harris has
provided in the past, is not supported in
the ELF environment.
2. The following options to as(1) have
meaning in the COFF environment but not in
the ELF environment. They are accepted
but ignored by the assembler in the ELF
environment.
-r
-Qfile_buffer_limit=number
- 14 -
Release Notes 7.1 CX/UX
-Qno_parse_errors
-QOCS
-Tsymtab_size
3. The following options to ld(1) have
meaning in the COFF environment but not in
the ELF environment. They are accepted
but ignored by the link editor in the ELF
environment.
-f fill
-ocs
-Qfile_buffer_limit=number
-QOCS
-VS num
The -M option to ld(1) has different semantics in the two
environments. In the ELF environment, it is followed by the
name of a mapfile. In the COFF environment, it causes a
message to be output for multiply defined external
definitions.
In the ELF environment, the link editor internally converts
COFF files to ELF files. By default, the link editor
performs the conversion without notification. However, if
the -v option to ld(1) is used, notification is given of
every file that is converted in this manner.
In the ELF environment, both dynamic linking (which uses
shared libraries) and static linking (which uses static, or
archive, libraries) are available. Dynamic linking offers
the advantages of reduced disk image sizes for programs,
reduced memory usage when multiple processes share the code
from a shared object, and reduced link edit time in a
development environment.
However, the use of shared libraries can impose a
performance penalty on the overall execution time of a
program. By default, programs built under CX/UX Release 7.1
use static linking. The standard profile and login files
provided with CX/UX Release 7.1 set the STATIC_LINK
environment variable, which directs the compilation systems
to use static linking.
- 15 -
CX/UX 7.1 Release Notes
A user may select dynamic linking either by unsetting
STATIC_LINK or by using certain compilation system options
(e.g., -ZLINK=dynamic with the C and the Fortran compilers).
The use of these options overrides the specification made by
the presence or absence of STATIC_LINK.
Compilation, debugging, and examination of object files in a
particular development environment is accomplished by
setting the SDE_TARGET variable to one of the three
following strings.
ELF For the ELF environment.
COFF For the COFF environment.
OCS For the OCS environment.
If SDE_TARGET is not set, the ELF environment is used. Some
tools provide options which directly specify the development
environment to be used during the execution of that tool.
The development environment has no direct effect on the
execution of a program. Unless a program examines and
relies upon this variable, the setting of SDE_TARGET is
irrelevant during execution of the program.
Previous CX/UX releases offered only COFF as the default
environment and OCS as the alternative environment. This
release of CX/UX provides ELF as the default environment.
Thus, the simple command:
cc foo.c
produces, by default, an ELF program. If STATIC_LINK is set
(which is the default case provided by CX/UX), this program
is statically linked with the archive C library. If
STATIC_LINK is not set, the program dynamically links the
shared object portion of the shared C library.
NOTE: The COFF and the OCS environments may not be
supported in future CX/UX releases. Users should convert to
the ELF environment.
Each development environment has a subdirectory under
/usr/sde which contains tools and libraries specific to that
environment. For example, /usr/sde/elf/usr/lib/libc.a is
the ELF version of the C library used in static linking.
- 16 -
Release Notes 7.1 CX/UX
For libraries having both an ELF and a COFF version, the
standard system name of the library is a link to the ELF
version. For example, /lib/libm.a is a symbolic link to
/usr/sde/elf/usr/lib/libm.a, making it the ELF version of
the math library used in static linking.
Comparison of COFF, OCS, and ELF Environments
_____________________________________________________________________________________
| Environmental Feature COFF OCS ELF & DWARF |
|____________________________________________________________________________________|
| |
| SDE_TARGET variable set to COFF OCS ELF (default) |
| |
| Berkley Universe Supported Yes No No |
| |
| Static Vs Dynamic Linking Static Static Both (static is default) |
| |
| Shared Libraries No No C, math, malloc, X11, POSIX, Fortran|
| |
| POSIX.4 support Yes Yes Yes |
| |
| 88open Compliance (BCS) Yes Yes No |
| |
| 88open Compliance (OCS) No Yes No |
|____________________________________________________________________________________|
For tools having both an ELF and a COFF version, the
standard system name of the tool refers to a driver that
determines which version to invoke, based upon the
development environment and/or the format of object files
read by the tool. For example, /bin/as invokes
/usr/sde/elf/usr/bin/as in the ELF environment and
/usr/sde/coff/usr/bin/as in the COFF environment.
For more information on software development environments
refer to the CX/UX Programmer's Guide, and CX/UX Support
Tools Guide.
6.5 SVR4 Memory Management
Previous releases of the CX/UX operating system contained a
memory manager based on SVR3. The memory manager in CX/UX
Release 7.1 is based on SVR4. The SVR4 memory manager has
several important new capabilities. Chief among these are
page-based control of the address space, memory-mapped
files, and a large disk cache.
- 17 -
CX/UX 7.1 Release Notes
The SVR4 memory manager views the address space of a process
as a simple vector of pages. Each page in the address space
can be manipulated independently of the other pages. Each
page can be mapped to a different object or be unmapped, can
be locked into primary memory or be unlocked, can have
different access rights, and so on. Now applications have
much more control of their address spaces compared with
previous releases.
The SVR4 memory manager allows a process to map a file into
its address space. A memory-mapped file can be accessed
directly through the CPU's load and store instructions
instead of indirectly through the read(2) and write(2)
system calls. As a file access method, memory mapping has
the advantage of greater simplicity (single-level store
programming model) and greater efficiency (no need to copy
file data between operating system and application buffers).
Previous releases of the operating system maintained two
disk caches: the buffer cache under the control of the file
system and the page cache under the control of the memory
manager. This release merges the two caches into one cache
under the control of the memory manager. The net result
should be a larger and more effective disk cache.
The new interfaces to the SVR4 memory manager include the
following routines: mincore(2), munmap(2), memcntl(2),
mmap(2), mprotect(2), swapctl(2), mlock(3C), munlock(3C),
mlockall(3C), munlockall(3C), and msync(3C). The older SVR3
interfaces, such as brk(2), sbrk(2), shmat(2), and plock(2),
are also available. And finally, Harris-unique enhancements
to the memory manager added in previous releases are still
available. These include support for local memory,
userdma(2), usermap(2), shmbind(2), and memadvise(2). The
following paragraphs discuss the impact of the new memory
manager on these interfaces.
Applications can no longer choose the cache modes for their
data and and stack segments; copyback mode is always used.
For backwards compatibility, the memadvise(2) system call
silently ignores attempts to set the cache mode. Shared
memory segments that are bound to physical memory via the
shmbind(2) service use a cache mode that is appropriate for
the physical address range. For example, I/O space is cache
inhibited, and the cache mode for reserved sections of
primary memory is determined by the reserve statement in the
kernel's configuration file. The default cache mode for
regular shared memory segments is copyback.
- 18 -
Release Notes 7.1 CX/UX
Series 4000 data caches are not coherent with DMA transfers.
Therefore, the operating system issues data cache flush
operations either before or after most I/O requests. These
operations can have an impact on interrupt and context
switch latency. The lowest-numbered CPU on each CPU board
fields all of the cross-CPU interrupts issued for the
purposes of cache flushing. Developers of real-time
applications may want to consider the fact that the
remaining CPUs on each board will not receive these
interrupts.
In previous releases, memadvise(2) controlled how the text,
data, and stack segments and the U-block used local memory.
In this release, the data segment and stack segment
categories have been replaced by writable data and read-only
data categories. The memadvise(2) service still accepts the
data segment and stack segment categories, but they are
treated as aliases for the writable data category.
Furthermore, the text segment category includes all pages
that have execute access, wherever they may be in the
address space.
A local memory usage policy can be specified in the mmap(2)
system call.
Kernel text can be replicated in selected local memory pools
with the ktextlocal parameter in the kernel's configuration
file, but a copy of the kernel remains in global memory.
In previous releases, there was one page replacement daemon
for every CPU, and page replacement was triggered only by
the state of the global memory pool. In this release, there
is only one page replacement daemon in the system, and page
replacement occurs in each memory pool independently of the
states of the other memory pools.
The swap space requirement for this release is larger than
that for CX/UX 6.2. In CX/UX 6.2, the system's capacity for
storing anonymous pages (pages used for a process' stack,
heap, and shared memory segments) is the size of primary
memory plus the size of all of the swap areas. Because of
this, the 6.2 kernel will boot and run without any swap
space at all. In this release, the system's capacity for
storing anonymous pages is only the size of all of the swap
areas.
Consequently, the Release 7.1 kernel needs swap space to
simply boot. The larger swap space requirement is a
property of the design of the SVR4 memory manager. In CX/UX
- 19 -
CX/UX 7.1 Release Notes
Release 7.1, the sum of the sizes of all of the swap areas
should be at least as large as primary memory. Exactly one
swap area must be specified in the kernel's configuration
file; the remaining swap areas should be added during the
transition to multi-user mode with the swap(1) command. In
the absence of any knowledge about a particular system's
workload, Harris recommends twice as much swap space as
primary memory.
For more information on these topics, see the related man
pages, memory(7), cache(7), the CX/UX Programmer's Guide,
and the CX/UX System Administration Manual.
6.6 POSIX.4
The IEEE Draft Standard P1003.4/D14 is now an accepted
standard, which is known as IEEE Standard 1003.1-1993. The
POSIX.4 interfaces are organized as an extension to the
original POSIX.1 standard and will be published as one
entity. CX/UX Release 7.1 supports all functional areas as
specified by this new standard. Note that computer vendors
cannot claim compliance to this standard because currently
there is no test suite to verify compliance.
Applications that were written for previous CX/UX releases,
which supported other drafts of the POSIX.4 interfaces,
might need modification to operate under this release.
Please see the section entitled Changes from Previous
Releases for specific details on which POSIX.4 interfaces
have changed to support the final version of this standard.
The POSIX.4 interfaces are documented in the Real-Time
Documentation Set, CX/UX Programmer's Guide, and man pages.
Following is a list of all of the POSIX.4 functional areas
and the name of the chapter and manual in which the
corresponding CX/UX interfaces are documented:
- 20 -
Release Notes 7.1 CX/UX
Counting semaphores "Interprocess Synchronization"
CX/UX Programmer's Guide
Process memory locking "Memory Management"
CX/UX Programmer's Guide
Memory mapped files and shared memory "Memory Management"
CX/UX Programmer's Guide
Priority scheduling "Process Scheduling and Management"
Real-Time Documentation Set
Real-time signal extension "Signal Management"
CX/UX Programmer's Guide
Clocks and timers "Timing Facilities"
CX/UX Programmer's Guide
Interprocess message passing "Interprocess Communication"
CX/UX Programmer's Guide
Synchronized input and output "Real-Time Files"
CX/UX Programmer's Guide
Asynchronous input and output "Real-Time I/O"
CX/UX Programmer's Guide
6.7 STREAMS Link Level Driver
This release includes a STREAMS access to LAN drivers
through the Data Link Provider Interface (DLPI). The dlpi(7)
man page describes the DLPI interface, and the sld(7) man
page describes the STREAMS LAN Driver (SLD).
6.8 New Libraries
Several of the system libraries are available in both ELF
and COFF versions. These include the C, math, X11, POSIX,
Fortran, and malloc libraries. The ELF versions are also
available in two forms - one for static linking and one for
dynamic linking. The compilation system uses either the
static version or the shared version, depending on the
software development environment being used and the options
specified in the compilation system.
The library /usr/lib/libelf.a provides a user interface to
functions which access an ELF file. The available functions
are:
- 21 -
CX/UX 7.1 Release Notes
elf_begin(3E) elf_getphdr(3E)
elf_cntl(3E) elf_getscn(3E)
elf_end(3E) elf_getshdr(3E)
elf_error(3E) elf_hash(3E)
elf_fill(3E) elf_kind(3E)
elf_flag(3E) elf_next(3E)
elf_fsize(3E) elf_rand(3E)
elf_getarhdr(3E) elf_rawfile(3E)
elf_getarsym(3E) elf_strptr(3E)
elf_getbase(3E) elf_update(3E)
elf_getdata(3E) elf_version(3E)
elf_getehdr(3E) elf_xlate(3E)
elf_getident(3E)
Note: This library has been designed to fully exploit
available memory resources when it is used to open
and read ELF files. Because the library is used in
several compilation systems tools, such as, the link
editor and the assembler, users may observe greater
memory consumption when building ELF programs than
when building COFF programs.
7. Changes from Previous Releases
7.1 Compilation Systems
7.1.1 C_Library
The nlist(3C) function accepts the name of either an ELF
executable file or a COFF executable file. Symbol tables in
COFF files are different from symbol tables in ELF files,
both in format and in the meaning of some of the fields.
The name list structure defined in /usr/include/sys/nlist.h
is the one traditionally associated with COFF files. If the
specified executable file is an ELF file, the COFF-style
name-list structure receives values from corresponding
fields in the ELF symbol table. No semantic conversion of
fields from the ELF meaning to the corresponding COFF
interpretation is performed. Programs invoking this
function must be aware of the object file format of the
specified executable file and perform appropriate semantic
interpretation of the name list.
- 22 -
Release Notes 7.1 CX/UX
7.1.2 Link_Editor
In CX/UX Release 7.1, COFF programs are link-edited, by
default, with the address space starting in page 16. This
suppresses a page 0 from the address space of the running
process, causing the process to receive a signal if it
attempts to dereference a NULL pointer. Even though
dereferencing a NULL pointer is indicative of a programming
error, some programs rely on this behavior. Kernel and
link-editor facilities, therefore, are provided to permit
these programs to continue dereferencing a NULL pointer.
If a process has its address space beginning above page 0
and that process dereferences a NULL pointer, the kernel
will normally supply the process with a page of zeroes
starting at address 0x0. This provision is made at the time
the dereference is attempted, and the dereference will not
produce a signal. If a signal is desired, however, then the
COFF link editor should be invoked with the -zno_page_zero
option, which marks the vendor section of the program to
instruct the kernel not to provide the page of zeroes.
COFF programs which need to have the address space starting
in page zero should be link-edited with the the -zzeroword
option. In this case, the process incurs a small
performance penalty on startup, and the kernel provides the
process with a word of zeroes at address zero.
ELF programs are link-edited, by default, without a page
zero in the address space. The -z lowzeroes option to the
ELF link editor instructs the kernel to provide a page of
zeroes, at address 0x0, when the process starts up.
A new -Qfpcr= option is added to ld. This option takes a
numerical argument which is to become the value of the
floating-point control register (fpcr) at program startup.
Appropriate fields in the vendor section are modified to
effect this setting of the fpcr. Use of this option effects
an override of the default setting of the fpcr at program
startup.
7.1.3 Analyze88
The analyze88 tool provides the same functionality for a
statically-linked ELF program as it does for a COFF program.
For a dynamically-linked ELF program, analyze88 operates
only on the static portion of the program. The provision of
analyze88 functionality and transformation of shared objects
is neither feasible nor advantageous.
- 23 -
CX/UX 7.1 Release Notes
When analyze88 is used to profile COFF programs, it utilizes
the region of the program's address space between the .text
section and the .data section as a "patch area." When
analyze88 is used to profile ELF programs, it uses a
separate .analyze_patch section in the program file as the
"patch area." Usually, the size of the provided patch area
is sufficient for analyze88. (For ELF programs the default
size of the patch area is three times the size of the
program's .text section.) In rare cases, where the size is
insufficient, analyze88 alerts the user to recreate the
program with a larger patch area. For COFF programs, the
patch area can be enlarged by relinking the program with the
use of a linker command file. ELF programs can be relinked
using the link editor's -Qanalyze_patch_size= option to
reserve additional space. (This option can also be used to
reduce the size of the patch area.)
7.2 System Daemons
The page replacement daemon is now called pageout instead of
vhand, and there is only one such daemon in the system
rather than one per CPU.
mbdaemon is a new kernel daemon that manages network buffer
space.
fsflush is a new kernel daemon that periodically flushes
dirty file system pages to backing store.
Parameters in the kernel's configuration file control the
operation of all these daemons. For more information, see
the CX/UX System Administration Manual.
7.3 POSIX.4 Interfaces
POSIX.4 interfaces that were released in previous CX/UX
releases have been based on various IEEE Draft Standards.
CX/UX Release 7.1 supports POSIX.4 interfaces that are
specified in the final version of this standard, IEEE
Standard 1003.1-1993. Some of the changes that have been
made to update the POSIX.4 functional areas to support this
standard will cause source incompatibility for existing
programs that are based on previous releases of the POSIX.4
interfaces. It is recommended that all applications that
utilize any of the POSIX.4 interfaces be recompiled with the
new release. Compilation errors will indicate most areas
where source incompatibility exists. Recompilation will
also update the application so that it is using the most
up-to-date POSIX.4 library routines, some of which contain
- 24 -
Release Notes 7.1 CX/UX
performance improvements in this release.
The sections below document the changes that must be made to
source code that utilizes the POSIX.4 interfaces that have
been released in previous CX/UX releases. The changes
required in an application that utilizes POSIX.4 interfaces
depends upon the operating system release for which the
application was originally written. The changes required
are documented below according to the release to which the
user is upgrading. The changes required are cumulative; for
example, if the source code was originally developed under
release 6.1, then the changes made in releases 6.2 and 7.1
must all be applied to the application source code.
Note: You need to concern yourself with the following
sections on Release 6.2 and Release 7.1 changes only
if you have existing programs that use POSIX.4
interfaces from previous releases.
7.3.1 CX/UX Release 6.2 Changes Affecting Existing
Applications
7.3.1.1 Binary semaphores
Support for POSIX.4 binary semaphore interfaces has been
dropped. This functionality is now supplied by the counting
semaphore interfaces.
7.3.1.2 Clocks and Timers
The name of the header file that must be included by a
program that uses any of the POSIX.4 clocks and timers
interfaces has changed. Previously the name of this include
file was ; the name of the header file is now
.
7.3.2 CX/UX Release 7.1 Changes Affecting Existing
Applications
7.3.2.1 Counting Semaphores
The counting semaphore functional area has changed
extensively. Programs that use these interfaces will need
to be upgraded to be functional under the new release. An
overview of the changes follows.
Several of the counting semaphore interfaces have changed
names. sem_lock is now called sem_wait. sem_trylock is now
called sem_trywait. sem_unlock is now called sem_post.
- 25 -
CX/UX 7.1 Release Notes
The functionality of the sem_init function has been split
into two separate functions. sem_init is now used only to
initialize an "unamed" counting semaphore that already
exists in memory. To use this interface, the application
must allocate space for a counting semaphore in a shared
memory region and then initialize that semphore by calling
sem_init. sem_open is a new function that is used to obtain
a "named" counting semaphore from the system (this
functionality was previously provided by the sem_init
function). This interface is used when the application
wants the system to allocate space for the counting
semaphore. All processes that call sem_open with the same
name will be referencing the same semaphore.
The sem_destroy function should be called only for
destroying unnamed semaphores. A new function, sem_close,
is used for destroying named semaphores. This means an
application either uses the sem_init and sem_destroy pair or
the sem_open and sem_close pair for creating and destroying
attachments to counting semaphores.
7.3.2.2 Real-Time Signals
The interface that blocks until a signal is received is now
called sigwaitinfo instead of sigwaitrt.
The sigevent structure contains a new member, sigev_notify,
which indicates whether a signal should really be sent.
This field must be set to the value SIGEV_SIGNAL if a signal
is to be generated. This change affects several other
interfaces that utilize the sigevent structure and are
described in subsequent sections.
Warning: Any program that uses a sigevent structure to
specify that a signal is to be delivered when an
event of interest occurs must now initialize the
sigev_notify member to SIGEV_SIGNAL. Failure to
do this initialization will not cause a
compilation error but may cause no signal to be
delivered.
When a signal handler is invoked such that a siginfo_t
structure is delivered and the signal was sent by a user
process via an interface such as the kill system call, the
si_code member of the signinfo_t structure is now called
SI_USER instead of SI_KILL.
- 26 -
Release Notes 7.1 CX/UX
7.3.2.3 Synchronized I/O
Setting the O_DSYNC and O_SYNC flags no longer affects read
operations to the file. These flags now specify
synchronized I/O data intergity or synchronized I/O file
integrity, respectively, for write operations. Read
operations can be synchonized to the same level of integrity
as write operations by specifying the O_RSYNC flag in
conjunction with either O_DSYNC or O_SYNC.
7.3.2.4 Asynchronous I/O
The aiocb structure contains a sigevent structure to define
how the calling process will be notified upon I/O
completion. When submitting an asynchronous I/O request via
aio_read, aio_write, lio_listio, or aio_fsync, the
sigev_notify member of this structure must be initialized as
described in the real-time signals section above.
7.3.2.5 Clocks and Timers
The typedef for a POSIX.4 clock ID has changed names. This
typedef was previously named clock_t and is now named
clockid_t.
The timer_create interface specifies a pointer to a sigevent
structure that defines how the calling process will be
notified upon timer expiration. The sigev_notify member of
this structure must be initialized as described in the
real-time signals section above.
The timer_create() function no longer returns the timer ID.
Instead, this function returns a zero for success and a -1
if an error has occurred. The timer ID is returned to the
location pointed to by a new argument to the timer_create()
function.
The behavior of the nanosleep() function has changed for the
case in which the sleep is interrupted by a signal. When
nanosleep() is interrupted by a signal, it returns -1 with
errno set to EINTR. If the second argument to nanosleep()
is non-null, then it points to a timespec structure that is
filled with the time remaining in the original sleep
interval.
- 27 -
CX/UX 7.1 Release Notes
7.3.2.6 Interprocess Message Passing
The mq_destroy() function is now called mq_unlink().
The mq_getattr() and mq_setattr() functions reference the
mq_attr structure. This structure no longer contains the
elements mq_sendwait and mq_rcvwait.
When a notification request is attached to a message queue
via mq_notify and the notification is delivered to that
process, then the notification request is now detached for
this process, and the message queue is once again available
for any process to attach a notification request.
Previously an attached notification request was not detached
unless the process explicitly detached the notification
request via mq_notify.
The mq_notify interface specifies a pointer to a sigevent
structure that defines how the calling process will be
notified when a message queue becomes non-empty. The
sigev_notify member of this structure must be initialized as
described in the real-time signals section above.
7.3.2.7 Memory Mapped Files and Shared Memory
In previous releases, the locks that were placed on pages by
using mlock were nested; that is, if mlock was called twice
for a given address range, then it was necessary to call
munlock twice for this address range to unlock the pages.
In the current release, calls to mlock are not nested, and
munlock needs to be called only once to unlock a given
address range.
7.3.2.8 Real-Time Files
The real-time files interfaces have been removed from IEEE
Standard 1003.1-1993. These interfaces are no longer
supported by CX/UX. The interfaces that have been removed
include the following: rf_create, rt_getattr, rf_setattr,
rf_getalloccap, rf_getcachecap, rf_getbiocap, rf_getaiocap,
rf_getdiocap, rf_getallocincr, rf_getincr, rf_getbuf, and
rf_freebuf.
7.3.3 Other_Changes
Some of the changes that have been made to update the
POSIX.4 functional areas to support the final version of the
POSIX standard will not cause source incompatibility for
existing programs that are based on previous versions of the
- 28 -
Release Notes 7.1 CX/UX
related interfaces. The sections that follow describe
changes to the interfaces that will not require source
changes in applications that were built to use previous
versions.
It is recommended that users recompile applications that use
POSIX.4 interfaces with the libraries in the current
release. If any cooperating programs are recompiled under
the new release, then all of the cooperating programs must
be recompiled. For example, a program compiled with the
version 7.1 POSIX.4 library that uses shared memory will not
be able to communicate with a program which uses the shared
memory interfaces provided by an earlier operating system
release.
7.3.3.1 Memory Mapped Files and Shared Memory
Full support is now provided for memory mapped files. The
previous release of these interfaces contained many
restrictions that are not a part of the IEEE Standard
1003.1-1993. These interfaces are now fully supported as
defined in the standard. Removal of the previous
restrictions does not affect applications that were written
to adhere to the restrictions imposed by the previous
release. Most of these interfaces are now a part of libc
instead of libposix4. See the following man pages for full
details: mmap(2), munmap(2), mlockall(3C), munlockall(3C),
mlock(3C), munlock(3C), shm_open(3P4), and shm_unlink(3P4).
The mprotect(2) and msync(3C) functions are now supported.
7.3.3.2 Interprocess Message Passing
The mq_setattr() function is now supported. It allows the
user to set the message queue to operate in non-blocking
mode.
7.3.3.3 Clocks and Timers
If no pointer to a sigevent structure is provided on a call
to timer_create(), then upon expiration of the timer, the
SIGALRM signal is sent to the process. If the SIGALRM
signal is being caught and the SA_SIGINFO flag is set for
the SIGALRM signal, then the value delivered with the signal
will be the timer ID of the expired timer.
- 29 -
CX/UX 7.1 Release Notes
7.3.3.4 Asynchronous I/O
Null elements can now be included in the array of I/O
requests that are passed via the lio_listio() function.
These elements will be ignored.
7.3.3.5 Counting Semaphores
A new function, sem_getvalue, has been added to obtain the
current value of a counting semaphore.
7.4 Core Files
A core image file created by the operating system when a
process terminates abnormally is now named core.pid where
pid is the process's ID. For backwards compatibility, core
is a hard-link to the most recently created core.pid file.
7.5 Utilities
7.5.1 /etc/rc
The rc script has been changed slightly. Three log files
are now saved at boot time, and compressed using
compress(1). The log files which are saved are:
/var/adm/sulog, /usr/lib/X11/xdm/xdm-errors, and
/var/cron/log. These are saved in their respective
directories by appending .OLD to the filename. If you need
to view these saved log files, you must first uncompress(1)
them. See the uncompress(1) man page for more information.
7.5.2 fdump(1)
There is a new option in the fdump(1) command, -M, which
allows you to specify the tape size in megabytes. See the
fdump(1) man page for more information.
7.5.3 tar(1)
The tar(1) utility now creates absolute pathnames if they
don't exist.
7.5.4 mkdir(1)
The mkdir(1) command can now be accessed from /sbin and from
/usr/bin.
- 30 -
Release Notes 7.1 CX/UX
7.5.5 man(1)
The man(1) script can now search different paths. You can
specify the paths to search in the environment variable
MANPATH, or use the -Mpath command-line option. Multiple
paths may be specified, separated by colons (i.e.
-M/usr/catman/a_man:/usr/catman/p_man). In addition, man(1)
will now format any unformatted man pages found. See the
man(1) man page for more information.
7.5.6 login(1)
The login(1) program now has additional configuration
options. The system administrator can configure different
timeout and security features. See the login(1) man page
for more information.
7.5.7 vmstat(1)
The output of the vmstat(1) command was changed to be
meaningful for the new SVR4 memory manager.
7.5.8 mpstat(1)
mpstat(1) now displays information about memory pool usage.
7.5.9 pstat(1)
The pstat(1) command no longer displays the region table or
the swap table.
7.5.10 ps(1)
The output of the ps(1) command is identical to that
produced by SVR4. Like SVR4, the -n option is no longer
supported, and the -c option now shows scheduling class
information.
7.5.11 top(1)
This release contains top(1) version 3.0. The version 3.0
display is very similar but not identical to earlier
versions.
- 31 -
CX/UX 7.1 Release Notes
7.5.12 swapon(1m)
The 4.2BSD swapon(1m) command was dropped in favor of the
SVR4 swap(1m) command.
7.5.13 swap(1m)
A new option, -f, in the SVR4 swap(1m) command reads
/etc/fstab and activates all of the swap devices found
therein.
7.5.14 ipcs(1)
The -b option now prints memory binding information for
shared memory segments.
7.5.15 Message_Catalogs_in_Utilities
The following commands use message catalogs to obtain
internationalized text strings for error and informational
messages.
cat chgrp chmod chown cp
date diff file find grep
ln ls mkdir more mv
passwd rm rmdir su tar
American English messages are displayed by default. Message
catalog files for other languages can be created by
translating the source catalog files in the directory
/usr/lib/locale/src/LC_MESSAGES. Once translated, use the
gencat(1M) command to create each compiled catalog file and
install it as described in the gencat(1M) man page.
7.6 System Services
7.6.1 fork(2)
fork(2) no longer assigns process IDs sequentially.
7.6.2 exec(2)
exec(2) can now load both ELF and COFF executables.
- 32 -
Release Notes 7.1 CX/UX
7.6.3 badaddr(2)
The address being tested no longer needs to be locked in
memory.
7.6.4 shmget(2)
The default cache mode for shared memory segments not bound
to the physical address space via shmbind(2) is copyback.
Attempts to specify a cache mode other than copyback are
silently ignored.
7.6.5 shmbind(2)
Bound shared memory segments use a cache mode that is
appropriate for the specified physical address. For
example, I/O space is cache inhibited. Reserved sections of
primary memory have a cache mode that is determined by the
reserve statement in the kernel's configuration file.
7.6.6 shmctl(2)
A new command, SHM_RMIDLD, destroys both the shared memory
segment ID and the shared memory segment itself at the same
time: when the segment is no longer in use. (By contrast,
the standard IPC_RMID command destroys the shared memory
segment ID immediately and destroys the shared memory
segment itself when it is no longer in use.)
7.6.7 shmat(2)
By default, the kernel places shared memory segments in the
virtual address range 0x80000000 to 0xfffff000. This policy
complies with both the BCS and the ABI. If insufficient
space is available, shmat(2) returns -1 and errno is set to
ENOMEM. Please note that, shmat() failures are identified
by the value -1; other "negative" values are NOT failures.
7.6.8 userdma(2)
userdma(2) uses the same locking mechanism as memcntl(2) and
plock(2). A given page can be locked multiple times through
different mappings; however, within a given mapping, page
locks do not nest. All multiple-lock operations on the same
address and in the same process are removed with a single
unlock operation.
A locked buffer is implicitly unlocked if the mapping is
removed or a page is deleted through file removal or
- 33 -
CX/UX 7.1 Release Notes
truncation.
The physical location of a locked buffer can change if the
process invokes fork(2).
The physical location of a locked buffer can change if a
private, read-only mapping is made writable by mprotect(2).
The physical location of a locked buffer can change if the
buffer resides in a local memory pool, is mapped to a file,
and another process attempts to access the file.
The physical location of a locked buffer can change if the
buffer resides in a local memory pool and the process
migrates to a CPU not attached to that pool (see
memadvise(2) and mpadvise(2)). This form of migration only
occurs in mpadvise(2) at the application's request; the
operating system's load balancer never migrates a process
out of a local memory pool.
7.6.9 usermap(2)
usermap(2) no longer requires the object mapped by the
target address to be locked in memory, and no longer
requires that the length be less than or equal to 8.
The kernel places usermap(2) segments in the virtual address
range 0x80000000 to 0xfffff000. This policy complies with
both the BCS and the ABI. If insufficient space is
available, usermap(2) returns -1 and errno is set to ENOMEM.
Please note that usermap() failures are identified by the
value -1 -- other "negative" values are NOT failures.
7.6.10 memadvise(2)
Applications can no longer select a cache mode for their
data and stack segments. Attempts to do so are silently
ignored. userdma(2) should be used to make an I/O buffer
coherent with DMA.
In previous releases, memadvise(2) controlled how the text,
data, and stack segments and the U-block used local memory.
In this release, the data segment and stack segment
categories have been replaced by writable data and read-only
data categories. The memadvise(2) service still accepts the
data segment and stack segment categories, but they are
treated as aliases for the writable data category.
Furthermore, the text segment category includes all pages
that have execute access, wherever they may be in the
- 34 -
Release Notes 7.1 CX/UX
address space.
7.6.11 iconnect(2)
The iconnect(2) system call no longer makes a copy of the
calling process's text segment when the IC_DEBUG flag in the
ic_flags field of the icon_conn structure is set. This
means that breakpoints set via the console will be visible
to other processes running the same program. If a process
encounters a console breakpoint while it is executing in
user mode, the process will be terminated with a SIGTRAP
signal. If it is likely that a user-mode process will
execute a routine that is being debugged via the console,
the tester can avoid the SIGTRAP signals by:
1. Temporarily creating a duplicate of the executable
file, or
2. Temporarily changing the routine under test so that it
is not executed in user mode.
7.6.12 ienable(2)
Data cache coherence becomes an issue when a process uses
local memory and connects to an interrupt. The iconnect(2)
and ienable(2) system calls place the burden of data cache
coherence on their callers. Unlike previous releases, these
system calls no longer attempt to keep the caches coherent.
The issue is this: translations to local and global page
frames usually specify the copyback or writethrough cache
modes. In order to keep the data caches coherent,
translations to remote page frames must specify the cache-
inhibited cache mode. The terms local and remote describe a
relationship between a page frame and a CPU. The kernel
builds translations for a process with respect to the CPU on
which the process is running. If translations were built
with respect to one CPU and subsequently used on a different
CPU, the data caches could become corrupted. In most
circumstances, these issues are hidden from applications by
the kernel's load-balancing and process-migration
algorithms. However, the situation just described can occur
if a process running on CPU A has bindings to local memory
and connects to an interrupt serviced by CPU B.
Applications should follow this procedure - the same
procedure recommended by previous releases - when connecting
to interrupts:
- 35 -
CX/UX 7.1 Release Notes
1. Discover which CPU services the interrupt of interest.
2. Bind the application to the CPU servicing the
interrupt.
3. Attach to any shared memory segments, mmap(2) any
files, etc. Lock all pages to be referenced at
interrupt level into memory.
4. Connect to the interrupt.
ienable(2) no longer returns an error if the process is
attached to a shared memory segment that is bound to local
memory.
7.7 curses
A problem involving the use of Ctrl-Z with a curses
application has been corrected. The talk(1C) program, for
example, now behaves correctly.
7.8 Manual Pages
Manual pages are no longer provided in hard-copy form.
Manual pages, however, continue to be available as on-line
documentation. Manual pages that are available on line are
contained in the following on-line reference manuals:
1. CX/UX User's Reference Manual
2. CX/UX Programmer's Reference Manual
3. CX/UX Administrator's Reference Manual
The manual pages in each of these manuals are presented in
sections; for example, the general purpose commands that are
described throughout the ensuing pages of this guide are
contained in Section 1 of the on-line CX/UX User's Reference
Manual, and the commands related to certain types of system
maintenance procedures performed by your system
administrator are contained in Section 8 of the on-line
CX/UX Administrator's Reference Manual. When you enter the
man command to display a manual page, you can optionally
specify the section by entering the command as indicated in
the following example:
man 1 clear
This capability is especially useful when a command is
- 36 -
Release Notes 7.1 CX/UX
documented in more than one section. If you do not specify
a section number, the documentation contained in all
sections is displayed.
Note: References to manual pages in this guide will
include notation of the appropriate section as
illustrated by the following:
man(1)
For additional information on use of the man(1) command,
refer to the system manual page.
Printing On-line Manual Pages
To print a manual page, enter the command as shown in the
following example.
man clear | lp ( or man 1 clear to specify section number )
For additional information on use of the man(1) command,
refer to the system manual page.
7.9 Kernel Configuration File
The following parameters in a kernel configuration file are
no longer supported: gpgslo, gpgshi, vhndfrac, vhandl,
vhandr, maxumem, and sptmap.
The following parameters are new in this release: mbstart,
mblowat, mbincr, ktextlocal, lotsfree, desfree, minfree,
fsflushr, noautoup, minpagefree
The maxpmem parameter was changed to work on a per-pool
basis and the reserve statement was changed to include cache
mode information.
For more information see the CX/UX System Administration
Manual.
7.10 Device Driver Interfaces
Several routines used by device drivers were changed for
CX/UX Release 7.1. The changes were either needed by the new
memory manager, or needed to improve system performance.
Although device drivers written for previous releases may
need some modification in order to run in this release, the
task of conversion should be straightforward. The sections
that follow describe these changes.
- 37 -
CX/UX 7.1 Release Notes
7.10.1 Memory-Mapped_Devices
Character drivers for memory-mappable devices can now supply
an mmap() or segmap() entry point.
7.10.2 Synchronization_Primitives
The second argument to initlock() must be NULL. Spin locks
are always initialized to the unlocked state.
#include
/* Initialize the spin lock at lockp to the unlocked state. The
* second argument must be NULL.
*/
void
initlock(lock_t *lockp, lockinfo_t *infop)
The second argument to initsema() must be NULL. The
functionality of the old fifo flag can be obtained by
asserting SEMA_FIFO in the third argument. Also, a mutual
exclusion semaphore initialized with the SEMA_NEST flag
allows nested locking; that is, the owner of a mutex is
allowed to re-lock the mutex several times.
#include
/* Initialize the semaphore at semp. The second argument must be
* NULL. Flags include
*
* MUTEX_SEMA initialize a mutual exclusion semaphore
* SEMA_NEST allow nested locking
*
* COND_SEMA initialize an eventcount semaphore
* SEMA_FIFO use FIFO queueing
*/
void
initsema(sema_t *semp, lockinfo_t *infop, int flags)
Mutual exclusion semaphores now allow reader/writer locking.
Write locks are applied by the old pmutex() routine; read
locks are applied by the new rmutex() routine (same calling
sequence as pmutex()). In some cases, the use of read locks
can increase the flow through heavily-traveled critical
sections. Both read and write locks are released by the old
vmutex() routine.
- 38 -
Release Notes 7.1 CX/UX
7.10.3 Virtual_Memory_Primitives
There is a typedef for physical addresses in :
paddr_t.
The old vtop_sys() and vtop_user() routines have been
replaced by the DDI-compliant vtop() routine.
/* Translate virtual address addr in the address space belonging to
* process proc into a physical address. If proc is NULL the
* kernel's address space is used. Returns the physical address if
* successful, 0 otherwise.
*/
paddr_t
vtop(caddr_t addr, struct proc *proc)
The old sptalloc() and sptfree() routines have been replaced
by iomem_alloc() and iomem_free().
#include
/* Allocate len bytes of memory suitable for use as a communication
* area between a device driver and its device. Flags include
*
* IOM_NOSLEEP do not wait for resources to become available
* IOM_CONTIG memory should be physically contiguous
* IOM_DCWRC data cache should be coherent with DMA writes
* IOM_DCRDC data cache should be coherent with DMA reads
*
* The newly allocated memory will always be page-aligned and its
* size will always be rounded up to a multiple of the page size.
* Returns the location of the new storage if successful, NULL
* otherwise.
*/
caddr_t
iomem_alloc(u_int len, u_int iomflags)
/* Free memory previously allocated with iomem_alloc().
*
void
iomem_free (caddr_t addr, u_int len)
The old set_up_pte() and remove_pte() routines have been
replaced by physmap_alloc() and physmap_free().
#include
- 39 -
CX/UX 7.1 Release Notes
/* Allocate virtual address space that is mapped to physical address
* pa for len bytes. Returns the location of the virtual mapping if
* successful, NULL otherwise. Flags include
*
* IOM_NOSLEEP do not wait for resources to become available
*/
caddr_t
physmap_alloc (paddr_t pa, u_int len, u_int iomflags)
/* Free virtual address space previously allocated with
* physmap_alloc().
*/
void
physmap_free (caddr_t addr, u_int len)
7.10.4 Cache-Handling_Primitives
Previous releases used writethrough cache mode for all
kernel data. This release attempts to use copyback cache
mode as much as possible for performance reasons. In
particular, uninitialized, statically-allocated data (the
.bss section) are in copyback mode. To make it easy for
device drivers to statically allocate writethrough storage,
initialized, statically-allocated data (the .data section)
are still in writethrough mode.
In previous releases, device drivers for Series 4000
machines could assume that all memory is DMA write coherent;
in other words, no cache flush is needed prior to a DMA
write. This is no longer the case for Release 7.1. In
general, device drivers must assume that a cache flush is
needed prior to a DMA write unless the memory is known to be
DMA write coherent. DMA write coherent memory can be
allocated with iomem_alloc(). Reserved memory can be made
DMA write coherent in the kernel's configuration file. The
kernel's .data section is DMA write coherent and mbufs are
DMA write coherent. All other memory must be assumed to be
DMA write incoherent.
Although the old P1DC() and uncache() primitives are still
supported, new and greatly improved data cache primitives
are available.
#include
/* Prepare the data cache for DMA in the virtual address range [addr,
* addr+len) in process proc. If proc is NULL the kernel's address
* space is used. Flags include
- 40 -
Release Notes 7.1 CX/UX
*
* DC_ISE DMA is to/from an ISE device (else a VME device)
* DC_READ DMA is read from device (write to primary memory)
* DC_WRITE DMA is write to device (read from primary memory)
* DC_MYCPU my CPU only, ignore other CPUs in the system
*/
void
dcache_previrtdma (caddr_t addr, u_int len, struct proc *proc,
u_int dcflags)
/* Fix the data cache after DMA has occurred in the virtual address
* range [addr, addr+len) in process proc. If proc is NULL the
* kernel's address space is used. Flags are the same as above.
*/
void
dcache_postvirtdma (caddr_t addr, u_int len, struct proc *proc,
u_int dcflags)
/* Prepare the data cache for DMA in the physical address range
* [paddr, paddr+plen). The physical address range must not cross a
* page boundary. Flags are the same as above.
*/
void
dcache_prephysdma (paddr_t paddr, u_int plen, u_int dcflags)
/* Fix the data cache after DMA has occurred in the physical address
* range [paddr, paddr+plen). The physical address range must not
* cross a page boundary. Flags are the same as above.
*/
void
dcache_postphysdma (paddr_t paddr, u_int plen, u_int dcflags)
/* Prepare the data cache for DMA in the range [poff, poff+plen) in
* page frame pp. For convenience, returns the physical address of
* location poff in page frame pp. Flags are the same as above.
*/
paddr_t
dcache_prepagedma (page_t *pp, u_int poff, u_int plen, u_int dcflags)
- 41 -
CX/UX 7.1 Release Notes
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 42 -
CONTENTS
1. Introduction............................................. 1
1.1 Boot/miniroot tape................................. 1
1.2 Products tape...................................... 2
2. Documentation............................................ 3
3. Prerequisites............................................ 5
3.1 Hardware Prerequisites............................. 5
3.2 Software Prerequisites............................. 5
4. Installation............................................. 5
4.1 Pre-Installation................................... 5
4.2 Installation Procedure............................. 5
4.3 Post-Installation.................................. 6
4.4 Disk Partition Sizes............................... 6
4.5 Installation Cautions.............................. 7
4.5.1 Placement of the /var Directory............ 7
4.5.2 Optional Products in Alternate
Partitions................................. 8
4.5.3 Latest Release of Optional Products........ 8
5. Cautions................................................. 9
5.1 Kernel Builds...................................... 10
5.2 Future Support..................................... 10
6. New Features in this Release............................. 11
6.1 Shared Objects and Dynamic Linking................. 11
6.2 New Shared Objects................................. 12
6.3 ELF and DWARF File Formats......................... 12
6.4 Software Development Environments.................. 13
6.5 SVR4 Memory Management............................. 17
6.6 POSIX.4............................................ 20
6.7 STREAMS Link Level Driver.......................... 21
6.8 New Libraries...................................... 21
7. Changes from Previous Releases........................... 22
7.1 Compilation Systems................................ 22
7.1.1 C Library.................................. 22
7.1.2 Link Editor................................ 23
7.1.3 Analyze88.................................. 23
7.2 System Daemons..................................... 24
7.3 POSIX.4 Interfaces................................. 24
7.3.1 CX/UX Release 6.2 Changes Affecting
Existing Applications...................... 25
7.3.1.1 Binary semaphores................. 25
7.3.1.2 Clocks and Timers................. 25
- i -
7.3.2 CX/UX Release 7.1 Changes Affecting
Existing Applications...................... 25
7.3.2.1 Counting Semaphores............... 25
7.3.2.2 Real-Time Signals................. 26
7.3.2.3 Synchronized I/O.................. 27
7.3.2.4 Asynchronous I/O.................. 27
7.3.2.5 Clocks and Timers................. 27
7.3.2.6 Interprocess Message Passing...... 28
7.3.2.7 Memory Mapped Files and Shared
Memory............................ 28
7.3.2.8 Real-Time Files................... 28
7.3.3 Other Changes.............................. 28
7.3.3.1 Memory Mapped Files and Shared
Memory............................ 29
7.3.3.2 Interprocess Message Passing...... 29
7.3.3.3 Clocks and Timers................. 29
7.3.3.4 Asynchronous I/O.................. 30
7.3.3.5 Counting Semaphores............... 30
7.4 Core Files......................................... 30
7.5 Utilities.......................................... 30
7.5.1 /etc/rc.................................... 30
7.5.2 fdump(1)................................... 30
7.5.3 tar(1)..................................... 30
7.5.4 mkdir(1)................................... 30
7.5.5 man(1)..................................... 31
7.5.6 login(1)................................... 31
7.5.7 vmstat(1).................................. 31
7.5.8 mpstat(1).................................. 31
7.5.9 pstat(1)................................... 31
7.5.10 ps(1)...................................... 31
7.5.11 top(1)..................................... 31
7.5.12 swapon(1m)................................. 32
7.5.13 swap(1m)................................... 32
7.5.14 ipcs(1).................................... 32
7.5.15 Message Catalogs in Utilities.............. 32
7.6 System Services.................................... 32
7.6.1 fork(2).................................... 32
7.6.2 exec(2).................................... 32
7.6.3 badaddr(2)................................. 33
7.6.4 shmget(2).................................. 33
7.6.5 shmbind(2)................................. 33
7.6.6 shmctl(2).................................. 33
7.6.7 shmat(2)................................... 33
7.6.8 userdma(2)................................. 33
7.6.9 usermap(2)................................. 34
7.6.10 memadvise(2)............................... 34
7.6.11 iconnect(2)................................ 35
7.6.12 ienable(2)................................. 35
7.7 curses............................................. 36
- ii -
7.8 Manual Pages....................................... 36
7.9 Kernel Configuration File.......................... 37
7.10 Device Driver Interfaces........................... 37
7.10.1 Memory-Mapped Devices...................... 38
7.10.2 Synchronization Primitives................. 38
7.10.3 Virtual Memory Primitives.................. 39
7.10.4 Cache-Handling Primitives.................. 40
8. Direct Software Support.................................. 42
- iii -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/UX
VERSION 7.1
RELEASE NOTES
0890108-7.1
October 1993
_________________________________________________________________
Trademark Acknowledgments
CX/UXO is a registered trademark of Harris Corp.,
Computer Systems Div.
Night HawkO is a registered trademark of Harris Corp.,
Computer Systems Div.
NightTraceTM is a trademark of Harris Corp., Computer
Systems Div.
NightViewTM is a trademark of Harris Corp., Computer
Systems Div.
88openO is a registered trademark of the 88open
Consortium, Ltd.
gdbTM is a trademark of the Free Software Foundation.
ABITM is a trademark for Application Binary Interface
UNIXO UNIX is a registered trademark of UNIX System
Laboratories, Inc.
EthernetO is a registered trademark of Xerox Corp.
return to index
================================================================================
CX/RT -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
CX/RT Version 7.1 includes two products, cx_rt and
cx_rt_develop, to be used in conjunction with CX/UX 7.1. The
cx_rt product consists of the CX/RT kernel, which is a low-
overhead real-time kernel compatible with the CX/UX 7.1
kernel. It is a multiprocessing multithreaded, preemptive
kernel.
2. Documentation
The following documentation is included with this release:
_______________________________________________
| Manual Name Pub. Number|
|________________________________|_____________|
| Real-Time Documentation Set | 0890285-070|
| CX/RT Version 7.1 Release Notes| 0890285-7.1|
|________________________________|_____________|
The CX/RT Reference Manual has been converted to a
documentation set composed of three books:
o Book 1 is entitled Guide to Real-Time Features.
This book contains the information that was formerly in
Part I of the CX/RT Reference Manual-that is, the
overview of the CX/RT product, the real-time kernel,
process scheduling and management, response time,
__________
- These release notes cover the following products: cx_rt
and cx_rt_develop
- 1 -
CX/RT 7.1 Release Notes
real-time peripherals, the frequency-based scheduler,
the performance monitor, and data recording.
o Book 2 is entitiled Guide to Real-Time Services
Utilities.
This book contains the information that was formerly in
Part II of the CX/RT Reference Manual-that is, the
procedures for using the real-time services utilities
rtutil and rtcp and the reference information on the
menus and tasks in rtutil and the commands in rtcp.
o Book 3 is entitled Guide to Real-Time Library
Interfaces.
This book contains the information that was formerly in
Part III of the CX/RT Reference Manual-that is, the
reference information for using the Ada, C, and FORTRAN
library interfaces to the frequency-based scheduler,
the performance monitor, and data recording.
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
3. Prerequisites
Prerequisites for CX/RT Version 7.1 are as follows:
3.1 Hardware
o Any Series 4000 or 5000 system
3.2 Software
o CX/UX 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
- 2 -
Release Notes 7.1 CX/RT
Refer to the Real-Time Documentation Set for configuration
instructions specific to cx_rt_develop.
5. Cautions
The real-time data recording program, rt_datarec, requires
that the CX/RT kernel be configured with the frequency-based
scheduler facility, the shared memory mechanism, and the
System V semaphore mechanism.
Due to its vendor-specific nature, the real-time library for
FORTRAN, /usr/lib/libF77rt.a, a part of the cx_rt_develop
product, is not OCSTM (Object Compatibility Standard)
compliant.* FORTRAN object modules compiled in OCS-
compliant mode will not be able to link with this library.
6. New Features in the cx_rt Product
6.1 POSIX.4
The IEEE Draft Standard P1003.4/D14 is now an accepted
standard, which is known as IEEE Standard 1003.1-1993. The
POSIX.4 interfaces are organized as an extension to the
original POSIX.1 standard and will be published as one
entity. CX/UX and CX/RT support all functional areas as
specified by this new standard. Note that computer vendors
cannot claim compliance to this standard because currently
there is no test suite to verify compliance.
Refer to the CX/UX Version 7.1 Release Notes for a list of
all of the POSIX.4 functional areas and the name of the
chapter and manual in which the corresponding interfaces are
documented.
Applications that were written for previous CX/UX and CX/RT
releases, which supported other drafts of the POSIX.4
interfaces, might need modification to operate under this
release. Please see the section entitled "Changes from
Previous Releases" for additional information.
__________
* OCS is a trademark of the 88open Consortium Ltd.
- 3 -
CX/RT 7.1 Release Notes
7. Changes from Previous Releases
7.1 Changes to POSIX.4 Interfaces
POSIX.4 interfaces that were released in previous CX/UX and
CX/RT releases have been based on various IEEE Draft
Standards. CX/UX and CX/RT support POSIX.4 interfaces that
are specified in the final version of this standard, IEEE
Standard 1003.1-1993. Some of the changes that have been
made to update the POSIX.4 functional areas to support this
standard will cause source incompatibility for existing
programs that are based on previous releases of the POSIX.4
interfaces. It is recommended that all applications that
utilize any of the POSIX.4 interfaces be recompiled with the
new release. Compilation errors will indicate most areas
where source incompatibility exists. Recompilation will
also update the application so that it is using the most
up-to-date POSIX.4 library routines, some of which contain
performance improvements in this release.
Please see the section entitled "Changes from Previous
Releases" in the CX/UX Version 7.1 Release Notes for
specific details on which POSIX.4 interfaces have changed to
support the final version of this standard. Note the
following in the "POSIX.4 Interfaces" section:
o The sections entitled "CX/UX Version 6.2 Changes
Affecting Existing Applications" and "CX/UX Version 7.1
Changes Affecting Existing Applications" document the
changes that must be made to source code that utilizes
the POSIX.4 interfaces that have been released in
previous CX/UX and CX/RT releases. The changes
required in an application that utilizes POSIX.4
interfaces depends upon the operating system release
for which the application was originally written. The
changes required are documented according to the
release to which the user is upgrading. The changes
required are cumulative; for example, if the source
code was originally developed under release 6.1, then
the changes made in releases 6.2 and 7.1 must all be
applied to the application source code.
Note: You need to concern yourself with these sections
only if you have existing programs that use
POSIX.4 interfaces from previous releases.
o Some of the changes that have been made to update the
POSIX.4 functional areas to support the final version
of the POSIX standard will not cause source
- 4 -
Release Notes 7.1 CX/RT
incompatibility for existing programs that are based on
previous versions of the related interfaces. The
section entitled "Other Changes" describes changes to
the interfaces that will not require source changes in
applications that were built to use previous versions.
7.2 Change Regarding nanosleep Documentation
In previous releases, the POSIX.4 nanosleep(3P4) routine has
been documented in the CX/RT Reference Manual in the chapter
entitled "Improving Response Time." In release 7.1, this
routine is documented with the other POSIX.4 clocks and
timers interfaces in the CX/UX Programmer's Guide in the
chapter entitled "Timing Facilities."
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 5 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
5. Cautions.................................................. 3
6. New Features in the cx_rt Product......................... 3
6.1 POSIX.4.............................................. 3
7. Changes from Previous Releases............................ 4
7.1 Changes to POSIX.4 Interfaces........................ 4
7.2 Change Regarding nanosleep Documentation............. 5
8. Direct Software Support................................... 5
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/RT
VERSION 7.1
RELEASE NOTES
0890285-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
DR11W -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The DR11W emulator is a high-speed, 16-bit parallel DMA
interface between the CX systems and most DR11W-compatible
devices, including other DR11W emulators. Furthermore, the
DR11W emulator provides several real-time features, such as
I/O directly to/from a process's address space, asynchronous
I/O support, three attention interrupt notification
mechanisms, and a 32 megabyte DMA transfer capability.
A set of library routines can be obtained to access the
DR11W device directly from user space. The source code to
this user level driver is provided so that the driver can be
modified to perfectly fit the needs of a given application.
Performing I/O through the user-level driver can provide a
tremendous improvement in reducing the overhead of issuing
an I/O request.
Refer to the CX/UX Programmer's Guide for complete
information.
2. Documentation
The following documentation is included with this release:
___________________________________
| Manual Name Pub. Number|
|____________________|_____________|
|____________________|_____________|
__________
- These release notes cover the following products: dr11w
- 1 -
DR11W 7.1 Release Notes
| DR11W Release Notes| 0890303-7.1|
|____________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
3. Prerequisites
Prerequisites for DR11W Version 7.1 are as follows:
3.1 Hardware
o Any Series 4000 or 5000 system
o DR11W emulator
3.2 Software
o CX/UX 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
5. Cautions
None.
6. New Features in this Release
None.
- 2 -
Release Notes 7.1 DR11W
7. Changes from Previous Releases
The DR11W_EPOLL ioctl(2) requires that both the current CPU
and the CPU servicing the DR11W interrupt have the same
local/global/remote relationship with the polling address.
If this is not the case, an error is returned; for example,
if the polling address is in a memory pool that is local to
the current CPU but is remote to the CPU that will
eventually service the DR11W interrupt, an error will be
returned.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 3 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
5. Cautions.................................................. 2
6. New Features in this Release.............................. 2
7. Changes from Previous Releases............................ 3
8. Direct Software Support................................... 3
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
DR11W
VERSION 7.1
RELEASE NOTES
0890303-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
OSI FTAM -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The OSI (Open Systems Interconnection) FTAM (File Transfer,
Access, and Management) software package allows the transfer
and remote access of files between Harris hosts (computers),
and between Harris hosts and hosts from other vendors who
run the OSI FTAM protocol as specified by the ISO
(International Standards Organization) 8571 standard.
OSI FTAM is based upon the FTAM software package developed
by Retix and operates in a STREAMS-based environment. OSI
FTAM requires the usage of the OSI LAN Transport software
package to provide the lower protocol layers (Transport and
Networking Layers) needed for communication in an OSI
environment.
OSI FTAM supports the FTAM-1 Unstructured Text, FTAM-2
Sequential Text, FTAM-3 Unstructured Binary, NBS-9 Directory
Filenames, and NBS-10 Random Binary Access document file
types.
The OSI FTAM product also supports an application program
interface (API) library based on the Manufacturing
Automation Protocol (MAP)/Technical and Office Protocol
(TOP) Version 3.0 standard.
__________
- These release notes cover the following products: ftam
- 1 -
OSI FTAM 7.1 Release Notes
2. Documentation
The following documentation is included with this release:
_________________________________________________________
| Manual Name Pub. Number|
|__________________________________________|_____________|
| OSI FTAM Administration Guide | 0890411-000|
| OSI FTAM Programmer Guide | 0890443-000|
| OSI FTAM User Guide | 0890445-000|
| OSI Upper Layers Common Facilities Manual| 0890447-000|
| OSI FTAM Version 7.1 Release Notes | 0890411-7.1|
|__________________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
- 2 -
Release Notes 7.1 OSI FTAM
3. Prerequisites
Prerequisites for OSI FTAM version 7.1 are as follows:
3.1 Hardware
o Any Harris Series 4000 or 5000 system.
o Special hardware is needed and is dependent upon the
type of network on which OSI FTAM is run. One or more
of the following is needed: an Ethernet controller
and/or an FDDI controller.
3.2 Software
o CX/UX 7.1
o STREAMS 7.1
o OSI LAN Transport 7.1
o Ethernet 7.1
4. Installation
Refer to the CX/UX System Administration Manual, Chapter 3,
for instructions on software installation.
4.1 Product Installation
The OSI FTAM product is installed in the following fashion:
/etc - Contains OSI FTAM configuration files.
/usr/bin/osi - Contains OSI FTAM commands.
/usr/catman - Contains on-line versions of all OSI FTAM
man pages.
/usr/etc/ftam - Contains OSI FTAM filestore daemons,
databases, and auditing. NOTE: Administrators should
ensure that this directory has full read, write, and
execute access for all groups. This will permit access to
the filestore databases by all FTAM utilities/application
- 3 -
OSI FTAM 7.1 Release Notes
programs.
/usr/etc/ftam/demo - Contains FTAM MAP/TOP 3.0 Application
Program Interface (API) demo program source code.
/usr/include/ftam - Contains various header files used by
the FTAM MAP/TOP 3.0 Application Program Interface (API)
library.
/usr/include/ulcommon - Contains API OSI upper layers
header files.
/usr/lib/ftam - Contains various libraries used by the
FTAM MAP/TOP 3.0 Application Program Interface (API)
library.
/usr/lib/ulcommon - Contains API OSI upper layers
libraries.
/usr/man - Contains formatted source code versions of all
OSI FTAM man pages.
/var/spool/ftam - Initially empty directory which will
contain keys to message queues utilized by the OSI FTAM
virtual filestore. NOTE: Administrators should ensure
that this directory has full read, write, and execute
access so that the filestore and lockmgr daemons can
function properly.
4.2 Kernel Configuration
Once the OSI FTAM software has been installed, the kernel
must be configured and rebuilt to support the OSI LAN
Transport stack over which the OSI FTAM product must run.
To do this, verify that the OSI LAN Transport stack product
has been installed and then uncomment the following options
in the kernel configuration file prior to kernel
recompilation:
mbufs #See OSI LAN Transport, Ethernet Release Notes
(0890419)
options STREAMS #STREAMS support
options "NSTRPUSH" #No. of pushes per stream
options "STRCTLSZ" #Max size of control portion of any
message
- 4 -
Release Notes 7.1 OSI FTAM
options NCLONE #Clone driver minor devices
options NLOG #Optional: Log driver minor devices
options NTIRDWR #TLI read/write module minor devices
options NTIMOD #TLI cooperating module minor devices
options OSILAN #OSI LAN Transport stack support
Depending on the system's hardware configuration, uncomment
one or more of the following kernel configuration file
options to configure LAN controllers prior to kernel
recompilation:
device pg[0-2] #Interphase 4211 Peregrine FDDI
controller
device ie[0-3] #Integral Ethernet controller
device eg[0-3] #Interphase 4207 Eagle Ethernet
controller
Refer to the CX/UX System Administration Manual, Chapter 4,
for instructions on configuring and building a kernel.
Also refer to the OSI LAN Transport, Ethernet Release Notes
(Publication #0890419) for further information on OSI LAN
Transport stack building and configuration on your system.
4.3 /etc/rc Script Modifications
Examine the /etc/rc and the /etc/shutdownrc scripts for OSI
LAN Transport and OSI FTAM-specific options which must be
uncommented prior to rebooting the OSI-configured kernel.
4.4 Application Entity Table
The OSI hosts address file __AETABLE__ is installed under
the directory /usr/etc/ftam. This file is accessed by all
OSI application software packages to determine the OSI
addresses of host systems (also known as application
entities or AEs in OSI terms). All of the OSI applications
expect the __AETABLE__ file to reside under the /etc
directory. Therefore, this file must be eventually moved to
the /etc directory prior to activating or using any of the
OSI applications. Since this file is released with every
- 5 -
OSI FTAM 7.1 Release Notes
OSI application, it is placed under the /usr/etc/XXX
directory (where XXX refers to the particular OSI
application) to prevent accidental overwrite of an existing
__AETABLE__ file in the /etc directory. OSI administrators
do not need to access each __AETABLE__ file in each OSI
application's /usr/etc directory, but either make only one
copy of the file for global use in the /etc directory or
simply modify the existing global /etc/__AETABLE__ with
addressing information for the new OSI application
installed. For more information on this file consult the
__AETABLE__(4) manual page.
The assignment and format of addresses in this file should
be consistent with those utilized by the OSI LAN Transport
protocol stack. Refer to the Network Directory Compiler
Reference Manual (Publication #0890446) for additional
information on OSI address formats. Also refer to the OSI
LAN Transport, Ethernet Release Notes (Publication #0890419)
for information relating to the determination of LAN device
physical addresses for use in OSI addresses.
Once local OSI FTAM address entries have been added to the
__AETABLE__, the NSAP portions of those local entries must
be added to the OSI LAN Transport's kernel NSAP table via
the nsap(1M) command. To ensure that these local NSAP
entries will be configured automatically at boot time, add
the new local OSI FTAM NSAP entries to the nsap command
logic of the /etc/rc system initialization script. Note
that the term "local" refers to those address entries
associated with the system on which the OSI FTAM product has
been installed and is running on.
4.5 OSI FTAM Configuration Files
Prior to filestore activation, modify the /etc/ffs.cfg and
/etc/ffs.auth files for system-specific OSI FTAM
customization. Local OSI FTAM filestore address entries
added to the __AETABLE__ will need to be set in the
corresponding fields of the /etc/ffs.cfg configuration file.
Refer to the OSI FTAM Administration Guide (Publication
#0890411) and the ffs.cfg(4) and ffs.auth(4) manual pages
for more information.
- 6 -
Release Notes 7.1 OSI FTAM
4.6 OSI FTAM Environment Variables
OSI FTAM administrators should take note of the environment
variables AETABLE, FILESTORES, and FTAMLOCAL which are used
by the OSI FTAM product (see the OSI FTAM User Guide,
fcp(1C), fls(1C), fmv(1C), or frm(1C) for further
information).
4.7 Filestore Initialization
First time installation of the OSI FTAM filestore attribute
and concurrency databases will require initialization of
these databases in order to correctly activate the filestore
daemons. This must be performed by the finit(1M) filestore
utility prior to activating the filestore processes from the
/etc/rc script. Failure to initialize these databases for
the first time will result in a filestore failure when the
system enters multiuser mode. To initialize these
databases, type the following commands while logged in as
root:
cd /usr/etc/ftam
/usr/etc/ftam/finit -cy /etc/ffs.cfg
/usr/etc/ftam/finit -ay /etc/ffs.cfg
This initialization process creates a set of attribute and
concurrency database ".k01" key and ".d01" data information
files in the /usr/etc/ftam directory which are used by the
filestore databases. After this initialization has taken
place, the FTAM filestore will be automatically activated
via the /etc/rc script when the system enters multiuser
mode.
4.8 OSI FTAM Audit Trail Files
System administrators should be aware of the creation of the
runtime filestore audit trail files ffs.audit and
ffs.audit.bak in the /usr/etc/ftam directory. By default,
the FTAM utilities audit trail file utils.audit is kept in
the /usr/etc/ftam directory as well. The utilities audit
trail file can exist on a per user basis if a user utilizes
the .ftInit FTAM customization file. The .ftInit file
provides a configuration parameter which permits the user to
specify where this audit trail file should reside. It is
recommended that system administrators enforce and maintain
- 7 -
OSI FTAM 7.1 Release Notes
a single location for this file in each .ftInit file that is
used. This location should be the /usr/etc/ftam directory.
Refer to the ffs.audit(4), utils.audit(4), and ftInit(4)
manual pages for more information.
4.9 OSI FTAM Temporary Lock Files
While the OSI FTAM filestore is running, the filestore lock
manager process will utilize the /var/spool/ftam directory
for "token files" used to identify keys to the message
queues used in the filestore database. These token files
will be identified as /var/spool/ftam/lockmgr (for the lock
manager process) and /var/spool/ftam/XXXX, where XXXX is the
database user ID of a user process that is currently logged
into the lock manager process. The /var/spool/ftam
directory is cleared with each reboot of the system.
4.10 OSI FTAM Manuals and Manual Pages
After the OSI FTAM package has been installed, examination
of the provided documentation and on-line manual pages is
recommended in order to gain familiarity with the product.
To locate all of the OSI FTAM on-line manual pages, enter
the following command:
/bin/man -k FTAM | pg
5. Cautions
The size of the /usr/etc/ftam directory can grow
considerably as a result of the amount of data stored in the
filestore's attribute and concurrency databases. This size
is a factor of FTAM usage. It may be necessary to perform
routine maintenance on this directory if disk space becomes
a problem. It is possible to relocate the FTAM filestore
databases and/or the auditing files by 1) moving them to a
new filesystem location and 2) by updating location-specific
information in the /etc/ffs.cfg and/or any .ftInit user
files.
The size of this directory can also be affected by the
amount of data stored in the OSI FTAM filestore audit trail
files. If this presents a problem, the filestore audit
trail files' location can be modified in the same manner as
- 8 -
Release Notes 7.1 OSI FTAM
the filestore databases mentioned in the previous paragraph.
6. FTAM API
An FTAM Application Program Interface (API) based upon the
Manufacturing Automated Protocol/Technical Office Protocol
(MAP/TOP) is included with this product. The FTAM API is
contained in the following libraries:
/usr/lib/ftam/libfi.a
/usr/lib/ftam/libfr.a
/usr/lib/ftam/libft_ai.a
Also required for operation of the FTAM API are the OSI
upper layers libraries providing the necessary OSI
Application, Presentation, and Session layer protocol
support. This support is contained in the following
libraries:
/usr/lib/ulcommon/libacse.a
/usr/lib/ulcommon/libps.a
/usr/lib/ulcommon/librtp.a
/usr/lib/ulcommon/libsession.a
/usr/lib/ulcommon/libsystem.a
/usr/lib/ulcommon/libupper.a
Support for the USL Transport Layer Interface (TLI) is also
needed and is provided with the general CX operating system
release. This support is provided in /usr/lib/libnsl.a.
Necessary include files are also provided for API support.
These files are installed under /usr/include/ulcommon and
/usr/include/ftam.
With the FTAM API, applications can be developed which
directly access the FTAM protocol machine. An example FTAM
API program is provided under /usr/etc/ftam/demo. This
program transfers a user-specified file between two
filestores. A makefile is also provided in which users can
actually build the example program. The makefile and source
files given provide users with a template on how to create
their own FTAM applications. To build the example API
program, type the following command sequence:
cd /usr/etc/ftam/demo
make demo
- 9 -
OSI FTAM 7.1 Release Notes
Once the example program, demo, has been built, it can be
executed by typing demo at the command line prompt. Prior
to executing the example program, all OSI FTAM environment
variables must be initialized (see the section entitled FTAM
Environment Variables above) and the FTAM filestore must be
running. The program will prompt the user two separate
times for source and destination (target) information
concerning the filestore, file to be transfered, a user ID,
and a supporting user ID password. The user of the example
program must have the appropriate user ID and password
already existing on both the source and target filestore
systems for the example program to operate correctly.
Please note that the FTAM API does not support a "loop back"
mode (i.e., an API program cannot connect to its host
filestore system, but rather must connect to a remote
filestore system).
7. New Features in this Release
None.
8. Changes from Previous Releases
None.
9. Recommended Reading Material
The following introductory references are recommended for
users who are unfamiliar with FTAM:
Uyless Black. OSI: A Model for Computer Communication
Standards. Prentice-Hall, Inc., 1991. ISBN 0-13-
637133-7.
John Henshall and Sandy Shaw. OSI Explained: end-to-end
computer communication standards. Ellis Horwood Limited,
1990. ISBN 0-13-639451-5.
The following introductory references are recommended for
users who are unfamiliar with the OSI upper layers (i.e.,
Presentation, Session, etc.):
- 10 -
Release Notes 7.1 OSI FTAM
William Stallings. Handbook of Computer-Communications
Standards. Volume 1, Second Edition. The Open Systems
(OSI) Model and OSI-Related Standards. Howard W. Sams &
Company, 1990. ISBN 0-672-22697-9.
William Stallings. Networking Standards: A Guide to
OSI, ISDN, LAN, and MAN Standards. Addison-Wesley
Publishing Company, Inc., 1993. ISBN 0-201-56357-6.
The following introductory references are recommended for
users who are unfamiliar with STREAMS and the Transport
Layer Interface (TLI):
UNIX System V Release 4 Programmer's Guide: Networking
Interfaces. HCSD Publication Number 0890396.
UNIX System V Release 4 Programmer's Guide: STREAMS.
HCSD Publication Number 0890397.
10. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 11 -
CONTENTS
1. Introduction............................................ 1
2. Documentation........................................... 2
3. Prerequisites........................................... 3
3.1 Hardware.......................................... 3
3.2 Software.......................................... 3
4. Installation............................................ 3
4.1 Product Installation.............................. 3
4.2 Kernel Configuration.............................. 4
4.3 /etc/rc Script Modifications...................... 5
4.4 Application Entity Table.......................... 5
4.5 OSI FTAM Configuration Files...................... 6
4.6 OSI FTAM Environment Variables.................... 7
4.7 Filestore Initialization.......................... 7
4.8 OSI FTAM Audit Trail Files........................ 7
4.9 OSI FTAM Temporary Lock Files..................... 8
4.10 OSI FTAM Manuals and Manual Pages................. 8
5. Cautions................................................ 8
6. FTAM API................................................ 9
7. New Features in this Release............................ 10
8. Changes from Previous Releases.......................... 10
9. Recommended Reading Material............................ 10
10. Direct Software Support................................. 11
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
OSI FTAM
VERSION 7.1
RELEASE NOTES
0890411-7.1
November 1993
_________________________________________________________________
Trademark Acknowledgments
Ethernet is a registered trademark of Xerox Corporation
Retix is a registered trademark of Retix
return to index
================================================================================
GDB -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
Versions 4.2 and 4.9 of the Free Software Foundation's GNU
Source-Level Debugger are provided with minor enhancements
in use at Harris Computer Systems Division.
GDB is provided free with CX/UX and is a fully supported
product.
2. Source
Source for either version of GDB is available on request
from Harris. However, only official distributions of GDB
will be supported by Harris. Harris will not support
customer-made changes to GDB.
3. Copyright
GDB is copyrighted by the Free Software Foundation, Inc.
Conditions for redistribution and warranty information may
be found in the GDB General Public License included as part
of this distribution.
4. Documentation
The following documentation is included with this release:
__________
- These release notes cover the following products: gdb
- 1 -
GDB 7.1 Release Notes
_____________________________________
| Manual Name Pub. Number|
|______________________|_____________|
| GDB Documentation Set| 0890393-010|
| GDB Release Notes | 0890393-7.1|
|______________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
5. Prerequisites
Prerequisites for GDB Version 7.1 are as follows:
5.1 Hardware
o Any Series 4000 or 5000 system.
5.2 Software
o CX/UX 7.1
6. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
The source for the 4.2 version of GDB may be found in
/usr/src/cmd/gdb/m88k. The source for the 4.9 version of
GDB may be found in /usr/src/cmd/gdb/gdb-4.9. The script
/usr/bin/gdb chooses between the two versions of GDB.
7. Cautions
ELF files must be statically linked to work correctly with
gdb4.9. See ld(1) for information about static linking.
- 2 -
Release Notes 7.1 GDB
8. New Features in this Release
gdb4.2 is the GDB version 4.2 that has traditionally been
supplied with CX/UX on Series 4000 systems. It does not
understand ELF executables. Users may explicitly invoke
this debugger with the name /usr/bin/gdb4.2.
gdb4.9 is based on the Free Software Foundation's GDB
version 4.9 port to the Motorola 88100 architecture. It
understands ELF executables and Harris' DWARF debugging
information. Although it understands COFF executables, it
frequently cannot access local variables on the stack and
does not understand COFF core files. Users may explicitly
invoke this debugger with the name /usr/bin/gdb4.9.
The script /usr/bin/gdb chooses between the two versions of
GDB based on:
o The type of the executable file argument to gdb
o The value of the SDE_TARGET environment variable
gdb4.9 is invoked if either of the following statements are
true:
o GDB was run with an ELF executable on the command line.
o GDB was not invoked with an existing executable, but
the SDE_TARGET environment variable was set to either
ELF or nothing.
In all other cases gdb4.2 is invoked.
9. Changes from Previous Releases
The script /usr/bin/gdb chooses between the two versions of
GDB. In past releases, /usr/bin/gdb was the name of the GDB
executable.
10. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
- 3 -
GDB 7.1 Release Notes
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 4 -
CONTENTS
1. Introduction............................................. 1
2. Source................................................... 1
3. Copyright................................................ 1
4. Documentation............................................ 1
5. Prerequisites............................................ 2
5.1 Hardware............................................ 2
5.2 Software............................................ 2
6. Installation............................................. 2
7. Cautions................................................. 2
8. New Features in this Release............................. 3
9. Changes from Previous Releases........................... 3
10. Direct Software Support.................................. 3
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
GDB
VERSION 7.1
RELEASE NOTES
0890393-7.1
October 1993
_________________________________________________________________
return to index
================================================================================
IEEE 488 -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
These release notes describe the release of the General
Purpose Interface Bus (GPIB) software for Series 4000 and
Series 5000 systems. It is based on the Motorola MVME300
GPIB interface board. The GPIB is a parallel interface bus
that allows up to 31 devices to be attached to each
controller. Devices may talk to each other or to the
controller. Currently, the driver only supports the MVME300
in controller mode and cannot be used as a device in slave
mode. Features that are supported include:
o Direct DMA to and from memory.
o Talker/Listener functionality in system controller mode
only.
o Serial and parallel polling.
o Local/remote/local lockout modes.
o Service requests.
Refer to the gpib(7) man page for additional information.
__________
- These release notes cover the following products: gpib
- 1 -
IEEE 488 7.1 Release Notes
2. Documentation
The following documentation is included with this release:
______________________________________
| Manual Name Pub. Number|
|_______________________|_____________|
| IEEE 488 Release Notes| 0890372-7.1|
|_______________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number is 1-800-
245-6453. For calls outside the continental United States
the number is 1-305-971-6248.
3. Prerequisites
Prerequisites for IEEE 488 Version 7.1 are as follows:
3.1 Hardware
o Any Series 4000 or Series 5000 system.
3.2 Software
o CX/UX 7.1
4. Installation
4.1 Software
This section documents the setup and installation of GPIB
software. Harris recommends that the procedures described
below be performed by system administrator level personnel.
Consult the CX/UX System Administration manual for
additional information.
4.1.1 Updating_the_Configuration_File
The configuration file contains lines of ASCII text of
possible system and product configurations. To include
product information for the GPIB product, locate the lines
below in your configuration file:
- 2 -
Release Notes 7.1 IEEE 488
####################################
#
# Motorola MVME 300 driver for GPIB
#
####################################
#
#device gpib0 at vba? csr 0xff8600 vector gpibintr
#device gpib1 at vba? csr 0xff8640 vector gpibintr
#device gpib2 at vba? csr 0xff8680 vector gpibintr
#device gpib3 at vba? csr 0xff86c0 vector gpibintr
#device gpib4 at vba? csr 0xff8700 vector gpibintr
#device gpib5 at vba? csr 0xff8740 vector gpibintr
#device gpib6 at vba? csr 0xff8780 vector gpibintr
#device gpib7 at vba? csr 0xff87c0 vector gpibintr
Uncomment only those lines which designate a GPIB board
installed in your system. (The # character denotes the line
as being a comment; deleting the character changes it to an
executable line.)
Next locate the reserve statement lines which are used for
the GPIB software in the configuration file. They appear as
follows:
# Allocate buffers for GPIB driver. The 'reserve' line sets aside
# a chunk of physical memory for the buffer at the specified address,
# and the GPIBBA and GPIBBS options pass those values through to the
# device driver. The GPIBMAXOPEN option specifies the maximum number
# of GPIB devices that may be open at any moment. The allocated buffer
# will be divided equally among the GPIBMAXOPEN devices.
#
# Note that the reserved buffer must lie entirely within the
# physical address range 0x100000 and 0xbfffff.
#
# reserve 0xb00000 length 0x10000
# options GPIBBA=0xb00000
# options GPIBBS=0x10000
# options GPIBMAXOPEN=16
In order to utilize the GPIB software, you will need to
uncomment the final four lines of this area (reserve and
options lines). The memory specified by the reserve
statement must be in the first 12 megabytes of physical
memory. This is a requirement of the MVME 300 card. This
area ends at address 0xc00000. Ensure that the GPIBBA and
GPIBBS values match those on the reserve statement.
On hardware configurations having a large quantity of
physical memory, the kernel and its buffer area may utilize
all of the first 12 megabytes of memory. If this is the
- 3 -
IEEE 488 7.1 Release Notes
case, the kernel will display an error message when the
system is booted indicating that the reserved memory could
not be allocated. The GPIB software will not operate in
that case. To reserve the necessary memory it will be
necessary to reduce the kernel size below 12 megabytes. The
easiest way to accomplish this is to reduce the size of the
system buffer cache. Find the buffers line near the
beginning of the configuration file, uncomment it, and set
the value to something in the 3000 - 6000 range which allows
the kernel to boot and reserve the required memory.
After building the configuration file you will need to
reconfigure and relink your kernel. Consult the CX/UX System
Administration manual, Chapter 4, for further instructions.
Note: During the boot process a message displays which GPIB
controllers were found on your system. If the newly
installed controllers are not found, you will need to check
on the hardware installation and jumper settings before
proceeding.
4.1.2 Running_MAKEDEV
The MAKEDEV script-utility uses mknod calls to create
special files that specify major and minor numbers used by
the system to identify GPIB devices. The controllers are
numbered 0 to 7. The devices on each controller are
numbered 0 to 30. MAKEDEV must be run for each controller
configured on your system.
Because each special file is tied to a specific physical
connection, a single device-file will be necessary for each
link. The special files will be named /dev/gpib/xxx, where
xxx is the logical unit number.
To create the GPIB special files the installer must change
(cd) to the /dev directory and type:
MAKEDEV gpibn
where n is the controller number of the GPIB. Following the
successful execution of the above utility, special files
will exist in the /dev/gpib directory. Note: Special files
need only be created for controllers that are currently
installed.
Devices are referenced as in the example table below.
- 4 -
Release Notes 7.1 IEEE 488
/dev/gpib/0d0 ; controller 0 device 0
/dev/gpib/0d1 ; controller 0 device 1
/dev/gpib/0d13 ; controller 0 device 13
/dev/gpib/1d1 ; controller 1 device 1
/dev/gpib/3d20 ; controller 3 device 20
4.2 Hardware
Refer to the Shippable Items (SI) Drawing Number 1120068
provided with the controller for proper switch settings.
5. Interface Definitions
5.1 open/close
Devices must be opened before they may be accessed. Each
device can be opened by only one process at a time. When a
process has finished with a device it should be closed, in
order to free the device for another process.
5.2 read/write
Once a device has been opened it can be read from or written
to with the standard read and write calls.
5.3 ioctl()
See the gpib(7) man page for a complete listing of ioctl
commands.
6. Cautions
Device reads and writes are restricted to 2048 bytes unless
the application enlarges the buffer size by calling ioctl()
with GPIB_SIZE. Reads or writes larger than the device's
current buffer allocation will be truncated to the current
buffer size. Closing a device resets the buffer size to the
default value.
Non-system controller mode is not supported. The GPIB board
must be the controller at all times. Some non-system
controller functions are included in the driver; their
results are unpredictable.
- 5 -
IEEE 488 7.1 Release Notes
7. Changes from Previous Release
None.
8. Appendix A - Sample Code Fragment
/***************************************************
*
* Test read and write functions on an Iotech 488 analyzer
* Iotech should be in device simulator mode.
* Displays test loops completed on Iotech.
* Test runs until killed.
*
****************************************************/
#include
#include
#include
#include
#include
int fd;
int ctlr = -1, device = -1;
int stat, i, ret, mm, count;
char str[88];
char *out = "D/ 0/\r";
char arg;
char *test[32];
char term = '\r';
main(argc,argv)
int argc;
char **argv;
{
if ( argc < 3 ) usage();
ctlr = atoi(argv[1]);
device = atoi(argv[2]);
if ( ctlr < 0 || ctlr > 7 || device < 0 || device > 30 ) usage();
/** initialize arrays **/
for ( i = 0; i < 32; i++ ) test[i] = (char *)malloc(80);
printf("IoTech Test on controller %d, device %d.0,ctlr,device);
sprintf(str,"/dev/gpib/%dd%d",ctlr,device);
- 6 -
Release Notes 7.1 IEEE 488
if ((fd=open(str,O_RDWR)) < 0) {
perror("open") ;
printf("open error on %s.\n",str);
exit(0);
}
if ((stat = ioctl(fd, GPIBSETEOS, &term)) < 0) {
perror( "GPIBSETEOS");
exit(1);
}
/** double buffer size to 4K for the fun of it **/
*term = 4096;
if ((stat = ioctl(fd, GPIB_SIZE, &term)) < 0) {
perror( "GPIB_SIZE");
exit(1);
}
/** tell device what we want to read **/
ret = write(fd,"W0X",3);
if ( ret == 3 ) ret = write(fd,"G0X",3);
if ( ret == 3 ) ret = write(fd,"I44X",4);
if ( ret == 4 ) ret = write(fd,"H4X",3);
if ( ret != 3 ) {
printf("Write failed.\n");
exit(1);
}
/** read in test patterns **/
mm = 0;
do {
ret = read(fd,test[mm], 27);
test[mm][27] = 0;
mm++;
} while ( ret == 27 && mm < 32 );
if ( ret != 27 ) {
printf("Read failed.\n");
exit(1);
}
/** now continue looping forever **/
count = 1;
do {
- 7 -
IEEE 488 7.1 Release Notes
ret = write(fd,"W0X",3);
if ( ret == 3 ) ret = write(fd,"G0X",3);
if ( ret == 3 ) ret = write(fd,"I44X",4);
if ( ret == 4 ) ret = write(fd,"H4X",3);
if ( ret != 3 ) {
printf("Write failed.\n");
exit(1);
}
mm = 0;
do {
ret = read(fd,str,27);
str[27] = 0;
if ( strcmp(test[mm],str) || ret != 27 ) {
printf("Read %ld Failed !\n",count);
printf("Test value [%s]\n",test[mm]);
printf("Read value [%s]\n",str);
exit(1);
}
mm++;
} while ( mm < 32 );
/** increment display **/
inc_count(21);
ret = write(fd,out,24);
if ( ret != 24 ) {
printf("Write failed.\n");
exit(1);
}
} while ( 1 );
close(fd);
}
inc_count(i)
int i;
{
if ( i < 2 ) return; /* overflow */
if ( out[i] == ' ' ) out[i] = '0'; /* added a digit */
if ( out[i] != '9' ) {
out[i]++;
return;
}
else {
- 8 -
Release Notes 7.1 IEEE 488
out[i] = '0';
inc_count(i-1);
}
}
usage()
{
printf("usage: tech controller device\n");
printf("controller 0..7, device 0..30\n");
exit(1);
}
9. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 9 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 2
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
4.1 Software............................................. 2
4.1.1 Updating the Configuration File............... 2
4.1.2 Running MAKEDEV............................... 4
4.2 Hardware............................................. 5
5. Interface Definitions..................................... 5
5.1 open/close........................................... 5
5.2 read/write........................................... 5
5.3 ioctl().............................................. 5
6. Cautions.................................................. 5
7. Changes from Previous Release............................. 6
8. Appendix A - Sample Code Fragment......................... 6
9. Direct Software Support................................... 9
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
IEEE 488
VERSION 7.1
RELEASE NOTES
0890372-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
CX/UX HC C -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
CX/UX hc C 7.1 is the Harris ANSI C compiler for Series 4000
and Series 5000 systems. The hc compiler accepts the C
language as defined by Kernighan and Ritchie, nearly all of
the traditional UNIX extensions to this definition, and all
of the features of the ANSI C standard. The hc compiler is
also known as cc.
2. Documentation
The following documentation is included with this release:
_______________________________________________
| Manual Name Pub. Number|
|________________________________|_____________|
| CX/UX Harris C Reference Manual| 0891019-060|
| CX/UX hc C Release Notes | 0891019-7.1|
| C A Reference Manual | 0890378-000|
|________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Support Center. The toll-free number is 1-800-245-6453.
For calls outside the continental United States the number
is 1-305-971-6248.
__________
- These release notes cover the following products: hc
- 1 -
CX/UX hc C 7.1 Release Notes
3. Prerequisites
Prerequisites for CX/UX hc Version 7.1 are as follows:
3.1 Hardware
o Any Harris Series 4000 or Series 5000 system
3.2 Software
o CX/UX 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
5. Cautions
o This release provides a new object-file format, ELF.
Support for COFF is still available. See Section 6.1
for details.
o hc can generate code that runs on both the Series 4000
and the Series 5000 Harris computers. The 88110
processor used in the Series 5000 can reorder loads and
stores of different memory locations; use the
-Qsync_volatile compiler option when compiling
applications that will be executed on the Series 5000
and that might depend on the ordering of loads from and
stores to memory. One example of such an application
is a device driver for which a load will change the
state of the device.
o The extent to which the hc compiler accepts the C
language as defined by the ANSI C standard as well as
defined by the first edition of Kernighan and Ritchie
is controlled by command-line options. See the
discussion of the -X[acto] option in hc(1) for an
explanation of how hc treats specific C-language
features in its different compilation modes.
- 2 -
Release Notes 7.1 CX/UX hc C
o Certain incorrect C constructs (as defined by Kernighan
and Ritchie), which are accepted by pcc-based
compilers, may not be accepted by hc. Correctly
written programs will compile without problems.
o Users are encouraged to retain the source for their
applications. Major releases may provide new object-
file formats, which will require the recompilation of
programs.
6. Changes from Previous Releases
The following changes from past releases of hc should be
noted.
6.1 ELF Object Files and Dwarf Debugging
hc now supports two object-file formats: COFF and ELF.
COFF is the object-file and debugging format traditionally
supported by CX/UX. ELF is the new, SVR4-compatible
object-file format and Dwarf is the debugging format
supported by CX/UX in ELF-format object files. ELF is the
CX/UX 7.1 default object-file format. New _COFF and _ELF
predefined macros exist. _COFF is defined when compiling in
the COFF software development environment (SDE). _ELF is
defined when compiling in the ELF SDE.
While the same compiler is used to generate object in either
of these two formats, other tools such as as and ld, and the
libraries have different formats. The new -Z command-line
option and the SDE_TARGET environment variable may be used
to choose which object-file format to work with. Please
refer to the hc(1) man page for information about SDE_TARGET
and the -Z option. Also, the CX/UX Programmer's Guide and
CX/UX Support Tools Guide contain more information about the
object-file formats and the tools that deal with them.
6.2 -Qfile_buffer_limit Command-Line Option
The -Qfile_buffer_limit command-line option can be used to
increase the size of the file buffers that ld uses when
linking large COFF executables. In situations where ld
could use larger buffers, it prints out a diagnostic to that
effect containing a number. Use that number (or a greater
number) with the -Qfile_buffer_limit option to permit ld to
- 3 -
CX/UX hc C 7.1 Release Notes
use optimally-sized file buffers and decrease link time.
6.3 New Optional Syntax for -O Command Line Options
hc now accepts an alternate syntax for the -O command-line
option, which is also accepted by hf77, the Harris Fortran
compiler. The new syntax is of the form -O,arg1[,arg2...],
where arg1, arg2, etc. are keywords from the following list:
minimal, global, maximal, reorder, noreorder, no_reorder,
post_linker, no_post_linker, standard, unsafe, safe.
minimal is a synonym for -O1. global is a synonym for -O2
or just -O. maximal is a synonym for -O3. The other
keywords serve as modifiers for these basic optimization
levels. reorder turns on the use of code reordering for
optimization; noreorder (and no_reorder) turn it off.
post_linker turns on the use of analyze88's post-linker
optimizations; no_post_linker turns it off. standard (and
safe) is equivalent to -Qopt_class=safe. unsafe is
equivalent to -Qopt_class=unsafe. safe and standard are
equivalent to -Qopt_class=standard.
- 4 -
Release Notes 7.1 CX/UX hc C
6.4 88110 Code Generation
hc provides enhanced code generation that takes advantage of
features unique to the 88110 microprocessor in Series 5000
systems. 88110 code generation is selectable via the
TARGET_ARCH environment variable and from the hc command
line via the -Qtarget command-line switch.
See the table later in this section for details about
targets. Code generated for the M88100 target is optimized
for the Series 4000. Code generated for the M88110 target
takes advantage of features unique to the 88110
microprocessor in Series 5000 systems and will not execute
on Series 4000 systems. Also, in this mode, a string
library specially optimized for the Series 5000 is linked
into the executable. Code generated for the M88110compat
target is compatible with the Series 4000, but instructions
are scheduled for optimal execution on the Series 5000.
Executables generated in this mode execute on either the
Series 4000 or the Series 5000.
A preprocessor macro is defined according to the compilation
target. M88100 is the default target for compilation on a
Series 4000. M88110 is the default target for compilation
on a Series 5000.
____________________________________________________________
| Target | Macro | Compile| Schedule| String |
| | | for | for | Library|
|_____________|______________|_________|__________|_________|
| M88100 | M88100 | 88100 | 88100 | 88100 |
| M88110 | M88110 | 88110 | 88110 | 88110 |
| M88110compat| M88110COMPAT| 88100 | 88110 | 88100 |
|_____________|______________|_________|__________|_________|
6.5 Compiler Pass Name Changes
There are now copies of the executables /lib/cxc and
/lib/cxc-reorder for each of the supported architectures.
Their names have been changed to reflect their principal
target architectures. For information about target-
architecture selection, see the preceding section.
/lib/cxc-100 is the compiler pass for M88100 and
M88110compat compilations. /lib/cxc-110 is the compiler
pass for M88110 compilations. /lib/cxc-reorder-100 is the
instruction-scheduler pass for M88100 compilations.
/lib/cxc-reorder-110 is the instruction-scheduler pass for
- 5 -
CX/UX hc C 7.1 Release Notes
M88110 and M88110compat compilations.
6.6 Preprocessor Changes
In past releases, the hc compiler used an internal
preprocessor rather than invoking a separate preprocessing
pass with cpp(1). The current release of hc always makes
use of a separate preprocessing pass either with cpp(1) or
with the new ANSI C preprocessor. This introduces the
following incompatibilities with preprocessing extensions
supported by the Harris hc compiler bundled with versions of
CX/UX prior to version 6.0:
o The sizeof() operator may no longer be used in
conditional compilation expressions (#if expressions).
This practice was never considered to be portable C.
o The #savetable, #loadtable, #pragma push, #pragma pop,
and #pragma optimization directives are no longer
supported.
o The #array_expand Harris-specific directive is no
longer supported.
o The compiler now treats the arguments to #pragma as a
sequence of C tokens. In the past, these were treated
as a character string and divided into tokens according
to rules that were unique to each #pragma directive.
This change should make the behavior of pragmas more
consistent. For example, all pragmas that accept
numeric arguments now accept C hexadecimal and octal
constants as well as decimal constants.
o #pragma must be used with all Harris-specific
directives when the compiler is run in ANSI C
conforming mode (-Xc option).
Note that the Harris #error directive (that controls
the printing of some error messages) has a name
conflict with the ANSI C #error directive (that causes
the compilation to terminate while printing the user-
specified diagnostic message); #pragma error should
always be used when the Harris version is desired.
The use of the external preprocessors has fixed the
following problems with the past release of hc.
- 6 -
Release Notes 7.1 CX/UX hc C
o Macros are now correctly expanded in #include
directives.
o Certain cases of token-splicing macros that failed with
the internal preprocessor now work in Old mode (-Xo
option). However, they typically do not work in the
ANSI C compilation modes (-Xt, -Xa and -Xc options).
6.7 Listing Option Changes
The format of hc compiler-generated listings (-QP option)
has changed. Page headers have a different layout than in
past releases. The use of the external preprocessors forces
some changes in the presentation of macro (-QPX) and include
(-QPa) file expansions (minor variations are noticed
depending on the compilation mode). The following #pragma
listing-control directives are no longer supported:
expandinclude, expandmacro, ident, linelength, list, page,
search, title.
6.8 Problems Fixed with This Release
The following errors in previous releases of hc have been
corrected:
o hc Version 7.1 can compile larger programs than
previous versions.
o Using the -i option could cause an incorrect source
file name to be inserted into the debugging information
in Old (traditional) mode.
o The -P option would cancel out the -g option. Now the
combination of -P and -g produces a preprocessed file
with line-number information included.
o If a single compilation included too many distinct
include files, the compiler would abort with a core
dump.
- 7 -
CX/UX hc C 7.1 Release Notes
7. Future Considerations
As part of Harris' commitment to standards, it can be
expected that in a future release of hc the default
compilation mode will change from Old (traditional) mode to
ANSI C mode. Users are advised to explicitly set
compilation modes on the hc command line as part of their
build procedures.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 8 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
5. Cautions.................................................. 2
6. Changes from Previous Releases............................ 3
6.1 ELF Object Files and Dwarf Debugging................. 3
6.2 -Qfile_buffer_limit Command-Line Option.............. 3
6.3 New Optional Syntax for -O Command Line Options...... 4
6.4 88110 Code Generation................................ 5
6.5 Compiler Pass Name Changes........................... 5
6.6 Preprocessor Changes................................. 6
6.7 Listing Option Changes............................... 7
6.8 Problems Fixed with This Release..................... 7
7. Future Considerations..................................... 8
8. Direct Software Support................................... 8
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/UX HC C
VERSION 7.1
RELEASE NOTES
0891019-7.1
October 1993
_________________________________________________________________
return to index
================================================================================
CX/UX HF77 FORTRAN -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
CX/UX Hf77 Fortran is a Harris Fortran product using Harris
CCG technology. Hf77 accepts standard Fortran 77, all of
the Portable Fortran F77 Compiler extensions, and select
Harris VOS Fortran and DEC Fortran and VAX FORTRAN
extensions.
The executable names hf77 and f77 both refer to the Hf77
compiler.
This release is available for Series 4000 and 5000 systems
and includes the following software. SDE is one of
/usr/sde/{coff,elf,ocs}.
CCG-based Fortran 77 compiler /usr/bin/hf77
/usr/bin/f77
/usr/lib/cxf77-100
/usr/lib/cxf77-110
/usr/lib/cxf77-reorder-100
/usr/lib/cxf77-reorder-110
/usr/lib/hf77cc
Run-time libraries SDE/usr/lib/libhF77.a
SDE/usr/lib/libhI77.a
SDE/usr/lib/libhU77.a
__________
- These release notes cover the following products: hf77
0. DEC Fortran and VAX FORTRAN are trademarks of Digital
Equipment Corporation.
- 1 -
CX/UX Hf77 Fortran 7.1 Release Notes
/usr/sde/elf/usr/lib/libhF77.so
/usr/sde/elf/usr/lib/libhI77.so
/usr/sde/elf/usr/lib/libhU77.so
Support files SDE/usr/lib/vax.o
/usr/lib/libf77.x
Other Fortran 77 family processors /usr/bin/fsplit
/usr/bin/ratfor
/usr/bin/xref
Select Fortran 66 and VOS Fortran 77 /usr/bin/f66_hf77
constructs and conversion scripts /usr/bin/fix_octal
/usr/bin/vos_hf77
/usr/lib/vos_hf77.awk
Man pages for the above.
2. Documentation
The following documentation is included with this release:
___________________________________________________
| Manual Name Pub. Number|
|____________________________________|_____________|
| CX/UX Hf77 FORTRAN Reference Manual| 0890240-050|
| CX/UX Hf77 FORTRAN Release Notes | 0890240-7.1|
|____________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Support Center. The toll-free number is 1-800-245-6453.
For calls outside the continental United States the direct
number is 1-305-971-6248.
3. Prerequisites
Prerequisites for CX/UX Hf77 Fortran Version 7.1 are as
follows:
- 2 -
Release Notes 7.1 CX/UX Hf77 Fortran
3.1 Hardware
o Any Series 4000 or Series 5000 system.
3.2 Software
o CX/UX 7.1.
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
5. Cautions
Included are problems reported in Software Action Requests
(SARs) open as of September 21, 1993. If an SAR is assigned
to a problem, its number appears in parentheses after the
description.
Users are encouraged to retain the source for their
applications. Major releases may provide new object file
formats which require the recompilation of programs.
o This release provides a new object-file format, ELF.
Support for COFF is still available. See the "New
Features" section for details.
o Initializing the same common-block location multiple
times may cause internal errors if the remainder of the
common-block initializations do not occur sequentially
in the storage sequence. (HM10543)
o Variable declarations that appear like typed function
headers confuse the compiler. (HM10806)
o A fatal error in a declaration invalidates the remaining
declarations on the line.
o Compiler syntax error recovery is not successful when a
previously declared PARAMETER is declared again.
(HM10639)
- 3 -
CX/UX Hf77 Fortran 7.1 Release Notes
o When initializing a large character scalar variable
(greater than 1320 characters) with a single character,
an invalid size character constant error occurs.
o Using INTEGER*2 variables in bitwise expressions with
hexadecimal constants may force the result type to be
INTEGER*4. (HM10891)
o The %LOC() intrinsic cannot be used in an I/O list; a
runtime library error is the result. (HM10722)
o A countdown loop with a negative real constant step size
is not entered when the bounds indicate it should be.
(HM10939)
o The compiler does not always detect an explicit
modification of a DO loop variable within the range of
the loop.
o The compiler does not generate an error for I/O
qualifiers with incorrect character values, e.g.,
specifying ACCESS=APPEND in an OPEN statement when
ACCESS="APPEND" was intended. (HM10662)
o The I/O ERR= branch is not taken for quota exceeded
error in WRITE statements. (HM08749)
o The use of a / format descriptor does not advance the
record pointer on an internal read. (GH0258)
o Tab characters in source files are not expanded to tab
stops, but treated as a single space except at the
beginning of the line, where they indicate the end of
the statement label field. This will cause problems if
tabs are expected to affect column positioning elsewhere
in source files. (HM10367) Tabs in the statement label
field are treated differently with the -VAX option; see
the CX/UX Hf77 Fortran Reference Manual for details.
o Error message line numbers are not always accurate when
source files INCLUDE other source files.
o Entry points do not have debug entries. (HM10494) Line
number debug entries may occasionally be incorrect.
(HM10553)
o The compiler does not generate an error for statement
label 0. (HM10622)
- 4 -
Release Notes 7.1 CX/UX Hf77 Fortran
o The Fortran library depends heavily on the AT&T versions
of the C libraries, so mixing Fortran and C in the UCB
universe will cause problems. (HM10327)
o Array subscript bounds checking (-C) does not check
values of individual subscripts, but rather overruns of
the entire array storage. (HM10444)
o The compiler may abort if bounds checking (-C) is used.
(HM10482)
o A several-thousand-line subprogram that uses several
hundred or more variables may take an inordinately long
time to compile with global optimization (-O2) or
higher. (HM10818)
o Code generated with the -g debug option in the COFF SDE
is slightly slower than code without it. Value
consistency is maintained between a temporary copy of a
variable in a CPU register and that variable's location
in memory. This is not the case in the ELF SDE.
o gdb can only access DATAPOOL variables through their
constructed name. (HM10864)
o The compiler runs out of memory when compiling programs
containing very large functions. (HM10982)
o The traper and trapfpe functions don't always return the
old error mask value as they should. (HM10961 and
HM10962)
o Certain EQUIVALENCE conditions may throw xref(1) into an
infinite loop. (HM11078)
6. New Features in this Release
o The hf77 compiler now supports two object-file formats:
COFF and ELF. COFF is the object-file and debugging
format traditionally supported by CX/UX. ELF is the
new, SVR4-compatible, object-file format, and Dwarf is
the debugging format supported by CX/UX in ELF-format
object files. ELF is the CX/UX 7.1 default object-file
format.
While the same compiler is used to generate object in
either of these two formats, other tools such as as(1)
- 5 -
CX/UX Hf77 Fortran 7.1 Release Notes
and ld(1), and the libraries have different formats. The
new -Z command-line option and the SDE_TARGET
environment variable may be used to choose which
object-file format to work with. Please refer to the
hf77(1) man page for information about SDE_TARGET and
the -Z option. Also, the CX/UX Programmer's Guide and
CX/UX Support Tools Guide contain more information about
the object-file formats and the tools that deal with
them.
The ELF object-file format supports shared objects,
allowing multiple processes to share the same executing
text thus saving real memory. Shared-object versions of
the Fortran libraries are supplied along with the ELF
static and traditional COFF versions. Shared-object
versions of the libraries are used by default in the ELF
software development environment (SDE). The -Z option
and the STATIC_LINK environment variable are used to
specify the library version the executable is linked
with.
Because of the additional object-file format, many of
the support files used by hf77 are now SDE-specific. See
the "FILES" section of the hf77(1) man page for details.
o The -o object-name option is accepted for renaming the
resulting object file. This usage is recognized when
the -c option is specified, there is one source file,
and the -o option appears before the source file name on
the command line.
o The -h shared-object-name option is accepted while
building a shared object. shared-object-name is the
name recorded for the shared object.
o The -O option now accepts keywords to control
optimization level, safety, and optimizations performed
by the instruction reorder tool and post-link optimizer.
See the hf77(1) man page for details.
o The -Qskew_large_arrays option is accepted for
encouraging efficient cache usage. See the hf77(1) man
page for details.
o The TARGET_ARCH environment variable is accepted as an
alternative to -Qtarget=. See the hf77(1) man page for
details.
- 6 -
Release Notes 7.1 CX/UX Hf77 Fortran
o Other new -Q options include -Qinvert_divides, -Qnotic,
-Qschedule_tn_window=N, -Qtic, and
-Qtime_conflict_stages=N.
6.1 Other Features
An SAR number in parentheses follows the description of an
extension if the extension was prompted by an SAR.
o The new POINTER statement may be used to declare a
pointer block. Essentially a based common block, a
pointer block allows the user to declare an unallocated
block of variables, the base address of which is
supplied by the user via a simple assignment statement.
See the CX/UX Hf77 Fortran Reference Manual section 4.20
for more details. Additionally, the sizeofblock(3f)
intrinsic is provided to query the size of a declared
pointer block.
o The new malloc(3f), calloc(3f), realloc(3f) and free(3f)
routines assist in dynamic memory management for pointer
blocks.
o Special floating-point values +/- infinity, +/-
signaling NaN (Not-a-Number) and +/- quiet NaN are
printed in mnemonic form rather than as asterisks or
forcing an exception. (HM10730)
o A warning message is generated when the CCG optimizer
has detected a use of an uninitialized variable.
(HM10644)
o The CCG optimizer examines logical operators .AND. and
.OR. and does not short-circuit these operations if the
operands are inexpensive to evaluate. Reexamine
-Qno_short_circuit if it is used for performance
reasons. See the CX/UX Hf77 Fortran Reference Manual
section 3.4.5 for more details.
o The IIDNNT() and JIDNNT() intrinsics are provided.
o Generated code is slightly faster.
- 7 -
CX/UX Hf77 Fortran 7.1 Release Notes
7. Changes from Previous Releases
7.1 Compiler Pass Name Changes
There are now copies of the executables /usr/lib/cxf77 and
/usr/lib/cxf77-reorder for each of the supported
architectures. Their names have been changed to reflect
their principal target architectures. The hf77 driver
selects the correct compiler and instruction scheduler based
on the setting of the -Qtarget= command-line option, the
TARGET_ARCH environment variable, or the compilation
architecture if no architecture is specified.
/usr/lib/cxf77-100 is the compiler for M88100 and
M88110compat compilations. /usr/lib/cxf77-110 is the
compiler for M88110 compilations. /usr/lib/cxf77-reorder-
100 is the instruction scheduler for M88100 compilations.
/usr/lib/cxf77-reorder-110 is the instruction scheduler for
M88110 and M88110compat compilations.
7.2 Other Changes
Most of the changes provided in this release are a result of
SARs received. The number in parentheses following each
change is the assigned SAR number that prompted the
modification.
o Subroutines no longer pass an incorrect value when an
IMPLICIT CHARACTER(A-Z) statement is used in a main
program. (HM10819)
o The compiler no longer dumps core when compiling BLOCK
DATA statements with the profiling option -p turned on.
(HM10862)
o The compiler no longer gives an error when compiling the
statement PARAMETER (IBITMASK = X'80000000'). (HM11003)
o Giving an integer value as the value of a CHARACTER*1
parameter now generates a relevant error rather than
causing the compiler to dump core. (HM10884)
o DATAPOOL block variables can now appear in NAMELIST I/O
statements. (HM10863)
o END DO statements can now be labeled. (HM10607)
o Invalid -Q options no longer causes the compiler to
abort. (HM10786)
- 8 -
Release Notes 7.1 CX/UX Hf77 Fortran
o Initial values for members of a common block initialized
in multiple files including BLOCK DATA subprograms are
now correct. Where multiple initializations conflict,
the values are bitwise-ORed together. (HM10453)
A complete list of all SARs closed for this release is, as
follows:
HM10453, HM10607, HM10786, HM10819, HM10862, HM10863,
HM10884, HM11003.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 9 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 2
3. Prerequisites............................................. 2
3.1 Hardware............................................. 3
3.2 Software............................................. 3
4. Installation.............................................. 3
5. Cautions.................................................. 3
6. New Features in this Release.............................. 5
6.1 Other Features....................................... 7
7. Changes from Previous Releases............................ 8
7.1 Compiler Pass Name Changes........................... 8
7.2 Other Changes........................................ 8
8. Direct Software Support................................... 9
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/UX HF77 FORTRAN
VERSION 7.1
RELEASE NOTES
0890240-7.1
October 1993
_________________________________________________________________
return to index
================================================================================
CX/UX VCOM X.25/DDN -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The VCOM X.25 software package provides access to the VCOM
X.25 controllers having the X.25/LAPB/WAN software resident
on the controllers.
This release contains the software utilities that allow a CX
system to communicate with another system with X.25 either
directly or through a Public Data Network. The package
provides an interface that allows TCP/IP utility programs to
operate over the X.25 link.
The VCOM X.25 STREAMS driver will provide an interface to
the NLI, LAP-B, and WAN layers via the SBE VCOM-24/34
multi-channel high-speed synchronous communications
controller. A programatic interface for CX/SX is not being
provided.
The driver/controller will support the following standards
and physical interfaces:
o CCITT X.25(80), X.25(84), and X.25(88)
o ISO 8208 support for DTE-DTE operation
o X.25 Level III '80, '84, and '88 Basic and extended
packet sequence numbering.
o X.25 Level II LAPB '80, '84, and '88. Basic and
extended frame sequencing not supported in '80 version.
__________
- These release notes cover the following products: VCOM
X.25 and DDN
- 1 -
CX/UX VCOM X.25/DDN 7.1 Release Notes
o DTE and DCE operation.
o EIA-232-C
o EIA-449
o V.35
2. Documentation
The following documentation is included with this release:
_________________________________________________
| Manual Name Pub. Number|
|__________________________________|_____________|
| CX/UX Networking Reference Manual| 0890118-060|
| CX/UX VCOM X.25 User's Guide | 0890417-010|
| CX/UX VCOM X.25 Release Notes | 0890417-7.1|
|__________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
3. Prerequisites
Prerequisites for CX/UX VCOM X.25/DDN Version 7.1 are as
follows:
3.1 Hardware
o Any Series 4000 or Series 5000 system.
o VCOM X.25 controller and interface specific ports.
- 2 -
Release Notes 7.1 CX/UX VCOM X.25/DDN
3.2 Software
o CX/UX 7.1
o CX/UX STREAMS.
o CX/UX TCP/IP.
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
5. Cautions
DDN cannot be run concurrently over two different types of
communications controllers.
The DDN interface is supported only on VCOM boards 0 and 1
(vc0 and vc1).
6. New Features in this Release
None.
7. Changes from Previous Releases
None.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
- 3 -
CX/UX VCOM X.25/DDN 7.1 Release Notes
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 4 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 2
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 3
4. Installation.............................................. 3
5. Cautions.................................................. 3
6. New Features in this Release.............................. 3
7. Changes from Previous Releases............................ 3
8. Direct Software Support................................... 3
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/UX VCOM X.25/DDN
VERSION 7.1
RELEASE NOTES
0890417-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
NETWORK FILE SYSTEM (NFS) -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The Network File System (NFS) allows files on a remote
system to be accessed as though they were local.
2. Documentation
The following documentation is included with this release:
_______________________________________________________
| Manual Name Pub. Number|
|________________________________________|_____________|
| CX/UX Network File System | 0890170-030|
| Network File System (NFS) Release Notes| 0890170-7.1|
|________________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
__________
- These release notes cover the following products: nfs
1 NFS is a trademark of Sun Microsystems, Inc.
- 1 -
Network File System (NFS) 7.1 Release Notes
3. Prerequisites
Prerequisites for Network File System (NFS) Version 7.1 are
as follows:
3.1 Hardware
o Any Series 4000 or 5000 system.
3.2 Software
o CX/UX 7.1
o TCP/IP 7.1
o Ethernet 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
Please refer to the CX/UX Network File System Reference
Manual, Appendix A, for instructions specific to installing
NFS.
5. Cautions
None.
6. New Features in this Release
A new kernel configuration option, RNODES, specifies the
maximum number of rnodes the system will create before
reusing cached rnodes (rnodes that have cached pages
associated with them but are not currently in use). This is
not a hard limit; if there are no free rnodes, new ones are
created as needed. The default value of this option is the
configured number of inodes.
- 2 -
Release Notes 7.1 Network File System (NFS)
7. Changes from Previous Releases
The kernel configuration options NFSSERVER and NFSCLIENT are
now completely independent of each other. Previous releases
would enable both options if either option was enabled.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 3 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
5. Cautions.................................................. 2
6. New Features in this Release.............................. 2
7. Changes from Previous Releases............................ 3
8. Direct Software Support................................... 3
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
NETWORK FILE SYSTEM (NFS)
VERSION 7.1
RELEASE NOTES
0890170-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
OSI LAN TRANSPORT, ETHERNET -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The OSI (Open Systems Interconnection) LAN (Local Area
Network) Transport protocol software package allows
communication between Harris hosts (computers), and between
Harris hosts and hosts from other vendors who run the OSI
LAN protocol. Ethernet, an optional product that is used in
conjunction with the OSI LAN protocol, is also described
here. The OSI LAN Transport package can also be utilized
with the optional TCP/IP package to create a dual protocol
LAN environment. Usage of such a dual protocol environment
will not require additional or special Ethernet or FDDI
(LAN) adapters as both protocols can share common adapters.
Since OSI LAN networks are commonly integrated within TCP/IP
networks, it is recommended that the optional TCP/IP
software package be utilized in conjunction with the OSI LAN
package. This protocol combination will enhance the
system's communication/networking capabilities.
The OSI LAN Transport package is based upon the Retix LAN
Transport software package and operates in a STREAMS-based
environment. The OSI LAN Transport package is accessible
via the USL Transport Layer Interface (TLI) library libnsl
which is provided with the CX/UX Operating System software
package. The OSI LAN Transport package provides the
following OSI protocols: Transport Class 4 (ISO 8073),
Connectionless Transport (ISO 8602), Connectionless Network
(ISO 8473), and End System to Intermediate System Routing
(ISO 9542). Depending on the number of LAN adapters
configured into the system, a Night Hawk system will be
automatically configured as either an OSI End System or ES
__________
- These release notes cover the following products:
osi_lan and ethernet
- 1 -
OSI LAN Transport, Ethernet 7.1 Release Notes
(single LAN adapter) or as an OSI Intermediate System or IS
(two or more LAN adapters).
The OSI LAN Transport package supports the CX/Retix OSI File
Transfer, Access, and Management (FTAM) and Virtual Terminal
(VT) applications.
2. Documentation
The following documentation is included with this release:
____________________________________________________________________
| Manual Name Pub. Number|
|_____________________________________________________|_____________|
| OSI LAN Transport Administration Guide | 0890419-000|
| OSI LAN Transport Programmer Guide | 0890441-000|
| Network Directory Compiler Reference Manual | 0890446-000|
| OSI LAN Transport,Ethernet Version 7.1 Release Notes| 0890419-7.1|
|_____________________________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
- 2 -
Release Notes 7.1 OSI LAN Transport, Ethernet
3. Prerequisites
Prerequisites for OSI LAN Transport version 7.1 are as
follows:
3.1 Hardware
o Any Harris Series 4000 or 5000 system.
o Special hardware is needed and is dependent upon the
type of network on which OSI LAN Transport is run. One
or more of the following is needed: an Ethernet
controller and/or an FDDI controller.
3.2 Software
o CX/UX 7.1
o STREAMS 7.1
o Ethernet 7.1
4. Installation
Refer to the CX/UX System Administration Manual, Chapter 3,
for instructions on software installation.
4.1 Product Installation
The OSI LAN Transport product is installed in the following
fashion:
/etc - OSI LAN Transport stack configuration file
osid.cfg.
/usr/bin/osi - OSI LAN Transport utilities.
/usr/catman - OSI LAN Transport on-line manual pages.
/usr/doc - RFC 1237 NSAP guidelines document.
/usr/etc - OSI LAN Transport kernel daemon and
initialization script.
- 3 -
OSI LAN Transport, Ethernet 7.1 Release Notes
/usr/include/netosi - OSI LAN Transport include files.
/usr/man - Formatted source copies of the OSI LAN
Transport manual pages.
/usr/src/uts/machine/[M88K][NH5000] - OSI LAN Transport
kernel object module.
/usr/src/uts/machine/netosi - Subdirectories containing
OSI LAN Transport kernel include and configuration files.
4.2 Kernel Configuration
Once the OSI LAN Transport software module has been
installed, the kernel must be configured and rebuilt and
relinked to include the OSI LAN Transport stack. To do
this, uncomment the following options in the kernel
configuration file prior to recompilation:
mbufs #See Kernel STREAMS Buffers Memory Allocation below
options STREAMS #STREAMS support
options "NSTRPUSH" #No. of pushes per stream
options "STRCTLSZ" #Max size of control portion of any
message
options NCLONE #Clone driver minor devices
options NLOG #Log driver minor devices (Optional
configurable item)
options NTIRDWR #TLI read/write module minor devices
options NTIMOD #TLI cooperating module minor devices
options OSILAN #OSI LAN Transport stack support
Depending on the system's hardware configuration, uncomment
one or more of the following options to configure LAN
controllers prior to recompilation:
device pg[0-2] #Interphase Peregrine FDDI controller
device ie[0-3] #Integral Ethernet controller
device eg[0-3] #Interphase Eagle Ethernet controller
- 4 -
Release Notes 7.1 OSI LAN Transport, Ethernet
NOTE: The OSI LAN Transport product can operate in a kernel
configured with TCP/IP (i.e., INET and SOCKETS options).
4.3 osi_space.c OSI LAN Transport Configuration File
System or network administrators should note the existence
of the /usr/src/uts/machine/netosi/lan/tp4/osi_space.c OSI
LAN Transport/Network stack configuration file. This file
contains kernel compilation variables whose values affect
the behavior and operation of the OSI LAN stack. Such items
include the number of OSI LAN Transport connections
supported, Transport and Network Layer default configuration
values, ES-IS routing table sizes, etc. This file is
compiled each time the kernel is rebuilt. Only experienced
OSI LAN Transport users should make modifications to this
file.
4.4 Kernel STREAMS Buffers Memory Allocation
STREAMS buffers used by the OSI LAN Transport product are
dynamically allocated and deallocated via kernel memory.
OSI LAN Transport performance is affected by the amount of
STREAMS buffers which are available to the protocol stack.
In order to ensure that there will be enough STREAMS buffers
for OSI operation, the number of interrupt-level CX kernel
memory pools should be increased. There are two types of
memory pools available to the kernel. The first type,
kma_small_ipools, are used for small sized allocations of
256 bytes or less. The other type, kma_large_ipools, are
used for allocations of more than 256 bytes, but not greater
than 4096 bytes. The size of STREAMS buffers usually falls
into the kma_large_ipools category, but can also be found in
the size ranges specified in the kma_small_ipools category
as well.
The number of kernel memory pools is determined in the
/usr/src/uts/machine/cf/space.c file. The values are
determined by the following equations:
int kma_small_ipools = (OSILAN + NIPH) * 24 + 1
int kma_large_ipools = (OSILAN + NIPH) * 24 + 1
As can be seen in the above equations, the number of memory
pools is determined by the OSI LAN Transport product's
kernel configuration and the number of Intelligent
Networking devices (iph) configured in the kernel (NIPH).
- 5 -
OSI LAN Transport, Ethernet 7.1 Release Notes
Both products require STREAMS buffers and as such their
existence will determine the number of such pools. It
should be noted that neither product (OSILAN or IPH) is
dependent upon the other. For normal OSI operations, the
more STREAMS buffers available, the more rapidly OSI
networking can acquire them, and the better OSI performance
will be. If there are too few buffers, then performance
will drop as OSI resources must wait to acquire buffers
already in use.
If the default value of 25 pools of each type (i.e., (OSILAN
(1) + NIPH (0)) * 24 + 1 = 25) is insufficient to meet your
OSI LAN stack requirements, it is recommended that the value
of 1 in the above equations be changed to a multiple of
eight in order to ensure that there will be sufficient
numbers of pools for OSI STREAMS buffer allocation. After
changing the equation, the kernel must be rebuilt in order
for the modification to take effect. The larger the number,
the more memory pools that will be available. It should be
noted that a large number of memory pools will result in a
larger kernel.
CX STREAMS also utilizes loaned memory buffers, also known
as mbufs, for usage with CX LAN adapters. System
administrators should also be aware of the mbufs kernel
parameter in the kernel configuration file located under
/usr/src/uts/machine/cf. This parameter is responsible for
determining the number of kilobytes of kernel memory which
will be allocated for use by the kernel for mbufs. By
default, the mbufs parameter is commented out in the kernel
configuration file and as such, its value defaults to 512.
Under normal conditions, this default value should be
sufficient, but if heavy OSI usage is expected, the mbufs
parameter should be uncommented and its value should be
doubled or set to an even greater value. Again it should be
noted that increasing this value will result in a larger
overall kernel size. It is recommended that NH5000 OSI
users increase this kernel parameter.
Any modifications to the parameters discussed above will
require a kernel rebuild and relink.
4.5 OSI LAN Transport Run Time Configuration
Examine the /etc/osid.cfg file for run time configuration
parameters necessary to activate the OSI LAN Transport
stack. This file is read by the OSI protocol stack
configuration and management daemon, /usr/etc/osid. OSI
- 6 -
Release Notes 7.1 OSI LAN Transport, Ethernet
daemon control operations (start/stop) are handled by the
/usr/etc/osi.rc script which is accessed by the /etc/rc
script at multiuser boot time. The parameters contained in
the osid.cfg file determine the STREAMS configuration of the
OSI module at the time it is activated and specify which LAN
adapters STREAMS should be established with. Consult
Chapter 2 of the OSI LAN Transport Administration Manual for
further information.
4.6 /dev Device Creation
Before rebooting the kernel, use the makedev(1M) utility to
create the following /dev devices which are referenced in
the /etc/osid.cfg configuration file:
sld - CX STREAMS Interface LAN Driver
cots - STREAMS Connection-oriented Transport Service
Driver
clts - STREAMS Connectionless Transport Service Driver
tmr - STREAMS OSI Timer Driver
stie0, steg[0-7], and/or stpg[0-7] - STREAMS LAN
controller interface depending on which LAN controller(s)
is configured in your system. stie - Integral Ethernet,
steg - Interphase Eagle Ethernet, or stpg - Interphase
Peregrine FDDI.
OPTIONAL: cotz or cltz - STREAMS TP4 and CTLP drivers
utilizing the Inactive Network Layer Protocol (INLP). See
inactive(1M).
It should be noted that access restrictions have been placed
on the STREAMS LAN controller interfaces. Once a STREAMS
LAN controller interface has been opened, it cannot be
opened again by another process until the original opening
process has closed the interface device.
4.7 /etc/rc Script Modifications
Before rebooting the reconfigured and rebuilt OSI LAN
Transport kernel, examine the /etc/rc script for OSI LAN
Transport-specific options which will need to be
uncommented. Modify the section entitled OSI Networking in
the etc/rc script. This section will configure and
- 7 -
OSI LAN Transport, Ethernet 7.1 Release Notes
initialize the OSI LAN Transport protocol stack when the
system enters multi-user mode. Also examine the single user
mode section for OSI LAN Transport shutdown logic which must
be uncommented.
Examine the OSI Networking section entries. If the system
will act as an OSI intermediate system, administrators will
need to assign an OSI Network Entity Title (NET) to identify
the system on the OSI network (see net(1M)). If the system
will act as an OSI end system (or an OSI intermediate
system), Network Service Access Points (NSAPs) will need to
be assigned to identify unique "addresses" or "access
points" used by various OSI applications such as File
Access, Transfer, and Management (FTAM) filestores, Virtual
Terminal (VT) responders, etc. (see nsap(1M)). See the
section entitled NET/NSAP Assignment for information
concerning the assignment of a NET and/or NSAPs for your
system. If this system will act as an OSI intermediate
system which must route to other local OSI intermediate
systems, then a static routing table must be created via the
Network Directory Compiler tool (ndc(1M)) and downloaded
into the kernel at boot time.
CX OSI-based kernels which will not contain a dual protocol
environment (i.e., both TCP/IP (Internet) and OSI LAN
Transport) will not be able to utilize the Internet
ifconfig(1M) LAN adapter configuration utility calls in the
/etc/rc script. Therefore system administrators should not
uncomment these calls in the /etc/rc script when an OSI-only
protocol environment is used. All appropriate LAN adapters
specified in the /etc/osid.cfg file (i.e., those associated
with the PORTn parameters) will be automatically
configured/activated when the OSI protocol stack is
activated via the /usr/etc/osi.rc script which calls the OSI
daemon /usr/etc/osid. This script is activated via an entry
in the /etc/rc script.
If a dual protocol stack kernel is utilized, all LAN
adapters which will be utilized by TCP/IP must access the
appropriate ifconfig(1M) calls in the /etc/rc script. Use
of the ifconfig call for LAN adapters which will be shared
by both TCP/IP and OSI is acceptable.
- 8 -
Release Notes 7.1 OSI LAN Transport, Ethernet
4.8 NET/NSAP Assignment
Specifying a NET or NSAP(s) in the /etc/rc script requires
some understanding of OSI addressing. OSI provides many
different formats for use in determining and assigning a NET
or NSAP. Each format is tailored for use in a particular
OSI environment. For information on OSI address formats,
consult the Network Directory Compiler Reference Manual
(HCSD Publication #0890446). U.S. Government OSI users
should also refer to RFC 1237 located under /usr/doc for
additional information concerning NSAP allocation.
An integral part of any NET or NSAP is the Subnetwork Point
of Attachment (SNPA) address. A SNPA is the OSI term for a
communications device attached to the system. In the case
of OSI LAN Transport, the Ethernet ie and eg devices and the
FDDI pg device are considered SNPAs. A SNPA address is the
physical address of the device. The SNPA address is also
referred to as the Media Access Control (MAC) address. A
typical SNPA address consists of 6 octets (bytes). For
example, a SNPA address for an Integral Ethernet (ie) device
might be 00 00 C9 E5 B4 04. Each SNPA address is unique to
each LAN device. Unless you have access to hardware
documentation or network analysis equipment, obtaining SNPA
addresses is not normally straight forward. Use of the run
time configuration daemon, osid, can assist in determining
the SNPA address of each LAN device configured for OSI LAN
Transport usage. When the osid daemon is activated in
verbose mode using the -v option, it will display startup
information on the screen. The SNPA address (MAC address)
of each configured LAN device will be displayed. With this
addressing information, a NET or NSAP(s) can be developed.
The use of the -v verbose option with the osid daemon is not
recommended for normal OSI LAN Transport operation. This
option should only be used during initial system setup to
assist administrators with configuration information.
4.9 OSI LAN Transport Manuals and Manual Pages
After the OSI LAN Transport package has been installed,
examination of the provided documentation and on-line manual
pages is recommended in order to gain familiarity with the
product. To locate all of the OSI LAN Transport on-line
manual pages, enter the following command:
/bin/man -k OSI | pg
- 9 -
OSI LAN Transport, Ethernet 7.1 Release Notes
5. Transport Layer Interface (TLI)
As mentioned previously, the OSI LAN Transport product is
accessible from user-level application programs which
utilize the USL Transport Layer Interface (TLI). This
library is located in /usr/lib/libnsl.a. See the OSI LAN
Transport Programmer Guide (HCSD Publication #089441) and
tp4(4P) for detailed information on utilizing TLI functions
with the OSI LAN Transport product.
6. X/Open Transport Interface (XTI)
There is no OSI LAN Transport support in the X/Open
Transport Interface located in /usr/lib/libxti.a. XTI OSI
applications (i.e., those accessing the ISO Transport
Protocol Information features of XTI) must be converted to
the appropriate TLI functions/structures. Most notable of
these conversions are the following:
o The buf field of the struct netbuf argument utilized by
the connection-oriented XTI functions, t_accept(),
t_connect(), t_rcvconnect(), and t_optmgmt() must be
converted from a struct isoco_options to a variable-
sized buffer containing one or more options with each
option consisting of three fields. For more detail on
this variable sized buffer and the option format,
consult the OSI LAN Transport Programmer Guide (HCSD
Publication # 0890441).
o The buf field of the struct netbuf argument utilized by
the connectionless mode XTI functions, t_sndudata(),
t_rcvudata(), and t_optmgmt() must be converted from a
struct isocl_options to a variable-sized buffer
containing one or more options with each option
consisting of three fields. For more detail on this
variable sized buffer and the option format, consult
the OSI LAN Transport Programmer Guide (HCSD
Publication # 0890441).
7. Cautions
None.
- 10 -
Release Notes 7.1 OSI LAN Transport, Ethernet
8. New Features in this Release
None.
9. Changes from Previous Releases
None.
10. Recommended Reading Material
The following introductory references are recommended for
users who are unfamiliar with OSI LAN protocols:
Uyless Black. OSI: A Model for Computer Communication
Standards. Prentice-Hall, Inc., 1991. ISBN 0-13-
637133-7.
John Henshall and Sandy Shaw. OSI Explained: end-to-end
computer communication standards. Ellis Horwood Limited,
1990. ISBN 0-13-639451-5.
William Stallings. Handbook of Computer-Communications
Standards. Volume 1, Second Edition. The Open Systems
(OSI) Model and OSI-Related Standards. Howard W. Sams &
Company, 1990. ISBN 0-672-22697-9.
William Stallings. Networking Standards: A Guide to
OSI, ISDN, LAN, and MAN Standards. Addison-Wesley
Publishing Company, Inc., 1993. ISBN 0-201-56357-6.
The following introductory references are recommended for
users who are unfamiliar with STREAMS and the Transport
Layer Interface (TLI):
UNIX System V Release 4 Programmer's Guide: Networking
Interfaces. HCSD Publication Number 0890396.
UNIX System V Release 4 Programmer's Guide: STREAMS.
HCSD Publication Number 0890397.
- 11 -
OSI LAN Transport, Ethernet 7.1 Release Notes
11. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 12 -
CONTENTS
1. Introduction............................................ 1
2. Documentation........................................... 2
3. Prerequisites........................................... 3
3.1 Hardware........................................... 3
3.2 Software........................................... 3
4. Installation............................................ 3
4.1 Product Installation............................... 3
4.2 Kernel Configuration............................... 4
4.3 osi_space.c OSI LAN Transport Configuration
File............................................... 5
4.4 Kernel STREAMS Buffers Memory Allocation........... 5
4.5 OSI LAN Transport Run Time Configuration........... 6
4.6 /dev Device Creation............................... 7
4.7 /etc/rc Script Modifications....................... 7
4.8 NET/NSAP Assignment................................ 9
4.9 OSI LAN Transport Manuals and Manual Pages......... 9
5. Transport Layer Interface (TLI)......................... 10
6. X/Open Transport Interface (XTI)........................ 10
7. Cautions................................................ 10
8. New Features in this Release............................ 11
9. Changes from Previous Releases.......................... 11
10. Recommended Reading Material............................ 11
11. Direct Software Support................................. 12
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
OSI LAN TRANSPORT, ETHERNET
VERSION 7.1
RELEASE NOTES
0890419-7.1
November 1993
_________________________________________________________________
Trademark Acknowledgments
Ethernet is a registered trademark of Xerox Corporation
Retix is a registered trademark of Retix
return to index
================================================================================
CX/UX RJE -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
This release contains the software utilities that allow a CX
system to emulate an IBM RJE, 2780, or 3780 workstation.
The package provides emulation for the various functions of
the workstation, including operator's console, multiple
printers, and card punches and readers.
2. Documentation
The following documentation is included with this release:
_______________________________________
| Manual Name Pub. Number|
|________________________|_____________|
| CX/UX RJE User's Guide | 0890364-000|
| CX/UX RJE Release Notes| 0890364-7.1|
|________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
__________
- These release notes cover the following products: rje
- 1 -
CX/UX RJE 7.1 Release Notes
3. Prerequisites
Prerequisites for CX/UX RJE Version 7.1 are as follows:
3.1 Hardware
o Any Series 4000 or 5000 system.
o MPCC-16 board set.
3.2 Software
o CX/UX 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
1) The installer must cd to the /dev directory and type the
following:
MAKEDEV mrje
2) The following option line in the system configuration
file must be uncommented:
# Max number of rje MPCC ports
# Uncomment the next line if mpcc rje is to be built into kernel
options MPCCRJE=8
3) The installer may then rebuild the kernel. Consult the
CX/UX System Administration Manual, Chapter 4, for further
instructions.
4) The protocol for each RJE, 2780, or 3780 port must be
changed to RJE in the file /etc/mpcctab.
5) The host config file in the directories
/usr/spool/rje/host_name must be modified to contain the
correct device number and protocol name.
- 2 -
Release Notes 7.1 CX/UX RJE
5. Cautions
None.
6. New Features in this Release
None.
7. Changes from Previous Releases
None.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 3 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
5. Cautions.................................................. 3
6. New Features in this Release.............................. 3
7. Changes from Previous Releases............................ 3
8. Direct Software Support................................... 3
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/UX RJE
VERSION 7.1
RELEASE NOTES
0890364-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
SVVS TEST SUITE -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The System V Verification Suite Release 4 (SVVS4) is a set
of programs and scripts provided by AT&T to determine
whether an operating system conforms with the System V
Interface Definition, Third Edition (SVID3). These release
notes contain information on setup and operation of SVVS4
under CX/UX 7.1. The test suite itself is not included in
the product and must be obtained separately.
2. Documentation
The following documentation is included with this release:
_____________________________________________
| Manual Name Pub. Number|
|______________________________|_____________|
| SVVS Test Suite Release Notes| 0891045-7.1|
|______________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
Refer to the System V Verification Suite (SVVS) Release 4.0
Users Guide for installation and operation instructions
__________
- These release notes cover the following products: SVVS
test suite
- 1 -
SVVS Test Suite 7.1 Release Notes
specific to this product. Copies of the SVVS Release 4.0
Users Guide, select code #320-608, may be obtained from
AT&T.
- 2 -
Release Notes 7.1 SVVS Test Suite
3. Prerequisites
Prerequisites for running the SVVS Test Suite Release 4.0
under CX/UX are as follows:
3.1 Hardware
o Any Series 4000 or Series 5000 system.
3.2 Software
o CX/UX 7.1
o TCP/IP 7.1
o STREAMS 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
Also refer to the SVVS Release 4.0 Users Guide for
installation and operation instructions specific to this
product.
5. Cautions
None
6. SVVS Functional Groupings
CX/UX 7.1 will pass the Base (BA) and Kernel Extensions (KE)
sections of System V Verification Suite 4.0. Base consists
of four subsections: BA/DEV, BA/ENV, BA/LIB and BA/OS.
Kernel Extensions consists of two subsections: KE/ENV and
KE/OS.
- 3 -
SVVS Test Suite 7.1 Release Notes
7. Setup and Operation
7.1 STREAMS and TLI
SVVS4 requires the implementor to include four STREAMS test
drivers and four STREAMS modules in the CX/UX kernel used
while the tests are being run. These are used for the
STREAMS and Transport Level Interface (TLI) tests. The
original source for these modules and drivers along with the
required header files are provided with SVVS4. However, the
CX/UX Multithreaded Kernel requires minor modifications to
the modules. In addition, configuration file entries must
be made to provide the necessary linkages to the drivers.
The multithreading changes and configuration file entries
necessary to run SVVS4 are provided with standard CX/UX 7.1.
The eight modules and drivers are also available in Release
7.1. However, they are configured out of the system to avoid
affecting normal system operation.
The procedures necessary to configure and run SVVS4 are as
follows:
1. Ensure that the svvs_tests product has been properly
installed on the system. This product includes the
kernel files necessary to configure the kernel to run
the STREAMS and TLI tests.
2. Add the following line
options SVVS_TESTS
to the configuration file used to build the kernel.
This causes the STREAMS modules and drivers to be
included, as well as, the configuration table entries
necessary to pass control to them.
3. Add the following line
options STRM_FIFO
to the configuration file used to build the kernel.
This causes the file system fifos and pipes to utilize
the STREAMS system instead of the sockets system. Some
of the tests depend upon STREAMS calls (getmsg(2),
putmsg(2)) working on fifos.
4. Uncomment the options STREAMS line, as well as, the
NLOG, NCLONE, and NTIMOD lines.
5. Run /etc/config and relink the kernel.
- 4 -
Release Notes 7.1 SVVS Test Suite
6. In the /dev directory, device entries must be made for
the streams devices. The major number used will vary
with the CX/UX Release. With Release 7.1, the first
major number is 116 as shown below. This may change
with subsequent releases. Also, all special files must
be readable and writeable by all processes. Enter the
following commands:
cd /dev
mknod lo0 c 116 0
mknod lo1 c 116 1
mknod lo2 c 116 2
mknod tidg c 49 117
mknod tivc c 49 118
mknod tmux c 49 119
chmod 666 lo0 lo1 lo2 tidg tivc tmux
The '49' value is the major number of the clone driver
which should remain constant. The minor numbers for
the tidg, tivc, and tmux devices will change when the
major number for the lo* devices (currently 116)
changes; they sequentially follow the major number.
7. The /dev/console special file must be readable and
writeable by all processes (this must be done after
each reboot).
cd /dev
chmod 666 console
7.2 Configuration Files
The following configuration files must be edited to conform
to the system where the SVVS4 tests are to be built and run.
Example files are provided.
7.2.1 Installation_Script
The installation script specifies the SVVS4 source and
destination directories and the compiler options used for
building. Typically, this script should be created under
the SOURCE directory.
Example file:
source /usr/svvs
destination /usr/svvs
- 5 -
SVVS Test Suite 7.1 Release Notes
compiler cc
options -O -w -q -Xa
libraries -lm -lmalloc -lgen -lnsl
extensions SHM CRYPT ENCRYPT SETKEY
sections src/tools src BA KE
print
7.2.2 sv_const.h
The file SOURCE/include/sv_const.h contains constants that
are built into the SVVS4 executable files. The following
example file contains "typical" values for CX/UX systems:
#define SV_CHILD_MAX 50 /* maximum number of processes per user */
#define SV_PIPE_MAX 8192 /* maximum number of bytes written to a pipe */
#define SV_OPEN_MAX 64 /* maximum number of open files per process */
#define SV_PATH_MAX 1024 /* maximum number of characters in a path name */
#define SV_CHAR_MAX 255 /* maximum value of a 'character' */
7.2.3 config
The file SOURCE/include/config contains values that are
loaded at run time by various SVVS4 executable files. This
file must be edited to conform to the system where the tests
are executed.
An example:
/*
** SVVSPATH is the pathname of the target directory where the executable
** SVVS is to reside. This value is used throughout the tests and commands
** to locate files associated with SVVS.
*/
SVVSPATH "/usr/svvs"
/*
** SVVS_FS is the device on which you will mount a file system with at
** least 100 free blocks which SVVS tests will mount, unmount, write to
** and read from. This should be a spare filesystem with no important
** files on it, since unexpected results from certain tests could
** damage it. This device need not be mounted when the tests are run,
** but it must be available for mounting.
*/
SVVS_FS "/dev/dsk/0s3"
/*
** SVVS_FSTYPE is the file system type of SVVS_FS, SVVS_FSDATA is the
** file system specific data associated with SVVS_FSTYPE, and SVVS_FSDLEN
** is the length of the SVVS_FSDATA string.
*/
SVVS_FSTYPE "4.2"
- 6 -
Release Notes 7.1 SVVS Test Suite
SVVS_FSDATA ""
SVVS_FSDLEN 0
/*
** MOUNT_POINT is a directory on which SVVS_FS will be mounted.
** Attempts will be made to unlink this directory as well as mount
** and unmount SVVS_FS there. The 'SVVSPATH/mnt' directory is
** provided for this purpose, but you may wish to specify some other
** path.
*/
MOUNT_POINT "/usr/svvs/mnt"
/*
** ROOT_UID, ROOT_GID, BIN_UID, BIN_GID are the user and group
** identification numbers for ROOT and BIN respectively.
** These values may be determined by examining "/etc/passwd" and
** "/etc/group" on the target system.
*/
ROOT_UID 0
ROOT_GID 3
BIN_UID 2
BIN_GID 2
/*
** UID and GID are the user and group identification numbers for the
** tester as they exist on the target system. And GID2 and GID3 are
** the supplementary group identification numbers for the tester on
** the target system. The value of GID2 and GID3 should be the same
** as "gid2" and "gid3" in the /etc/group file. In the /etc/group file
** the tester should be set up as a member in "gid2" and not as a member
** in "gid3". This tester will be the only user who may run SVVS
** tests reliably, since certain tests test results against these
** values. UID2 allows SVVS to create processes with a known UID
** and to know that no other processes should exist with that user id.
*/
UID 200
GID 201
UID2 204
GID2 202
GID3 203
/*
** SYS_NAME is the system name of the target system as returned by
** uname(BA_OS). This value can be obtained by using the 'uname -s'
** command.
*/
SYS_NAME "CX/UX"
/*
** NODENAME is the target system node name as returned by
** uname(BA_OS). This value can be obtained by using the 'uname -n'
** command.
*/
NODENAME "ecx2"
- 7 -
SVVS Test Suite 7.1 Release Notes
/*
** RELEASE is the target operating system release number as returned
** by uname(BA_OS). This value can be obtained by using the 'uname -r'
** command.
*/
RELEASE "7.1"
/*
** VERSION is the target operating system version as returned by
** uname(BA_OS). This value can be obtained by using the 'uname -v'
** command.
*/
VERSION "ECX2"
/*
** MACHINE is the target hardware name as returned by uname(BA_OS).
** This value can be obtained by using the 'uname -m' command.
*/
MACHINE "m88k"
/*
** SVVS_ROOT is the device name of the root device on the target
** system. This value can be obtained using the df command.
*/
SVVS_ROOT "/dev/dsk/0s0"
/*
** FSYSNAME is the name of the root file system on the target
** system. This value can be obtained using the labelit command.
** You may need to be the super-user to execute this command.
*/
FSYSNAME ""
/*
** PACKNAME is the disk pack name of the root file system on the
** target system. This value can be obtained using the labelit
** command. You may need to be the super-user to execute this
** command.
*/
PACKNAME ""
/*
** OFF_LINE_DEV is the device number of a device which does not
** exist on the target system. This device MUST NOT EXIST! The
** tests will attempt to do a variety of operations, some of which
** may be destructive to this device. If it exists, these tests
** will fail and strange things may happen to the device. Ask your
** system administrator for this value.
*/
OFF_LINE_DEV 077577
/*
** CDEV and BDEV are the device numbers of a character and block
** special device respectively. These devices MUST exist on the
** target system. These values should be provided in the form that
** is used by the mknod system call on the target system. Ask your
- 8 -
Release Notes 7.1 SVVS Test Suite
** system administrator for these values.
*/
CDEV 1
BDEV 03003
/*
** SPARE_DEV is used by exit(BA_OS) to test job control. This is a spare
** terminal device that does not need to be connected to an actual terminal.
** However, no one should be allowed to connect to this terminal while
** SVVS is running.
*/
SPARE_DEV "/dev/ttyAa"
/*
** Resource Defaults for testing getrlimit(BA_OS)
*/
CPU_CUR_L 2147483647
CPU_MAX_L 2147483647
FSIZE_CUR_L 2147483647
FSIZE_MAX_L 2147483647
DATA_CUR_L 2147483647
DATA_MAX_L 2147483647
STACK_CUR_L 2147483647
STACK_MAX_L 2147483647
CORE_CUR_L 2147483647
CORE_MAX_L 2147483647
NOFILE_CUR_L 64
NOFILE_MAX_L 1024
/*
** PROC_LIMIT is the per-process file size limit on the target
** system, measured in 512 byte blocks. This value is returned
** by ulimit(BA_OS) when its command is 1 (get the ulimit).
*/
PROC_LIMIT 4194303
/*
**
** The ulimit minimum allocation unit
**
*/
ULIMUNIT 512
/*
** SYS_NMLN is the number of characters in the strings returned from
** uname(BA_OS). Ask your system administrator or a programmer for
** this value. Note: SYS_NMLN in will override this value.
*/
SYS_NMLN 256
/*
** The path of the master pseudo-tty
*/
PTM "/dev/ptyA0"
/*
- 9 -
SVVS Test Suite 7.1 Release Notes
** The name of the reserved group (usually tty) for pseudo
** ttys
*/
GIDTTY 201
/*
** Strings for multi-byte to wide character conversion
**
** MBLENS - a list of the lengths of each of the characters in the
** multi-byte string, MBSTRING
**
*/
MBLENS "1 1 1 1"
MBSTRING "1234"
/*
** The following describes the parameters required for the multiple
** language support tests.
**
** The tester could specify one more language other than "C" that is
** also supported by the target system by LANG1.
**
** The following parameters are required to test the interface for
** the formatting of numeric quantities (monetary and otherwise) based
** on the language LANG1.
**
** DECIMAL_POINT The decimal-point character used to format
** mon-monetary quantities.
**
** THOUSANDS_SEP The character used to separate groups of digits
** to the left of the decimal-point character in
** formatted non-monetary quantities.
** GROUPING A string in which each element is taken as an
** integer that indicates the number of digits that
** comprise the current group in a formatted
** non-monetary quantity. The elements of GROUPING
** are interpreted according to the following:
**
** MAX_CHAR No further grouping is to be performed.
** 0 The previous element is to be repeatedly
** used for the remainder of the digits.
** other The value is the number of digits that
** comprise the current group. The next
** element is examined to determine the
** size of the next group of digits to
** the left of the current group.
**
** INT_CURR_SYMBOL The international currency symbol applicable to
** the current locale, left-justified within a
** four-character space-padded field.
** CURRENCY_SYMBOL The local currency symbol applicable to the
- 10 -
Release Notes 7.1 SVVS Test Suite
** current locale.
** MON_DECIMAL_POINT The decimal-point used to format monetary
** quantities.
** MON_THOUSANDS_SEP The separator for groups of digits to the left
** of the decimal-point in formatted monetary
** quantities.
** MON_GROUPING A string in which each element is taken as an
** integer that indicates the number of digits that
** comprise the current group in a formatted
** monetary quantity. The elements of MON_GROUPING
** are interpreted according to the rules described
** under GROUPING.
** POSITIVE_SIGN The string used to indicate a nonnegative-valued
** formatted monetary quantity.
** NEGATIVE_SIGN The string used to indicate a negative-valued
** formatted monetary quantity.
** FRAC_DIGITS The number of fractional digits (those to the
** right of the decimal-point) to be displayed in
** a formatted monetary quantity.
** P_CS_PRECEDES Set to 1 or 0 if the CURRENCY_SYMBOL respectively
** precedes or succeeds the value for a nonnegative
** formatted monetary quantity.
** P_SEP_BY_SPACE Set to 1 or 0 if the CURRENCY_SYMBOL respectively
** is or is not separated by a space from the value
** for a nonnegative formatted monetary quantity.
** N_CS_PRECEDES Set to 1 or 0 if the CURRENCY_SYMBOL respectively
** precedes or succeeds the value tfor a negative
** formatted monetary quantity.
** N_SEP_BY_SPACE Set to 1 or 0 if the CURRENCY_SYMBOL respectively
** is or is not separated by a space from the value
** for a negative formatted monetary quantity.
** P_SIGN_POSN Set to a value indicating the positioning of the
** POSITIVE_SIGN for a nonnegative formatted monetary
** quantity. The value of P_SIGN_POSN is interpreted
** according to the following:
**
** 0 Parentheses surround the quantity and
** CURRENCY_SYMBOL.
** 1 The sign string precedes the quantity
** and CURRENCY_SYMBOL.
** 2 The sign string succeeds the quantity
** and CURRENCY_SYMBOL.
** 3 The sign string immediately precedes
** the CURRENCY_SYMBOL.
** 4 The sign string immediately succeeds
** the CURRENCY_SYMBOL.
**
** N_SIGN_POSN Set to a value indicating the positioning of the
** NEGATIVE_SIGN for a negative formatted monetary
- 11 -
SVVS Test Suite 7.1 Release Notes
** quantity. The value of N_SIGN_POSN is interpreted
** according to the rules described unter P_SIGN_POSN.
*/
LANG1 ""
DECIMAL_POINT ""
THOUSANDS_SEP ""
GROUPING ""
INT_CURR_SYMBOL ""
CURRENCY_SYMBOL ""
MON_DECIMAL_POINT ""
MON_THOUSANDS_SEP ""
MON_GROUPING ""
POSITIVE_SIGN ""
NEGATIVE_SIGN ""
FRAC_DIGITS 0
P_CS_PRECEDES 0
P_SEP_BY_SPACE 0
N_CS_PRECEDES 0
N_SEP_BY_SPACE 0
P_SIGN_POSN 0
N_SIGN_POSN 0
/*
** The following parameters apply only to Transport Service Interface
** tests. The description which follows is directed toward a reader with
** a solid understanding of transport providers as described in the SVID.
** The values used here should be reviewed by a programmer or system
** administrator familiar with transport services and your installation.
**
**
** The following set of parameter names are constructed as follows:
**
** The prefix for the parameter is one of:
**
** TPDG "Transport Provider Data Gram", a connectionless
** mode provider.
** TPVC "Transport Provider Virtual Circuit", a connection
** mode provider.
** SEMA A connection mode provider used for semaphore
** operations when performing point to point tests.
**
** The suffix for each parameter is a number between 0 and 3. This
** number denotes a "logical node number". All entries with the
** same prefix and "logical node number" are treated as referring to
** a single transport endpoint by the tests. There are four "logical
** nodes" used by the connection mode tests, and two "logical nodes"
** used by the connectionless mode tests. If point to point testing
** is being performed, two more "logical nodes" are used for
** semaphore operations. If SEMAADDR0 and SEMACONN0 are identical
** then the virtual circuit semaphore link is not used, and loop
- 12 -
Release Notes 7.1 SVVS Test Suite
** back testing is assumed. This is discussed in more detail below.
** Note that point to point testing is unsupported, and is provided
** strictly for diagnostic purposes.
**
** The infix for each parameter is one of:
**
** FILE The name of a device to be used as a transport
** provider.
** MINOR The number of minor devices associated with this
** device.
** ADDR The address at which this "logical node" will bind.
** This must be an address which is local to the
** system on which the test is being run. This value
** is entered as a 'C' language string. Use '0n'
** to enter special characters and null characters.
** '0n' will be interpreted as an octal value.
** CONN The address to which other "logical nodes" will
** establish connections or send datagrams. If CONN
** is the same as ADDR, this indicates that the tests
** are being run in loop back mode. If CONN is
** different from ADDR, then point to point testing
** is indicated. For point to point testing, two
** copies of a test must be executed, one on each
** end of a transport layer interface link. (Note
** that this may or may not be on different machines.)
** The configuration file for the other test must
** have corresponding values for ADDR and CONN at each
** "logical node", such that the ADDR entry for each
** "logical node" is identical to the CONN entry for
** the other configuration file. Since CONN is used
** locally to establish connections / route packets
** to a "logical node", this causes the local test
** to communicate with the corresponding "logical
** node" from the other test. For the SEMA entries,
** the first ADDR/CONN pair ("logical node" 0) are
** examined to determine if a virtual circuit should
** be initialized for use as a semaphore mechanism.
** If SEMAADDR0 and SEMACONN0 are identical and of the
** same length, loop back testing is indicated.
** If these addresses are entered incorrectly, or
** (in the case of point to point testing), do
** not match endpoints where another copy of the test
** will be concurrently executed, the tests will
** not function correctly.
** ALEN The length of the ADDR for this "logical node".
** CLEN The length of the CONN for this "logical node".
** WAIT A timeout period. Note that there is
** no suffix for this parameter, it applies to
** all logical nodes with the same generic kind of
- 13 -
SVVS Test Suite 7.1 Release Notes
** provider. This can probably be left as it is.
** TYPE The type of the service, as returned by t_open
** or t_getinfo. For connectionless mode service,
** this must be "T_CLTS", for connection mode service,
** this is either "T_COTS" or "T_COTS_ORD".
**
**
*/
TPDGTYPE "T_CLTS"
TPDGWAIT 0
TPDGFILE0 "/dev/tidg"
TPDGMINOR0 12
TPDGADDR0 " 1"
TPDGALEN0 4
TPDGCONN0 " 1"
TPDGCLEN0 4
TPDGFILE1 "/dev/tidg"
TPDGMINOR1 12
TPDGADDR1 " 2"
TPDGALEN1 4
TPDGCONN1 " 2"
TPDGCLEN1 4
TPVCTYPE "T_COTS_ORD"
TPVCWAIT 0
TPVCFILE0 "/dev/tivc"
TPVCMINOR0 12
TPVCADDR0 " 1"
TPVCALEN0 4
TPVCCONN0 " 1"
TPVCCLEN0 4
TPVCFILE1 "/dev/tivc"
TPVCMINOR1 12
TPVCADDR1 " 2"
TPVCALEN1 4
TPVCCONN1 " 2"
TPVCCLEN1 4
TPVCFILE2 "/dev/tivc"
TPVCMINOR2 12
TPVCADDR2 " 3"
TPVCALEN2 4
TPVCCONN2 " 3"
TPVCCLEN2 4
TPVCFILE3 "/dev/tivc"
- 14 -
Release Notes 7.1 SVVS Test Suite
TPVCMINOR3 12
TPVCADDR3 " 1 "
TPVCALEN3 4
TPVCCONN3 " 1 "
TPVCCLEN3 4
SEMAFILE0 "/dev/tivc"
SEMAADDR0 " 2 "
SEMAALEN0 4
SEMACONN0 " 2 "
SEMACLEN0 4
SEMAFILE1 "/dev/tivc"
SEMAADDR1 " 3 "
SEMAALEN1 4
SEMACONN1 " 3 "
SEMACLEN1 4
/*
** Structure elements, as returned by t_open and t_getinfo.
**
** ADDR maximum length of an address for this provider
** OPTIONS maximum length of options for this provider
** TSDU maximum length of tsdu for this provider
** ETSDU maximum length of etsdu for this provider
** CONNECT maximum length of data sent with a connect request
** DISCON maximum length of data sent with a disconnect request
*/
TPDGINFO_ADDR 4
TPDGINFO_OPTIONS 4
TPDGINFO_TSDU 1024
TPDGINFO_ETSDU -2
TPDGINFO_CONNECT -2
TPDGINFO_DISCON -2
TPVCINFO_ADDR 4
TPVCINFO_OPTIONS 4
TPVCINFO_TSDU 4096
TPVCINFO_ETSDU 64
TPVCINFO_CONNECT 16
TPVCINFO_DISCON 16
/*
** An invalid address and its length
*/
TPBADADDR " \f"
TPBADLEN 4
/*
** An invalid option set, and its length
*/
BADOPTIONS "fdakslfj"
- 15 -
SVVS Test Suite 7.1 Release Notes
BADOPTLEN 8
/*
** AMAXLEN is the maximum length of a transport provider address
*/
AMAXLEN 256
/*
** OMAXLEN, DMAXLEN, and T_CON_DELAY are Driver dependent values. If
** you are using the drivers supplied with SVVS, the values given
** here are correct. For other drivers, ask a System Programmer.
**
** OMAXLEN is the maximum length of the options for t_optmgmt.
*/
OMAXLEN 8
/*
** DMAXLEN is the maximum length of data.
*/
DMAXLEN 16
/*
** T_CON_DELAY is the number of seconds that the test should wait before
** establishing a connection, t_rcvconnect(BA_OS), or submitting a
** disconnect request, t_rcvdis(BA_OS).
*/
T_CON_DELAY 0
8. Problem Areas
The following section lists the SVVS4 tests that fail (and
the reason why).
BA/LIB/exp
Will fail cbrt(HUGE) with: "unexpected signal occurred:
SIGFPE".
USL has granted a waiver for this.
BA/LIB/mktime
Will get errors of the type "Normalized, Different ..."
This only fails when the current time is not Daylight
Savings Time.
Documented in USL's SVVS4 Known Problem List.
BA/LIB/ptsname
Will fail with "The last element of the path must be a
number."
- 16 -
Release Notes 7.1 SVVS Test Suite
This cannot be done in CX/UX.
BA/LIB/t_rcvudata (and t_snd)
These TLI tests may fail under certain conditions when
run on a multiprocessor.
The tests incorrectly coordinate between readers and
writers. Documented in USL's SVVS4 Known Problem List.
Considered successful if it passes in a single cpu
environment.
BA/OS/fopen
This gets failures of the type "file contents differ:
buf3[0]=+, buf4[43]=".
Invalid C code within the test suite source. Documented
in USL's SVVS4 Known Problem List.
BA/OS/getcwd
This fails when getcwd is called with a size parameter of
-1. It expects NULL on return and errno set to EINVAL.
This violates POSIX-1990. The size parameter is unsigned.
BA/OS/getrlimit
This gets a failure of the type "child process exited
abnormally".
The test is incorrect. USL has granted a waiver for this.
BA/OS/write
This gets a failure when writing data to a pipe until it
is full. It reports unexpected signal SIGALRM.
The test is incorrect. Documented in USL's SVVS4 Known
Problem List.
- 17 -
CONTENTS
1. Introduction............................................. 1
2. Documentation............................................ 1
3. Prerequisites............................................ 3
3.1 Hardware............................................ 3
3.2 Software............................................ 3
4. Installation............................................. 3
5. Cautions................................................. 3
6. SVVS Functional Groupings................................ 3
7. Setup and Operation...................................... 4
7.1 STREAMS and TLI..................................... 4
7.2 Configuration Files................................. 5
7.2.1 Installation Script.......................... 5
7.2.2 sv_const.h................................... 6
7.2.3 config....................................... 6
8. Problem Areas............................................ 16
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
SVVS TEST SUITE
VERSION 7.1
RELEASE NOTES
0891045-7.1
October 1993
_________________________________________________________________
return to index
================================================================================
VSX TEST SUITE -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The VSX Test Suite Release 3.205 1 is a set of programs and
scripts used to determine whether an operating system
conforms with the X/Open Portability Guide (XPG3). These
release notes contain information on the setup and operation
of VSX under CX/UX 7.1 and are meant to be an addendum to
the VSX Release 3.205 Users Guide. The test suite itself
and the VSX Release 3.205 Users Guide are not included and
must be obtained separately from X/Open Company, Limited.
2. Documentation
The following documentation is included with this release:
____________________________________________
| Manual Name Pub. Number|
|_____________________________|_____________|
| VSX Test Suite Release Notes| 0891050-7.1|
|_____________________________|_____________|
These release notes contain information specific to the
configuration of CX/UX 7.1 for the VSX test suite to run.
Refer to the VSX Release 3.205 Users Guide for installation
and operation instructions specific to the VSX test suite
__________
- These release notes cover the following products:
vsx_tests
1. VSXO is a copyright of X/Open Company, Limited.
- 1 -
VSX Test Suite 7.1 Release Notes
itself.
3. Prerequisites
Prerequisites for running the VSX Test Suite Version 3.205
are as follows:
3.1 Hardware
o Any Series 4000 or Series 5000 system.
o MPCC Serial Communications board.
3.2 Software
o CX/UX 7.1
o STREAMS 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
Also refer to the VSX Release 3.205 Users Guide for
installation and operation instructions specific to the VSX
test suite itself.
5. Cautions
None.
6. VSX Functional Groupings
CX/UX 7.1 will pass the Base section of VSX Release 3.205.
This consists of eight subsections: ANSI.os, ANSI.hdr,
POSIX.os, POSIX.hdr, XOPEN.os, XOPEN.hdr, XOPEN.cmd, and
lang.C. The XPG2 and Data Management subsections are not
applicable to CX/UX 7.1.
- 2 -
Release Notes 7.1 VSX Test Suite
7. Setup and Operation
The procedures necessary to configure and run VSX are
described in the next section.
7.1 Setup
1. Log in as root.
2. Configure the kernel:
o Uncomment the options STREAMS line in the kernel
configuration file.
o Add the following line
options STRM_FIFO
to the configuration file used to build the
kernel. This causes the file system fifos and
pipes to utilize the STREAMS system instead of the
sockets system. Some of the tests depend upon
STREAMS calls working on fifos.
o Do NOT configure NFS nor have any nfs daemons
running while executing the test suite. Edit
/etc/rc to make sure all NFS daemons are commented
out.
o Do NOT configure the HIGHRESTIMING option.
o Run /etc/config and relink the kernel.
3. You must have two extra partitions available for VSX to
mount and unmount during the test run. These
partitions should not be mounted when the run begins,
but should be readable/writable by user vsx0 as
described below.
4. Change directory to /dev and use MAKEDEV to create a
set of ttys for a non-existent controller. That is,
vx1 or hps1 or another controller which is NOT
configured into your kernel. The tty lines should be
readable/writable by user vsx0.
5. Connect a null modem cable to two ports on your serial
communications board for the tty tests. These ports
are specified in the .vtestrc file as discussed below.
6. Change directory to /usr/src/VSX/LANG and run make to
install the pseudo-language databases.
- 3 -
VSX Test Suite 7.1 Release Notes
7. Add an entry for user vsx0 to the /etc/passwd file.
The home directory for vsx0 is where the VSX test suite
will be loaded. Here is an example /etc/passwd entry
for user vsx0:
vsx0::800:800:VSX test user:/usr/VSX:/sbin/sh
8. Edit the /etc/group file to add groups for VSX. User
vsx0 must be in 16 distinct groups in the group file,
but user vsx0 may NOT belong to group vsxg1. A sample
group file follows:
root::0:root
other::1:
bin::2:bin,daemon
sys::3:bin,sys,adm
adm::4:adm,daemon
kmem::5:bin
mail::6:
news::7:news,notes
operator::8:bin
secadm::10:
uucp::11:uucp
daemon::12:daemon
misc::13:nuucp
rje::18:
lp::71:
RESERVED:group ids 0 through 99 reserved to HARRIS:98:
vsxg0::800:
vsxg1::801:
vsxg2::802:vsx0
vsxg3::803:vsx0
vsxg4::804:vsx0
vsxg5::805:vsx0
vsxg6::806:vsx0
vsxg7::807:vsx0
vsxg8::808:vsx0
vsxg9::809:vsx0
vsxg10::810:vsx0
vsxg11::811:vsx0
vsxg12::812:vsx0
vsxg13::813:vsx0
vsxg14::814:vsx0
vsxg15::815:vsx0
vsxg16::816:vsx0
9. Make the home directory for vsx0, owned by user vsx0.
10. Create a .profile file for user vsx0 and modify the
PATH environment variable to include $HOME/BIN.
Also, set the environment variable SDE_TARGET=COFF and
- 4 -
Release Notes 7.1 VSX Test Suite
export it in .profile.
11. Change directory to the vsx0 home directory and read in
the tape. The tape format is specified on the tape
label.
12. Change the owner and group of all the files to vsx0:
find . -print | xargs chown vsx0
find . -print | xargs chgrp vsxg0
13. Logout as root and login as vsx0.
7.2 Configuration Files
There are several configuration files which must be edited
to conform to the system where the VSX tests are to be built
and run. A discussion of these files and example files
follow.
7.2.1 Installation_Scripts
The config.sh script asks some questions about the source
and destination directories and the compiler options used to
build the test suite. Several files are generated when
config.sh is run. They are discussed below.
7.2.2 vsxconfig.h
The config.sh script generates the file SRC/vsxconfig.h,
which must be edited to change the highest signal number
from -1 to 65. No other changes are necessary.
Example vsxconfig.h:
/****** This file contains definitions for those elements which ******/
/****** 'incrpt' found to be missing from the system include files ******/
/****** - Missing elements ******/
/****** Start of Definitions for file signal.h ******/
#define NSIG 65 /* user supplied: (highest signal number + 1) */
/****** End of Definitions for file signal.h ******/
/**** End of Definitions added by this 'incrpt' run ******/
- 5 -
VSX Test Suite 7.1 Release Notes
7.2.3 vsxparams
The config.sh script uses your answers to create the
SRC/vsxparams file. It may be edited to change the values
originally supplied. To save a copy of this file to use in
future runs, make a copy in the SRC/install/params.data
directory. The next time config.sh is run, it will ask if
you wish to use any of the parameter files it finds in
SRC/install/params.data.
Example vsxparams file:
#VSX_OPER - Name of the person running the VSX test suite
VSX_OPER="Software Development"
#VSX_ORG - Name of the organization for whom VSX is being run
VSX_ORG="Harris Computer Systems Division"
#VSX_SYS - Name of the system (hardware and software) on which the VSX
# verification is being performed
VSX_SYS="HN4404/CX7.1"
#VSXDIR - this parameter defines the source directory for the VSX software.
# The value given to this parameter must be a full pathname
VSXDIR="/usr/VSX/SRC"
#TESTROOT - this parameter defines the directory from which the VSX tests
# will be executed.
# The value given to this parameter must be a full pathname
TESTROOT="/usr/VSX/TESTROOT"
#SPEED - this parameter defines the speed of the machine on a 1-10 scale
# A speed of 1 is given to a very fast machine and 10 to a very
# slow machine
SPEED="2"
#INCDIRS - this parameter defines the directories which contain the include
# files for the system being tested, in order of searching.
# This parameter is normally set to /usr/include
INCDIRS=" /usr/include /usr/include/sys"
#LIB1 - this parameter defines the directory which contains the C library
# This parameter is normally set to /lib (For iAPx286 - /lib/large)
LIB1="/usr/sde/coff/usr/lib"
#LIB2 - this parameter defines another directory that the C compiler will
# search to find library archive files.
# This parameter is normally set to /usr/lib (For iAPx286 /usr/lib/large)
# May be set to "none" if the C compiler only searches LIB1.
LIB2="/usr/lib"
- 6 -
Release Notes 7.1 VSX Test Suite
#CC - this parameter defines the C compiler to be used in building the suite.
# This parameter is normally set to /bin/cc
CC="/usr/bin/cc"
#COPTS - this parameter defines any special command line options needed by the
# C compiler.
# This parameter is normally set to ""
COPTS="-O -Xa -Qspill_register_if_address_taken -w -ZCOFF"
#DEFINES - feature test macros and any special defines used for this system
# If testing the base subset, this parameter must include
# -D_XOPEN_SOURCE for X/Open mode, or -D_POSIX_SOURCE (with no
# other feature test macros) for POSIX-only mode.
DEFINES="-D_XOPEN_SOURCE "
#LDFLAGS - this parameter defines any special link editor (loader) options
# needed by the C compiler link edit phase.
# This parameter is normally set to "" (For iAPx286 - -ml)
LDFLAGS="-ZCOFF /usr/sde/coff/usr/lib/ansi.o"
#CFPURE - this parameter defines the link editor option used to produce a
# pure executable (shared text) program.
# Some systems require this parameter to be set to -n (non-X/Open option)
# Other systems require this parameter to be set to ""
CFPURE=""
#LORDER - this parameter defines the sequential object library ordering program.
# If the system has an archiver which does not need lorder this
# parameter should be set to "echo".
LORDER="echo"
#TSORT - topological sort program used in library ordering.
# If LORDER has been set to "echo", this parameter should be set to "cat".
# Otherwise this parameter should be set to "tsort"
TSORT="cat"
#RANLIB - this parameter defines the random object library ordering program.
# If this parameter is set to "ranlib", LORDER should be set to "echo"
# and TSORT set to "cat".
# Otherwise this parameter should be set to "echo"
RANLIB="ranlib"
#AR - the command (and options) used to create a library archive.
# This parameter is normally set to "ar cr"
AR="ar cr"
#CHOWN - the command used to change the ownership of files.
# This parameter is normally set to "chown" or "/etc/chown"
CHOWN="chown"
- 7 -
VSX Test Suite 7.1 Release Notes
#CHGRP - the command used to change the group ownership of files.
# This parameter is normally set to "chgrp"
CHGRP="chgrp"
#CHMOD - the command used to change the mode of files
# This parameter is normally set to "chmod"
CHMOD="chmod"
#MLIB - the name of the mathematics library
# This parameter is usually set to "/usr/lib/libm.a"
MLIB="/usr/sde/coff/usr/lib/libm.a"
#LIBISAM - the name of the isam library
# This parameter is usually set to "/usr/lib/libisam.a", but may be left
# blank if the data management tests have not been installed
LIBISAM=""
#SYSLIBS - the names of additional libraries needed to compile VSX
# These library names should be full path names.
# Typical libraries needed on this line are:-
# The library containing the directory routines
# The library containing the enhanced memory allocation routines
# The library containing the vprintf function
# The library containing the NLS routines
# The parameter should be of the form "/usr/lib/libnam1.a /lib/libnam3.a"
# This parameter will often be set to ""
SYSLIBS=" /usr/sde/coff/usr/lib/libmalloc.a /usr/sde/coff/usr/lib/libc.a \
/usr/lib/libPW.a"
#SIGNAL_SUPP - indicates whether the ANSI function signal() is supported
# This parameter must be "y" in full X/Open mode but may be "n" in
# POSIX-only mode.
SIGNAL_SUPP="y"
7.2.4 userintf.c
Edit the file SRC/userintf.c to declare the dummy variable
in the use_time() routine a volatile int. The correct
format of the use_time() routine is as follows:
/*
* Use_time() performs processing which will accumulate
* user CPU time. The number of iterations may be adjusted
* if necessary.
*/
public void
use_time()
{
int i;
- 8 -
Release Notes 7.1 VSX Test Suite
volatile int dummy = 0;
for (i = 0; i < 100; i++)
dummy = dummy + i / (dummy + 1) * (dummy % 3);
}
7.2.5 install.sh
After making the necessary changes to vsxparams,
vsxconfig.h, and userintf.c, you will run the script
install.sh. This script will build the tool set used to
build and run the test suite, but does not build the test
suite itself.
After running install.sh, you must again login as root and
make the file SRC/BIN/chmog setuid root:
chown root SRC/BIN/chmog
chmod 4755 SRC/BIN/chmog
7.2.6 .vmakerc
The file .vmakerc is generated by install.sh, and contains
the information, such as compiler options, that are used to
build the test suite. This file must be edited to conform
to the system where the tests will be executed.
An example:
#VSX_OPER - Name of the person running the VSX test suite
VSX_OPER=Software Development
#VSX_ORG - Name of the organization for whom VSX is being run
VSX_ORG=Harris Computer Systems Division
#VSX_SYS - Name of the system (hardware and software) on which the VSX
# verification is being performed
VSX_SYS=HN4404/CX7.1
#VSXDIR - this parameter defines the source directory for the VSX software.
# The value given to this parameter must be a full pathname
VSXDIR=/usr/VSX/SRC
#TESTROOT - this parameter defines the directory from which the VSX tests
# will be executed.
# The value given to this parameter must be a full pathname
TESTROOT=/usr/VSX/TESTROOT
#PATH - the command search path to be set in the environment passed to "make".
# Normally set to the PATH in effect when config.sh was run.
- 9 -
VSX Test Suite 7.1 Release Notes
# Must contain the directories where commands specified in the
# parameters below reside (if full path names are not given).
PATH=:/bin:/usr/bin:/usr/ucb:/usr/VSX/BIN
#VSX_MAKE - this parameter defines the make(1) command to be used.
# Normally left blank so the default ("make") will be used.
VSX_MAKE=
#INCDIRS - this parameter defines the directories which contain the include
# files for the system being tested, in order of searching.
# This parameter is normally set to /usr/include
INCDIRS=/usr/include
#CC - this parameter defines the C compiler to be used in building the suite.
# This parameter is normally set to /bin/cc
CC=/bin/cc
#COPTS - this parameter defines any special command line options needed by the
# C compiler.
# This parameter is normally set to ""
COPTS=-O -Xa -Qspill_register_if_address_taken -w -ZCOFF
#LDFLAGS - this parameter defines any special link editor (loader) options
# needed by the C compiler link edit phase.
# This parameter is normally set to "" (For iAPx286 - -ml)
LDFLAGS=-ZCOFF /usr/sde/coff/usr/lib/ansi.o
#LORDER - this parameter defines the sequential object library ordering program.
# If the system has an archiver which does not need lorder this
# parameter should be set to "echo".
LORDER=echo
#TSORT - topological sort program used in library ordering.
# If LORDER has been set to "echo", this parameter should be set to "cat".
# Otherwise this parameter should be set to "tsort"
TSORT=cat
#RANLIB - this parameter defines the random object library ordering program.
# If this parameter is set to "ranlib", LORDER should be set to "echo"
# and TSORT set to "cat".
# Otherwise this parameter should be set to "echo"
RANLIB=ranlib
#AR - the command (and options) used to create a library archive.
# This parameter is normally set to "/bin/ar cr"
AR=ar cr
#MLIB - the name of the mathematics library
# This parameter is usually set to "/usr/lib/libm.a"
- 10 -
Release Notes 7.1 VSX Test Suite
MLIB=/usr/sde/coff/usr/lib/libm.a
#LIBISAM - the name of the isam library
# This parameter is usually set to "/usr/lib/libisam.a", but may be left
# blank if the data management tests have not been installed
LIBISAM=
#SYSLIBS - the names of additional libraries needed to compile VSX
# These library names should be full path names.
# Typical libraries needed on this line are:-
# The library containing the directory routines
# The library containing the enhanced memory allocation routines
# The library containing the vprintf function
# The library containing the NLS routines
# The parameter should be of the form "/usr/lib/libnam1.a /lib/libnam3.a"
# This parameter will often be set to ""
SYSLIBS=/usr/sde/coff/usr/lib/libmalloc.a /usr/sde/coff/usr/lib/libc.a \
/usr/lib/libPW.a
#DBUG - whether or not the debugging option is used
# This parameter is usually not set
DBUG=
#DEFINES - feature test macros and any special defines used for this system
# If testing the base subset, this parameter must include
# -D_XOPEN_SOURCE for X/Open mode, or -D_POSIX_SOURCE (with no
# other feature test macros) for POSIX-only mode.
DEFINES=-D_XOPEN_SOURCE
7.2.7 .vtestrc
After building the test suite, you must edit the file
TESTROOT/.vtestrc to reflect the configuration of the system
where the test suite is to be run. This file controls the
options used when actually running the test suite.
All tty lines and disk partitions specified in .vtestrc
should be readable and writable by user vsx0. An example
.vtestrc follows:
# This file is a pro forma parameter file for the vtest program
# The values contained in this file must be modified for the target
# system. If your system uses the default value a value should
# NOT be specified in this file.
#
# General Parameters - required for all sub-sets ('base', 'dm', 'xpg2')
#
LOGNAME=vsx0
TZ=EST5EDT
- 11 -
VSX Test Suite 7.1 Release Notes
# Full path for test root directory - Default - None
TESTROOT=/usr/VSX/TESTROOT
# Source directory for VSX - Default - None
VSXDIR=/usr/VSX/SRC
# Test Run Name - Default - Vtest
VSX_NAME=
# Operator Name - Default - Unknown
VSX_OPER=Software Development
# Organization - Default - X/OPEN Group
VSX_ORG=Harris Computer Systems Division
# Search Path - Default - :/bin:/usr/bin
VSX_PATH=:/usr/bin:/usr/ucb:/usr/VSX/BIN
# System Name - Default - VSX Test System
VSX_SYS=HN4404/CX7.1
# User/Group ID's - Default - UIDs of user names vsx0, vsx1, vsx2
# GIDs of group names vsx0, vsx1, vsx2
VSX_UID0=
VSX_UID1=
VSX_UID2=
VSX_GID0=
VSX_GID1=
VSX_GID2=
# list of signal numbers to set to be ignored - Default - None
# many systems will need to include the signal number for SIGSYS
# Example: 12,42
VSX_SIG_IGN=
# list of signal numbers to leave alone - Default - None
# used for exotic signals which cause problems if set to be caught
# Example: 43, 44
VSX_SIG_LEAVE=
#
# Operating System Characteristics - required for 'base' sub-set
# (both POSIX and X/Open modes)
#
# alarm() accuracy - Default - SPEEDFACTOR
VSX_AL_ACCURACY=
# block special file name - Default - None
# set to "unsup" if block special files are not supported
- 12 -
Release Notes 7.1 VSX Test Suite
VSX_BLKDEV_FILE=/dev/dsk/0s3
# character special file name - Default - None
# set to "unsup" if character special files are not supported
VSX_CHRDEV_FILE=/dev/tty00
# clock() accuracy - Default - 5 per cent
VSX_CLOCK_ERR=
# closedir() detects EBADF? (Y/N) - Default - None
VSX_CLOSEDIR_EBADF=Y
# max number of file locks settable by fcntl() - Default - None
# may be set to -1 if there is no practical limit
VSX_FCNTL_MAXLOCK=-1
# floating point calculations in software (Y/N) - Default - No
VSX_FP_SOFTWARE=Y
# invalid group ID - Default - unsupported
VSX_INVALID_GID=99999
# group name not in group database - Default - "nogroup"
VSX_INVALID_GNAME=
# invalid "_PC_..." value for pathconf() - Default - -1
VSX_INVALID_PC=
# user name not in user database - Default - "nouser"
VSX_INVALID_PNAME=
# invalid user ID - Default - unsupported
VSX_INVALID_UID=99999
# invalid "_SC_..." value for sysconf() - Default - -1
VSX_INVALID_SC=
# invalid signal - Default - -1
VSX_INVAL_SIG=
# link()/unlink() work on directories (Y/N/U) - Default - None
# Y = both work
# N = neither works
# U = only unlink() works
VSX_LINK_DIR_SUPP=Y
# link() may be used across file systems (Y/N) - Default - None
VSX_LINK_FILESYS_SUPP=N
- 13 -
VSX Test Suite 7.1 Release Notes
# mountable file system - Default - None
# can be the same as VSX_ROFS
VSX_MOUNT_DEV=/dev/dsk/0s3
# access() supports appropriate privileges (Y/N) - Default - no
VSX_PRIV_ACCESS_SUPP=Y
# chown() & chmod() support appropriate privileges - Default - no
VSX_PRIV_CHOWN_SUPP=Y
# readdir() detects EBADF? (Y/N) - Default - None
VSX_READDIR_EBADF=Y
# removing a busy directory gives EBUSY (Y/S/P/N) - Default - None
# Y = Yes, always
# S = Yes, but only when in use by the system
# P = Yes, but only when in use by another process
# N = No
VSX_REMOVE_DIR_EBUSY=S
# renaming a busy directory gives EBUSY (Y/S/P/N) - Default - None
# Y = Yes, always
# S = Yes, but only when in use by the system
# P = Yes, but only when in use by another process
# N = No
VSX_RENAME_DIR_EBUSY=S
# rename() on directories requires write access (Y/N) - Default - None
VSX_RENAME_DIR_WPERM_REQD=N
# read only file system - Default - None
# can be the same as VSX_MOUNT_DEV
VSX_ROFS=/dev/dsk/0s3
# setting S_ISUID and S_ISGID is supported (Y/N) - Default - no
VSX_SET_ID_MODES_SUPP=Y
# setpgid() is supported (Y/N) - Default - no
# (must be Y if _POSIX_JOB_CONTROL is defined)
VSX_SETPGID_SUPPORTED=Y
# sigaddset() & sigdelset() can give EINVAL (Y/N) - Default - no
VSX_SIGSET_EINVAL=Y
# file name of terminal vtest is running on - Default - None
VSX_TTYNAME=/dev/console
# user logged onto VSX_TTYNAME - Default - None
VSX_TTYUSER=vsx0
- 14 -
Release Notes 7.1 VSX Test Suite
# no. of blocks for which ulimit() works correctly - Default - None
# Example: 2
VSX_ULIMIT_BLKS=1
# name of a file which cannot be locked - Default - unsupported
VSX_UNLOCKABLE_FILE=
# unsupported process group ID (> 0) - Default - None
VSX_UNSUPPORTED_PGID=99999
# unused (valid) group ID - Default - None
VSX_UNUSED_GID=999
# unused (valid) user ID - Default - None
VSX_UNUSED_UID=999
#
# Operating System Characteristics - required for 'base' sub-set
# (X/Open mode)
#
# block special file (unavailable device) - Default - None
# Must be readable and writable by user vsx0 or group vsx0
VSX_NXIO_BLKDEV=/dev/dsk/0s6
# char special file (unavailable device) - Default - None
# Must be readable and writable by user vsx0 or group vsx0
VSX_NXIO_CHRDEV=/dev/tty10
# shared executable - Default - Not available
# or ETXTBSY not supported
VSX_PURE_FILE=${TESTROOT}/BIN/purefile
#
# Operating System Characteristics - required for 'xpg2' sub-set
#
# accounting file - Default - None
VSX_ACCT_FILE=
# memory alignment - Default - 0
VSX_BRK_ALIGN=4
# fault address - Default - None
VSX_FAULT_ADDR=0xc0000000
# second mountable file system - Default - None
# can be the same as VSX_ROFS
# must be different from VSX_MOUNT_DEV
VSX_MOUNT_DEV2=/dev/dsk/0s4
- 15 -
VSX Test Suite 7.1 Release Notes
# inhibit set time test (Y/N) - Default - Inhibit test
VSX_STIME_TEST=Y
#
# Compiler Characteristics - required for all sub-sets
#
# Note:- if the isam header file is not in the default include directory
# these parameters should cause the appropriate directory
# to be searched (if the data management tests are being run)
#
# C compiler - Default - /bin/cc
# This can be a shell script if required (e.g. if the compiler
# outputs a copyright line, the script should suppress it)
VSX_CC=/bin/cc
# C compiler flags - Default - None
# If testing the base subset, this parameter must include
# -D_XOPEN_SOURCE for X/Open mode, or -D_POSIX_SOURCE (with no
# other feature test macros) for POSIX-only mode.
VSX_CFLAGS=-O -Xa -D_XOPEN_SOURCE -Qspill_register_if_address_taken -w -ZCOFF
# C compiler libraries - Default - -lm
# Usually contains the maths library (-lm) and any libraries
# used in the SYSLIBS vmake parameter
VSX_LIBS=/usr/sde/coff/usr/lib/libm.a /usr/sde/coff/usr/lib/libmalloc.a /lib/libc.a /usr/lib/libPW.a
#
# Compiler Characteristics - required for 'base' sub-set
#
# Loader - Default - VSX_CC
VSX_LD=
# Include syntax (-Idir or -I dir) - Default - no separator
VSX_C_ISEP=
# Loader flags - Default - None
VSX_C_LINK=-ZCOFF /usr/sde/coff/usr/lib/ansi.o
# C compiler flag to prohibit load phase - Default - -c
VSX_C_NOLINK=
# Loader option to rename output - Default - -o
VSX_C_OUT=
# C compiler object file suffix - Default - .o
VSX_C_SUFFIX=
#
# Terminal Interface Parameters - required for 'base' subset
- 16 -
Release Notes 7.1 VSX Test Suite
#
# Terminal device to be used as controlling terminal
VSX_TERMIOS_TTY=/dev/tty00
# Terminal device connected to VSX_TERMIOS_TTY by loopback
VSX_TERMIOS_LOOP=/dev/tty01
# These terminals are asynchronous serial (Y/N) - Default - no
VSX_TERMIOS_ASYNC=Y
# Normal speed setting for terminal tests - Default - none
# Example: B9600
VSX_TERMIOS_SPEED=B9600
# Modem control is supported (Y/N) - Default - no
VSX_MODEM_CONTROL=Y
# START & STOP characters can be changed (Y/N) - Default - no
VSX_START_STOP_CHNG=Y
# tcgetpgrp() is supported (Y/N) - Default - no
VSX_TCGETPGRP_SUPPORTED=Y
# tcsetpgrp() is supported (Y/N) - Default - no
VSX_TCSETPGRP_SUPPORTED=Y
# Erase sequence echoed when ECHOE and ECHO are set
# Example: \b \b
PCTS_ECHOE=\b \b
# Kill sequence echoed when ECHOK and ECHO are set,
# for kill character CTRL-U (c_cc[VKILL] == '\025')
# Example: \025\n
PCTS_ECHOK=\025\n
#
# Special Environment Parameters for Internationalization
# - required for 'base' sub-set
#
# The system being tested may rely on certain parameters
# being defined in the environment. These parameters should
# be entered in this file in the form PARAMETERNAME=VALUE.
# Each parameter should be entered on a separate line with
# the PARAMETERNAME being at the start of the line.
#
# Warning: VSX does not use the environment set by the user
# but creates its environment from this file.
#
- 17 -
VSX Test Suite 7.1 Release Notes
#
# END OF PARAMETERS FILE
8. Running the Test Suite
When running the test suite, it is necessary to use the run
command with the -b option to restrict the execution
of the test suite to one cpu. If allowed to migrate, random
tests can fail due to timing factors. See the run(1) on-
line man page for further usage information.
run -b 0 vtest -V
9. Problem Areas
The following section lists the VSX tests that fail (and the
reason why).
POSIX.os/devclass/cfsetospee 3
Test Information:
SIGHUP not received by controlling process
cfsetospee test 3 is expecting SIGHUP when it sets the
baud rate to B0 on a tty which is not a controlling
terminal. This is incorrect. The test should set B0 on
the loop tty.
Permanent waiver granted.
POSIX.os/ioprim/fcntl 1 3 4 6 7 8
Test Information:
fcntl(4, F_SETFD, 1) failed
the lowest fd available is returned
RETURN VALUES: expected: 0, observed: 1
The tests erroneously assume that 0 is returned on
successful completion of fcntl, when in fact XPG3 and
other specifications state that any value other than -1
indicates successful completion.
Permanent waiver granted.
POSIX.os/misc/unistd_1 7
- 18 -
Release Notes 7.1 VSX Test Suite
Test Information:
Compiler or run-time messages or results:
_POSIX_VERSION has an invalid value
Should have the value: 198808L, Actually had the value: 199009
The IEEE 1003.1-1990 Standard has been published and
supersedes 1988 (on which VSX is based), so it can no
longer be expected that sysconf() return 198808.
Permanent waiver granted.
POSIX.os/procprim/sigconcept 29
Test Information:
deletion reason: external error - waitpid() failed, errno 4
The problem is in the routine ch_t29 within the file
sigcon3.c A portion from the code:
sig_recvd = 0;
i = 0;
j = 0;
while (!sig_recvd)
i++, j++;
This relies on the global variable sig_recvd being
changed asynchronously by a signal catcher routine. The
ANSI C definition requires that such a variable be
declared as volatile. Otherwise, optimizing compilers
could assume that sig_recvd does not change after the
initialization and hence never get out of the while loop.
Permanent waiver granted.
XOPEN.os/genuts/pclose
Test Information:
pclose() did not return the exit code of command
expected 52, pclose() returned 0
The test uses the wrong data type (short) for the return
value from pclose in this test. XPG3 specifies that
pclose returns an int. The other tests correctly use an
int for the return value. The test succeeds when the
proper data type is used.
- 19 -
VSX Test Suite 7.1 Release Notes
Permanent waiver granted.
XOPEN.os/procenv/cuserid
Test Information:
cuserid(buf) did not return buf
current effective user ID is 999 (VSX_UNUSED_UID)
The behavior specified by XPG3 for cuserid() differs from
that of P1003.1-1988, System V Release 4, and historical
implementations, -- all of which return a NULL pointer
value when the login name cannot be determined. We would
prefer not to change the functionality of this interface,
and request that XPG3 be amended to allow the old POSIX
and SVR4 behavior.
Permanent waiver granted.
- 20 -
CONTENTS
1. Introduction............................................. 1
2. Documentation............................................ 1
3. Prerequisites............................................ 2
3.1 Hardware............................................ 2
3.2 Software............................................ 2
4. Installation............................................. 2
5. Cautions................................................. 2
6. VSX Functional Groupings................................. 2
7. Setup and Operation...................................... 3
7.1 Setup............................................... 3
7.2 Configuration Files................................. 5
7.2.1 Installation Scripts......................... 5
7.2.2 vsxconfig.h.................................. 5
7.2.3 vsxparams.................................... 6
7.2.4 userintf.c................................... 8
7.2.5 install.sh................................... 9
7.2.6 .vmakerc..................................... 9
7.2.7 .vtestrc..................................... 11
8. Running the Test Suite................................... 18
9. Problem Areas............................................ 18
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
VSX TEST SUITE
VERSION 7.1
RELEASE NOTES
0891050-7.1
October 1993
_________________________________________________________________
return to index
================================================================================
OSI VT -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The OSI (Open Systems Interconnection) VT (Virtual Terminal)
software package allows remote access/login between Harris
hosts (computers), and between Harris hosts and hosts from
other vendors who run the OSI VT protocol as specified by
the ISO (International Standards Organization) 9040/9041
standards.
The OSI VT product is based upon the VT software package
developed by Retix and operates in a STREAMS-based
environment. VT requires the usage of the OSI LAN Transport
software package to provide the lower protocol layers
(Transport and Networking Layers) needed for communication
in an OSI environment.
The OSI VT product provides a VT initiator (client) and a VT
responder (server). One or both of these pieces can be
utilized on a CX system. The VT initiator is used to access
VT responders on remote systems and the VT responder permits
access by remote VT initiators to the local system on which
it is installed.
The OSI VT product supports the Default A-mode, NIST
(National Institute of Standards and Technology)
Transparent, NIST Telnet, and NIST X.3 terminal profiles.
__________
- These release notes cover the following products: vt
- 1 -
OSI VT 7.1 Release Notes
2. Documentation
The following documentation is included with this release:
_________________________________________________________
| Manual Name Pub. Number|
|__________________________________________|_____________|
| OSI VT Administration Guide | 0890412-000|
| OSI VT Programmer Guide | 0890442-000|
| OSI VT User Guide | 0890444-000|
| OSI Upper Layers Common Facilities Manual| 0890447-000|
| OSI VT Version 7.1 Release Notes | 0890412-7.1|
|__________________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
- 2 -
Release Notes 7.1 OSI VT
3. Prerequisites
Prerequisites for OSI VT version 7.1 are as follows:
3.1 Hardware
o Any Harris Series 4000 or 5000 system.
o Special hardware is needed and is dependent upon the
type of network on which OSI VT is run. One or more of
the following is needed: an Ethernet controller and/or
an FDDI controller.
3.2 Software
o CX/UX 7.1
o STREAMS 7.1
o OSI LAN Transport 7.1
o Ethernet 7.1
4. Installation
Refer to the CX/UX System Administration Manual, Chapter 3,
for instructions on general software installation.
4.1 Product Installation
The OSI VT product is installed in the following fashion:
/etc - Contains OSI VT configuration files.
/usr/bin/osi - Contains the OSI VT initiator command.
/usr/catman - Contains on-line versions of all OSI VT man
pages.
/usr/etc/vt - Contains the OSI VT responder daemon and
support files.
/usr/include/ulcommon - Contains API OSI upper layers
include files.
- 3 -
OSI VT 7.1 Release Notes
/usr/include/vt - Contains OSI VT API include files.
/usr/lib/ulcommon - Contains API OSI upper layers
libraries.
/usr/lib/vt - Contains OSI VT API library.
/usr/man - Contains formatted source code versions of all
OSI VT man pages.
/usr/src/uts/machine/[M88K][NH5000] - Contains OSI VT
kernel module.
4.2 Kernel Configuration
Once the OSI VT software has been installed, the kernel must
be configured and rebuilt to support the OSI LAN Transport
stack over which the OSI VT product must run. To do this,
verify that the OSI LAN Transport stack product has been
installed and then uncomment the following options in the
kernel configuration file prior to kernel
reconfiguration/recompilation:
mbufs #See OSI LAN Transport, Ethernet Release Notes
(0890419)
options STREAMS #STREAMS support
options "NSTRPUSH" #No. of pushes per stream
options "STRCTLSZ" #Max size of control portion of any
message
options NCLONE #Clone driver minor devices
options NLOG #Optional: Log driver minor devices
options NTIRDWR #TLI read/write module minor devices
options NTIMOD #TLI cooperating module minor devices
options OSILAN #OSI LAN Transport stack support
options OSIVT #OSI Virtual Terminal driver support
pseudo-device pty #No. of pseudo terminals to be
supported
- 4 -
Release Notes 7.1 OSI VT
Depending on the system's hardware configuration, uncomment
one or more of the following kernel configuration file
options to configure LAN controllers prior to kernel
reconfiguration/recompilation:
device pg[0-2] #Interphase Peregrine FDDI controller
device ie[0-3] #Integral Ethernet controller
device eg[0-3] #Interphase Eagle Ethernet controller
Refer to the CX/UX System Administration Manual, Chapter 4,
for instructions on configuring and building a kernel.
Also refer to the OSI LAN Transport, Ethernet Release Notes
(Publication #0890419) for information specific to the
building and configuration of the OSI LAN Transport stack on
your system.
4.3 /etc/osid.cfg File Modification
The OSI VT initiator must be able to open the VT STREAMS
loop-around driver, /dev/vtl. In order for the initiator to
access the correct device, the VTL parameter in the
/etc/osid.cfg file must be uncommented. To do this, edit
the file and remove the '#' character in column one of the
line containing the entry. The uncommented VTL parameter
should then begin in column one of this line.
Adding or uncommenting the VTL parameter in the osid.cfg
configuration file, will not require a shutdown and restart
of the OSI LAN Transport protocol stack if it is already
configured and running.
4.4 /dev Configuration
Prior to activating any OSI VT initiator (/usr/bin/osi/vti),
system administrators must use the /dev/MAKEDEV utility (see
makedev(1M)) to create the STREAMS-clone device /dev/vtl.
This device is specified by the VTL parameter in the
/etc/osid.cfg configuration file. OSI VT initiators access
the VTL parameter in osid.cfg to determine the name of this
STREAMS driver. The vtl device is a STREAMS loop around
driver used to provide a STREAMS-based tty input-like
interface to the STREAMS-based OSI VT initiator. Since
CX/UX does not support STREAMS-based tty devices at this
time, the OSI VT initiator must use the /dev/vtl device.
- 5 -
OSI VT 7.1 Release Notes
When each OSI VT initiator session is activated, the vti
process will fork a child process to interface with the
/dev/vtl driver. Therefore, each vti session will have two
processes associated with it. To create the /dev/vtl
device, type the following commands as root or super user:
cd /dev
/dev/MAKEDEV vtl
Pseudo terminal devices (ptys) must also be created under
/dev. Use the /dev/MAKEDEV script to create groups of ptys
by typing the following commands as root or super user:
cd /dev
/dev/MAKEDEV pty# (# = unit number in the range 0-15)
4.5 /etc/rc Script Configuration
Examine the /etc/rc and the /etc/shutdownrc scripts for OSI
VT-specific options prior to rebooting the
reconfigured/recompiled kernel.
4.6 Application Entity Table
The OSI hosts address file __AETABLE__ is installed under
the directory /usr/etc/vt. This generic file is accessed by
all CX OSI application software packages to determine the
OSI addresses of host systems (also known as application
entities or AEs in OSI terms). All of the CX OSI
applications expect the __AETABLE__ file to reside under the
/etc directory. Therefore, this file must be eventually
moved to the /etc directory prior to activating or using any
of the OSI applications. Since this file is released with
every CX OSI application, it is placed under the
/usr/etc/XXX directory (where XXX refers to the particular
OSI application) to prevent accidental overwrite of an
existing __AETABLE__ file in the /etc directory. OSI
administrators do not need to access each __AETABLE__ file
in each OSI application's /usr/etc directory, but either
make only one copy of the file for global use in the /etc
directory or simply modify the existing global
/etc/__AETABLE__ with addressing information for the new OSI
application installed. For more information on this file
consult the __AETABLE__(4) manual page.
- 6 -
Release Notes 7.1 OSI VT
The assignment and format of addresses in this file should
be consistent with those utilized by the OSI LAN Transport
protocol stack. Refer to the Network Directory Compiler
Reference Manual (Publication #0890446) for additional
information on OSI address formats. Also refer to the OSI
LAN Transport, Ethernet Release Notes (Publication #0890419)
for information relating to the determination of LAN device
physical addresses for use in OSI addresses.
Once local OSI VT address entries have been added to the
__AETABLE__, the NSAP portions of those local entries must
be added to the OSI LAN Transport's kernel NSAP table via
the nsap(1M) command. To ensure that these local NSAP
entries will be configured automatically at boot time, add
the new local OSI VT NSAP entries to the nsap command logic
of the /etc/rc system initialization script. Note that the
term "local" refers to those address entries associated with
the system on which the OSI VT product has been installed
and is running on.
4.7 OSI VT Configuration Files
Prior to activating the OSI VT responder /usr/etc/vt/vtr
modify the /etc/vt.cfg, /usr/etc/vt/.vtcli,
/usr/etc/vt/vtlist, and /usr/etc/vt/.vtInit files for
system-specific OSI VT customization (see the OSI VT
Administration Guide and the OSI VT User Guide for further
information). OSI VT TSAP, SSAP, and PSAP entries added to
the /etc/__AETABLE__ must be included in the corresponding
parameters in the /etc/vt.cfg file. Creation of pseudo
terminal devices (ptys) in the /dev directory via the
/dev/MAKEDEV script and the entry of these devices into the
/etc/inittab file will also be necessary prior to OSI VT
responder activation. See the CX/UX System Administration
Manual and the makedev(1M) manual page for further
information on configuring and creating pty devices.
4.8 Environment Variables
OSI VT administrators should take note of the environment
variables VTCLI, VTINIT, and VTI_AENAME, which are used by
the OSI VT application (see the OSI VT User Guide for
further information).
- 7 -
OSI VT 7.1 Release Notes
4.9 OSI VT Manuals and Manual Pages
After the OSI VT package has been installed, examination of
the provided documentation and on-line manual pages is
recommended in order to gain familiarity with the product.
To locate all of the OSI VT on-line manual pages, enter the
following command:
/bin/man -k VT | pg
5. OSI VT API
A OSI VT Application Program Interface (API) is included
with this product. The OSI VT API is contained in the
following library:
/usr/lib/vt/libvt.a
Also required for operation of the OSI VT API are the OSI
upper layers libraries providing the necessary OSI
Application, Presentation, and Session layer protocol
support. This support is contained in the following
libraries:
/usr/lib/ulcommon/libacse.a
/usr/lib/ulcommon/libps.a
/usr/lib/ulcommon/librtp.a
/usr/lib/ulcommon/libsession.a
/usr/lib/ulcommon/libsystem.a
/usr/lib/ulcommon/libupper.a
Support for the USL Transport Layer Interface (TLI) is also
needed and is provided with the general CX operating system
release. This support is provided in /usr/lib/libnsl.a.
Necessary include files are also provided for API support.
These files are installed under /usr/include/ulcommon and
/usr/include/vt.
With the OSI VT API, experienced VT programmers can create
new VT profiles that directly access the VT protocol machine
via the API. Due to the complex nature of the OSI VT
protocol, it is recommended that only very experienced VT
programmers attempt to use the OSI VT API.
- 8 -
Release Notes 7.1 OSI VT
6. Cautions
None.
7. New Features in this Release
None.
8. Changes from Previous Releases
Previous users of the Retix Virtual Terminal product should
note that some CX/UX-specific changes have been made to the
Retix OSI VT product.
o The CX/Retix version of OSI VT utilizes the CX-based
pseudo terminal (pty) driver subsystem rather than a
STREAMS-based pty subsystem. The CX pty driver
subsystem is based on the 4.3BSD pty driver subsystem.
o Since the CX/Retix OSI VT product utilizes CX-based
pseudo terminals, all accounting entries will be
written to the /etc/utmp and /etc/wtmp files. CX/UX
pty accounting entries can be examined using the who(1)
command.
o Since this OSI VT release utilizes existing CX
accounting tools, it will not support the Retix-
implemented vtutmp and vtwtmp accounting files or the
vtwho utility.
9. Recommended Reading Material
The following introductory reference is recommended for
users who are unfamiliar with OSI VT:
Uyless Black. OSI: A Model for Computer Communication
Standards. Prentice-Hall, Inc., 1991. ISBN 0-13-
637133-7.
The following introductory references are recommended for
users who are unfamiliar with the OSI upper layers (i.e.,
Presentation, Session, etc.):
- 9 -
OSI VT 7.1 Release Notes
John Henshall and Sandy Shaw. OSI Explained: end-to-end
computer communication standards. Ellis Horwood Limited,
1990. ISBN 0-13-639451-5.
William Stallings. Handbook of Computer-Communications
Standards. Volume 1, Second Edition. The Open Systems
(OSI) Model and OSI-Related Standards. Howard W. Sams &
Company, 1990. ISBN 0-672-22697-9.
William Stallings. Networking Standards: A Guide to
OSI, ISDN, LAN, and MAN Standards. Addison-Wesley
Publishing Company, Inc., 1993. ISBN 0-201-56357-6.
The following introductory references are recommended for
users who are unfamiliar with STREAMS and the Transport
Layer Interface (TLI):
UNIX System V Release 4 Programmer's Guide: Networking
Interfaces. HCSD Publication Number 0890396.
UNIX System V Release 4 Programmer's Guide: STREAMS.
HCSD Publication Number 0890397.
10. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
- 10 -
Release Notes 7.1 OSI VT
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 11 -
CONTENTS
1. Introduction............................................ 1
2. Documentation........................................... 2
3. Prerequisites........................................... 3
3.1 Hardware........................................... 3
3.2 Software........................................... 3
4. Installation............................................ 3
4.1 Product Installation............................... 3
4.2 Kernel Configuration............................... 4
4.3 /etc/osid.cfg File Modification.................... 5
4.4 /dev Configuration................................. 5
4.5 /etc/rc Script Configuration....................... 6
4.6 Application Entity Table........................... 6
4.7 OSI VT Configuration Files......................... 7
4.8 Environment Variables.............................. 7
4.9 OSI VT Manuals and Manual Pages.................... 8
5. OSI VT API.............................................. 8
6. Cautions................................................ 9
7. New Features in this Release............................ 9
8. Changes from Previous Releases.......................... 9
9. Recommended Reading Material............................ 9
10. Direct Software Support................................. 10
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
OSI VT
VERSION 7.1
RELEASE NOTES
0890412-7.1
November 1993
_________________________________________________________________
Trademark Acknowledgments
Ethernet is a registered trademark of Xerox Corporation
Retix is a registered trademark of Retix
return to index
================================================================================
X.400-1988 -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The CX OSI (Open Systems Interconnection) X.400-1988 Message
Handling System (MHS) software package allows standardized
personal messaging between Harris hosts (computers), and
between Harris hosts and hosts from other vendors who run
the OSI X.400-1988 protocol as specified by the CCITT
(International Telegraph and Telephone Consultative
Committee) X.400 standards developed in 1988.
The CX X.400-1988 product is based upon the X.400-1988
software package developed by Retix and operates in a
STREAMS-based environment. CX X.400-1988 requires the usage
of the OSI LAN software package to provide the lower
protocol layers (Transport and Networking Layers) needed for
communication in an OSI environment.
The CX X.400-1988 product provides support for the User
Agent (UA), Message Store (MS), and Message Transfer Agent
(MTA) components of the MHS. Any combination of these
pieces can be utilized on a CX system.
2. Documentation
The following documentation is included with this release:
__________
- These release notes cover the following products:
x400_88
- 1 -
X.400-1988 7.1 Release Notes
__________________________________________________________
| Manual Name Pub. Number|
|___________________________________________|_____________|
| X.400-1988 User Guide | 0890XXX |
| CX/UX X.400-1988 Version 7.1 Release Notes| |
|___________________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
- 2 -
Release Notes 7.1 X.400-1988
3. Prerequisites
Prerequisites for X.400-1988 Version 7.1 are as follows:
3.1 Hardware
o Any Harris Series 4000 or 5000 system.
o Special hardware is needed and is dependent upon the
type of network on which X.400-1988 is run. One or
more of the following is needed: an Ethernet controller
and/or an FDDI controller.
3.2 Software
o CX/UX 7.1
o CX/UX STREAMS 7.1
o CX/UX OSI LAN 7.1
o Ethernet 7.1
4. Installation
Refer to the CX/UX System Administration Manual, Chapter 3,
for instructions on general software installation.
4.1 Product Installation
The X.400-1988 product is installed in the following
fashion:
4.2 Kernel Configuration
Once the X.400-1988 software has been installed, the kernel
must be configured and rebuilt to support the OSI LAN stack
overwhich the X.400-1988 product must run. To do this,
verify that the OSI LAN stack product has been installed and
then uncomment the following options in the kernel
configuration file prior to kernel recompilation:
- 3 -
X.400-1988 7.1 Release Notes
options STREAMS #STREAMS support
options "NSTRPUSH" #No. of pushes per stream
options "STRCTLSZ" #Max size of control portion of any
message
options NCLONE #Clone driver minor devices
options NLOG #Log driver minor devices
options NTIRDWR #TLI read/write module minor devices
options NTIMOD #TLI cooperating module minor
devices
options OSILAN #OSI LAN stack support
Depending on the system's hardware configuration, uncomment
one or more of the following kernel configuration file
options to configure LAN controllers prior to kernel
recompilation:
device pg[0-2] #Interphase Peregrine FDDI controller
device ie[0-3] #Integral Ethernet controller
device eg[0-3] #Interphase Eagle Ethernet controller
Refer to the CX/UX System Administration Manual, Chapter 4,
for instructions on configuring and building a kernel.
Also refer to the OSI LAN Release Notes (Publication
#0890XXX) for information specific to the building and
configuration of the OSI LAN stack on your system.
4.3 /etc/rc Script Configuration
Examine the /etc/rc and the /etc/shutdown.rc scripts for
X.400-specific options prior to rebooting the OSI-configured
kernel.
- 4 -
Release Notes 7.1 X.400-1988
4.4 Application Entity Table
The OSI hosts address file __AETABLE__ is installed under
the directory /usr/etc/x400_88. This generic file is
accessed by all CX/Retix OSI application software packages
to determine the OSI addresses of host systems (also known
as application entities or AEs in OSI terms). All of the CX
OSI applications expect the __AETABLE__ file to reside under
the /etc directory. Therefore, this file must be eventually
moved to the /etc directory prior to activating or using any
of the OSI applications. Since this file is released with
every CX OSI application, it is placed under the
/usr/etc/XXX directory (where XXX refers to the particular
OSI application) to prevent accidental overwrite of an
existing __AETABLE__ file in the /etc directory. OSI
administrators do not need to access each __AETABLE__ file
in each OSI application's /usr/etc directory, but either
make only one copy of the file for global use in the /etc
directory or simply modify the existing global
/etc/__AETABLE__ with addressing information for the new OSI
application installed. For more information on this file
consult the __AETABLE__(4) manual page.
4.5 Environment Variables
4.6 X.400-1988 Configuration Files
5. Cautions
None.
6. New Features in this Release
None.
- 5 -
X.400-1988 7.1 Release Notes
7. Changes from Previous Releases
None.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 6 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 3
3.1 Hardware............................................. 3
3.2 Software............................................. 3
4. Installation.............................................. 3
4.1 Product Installation................................. 3
4.2 Kernel Configuration................................. 3
4.3 /etc/rc Script Configuration......................... 4
4.4 Application Entity Table............................. 5
4.5 Environment Variables................................ 5
4.6 X.400-1988 Configuration Files....................... 5
5. Cautions.................................................. 5
6. New Features in this Release.............................. 5
7. Changes from Previous Releases............................ 6
8. Direct Software Support................................... 6
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
X.400-1988
VERSION 7.1
RELEASE NOTES
0890XXX-7.1
September 1993
_________________________________________________________________
Trademark Acknowledgments
Ethernet is a registered trademark of Xerox Corporation
Retix is a registered trademark of Retix
return to index
================================================================================