Kbase 18212: Version 8.3A Release Notes
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
25/08/1998 |
|
Version 8.3A Release Notes
PROGRESS VERSION 8.3A RELEASE NOTES
August, 1998
Database
PROBKUP Cannot Run When Microsoft NT 3.51 Backup Utility Is Open
Remotely Connecting to a Coordinator Database for Two-phase
Commit
SYSTEM ERROR 1007 with Windows NT Multi-user Mode
Report Builder
No Join Reorder Option Improves Report Builder Performance
Menu and Dialog Errors with Hebrew
Microsoft Windows Operating System
Registry Base Key Is Not Allowed in Parameter Files
Digital UNIX Issues
SQLCODE Variable Must Be SHORT on DBE Digital UNIX
Solaris Issues
SETUSERID Function and Core Dumps on Solaris
ProControl Enhancements
AutoStart Tab
Item Definitions
Error Messages
Add APW Button
Process Priority list
Documentation
FIND Statement Only Uses a Single Index
Internationalization
Double-Byte Character Sets Require Use of UNIX stty -istrip
Option
SYSTEM ERRORS 48 and 49 with Browsers on DBE UNIX Character
Client
DataServer Issues
Dash Not Allowed in SQL CREATE TABLE Statement
PROGRESS DataServer for ODBC Does Not Support DB2 Stored
Procedures
ORACLE Segmentation Fault on HPUX 10.20 and 11.0
Digital NT Clusters
Setting Up PROGRESS to Utilize Digital´s NT Clusters
-------------------------------------------------------------------
Database
PROBKUP cannot run when Microsoft NT 3.51 Backup Utility is open
RELEASE NOTE # 083A-00109
If the Microsoft NT 3.51 Backup Utility is open and you attempt
to run the PROBKUP utility, the system returns an error message
when attempting to access the backup device, usually the tape
drive. To use the PROBKUP utility, close the Microsoft NT 3.51
Backup Utility first.
--------------------------------------------------------------------
Remotely Connecting to a Coordinator Database for Two-phase Commit
RELEASE NOTE # 083A-00200
If the name of the coordinator database being used in a two-phase
commit has more than seven characters, you might not be able to
connect remotely to the coordinator database. There are two
workarounds:
- Use the -tp parameter to assign a two-phase commit nickname
with less than eight characters for the coordinator database.
- Use a logical database name with less than eight characters
for the coordinator database.
--------------------------------------------------------------------
SYSTEM ERROR 1007 with Windows NT Multi-user Mode
RELEASE NOTE # 083A-00201
When running Windows NT in multi-user mode, you might see the
following error:
SYSTEM ERROR: unexpected wakeup from wait code <num>,
user <num> (1007).
This error causes the database server to shut down. The
workaround is to start the database server with the Spin Lock
Retries (-spin 1) startup parameter.
--------------------------------------------------------------------
Report Builder
No Join Reorder Option Improves Report Builder Performance
RELEASE NOTE # 083A-00202
The SQL Engine in Report Builder checks the SQL in reports to
optimize performance. If you are using implicit join syntax for
inner joins, the SQL Engine might change the order in which
tables are listed in the FROM Clause of a SELECT Statement during
optimization. The hierarchy the SQL Engine uses to reorder the
tables might not always produce the best order to query the
database.
For example, the hierarchy ranks a field that is a unique index
as better than a field that is not an index. The SQL engine would
reorder the FROM Clause to query the table with the unique index
field first. However, if the table with the unique index field
contains 500,000 records and the table with the other field
contains 30,000 records, the reordered query is less efficient
than a query that looks at the smaller table first.
You can specify that you do not want the tables to be reordered
by using a new option. If you choose the Database->No Join Reorder
menu item, the SQL Engine does not reorder the tables in an
implicit join. Choosing this option might improve the performance
of your reports.
This option does not work if you use the -rbexpjoins startup
parameter. The -rbexpjoins startup parameter forces Report Builder
to use explicit join syntax for inner joins. See Chapter 3 of the
PROGRESS SQL Guide and Reference for more information on the
differences between implicit and explicit join syntax.
--------------------------------------------------------------------
Menu and Dialog Errors with Hebrew
RELEASE NOTE # 083A-00203
Version 8.3A Report Builder does not display menus and dialogs
correctly in Hebrew using the Hebrew language resource dll,
reshbr32.dll.
--------------------------------------------------------------------
Microsoft Windows Operating System
Registry Base Key is not allowed in parameter files
RELEASE NOTE # 083A-00149
Do not use the Registry Base Key startup parameter (-basekey) in a
parameter file. PROGRESS will not recognize the parameter.
To address this issue, place the -basekey startup parameter,
optionally along with the -ininame startup parameter, directly on
the PROGRESS command line.
--------------------------------------------------------------------
Digital UNIX Issues
SQLCODE Variable Must Be SHORT on DBE Digital UNIX
RELEASE NOTE # 083A-00204
The PROGRESS Embedded SQL Guide and Reference says SQLCODE must be
data type "long". For embedded SQL applications on the Double-byte
Enabled (DBE) Digital UNIX plaform, you must set the data type of
SQLCODE to "short".
For example, when you use the dyndemo.cc sample program in
$DLC/probuild/esqlc, find the following code:
static long SQLCODE;
You must change this to:
static short SQLCODE;
--------------------------------------------------------------------
Solaris Issues
SETUSERID Function and Core Dumps on Solaris
RELEASE NOTE # 083A-00205
Due to a Sun-implemented security feature, Solaris (intel) and
Solaris (sparc) executables will not core dump unless the real
userid matches the SETUSERID.
--------------------------------------------------------------------
ProControl Enhancements
Several enhancements were made to the ProControl utility in
release 8.2C. The ProControl utility will be upward compatible
with previous versions. You may use your current settings with no
changes.
--------------------------------------------------------------------
AutoStart Tab
RELEASE NOTE # 083A-00150
ProControl provides a new tab, AutoStart. This new dialog box
lists all current ProControl entries and allows the user to
specify a startup order for each entry. This setting is saved in
the Windows/NT registry and used by ProService during its AutoStart
processing.
Use the Up and Down buttons to order the startup items as desired.
This specifies the order that ProService will use in attempting to
start the items. This is useful when you desire to start one item,
such as a database before another item, such as an AppServer. Note
that this ordering does not imply any dependencies. ProService
will attempt to start all items in order regardless of the status
of previous items in the autostart list.
By default, all ProControl entries marked as AutoStart via the
AutoStart checkbox on the General configuration page will have a
startup order of 1. A startup order of 0 will indicate no AutoStart
for this entry. Entries with the same startup order will NOT be
processed in any specific order, just as in previous versions.
---------------------------------------------------------------------
Item definitions
RELEASE NOTE # 083A-00151
ProControl item definitions are no longer limited to 24 items.
--------------------------------------------------------------------
Error messages
RELEASE NOTE # 083A-00152
ProControl no longer displays only Win/NT error numbers. All NT
error numbers are now translated into the error text supplied by
Win/NT and displayed.
--------------------------------------------------------------------
Add APW Button
RELEASE NOTE # 083A-00153
ProControl has a new Add APW button on the DB Writers page. This
button is enabled only when the database has been started. When
pressed, this button updates the database definition by
incrementing the number of Asynchronous Page Writers in the field.
It then sends a message to ProService to start an additional APW
process.
--------------------------------------------------------------------
Process Priority list
RELEASE NOTE # 083A-00154
ProControl has a new Process Priority dropdown list on all of its
General pages. This additional information is saved in the
Windows/NT registry and used by ProService when starting the
process associated with this entry.
This setting is used to set the process priority of the resulting
process started by ProService. By default, all NT processes have
"Normal" priority. On a loaded system, a database server may need
to have the priority set to "High" to allow it more processing time
and improve responsiveness. The "Idle" setting may be used for
low priority items to prevent them from taking processing time
away from more important processes.
--------------------------------------------------------------------
Documentation
FIND Statement only uses a single index
RELEASE NOTE # 083A-00156
The PROGRESS Database Design Guide, page 4-18, describes how
PROGRESS will choose multiple indexes when using a compound WHERE
clause and the AND option. This information does not apply to the
FIND statement. The FIND statement will only use a single index.
--------------------------------------------------------------------
Internationalization
Double-Byte Character Sets Require Use of UNIX stty -istrip Option
RELEASE NOTE # 083A-00206
When you use a UNIX character client with double-byte character
sets, your terminal must be set to not strip input characters to
seven bits. Check the settings of your terminal this using the
"stty" command from a UNIX shell. If you do not see the "-istrip"
option listed, enter the command "stty -istrip".
--------------------------------------------------------------------
SYSTEM ERRORS 48 and 49 with Browsers on DBE UNIX Character Client
RELEASE NOTE # 083A-00207
A memory leak might occur on certain platforms running Double-byte
Enabled (DBE) UNIX character clients. When you open and then close
a browser several times during a session, you might see the
following error messages:
SYSTEM ERROR: Bus error. (48)
SYSTEM ERROR: Memory Violation. (49)
This issue has occurred on Solaris 2.6. It might also occur on
other platforms and earlier Version 8 releases.
--------------------------------------------------------------------
DataServer Issues
Dash Not Allowed in SQL CREATE TABLE Statement
RELEASE NOTE # 083A-00208
In SQL, you cannot use the dash (-) character as part of a table
name in a CREATE TABLE statement. For example if you used
"credit-limit" as the name of the table, you might see the
following error:
SQLCODE = -1
** Invalid SQL identifier -LIMIT. (955)
You cannot use the backslash (\) special character or the ESQL
No Padding (-esqlnopad) startup parameter to workaround this issue.
--------------------------------------------------------------------
PROGRESS DataServer for ODBC Does Not Support DB2 Stored Procedures
RELEASE NOTE # 083A-00209
The PROGRESS DataServer for ODBC supports the execution of native
Stored Procedures in a PROGRESS ODBC DataServer session. Because
DB2 Stored Procedures are stored as external objects from the DB2
database and have special procedural and syntactical requirements,
this feature does not currently work for DB2 Stored Procedures.
--------------------------------------------------------------------
ORACLE Segmentation Fault on HPUX 10.20 and 11.0
RELEASE NOTE # 083A-00210
On UNIX, the ORACLE DataServer requires you to build executables
with PROBUILD and link with the ORACLE libraries. (See Chapter 3
of the PROGRESS DataServer for Oracle Guide.)
Among the required environment variables that must be set, both
scripts that PROBUILD generates require that the ORALIB environment
variable is set. If ORALIB is not set, the buildenv scripts, ldpro
and ldorasrv, set it automatically. The executable that the ldpro
script generates gets a segmentation fault.
The segmentation violation is a known problem with ORACLE 7.3.3
and later running on HP. The ORACLE DataServer executable fails
even if it is not connected to the ORACLE database at the time.
ORACLE 7.3.3, 7.3.4, and 8.0.X now include libcma.sl as a part of
DCE (POSIX Threads). So the ORACLE DataServer also now requires
libcma.sl.
The following code example produces a segmentation fault:
def var c as char format "X(20)".
do while true:
readkey pause 0.
if keyfunction(lastkey)=chr(lastkey) and
lastkey >= 32 then do:
c = c + chr(lastkey).
next.
end.
if keyfunction(lastkey)="END ERROR" then leave.
end.
To workaround this problem, you must edit the ldpro script that
PROBUILD generates to explicitly include /usr/libc.a and
/usr/libc.sl and change the order of the wvsys.o, ocsys.o, and
orasys.o objects.
The following script example shows the changes to make:
#!/bin/sh
# Module:full-4GL
# oradbim - ORACLE DATASERVER
# bsd-sockets - TCP-IP NETWORK PROTOCOL
# named-pipes - NAMED PIPES
# qa-layer - VT QA layer
# Version: 8.3A
.
.
.
$PROLOAD/4gl/smdtypn.o
$PROLOAD/4gl/dbsys.o
$PROLOAD/4gl/mtsys.o
$PROLOAD/4gl/musys.o
/usr/lib/libc.a \ <--- libc.a library inserted here
$PROLOAD/4gl/wvsys.o \ <--- wvsys.o (fileno call inserted here)
$PROLOAD/oracle/ocsys.o \ before the ORACLE dataserver objects
$PROLOAD/oracle/orsys.o \ ocsys.o and orsys.o
$PROLOAD/4gl/prsys.o
$PROLOAD/4gl/sfsys.o
$PROLOAD/4gl/wisys.o
$PROLOAD/4gl/sm4glsys.o
$PROLOAD/4gl
casys.o
$PROLOAD/4gl/qrsys.o
$PROLOAD/4gl/wqsys.o
$PROLOAD/4gl/wvsys.o
$PROLOAD/4gl/pdsys.o
$PROLOAD/4gl/runtime.o
$PROLOAD/4gl/dbmgr.o
$PROLOAD/4gl/iolyr.o
$PROLOAD/4gl/compiler.o
$PROLOAD/4gl/rn4glsys.o
$PROLOAD/4gl/stlib.o
$PROLOAD/4gl/ut.o
-lm \ <-- move -lm \ above $ORALIB and $SOCKLIB
/usr/lib/libc.sl \ <-- insert libc.sl here after "-lm" and
$ORALIB \ before $ORALIB and $SOCKLIB
$SOCKLIB
/usr/lib/libcl.a
.
.
.
--------------------------------------------------------------------
Digital NT Clusters
Setting Up PROGRESS to utilize Digital´s NT clusters
RELEASE NOTE # 083A-00141
About this Topic
This topic describes the steps necessary to setup and to configure
your NT Clusters system to run PROGRESS Database Servers and allow
failover of those servers to provide continuous client access to
your database servers. It also includes some examples used to
test the functionality. These examples include scripts to start
and shutdown ProService as well as examples to start and stop
specific database servers. There is also some sample code for the
client to exhibit the considerations that need to be made in the
event of one of the cluster nodes failing.
This topic has the following sections:
o What are NT Clusters?
o Configuring the NT Cluster System
o PROGRESS Database Server Considerations and Configurations
o PROGRESS Client Considerations and a Client Code Example
What are NT Clusters?
NT Clusters provide a mechanism for server application providers
to create/configure their server applications to run seamlessly
from the client´s perspective.
An NT Cluster is comprised of two identical Windows NT Server
systems connected to a shared SCSI storage device. The cluster
shared disk storage can either be disks on the same SCSI bus or
disks connected through a smart SCSI Controller. The Digital NT
Clusters´ documentation describes all the possible and supported
configurations.
Within the scope of the NT Cluster, there are a few tools to
manage the cluster. The primary tool is the
"Cluster Administrator" from which the "Failover Manager" manages
the cluster failover resources. Failover is defined as the moving
of resources from a primary node to a secondary node when the
primary node either crashes or there is manual intervention to
force resource reallocation from one node to another.
Cluster Administrator
The Cluster Administrator is a GUI tool that allows you to define
"Failover Groups" and "Failover Objects" that will failover from
one node to the other. Failover Groups are user-defined entities
of Failover Objects. Failover Objects are the specific parts that
are determined necessary to allow server products to run.
Examples of Failover Objects include disks, network protocols, and
scripts. Application server providers can also provide DLLs to
make more direct calls to their products from the Failover Manager.
Examples of these are the MS SQL Server, Oracle Database Server,
Lotus Notes, and Web Servers.
Failover Manager
The Failover Manager is an image running on each node in the
cluster. It handles the reading of the Failover Group information
and performs the startup and shutdown of the various Failover
Objects in the specific order in which they were defined.
The Failover Manager determines when one node has either crashed
or has shutdown in some manner, then it performs actions based on
the objects that were running on the failed node. The Failover
Manager also allows for manual intervention to failover specific
Failover Groups as if the primary node failed.
Failover Groups
Failover Groups are created by the cluster system manager using
the Cluster Administrator interface. The Failover Group must
contain at least one Failover Object and a cluster node must be
chosen as the primary node. Within each Failover Group, the
Cluster Administrator requires that there be at least one shared
disk Failover Object.
After these minimum requirements are met, any number of other
Failover Objects can be placed into or removed from the Failover
Group. When removing Failover Objects from a Failover Group the
Cluster Administrator will ensure that there is at least one
object in the group.
Failover Groups can be deleted, in which case the Failover Objects
that were in the group are returned to the general pool of
Failover Objects. A Failover Group contains all the dependencies
to allow the group to function as a unit on a node.
Failover Objects
Failover Objects are defined by the cluster manager using the
Cluster Administrator interface. Failover Objects are created and
placed into a pool of available objects. When the Failover Group
is created, an object is placed into the group and removed from
the pool of objects.
A Failover Object cannot be placed into two Failover Groups; in
this scenario, two identical objects would need to be created.
Failover Objects have "Startup" and "Shutdown" attributes. When a
Failover Group is brought online the startup option is run;
conversely, when the Failover Manager determines that the group
must be failed over, the shutdown option is run.
The two primary Failover Objects are Shared Disks and TCP/IP
Alias. These objects give the cluster the ability to make the
cluster nodes transparent to the client(s).
The shared disk objects are created automatically when the shared
disks are given a name by the Cluster Administrator interface.
When a disk object is placed into a Failover Group, it is brought
online to the primary node by the Failover Manager. Due to the
nature of SCSI, only one node can directly access or own a shared
disk at any one time.
The TCP/IP alias objects are defined by the cluster manager using
IP addresses that are not currently assigned to any other node.
The cluster TCP/IP alias allows clients to access the nodes in the
cluster without the clients needing to know to which nodes they
are connected.
A TCP/IP alias object is associated with only one node at a time
and migrates from the primary to the secondary node, when the
Failover Manager fails over a Failover Group. In this scenario,
the client just reconnects to the same name, but now the client
is attached to a different node.
There can be more than one TCP/IP alias name per cluster. This
would happen when each node is acting as a server to a different
database and defines only one IP address with the database server.
Management of the TCP/IP alias name dependencies is left up to the
cluster system manager. It is recommended that a TCP/IP alias
object be present for each Failover Group that has objects
requiring TCP/IP services.
For PROGRESS, the only other Failover Object used is the script
object. This object allows the Failover Manager to either run a
script or run a specific image as defined by the cluster system
manager.
Scripts or images that are to be run can either be placed onto a
shared storage device or onto the system disk of each node. When
using the system disk, the drive letter for the system disk must
be the same on both nodes or an environment variable must be used
on both nodes to mask the drive letter.
When using shared storage for a script object script or image,
the shared disk object must be placed before the script object
in the order of the Failover Group. This ensures the disk is
online before the Failover Manager attempts to run the script
object.
PROGRESS Example
For PROGRESS, a Failover Group might be comprised of a shared disk
object, a TCP/IP alias object, and a script object that would
start a database server. Thus in order for the database server
to start, it must first have a disk and then a TCP/IP address,
before the server can start. The script object can either start
the database server directly or the script object can run a
written script that starts the database server.
Configuring the NT Cluster System
The configuration and setup of the actual NT Cluster is described
in the NT Clusters documentation. The order in which you install
the NT Cluster software and your PROGRESS software is very
important.
If you install PROGRESS after installing your NT Cluster software,
you will need to reboot the node to allow the NT Cluster software
to read the Registry and system environment variables so it knows
about the PROGRESS software.
If you install PROGRESS first, then install the NT Cluster
software there are no such problems. Each node in the cluster
must have PROGRESS installed onto its system disk. It is strongly
recommended you install identical versions and patches of PROGRESS
on both nodes to ensure the same operating environment.
One other configuration issue that you should be aware of is that
the system disk drive letter must be the same for both nodes in
your cluster. (Usually this letter is either "C:" or "D:"
depending on how you partition your node´s system disk.) Using
the same system disk drive letter, lets you create and run scripts
from your NT Cluster Failover Manager. The script location is
stored in the Failover Manager and must be listed with the same
physical location on both systems.
After the two systems have the NT Cluster software running, use
the Windows NT Disk Administrator to assign a drive letter to
each shared disk and then use the Cluster Administrator to assign
a name to your disks and to create your disk Failover Object(s).
Use the Cluster Administrator to create your TCP/IP alias Failover
Object(s) also. Once they are created, these objects will appear
in the Cluster Administrator display and you can begin to create
your Failover Groups for PROGRESS.
PROGRESS Database Server Considerations and Configuration
On the server side, think of the cluster as one node. Although
from a management viewpoint, you will still have nodes onto which
you must install, configure, and update the product.
The original setup is the most time consuming, because you must
install, configure, and maintain the PROGRESS environment in
addition to updating and maintaining the TCP/IP SERVICES file
on each node. However, from a user´s or an application´s
viewpoint there is only one host and one service.
For TCP/IP, the service name you associate with your database
server is a name that will be used cluster-wide. Therefore, you
must edit the TCP/IP SERVICES file on both nodes and also add the
same service name and socket number on each node. You must use
the same names and numbers, because in a failover, the secondary
node starts the database server and your clients need to reconnect
to your service by node and service number.
After PROGRESS is installed on both nodes, you need to determine
which cluster shared disk(s) will hold your database. Next, use
the Cluster Administrator to create a new Progress Failover Group.
Into the group place the shared disk object(s). Doing this places
the disk(s) online on the node that you have chosen to be the
primary node. From the primary node, use the PROGRESS Database
Administration tools to create or copy a database onto the shared
disk(s).
Next, use ProControl to configure the database server information,
using a cluster TCP/IP alias for the Host (-H) parameter name and
the "cluster- wide" service name from the SERVICES file for the
Service (-S) parameter name.
You need to duplicate this effort on both nodes, so it is
recommended that you have a ProControl screen visible on both
nodes, so you can be sure the duplication is exact.
Within ProControl you can choose to have the database server
started automatically or not. If you have only one cluster shared
disk, it is recommended that you allow ProControl to start the
database servers automatically when ProControl starts ProService.
However, if you have multiple cluster shared disks and you have
chosen to have each node act as the primary node for specific
database servers, this approach is not recommended. At this time,
ProControl only knows three commands, "Start, Stop, and Status".
Therefore, if you have database servers running on both nodes and
one node fails and those database servers failover to the
secondary node, you would have to "Stop" and "Start" ProControl in
order to start the automatic database server startup. Doing this
disrupts current users of the secondary node.
In the single cluster shared disk model, ProControl should not be
already running on the non-primary node, so in a failover you
start ProControl with automatic database server startup set and
your database servers will be started for you.
Continue creating Failover Groups and adding/modifying ProControl
for each database server on each shared disk.
After this is done, use the Cluster Administrator to create
Script Failover Objects to be placed in your Progress Failover
Group(s). These script objects can be either actual scripts or
they can be the direct command line interface into ProControl.
In either case, you must use the ProControl command line interface.
The following sections describe the command line interface and
give you some examples for scripts.
ProControl Command Line Interface
In order to start servers to PROGRESS databases on an NT node,
ProControl simply runs the PROGRESS image, PCCMD.EXE. This image
controls either starting or stopping ProService and the various
database servers. Within your scripts or script objects, use the
following syntax and parameters based on your requirements:
%DLC%\BIN\PCCMD.EXE P1 P2 [P3]
%DLC% should be listed as a system-wide environment variable as
described from the PROGRESS installation. The parameters to
PCCMD.EXE dictate what is done. The following is the list of
parameters you will need:
o P1 - Parameter 1
PROSERVICE - For ProService options
DATABASE - For Database options
o P2 - Parameter 2
START - To start either ProService or the Database Server
named in P3
STOP - To stop either ProService or the Database Server
named in P3
STATUS - Return current status of ProService or Database Server in P3
- Use %ERRORLEVEL% to detect return status
in script
- A return of "0" indicates request is
running (started)
- A return of "1" indicates request is not
running (stopped)
- Else, check if %DLC% is defined correctly.
o [P3] - Parameter 3 (required if Parameter 1 is DATABASE)
ID - "Name" entered in ProControl´s "Identifiers"
field.
If a wrong parameter is passed to PCCMD.EXE, it will be signaled
to the standard output and no action will be taken. Some command
line examples include:
%DLC%\BIN\PCCMD.EXE ProService Status
A return of 0 from this call means ProService is already running
%DLC%\BIN\PCCMD.EXE ProService Start
If run while already running, a message will be displayed stating
that ProService is already running; otherwise, a successful run
will return 0.
%DLC%\BIN\PCCMD.EXE ProService Stop
If run while already stopped, a message will displayed stating
that ProService is already stopped; otherwise, a successful run
will return 0.
%DLC%\BIN\PCCMD.EXE Database Status DEMO
A return of 0 from this call indicates the Database server for
DEMO is already running %DLC%\BIN\PCCMD.EXE Database Start DEMO
A return of 0 from this indicates the Database server for DEMO
was started successfully. If a start is attempted twice 0 will
still be returned and no message is displayed.
%DLC%\BIN\PCCMD.EXE Database Stop DEMO
A return of 0 from this indicates the Database server for DEMO
was stopped successfully. If a stop is attempted twice or
attempted upon a stopped database server, a 1 will be returned
and no message is displayed.
Using the above commands, you can either create an entire script
to be run or you can create Failover Objects for ProControl and
each database server to be placed into a Progress Failover Group.
Determining whether or not to create a script depends on the
environment. In the simple case of one database server per
cluster, by simply starting and stopping ProService with the
database server being automatically started and shutdown by
ProService, a script is unnecessary. In this case, using the
direct command line start/stop ProService as the startup and
shutdown options to the Failover Object should be used. In the
more complicated case of multiple database servers on both nodes,
you should use scripts. The scripts can then use the "status"
option to PCCMD.EXE to determine whether or not ProService is
running, as well as determine whether or not a database server
is running for the particular object.
Note:
The Failover Manager is documented to perform startup in the order
of the Failover Groups and shutdown in the reverse order of the
Failover Groups.
Startup of objects within each group is performed in the order
listed within the group, while shutdown is executed in reverse
order. Therefore, the cluster system manager must properly
configure the order so that each PROGRESS database server will
have the necessary disk and network objects in place before
attempting to start. This becomes especially tricky when dealing
with multiple TCP/IP alias objects. It is recommended that for
each database server that uses a particular TCP/IP alias name,
the script objects to start and stop the database be placed into
the same group as the TCP/IP alias name.
ProService Startup/Shutdown Script Examples:
The following are examples of scripts that can be used to start
and stop ProService. The scripts are stored on a shared disk,
which is assigned the drive letter "S". The Failover Object is
configured to run the scripts for start and stop respectively.
StartProService.cmd
ECHO OFF
REM This is a Cluster Startup Script for the Cluster Failover
REM Manager to execute when the cluster has a problem. It´s primary
REM purpose is to restart ProService if it isn´t already started on the node.
SET LOG=S:\ProgressScripts\StartProService.log
ECHO "Running on %COMPUTERNAME%" >> %LOG%
DATE /T >> %LOG%
%DLC\bin\PCCMD.EXE ProService Status >> %LOG%
IF %ERRORLEVEL% == 1 GOTO notstarted
ECHO "ProService already running >> %LOG%
GOTO done
:notstarted
ECHO "Starting ProService" >> %LOG%
%DLC%\bin\PCCMD.EXE ProService Start >> %LOG%
ECHO "Return value from start is %ERRORLEVEL%" >> %LOG%
:done
StopProService.cmd
ECHO OFF
REM This is a Script for the Cluster Failover Manager to execute when the
REM cluster has a problem. It´s primary purpose is to Stop ProService
REM if it isn´t already stopped on the node.
SET LOG=S:\ProgressScripts\StopProService.log
ECHO "Running on %COMPUTERNAME%" >> %LOG%
DATE /T >> %LOG%
%DLC\bin\PCCMD.EXE ProService Status >> %LOG%
IF %ERRORLEVEL% == 1 GOTO notstarted
ECHO "Shutting down ProService" >> %LOG%
%DLC%\bin\PCCMD.EXE ProService Stop >> %LOG%
ECHO "Return value from shutdown is %ERRORLEVEL%" >>
%LOG%
GOTO done
:notstarted
ECHO "ProService is already shutdown >> %LOG%
:done
Specific Database Startup/Shutdown Script Examples:
Within ProService startup or shutdown scripts, or within a separate
script, once ProService has started, then specific database
servers can be started. Conversely, before ProService is
shutdown, the database servers should be shut down as well.
If you have multiple databases you might want to create a generic
script that can be run with an input parameter for the database
name. The following examples assume that you have set up
ProControl to have a database server identified as "CluDemo1".
(Note it is very important to match the case between the script
and ProControl.) If the scripts are contained within the
ProService startup/shutdown scripts (either directly or through a
reference call), then only one object needs to be added to the
Failover Group. However, if they are separate scripts then
multiple objects are needed for each database to be started/shutdown
by the Failover Group.
The following are code fragments to Start and then Stop the
PROGRESS database server for database CluDemo1. The code assumes
the same as the Start and Stop ProService examples above with the
cluster shared disk as drive letter "S".
StartCluDemo1.cmd
ECHO OFF
REM This is a Script for the Cluster Failover Manager to execute
REM when the cluster has a problem. It´s primary purpose is
REM to Start the Database server for CluDemo1.
SET LOG=S:\ProgressScripts\StartCluDemo1.log
ECHO "Running on %COMPUTERNAME%" >> %LOG%
DATE /T >> %LOG%
%DLC%\bin\pccmd.exe Database Status CluDemo1 >> %LOG%
IF %ERRORLEVEL% == 1 GOTO startcludemo1
ECHO "Server for CluDemo1 already started" >> %LOG%
GOTO done cludemo1start
:startcludemo1
ECHO "Starting database server for CluDemo1" >> %LOG%
%DLC%\bin\PCCMD.EXE Database Start CluDemo1
ECHO "Return value from startup is %ERRORLEVEL%" >>
%LOG%
:donecludemo1start
StopCluDemo1.cmd
ECHO OFF
REM This is a Script for the Cluster Failover Manager to execute
REM when the cluster has a problem. It´s primary purpose
REM is to Stop the Database server for CluDemo1.
SET LOG=S:\ProgressScripts\StopCluDemo1.log
ECHO "Running on %COMPUTERNAME%" >> %LOG%
DATE /T >> %LOG%
%DLC%\bin\pccmd.exe Database Status CluDemo1 >> %LOG%
IF %ERRORLEVEL% == 0 GOTO stopcludemo1
ECHO "Server for CluDemo1 already stopped" >> %LOG%
GOTO donecludemo1stop
:stopcludemo1
ECHO "Stopping database server for CluDemo1" >> %LOG%
%DLC%\bin\PCCMD.EXE Database Stop CluDemo1
ECHO "Return value from startup is %ERRORLEVEL%" >>
%LOG%
:donecludemo1stop
PROGRESS Client Considerations and a Client Code Example
On the client side, you need to consider a few things. First, the
client no longer connects to a specific host using the "-H"
parameter. Instead, the client connects to an NT Cluster TCP/IP
Alias. Therefore, any code in which you specify the host to
connect to, you must modify the code to use the cluster alias in
use for the database server. You can still connect directly to a
host; however, if that host is down or not serving the database,
then your client will not reconnect, unless you change the "-H"
value to the name of the other node. Secondly, if you do not
already have in your PROGRESS client P-Code error checking for
the STOP signal, you must add code to handle the STOP signal.
See the PROGRESS Programming Handbook section on "How PROGRESS
Handles System and Software Failure" for details on the STOP
condition handling.
The following code examples exhibit the types of error handling
that need to be done to support the cluster failover from the
client side. When a node fails and the Cluster Manager migrates
the database server from one node to another, the PROGRESS client
is given a STOP signal which is trapped and handled in our code.
The client automatically receives a couple of PROGRESS generated
error dialog boxes indicating the last write was not performed
and potentially, the last transaction was not completed. Alert
your client users to these messages, so they know that they must
reenter their last transaction.
The following examples assume that you have a Database server
running on your Windows NT cluster with a Service (-S) name of
´cludemo1´ using the Host (-H) name ´cluster´. The demonstration
is strictly to exhibit what type of programming must be done to
make this work. It is not a full-featured application. The
CluDemo1 database is a copy of the PROGRESS SPORTS demonstration
database with no other changes.
Lastly, one other programming consideration that is exhibited by
the demonstration program: Do you bring your client back to the
point where the failure occurred, or do you start your client at
the beginning? In other words, how much state do you keep within
your code? This example tries to bring the client back to the
last customer record they were updating before the STOP was
raised. Therefore, the state that is kept within this code is
the last customer record chosen.
"repeat.p"
DEFINE NEW GLOBAL SHARED VARIABLE cur-cust AS INTEGER INITIAL 0.
REPEAT ON ERROR UNDO, LEAVE
ON STOP UNDO, RETRY:
IF RETRY
THEN DO:
MESSAGE "The STOP condition has occurred." SKIP
"Do you wish to continue?" VIEW-AS ALERT-BOX QUESTION
BUTTONS yes-no UPDATE continue-ok AS LOGICAL.
IF NOT continue-ok
THEN UNDO, LEAVE.
END.
IF NOT CONNECTED ("cludemo1") THEN
connect cludemo1 -S cludemo1 -H cluster -N tcp.
IF CONNECTED ("cludemo1")
THEN DO:
RUN updcust.p.
MESSAGE "Exit from updcust.p" SKIP
"Do you wish to continue?" VIEW-AS ALERT-BOX QUESTION
BUTTONS yes-no UPDATE continue-ok.
IF NOT continue-ok
THEN LEAVE.
ELSE cur-cust = 0. /* Reinitialize */
END.
ELSE
DO:
MESSAGE "Database not available." SKIP
"Do you wish to continue?" VIEW-AS ALERT-BOX QUESTION
BUTTONS yes-no UPDATE continue-ok.
IF NOT continue-ok
THEN LEAVE.
END.
end.
"updcust.p"
/* If never run before cur-cust is 0 */
DEFINE SHARED VARIABLE cur-cust AS INTEGER.
DEFINE VARIABLE first-time AS LOGICAL INITIAL TRUE.
REPEAT WITH 1 COLUMN 1 DOWN:
IF first-time AND cur-cust NE 0
THEN DO:
FIND customer WHERE customer.cust-num = cur-cust NO-ERROR NO-WAIT.
END.
ELSE
DO:
PROMPT-FOR customer.cust-num.
FIND customer USING cust-num NO-ERROR NO-WAIT.
END.
first-time = FALSE.
IF NOT AVAILABLE customer
THEN DO:
MESSAGE "Customer record " INPUT customer.cust-num " not found."
SKIP
"Do you wish to continue?" VIEW-AS ALERT-BOX QUESTION
BUTTONS yes-no UPDATE continue-ok AS LOGICAL.
IF NOT continue-ok
THEN LEAVE.
cur-cust = 0.
END.
ELSE
DO:
cur-cust = customer.cust-num.
DISPLAY customer.cust-num.
UPDATE name address city state postal-code credit-limit.
END.
END.