The following is a verbatim type-up (actually a scan) of a nifty telco
manual/specs sheet found at my local 5ESS end office while trashing,
minus the pretty pictures. Doesn't have any "DO NOT DISTRIBUTE UNDER
PUNISHMENT OF DEATH" writing on it, so I guess its OK to share it.
-cosec
-----------------------------------------------------------------------------
DEC Signalling System 7 (DECss7) Version 2.5
SPD 34.19.04
--DESCRIPTION--
DEC Signalling System 7 (DECss7) is a communications software product. It
allows Digital UNIX[R] (formerly known as DEC OSF/1) Alpha system based and
OpenVMS Alpha system-based telecommunications applications to be connected
to Signalling System Number 7 (SS7) networks that conform to ITU Blue Book
(1988) and White Book (1992) for TCAP Recommen dations (International
Telecommunications Union Telecommunications Stan dardization Sector; ITU-T,
formerly known as CCITT), American National Standards Institute (ANSI) (1988)
Recommendations, the European Telecommunications Standards Institute (ETSI)
1991 Standard, and the Japanese Telecommunications Technology Committee (TTC)
1990 Recommendations.
The aim of DECss7 is to provide Signalling Point functions to applications
that use the Signalling System 7 protocol. Application Pro gramming
Interfaces are available to the application programmer at the MTP3, SCCP and
TCAP levels of the protocol and at the management and administration level of
the platform.
DECss7 allows extremely high levels of availability to be obtained by
implementing a distributed configuration, where all components (software or
hardware) can be replicated for redundancy.
Environment:
DECss7 provides end-node connectivity to a Signalling System 7 network.
Examples of where such connectivity can be used are "Home Lo cation
Registers" (HLR), "Authentication Centres" (AUC) and "Equip ment Identity
Registers" (EIR) in Mobile Networks, and "Service Con trol Points" (SCP) or
Intelligent Peripherals (IP) in Intelligent Networks.
Three major types of component compose the DECss7 product. One component,
DECss7 Front-End Process (FEP), provides connectivity. The DECss7 Back-End
Process (BEP), provides access to one or more of the DECss7 APIs at the MTP3,
SCCP or TCAP levels. The Director Process (DIR) provides access to the
Management API. These components can be co-resident on the same CPU or
distributed across a Client/Server environment, supporting multiple copies of
applications and multiple access links across multiple CPUs.
Components:
DECss7 implements the following functions (refer to Statement of Compliance
Documents):
Message Transfer Part Level 1 (MTP1) For connection to the Signalling
network, DECss7 uses the standard Digital EISA card DNSES Communications
Controller for Alpha systems. DECss7 requires that the clock be generated
externally for speeds of 48, 56, and 64K bps. Bit rates up to 64K bps are
supported for each channel of the DNSES Communications Controller. Two active
channels per communications controller are supported, and a machine running
the DECss7 Front End Process can support a maximum of five DNSESs. Four
physical connections are possible:
Standard V.35 cable with a 34 pin connector (ISO 2593)
Standard V.36 cable with V10/V11 levels and a 37 pin connector (ISO 4902).
Modified V.35 cable for X21 interface (leased-line)
E1 and T1 connections with the use of a multiplexer.
Message Transfer Part Level 2 (MTP2) DECss7 implements the Basic Error
Correction method.
Message Transfer Part Level 3 (MTP3) For the ANSI version of DECss7 V2.5
the following features are available for cluster messages:
The handling of messages on a cluster basis
Signalling Route management for the cluster
Dynamic destination management for unknown destinations in a known
cluster.
Discrimination: DECss7 implements end-node functions; DECss7 recognises
itself as a single Point Code.
Distribution: DECss7 implements multiple MTP user parts, one of which is
SCCP.
Routing: Associated and Quasi-Associated modes are supported. The maximum
number of Destination Point Codes (DPCs) is set at configuration time. There
is no logical limit on the number of allowed DPCs. There may be up to 16
routes per DPC for ITU-T (32 for ANSI, 2 for TTC) with a single linkset per
route. The method of load-sharing or priority resolution performed across
routes for a DPC or a cross links for a linkset is modifiable.
Congestion: DECss7 V2.5 provides two options:
Congestion for international signalling networks (ITU-T and CHINA)
Congestion with multiple thresholds and priority for national signalling
networks (ANSI and TTC).
Traffic Management: All procedures are implemented except for MTP Restart.
Link Management: DECss7 implements the basic link management procedures.
Route Management: Transfer Allowed, Transfer Restricted and Transfer
Prohibited messages are received and processed for destinations and clusters
according to the ANSI recommendations. The Route-Set Test procedure is
implemented.
Testing and Maintenance: DECss7 implements the procedures described in
the Q.70 7 Recommendation. This is used for putting links into service and
processing Adjacent Signalling Point Restart procedures.
Signalling Connection Control Part (SCCP) DECss7 implements the two
connectionless classes: Class 0 (Basic) and Class 1 (Sequenced).
DECss7 V2.5 SCCP allows outgoing messages to be sent with routing based
on simplified Global Title translation. Outgoing messages are sent to one
(or two) signalling points where the full translation takes place. SCCP
management functions are supported.
Transaction Capabilities Application Part (TCAP):
A White Book implementation is provided at this protocol level for the
ITU-T variant.
DECss7 V2.5 implements both the structured dialogue and the unstructured
(unidirectional) dialogue options. The indefinite length form is accepted
in reception. Through the DECss7 application interface two types of primitive
are provided: dialogue-handling primitives and component-handling primitives.
Management:
Any component of DECss7 is an entity that can be controlled and monitored: in
particular, the applicable measurements specified in the Q.791
Recommendations are made accessible; similarly, any event (for example, link
failure) can be reported.
For the design of the management structure of DECss7 an object-oriented
director entity framework is used.
Application Programming Interfaces:
Multiple Application Programming Interfaces (APIs) can be used at different
levels of the SS7 protocol in the same application. This func tionality
allows applications to handle different types of Signalling System 7
messages.
The DECss7 TCAP API allows an application to open or close TCAP dialogues, to
exchange components, and to handle special conditions that occur
asynchronously during a dialogue. The DECss7 SCCP API allows both data and
SCCP management requests or indications to be sent and received. The DECss7
MTP API allows MTP messages to be sent and received. A single application
process can access different APIs.
The procedures of the interfaces are mapped to the logical TCAP, SCCP or
MTP procedures and consist of a library of routines (requests and
indications) linked to the application software.
The DECss7 APIs are offered under both the Digital UNIX V3.2D Operating
System and the OpenVMS V6.2 Operating System. Under Digital UNIX, they can be
called using the C or C++ programming language only. Under OpenVMS, they can
be called using any programming language.
Management Application Programming Interface:
This interface allows a management application to access the internal
functions of DECss7 to control and monitor them and allows the man agement of
distributed configurations.
The Management API consists of a library of routines accessible under the
Digital UNIX V3.2D Operating System or the OpenVMS Operating System V6.2.
Under Digital UNIX, these can be called using the C or C++ programming
language only. Under OpenVMS, they can be called using any programming
language.
DECss7 is shipped with a basic management application that can configure and
start the product; it offers a command-line interface. A full-function
management application is not supplied with DECss7 V2.5 and must be
developed.
Generic User Part Application Programming Interface:
The GUP API enables a customer to develop an application that can be managed
by the standard management API.
In this way, the same management application can manage both the DECss7
entities and private entities of the application with the same set of
requests available at the management API level.
SCCP Management Interface:
Similar to the management API, this interface is a set of routines allowing
an application to send or receive SCCP management requests or indications,
exchanged with the signalling network or remote network users. This interface
is also available in the SCCP API.
User Distribution:
If the default DECss7 message distribution mechanism for incoming messages
does not select an application copy in an appropriate way for a particular
application, it is possible to implement a customised mechanism instead. The
default mechanism and various customised mechanisms can coexist on the same
platform. Each application Subsystem Number (SSN) or Service Indicator (SI)
can use a customised mechanism or the default mechanism.
DECss7 provides User Distribution (UD) API functions for implementing user
distribution algorithms.
MultiNetwork Platforms:
DECss7 allows one hardware platform to function as several separate
signalling points in the same or different networks, provided that
appropriate versions of the software are installed. For example, a
single hardware platform could function as:
A signalling point in an ITU-T network and a signalling point in an ANSI
network: both ITU-T and ANSI versions of the software are installed.
A signalling point in an ANSI network, but with an ITU-T TCAP application:
the ITU-T version of the TCAP level and the ANSI ver sion of the Network
Service Part (SCCP and MTP levels) are installed.
Two separate signalling points in the same (ANSI) network: each signalling
point is identified by a different SS7 network address (Point Code). Only the
ANSI version of the software is installed. This type of configuration is also
possible for the other protocol variants, such as ITU-T or CHINA. (This is
the type of configuration used in verifying an installation with the
Installation Verification Procedure (IVP), as described in the DECss7
Installation Guide.)
Distributed Implementation:
Both FEP and BEP functionality can run on the same machine, or machines can
be dedicated to FEP or BEP functions. In the latter case, the machines are
referred to as front-ends or back-ends respectively. In such a configuration
the front-ends are dedicated to handling links, while applications run on the
back-ends. The links of a linkset may be distributed across a number of
processors that collectively have the same Signalling Point Code.
When there is more than one processor in a DECss7 configuration, the
processors are linked by one or more Ethernet or FDDI LANs. A given
application, identified by a Subsystem Number may have several copies running
on the same or on different processors in a configuration.
Note: Digital recommend that you have a dedicated Ethernet or FDDI link
between BEP and FEP. If the Ethernet or FDDI link is not dedicated to DECss7
internal use, then you must make sure that this link is not loaded at
maximum. For instance, on Ethernet do not exceed 30% load.
Performance:
DECss7 V2.5 can handle throughput from hundreds to thousands of Message
Signal Units per second depending on the configuration and the power of the
machines configured. Full details on the performance of DECss7 are available
from the Telecom Expertise Center through your local Digital office.
Clustering:
A DECss7 V2.5 platform can be configured for operation on member nodes that
also form part of a cluster as determined by the configuration of the
Operating System. Full details on clustering for DECss7 are available from
the Telecom Expertise Center through your local Digital of fice.
Dimensioning:
The sizing and configuring of a DECss7 platform depends on the number of
links required, performance goals, availability requirements, and the size of
the application. For more information, contact your local Digital office.
--STANDARDS--
Table 1 contains the equivalent ITU-T, Bellcore, TTC, ANSI and CHINA
Recommendations for each of the SS7 protocols implemented in DECss7 V2.5. In
compliance with the ITU-T Q.700 Recommendation, mapping of the SS7 stack has
been attempted according to the Open System Interconnection (OSI) model.
For a full definition of compliance to standards consult the relevant
statement of compliance document available from your local Digital office.
------------------------------------------------------------------------
Table 1: SS7 Standards Addressed by DECss7 V2.5
________________________________________________________________________
CHINA
(based
on
OSI GF001- SS7
Layer ITU-T Bellcore TTC_[1] ANSI 9001[2])
Protocol
________________________________________________________________________
1 to 7 Q700 Q.700 SS7
Overview
7 Q.771 Q.771 T1.114.1 Q.771
TCAP
7 Q.772 Q.772 T1.114.2 Q.772
TCAP
7 Q.773 Q.773 T1.114.3 Q.773
TCAP
7 Q.774 Q.774 T1.114.4 Q.774
TCAP
7 Q.775 Q.775
TCAP
3 Q.711 Q.711 T1.112.1 Q.711
SCCP
3 Q.712 Q.712 T1.112.2 Q.712
SCCP
3 Q.713 Q.713 T1.112.3 Q.713
SCCP
3 Q.714 Q.714 T1.112.4 Q.714
SCCP
3 Q.716 Q.716 Q.716
SCCP
Perfor-
mance
1 to 3 Q.701 Q.701 JT-Q.701 T1.111.1 Q.701 MTP
Overview
1 Q.702 Q.702 JT-Q.702 T1.111.2 Q.702
MTP1
2 Q.703 Q.703 JT-Q.703 T1.111.3 Q.703
MTP2
3 Q.704 Q.704 JT-Q.704 T1.111.4 Q.704
MTP3
3 Q.707 JT-Q.707 Q.707
MTP3
On-Line
Testing
&
Main-
tenance
1 to 3 Q.705 Q.705 T1.111.5 Q.705
Network
9
Struc-
ture
1 to 3 Q.706 Q.706 T1.111.6 Q.706 MTP
Per-
formance
1 to 3 T1.111.7 MTP
1 to 3 T1.111.8 MTP
1 to 3 Q.780 Q.780 MTP
Tests-
Overview
2 Q.781 Q.781 Q.781
MTP2
Tests
3 Q.782 Q.782 Q.782
MTP3
Tests
1 to 3 Q.791 Q.791 Q.791 MTP
and
SCCP
Measurements
________________________________________________________________________
[1]The TTC protocol is test-qualified on request only.
[2]The ITU-T recommendations are modified or supplemented for CHINA by
the set of specifications contained in the technical specification document
GF001-9001 issued by the Ministry of Posts and Telecommunications of the People's
Republic of China.
------------------------------------------------------------------------
--INSTALLATION--
Digital recommends that the customer's first purchase of this product
includes Digital Installation Services.
--HARDWARE REQUIREMENTS (FRONT-END)--
The connectivity part of DEC Signalling System 7 (DECss7) is sup ported
on the following AlphaGeneration[TM] products from Digital Equipment
Corporation, and with a minimum of 256 MB memory for Digital UNIX and 128 MB
memory for OpenVMS. For connectivity to the Signalling System 7 network, the
DNSES board is required on AlphaGeneration systems from Digital. Up to five
DNSES boards can be installed on one machine.
When a DECss7 machine is configured as a FEP, other protocols using the
DNSESs can be supported on the same machine.
Processors Supported:
AlphaGeneration
products
from
Digital:
Digital AlphaServer[TM] 2100 4/200,
Digital AlphaServer 2100 4/275,
Digital AlphaServer 1000 4/200,
Digital AlphaServer 2000 4/200.
Processors Not Supported:
For connectivity reasons no AlphaGeneration processors from Digital
without EIS A bus are supported.
--HARDWARE REQUIREMENTS (BACK-END)--
Processors Supported:
AlphaGeneration
products
from
Digital:
Digital AlphaServer 8200,
Digital AlphaServer 8400,
Digital AlphaServer 2100 4/200,
Digital AlphaServer 2100 4/275,
Digital AlphaServer 4100,
Digital AlphaServer 1000 4/200,
Digital AlphaServer 2000 4/200,
Digital AlphaStation[TM] 600,
Digital AlphaStation 400 4/233,
Digital AlphaStation 500,
Digital AlphaStation 200 4/233,
Digital AlphaStation 200 4/166,
Digital AlphaStation 250,
Digital AlphaStation 255.
--SPECIAL HARDWARE REQUIREMENTS--
For questions about hardware requirements for special configurations,
please contact the engineering group or product management, both in the
Telecom Expertise Center, contactable through your local Digital office.
--OPTIONAL HARDWARE (BACK-END)--
A second Ethernet interface and cable. An FDDI interface with one or two
attachments.
Processor Restrictions:
The minimum memory required is 256 MB for Digital UNIX and 128 MB for
OpenVMS.
--SOFTWARE REQUIREMENTS--
DECss7 Front-End Process:
Digital UNIX Operating System Version 3.2D or
OpenVMS Alpha Operating System Version 6.2
DECnet/OSI Version 3.2 for Digital UNIX V3.2D Alpha Systems, if chosen as
the internal DECss7 transport, or
DECnet/OSI Version 6.3 for OpenVMS Alpha Systems.
WANDD Version 1.2 for Digital UNIX Alpha Systems, included in the product
X.25 Version 1.2 for DEC OSF/1 Systems or
WANDD Version 1.0D for OpenVMS Alpha Systems.
DECss7 Back-End Process:
Digital UNIX Operating System Version 3.2D or
OpenVMS Alpha Operating System Version 6.2
DECnet/OSI Version 3.2 for Digital UNIX Alpha Systems, if chosen as the
internal DECss7 transport, or
DECnet/OSI Version 6.3 for OpenVMS Alpha Systems.
--SOFTWARE LICENSING--
There are two types of DECss7 license:
A DECss7 BEP license allows access to the DECss7 APIs and management APIs
with the specified stack standard. One or more stacks can be combined on the
same machine and accessed by the user application.
A DECss7 FEP license allows connection to the physical SS7 links. A
concurrent FEP license is valid for two physical links. With a traditional
FEP license, all the physical links that can be connected to a particular FEP
machine can be addressed.
The BEP and FEP can run on the same machine or be distributed and
combined over several machines, still representing one single point code, for
software and hardware fault tolerance.
If the FEP and BEP are on the same machine, and only one machine is present
in the system, a special package, called a monolithic configuration, is
introduced to promote entry-level solutions.
A monolithic solution has to be considered as standalone. It is not possible
to assign the same point code to two monolithic solutions next to each other.
For these, distributed licenses must be purchased.
The DECss7 licensing fee is calculated using the appropriate number of BEP
licenses for the back-end processors, plus the number of FEP licenses for
the number of physical links required divided by two for the front-end
processors.
There is no update procedure to migrate from monolithic to distributed
licenses. The full licenses have to be purchased.
When one or more FEP licenses are added to an existing configuration, the
TUTU (Trade Up to User) licenses must be purchased (again one license for
every two physical links).
Upgrades from previous versions are to be performed using for the BEP the
traditional update licenses and for the FEP either the traditional update
licenses or the concurrent update ones (if the latter, again one license
every two physical links).
This software is furnished under the licensing provisions of Digital
Equipment Corporation's Standard Terms and Conditions. For more information
about Digital's licensing terms and policies, contact your local Digital
office.
--DECss7 V2.5--
Licenses Available - Digital UNIX Alpha systems
Back-
End
ANSI:
QL-3Z7A*-AA DECss7-ANSI O/A TRAD LIC
QL-3Z7A*-RA DECss7-ANSI O/A TRAD UPD LIC
QL-3Z7A9-LG DECss7-ANSI O/A 180 DAY LOAN
Back-
End
ITU-
T:
QL-3Z8A*-AA DECss7-ITU O/A TRAD LIC
QL-3Z8A*-RA DECss7-ITU O/A TRAD UPD LIC
QL-3Z8A9-LG DECss7-ITU O/A 180 DAY LOAN
Back-
End
TTC:
QL-3Z9A*-AA DECss7-TTC O/A TRAD LIC
QL-3Z9A*-RA DECss7-TTC O/A TRAD UPD LIC
QL-3Z9A9-LG DECss7-TTC O/A 180 DAY LOAN
Front-
End:
QL-3ZBA9-AA DECss7-FEP O/A TRAD LIC
QL-3ZBA9-RA DECss7-FEP O/A TRAD UPD LIC
QL-3ZBAM-3C DECss7-FEP OSF CONC 2 LIC
QL-3ZBAM-5C DECss7-FEP OSF CONC 2 UPD
QL-3ZBAM-9C DECss7-FEP OSF CONC 2 TUTU
QL-3ZBA9-LG DECss7-FEP O/A 180 DAY LOAN
--DECss7 V2.5--
Licenses Available - OpenVMS Alpha systems
Back-
End
ANSI:
QL-3Z1A*-AA DECss7-ANSI V/A TRAD LIC
QL-3Z1A*-RA DECss7-ANSI V/A TRAD UPD LIC
QL-3Z1A9-LG DECss7-ANSI V/A 180 DAY LOAN
Back-
End
ITU-
T:
QL-3Z2A*-AA DECss7-ITU V/A TRAD LIC
QL-3Z2A*-RA DECss7-ITU V/A TRAD UPD LIC
QL-3Z2A9-LG DECss7-ITU V/A 180 DAY LOAN
Back-
End
TTC:
QL-3Z3A*-AA DECss7-TTC V/A TRAD LIC
QL-3Z3A*-RA DECss7-TTC V/A TRAD UPD LIC
QL-3Z3A9-LG DECss7-TTC V/A 180 DAY LOAN
Back-
End
CHINA:
QL-56KA*-AA DECss7-CHI V/A TRAD LIC
QL-56KA*-RA DECss7-CHI V/A TRAD UPD LIC
QL-56KA9-LG DECss7-CHI V/A 180 DAY LOAN
Front-
End:
QL-3Z5A9-AA DECss7-FEP V/A TRAD LIC
QL-3Z5A9-RA DECss7-FEP V/A TRAD UPD LIC
QL-0S8AA-3C DECss7-FEP VMS CONC 2 LIC
QL-0S8AA-5C DECss7-FEP VMS CONC 2 UPD
QL-0S8AA-9C DECss7-FEP VMS CONC 2 TUTU
QL-3Z5A9-LG DECss7-FEP V/A 180 DAY LOAN
Note: The part numbers shown are valid at time of release. Please contact
your local Digital office for the most up to date information.
DECss7 V2.5 Monolithic Packages:
Licenses Available - Digital UNIX Alpha systems
QP-02WAA-01 DECss7 F/B O/A LIC PKG
...1 QL-3ZBAM-3C DECss7-FEP OSF CONC 2 LIC
...1 QL-3Z6AQ-AA DECss7-BEP O/A TRAD LIC
QP-02WAA-02 DECss7 F/B O/A LIC PKG
...1 QL-3ZBAM-3C DECss7-FEP OSF CONC 2 LIC
...1 QL-3Z6AG-AA DECss7-BEP O/A TRAD LIC
QP-02WAA-03 DECss7 F/B O/A LIC PKG
...1 QL-3ZBAM-3C DECss7-FEP OSF CONC 2 LIC
...1 QL-3Z6AE-AA DECss7-BEP O/A TRAD LIC
DECss7 V2.5 Monolithic Packages:
Licenses Available - OpenVMS Alpha systems
QP-02VAA-01 DECss7 F/B V/A LIC PKG
...1 QL-0S8AA-3C DECss7-FEP VMS CONC 2 LIC
...1 QL-3Z0AQ-AA DECss7-BEP V/A TRAD LIC
QP-02VAA-02 DECss7 F/B V/A LIC PKG
...1 QL-0S8AA-3C DECss7-FEP VMS CONC 2 LIC
...1 QL-3Z0AG-AA DECss7-BEP V/A TRAD LIC
QP-02VAA-03 DECss7 F/B V/A LIC PKG
...1 QL-0S8AA-3C DECss7-FEP VMS CONC 2 LIC
...1 QL-3Z0AE-AA DECss7-BEP V/A TRAD LIC
Monolithic Solutions:
Part numbers QL-3Z6A*-** and QL-3Z0A*-** represent special entry-level
back-end solutions that can only work in an undistributed way.
They cannot be purchased individually but only in packages to gether with
the appropriate front end. Additional front-end links can be added to such
packages as needed, but without any possibil ity of distributing the solution
across machines.
If the need for a distributed solution arises, the appropriate back-end
licenses for a distributed system must be purchased.
License Management Facility Support:
This layered product supports the Digital UNIX and OpenVMS License
Management Facility.
License units for the BEP functionality are allocated on an Unlimited System
Use basis. License units for the FEP functionality are allocated on an
Unlimited Use plus Concurrent Use basis.
For more information on the License Management Facility, refer to the
appropriate Product Description (SPD 25.01.xx) or the License Management
Facility Manual of the OpenVMS Operating System documentation set.
OpenVMS Tailoring:
For OpenVMS, the following OpenVMS classes are required for full
functionality of this layered product:
OpenVMS Required Saveset
Network Support
Secure User's Environment
Utilities
ORDERING DECss7:
Software media and documentation are distributed directly by the engineering
team in the Telecom Expertise Center, contactable through your local Digital
office, which sends an internal mail to DECSS7_ORDER@VBO containing the
following information:
The item required:
SW kit
Documentation kit
The version required:
V2.5
The protocol variant required:
ANSI for the North American market
ITU-T for the European and Asian markets
TTC for Japan
CHINA for China (not available on Digital UNIX Alpha systems).
The platform required:
Digital UNIX Alpha systems
OpenVMS Alpha systems
--GROWTH CONSIDERATIONS--
The minimum hardware and software requirements for any future version of
this product may be different from the requirements for the current version.
--SOFTWARE PRODUCT SERVICES--
Consulting and training services relating to this product, and services for
implementing particular customer-specific variants to the standard product
are available.
A variety of service options are available from Digital. For more
information, contact your local Digital office.
--SOFTWARE WARRANTY--
Warranty for this software product is provided by Digital with the purchase
of a license for the product as defined in the Software Warranty Addendum of
this SPD.
The above information is valid at the time of release. Please contact your
local Digital office for the most up-to-date information.
[TM] The DIGITAL Logo, AlphaGeneration, DEC, DECnet, DECstation, DECsystem,
DEC windows, DECss7, MicroVAX, OpenVMS, TK, VAX, VAXft, VAXserver,
AlphaServer, AlphaStation, VAXstation, Q-bus and Digital UNIX are trademarks
of Digital Equipment Corporation.
Digital UNIX V3.2 is an X/Open UNIX 93 branded product.
[R] Motif and OSF/Motif are registered trademarks of Open Software
Foundation, Inc.
[R] OSF/1 is a registered trademark of Open Software Foundation, Inc.
[R] UNIX is a registered trademark in the United States and other
countries
licensed exclusively through X/Open Company, Ltd.
[R] X/Open is a registered trademark of X/Open Company, Ltd.
AE-PHT5C-TE
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
