DOCUMENT DETAILS
Document title Technical Requirements Specification
UNIverse D3.1.1
reference
Other references D3.1.2 - Critical Success Factors
D3.2.1 - User Services Requirements Specification
Author(s) R. Murray
Availability Public Domain
Ownership Consortium
Version 2.1
Date 07-Oct-97
Status Released
DOCUMENT RELEASE
Primary reviewers WP 3.1 participants QA'd by George Bingham Accepted by George Bingham Acceptance date 30-April-1997
DOCUMENT HISTORY
Version Date Status Description Distribution
1.0 24/12/96 Draft First issue with proposed table Consortium
of contents
1.0.1 21/01/97 Draft First draft for comment Consortium
1.0.2 07/02/97 Draft Draft for comment Consortium
1.0.3 23/04/97 Draft Final draft Consortium
1.0.4 30/04/97 Draft Submitted for QA GB
2.0 30/04/97 Released Consortium and EC
2.1 07/10/97 Released Second Release Consortium & EC
Published by Fretwell-Downing, Brincliffe House, 861 Ecclesall Road, Sheffield, S11 7AE, UK on behalf of the UNIverse Consortium.
UNIverse Consortium. This document is protected by copyright. Distribution or duplication in any form or processing of the document or any part of it by electronic systems may be done only with the explicit permission of the UNIverse Consortium.
R. Murray - 27/01/97
Summary: This document defines the technical requirements of the system from the point of each of the components defined in the system architecture. The definitions are then further developed in the specifications work packages 4.x
TABLE OF CONTENTS
0. Introduction & Scope
1. Logical Union Catalogue 1.1 Character Set 1.2 Query Adaptation 1.3 Record Syntax Conversion 1.4 De-duplication & Merging
2. Local Services 2.1 User Profile Services 2.2 Database Profile Services 2.3 Multi-lingual Thesaurus Services & Thesaurus Storage 2.4 Local Searching, Catalogue and Object Store
3. Search Kernel / Z39.50 Facilities 3.1 Z39.50(+) Server 3.2 Scalability, Client-Server Interaction & Performance 3.3 Z39.50 Client
4. Inter-Library Loans & Document Requesting
5. Document Delivery
6. Record Download
7. User Interface & Administration 7.1 WWW Interface 7.2 UNIverse Client
8. Process Monitor
9. Error Logging
10. Components Interface
11.1. Hardware and Systems Environment 11.1 Run-time Environment 11.2 Package Software Requirements for Run-time Environment 11.3 Recommended Hardware Environments 11.4 Development Environment
This document defines the overall technical requirements of the UNIverse system by defining the requirements of each of identified components defined in the system architecture (4.1.1). Requirements within this document are taken to the level of 'logical interface definitions' for components. The definitions are then further developed into concrete interfaces within the specifications work packages 4.x.
The following subsections (1.1 - 1.5) define the technical requirements for the components within the 'Logical Union Catalogue' services.
Internally the UNIverse server will work in Unicode; all incoming character sets are mapped into this character set. Before despatching data to UNIverse clients the character set will be 'degraded' as necessary. The character set conversion utility responsible for converting strings between character sets. It has a simple interface that accepts 3 parameters:
The utility returns the string in the required character set.
The character set conversion utility must be capable of converting to and from Unicode. The character sets capable of being converted to and from Unicode should include:
Optional Additions:
AdaptCharacterSet( Incoming String, Incoming String Character Set, Required Character Set )
Parameters:
Incoming String The string to be converted
Incoming String Character Set The character set of the incoming string
(from those supported)
Required Character Set The required character set (from those
supported)
Returns :
Outgoing String The string in the new character set
Error Handling
Errors may occur from invalid conversion requests (e.g. from/to an unknown/unsupported character set). This must not cause a fatal error, the procedure should return the original string unchanged and place a message in the system debug log.
The character set conversion routine by necessity must process every string on a character-by-character basis. Whilst the character manipulation routines are expected to be very fast there is potentially a large overhead due to the frequency this routine will be called, hence the routine must be written for performance. In particular, since the conversion routine must be data driven, the caching of the conversion tables in memory should be considered.
OIDs should be used for character set representation (this allows for specifying position in shifting character sets such as ISO 8022).
The query adaptation facility will be called prior to issuing a query to a remote Z39.50 target. The facility makes use of the profile database to map the user's query onto an 'optimal' query that can be evaluated at each target. The utility has a simple call interface accepting the following parameters:
The query adaptation utility converts the requested query into the nearest query type that the target can evaluate and returns that query to the caller. If the target cannot evaluate any query that is sufficiently close to the requested query then an error condition is returned.
A query adaptation utility must be able to :
The semantic indicator should be respected when re-formulating queries - i.e. if exact semantic match is specified the query should not be re-formulated.
AdaptQuery( Incoming Type 1 Query, Target DatabaseName, Default Behaviour )
Parameters:
Incoming Type 1 Query The incoming query to be converted
Target Database Name The target database name for which the
query should be converted
Default Behaviour Whether or not query adaptation should
take place if no semantic indicators are
set.
Returns :
Returns Type 1 query The new type 1 query.
Functionality
The AdaptQuery function is called by the Z client to change to the query definition into an appropriate query for the target database. It will:
Errors may occur in the query adaptation function through:
Where possible these should not cause fatal errors. All errors must be logged to the system debug file.
In particular unavailability of the profile database and unknown call attributes should result in the original query terms being returned to the caller with an error being placed in the error log.
The query adaptation function is called on a once per database-query basis (i.e. once for every database within a query). This is not expected to have a significant overhead on system throughput.
Should the Universe server return an error condition or should the system rely on the Z39.50 target to respond?
The record syntax conversion utility is responsible for converting all incoming record syntaxes into an internal canonical syntax (see below) and converting from that syntax to the format required by the various client interfaces.
The record syntax conversion utility must be capable of converting to and from the internal (GRS based record syntax). The syntaxes capable of being converted to and from should include:
Optional
ConvertRecordSyntax( Incoming Record, Incoming Record Syntax, Required Record Syntax )
Parameters:
Incoming Record The record to be converted
Incoming Record Syntax The syntax of the record to be converted
(from the supported list)
Required Record Syntax The syntax to be converted into (from the
supported list).
Returns :
Outgoing Record The record in the new syntax
The function may call an internal function that converts to and from the GRS record structure- this can then be called twice to convert between any supported structures.
Errors may occur from invalid conversion requests (e.g. from/to an unknown/unsupported record syntax). This must not cause a fatal error.
The record syntax conversion routine by necessity must process every record as they pass through the server. Record syntax conversion can be a time-consuming process, and whilst being table driven provides a more elegant and generic solution for an on-line service speed is of the essence. For this process within the search and retrieve domain execution speed is a higher priority than genericism or even conversion quality.
The definition of the GRS-1 tag paths used in the internal record syntax must be defined at the specification stage.
This utility will project records together that are recognised as potential duplicates into a 'cluster record'. This can clearly be done to varying levels of precision and may be under user control.
The deduplication and merging process is asynchronous with messaging /'up-calling' to client interfaces. The internal record structure used within the UNIverse server will represent clusters as single GRS records.
Z client sends a new record/set of records to the de-duplication process (note that these will already be converted into internal format in Unicode).
The component attempts to match the new records against its currently held result set and causes either new clusters to be generated (in the case of no match) or updates existing clusters.
The Deduplication process must maintain a map of its view of a result set (and therefore an incoming client's view of the result set) onto the remote target databases' result sets.
Errors may occur in the de-duplication process through:
Where possible these should not cause fatal errors. All errors must be logged to the system debug file.
Of all the aspects of the UNIverse server, the de-duplication process is the one that is most likely to cause performance problems. This has to be taken into consideration in the design to enable fast throughput. Record de-duplication must be achieved in well under 1 second (10 per second would seem reasonable). Asynchronous de-duplication should be evaluated if 'in-line' deduplication proves to be too slow.
The possibility of running the de-duplication operation as a thread or process should be considered. If this is implemented then the ability to run multiple such threads to achieve scalability should be examined.
The interface between the de-duplication process and the Zservers and Zclients must be defined.
The process architecture must be defined - is the de-duplication component a separate process and what is the cardinality of the process?
The mechanism for the Zserver notifying the user client of new records and changed records must be defined.
The notification mechanism must be consistent when 'stacking' is considered.
The de-duplication process must be under user and/or system manager control. A configuration system must be used to specify duplication criteria. This configuration requires:
Example De-duplication Configuration
Data Element Name Data Element type %age Match ISBN Control Number 95 Title String 50 Author String 10 Edition String 10 Publication Date Date 45 ...
The data element name column contains names from the internal record syntax.
The user can then set a threshold value, which once a match has exceeded the record is regarded as a duplicate.
Example Match Algorithm
Zclient New Record Notification
{
Set New Record Likelihood = 100%
For each record in the existing result set or until match found:
{
For each data element in de-duplication profile:
{
If NewRecord Data Element matches Result Set Data Element according to rules specified by Data Element Type then:
{
New Record Likelihood = New Record Likelihood
* (100 - Data Element Match Likelihood)
If New Record Likelihood > Match Threshold then
{
Merge Record and update result set
Notify Zserver of modified record
Finish
}
}
}
}
Add Record to Result Set
Notify Z Server of New Record
Authentication services are provided to the Z39.50(+) server. The authentication service is used for 2 separate, but related activities:
The user profile data includes the list of remote database accounts that each user has access to. If required authentication information can be stored within the profile database to provide automatic responses to challenges from remote targets, otherwise the challenge must be passed through to the client.
The authentication service must be callable from the Z39.50 server to establish user credentials to use UNIverse.
Z39.50 clients will call the authentication service when remote servers challenge them. The authentication service must be capable of (optionally) storing user id / password mapping for UNIverse users onto remote database accounts.
If the UNIverse server is not capable of resolving the authentication challenge the challenge must be passed on to the Z39.50(+) server and then onto the UI.
User profile information must include:
Certification services are out of scope for UNIverse.
AuthenticateUser( Identity, Authentication )
Parameters:
Identity The user identity
Authentication information Authentication information for the user
(e.g. a password)
Returns :
Returns Userid or Exception
Functionality
Called by Z39.50(+) server when a client connects to the UNIverse server. Checks the passed User Id and authentication information against the local user profile database to establish the user's credentials to access the UNIverse server.
GetAuthentication( Userid, Target Database )
Parameters:
Userid The user identity
Target Database The name of the target database the user
is trying to connect to
Returns:
Identity & Authentication The user id and authentication Or information to be used for the target Exception database or a failure condition.
Functionality
Called by Z39.50 client process to obtain authentication information for a target database for a particular user name. The function will try to obtain userid and authentication information from the local profile database, if it fails it will instruct the Z39.50(+) server to issue an authentication challenge to the user.
GetAvailableServices( userid )
Parameters:
Userid The user identity
Returns:
Available Services List of accessible target databases held
in some structure that carries their
relationship (e.g. Target - database
tree). Also the services that are
available to the user at that database
(e.g. direct requesting or not).
Functionality
Called by Z39.50(+) server in response to user request to list databases.
Authentication errors are most likely to be caused by the lack of availability of the profile database. In this case the user must not be authenticated and a user-friendly error message must be produced. The error must also be logged to the system error file.
This is not expected to be problematic.
Distribute authentication services are considered out of scope for the UNIverse project.
How is the mediation/authorisation level of the user passed to the client?
The profile database holds data required to describe the addresses and capabilities of remote targets. The data schema holds the 'explain database' and can be populated either manually or on-line. The database profile services provide an explain interface to the Z39.50(+) server.
The Z39.50(+) server transparently provides explain information to the client :
Database Local Remote
Explain Database
Local Local database, local Manually maintained local explain
explain database. The database is presented to the
Z39.50(+) server client when the remote target is
interfaces with the 'explained'.
local explain
database.
Remote The client's explain request is
cascaded on-line to an explain if
the target database. (note that
addressing information at least
must be held in the local profile
database).
The database profile services are required to:
DescribeTarget( TargetName )
Parameters:
Target Name The target /target database to be
described
Returns :
Available Services Description of database / target
Functionality
DescribeTarget will fetch details from the local database. This will return the available profile information and also whether the target name can self-describe. If the target can self-describe the function will start a Z-client session and issue an explain request to the target.
AdaptQueryAttribute( Use Attribute, StructureAttribute, DatabaseTargetName )
Parameters:
Use Attribute The use attribute to be adapted
Structure Attribute The structure attribute to be adapted
Target Name The target /target database to adapt the
query to
Returns :
Adapted Query Attribute Combination The use + structure attribute to be
applied by the client
Functionality
This is called by the Query Adaptation component to adapt individual attribute combinations. Adaptations are performed by looking up in a 5-column database table:
Target Incoming Use Incoming Outgoing Use Outgoing Structure
/Database Name Attribute Structure Attribute Attribute
Attribute
LOC-Books Title Word List Title Phrase
Column Definition
Target /Database Name The target or target database name for which the
conversion applies.
Incoming Use Attribute The use attribute to be changed.
Incoming Structure The structure attribute to be changed.
Attribute
Outgoing Use Attribute The replacement use attribute.
Outgoing Structure The replacement structure attribute.
Attribute
The query adaptation function then is passed a triplet consisting of target/database name, incoming use attribute and incoming structure attributes. If it finds this combination in a row of the above table it returns the corresponding outgoing use attribute and outgoing structure attribute.
ListQueryAttribute( Collection of Target Database Names )
Parameters:
Collection of Target Database The list of target databases which are to be Names queried
Returns :
Collection of attribute The list of attribute combinations supported by combinations all databases.
Functionality
This may be called by the client prior to configuring its user interface for entering queries for the selected databases.
Errors may occur in the query adaptation function through:
Where possible these should not cause fatal errors. All errors must be logged to the system debug file.
In particular unavailability of the profile database and unknown call attributes should result in null lists being returned and an error being written to the log file.
This is not expected to have major performance implications.
For scalability of this service, generating full explain requests and caching explain data through use of a 'crawler' or 'gatherer' should be examined.
This should be provided through an explain database proxy. These functions then must be mapped onto the Explain services.
The multi-lingual thesaurus services provides the search and scan facilities on the thesaurus data. Searches can be performed on local and remote thesauri.
The UNIverse Multi-lingual Thesaurus Services must be able to:
The Thesaurus Service uses a Thesaurus Database. The UNIverse Thesaurus Database has:
The translating service is provided through the UNIverse Thesaurus. In a single thesaurus, one or more terms must be connected with the UNIverse Thesaurus. If a translation can not be obtained directly (the term is not included in the UNIverse Thesaurus), the relations of the term within the thesaurus and their connection to the UNIverse Thesaurus can be used to approximate a translation. The user is informed of the way a translation was obtained and gets an indication of the matching of the translation with the search term.
FindTerm( IncomingTerm )
Searches all the thesauri on the local UNIverse server to find an entrance to a thesaurus.
Parameters:
IncomingTerm The term to search for
Returns:
List of matching terms in local Only the local thesauri are searched.
thesauri Resulting terms are displayed with their
definition and the thesaurus they are
found in.
ExpandTerm( IncomingTerm )
Parameters:
IncomingTerm The term to expand
Returns:
List of related Thesaurus Terms Only the current thesaurus is searched.
Resulting terms are displayed with their
relation to the IncomingTerm
TranslateTerm( IncomingTerm, RequestedLanguages )
Parameters:
IncomingTerm The term to translate
RequestedLanguages Optional. The UNIverse Thesaurus is used
to find terms in the requested languages
in other thesauri. The Thesaurus Database
is used to select other UNIverse servers.
Returns:
List of translated Thesaurus Terms Each term is given with the thesaurus it
is found in and an indication of the
match between the IncomingTerm and the
TranslatedTerm
Functionality
The user enters a subject. FindTerm will search local thesauri for the subject. If the subject is found to be a term in one or more of the thesauri the user has the option to refine the search by using a thesaurus. If the term is not found the subject is used in the search.
The user can search further through the thesaurus with ExpandTerm or with TranslateTerm.
The search in the thesaurus continues until the user selects a term to be used in a query.
Errors may occur in the thesaurus function through:
Where possible these should not cause fatal errors. All errors must be logged to the system debug file.
The performance aspects of the thesaurus will be mainly governed by the database access speed.
Whilst not specifically part of the UNIverse project it is envisaged that the distribution architecture for catalogue searching through Z39.50 will also apply to thesaurus searching. This should allow enormous scalability of the thesaurus facility.
The local search, catalogue and object store enables the UNIverse server to operate as a database target within the UNIverse network. This can be used in 2 ways:
This is a local issue for the catalogue database. Diagnostic messages sent to the UNIverse server are governed by the Z39.50 standard.
The key component of the UNIverse server is the Z39.50(+) server. Its role is to transparently resolve service requests locally or using access to parallel Z39.50 client sessions. The Z39.50(+) server is the controlling process within a UNIverse transaction.
The error conditions reported by the Z39.50 server should follow the definitions specified in the Z39.50 standard.
The Z39.50 server is not seen as a major performance bottleneck.
A major scalability feature is achieved by the stability of Z39.50 server stacking.
The following diagram shows the overall flow of control through the UNIverse server (this is greatly expanded in D4.1.1 - system architecture deliverable).
The basic phases & states of the transaction are:
It should be noted that with this state model a UNIverse server will not look like a standard database target (it will issue 'spurious' resource control reports). However a standard Z39.50 client should be able to inter-operate with it.
An essential requirement for this model however is that a clients view of a UNIverse server talking to a UNIverse server is identical to a UNIverse server talking to a standard target (i.e. a 2 tier interaction is identical to a 3 tire interaction). Achieving this will ensure that indefinite UNIverse stacking will work at the level of the state model (proof by induction!).
Responsible for providing access to remote database targets. Specific services include:
The Z39.50 client component must deal appropriately with all the diagnostic messages specified within the Z39.50 standard.
This is not seen as a bottleneck for system performance.
The ILL and Document Requesting components of the UNIverse server are responsible for managing the document delivery process from initial request to completion of the transaction.
There are a number of different cases that this must cater for:
Processing Requests ( Requester and Responder)
Incoming messages (either requests from remote systems or responses to requests from this system) are logged to the transaction store. If these can be processed automatically (e.g. request for an electronic item that is held and can be shipped over the network) then a response message is automatically sent, the request status updated and the request processed. If manual processing is required then the ILL clerk manually updates the status, this causes the appropriate response message to be sent to the requester/responder.
The user interface that manages the transaction store must respect the state model embodied in the ISO ILL protocol:
Because of the possible protracted nature of an ILL / Document Delivery request many possible error conditions exist:
The system must log all errors and allow the user to track and recover from error conditions wherever possible.
A local watchdog process must check on request driver process activity and restart the process if necessary.
The system must automatically attempt retries if a remote server is unavailable for a temporary reason.
The request drivers run asynchronously, performance is not seen as a major issue.
The document delivery component of the UNIverse server manages the electronic transmission and reception of documents. This involves two distinct operations:
Note that within the UNIverse system all document deliveries will pass through the UNIverse server for auditing and tracking purposes.
As the diagram above depicts the delivery manager can be regarded as two logically distinct components:
The document delivery process suffers from the same error conditions as the ILL messaging system. These include:
The system must log all errors and allow the user to track and recover from error conditions wherever possible.
A local watchdog process must check on request driver process activity and restart the process if necessary.
The system must automatically attempt retries if a remote server is unavailable for a temporary reason.
Performance is not seen as a major issue for the Document Delivery sub-system.
The record download service is available from the administrative clients to allow staff users to download records for their local catalogue.
Errors could be caused by the caller asking for unsupported or unknown record syntaxes. Where possible these should not cause fatal errors. All errors must be logged to the system debug file.
The record download facility is not seen as a major performance bottleneck.
Scope
The WWW user interface provides end-user access to the UNIverse system. An overall interface flow is shown in the above diagram.
The user interface of the WWW access point to UNIverse will be mostly defined by the WWW gateway. The WWW client itself may have to be taken in consideration, while defining this interface, mainly to insure the consistency of the proposed interface across clients and platforms. The user interface will be based on HTML with additions in Java and/or JavaScripts to cover interface components and functionality outside the scope of HTML.
The gateway to the UNIverse server has to provide the web browser access to all the end-user services including:
The WWW gateway to the Z39.50+ UNIverse server has to provide the user of the web browser access to the authentication service. The server will use the standard z39.50 Id/authentication parameter of the Init service. In this case the gateway has to pass the identity and the authentication information (password) of the user to the server, which will determine whether the user is authorised to enter into communication with it and to establish a Z39.50 association.
The web user interface will use the standard HTML forms and/or Java, requesting the users to enter their Id/password to be passed to the gateway and forwarded to the server. The interface has to give a possibility to the user to choose his own password if the UNIverse server will support this.
There are different ways to provide the database selection service by the user interface based on HTML forms and Java. One is through using the explain service of the Z39.50 standard to provide a list of the available databases. The user has to be provided with all local and remote databases he has access to. The user has to have the possibility to choose one or more of the available databases by using the HTML form select tags or checkboxes and radio buttons as well. A hierarchical list of databases, classified by subject, may be required to ease database selection. The databases selected by the user have to be passed to the server through the gateway.
The Multi-lingual thesaurus searching is not a functionality of the WWW gateway as such. However, the gateway will be designed to allow smooth integration with existing thesaurus browsing facilities. One such service will be integrated within the UNIverse project but the WWW gateway will not be only geared to this service. Integration of the service will be done either through HTTP redirections between the WWW gateway and an HTTP aware thesaurus searching service or through the Z39.50 search service.
Once again, the database searching interface will be mostly based on HTML forms and Java. Multiple forms will reflect the end user levels of expertise. A simple search form will only accept simple keywords while a more advanced form will allow Boolean expressions, field selection, truncation, etc. These forms may also include parameters related to display format.
The document requesting will based on services offered by the UNIverse server, which in turn reflect services available on the database servers. Depending on the service used (e.g. On-line delivery, ILL) the end user will be presented with a specific form, requesting information required by this service.
Request progress monitoring will only be required for off-line document delivery (e.g. ILL). The role of the gateway will be simply to use the monitoring facilities of ILL. The gateway will not directly use ILL be will have to map to the services reflected by the UNIverse server interface.
The user interface must reflect all underlying error conditions in a user-friendly manner. The error log should be used for detailed error tracking.
The primary role of the UNIverse client is to provide access to administrative services, although it will also provide a windows-based end-user access point.
The requirements in terms of end-user services are identical to the WWW interface. The requirements for administration include:
The UNIverse client should provide an interface on to the system error log to allow tracking of error conditions.
The UNIverse server will be a complex computing environment consisting of a number of co-operating processes. In order to achieve robustness of the server environment it is essential that system management routines are available to check the status of the UNIverse processes and to provide simple routines for start-up and graceful shutdown.
The requirements for the process monitor include:
The process monitor is a major defence against fatal system errors. For example if one of the system processes dies or hangs, the process monitor should force a re-start of the process. Processes that include message queues (e.g. the ILL request drivers and document delivery drivers) should then pick-up from the point of failure.
The most serious fault condition would be therefore be a simultaneous failure of the process manager and another system process (since then the system process would not then be automatically re-started). In fact a failed process manager leaves the UNIverse server in a potentially very dangerous situation - the next process failure will be fatal.
The process manager must be written for robustness - its continuous execution must be guaranteed.
A generic error logging routine is available to all system components. This provides a standard interface to be called when an error condition is encountered. The error logging sub-system logs errors to a debug file and may cause an operator alert.
UniverseLog( Process, ErrorType, ErrorCode, … )
Logs an error condition to the error file.
Parameters:
Process The name of the process generating the
log.
ErrorType The type/severity of the error.
ErrorCode The code for the error - this provides a
lookup to an error file for descriptions.
Component Name Interface Style
Character Set Conversion C API (called from de-duplication
process)
Query Adaptation C API (called from Z client)
Record Syntax Conversion C API (called from de-duplication
process)
De-duplication & Merge Separate process - Sockets i/f
Authentication & User Profiles C API (upwards)
SQL access to local database
Profile Database C API (upwards)
SQL access to local database.
Multi-lingual Thesaurus Services & C API (upwards)
Thesaurus Storage SQL access to local database.
Z39.50(+) server BER / ASN.1 (upwards)
C API (downwards)
Z39.50 Client C API (upwards)
BER / ASN.1 (downwards)
Request Drivers C API
Transaction Store C API
System Administration SQL
Process Monitor Separate Process - Sockets Interface
SNMP?
Component Requirements
UNIverse Server Solaris or NT4
UNIverse Client NT4 or Windows 95 (NT only for Unicode
support).
WWW Browser Any Java Enabled
MS Internet Explorer 3 (+)
Netscape Navigator 3 (+)
Other Z39.50 Clients Any version 3 clients.
Component Requirements
UNIverse Server Oracle Database Version 7.3.x
(This will be shipped with the UNIverse
server).
Component Requirements
UNIverse Server Running Solaris SPARC 5 / SPARC 20
Disk : Dependant on data volumes : ~4Gb
Universe Server Running NT Minimum : Pentium with 32Mb RAM
Recommended : Pentium with 64Mb RAM
Disk : Dependant on data volumes : ~4Gb
Universe Client Running NT Pentium with 32Mb RAM
Universe Client Running Windows 95 Pentium with 16Mb RAM
Combined Universe Server and Client Minimum : Pentium with 32Mb RAM
on Windows NT Recommended : Pentium with 64Mb RAM
Disk : Dependant on data volumes : ~4Gb
Component Requirements Server C Compiler gcc Client C Compiler Microsoft Visual C++ V5 Server Platform Solaris Client Platform Windows NT 4.0 Server version control system Cvs Client version control system SourceSafe