sql92 Ica

Progress SQL92 Server: Installation,
Environment and Administration
Sébastien Haefelé, Product Manager,

the Progress Company
Progress SQL92 Server: Installation, Environment, and Administration
Contents
1. Introduction ............................................................................................................................................................ 3
2. The Progress SQL92 Server Architecture............................................................................................................ 4
2.1. SQL92 Architecture Overview.................................................................................................................. 4
2.2. Progress General Client/Server Architecture ........................................................................................... 5
2.3. SQL92 Server Internal Architecture ......................................................................................................... 6
2.3.1. Example 1: Selecting information from an SQL92 client............................................ 7
2.3.2. Example 2: Inserting new rows with a before insert trigger defined .......................... 8
2.3.3. Example 3: Creating a stored procedure ................................................................... 9
3. The SQL92 Server Installation ............................................................................................................................ 10
3.1. Availability Per Operating Systems........................................................................................................ 10
3.2. Operating System Prerequisites ............................................................................................................ 11
3.2.1. Operating System Patches ...................................................................................... 11
3.2.2. JDK........................................................................................................................... 11
3.3. License Requirements ........................................................................................................................... 13
3.4. Installation Process................................................................................................................................ 14
3.4.1. Local installation....................................................................................................... 14
3.4.2. NetSetup configuration............................................................................................. 16
4. The SQL92 Server Environment ......................................................................................................................... 17
4.1. Under UNIX ........................................................................................................................................... 18
4.1.1. Operating System Environment Variables ............................................................... 18
Compaq Tru64: .............................................................................................................................. 20
HP-UX: ............................................................................................................................................ 21
IBM AIX:.......................................................................................................................................... 22
Linux:.............................................................................................................................................. 22
SCO UnixWare: .............................................................................................................................. 23
Sun Solaris Sparc:......................................................................................................................... 24
4.1.2. What Progress Provides........................................................................................... 25
4.2. Under Microsoft Windows or Citrix......................................................................................................... 31
4.2.1. Operating System Environment Variables ............................................................... 31
4.2.2. What Progress Provides........................................................................................... 33
4.3. Moving the JDK into Another Directory .................................................................................................. 37
4.3.1. Under UNIX .............................................................................................................. 38
4.3.2. Under Windows ........................................................................................................ 38
5. SQL92 Server Administration ............................................................................................................................. 39
5.1. Starting and Stopping the SQL92 Server............................................................................................... 39
5.1.1. Using the Progress Explorer and the Admin Service............................................... 39
5.1.2. Using the Command-line Interface to the Admin Service ........................................ 41
5.1.3. Using the Progress proserve Script ......................................................................... 45
5.1.4. Using the _mprosrv Executable in a Custom Script................................................. 46
5.2. Best Practices: Some Guidelines........................................................................................................... 46
5.2.1. Server Startup Parameters....................................................................................... 46
5.2.2. Guidelines for Administrating Your Database Servers............................................. 47
A Appendix ............................................................................................................................................................... 49
A.1 Progress Licenses That Install the Progress Explorer and Administration Server ................. 49
A.2 Manually Modifying the conmgr.properties File ...................................................................... 51
A.3 Table of Equivalence between Progress Explorer Entries, conmgr.properties Entries
and proserve Command-line Parameters ....................................................................................... 55
2
1. Introduction
This white paper is mainly targeted towards a technical audience that has little to medium understanding of the
Progress SQL92 server. It can also be used as a reference or summary document for technical readers that have a
medium to good understanding of the Progress SQL92 server.
The goal of this document is to:

• Describe the most common tasks that should be performed when installing, configuring, and
administrating the Progress SQL92 server in order to avoid the most common pitfalls.
• Help avoid the most common issues a user may face while performing one of the tasks mentioned above
and highlights the current limits with the Progress SQL92 server. Some of those issues are due to the
absence of a JDK that may be required by the Progress SQL92 server in order to compile and execute
SQL92 triggers or stored procedures, or resource problems when connecting the database that could be
caused by the maximum number of connections allowed to a database, for instance.
Installing, configuring, and administrating the Progress SQL92 server can be daunting to anyone who does not
understand the Progress architecture, especially if a working configuration needs to be set up in a minimum
amount of time.
For this reason, this document starts by providing a general description of the Progress SQL92 server architecture,
followed by technical information concerning installation / deployment, configuration and database administration
of the Progress SQL92 server for Progress Version 9.1 on all the operating systems where this server is available.
As a result, this white paper is organized in the following way, where each section has subsections related to the
operating system on which the specific task needs to be performed:
• “The Progress SQL92 Server Architecture” section covers the server architecture starting by an overview
describing how it fits in the ‘Big Picture’ and is followed by a simplified description of the internal
processing performed by the SQL92 server. In other words, this is theory and really serves as an
introduction or reference point to the following 3 sections.
• “The SQL92 Server Installation” section covers mainly the availability per operating system, the license
requirements, the Java requirements and the operating systems pre-requisites that have to be in place
before performing the installation itself. After this, it is followed by a short description of the installation
process and SQL92 and issues you could have during this process.
• “The SQL92 Server Configuration” section covers mainly the different ways to configure the Progress
SQL92 server through the different tools that are available with Progress 9.1 and the environment
requirements depending on the different functionality you need to use with the SQL92 server.
3
• “The SQL92 Server Administration” section provides a complete list of the server startup parameters
that can be used in specific configurations and some guidelines to facilitate the database administration
task with the different tools available. It also describes database maintenance tasks (Dump / Load) and
performance management (in terms of database server parameters only). In other words, this section
could also be considered as an introduction to advanced database administration for Progress SQL92.
However, the goal of this document is not to discuss database design and maintenance issues in terms of table
structure, constraints etc. or interoperation with the Progress 4GL server or application. Nor does it discuss
security management for SQL92 or other database administration tasks that could be performed on the database
itself (such as updating the data used by the SQL92 cost-based optimizer – UPDATE STATISTICS).
By reading this document you should gain a clearer understanding of the Progress server architecture in general
and more specifically the SQL92 server architecture with a brief summary of its internals. You should gain
enough understanding of the SQL92 server environment and its requirements during installation and configuration
depending on the functionalities you need to use. Ultimately you should gain full control over the server
environment so that you can perform maintenance tasks in the most efficient manner, such as modifying the server
environment in order to update some elements such as the JDK. You should also gain the ability to configure your
SQL92 server in the most efficient way to avoid networking resource issues.
2. The Progress SQL92 Server Architecture
This section covers the Progress SQL92 server architecture starting with an overview describing how it fits in the
‘Big Picture’ with some background information to understand the architectural choice.
It then describes in more detail the Progress client/server architecture involving 4GL and SQL92 clients to
establish a common framework for best describing the practical issues presented in Section 5 of this document.
A general description of the internal processing performed by the SQL92 server in relation with requests received
from SQL92 clients is also part of this white paper. This mainly helps in understanding what the SQL92 server is
doing in different cases.
In other words, this section is mainly theory and really serves as an introduction or reference point to the
following three sections, which discuss how to install, configure, and administrate the Progress SQL92 server.
2.1. SQL92 Architecture Overview
In 1997, Progress took the decision to develop a new set of products, the SQL92 products which were
distinct from the Progress 4GL world and its SQL89 interface. The new SQL92 components have been
available since Version 9.1A. It is still at the beginning of its development path and future releases will see it
grow and evolve in different areas.
In the early planning phases for the SQL92 server, Progress Software conducted market studies and
researched software requirements for deployed applications. Progress decided to implement the SQL92
interface in a client/server configuration only as most of the SQL applications in use today are in effect
composed of:
• An SQL database server
• A client application accessing the database through different interfaces
4
Further conclusions of market study led to supporting interfaces to the Progress RDBMS through SQL92
along the following connection paths:
• Through a JDBC Driver
• Through an ODBC Driver
• Through an ESQL/C Interface
As a result of these choices, the Progress SQL92 server can only be accessed and used in client/server from
one of the above 3 interfaces. There is no shared-memory connection or no single-user access to a
Progress SQL92 database. This results in the architecture shown in Figure 1 below where “N” stands for
“Network.”
Figure 1: Progress SQL92: Architecture Overview
2.2. Progress General Client/Server Architecture
Since every SQL92 connection is a client/server connection, it is required to detail how the SQL92
client/server architecture integrates with the 4GL client/server architecture.
In Figure 2 below, you have a quite detailed snapshot of the architecture when 4GL and SQL92 clients are
connected to the database in a client/server configuration.
As you can notice in the Figure 2:
• The Progress database broker is common to the SQL92 server and 4GL servers. It can start both
processes depending which type of client connects the database.
• The SQL92 server integrates perfectly with Progress background process and the Admin Service
through which it can be started.
• The SQL92 database server processes always perform database operation through the shared
memory attached to the database. This shared memory is in fact common to all processes running
against a specific Progress database.
5
• The SQL92 database servers are only accessible from SQL92 clients. The connection is always
established through the network layer from the SQL92 clients.
• Each Progress SQL92 server handles a single SQL92 client. The SQL92 server process is not
designed to handle more then one client at the same time. This can lead to severe resource issues on a
machine handling either 4GL and SQL92 connections or a high number of concurrent SQL92 clients.
• An SQL92 server cannot access and query several databases at the same time. This means that the
SQL92 server is attached to only one physical database. This also highlights the fact that SQL requests
over several databases need to be handle by the client. If there are joins to be made between 2 tables in 2
different databases, the join operation needs to be performed by and within the client application itself.
(The same rule is applicable to the Progress 4GL.)
Figure 2: Progress Client/Server Architecture Overview
Note: the “multiple” volumes, on the right side of Figure 2, symbolize the fact that the database is multi-
volume with Progress V9. They do not symbolize multiple databases connections.
2.3. SQL92 Server Internal Architecture
To go a bit deeper into the subject of this white paper, let’s have a closer look at the SQL92 server and the
tasks it is performing when answering SQL92 client requests.
Generally speaking, the SQL92 server is composed of 3 elements:
• The database storage manager, which is common with the 4GL server and handles all requests on the
database, shared memory and other resources such as BI and AI notes. This white paper does not go into
more detail on the storage manager as it is not central to understanding the SQL92-specific database
management processing performed from the SQL92 server.
• The SQL92 server itself, which performs several actions handled by different subcomponents. Figure 3
below gives a basic idea of the SQL92 server structure.
• The Java layer interface and the Java Virtual Machine (JVM), which is in charge of executing stored
procedures and database triggers. Figure 3 below includes the Java interface as it is specific to the
6
SQL92 server. However, Figure 3 leaves out the JVM because it plays no role in the SQL92-specific
database management processing performed from the SQL92 server.
Figure 3: Progress SQL92 Server Internal Architecture
To understand what the SQL92 server is doing we will walk through 3 examples. This will at the same time
help define the role of each SQL92 server component (also called Manager).
2.3.1. Example 1: Selecting information from an SQL92 client
• A ‘select’ request comes via the network.
• The Communication Manager receives this request.
• The Communication Manager checks if there is a need for a transaction. If yes (based on the
transaction isolation level – for more information on this subject please check any good SQL manual) it
starts one transaction through the Local Transaction Manager. If not, it goes to the next step.
• The Communication Manager passes the request to the Statement Manager.
• The Statement Manager requests to get it parsed against the database to verify the syntax for all objects
names referenced in the statement (such as tables, views, synonyms, columns and stored procedures)
defined in the database. (You would get syntax error messages if this step fails.) Parsing is done with the
information retrieved by the Schema Manager.
• If the statement contains views, the definition of each view used is retrieved and integrated in the original
SQL statement. This means that the View Manager will replace each occurrence of a view name by the
corresponding select statement defining this view in the original select statement.
• The Statement Manager asks the Authorization Manager to verify that the user issuing the request has
sufficient privileges to really access the data requested. (You would get insufficient privileges error
messages if this step fails.)
7
• The Statement Manager asks for an optimized query before processing it. The Optimizer’s goal is to
execute the query against the database in the most efficient way. The end result of this operation is an
SQL statement defining the order in which the table will be accessed and with which “WHERE”
condition and indexes each tables will be accessed.
• The Statement Manager passes the optimized SQL select statement to the Execution Manager for
processing against the database.
• The Statement Manager receives the result set and passes this information to the Communication
Manager.
• The Communication Manager formats the result set to send it to the SQL92 client.
2.3.2. Example 2: Inserting new rows with a before insert trigger

