[Top]
[Prev]
[Next]
[Bottom]
The Cooperative Consoles Receiver is the user entry point
for starting the exchange of information between multiple Site/SunNet/Domain
Manager Consoles using Cooperative Consoles (CC). Installation of the Cooperative
Consoles Receiver on a management station adds the Receiver to the Domain
Manager Console's Tools Menu on that machine, as shown in
Figure 3-1
.
When you pull down the Domain Manager Console's Tools menu
and select the Cooperative Consoles Receiver, the Receiver window appears,
as shown in
Figure 3-2
. When launched, the Receiver process attempts to register with the Sender
process on those Site/SunNet/Domain Manager Console machines on the Receiver's
Registration List. The Registration List also specifies the specific database
and event-forwarding criteria (Filter Table) to be used by the remote Sender
processes. To build the Receiver's Registration List, see
Chapter 4, "Using the Configuration Tool
." The Receiver window provides information about the status of the connection
with remote sending stations.
The six buttons on the Receiver window have the following uses:
- First, all existing elements in the database on the local
machine that match the selected connection are deleted. The data for the selected
connection is matched using the Createdbycc
field (<hostname>:<filter-table>:<database-name>). The
Createdbycc field is included in the properties
sheet for that element; see
Figure 3-3
.
- Second, the Receiver sends a synchronization request
to the target sending station. The Sender then sends all topology information
that passes the pertinent filters for the selected entry.
You can quit from the Receiver by pressing MENU over the
control bar at the top of the window and selecting Quit from the control bar
menu.
When you first start the Receiver, the Receiver process
attempts to register with the Sender process on each machine specified on
a list of target management stations. When registering with a Sender on a
remote station, the Receiver can pass a user database name that the Sender
process uses to select database information when forwarding database traps
from that machine. Because multiple user databases can exist on the Site/SunNet/Domain
Manager machine, a user database name is needed to specify which database
the Sender process is to access. The Sender accesses the database file named
db.<database-name>
where <database-name> is passed by the Receiver
at the time of registering with the Sender.
NOTE - Do not enter db. as
part of the database name; the db. is generated automatically.
The Receiver process also passes to each Sender the name
of the filter file to use for selecting event and topology information for
forwarding to the receiving station.
When the Receiver is first launched from the Console
Tools Menu, it attempts to register with the four target hosts, as shown in
Figure 3-2
. As the Receiver attempts to register with the Sender at mgr.West.Sun.Com
, it will pass the value "west_coast" to indicate that the Sender should
access the database file db.west_coast. The Receiver also passes
the filter file name criticalnodes.ccf, that mgr.West.Sun.Com
is to use for selecting information to forward.
Registration with a remote Site/SunNet/Domain Manager
console machine is successful only if the requesting Receiver is on the target
Sender's list of stations authorized to receive forwarded information. (Use
the Configuration Tool on the sending station to define the list of remote
stations authorized to register with the local Sender process, as described
in
Chapter 4, "Using the Configuration
Tool
.")
A Receiver's attempt to register with a Sender process
fails if the Receiver passes the name of a nonexistent filter file or passes
a database name it is not authorized to access. Receivers running on different
hosts can request use of different Filter files when registering with the
same Sender daemon.
3.2.1 Receipt of Topology Information
After a Receiver process successfully registers with
a Sender process on a remote station, topology type information is forwarded
from the Sender process to the Receiver process according to user-configurable
criteria. (Use the Configuration Tool on the sending station to define the
Sender's processing of information to be forwarded.) Multiple Receivers on
various hosts can register with the Sender on a given Site/SunNet/Domain Manager
Console machine and the criteria used for forwarding can be configured separately
for each receiving station.
The Receiver process receives only topology data
(SNM database traps) from the Sender.
NOTE - For other information like the
SNMP traps, SNM events, and the SNM glyph traps, the sender forwards this
information to the Event Dispatcher process directly on the receiving station.
As topology traps are received by the Receiver process,
the Receiver uses the database Application Programming Interface (API) of
the local Domain Manager console to update the local database to reflect
the topology information received from sending stations. The local Receiver
is able to track the source of the elements that it adds to the local database
due to the Createdbycc field. This field
is blank for all elements created by the local Site/SunNet/Domain Manager
console.
Whenever the Receiver creates elements in the local
database, the Createdbycc field is filled
in, as shown in
Figure 3-3
, to indicate the connection that was the source of that topology information.
The Createdbycc field matches the connection
on hostname, filter table, and database name.
User-configurable filters are used at the sending
station to determine what topology information should be forwarded. Forwarded
information can include view memberships, agents and proxy system names on
the element's "properties sheet," glyph color, screen position (X,Y coordinates),
and attributes. See
Chapter 4, "Using the Configuration
Tool
" for instructions on how to configure the types of information to be forwarded.
When the Receiver process receives a topology trap
from a sending station, it reads the local SNM database to determine if this
element already exists. If the element does not exist, it is added to the
local database. If an element already exists in the local database, the Receiver
process determines whether the forwarded features of the element match those
already attributed to the element. If the element's characteristics in the
local database already match the features reported in the trap, the trap
is ignored. If the element's characteristics in the database differ from
the forwarded characteristics, the element information in the local database
is changed to match the information forwarded from the sending station.
NOTE - If an element forwarded from
the sending station already exists in the local runtime database and the existing
record does not match the information passed from the remote sending station,
the Receiver overwrites the existing record with the information forwarded
from the Sender process on the remote station. Only the view membership information
in the existing record is retained. If you want to protect local database
records from being overwritten, you should configure the Sender daemons to
not forward database traps to the local Receiver for those elements.
3.2.1.1 Synchronization of Shared Topology Information
The filters on the sending station define the information
to be shared with remote receiving stations. When the databases exactly match
in this targeted information, they are said to be "synchronized." If a Receiver
is down for a period of time, the database information on the sending machine
can change during that interval. "Synchronization" is the process of updating
the topology information on the receiving station so the two stations have
exactly the same picture of the segment of network information to be shared
between them.
You can manually execute synchronization by clicking
on the Synchronize button (see
Figure 3-2
) or by configuring the Receiver to request synchronization automatically
at start-up or at scheduled times. The Receiver initiates synchronization
by sending a synchronization request to a selected Sender. In response to
a synchronization request from an authorized Receiver, the Sender reads through
its local database and forwards to the Receiver all topology data that passes
the specified filters.
Whenever the Receiver adds elements to the local
database to reflect information passed by remote Senders, it indicates in
the element's
Createdbycc field (as shown in
Figure 3-3
) the hostname, filter table name, and database name that was the source
for that element.
Whenever a synchronization is initiated for a
selected sending station, the Receiver removes all the existing records in
the database with a Createdbycc field that
matches the target host, filter, and database names. Replacement records are
then added to the local database as new information is received from the
sending station in response to the synchronization request. For more information
about database synchronization, see
Section 3.5, "Database Synchronization
."
3.2.1.2 Holding Area Views
By default, a "holding area" view is created at
the receiving console for each connection to a remote sending station. Holding
area views created by the Receiver are indicated in the Home view by the
CC icon, as shown in
Figure 3-4
. The name of a "holding area" view has the following form:
snm:<host-name>:<database-name>
where <host-name> is the name of the sending
station and <database-name> is the database name used by the Sender
daemon at that station.
In
Figure 3-4
, CC holding area views for sending machines named luckybull
and nanak are present in the Home view.
When information about an element's view memberships
is passed from a sending station, the Receiver adds the element to the specified
views, if they already exist. The "holding area" is used to store elements
whose view location is unknown to the Receiver. This situation can occur if
elements are created at the sending station between synchronizations. If
the element is a member of <viewname>, where <viewname> is not
a view that already exists on the receiving station, the Receiver places the
new element in the "holding area" view that corresponds to that sending station.
Topology information passed to a receiving station
during synchronization never goes into holding area views, however. During
synchronization viewname information is always passed before element information,
so the views required for the elements already exist in the database at the
receiving station. Thus, the holding area views are typically empty during
normal operation.
3.2.1.3 Using the Receiver -h Option
If you want the Receiver to leave elements (such
as components, views) that it adds to the local database in the "holding
area" view, the Receiver's -h use the runtime option to implement
it. If you specify the -h option, any views and elements added
to the local runtime database by the Receiver are held in the "holding area"
view. This approach is useful if the local console is receiving forwarded
topology information from a number of sending stations. The topology information
forwarded from each machine is grouped under its respective holding area
view in the console's Home view.
The following two examples illustrate how the
database from different sending stations are grouped in the holding area views
using the Receiver -h option.
In
Figure 3-5
, two different views, Spain from the sending station luckybull
with database artie, and India from the sending station
nanak with database raju, are sent to the
receiving station charm2 with database tylie. When
charm2 receives information from the two sending stations,
luckybull and nanak, it groups the topology
data from the view Spain and India into the two respective
holding area views in database tylie.
However, if both luckybull and
nanak have the same view Spain, then both holding
area views in database tylie on charm2 will contain
all the topology data associated with database artie and database
raju as illustrated in
Figure 3-6
.
To implement the -h option, select Customize
from the Domain Manager Console Tools menu, which invokes the Custom Tools
window, as shown in
Figure 3-7
. Select the Cooperative Consoles Receiver and type in the -h
runtime option, as shown below. Click SELECT on the Change button, then
click SELECT on the Apply button to save the change.
NOTE - Using the -h
option does not prevent the Receiver from overwriting element records if
information for that same element is forwarded from a sending station and
it does not match the existing record. The -h option provides a
convenient way of grouping forwarded information by sending machine. If you
want to prevent overwriting of certain element records in the local SNM database,
you need to configure the Sender daemons to not forward topology information
about those elements.
A building block used by CC is the facility for
forwarding events and traps, provided by the SNM Event Dispatcher (na.event
). The Event Dispatcher permits network management applications to register
with it to receive SNMP traps, SNM events, SNM database traps, and Glyph traps.
Each instance of the Site/SunNet/Domain Manager console running on that machine
is itself a network management application that registers with the Event
Dispatcher to receive all traps and events. The Event Dispatcher spawns a
child process for each network management application that registers with
it.
When the Sender daemon on a given host is first
launched, it registers with the Event Dispatcher on that machine in order
to receive all SNMP traps, Glyph traps, SNM events, and SNM database traps.
The Event Dispatcher forwards this information to the Sender daemon on the
local machine for filtering and forwarding to receiving stations.
On each receiving station, the local Event Dispatcher
receives SNMP traps, SNM events, and Glyph traps from remote Sender processes.
The Event Dispatcher then forwards this information to the Domain Manager
Console on the local machine. The Event Dispatcher on the receiving station
does not receive SNM database traps forwarded from remote Sender daemons
-- topology information is sent to the Receiver process on the receiving station.
The Sender process on a Site/SunNet/Domain Manager
console machine is launched in response to the first registration request
from a remote Receiver process. When the Sender process is first created,
it registers with the local SNM Event Dispatcher to receive all SNMP traps,
Glyph traps, SNM events, and SNM database (topology) traps.
A separate child Sender process is spawned for
each receiving station that registers with the Sender. A Receiver process
unregisters with the Sender if the user selects Quit from the Receiver window
control menu on the receiving station. The Sender process unregisters with
the Event Dispatcher and exits if every Receiver that had registered with
it has unregistered.
3.4.1 Access Control
Access of remote receiving stations to local event
and topology information is controlled by the Sender daemon. A remote Receiver
process can successfully register with the Sender, and access a given local
database, only if that receiving station is authorized to register with this
Sender and access the specified database. To make this determination, the
Sender daemon uses an authorization list that you define using the Configuration
Tool on the sending station. This authorization list provides you with the
ability to prevent unauthorized eavesdropping and discourage unnecessary forwarding
of network event information.
The authorization list allows you to specify
a list of authorized databases for each receiving station. See
Section 4.2.1, "Setting Up
the Authorization List
" for further discussions on Authorization List.
3.4.2 Information Forwarding
As previously discussed, the Event Dispatcher
on the receiving station receives SNMP traps, Glyph traps, and SNM events.
All these events and traps are forwarded by the sender daemon.
The Sender daemon reformats all SNMP traps,
Glyph traps, and SNM events into SNM traps before forwarding them to the Event
Dispatcher on the receiving station. The Event Dispatcher on the receiving
station passes the traps to the local Site/SunNet/Domain Manager Console.
An SNM event is converted into a trap before being sent to a remote Domain
Manager Console. This console ignores an SNM event that it cannot match to
one of its own event requests.
3.4.2.1 Event-Forwarding Example
The example in
Figure 3-8
shows an SNM event as viewed in the Event/Trap Reports window on the Site/SunNet/Domain
Manager console running on the machine montecarlo. As indicated
in the Console footer, the event has been generated by the SNM diskinfo
agent on the router emtv14a-41 in response to an event request
"diskinfo.checkiffull" launched from this console machine. The condition that
defined the occurrence of this event was any file system on emtv14a-41
having more than 90% of its capacity used. The glyph representing
emtv14a-41 has dimmed to indicate an alarm has occurred.
The Sender daemon on montecarlo reformats
this event as a trap, then forwards it to the appropriate receiving stations.
Figure 3-9
shows this trap as viewed in the Event/Trap Reports window on the receiving
station.
The line "coop_forwarded_by=montecarlo" in the
Event/Trap Reports window in
Figure 3-9
indicates that this trap is an event or trap that is forwarded by the Cooperative
Consoles Sender process located on the Site/SunNet/Domain Manager console
machine named montecarlo. Also, notice that the priority of the
event has been changed by the Sender from high to low, as indicated in the
last line in the Event/Trap Report window in
Figure 3-9
. This action is configured by the user when defining the Filter Table used
by the Sender for forwarding events to this receiving station.
3.4.2.2 Filtering Events and Traps for Forwarding
NOTE - Filtering is the most
powerful and complex part of Cooperative Consoles. Please read this section
thoroughly to understand the filtering process before you attempt to configure
the filter files.
The Sender process uses one or more filter files
in processing SNM events, SNMP traps, Glyph traps, and database traps for
forwarding to the Event Dispatcher or Receiver Application on the receiving
stations. The information that needed to be forwarded or dropped to the receiving
station via database traps is specified in database template files. For information
on the types of database traps and the information that can be forwarded,
see
Section 4.2.3.3, "Adding
a Database Trap Type Entry
."
Multiple receiving stations can use the same
filter file if the same criteria are to be used in processing events for
forwarding, or separate filters can be defined for different receiving stations.
Each filter file (filter table) contains one
or many filter entries that define the selection criteria (whether it's a
match) and action (whether to pass or drop) to be taken for a given SNM event,
SNMP trap, Glyph trap, or database trap.
For events, SNMP traps, and Glyph traps,
the selection criteria in each filter entry is based on the following:
- Filter type (for example, hostname, component,
view name, view type, or default)
- Name (host name, component type, view name,
or view type)
- Events or Traps type (for example, events,
SNMP traps, or Glyph traps)
- Trap Selection Template (only if "traps"
is selected and incoming traps are of SNMP trap type; SNMP traps can be further
selected based on this template)
For database traps, the selection criteria in
each filter entry is based on the following:
Any given trap or event that matches the selection
criteria above is selected to pass or drop. Otherwise, the next filter entry
(by precedence rule) is considered for that event or trap. The order of precedence
is as follows:
When more than one filter entry is eligible
for being a match, the first entry encountered is considered for the match.
The filter entries are checked until a match is found or until the filter
file is exhausted. Once a match is found, the action specified in the matching
filter entry is performed after checking against the priority field and making
the necessary priority changes. Any unmatched events or traps are dropped.
An event or trap that is considered a high
priority event for one management station might have a lower priority for
another management station. For this reason, you can also use the filters
to change priorities of events or traps when forwarded from a sending station
to a receiving station.
3.4.2.3 Forwarding of Topology Information
When the Sender daemon receives SNM database
traps from the local Event Dispatcher, it uses the filter file specified
for the target receiving station to determine which database template file
to use in processing the database trap. The DB Template field contains the
template file name.
The name of the element is the minimum information
passed when a database trap is forwarded to the Receiver process on the receiving
station. The database template file allows you to specify additional topology
information that should be forwarded.
Because the filter file allows you to specify
different DB Template files in each filter, you can use the filter selection
criteria to specify different types of topology information to forward for
different devices (by host name or element type), if you define different
DB template files. Refer to
Chapter 4, "Using the Configuration
Tool
" for information about configuring the filter table and the DB Template
files.
The runtime databases on the sending and receiving
stations are said to be "synchronized" when they are in agreement on the
area of network information that they are intended to share. For example,
if Consoles on machines RegionWest and RegionEast are both intended to contain
information about routers on Net_A, then the RegionWest and RegionEast consoles
are synchronized when they have the same information about routers in Net_A.
Synchronization is therefore always in regard to some defined set of data
that two or more runtime databases are intended to share. This information
can include everything in the respective runtime databases or only some of
that information. The intended area of shared data is determined by the filters
on the pertinent sending stations.
Synchronization is an action initiated by
the Receiver. When synchronization is initiated, the Receiver sends a synchronization
request to the selected sending station on its Registration List, that is,
the list of target stations from which the Receiver requests event and topology
information.
When a Sender daemon receives a synchronization
request from a receiving station on its list of authorized Receivers, the
Sender reads through the database and sends all topology information in the
DB Template files indicated for the target receiving station. As this information
is received by the Receiver requesting the updated information, it is added
to the local runtime database.
Whenever the Receiver adds elements to the
local database to reflect information passed by remote Senders, it indicates
in the element's Createdbycc field (as shown
in
Figure 3-10
) the hostname, filter table name, and database name that were the source
for that element.
Whenever a synchronization is repeated for a
target-sending station, already existing elements with a Created
bycc attribute that matches the target hostname, filter,
and database name are deleted and replaced with the updated information received
from the sending station. In this way, the Receiver ensures that the local
database reflects the latest information from the remote sending station.
Because not all of the information in the local database may be shared information,
the Createdbycc attribute enables the Receiver
to identify which portions of the local runtime database are shared with
the remote sending stations.
3.5.1 Ways to Initiate Synchronization
A Receiver can initiate synchronization with
its target sending stations in several ways:
Refer to
Chapter 4, "Using the Configuration
Tool
" for information about configuring the CC Receiver for automatic synchronization.
3.5.2 Multiple Sources of Information
Some scenarios include deriving an element in
your local SNM database from a remote Site/SunNet/Domain Manager console
on host A but not all of the attribute information for that element has come
from host A. An example is illustrated by the periphery-to-center configuration
shown in
Figure 3-11
. In this scenario, information about the device doctest can
be received at Domain Manager Console central from either Console
site1 or Console site2.
In the situation depicted in
Figure 3-11
, the source of the instance doctest on central was
site1, as indicated by the Created
bycc field (shown beneath the elements in this example).
In a case such as this, the source is determined chronologically -- the first
station to send information about an element is considered to be the source.
But modifications to the properties sheet for doctest on
site2 is also reflected in the instance of doctest on
central.
If the Receiver on central initiates
a synchronization with snm1, the elements jupiter and
doctest on central are deleted, then replaced by
updated elements that match the current information on site1. If
additional information about doctest has site2 as its
source, then it is necessary, with this configuration, to do a synchronization
with site2 to update this information as well. When information
about specific elements has its source in multiple connections, it is necessary
to initiate a synchronization with all of these connections to update information
about that element.
The Receiver's Delete Permission option allows
you to control the effect of deleting an element when multiple Site/SunNet/Domain
Manager Consoles are linked by CC. The Createdby
cc field on each element in a local database indicates to the local
Receiver process the source of that element. If the Created
bycc field is blank, this indicates that the local Domain
Manager console created that element -- for example, by running Discover
to build a view of its local network.
On the other hand, if the element was added
to the local SNM runtime database by the Receiver, the Created
bycc field indicates that the particular connection with
a remote sending station was the source of that element. The source information
in the Createdbycc field is in the following
form:
<hostname>:<filter-table>:<database-name>
In the sample configuration in
Figure 3-12
, the arrows indicate the direction of information flow from sending stations
to receiving stations. The two elements doctest and jupiter
were originally created on the station domain1. The Created
bycc fields that result from this configuration are shown
beneath each element.
When an element is deleted on a Site/SunNet/Domain
Manager console, the Sender transmits a delete trap to registered Receivers
if that element falls in the area of network information to be shared between
them (as defined by the filters). If you have configured the Receiver's connection
to that sending station with a Delete Permission of All, then the Receiver
deletes the indicated element, no matter whether that remote sending station
was the source of the element or not. If the Delete Permission for that connection
is set to Source, however, then only elements that had that connection as
their source could be deleted as the result of a deletion of an element on
that remote station.
In the case of the configuration in
Figure 3-12
, if the Receiver on domain1 has its connection with domain3
set to a Delete Permission of All, and a user on domain2 or
domain3 deletes the element, this results in its
deletion on domain1 as well. On the other hand, if domain1's
connection to domain3 has a Delete Permission set to Source,
then the deletion of jupiter on either domain2 or
domain3 would not result in the deletion of
jupiter on domain1, since domain1 is itself
the source of that element on that console. Setting the Delete Permission
to Source for a connection means that only an element whose Created
bycc field matches that connection can be deleted as the
result of a delete trap received from that connection.
If Domain Manager console A has received an
element from another Site/SunNet/Domain Manager console, B, then the
Createdbycc field for the instance of that element
on Console B is filled in on the element's properties sheet to indicate that
host A was the source for that information. For example,
Figure 3-13
shows part of the properties sheet for a router element named "emp-lab-swqa."
The Createdbycc field on this properties
sheet indicates that this element was received from the host luckybull
.
Elements created locally on B (for example,
by running Discover), on the other hand, have a blank Created
bycc field. An element with a blank Created
bycc field is said to be local to that Console.
Elements that are not local are deleted by the Receiver when a synchronization
is initiated with the sending station that was the source for that element.
3.7.1 Localizing Selected Elements
Situations can arise where you do not want an
element that was received by CC from a remote station to be deleted when
a synchronization is performed. You can accomplish this by blanking out the
Createdbycc field in the properties
sheet for that element.
To do this, select Properties... from the
element's icon pulldown menu to invoke the element's properties sheet. Delete
the information in the Createdbycc field,
then select Apply. An element that has had its Createdby
cc field blanked out this way is said to be "localized." You can localize
selected elements manually, as just described. But the CC Receiver also provides
a facility for doing a global localization of all elements received from
a selected connection.
3.7.2 Global Localization
Clicking on the Localize button in the Receiver
window clears the Createdbycc field for
all elements that had the selected connection as their source. The CC Receiver
then regards these elements as having the local Domain Manager console as
their source -- as if they had been created locally by running Discover,
for example.
The Localize button should be used only in
certain special situations. If parts of the local network topology on your
console have been built up by receipt of topology information from remote
sending stations, in certain occasions you might not want this information
to be wiped out by a new synchronization. You can localize the information
received from selected stations so that a new synchronization with those stations
does not erase that previously acquired topology data.
An example of such a situation is illustrated
in
Figure 3-14
. Figure 3-14
shows two Domain Manager consoles arranged in a peer-to-peer configuration.
(The peer-to-peer configuration is defined in
Chapter 2, "Cooperative Consoles Configurations
.") The host domainA is the source of the database elements
jupiter and doctest on domainB. If the database
on domainA should be cleared (for example, by starting Domain Manager
with the -i option), the database could be recovered if
domainA were to synchronize with domainB .
However, the database information that is passed from domainB
to domainA now indicates domainB as its source, as shown in
Figure 3-15
.
NOTE - In the situation depicted
in Figure 3-15
, the area of shared information is derivative on both machines -- there
is no underived database source for this information. In this situation it
is recommended that you recreate a base or underived source for the data by
localizing one of the copies of the information. Otherwise, a synchronization
on either domainA or domainB for this connection will
result in the data being deleted on both machines since there is no underived
data source from which the information can be updated. Localizing the connection
at the Receiver for domainA allows you to designate the local Console
domainA as the source for the data, thus restoring
the situation depicted in Figure 3-14
.
The Receiver window provides the method for
shutting down operation of CC. If you press the MENU button over the Receiver
window control panel, the control panel popup menu appears. If you select
Quit, the local Receiver process unregisters with the Sender processes at
each of its target sending stations.
When all of the Receiver processes that
have registered with the Sender process on a given Site/SunNet/Domain Manager
machine unregister, that Sender process on that machine unregisters with the
local Event Dispatcher and exits. Thus, all CC operations -- Sender and Receiver
processes -- cease after Quit has been selected for the Receiver process
at each receiving station.
The Cooperative Consoles executable binaries
must be installed under the same path as the SNM executables ($SNMHOME).
The default location for the executable binary files for CC is:
These files can be relocated or installed on
a server and shared across a network. The file structure for the Cooperative
Consoles product is shown in
Table 3-1
. SNMHOME here refers to the path where Site/SunNet/Domain Manager has been
installed.
The contents of the filter directory are
copied to:
libcoop is a directory for all libraries
required to operate CC.
By convention, the following extensions
are used. However, you can specify your own extensions.
[Top]
[Prev]
[Next]
[Bottom]
Copyright 1996 Sun Microsystems, Inc., 2550 Garcia Ave.,
Mtn. View, CA 94043-1100 USA. All Rights Reserved