defined
• An ‘insert’ request comes via the network.
• The Communication Manager checks if there is an active transaction and if not will start one
transaction through the Local Transaction Manager when allowed by the transaction isolation level in
use (Read uncommitted does not allow to start transactions on the database – for more information on
this subject please check any good SQL manual). If it cannot start a transaction due to the transaction
isolation level, an error message is returned; otherwise it goes to the next step.
• The Statement Manager requests to get it parsed against the database to verify the syntax for all object
names referenced in the statement (such as tables, views, synonyms, columns and stored procedures)
defined in the database. (You would get syntax error messages if this step fails.) Parsing is done with the
information retrieved by the Schema Manager.
• If the statement contains views, the definition of each view used is retrieved and integrated in the original
SQL statement. This means that the View Manager will replace each occurrence of a view name by the
corresponding select statement defining this view in the original select statement.
sufficient privileges to really access the data requested. (You would get insufficient privileges error
• Since there is a “before insert” trigger, the Statement Manager will call the JVM and ask to process the
trigger.
• The JVM processes the before insert trigger and discusses subsequent database accesses with the Stored
Procedure Manager.
• Assuming there are other SQL requests in the before insert trigger, during this operation any additional
SQL requests (coming from the trigger code) are processed on the database and handled by the Stored
Procedure Manager. The Stored Procedure Manager passes the SQL requests defined in the trigger
code to the Statement Manager.
• The Statement Manager will consider those “trigger” requests as new requests received from the same
user and follow again the same steps for each of them.
8
• Once the trigger is processed, the Statement Manager passes the insert statement to the Execution
Manager and retrieves errors or successful completion messages. (Row locking issues are error
messages.)
• The Statement Manager passes the previous message to the Communication Manager.
• The Communication Manager formats it and sends it to the SQL92 client.
2.3.3. Example 3: Creating a stored procedure
• A ‘create stored procedure’ request comes via the network.
• The Communication Manager checks if there is an active transaction and if not will start one
transaction through the Local Transaction Manager when allowed by the transaction isolation level in
use. (Read uncommitted does not allow to start transactions on the database – for more information on
this subject please check any good SQL manual.) If it cannot start a transaction due to the transaction
isolation level, an error message is returned; otherwise it goes to the next step.
sufficient privileges to really perform the insert statement. (You would get insufficient privileges error
• The Statement Manager will pass the Request to the Stored Procedure Manager.
• The Stored Procedure Manager generates a Java file out of the code received from the request itself.
• The Stored Procedure Manager passes the file to the Java Compiler.
• The Java Compiler executes its tasks but establishes no connections to the database. This means that
SQL statements against the database are not parsed to verify their syntax.
• Once the Java class is generated, the Stored Procedure Manager retrieves the file and passes it back to
the Statement Manager.
• The Statement Manager passes the Java class and the original statement to the Execution Manager so
that the stored procedure is made available in the database
• The Execution Manager returns errors or successful completion messages to the Statement Manager.
• The Statement Manager passes the previous message to the Communication Manager.
• The Communication Manager formats it and sends it to the SQL92 client.
Note: This is only an overview of what the SQL92 server does internally as the overall processing is in fact
more complex.
9
3. The SQL92 Server Installation

After defining the architecture implemented with the SQL92 server and reviewing some of its internal
mechanism, we have now a common understanding of the way the SQL92 server is working. Based on this
information, we can review its requirements while performing different tasks, such as installation (this
section), configuration, and administration (next sections).
Before actually performing the installation of the Progress SQL92 server, we will review the product
availability per operating system. We will also cover in this section the operating system pre-requisite before
performing the installation (including the JDK requirements). This is followed by a list of Progress product
licenses that include and will install the SQL92 server. The last section covers the installation process itself
with a list of points to check before and after the installation.
3.1. Availability per Operating Systems
The Progress SQL92 server is not available on all operating systems supported by Progress products. The
following table mentions the earliest version of the SQL92 server for each operating system where a
Progress product can be installed.
Table 1: First availability of the SQL92 server per operating system
Operating System First Progress Version with the SQL92 Server
Citrix MetaFrame 9.1a
Compaq® Tru64 9.1a
DG/UX Intel Not Available
HP-UX® 11 (Prgs 32-bit) 9.1a
HP-UX® 11 (Prgs 64-bit) 9.1b
IBM AIX® 9.1a
Linux Intel 9.1b
SCO OpenServer Not Available
SCO UnixWare® 9.1b
Sun® Solaris™ Intel Not Available
Sun® Solaris™ Sparc 9.1a
Microsoft Windows® 32 Intel 9.1a
Notes:
• Versions that are older than the ones listed do not contain the Progress SQL92 server. For instance, 9.1a
on SCO UnixWare.
10
• In 9.0a or b, the SQL92 server was either a beta product or an SDK (Software Development Kit) product
and is not supported in production/deployment. For this reason, these versions are not referenced in this
table.
• For more information on the specific operating system versions supported please contact your Progress
sales representative or Progress Technical Support, or check the latest Product Availability Guide
available at www.Progress.com/products/pavail.pdf.
3.2. Operating System Prerequisites
Before performing the installation itself, it is wise to check if the machine and operating system can support
a fully functional Progress version. In this section we will cover the operating system patches and JDK that
may be required to have a fully functional Progress SQL92 server.
3.2.1. Operating System Patches
Operating system patches may be required with specific configurations, for example:
• OS patch MUP-2 needs to be installed for AIX 4.3.2.
• Sun Sparc 2.6 requires operating system patch #105591-07 before installing Progress.
To have a complete list of required patches on a specific Operating System, check in this order:
• The installation documentation for your operating system
• The hard-copy Progress Release Notes
• The Progress README file (under $DLC or %DLC%)
• The Progress Knowledge Base (www.Progress.com/support) where you would find, for instance, the
following entries:
o KB-19574: SQL-92 AIX Patch information 9.1A
o KB-19635: Patch Requirements for V9.1A on AIX, Solaris
Note: In general, the keywords to use when looking for operating system patches are the operating
system name and “patch” (for instance, Solaris patch)
3.2.2. JDK
With 9.1a and following releases, having the JDK installed prior to a Progress installation is a requirement.
Progress made it a requirement to prevent future issues due to the absence of a valid JDK version installed on the
machine with the Progress SQL92 server. If no valid JDK is detected while installing the different products you
have purchased and Progress does not install a JDK on the machine where the installation takes place, Progress
will simply prevent the installation of any licenses containing the SQL92 server. This ensures that the SQL92
server is fully functional and can support stored procedures and database triggers even if they are not immediately
required.
The SQL92 server will require a JDK only when it processes requests from an SQL92 client application that are
accessing stored procedures or database triggers. As described in the previous chapter (section: SQL92 server
Internal Architecture) those objects are server-side objects and the language supporting them is Java.
11
Changing the JDK version after installing Progress is possible but requires a good understanding of the Progress
configuration files that we will provide in one of the following sections. As a result it is simpler to install the
correct JDK version before installing Progress.
The following table provides information on the JDK required prior to a Progress install. This information is listed
per Progress version. In fact compatibility tests with the different JDK versions are done for each new Progress
versions. These tests are intended to find the most recent and most stable JDK version that works with all
products. As a result, the required JDK to install can be different for each Progress version and operating system.
They can also differ by version or provider. The table below additionally provides the information required to find
the correct JDK from the correct provider, based on the operating system and the Progress version.
Table 2: JDK Requirement for each Progress version per operating system
Operating System 9.1a 9.1b 9.1c
(1) (1) (1)

Citrix MetaFrame 1.1.8 * 1.1.8 * 1.3.0 *
(2) (2) (2)

Compaq® Tru64 1.1.7 1.1.7 1.3.0
DG/UX Intel Not Available Not Available Not Available
(3) (3) (3)

HP-UX® 11 (Prgs 32-bits) 1.1.7 1.1.7 1.3.0
(3) (3) (3)

HP-UX® 11 (Prgs 64-bits) 1.1.7 1.1.7 1.3.0
(4) (4) (4)

IBM AIX® 1.1.6 1.1.6 1.3.0
(4) (1)
Linux Intel Not Available** 1.1.8 1.3.0
(5) (5) (5)

SCO OpenServer 1.1.3 1.1.3 1.2.2
(5) (5) (5)

SCO UnixWare® 1.1.7 1.1.7 1.2.2
(1) (1) (1)

Sun® Solaris™ Intel 1.1.7 * 1.1.7 * 1.3.0 *
(1) (1) (1)

Sun® Solaris™ Sparc 1.1.7 * 1.1.7 * 1.3.0 *
(1) (1) (1)

Microsoft Windows® 32 Intel 1.1.8 * 1.1.8 * 1.3.0 *
Notes:
(1)
: Provided by Sun (http://java.sun.com/)
(2)
: Provided by Compaq (http://www.compaq.com/)
(3)
: Provided by Hewlett-Packard (http://www.hp.com/)
(4)
: Provided by IBM (http://www.ibm.com/)
(5)
: Provided by SCO (http://www.sco.com/java)
*: Progress may automatically install the JDK, depending on the licenses installed (see the following
section, “License requirements”).
**: Progress Version 9.1A SQL92 Server was not a commercial release under Linux Intel.
12
3.3. License Requirements
This section deals only with license requirements for installing the Progress SQL92 server on a specific
machine. As there is no specific SQL92 server license in 9.1a, b, c etc., the following table lists the Progress
licenses that offer the possibility to install the SQL92 server.
To install the SQL92 server with at least one of the licenses mentioned below, you need to execute the
install procedure required for any Progress product. However, the Progress SQL92 server is not installed by
default. You need to request its installation specifically by performing a complete installation.
Additionally, the table below gives extra information about the JDK. This additional information clarifies
which Progress licenses containing the SQL92 server may also install the required JDK. This same
information needs to be cross-referenced with the table from the previous section, “JDK Requirement for
each Progress version per operating system” because Progress installs a JDK only on some specific
operating systems.
Progress will only perform the installation of one of the following licenses if any of the following condition
is met:
• The required JDK is already installed on the machine and is detected through the PATH environment
variable
• Progress also installs the JDK during its own installation
This explains why on most UNIX operating systems (On every operating system where Progress does not
install the JDK), it is mandatory to download the required JDK from the vendor we have certified our
product with and install it manually prior to the Progress installation.
As a reminder, Progress SQL92 requires a JDK local to the SQL92 server for:
• SQL92 database triggers
• SQL92 stored procedures
• The JDK enables the Progress SQL92 server to compile and execute stored procedures as well as
database triggers each time it is required. A JRE is sufficient only for executing existing stored
procedures; it will not allow creation of new stored procedures or database triggers.
Note: The JDK contains the JRE.
Table3: Progress licenses with SQL92 server and JDK requirements
Is a JDK installed by Progress on some

Product License
Operating Systems?
4GL Development Yes
Enterprise Database No
Personal Database No
ProVision * Yes
ProVision Development Server Yes
ProVision Plus * Yes
ProVision Plus Development Server Yes
Visual Translator * No
13
Is a JDK installed by Progress on some

Product License
Operating Systems?
WebSpeed Development Server Yes
WebSpeed Workshop * Yes
Workgroup Database No
Notes:
* Available for Microsoft Windows/Citrix types of operating systems only.
3.4. Installation Process
With Progress, two types of installation can be performed. To install a specific Progress product on a
machine you can do a local installation or a NetSetup. The NetSetup installation is specific to Windows
operating systems and cannot be performed under any other operating system (such as UNIX-based
operating systems).
Moreover, in terms of best practices, local installations are always preferred over NetSetup installations
because they offer a better stability to a configuration used in production. Getting the binary code for
processes from a machine remote to the one where the process is running can go wrong due to networking
issues. Attempting to access some specific shared library that was not loaded on the machine where the
process is running while the network is down can lead to a database crash.
3.4.1. Local installation
When installing server licenses this is the installation to perform for a production system. It ensures that the
database processes are still able to get executed no matter what is happening else where on your network.
The server processes and the databases should always be considered as a logical unit regrouped on a single
machine. In this grouping, the binary code for the processes and the database files should be local to the
machine where the processes are started and should never get separated on two (or more) different machines.
3.4.1.1. Before local installation

Before performing a local installation, ensure that the operating system is at the required level (see previous
sections for more information).
It is mandatory to:
• Install the correct JDK version on the machine prior to installing Progress, or to check that Progress
installs the JDK for you depending on the licenses installed, the operating system and the Progress
version to install.
• Read the hard-copy Progress Release Notes for the installation. The Progress Release Notes might
replace or supplement the installation instructions in this white paper or in the Progress Installation and
Configuration Guide product documentation.
14
3.4.1.2. During local installation

Once this is done, start the normal installation process and follow the instructions in the Progress
Installation and Configuration Guide for your operating system type.
During the installation process itself (after supplying the serial numbers and control numbers of the licenses
to be installed), Progress will ask you for the following SQL92 server related information:
• Server Engines (to install): Select Both server engines or SQL92 only.
• Java Home Pathname: Specify the directory where the JDK is installed. For instance, if jdk118 is
installed in /usr/jdk118 then you should enter /usr/jdk118 (not requested under Windows).
• Type of Installation: always choose a complete installation of the licenses that provide access to the
SQL92 server will install that specific product or custom if you know which products to select for
installation.
• The destination path name offers the chance to change the installation directory path.
• The working directory where Progress processes temporary files will also be stored (including SQL92
server processes).
Troubleshooting questions:
Note: These questions only apply to UNIX-based operating systems as Progress installs a JDK under
windows.
What would happen, during the installation, if a JDK has not been detected and if Progress does not
install the JDK on your specific operating system or for the licenses you are installing?
• Installing products that require Java is prevented. A warning is first displayed notifying that not JDK has
been detected: “A JVM has not been detected. Installation of products that require Java will not be
allowed.”
• If you ignore this warning message and proceed, the installation of all licenses requiring the presence of
a JDK on your operating system is prevented. In this case, the Progress installation process informs you
that this specific license requires a functional JDK. Since all licenses containing the SQL92 server
require the presence of a JDK, none of them will be installed.
What triggers this warning to be displayed?

• This happens because Progress did not detect any reference to a directory symbolized by
$JDK_HOME/bin. Three different issues can cause the previous message to be displayed:
o The directory pointed to does not contain the required JDK or does not exist.
o The directory where the JDK is installed is not included in the PATH.
o The JDK has not been installed.
What should I do to proceed with the installation?

• All licenses that will allow the installation of the Progress SQL92 server require a functional JDK
installed on your machine. To allow a correct installation of the Progress SQL92 server, an installed JDK
is required. For instance, under UNIX, if JDK 1.1.8 is installed in /usr/jdk118, then you should have
/usr/jdk118/bin included in your PATH. Your only option at this stage of the installation is to abort the
installation process, download the required JDK (refer to the previous sections to know which one and
where you can download it), install it, and restart the installation process.
15
3.4.1.3. After local installation

Note: This section is specific to UNIX.
Since the local installation was performed as root, it is mandatory to ensure that everybody can create files
in the working directory specified at install time. This is required because the SQL92 server processes do not
use the root privileges as other Progress processes commonly do. Instead, the SQL92 processes always use
the privileges of the user who started the database server. For this reason granting read and write access on
the working directory to everyone on the system who can start and stop the Progress servers is the first task
to perform once the installation has completed successfully.
3.4.2. NetSetup configuration
For testing purpose (and not in a production environment), the installation of a Progress SQL92 server can be
done with a NetSetup.
The reasons this type of installation should never be used in a production environment are simple:
• This slows down the processes to start a broker on a Progress database.
• This additional factor will add to the connection time of remote clients as the process may need to access
shared library that are stored on some other machines.
• If a networking problem occurs between the machine where the process is running and the machine
where the binary code of that process is stored, what happens to that process? It will crash.
• If the server processes accessing the database are crashing, Progress cannot completely guarantee the
data integrity of all information stored in the database or currently being manipulated.
However, if the intention is only to test an application against a test database, then this configuration is
acceptable, but only if it is for test purposes.
Considering that we are building a test environment, the next section includes points that you will need to
pay attention too when installing a Progress server through a NetSetup under Windows operating systems.
3.4.2.1. Before NetSetup

There are definitely some points to consider before doing a NetSetup:
• You need to have an existing Progress product installed somewhere on your network. This product
should already have the SQL92 server available. If this is not the case, then please install such a
configuration on your network (refer to Section “3.3.1: Local Installation”) and change the installation
directory so that it gets installed on a file server instead of simply being installed locally to your
machine.
• You also need to know on which drive this Progress product was installed when performing the local
installation. With this information, you need to create a mapped drive with the same letter and mounted
at the same point in the directory structure than what was done from the machine from which the local
installation was performed.
The reason is that Progress not only stores information in the registry of the machine from which the first
install is performed, but it also creates files (for instance .bat files or even the progress.ini file) at install
time that are used from the command prompt. These files contain references to the drive letter and
directory where Progress is installed and are stored in %DLC%\bin or in %DLC%.
To clarify, let’s take an example. For instance, if the original installation was performed under a
directory seen as H:\Progress where H:\ is a drive mapped on a file server, you need to create the same
H:\ driver mapping the same mounting point on the machine where you intend to perform the NetSetup.
16
• You need to ensure that every user using this configuration has enough privileges to access the mapped
drive (at least has read privileges).
• You need to ensure that there is a JDK available on the same network drive or at least installed and
accessible through the same directory path than what was configured on the machine from which the
original installation was performed if Progress did not install one for you.
For example, you installed only a workgroup server license on a shared drive. With this license installed
Progress does not install the JDK. You need to have one installed prior to your installation. It is best to
install this product on the shared drive that will also be used with the Progress installation. With this
configuration you share the JDK and the Progress product on your network.
If you have ensured all the above is set, you are ready to perform a NetSetup installation.
3.4.2.2. During NetSetup

Start the normal installation process and follow the instructions in the Progress Installation and
Configuration Guide for Windows.
During NetSetup, no questions related to the Progress server processes will be asked (such as the location of
the JDK). This is expected as you are performing a Shared Network Installation. This means that you have
access to everything that has been previously installed on the network file system (including the JDK).
3.4.2.3. After NetSetup

Once NetSetup is completed, you have access to the Progress SQL92 server but you can start and stop these
processes only through limited ways:
• proenv script
• proserve script
• _mprosrv.exe
The next two sections will describe these scripts and ways to administrate a Progress SQL92 server.
4. The SQL92 Server Environment

With an installed Progress SQL92 server there are several places to check in case of problems, or to be
aware of before actually starting using this product. In fact, the server process relies heavily on the
environment specified at install time. Progress expects that the environment does not change once the
installation has been performed as it is supposed to be correct from the outset.
If, at a later stage, this environment needs to change (for instance because the system administrator needs to
move the JDK from one directory to another, or update the JDK version) there are settings to change in the
SQL92 server environment.
This section covers the complete environment used by the SQL92 server under UNIX and Windows/Citrix
operating system types, including how to maintain the Progress SQL92 environment when changes are
required on the machine hosting Progress.
17
4.1. Under UNIX
This section covers the environment used by the SQL92 server under UNIX starting with operating system
environment variables and followed by the two scripts built at the end of the Progress install during the
tailoring process. Scripts that start Progress processes (e.g., proserve) reference two specific scripts that
define all the variables required to ensure a fully functional SQL92 server.
4.1.1. Operating System Environment Variables
Assuming a database server is started through the _mprosrv executable, under UNIX, the minimum
environment required to have a fully functionally SQL92 server should contain the variables described
below. The different variables required are sorted by the type of functionality that they enable in the SQL92
server.
4.1.1.1. Progress General Environment Variables

These variables are required for all Progress processes under UNIX:
• DLC: Progress installation directory
• PATH: Contains $DLC/bin so that the executable can be found from the command line
• PROMSGS: Points toward the Progress error message file so that processes can return the correct error
messages
More information on those variables is available in the Progress Installation and Configuration Guide for
UNIX.
4.1.1.2. Java Environment Variables for the SQL92 Server

There are two types of Java packages that can be used with the SQL92 server. Each of them brings different
functionality:
• On one hand, the JRE (Java Runtime Environment) allows only execution of existing compiled Java
application. When used with the Progress SQL92 server, this means that it does not allow the creation of
Java stored procedures and database triggers. It only allows their execution.
• On the other hand, the JDK (Java Development Kit) allows execution of existing Java application and
allows compilation of Java classes into Java binary code. When used with the Progress SQL92 server,
this means that it allows compilation of stored procedures and database triggers so that they can be
executed later.
The above points highlight that you can allow or prevent users to create stored procedures and database
triggers based on the values you specify for the environment variables provided below. However providing
an environment pointing to a JRE instead of a JDK is not a good practice. If a user should not have the
ability to create stored procedures and database triggers, this should be managed with the privileges used
within the SQL92 database. As a result, we will not provide, in the next sections, an example of environment
limited to the JRE.
The variables provided below help the SQL92 server find the Java executables required when executing
stored procedures or database triggers:
• JVMEXE: The executable name of the JVM (Java in most cases)
• JDKHOME: JDK Install directory
• JREHOME: JRE Install directory (subdirectory of JDKHOME)
18
The variables provided below help the SQL92 server find the compiled classes (binary Java code) required
by the Java executables when processing stored procedures or database triggers:
• PROGRESSCP: Java Classpath specific to Progress objects for stored procedures and database triggers
• JDKCP: Standard JDK Classpath
• JRECP: Standard JRE Classpath
• CLASSPATH: Sum of the previous 3 Classpaths
This variable defines the java policy required by the SQL92 server:
• JAVAPOLICY: Policy defined by Progress
These variables define values that are dependant on the operating systems and the Progress implementation
for the SQL92 server to properly use and access the Java environment. Their value usually changes per
operating system.
• THREADS_FLAG: The Java threading model used by the JVM. This is dependant on the operating
system.
• JVMARGS: JVM Argument for memory management model. This is dependant on the operating
system.
• VMTYPE: Java Virtual Machine Type. This is dependant on the operating system.
Note: See the section, “Examples: Environment scripts under various operating systems” to get the proper
value for THREADS_FLAG, JVMARGS and VMTYPE as they are operating-system dependant.
4.1.1.3. Operating System Shared Library PATH

In the case of the operating system shared library path the complete list is provided below for each UNIX
flavor that supports the Progress SQL92 server.
Any Progress server requires this environment variable as the different engines are provided in different
shared libraries starting with V9.
The shared library path should also include the correct path to the Java JVM library:
• Compaq Tru64 (formerly Digital UNIX): LD_LIBRARY_PATH
• HP-UX: SHLIB_PATH
• IBM AIX: LIBPATH
• Linux: LD_LIBRARY_PATH
• Sun Solaris Sparc: LD_LIBRARY_PATH
• SCO UnixWare: LD_LIBRARY_PATH
19
4.1.1.4. Other Environment Variables

There are some other environment variables that are not required when starting the Progress SQL92 server
process. However they are very handy and offer interesting possibilities:
• WRKDIR: Specify the working directory for the SQL92 server. In this directory, the SQL92 server will
create all the temporary files it requires while processing client requests. To set the WRKDIR variable:
WRKDIR =/usr1/test/tmp
• SQLREUSE: Specify the SQL92 server behavior. If a connection ends, should the server stop or should
it wait for some other connection? To set the SQLREUSE variable:
SQLREUSE=on (to enable it)
SQLREUSE=false (to disable it)
4.1.1.5. Examples: Environment scripts under various operating

systems
This section will provide working examples of scripts used with V9.1C and V9.1D under all UNIX
operating systems where the SQL92 server is available.
For each of the examples provided, you may need to update the values of the variables marked in bold
according to the location where the different elements are installed (Progress and JDK mainly). You can also
add the other two variables mentioned in the previous section, “Other Environment Variables.”
Note: These scripts do not work with 9.1a or b, as the JDK used with these two versions is not the same as
the one used with 9.1c. The following script can be adapted to other Progress versions after finding the
correct values to set in the files described in the next section. Those files are named java_env and slib_env.
They are located in $DLC/bin.
Compaq Tru64:
#!/bin/sh
# Progress Environment (For Compaq TRU64 + PRGS 9.1c)
echo "Setting Progress Environment manually for Compaq TRUE 64 + Prgs 9.1c"
# Determine the correct directory where Progress is installed

# from either the tailored name or existing value of $DLC.
# Set the user working directory - this is a tailored value
DLC=/usr1/v91C/dlc
WRKDIR=/usr1/test/tmp
# Set the PATH - this is a tailored value

# Set PROMSGS (if not set) add another others here
PATH=$DLC/bin:$PATH
PROMSGS=$DLC/promsgs
# Set the virtual machine to java. This is available in both

# the JDK and JRE environments - so we can default to it.
# Set defaults for JDK, JRE home
JDKHOME=/usr1/jdk13
JREHOME=$JDKHOME/jre
JVMEXE=java
# Sets the CLASSPATH for the Java environment

ProgressCP=$DLC/java/alphajdbc.zip:$DLC/java/Progress.zip
JDKCP=$JDKHOME/lib/tools.jar
JRECP=
CLASSPATH=$JRECP:$ProgressCP:$JDKCP
# Sets Different parameters for the Java environment

THREADS_FLAG=native
JAVAPOLICY=$DLC/java/java.policy
JVMARGS="-mx25m"
20
VMTYPE=client
ARCH=alpha
# Set the shared library search path for the server engine based
# on the previous variables.
LD_LIBRARY_PATH=$JREHOME/lib/$ARCH/${THREADS_FLAG}_threads:$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$LD_LIBRA
RY_PATH:$DLC/lib
# Exporting all the variables

export DLC WRKDIR PATH PROMSGS
export JVMEXE JDKHOME JREHOME
export ProgressCP JDKCP JRECP CLASSPATH
export THREADS_FLAG JAVAPOLICY JVMARGS VMTYPE ARCH
export LD_LIBRARY_PATH
echo "The end!"
HP-UX:
#!/bin/sh
# Progress Environment (For HP-UX + Prgs 9.1c)
echo "Setting Progress Environment manually for HP-UX + Prgs 9.1c"

DLC=/usr1/v91C/dlc

PATH=$DLC/bin:$PATH

JDKHOME=/usr1/jdk13
JVMEXE=java

ProgressCP=$DLC/java/Progress.zip
JRECP=

THREADS_FLAG=native_threads
JVMARGS="-ms8m"
VMTYPE=server
ARCH=PA_RISC
SHLIB_PATH=$JREHOME/lib/$ARCH/$THREADS_FLAG:$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$SHLIB_PATH:$DLC/lib

export SHLIB_PATH
echo "The end!"
Note: Under HP-UX, if a variable does not exist in your environment, before doing something like:
$SHLIB_PATH=.:..:$SHLIB_PATH (done in the above script example), an error message is returned and
the variable is not set. Make sure this variable is initialized before calling the above script.
21
IBM AIX:
#!/bin/sh
# Progress Environment (For IBM AIX + PRGS 9.1c)
echo "Setting Progress Environment manually for IBM AIX + Prgs 9.1c"

DLC=/usr1/v91C/dlc

PATH=$DLC/bin:$PATH

JDKHOME=/usr1/jdk13
JVMEXE=java

JRECP=

THREADS_FLAG=native
JVMARGS="-ms8m"
VMTYPE=client
ARCH=aix
LIBPATH=$JREHOME/bin:$LIBPATH:$DLC/lib

export LIBPATH
echo "The end!"
Linux:
#!/bin/sh
# Progress Environment (For Linux + Prgs 9.1c)
echo "Setting Progress Environment manually for Linux + Prgs 9.1c"

DLC=/usr1/v91C/dlc

PATH=$DLC/bin:$PATH

22

JDKHOME=/usr1/jdk13
JVMEXE=java

JRECP=

THREADS_FLAG=native
JVMARGS="-ms8m"
VMTYPE=classic
ARCH=i386
LD_LIBRARY_PATH=$JDKHOME/lib/$ARCH:$JREHOME/lib/$ARCH:$JREHOME/lib/$ARCH/${THREADS_FLAG}_threads:$JREHOME/bin:$JRE
HOME/lib/$ARCH/$VMTYPE:${LD_LIBRARY_PATH}:$DLC/lib
PROLIBPATH=$LD_LIBRARY_PATH

export LD_LIBRARY_PATH PROLIBPATH
echo "The end!"
Notes:
• Under Linux, if a variable does not exist in your environment, before doing something like:
$LD_LIBRARY_PATH=.:..:$LD_LIBRARY_PATH (done in the above script example), an error
message is returned and the variable is not set. Make sure this variable is initialized before calling the
above script.
• Under Linux with Progress 9.1c a problem has been detected when retrieving the LD_LIBRARY_PATH
variable from the SQL92 server. To solve this issue, an additional variable is required: PROLIBPATH.
This variable needs to be set to the same value as LD_LIBRARY_PATH.
SCO UnixWare:
#!/bin/sh
# Progress Environment (For SCO UnixWare + Prgs 9.1c)
echo "Setting Progress Environment manually for SCO UnixWare + Prgs 9.1c"

DLC=/usr1/v91C/dlc

PATH=$DLC/bin:$PATH

JDKHOME=/usr/java2
JVMEXE=java
23

JRECP=

THREADS_FLAG=native
JVMARGS="-ms8m"
VMTYPE=classic
ARCH=x86at
LD_LIBRARY_PATH=$JREHOME/lib/$ARCH/${THREADS_FLAG}_threads:$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$LD_LIBRA
RY_PATH:$DLC/lib

echo "The end!"
Note: Under SCO UnixWare, if a variable does not exist in your environment, before doing something like:
$LD_LIBRARY_PATH=.:..:$LD_LIBRARY_PATH (done in the above script example), an error message
is returned and the variable is not set. Make sure this variable is initialized before calling the above script.
Sun Solaris Sparc:

Progress provides the JDK on this operating system. As a result the only variables to check for this script to
work are $DLC and $PATH.
#!/bin/sh
# Progress Environment (For Solaris Sparc + Prgs 9.1c)
echo "Setting Progress Environment manually for Solaris Sparc + Prgs 9.1c "

DLC=/usr1/v91C/dlc

PATH=$DLC/bin:$PATH

JDKHOME=$DLC/jdk
JVMEXE=java

JRECP=

JVMARGS="-ms8m"
VMTYPE=client
ARCH=sparc
24

LD_LIBRARY_PATH=$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$LD_LIBRARY_PATH:$DLC/lib

export JAVAPOLICY JVMARGS VMTYPE ARCH
echo "The end!"
Note: Under Solaris, if a variable does not exist in your environment, before doing something like
$LD_LIBRARY_PATH=.:..:$LD_LIBRARY_PATH (done in the above script example), an error message
is returned and the variable is not set. Make sure this variable is initialized before calling the above script.
4.1.2. What Progress Provides
Progress already provides script files that set the environment variables mentioned in section 4.1.1.
In the next sections, we will detail the two scripts provided by Progress: slib_env and java_env. We will also
enhance the proenv script so that it calls those two environment scripts. This will allow starting an SQL92
server and make sure it runs with all required functionality.
4.1.2.1. The java_env Script

The java_env script (available under $DLC/bin) sets only the Java-related environment variables. All the
other scripts starting processes that use Java will call this script.
For instance, the SQL92 server can be started via the proserve script. As a result the proserve script calls the
java_env script in order to set the Java-related environment variables.
Those variables are set in two sections, as the script is built to take care of differences between operating
systems. The first section (on top of the file) sets the values that are not operating-system dependant and also
gives default values for all the other environment variables. The second section resets the variables that are
operating-system dependant.
Bellow is a list of the variables set in the java_env script:
• JVMEXE (First Section)
• PROGRESSCP (First Section)
• JAVAPOLICY (First Section)
• THREADS_FLAG (Second Section)
• JVMARGS (Second Section)
• JREHOME (Second Section)
• JDKHOME (Second Section)
• JDKCP (Second Section)
• JRECP (Second Section)
• CLASSPATH (Second Section)
• Shared Library Path (Second Section)
For descriptions of those variables, see section 4.1.1.2, “Java Environment for the SQL92 Server.”
Most of the values provided in this script should never be changed with the exception of JDKHOME and
JREHOME (if the version is updated or the install directory has changed). Their value should be changed
only in the section related to your operating system.
The java_env script below is the one Progress provides with V9.1C and V9.1D for all UNIX operating
systems.
25
#!/bin/sh
# Setup the Java environment for JDK/JRE and Progress,
# this script expects the DLC environment variable to be set
: ${DLC?"DLC variable must be set"}
# If internal build environment - Java is already setup just exit

if [ -n "$RDLLSC" ]
then
:
else
# Set the virtual machine to java. This is available in
# both the JDK and JRE environments - so we can default to it.
JVMEXE=java
export JVMEXE
# Set defaults for JDK, JRE home, bin, lib directories

# platform specific overrides are below
JDKHOME=${JDKHOME-$DLC/jdk}
JREHOME=${JREHOME-$DLC/jre}
ProgressCP=${ProgressCP-
$DLC/java/Progress.zip:/usr1/v91C/java/sonicMQ/lib/client.jar:/usr1/v91C/java/sonicMQ/lib/jndi.jar}
export ProgressCP
JAVAPOLICY=${JAVAPOLICY-$DLC/java/java.policy}
export JAVAPOLICY
# If the FATHOMCP environment File exists, source the file. This will set
# the FATHOMCP, the Application Mgmt Classpath, if Fathom has been
# installed
if [ -f $FATHOMTARG/bin/fathomcp_env ]
then
. $FATHOMTARG/bin/fathomcp_env
elif [ -f $DLC/bin/fathomcp_env ]
then
. $DLC/bin/fathomcp_env
fi
# Set the java runtime environment

OSNAME=ùname`
case "$OSNAME" in
"SunOS") # Sun Solaris v2.5.1/v2.6 we ship jdk,jre
JRECP=
JVMARGS="-ms8m"
VMTYPE=client
ARCH=ùname -p`
# Set the shared library search path - snippet from the java script
LD_LIBRARY_PATH=$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$LD_LIBRARY_PATH
;;
"HP-UX") # HP UNIX 11.00

THREADS_FLAG=native_threads
JVMARGS="-ms8m"
#JDKHOME=
JRECP=
VMTYPE=server
ARCH=PA_RISC
# set the shared library search path - snippet from the java script
SHLIB_PATH=$SHLIB_PATH:$JREHOME/lib/$ARCH/$THREADS_FLAG:$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH
export SHLIB_PATH
;;
"AIX") # IBM UNIX we ship No jdk, jre

THREADS_FLAG=native
JIT=""
JVMARGS="-ms8m"
#JDKHOME=
26
JRECP=
VMTYPE=client
ARCH=aix
LIBPATH=$JREHOME/bin:${LIBPATH}
export LIBPATH
SQL_LIBPATH=$LIBPATH
export SQL_LIBPATH
;;
"OSF1") # Digital UNIX we ship No jdk, jre

ProgressCP=$DLC/java/alphajdbc.zip:$ProgressCP; export ProgressCP
JVMARGS="-mx25m"
JDKHOME=
JREHOME=$JDKHOME
JRECP=
VMTYPE=client
ARCH=alpha
LD_LIBRARY_PATH=$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$LD_LIBRARY_PATH
;;
"UnixWare") # Unixware we ship No jdk, jre

THREADS_FLAG=native
JIT=""
JVMARGS="-ms8m"
JDKHOME=
JREHOME=$JDKHOME
JRECP=
VMTYPE=classic
ARCH=x86at
LD_LIBRARY_PATH=
$JREHOME/lib/$ARCH/${THREADS_FLAG}_threads:$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$LD_LIBRARY_PATH
;;
"SCO_SV") # SCO Open Server 5 we ship No jdk, jre

THREADS_FLAG=green
JIT=""
JVMARGS="-ms8m"
JDKHOME=
JREHOME=$JDKHOME
JRECP=
VMTYPE=classic
ARCH=x86at
LD_LIBRARY_PATH=
$JREHOME/lib/$ARCH/${THREADS_FLAG}_threads:$JREHOME/lib/$ARCH/$VMTYPE:$JREHOME/lib/$ARCH:$LD_LIBRARY_PATH
;;
"dgux") # DGUX Unixware cert. We ship No jdk, jre

THREADS_FLAG=native
JIT=""
JVMARGS="-ms8m"
JDKHOME=
JREHOME=$JDKHOME
JDKCP=$JDKHOME/lib/classes.zip
JRECP=$JDKCP
ARCH=dgux_x86
LD_LIBRARY_PATH=$JREHOME/lib/$ARCH/${THREADS_FLAG}_threads:$LD_LIBRARY_PATH
;;
"Linux")
THREADS_FLAG=native
27
JIT=""
JVMARGS="-ms8m"
JDKHOME=
JREHOME=$JDKHOME
JAVAHOME=$JREHOME
export JAVAHOME
JRECP=$JDKCP
VMTYPE=classic
ARCH=i386
LD_LIBRARY_PATH=
$JREHOME/lib/$ARCH:$JREHOME/jre/lib/$ARCH:$JREHOME/jre/lib/$ARCH/${THREADS_FLAG}_threads:$JREHOME/jre/bin:$JREHOME
/jre/lib/$ARCH/$VMTYPE:$LD_LIBRARY_PATH
export PROLIBPATH
;;
*) # Unrecognized uname, we ship No jdk, jre

THREADS_FLAG=green
JIT=""
JVMARGS="-ms8m"
# JDKHOME=
JREHOME=$JDKHOME
JRECP=$JDKCP
echo "WARNING: not setting shared library include path"

;;
esac
CLASSPATH=$JRECP:$ProgressCP:$FATHOMCP
export THREADS_FLAG
export JVMARGS
export JREHOME
export JDKHOME
export JDKCP
export JRECP
export CLASSPATH
#echo "ARCH= $ARCH"

#echo "JVMEXE= $JVMEXE"
#echo "ProgressCP= $ProgressCP"
#echo "THREADS_FLAG= $THREADS_FLAG"
#echo "JVMARGS= $JVMARGS"
#echo "JREHOME= $JREHOME"
#echo "JDKHOME= $JDKHOME"
#echo "JRECP= $JRECP"
#echo "JDKCP= $JDKCP"
#echo "CLASSPATH= $CLASSPATH"
#echo "LD_LIBRARY_PATH= $LD_LIBRARY_PATH"
#echo "SHLIB_PATH= $SHLIB_PATH"
#echo "LIBPATH= $LIBPATH"
fi
4.1.2.2. The slib_env Script

The slib_env script (available under $DLC/bin) sets only the shared-library-related environment variable for
Progress processes. This enables all Progress processes to work wherever the product has been installed.
This variable is set per operating system as different UNIX operating systems give it a different name. All
the other scripts starting processes call this script.
For instance, the SQL92 server can be started via the proserve script. As a result the proserve script calls the
slib_env script in order to set the shared library environment variable.
All the values provided in this script should never be changed as they are set to enable Progress to work
properly. The only case where the value would require to be modified is when moving Progress to a
28
different directory; however, it is easier and safer to re-install the complete product. The slib_env script
below is the one Progress provides with V9.1C and V9.1D for all UNIX operating systems.
#!/bin/sh
# Progress Shared Library setup
# Setup the Progress shared library environment.

# This script expects the DLC environment variable to be set
: ${DLC?"DLC variable must be set"}
# If internal build environment - this is already setup just exit

if [ -n "$RDLLSC" ]
then
:
else
# set the shared library include path for Progress - system specific
OSNAME=ùname`
case "$OSNAME" in
"SunOS") # Sun Solaris v2.5.1/v2.6
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DLC/lib
;;
"HP-UX") # HP UNIX, v11.00, v10.20

SHLIB_PATH=$SHLIB_PATH:$DLC/lib
export SHLIB_PATH
;;
"AIX") # IBM UNIX v4.2

LIBPATH=$LIBPATH:$DLC/lib
export LIBPATH
PROLIBPATH=$LIBPATH
export PROLIBPATH
;;
"OSF1") # Digital UNIX

;;
"UnixWare") # Unixware 7
;;
"dgux") # DG/UX (Unixware 7 cert platform)

;;
"SCO_SV") # SCO Open Server 5 (Unixware 7 cert platform)

;;
"Linux")
export PROLIBPATH
;;
*) # Unrecognized uname
echo "WARNING: not setting shared library include path"
;;
esac
fi
29
4.1.2.3. The proenv Script

Progress also provides a default command-line environment: the proenv script (available under $DLC/bin).
Unfortunately, the Java environment and the shared-library environment are not set with this script. This
slightly limits the functionality offered under this environment but is still very useful when starting a
Progress process from the command prompt.
To improve this script and offer access to more functionality (for instance, enable reuse of scripts developed
with former Progress versions for database startup procedures that were calling the _mprosrv executables) a
modified version of this script (below) is required.
This original script is usually used to set up a command-line environment with basic settings. The modified
version can be used as a base to develop an environment script or other database startup / shutdown scripts.
(Keep a copy of the original before any modification.)
This modified script is enhanced with the items marked in bold. Those items will set the required Java
environment and shared-library environment to ensure a fully functioning SQL92 server. As presented here,
the script can be used directly under any UNIX flavor.
# proenv
DLC="/usr1/v91A05/dlc"
WRKDIR="/usr1/v91A05/wrk"
PATH=$DLC/bin:$PATH
PS1="proenv>"
export DLC WRKDIR PATH PS1
# set the Progress shared lib environment

if [ ! -f $DLC/bin/slib_env ]
then
echo "slib_env could not be found."
echo
echo "Progress shared library environment not set correctly."
echo "Progress DLC environment variable may not be set correctly."
echo "Set DLC variable to Progress installation directory."
echo
echo "Progress DLC setting: $DLC"
echo
exit 1
fi
# Set the Progress Shared lib environment

. $DLC/bin/slib_env
# set the java environment

if [ ! -f $DLC/bin/java_env ]
then
echo "Java Environment not found, using Java free environment"
exec /bin/sh
exit 0
fi
# Set the Java environment

. $DLC/bin/java_env
# start up a new shell

exec /bin/sh
30
4.2. Under Microsoft Windows or Citrix
Although the environment variables under UNIX and Windows are similar they are not set in the same
places. Progress takes full advantage of the registry mechanism available under the Windows based
operating systems and, as a result, sets and repeats its environment variables in different locations. Progress
processes will check those different places in a specific order when starting.
4.2.1. Operating System Environment Variables
Assuming a database server is started through the _mprosrv executable, under Windows, the minimum
environment required to have a fully functionally SQL92 server should contain the variables described in the
following sections. The different variables required are sorted by the type of functionality that they enable in
the SQL92 server.
4.2.1.1. Progress General Environment Variables

These variables are required for all Progress processes under Windows, although they do not need to be set
in the User or System environment because all Progress processes by default check other locations that are
listed in section 4.2.2:
• DLC: Progress installation directory
• PATH: Contains %DLC%\bin so that the executable can be found from the command line
• PROMSGS: Points toward the Progress error message file so that processes can return the correct error
messages
• LIB: Points towards the Progress libraries available in %DLC%\lib under Windows
More information on those variables is available in the Progress Installation and Configuration Guide for
Windows Section 5.4, The Windows Registry and the Progress.ini File.
4.2.1.2. Java Environment for the SQL92 Server

There are two types of Java packages that can be used with the SQL92 server. Each of them brings different
functionality:
• On one hand, the JRE (Java Runtime Environment) allows only execution of existing compiled Java
applications. When used with the Progress SQL92 server, this means that it does not allow the creation
of Java stored procedures and database triggers. It only allows their execution.
• On the other hand, the JDK (Java Development Kit) allows execution of existing Java applications and
allows compilation of Java classes into Java binary code. When used with the Progress SQL92 server,
this means that it allows compilation of stored procedures and database triggers so that they can be
executed later.
The above points highlight that you can allow or prevent users to create stored procedures and database
triggers based on the values you specify for the environment variables provided below. However providing
an environment pointing to a JRE instead of a JDK is not a good practice. If a user should not have the
ability to create stored procedures and database triggers, this should be managed with the privileges used
within the SQL92 database. As a result, we will not provide, in the next sections, an example of environment
limited to the JRE.
31
The variables provided below help the SQL92 server find the Java executables required when executing
stored procedures or database triggers:
• JVMEXE: The executable name of the JVM (Java in most cases)
• JDKHOME: JDK Install directory
• JREHOME: JRE Install directory (subdirectory of JDKHOME)
The variables provided below help the SQL92 server find the compiled classes (binary Java code) required
by the Java executables when processing stored procedures or database triggers.
• PROGRESSCP: Java Classpath specific to Progress objects for stored procedures and database triggers
• JDKCP: Standard JDK Classpath
• JRECP: Standard JRE Classpath
• CLASSPATH: Sum of the previous 3 Classpaths
These variables define values that are required by the Progress implementation for the SQL92 server to
properly use and access the java environment.
• JAVAPOLICY: Policy defined by Progress
• JVMARGS: JVMArgument for memory management model
4.2.1.3. Other Environment Variables

There are some other environment variables that are not required when starting the Progress SQL92 server
process. However, they are very handy and offer interesting possibilities:
• WRKDIR: Specify the working directory for the SQL92 server. In this directory, the SQL92 server will
create all the temporary files it requires while processing client requests. To set the SQLREUSE variable:
SQLREUSE=on (to enable it)
SQLREUSE=false (to disable it)
• SQLREUSE: Specify the SQL92 server behavior. If a connection ends, should the server stop or should
it wait for some other connection? To set the WRKDIR variable:
WRKDIR =C:\temp
4.2.1.4. Example: One Environment Script

This section provides a working script used with V9.1c under Microsoft Windows 2000 Professional where
the SQL92 server is available. This same script may not work with 9.1a or b, as the JDK used with these
two versions is not the same as the one used with 9.1c or it may be installed in a different directory.
You may need to update the values of the variables marked in bold according to the location of the different
elements after install (Progress and JDK mainly). You can also add to or modify the other two variables
mentioned in the previous section, “Other Environment Variables.”
32
You can modify the following script to start specific Progress processes.
echo off
echo Setting Progress Environment manually for Windows 2000 + Prgs 9.1c
REM Determine the correct directory where Progress is installed

REM from either the tailored name or existing value of $DLC.
REM Set the user working directory - this is a tailored value
REM set DLC=C:\PROGRAM FILES\Progress\DLC
set DLC=W:\DLC
set WRKDIR=D:\TEMP
REM Set the PATH

REM Set PROMSGS
set PATH=%DLC%\jdk\bin;%DLC%\BIN;%PATH%
set PROMSGS=%DLC%\promsgs
set LIB=%DLC%\LIB;%LIB%
REM Set the virtual machine to java. This is available in both

REM the JDK and JRE environments - so we can default to it.
REM Set defaults for JDK, JRE home
set JDKHOME=%DLC%\jdk
set JREHOME=%DLC%\jdk\jre
set JVMEXE=java
REM Sets the CLASSPATH for the Java environment

set ProgressCP=%DLC%\java\Progress.zip
set JRECP=%JREHOME%\lib\rt.jar;%JREHOME%\lib\i18n.jar
set JDKCP=%JDKHOME%\lib\tools.jar
set CLASSPATH=%JRECP%:%ProgressCP%:%JDKCP%
REM Sets Different parameters for the Java environment

set JAVAPOLICY=%DLC%\java\java.policy
set JVMARGS=-ms8m
prompt $P:9.1c env$g
REM - The End –

echo on
4.2.2. What Progress Provides
Progress already provides script files that set the environment variables mentioned in section 4.2.1. In this
section, we will detail the three different places where Progress sets these environment variables. We will
also enhance the proenv script so that it allows execution of scripts developed for previous Progress
versions. This will allow starting an SQL92 server and make sure it runs with all required functionality.
The Progress servers will load their environment variables from specific locations. These locations are listed
below in the order in which they are accessed.
First, the server process will look in the Windows registry system under the following location in this order:
• HKEY_local_machine\software\PSC\Progress\<version>
• HKEY_current_user\software\PSC\Progress\<version>
If the required environment is not completely defined or is not available in the Windows registry, all
Progress processes will look for and try to access the progress.ini file available under %DLC%\bin.
33
4.2.2.1. The Windows Registry

The Windows registry entries accessed by all Progress processes contain all environment variables that may
be required to run any licensed product available under Windows. For this reason, under
HKEY_local_machine\software\PSC\Progress\<version> and / or under
HKEY_current_user\software\PSC\Progress\<version>, Progress has structured its registry entries keys in
the following fashion. (The keys containing the variables that the SQL92 server uses are marked in bold.):
• Colors
• Debug-Buttons
• Debug-Init
• Debug-Macros
• Fonts
• JAVA
• Proedit
• ReportBuilderDefaults
• ReportBuilderPreferences
• ReportBuilderSaveList
• Startup
• WinChar Colors
• WinChar Startup
The JAVA section contains the definition of the Java-related environment variables and the Startup section
contains the other environment settings with the exception of the LIB and PROMSGS variables that are reset
by default. The PATH variable should be set in the Windows environment.
Important Note: Under no circumstances should the registry entries be modified manually. Use the init2reg
utility provided by Progress to update the entries (see section 4.3.2). The extract below is provided only for
informational purposes.
Below is a list of the variables set in the registry for Progress 9.1c (after an export). The ‘…’ at the
beginning of the keys is to be replaced by one of the following values:
• HKEY_local_machine
• HKEY_current_user
The following is an excerpt. The Progress SQL92 server specifically accesses the variables and keys marked
in bold.
[…\SOFTWARE\PSC\Progress\9.1C]
"WorkPath"="d:\\work\\91c"
.
.
.
[…\SOFTWARE\PSC\Progress\9.1C\Java]
"JDKHOME"="w:\\dlc\\jdk"
"JREHOME"="w:\\dlc\\jre"
"JRECP"="w:\\dlc\\jre\\lib\\rt.jar;w:\\dlc\\jre\\lib\\i18n.jar"
"JDKCP"="w:\\dlc\\jdk\\lib\\tools.jar"
"FATHOMCP"=""
34
"ProgressCP"="w:\\dlc\\java\\Progress.zip;w:\\dlc\\java\\sonicMQ\\lib\\client.jar;w:\\dlc\\java\\sonicMQ\\lib\\jnd
i.jar"
"JVMEXE"="java"
"JVMARGS"="-ms8m"
"JAVAPOLICY"="w:\\dlc\\java\\java.policy"
[…\SOFTWARE\PSC\Progress\9.1C\Startup]
"V6Display"="no"
"DefaultFont"="MS Sans Serif, size=8"
"DefaultFixedFont"="Courier New, size=8"
"DLC"="w:\\dlc"
"Use-3D-Size"="Yes"
"PROBUILD"="w:\\dlc\\PROBUILD"
"PROPATH"=".,w:\\dlc\\gui,w:\\dlc,w:\\dlc\\bin,w:\\dlc\\PROBUILD\\EUCAPP\\EUC.PL,w:\\dlc\\PROBUILD\\EUCAPP"
"UseSourceEditor"="yes"
"EditorConfigPath"="d:\\work\\91c\\proedit"
.
.
.
4.2.2.2. The Progress.ini File

The Progress.ini file contains all the entries available in the Windows registry plus some additional ones.
They are all listed below. The additional entries are not relevant to the Progress server processes. The
sections that impact the SQL92 server are shown in bold:
• Startup
• Colors
• Default Window
• Fonts
• WinChar Startup
• WinChar Colors
• WinChar Default Window
• WinChar Keys
• Debug-Init
• Debug-Macros
• Debug-Buttons
• ProADE
• Proedit
• RBStartup
• ReportBuilderSaveList
• ReportBuilderPreferences
• ReportBuilderDefaults
• JAVA
35
The JAVA section contains the definition of the Java-related environment variables and the Startup section
contains the other environment settings with the exception of the LIB and PROMSGS variables that are reset
by default. The PATH variable should be set in the Windows environment.
Important Note: if the Progress environment needs to be modified, the modification should be done in the
Progress.ini file and later on that file should be transferred to the Windows registry using the Progress
ini2reg utility (see section 4.3.2). Before modifying the Progress.ini file, make sure a backup copy is
available.
Below is an excerpt from the Progress.ini after a local installation in the W:\dlc directory of Progress 9.1C.
The Progress SQL92 server specifically accesses the variables and keys marked in bold.
[Startup]
V6Display=no
;ImmediateDisplay=yes
;MultitaskingInterval=100
DefaultFont=MS Sans Serif, size=8
DefaultFixedFont=Courier New, size=8
DLC=w:\dlc
Use-3D-Size=Yes
PROBUILD=w:\dlc\PROBUILD
PROPATH=.,w:\dlc\gui,w:\dlc,w:\dlc\bin,w:\dlc\PROBUILD\EUCAPP\EUC.PL,w:\dlc\PROBUILD\EUCAPP
UseSourceEditor=yes
EditorConfigPath=d:\work\91c\proedit
.
.
.
; This section defines the Java environment.

[JAVA]
JDKHOME=w:\dlc\jdk
JREHOME=w:\dlc\jre
JRECP=w:\dlc\jre\lib\rt.jar;w:\dlc\jre\lib\i18n.jar
JDKCP=w:\dlc\jdk\lib\tools.jar
FATHOMCP=
ProgressCP=w:\dlc\java\Progress.zip;w:\dlc\java\sonicMQ\lib\client.jar;w:\dlc\java\sonicMQ\lib\jndi.jar
JVMEXE=java
JVMARGS=-ms8m
JAVAPOLICY=w:\dlc\java\java.policy
4.2.2.3. The PROENV Shortcut

Under Windows, Progress provides a default command-line environment: accessible directly from the
Progress Start menu. This shortcut is called “Proenv” and calls a .bat file (proenv.bat available under
%DLC%\bin) in charge of setting a basic Progress environment in which basic command-line functions can
be performed.
Unfortunately, the Java-related environment and the shared-library-related environment are not set with this
script. This slightly limits the functionality offered under this environment but is still very useful when
starting a Progress process from the command prompt.
To improve this script and offer access to more functionality (for instance enable reuse of scripts developed
with former Progress versions for database startup procedures that were calling the _mprosrv executables) a
modified version of this script (below) is required.
This original script is usually used to set up a command-line environment with basic settings. The modified
version can be used as a base to develop environment scripts or other database startup / shutdown scripts.
(Keep a copy of the original before making any modifications.)
36
This modified script is enhanced with the items marked in bold. Those items will set the required Java
environment and shared library environment to have a fully functional SQL92 server.
# proenv
DLC="/usr1/v91A05/dlc"
WRKDIR="/usr1/v91A05/wrk"
PATH=$DLC/bin:$PATH
PS1="proenv>"
export DLC WRKDIR PATH PS1
# set the Progress shared lib environment

if [ ! -f $DLC/bin/slib_env ]
then
echo "slib_env could not be found."
echo
echo "Progress shared library environment not set correctly."
echo "Progress DLC environment variable may not be set correctly."
echo "Set DLC variable to Progress installation directory."
echo
echo "Progress DLC setting: $DLC"
echo
exit 1
fi
# Set the Progress Shared lib environment

. $DLC/bin/slib_env
# set the java environment

if [ ! -f $DLC/bin/java_env ]
then
echo "Java Environment not found, using Java free environment"
exec /bin/sh
exit 0
fi
# Set the Java environment

. $DLC/bin/java_env
# start up a new shell

exec /bin/sh
4.3. Moving the JDK into another Directory
Some of the tasks required when administrating a machine where Progress 9.1a, b, c or d is installed are:
• Moving an installed JDK from one directory to another directory (for space management reasons)
• Upgrading a JDK from one release to the next release (although Progress supports and tested only the
JDK versions listed in this white paper, the Progress Installation and Configuration Guide, or the
Progress Release Notes).
Basically, all the operations affecting either the install location of a Progress product or the JDK it requires
to be fully functional result in modifications to the environment used by Progress processes such as the
SQL92 server.
This section explains how to maintain the environment in use by Progress and suggests guidelines or best
practices to achieve the type of modification mentioned above. However for the sake of clarity, we will
present only one example in detail: moving the JDK from one directory to another directory under Microsoft
Windows-based operating systems and UNIX-based operating systems.
37
4.3.1. Under UNIX
After moving the JDK to another directory, modify the $DLC/bin/java_env with the new information.
This simply means that you need to update the following environment variables in the java_env file or in
your custom scripts:
• JDKHOME
• JREHOME
• JDKCP
• JRECP
• CLASSPATH
4.3.2. Under Windows
This example assumes:

• Progress 9.1c is installed in W:\DLC.
• The JDK has been installed with Progress under W:\DLC\jdk.
The goal:
• Move the JDK to C:\JDK.
The steps to follow:

1. Make a backup copy of your progress.ini file (located in %DLC%\bin).
2. Open your Progress.ini file in any editor.
3. Modify the entries in the JAVA section (at the end of the .ini file) to point to the new location of the JDK.
The values that need to be updated are defined by the following variables:
• JDKHOME
• JREHOME
• JDKCP
• JRECP
• CLASSPATH
4. Save the updated Progress.ini file in the %DLC%\bin directory.
5. Transfer the Progress.ini file into the Windows registry system using the ini2reg.exe utility.
6. Remove the extra copy of the JRE located under W:\DLC (as the JDK already contains the JRE).
38
5. SQL92 Server Administration

This section describes the different ways to start and stop SQL92 servers on a Progress database followed by
some guidelines to allow a better management of the different server processes in each case. One of the main
functionalities available with Progress is the ability to start different brokers on the same database. The best
practices section takes full advantage of this functionality to help differentiate as much as possible 4GL and
SQL92 servers running against a single Progress database.
5.1. Starting and Stopping the SQL92 Server
Progress Version 9 offers four ways to start and manage database servers, regardless if they are serving 4GL
or SQL92 clients. These are:
• Through the Progress Explorer and the Admin Service
• Through the command-line interface to the Progress Admin Service
• Through the Progress proserve script
• Starting the Progress _mprosrv executable directly
We will review each of these techniques for starting Progress database servers in the next sections.
The methods provided above are presented in order of increasing difficulty. This means that the first method
presented is the easiest to use, and the last one is the most difficult to use.
Each section gives additional information trying to identify requirements (in terms of installed products and
their usage, knowledge required to use them).
5.1.1. Using the Progress Explorer and the Admin Service
This section describes the usage of the Progress Explorer in combination with the Progress Administration
Server.
The Progress Explorer is the graphical interface to the Administration Server. This utility is only provided
under Windows operating systems. It is the only way to properly configure processes handled by and from
the Administration Server.
The Administration Server is provided on all operating systems where a database license (such as Personal,
Workgroup, or Enterprise licenses) can be installed. This means that this process can be started on the
machine where the Progress Explorer is installed (for instance Windows operating systems) or a remote
machine where the Progress Explorer is not installed (for instance, on UNIX-based operating systems).
Because of the different architectural choices you can make and because the Progress Explorer is only
available on Windows operating systems, there is no requirement to have both elements running on the same
machine. In fact, a good practice is to have a specific Windows machine dedicated to the use of the Progress
Explorer where you should perform all the administration tasks (configuration / maintenance / starting and
stopping processes) for all the databases available through your local network. In this way you have a central
point to perform any task required by your databases.
These are the prerequisites to verify before defining the configuration:

• The Progress Database Server:
o The SQL92 server executable (_sqlsrv2 located in $DLC\bin under UNIX or %DLC%/bin
under Windows) is installed on each machine hosting one or more database for which you want
to provide SQL access.
39
• The Progress Administration Server:

o The Administration Server is installed on each machine hosting one or more database and
server processes (regardless if they are 4GL or SQL92 servers).
o The Administration Server has been started. Please refer to the following sections in your
Progress documentation for more information on how to start the Progress Administration
Server:
If your Administration Server is installed under UNIX, “Progress Installation and
Configuration Guide Version 9 for UNIX” Section 8: Configuring Progress Unified
Broker Products.
If your Administration Server is installed under Windows, “Progress Installation and
Configuration Guide Version 9 for Windows” Section 7: Configuring Progress
Unified Broker Products.
• The Progress Explorer:

o The Explorer is installed on a machine running a Windows operating system with the proper
Progress license.
o The Explorer is installed on the machine from which most of the database administration tasks
are performed.
o The Explorer is connected to the Administration Server on which you want to configure and
administrate your different database local to the Administration Server. Please refer to the
following sections in your Progress documentation for more information on the Progress
Explorer Framework and how it works:
“Progress Database Administration Guide and Reference” Section 5.1: The Progress
Explorer Framework
The appendix of this white paper contains an equivalence table between Progress
Explorer entries, conmgr.properties entries and proserve command-line parameters.
To connect to an existing Administration Server from the Progress Explorer and create a database
configuration, please refer to the Progress Explorer online Help (or more directly, open the file called:
proexp.chm, located under %DLC%\prohelp\html\). In this online help, check mainly the following sections:
• Getting Started with the Progress Explorer
• Database Configuration and Administration
Example of a simple configuration to start an SQL92 broker with the Progress Explorer:
• Start your Progress Explorer.
• Connect a running Administration Server (local or remote).

o To connect to a running Administration Server from the Progress Explorer please refer to the
Progress Explorer online Help. In this online Help, check mainly the following section:
- Getting Started with the Progress Explorer / Connecting to an AdminServer
• Create a new entry under the Database Node. (Expand the AdminServer node that you just connected.):
o You will need to provide:
- A name for this group of database configuration
- The complete database path as seen by the Administration Server
40
o For a complete description of how to create a new database entry from your Progress Explorer
session, please refer to the Progress Explorer online Help. Check the following section:
- Database Configuration and Administration / Adding a Database to the Progress Explorer
• At this stage, Progress has immediately created a default configuration for your database. This
configuration contains the default server group. The properties of the Default configuration should be
modified depending on what you are trying to achieve. (Details about modifying a default configuration
are beyond the scope of this white paper.)
• Edit the properties of your default server group and add the following values:
o Service Name or Port Number: 5000 (or any other number above 1024 that is not used by any other
process running on your machine)
o Number of Server: 5 to allow at least 5 SQL92 servers to start on your database (or any number
above 1)
• Save your changes.
• Start your default configuration by selecting the Default Configuration, right-clicking, and selecting Start
in the pop-up menu.
You have now started the Progress broker (with a specific service) on the machine where the Administration
Server is running. This broker is ready to handle SQL92 connections as well as 4GL connections.
Note: If you wish to test the SQL92 server and therefore establish a simple SQL92 connection, please refer
to the “Progress SQL92 Guide and Reference” Section 1.5: Progress SQL Explorer.
Conclusion:
This method is the easiest and simplest to use when starting to configure and administrate the Progress
SQL92 server. It provides good control over the architecture you may want to put in place and provides a
flexible interface. It also gives good control over the server processes providing ways to perform most of the
tasks required by database administration. However, it does not offer the possibility to build your own
scripts to start the database server processes.
This method requires the use of the Progress Administration Server on the machine where your database is
located and the Progress Explorer on a PC running a Windows based operating system. These two additional
components need to be installed before using them.
Complex or subtle database administration tasks require some practice to fully understand how they work
together and master the possibilities they offer as a database administration framework.
Note: If you cannot find the Administration Server or the Progress Explorer on your machine, please refer to
the Appendix. A table gives you, for each existing Progress licenses, additional information about the
installation of the Progress Explorer and the Administration Server.
5.1.2. Using the Command-line Interface to the Admin Service
This section describes the usage of the command-line interface (dbman) to the Progress Administration
Server, which is always provided on all operating systems where a database license (such as Personal,
Workgroup or Enterprise licenses) can be installed.
The command-line interface accesses a running Administration Server through its listening port number,
which means that its available and usable from a session running on the machine were the Administration
Server has been started or from an other machine. However this utility is always provided on the machine
where the Administration Server is installed. It is a simple way to manage databases within the
Administration Server framework.
41
The configuration available through an Administration Server must be defined and stored in the Progress
file: conmgr.properties (usually located under %dlc%\properties or $DLC/properties). The command line
interface to the Administration Server (dbman) does not offer an interface to update this file.
The tool to use to maintain the conmgr.properties file is the Progress Explorer. Progress strongly
recommends using this tool to modify this file rather than doing it manually. However, in some extreme
circumstances, you may need to update this file manually within a text editor (for instance when you do not
have any machine with the Progress Explorer installed). Because of manual modification of and possible
typos in the conmgr.properties file and its specific requirements described below, we cannot guarantee that
the configurations you manually define / modify in the conmgr.properties file will be working.
The conmgr.properties file is not operating-system dependant; it has the same structure on all operating
systems. In fact, the only point that will differ between UNIX and Windows operating systems is the way
you provide the path to a specific file or directory (such as the database file). This means that you can do the
operations described here under UNIX as well as under Windows operating systems.
Starting a database server with this technique is basically a two-step operation that we will expand on later
on:
• Edit the conmgr.properties file to create a new configuration or update an existing configuration.
• Use the command-line interface to the Administration Server to start and stop the database
processes.
These are the prerequisites to verify before defining or modifying a configuration and starting / stopping the
database processes:
• The Progress Administration Server:

o The Admin Service is installed on each machine hosting one or more database and server
processes (regardless if they are 4GL or SQL92 servers).
o The Admin Service has been started. Please refer to the following sections in your Progress
documentation for more information on how to start the Progress Administration Server:
Broker Products.
• The conmgr.properties file:

o Understand the structure of this file so that you can easily modify it and maintain your own
entries. For more information on this subject please check:
The “Progress Database Administration Guide and Reference” Section 5: Starting
Up and Shutting Down.
The conmgr.properties file, which contains information about the different entries that
can be used within each section.
42
The appendix of this white paper contains an equivalence table between Progress
Explorer entries, conmgr.properties entries, and proserve command-line parameters.
• The command-line session:

o This can be one of the following type of sessions:
Telnet on the UNIX machine, preferably where you have installed and started the
Administration Server.
The console of the UNIX machine, preferably where you have installed and started
A command prompt on the Windows machine, preferably where you have installed
and started the Administration Server.
o Must have the complete Progress environment. To make sure all environment variables are
properly defined, please refer to sections 4.1 or 4.2 depending on the operating system running
on the machine where you have started your command prompt.
Example of a simple configuration to start an SQL92 broker with the command line interface to the
Progress Administration Server:
• Start a command-line session on the machine where the Administration server is running.
• Make a copy of the conmgr.properties file located in %DLC%\properties or $DLC/properties. Name the
copy conmgr.properties.back and edit the original conmgr.properties file.
• Create a new section in the conmgr.properties file by copying the following section under the last section
marked as [database.<A name>]. This section defines the key elements that are associated with a
physical database. The name used for this section is always based on the following template:
[database.<A name>]
[database.whitepaper]
configurations=whitepaper.defaultconfiguration
databasename=D:\Work\91c\db\sports
defaultconfiguration=whitepaper.defaultconfiguration
displayname=WhitePaper
• The required entries in this section are:

o The ‘configurations’ entry is a coma-separated list defining all the different configurations that you
would create for a single database. The names used are always composed of the concatenation of the
database (used in the name of this section) and a unique name defining the configuration separated
by a point.
o The ‘databasename’ entry provides the complete path to the database (excluding the .db extension)
Note: Under UNIX, you would have to specify something like /users/work/91c/db/sports.
o The ‘defaultconfiguration’ entry specifies which of the configuration declared under the
‘configurations’ entry is the default one.
o The ‘displayname’ entry contains the name to display in the Progress Explorer when maintaining
entries managed from the Administration Server using this conmgr.properties file. This name is
usually extracted from the name of the section.
• Create a new entry in the conmgr.properties file (located under %DLC%\properties or $DLC/properties)
by copying the following section under the last section marked as [configuration.<A name>.<A
configuration name>]. We are now providing the required information for the only configuration
43
(whitepaper.defaultconfiguration) that has been declared with the information previously added to the
conmgr.properties file. The name used for this section is always based on the following template:
[configuration.<A name>.<A configuration name>] where the combination <A Name>. <A
configuration name> is declared in the ‘configurations’ entry provided in the previous section.
[configuration.whitepaper.defaultconfiguration]
database=whitepaper
displayname=defaultConfiguration
servergroups=whitepaper.defaultconfiguration.defaultservergroup

o The ‘database’ entry is a repeat of the name of the database name used when we added the section
[database.whitepaper] to the conmgr.properties file. It informs the Administration Server about the
fact that this Configuration section is declared in the mentioned database section.
o The ‘displayname’ entry simply states the name to display in the Progress Explorer when
administrating the different configurations for this specific database. This name is usually extracted
from the name of this section.
o The ‘servergroups’ entry is a coma-separated list defining all different groups of servers that you
would create for a single configuration. The names used are always composed of the concatenation
of the database name (used in the name of this section), the configuration name (under which this
Server Group is declared), and a unique name defining the server group name separated by a point.
• Create a new sub-section (in the [environment] section) in the conmgr.properties file by copying the
following section under the last section marked as [servergroup.<A name>.<A configuration name>.<A
Server Group name]. This section defines the settings specific to your Server group. The name used for
this section is always based on the following template: [servergroup.<A name>.<A configuration
name>.<A server group name>] where the combination <A Name>.<A configuration name><A server
group name> is declared in the ‘servergroups’ entry provided in the previous section.
[servergroup.whitepaper.defaultconfiguration.defaultservergroup]
configuration=whitepaper.defaultconfiguration
displayname=defaultServerGroup
numberofservers=5
port=5000

o The ‘configuration’ entry is a repeat of the name of the configuration name used when we added the
section [configuration.whitepaper.defaultconfiguration] to the conmgr.properties file. It informs the
Administration Server about the fact that this Servergroup section is declared in the mentioned
Configuration section.
administrating the different server groups for this specific configuration. This name is usually
extracted from the name of this section.
o The ‘numberofservers’ entry specifies the maximum number of servers (4GL and SQL92) this
server group can start.
o The ‘port’ entry specifies the port number on which the broker configured here will listen for client
server connections.
• At this stage you should have created a default configuration for your database. This configuration
contains the default server group. The properties of the Default servergroup should be modified
44
depending on what you are trying to achieve, however, those instructions are beyond the scope of this
white paper.
• Stop and restart your Administration Server to reload the new conmgr.properties file.
• Issue the following command to start the database server:

o dbman -database WhitePaper -config defaultConfiguration –start
o For more information on the dbman command please refer to the “Progress Database
Administration Guide and Reference” Section 18: Database Administration Utilities.
You have now started the Progress broker (with a specific service) on the machine where the Administration
Server is running. This broker is ready to handle SQL92 connections as well as 4GL connections.
Note: If you wish to test the SQL92 server and therefore establish a simple SQL92 connection, please refer
to the “Progress SQL92 Guide and Reference” section 1.5: Progress SQL Explorer
Conclusion:
This method is easy to use for starting and stopping a defined configuration. However, manually defining
configurations in the conmgr.properties file is not a simple task and should never be attempted by someone
new to Progress.
With regards to defining new configurations:

• Someone new to Progress should always define new configurations and perform administration tasks
from the Progress Explorer (see the previous section).
• Advanced users, or at least users very familiar with the Administration Server framework and more
specifically the structure of the conmgr.properties file, can use this method, although it remains tricky to
define a new configuration in the conmgr.properties file. Defining and maintaining entries in the
conmgr.properties is much easier when done from the Progress Explorer.
With regards to starting and stopping existing configurations:

• The best point about the command-line interface is that it allows writing your own scripts for starting and
stopping database servers at predefined times.
• It only requires the Progress Administration Server up and running on the machine where your database
is located and your own scripts to start and stop predefined configurations.
• Your scripts should also contain the required Progress environment or call the environment files Progress
provides (see section 4.1 and 4.2 in this document for more information).
Note: If you cannot find the Administration Server on your machine, please refer to the Appendix. A
table gives you, for each existing Progress licenses, additional information about the installation of the
5.1.3. Using the Progress proserve Script
The goal of this section is to describe how to start a database server from the proenv (or your customized
Progress environment) and use the proserve script provided with a Progress installation.
From this interface you can create your own startup scripts so that your databases are configured in the most
efficient way and according to your exact needs.
Within this environment you gain some additional control over the actual SQL92 server process and you
have access to some environment variables that can be set specifically for the server process started through
your current environment (for instance, SQLREUSE).
45
The prerequisites are:

• The Progress database server.
• The SQL92 server installed on the machine where the database is located.
5.1.4. Using the _mprosrv Executable in a Custom Script
The goal of this section is to describe how to start a database server from your customized Progress
environment (or the Progress proenv script) and start your database server by directly calling the _mprosrv
executable.
From this interface you can create your own startup scripts so that your databases are configured in the most
efficient way and according to your exact needs.
Within the context defined here, please note that you are in charge of making sure that the complete Progress
environment has been properly defined before starting the database server. In this environment you have full
control over the actual SQL92 server process. You are in charge of, and responsible for, defining everything.
The prerequisites are:

• The Progress database server.
• The SQL92 Server installed on the machine where the database is located.
5.2. Best Practices: Some Guidelines
We just covered in the previous section the different ways to start and stop a database server. This section
describes which parameters have particular impact on the Progress SQL92 database server and how to use
them effectively.
To achieve this goal we will need to review the different types of parameters that are available with Progress
9.1. Then we will attempt to define criteria to help administrate the database to the best possible standards
and define how to set up the parameter values based on your production environment and requirements. Two
setup examples show how to apply these guidelines.
5.2.1. Server Startup Parameters
The Progress server parameters are grouped into five different categories. Each of those categories defines
specific resources to be used with the database.
The categories of server startup parameters are:

• Database server performance parameters (Example: -B, -L)
• Database server internationalization parameters
• Database server statistics parameters
• Database server network parameters (Example: -N, -S and –H)
• Database server type parameters (Example: -m3 for secondary login broker)
Note: For a list of the parameters in each group, see the Progress Startup Command and Parameter
Reference.
46
These categories of parameters define ‘database access and shared resources’:

• Database server performance parameters
• Database server internationalization parameters
• Database server statistics parameters
They are common to all brokers and servers running on a single physical database. They are set by the first
broker started on the database.
One category of parameters defines ‘database broker resources.’ They define the client access resources
shared by all servers spawned from the broker:
• Database sever network parameters (Example: -Mi, -Mn, -Ma, -minport, -maxport)
In this category you can also find some specific parameters linked to the Admin Service and Java classpath
for SQL92 (Example: -adminport & -classpath).
The database server type parameters can start:

• An Auto Server (-m1 – This is used internally by Progress)
• A single DB server (-m2)
• A secondary login broker (-m3)

The database server type parameters help separate administration tasks for SQL92 and 4GL servers.
5.2.2. Guidelines for Administrating Your Database Servers
Here is a summary of the key points to keep in mind when managing your SQL92 servers:
• Separate as much as possible the client application environment from the server environment
(especially if running on the same machine)
o Separate the SQL92 server from the 4GL server (avoid using the same broker for both
types of connections). Use the –m3 for the secondary login broker if started manually.
o Ensure you know which broker is started first (4GL or SQL) to control easily the database
access shared resources parameters.
• Separate the start of each broker by at least 30 seconds if started from scripts.
• Under a Windows operating system, the ODBC driver uses the same registry keys as the SQL92
server when these are installed on the same machine.
• The Java part of the JDBC driver is only a set of java classes that can be integrated into most
environments (with respect to the minimal JDK level required).
• The minimal environment (for ease of use):

o Under UNIX:
DLC=<where Progress is installed>
PATH= $DLC/bin:$PATH
o Under Windows:
DLC=<where Progress is installed>
PATH=%DLC%\bin;%PATH%
o Specific to JDBC connections:
47
CLASSPATH
JREHOME
• Avoid starting the database server with the executable: _mprosrv.
• Ensure that the environment is set up in the Progress scripts.

• Keep backups of the original files before modification.
48
A Appendix
A.1 Progress Licenses That Install the Progress Explorer and

Administration Server
This table gives you the complete list of licenses available. For each of those licenses it informs you if the
Progress Administration Server or the Progress Explorer is installed.
Is the Administration Is the Progress Explorer
Progress Product License Server installed with this installed with this license
license? under Windows?
4GL Development Yes Yes
AppServer Internet Adapter No No
AppServer Internet Adapter/S No No
AppServer Load Balancing Option No No
Client Networking No No
Client-side Security No No
Debugger No No
Enterprise Database Yes Yes
ESQL-89/C No No
NameServer Yes Yes
NameServer Enterprise Edition Yes Yes
ODBC Enterprise DataServer* Yes Yes
ODBC Personal DataServer* No No
Open Client Toolkit* No No
Oracle DataServer Yes Yes
Personal Database Yes Yes
Progress AppServer Yes Yes
ProVision* Yes Yes
ProVision Development Server Yes Yes
ProVision Plus* Yes Yes
49
Is the Administration Is the Progress Explorer

Progress Product License Server installed with this installed with this license
license? under Windows?
ProVision Plus Development Server Yes Yes
Query/Results No No
Report Builder* No No
Secure AppServer Yes Yes
SonicMQ Adapter Yes Yes
SQL Server Enterprise* Yes Yes
SQL Server Personal* No No
SQL-92 Client Access No Yes
Toolkit No No
Translation Manager* No No
Visual Translator* No No
WebClient* No No
WebSpeed Development Server Yes Yes
WebSpeed Enterprise Transaction Server Yes Yes
WebSpeed Messenger No No
WebSpeed Transaction Server Yes Yes
WebSpeed Workshop* Yes Yes
Workgroup Database Yes Yes
(*) This license is available only under Windows operating systems
Note: To make sure that the Progress Explorer and/or the Administration Server are installed on your
machine, you must perform a Typical or Complete Installation of one of the licenses that provides these
components.
50
A.2 Manually Modifying the conmgr.properties File
The operations described here can be performed under UNIX as well as Windows operating systems. The only
noticeable difference with regards to the conmgr.propreties on both operating system types is the way a PATH is
specified.
These are the prerequisites to verify before defining or modifying a configuration in the conmgr.properties file:
• The Progress Administration Server (This ensures that the conmgr.properties file is available on the
machine where you will attempt this modification.):
o The Admin Service is installed on each machine hosting one or more database and server
processes (regardless if they are 4GL or SQL92 servers).
o The Admin Service is usable on this machine. Please refer to the following sections in your
Progress documentation for more information on how to start the Progress Administration
Server:
Broker Products.
• The conmgr.properties file:

o Understand the structure of this file so that you can easily modify it and maintain your own
entries. For more information on this subject, please check:
The “Progress Database Administration Guide and Reference” Section 5: Starting
Up and Shutting Down.
The conmgr.properties file, which contains information about the different entries that
can be used within each section.
The following section of this white paper that contains an equivalence table between
Progress Explorer entries, conmgr.properties entries, and proserve command-line
parameters.
• The command-line session (used to perform the modification in the conmgr.properties):

o This can be one of the following type of sessions:
Telnet on the UNIX machine, preferably where you have installed and started the
The console of the UNIX machine, preferably where you have installed and started
51
A command prompt on the Windows machine, preferably where you have installed
and started the Administration Server.
o Must have the complete Progress environment. To make sure all environment variables are
properly defined, please refer to sections 4.1 or 4.2 depending on the operating system running
on the machine where you have started your command prompt.
Example of a new configuration created in the conmgr.properties with a text file editor:
• Start a command-line session on the machine where the Administration server is running.
• Make a copy of the conmgr.properties file located in %DLC%\properties or $DLC/properties. Name the
copy conmgr.properties.back and edit the original conmgr.properties file. It should look as follows as
there were no configurations defined in my conmgr.properties file when I wrote this white paper.
#
# Connection Manager Properties File
#
%% Juniper Properties File
%% version 1.1
%% 01-Apr-90 4:02:09 PM
• Create a new section in the conmgr.properties file by copying the following section under the last section
marked as [database.<A name>]. If you started with a blank conmgr.properties file, please check the
conmgr.propreties file provided at the end of this section.
• This part of the file defines the key elements that are associated with a physical database. The name used
for this sections is always based on the following template: [database.<A name>]
• The required entries are:

o The ‘configurations’ entry is a coma-separated list defining all different configurations that you
would create for a single database. The names used are always composed of the concatenation of the
database (used in the name of this section) and a unique name defining the configuration separated
by a point.
o The ‘databasename’ entry provides the complete path to the database (excluding the .db extension).
– Note: under UNIX you would have to specify something like /users/work/91c/db/sports.
o The ‘defaultconfiguration’ entry specifies which of the configuration declared under the
‘configurations’ entry is the default one.
o The ‘displayname’ entry contains the name to display in the Progress Explorer when maintaining
entries managed from the Administration Server using this conmgr.properties file. This name is
usually extracted from the name of the section.
• For optional entries in this section, please refer to the table of equivalence between Progress Explorer
and conmgr.properties, which presents every possible entry in the conmgr.properties file.
52
• Create a new entry in the conmgr.properties file (located under %DLC%\properties or $DLC/properties)
by copying the following section under the last section marked as [configuration. <A name>.<A
configuration name>]. If you started with a blank conmgr.properties file, please check the
conmgr.propreties file provided at the end of this section.
• We are now providing the required information for the only configuration
(whitepaper.defaultconfiguration) that has been declared with the information previously added to the
conmgr.properties file. The name used for this section is always based on the following template:
[configuration. <A name>.<A configuration name>] where the combination <A Name>.<A
configuration name> is declared in the ‘configurations’ entry provided in the previous section.
database=whitepaper

o The ‘database’ entry is a repeat of the name of the database name used when we added the section
[database.whitepaper] to the conmgr.properties file. It informs the Administration Server about the
fact that this Configuration section is declared in the mentioned database section.
administrating the different configurations for this specific database. This name is usually extracted
from the name of this section.
o The ‘servergroups’ entry is a coma-separated list defining all different groups of server that you
would create for a single configuration. The names used are always composed of the concatenation
of the databasename (used in the name of this section), the configuration name (under which this
Server Group is declared) and a unique name defining the server group name separated by a point.
• For optional entries in this section, please refer to the table of equivalence between Progress Explorer
and conmgr.properties, which presents every possible entry in the conmgr.properties file.
• Create a new sub-section (after the [environment] section flag) in the conmgr.properties file by copying
the following section under the last section marked as [servergroup.<A name>.<A configuration
name>.<A Server Group name]. If you started with a blank conmgr.properties file, please check the
conmgr.propreties provided at the end of this section.
• This section defines the settings specific to your Server group. The name used for this section is always
based on the following template: [servergroup.<A name>.<A configuration name>.<A server group
name>] where the combination <A Name>.<A configuration name><A server group name> is declared
in the ‘servergroups’ entry provided in the previous section.
numberofservers=5
port=5000

o The ‘configuration’ entry is a repeat of the name of the configuration name used when we added the
section [configuration.whitepaper.defaultconfiguration] to the conmgr.properties file. It informs the
Administration Server about the fact that this Servergroup section is declared in the mentioned
Configuration section.
53
administrating the different server groups for this specific configuration. This name is usually
extracted from the name of this section.
o The ‘numberofservers’ entry specifies the maximum number of servers (4GL and SQL92) this
server group can start.
o The ‘port’ entry specifies the port number on which the broker configured here will listen for client
server connections.
• For optional entries in this section please refer to the table of equivalence between Progress Explorer and
conmgr.properties, which presents every possible entry in the conmgr.properties file.
• At this stage you should have created a default configuration for your database. This configuration
contains the default server group. The properties of the Default servergroups should be modified
depending on what you are trying to achieve, however those instructions are beyond the scope of this
white paper.
• Stop and restart your Administration Server to reload the new conmgr.properties file.
In other words, after all the modifications described above, your conmgr.properties should like this:
#
# Connection Manager Properties File
#
%% Properties File
%% version 1.1
%% May 5, 2002 4:32:05 PM
database=whitepaper
[environment]
numberofservers=5
port=5000
Once more, this manual modification is difficult. Attempting it can create more problems than help solve them. As
a result, a person new to Progress should never attempt this modification. Only an advanced DBA should attempt
it.
54
A.3 Table of Equivalence between Progress Explorer Entries,

conmgr.properties Entries and proserve Command-line Parameters
Progress Explorer entries Conmgr.properties entries Command-line startup parameter
In the [database.<A database name>]

Under the Databases node
section
Sub-node name displayname= Not Applicable
Properties of the sub-node
Path and file name of database databasename= -db
Selection list configurations= Not Applicable
Automatically start this database

autostart= Not Applicable
when the AdminServer is started
Not Applicable defaultconfiguration= Not Applicable
Under the Configurations node for In the [configuration.<A database

a specific database: a name>.<A configuration name>]
configuration node section
Not Applicable Beforeimagebufferedwrites -r
Not Applicable databasecodepage= -cpdb
Not Applicable semaphoresets= -semsets
Not Applicable sqlyearoffset= -yy
In the General Section
# Blocks in DB buffer blocksindatabasebuffers= -B
# Hash table entries hashtableentries= -hash
# Lock table entries locktableentries= -L
Maximum users maxusers= -n
Maximum servers maxservers= -Mn
Any other database startup

Other server Arguments otherargs=
parameter not listed in this column
Apply cash Protection crashprotection= -I
Employ direct I/O directio= -directio
In the Background Writers section
55
Watchdog: Auto startup watchdogprocess= Not Applicable
Asynchronous page writers: # of

asynchronouspagewriters= Not Applicable
APW’s to start
Before-image Writer: Auto startup beforeimageprocess= Not Applicable
Before-image Writer: Buffers beforeimagebuffers= -bibufs
Before-image Writer:bi threshold bithold= Not Applicable
Before-image Writer: Before image

beforeimagestall= Not Applicable
stall
Before-image Writer: delay writes beforeimageclusterage= -G
Before-image Writer: cluster age beforeimagedelaywrites= -Mf
After-image Writer: Auto startup afterimageprocess= Not Applicable
After-image Writer: After-image stall afterimagestall= -aistall
After-image Writer: buffers afterimagebuffers= -aibufs
In the International section
Collation table (-cpcoll) collationtable= -cpcoll
Case table (-cpcase) casetablename= -cpcase
Conversion map (-convmap) conversionmap= -convmap
Server code page (-cpinternal) internalcodepage= -cpinternal
Log code page (-cplog) logcharacterset= -cplog
In the Advanced section
General: Shared-memory overflow

sharedmemoryoverflowsize= -Mxs
size
General: Spin lock retries spinlockretries= -spin
Page writer: Page writer queue delay pagewriterqueuedelay= -pwqdelay
Page writer: Page writer queue

pagewriterqueuemin= -pwqmin
minimum
Page writer: Page writer scan pagewriterscan= -pwscan
Page writer: Page writer scan delay pagewriterscandelay= -pwsdelay
Page writer: Page writer maximum

pagewritermaxbuffers= -pwwmax
buffers
Lock delays: Nap interval Nap= -nap
Lock delays: Nap maximum interval napmax= -napmax
56
In the [servergroup.<A database

Under a pre-defined configuration
name>.<A configuration name>.<A
node: a Servergroup Node
server group name>] section
Client type type= -servertype
General: Service name or port

port= -S
number
General: Number of servers numberofservers= -Mpb
General: Message buffer size messagebuffersize= -Mm
General: Reporting interval reportinginterval= -rpint
Clients: Maximum client per server maxclientsperserver= -Ma
Clients: Minimum clients per server minclientperserver= -Mi
Ports: Maximum dynamic port maxdynamicport= -maxport
Ports:Minimum dynamic port mindynamicport= -miniport
Notes:
• Each entry stating “Not Applicable” in the Command line startup parameter column means in fact
that this Progress Explorer/conmgr.property triggers a command line to start a process, it is a specific
label used internally to bundle everything together, or because these are properties specific to the
Administration server when describing configurations. These have no equivalent in command-line
parameters.
• For each parameter listed in the Command line startup parameter column, the values you can use are
documented in the Progress Startup Command and Parameter Reference manual. However for some
specific entries, values are listed here:
o –server type is command-line startup parameter only available starting with Version 9.1D.
Values to use are: 4gl, sql or both.
• For each parameter listed in the Conmgr.properties entries column, the values you can use are
documented in the Progress Startup Command and Parameter Reference. However, for some specific
entries, values are listed here:
o afterimageprocess= takes the following values: “true” or “false”.
o beforeimagestall=
o bithold= takes a positive integer.
o beforeimageprocess= takes the following values: “true” or “false”.
o asynchronouspagewriters= takes the following values: “true” or “false”.
o watchdogprocess= takes the following values: “true” or “false”.
o autostart= takes the following values: “true” or “false”.
57
Corporate and North AmericanHeadquarters

Progress Software Corporation, 14 Oak Park, Bedford, MA 01730 USA Tel: 781 280 4000 Fax: 781 280 4095
Europe/Middle East/Africa Headquarters

Progress Software Europe B.V. Schorpioenstraat 67 3067 GG Rotterdam, The Netherlands Tel: 31 10 286 5700 Fax: 31 10
286 5777
Latin American Headquarters

Progress Software Corporation, 2255 Glades Road, One Boca Place, Suite 300 E, Boca Raton, FL 33431 USA Tel: 561 998
2244 Fax: 561 998 1573
Asia/Pacific Headquarters www.Progress.com

Progress Software Pty. Ltd., 1911 Malvern Road, Malvern East, 3145, Australia Tel: 61 39 885 0544 Fax: 61 39 885 9473
Specifications subject to change without notice.
Progress is a registered trademark of Progress Software Corporation. All other trademarks, marked and not marked, are the © 2002 Progress Software Corporation.
property of their respective owners. All rights reserved.
58

sql92 Ica

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

sql92 Ica

Încărcat de

Drepturi de autor:

Formate disponibile

Progress SQL92 Server: Installation,

Environment and Administration

Sébastien Haefelé, Product Manager,

The goal of this document is to:

2. The Progress SQL92 Server Architecture

2.1. SQL92 Architecture Overview

• An SQL database server

• A client application accessing the database through different interfaces

• Through an ODBC Driver

• Through an ESQL/C Interface

Figure 1: Progress SQL92: Architecture Overview

2.2. Progress General Client/Server Architecture

Figure 2: Progress Client/Server Architecture Overview

2.3. SQL92 Server Internal Architecture

Figure 3: Progress SQL92 Server Internal Architecture

2.3.1. Example 1: Selecting information from an SQL92 client

• A ‘select’ request comes via the network.

• The Communication Manager receives this request.

• The Communication Manager passes the request to the Statement Manager.

2.3.2. Example 2: Inserting new rows with a before insert trigger

• An ‘insert’ request comes via the network.

• The Communication Manager receives this request.

• The Communication Manager passes the request to the Statement Manager.

• The Communication Manager formats it and sends it to the SQL92 client.

2.3.3. Example 3: Creating a stored procedure

• A ‘create stored procedure’ request comes via the network.

• The Communication Manager receives this request.

• The Communication Manager passes the request to the Statement Manager.

• The Communication Manager formats it and sends it to the SQL92 client.

3. The SQL92 Server Installation

3.1. Availability per Operating Systems

Table 1: First availability of the SQL92 server per operating system

Operating System First Progress Version with the SQL92 Server

Citrix MetaFrame 9.1a

Compaq® Tru64 9.1a

DG/UX Intel Not Available

HP-UX® 11 (Prgs 32-bit) 9.1a

HP-UX® 11 (Prgs 64-bit) 9.1b

IBM AIX® 9.1a

Linux Intel 9.1b

SCO OpenServer Not Available

SCO UnixWare® 9.1b

Sun® Solaris™ Intel Not Available

Sun® Solaris™ Sparc 9.1a

Microsoft Windows® 32 Intel 9.1a

3.2. Operating System Prerequisites

3.2.1. Operating System Patches

• The hard-copy Progress Release Notes

• The Progress README file (under $DLC or %DLC%)

Operating System 9.1a 9.1b 9.1c

(1) (1) (1)

(2) (2) (2)

DG/UX Intel Not Available Not Available Not Available

(3) (3) (3)

(3) (3) (3)

(4) (4) (4)

(5) (5) (5)

(5) (5) (5)

(1) (1) (1)

(1) (1) (1)

(1) (1) (1)

3.3. License Requirements

• Progress also installs the JDK during its own installation