bankapp is a sample ATMI banking application that is provided with the Oracle Tuxedo software. The application performs the following banking functions: opens and closes accounts, retrieves account balances, deposits or withdraws money from an account, and transfers monies from one account to another.
The bankapp tutorial is presented in three sections:
bankapp uses a demo relational database delivered with the software that enables you to use the sample application. Various commands and SQL code within the sample application (included for demo purposes only) provide access to the database.
The bankapp directory contains the following files:
|
|
|
|
|
Contains two services: OPEN_ACCT and CLOSE_ACCT to open and close accounts.
|
|
|
|
|
|
|
|
|
Contains a set of services: ABAL, TBAL, ABAL_BID, and TBAL_BID that allow the audit client to obtain bank-wide or branch-wide account or teller balances.
|
|
|
Contains two services: ABALC_BID, and TBALC_BID. These services are the same as TBAL_BID and ABAL_BID, except that TPSUCCESS is returned when a branch ID is not found, which allows auditcon to continue running.
|
|
|
|
|
|
Contains two services: BR_ADD and TLR_ADD for adding branches and tellers to the database.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Documentation of additions to bankapp that demonstrate new features. The file is located in the samples/atmi/bankapp directory .
|
|
|
Documentation of additions to bankapp that demonstrate new features for the Windows 2003 platform. The file is located in the samples\atmi\bankapp directory .
|
|
|
|
|
|
|
|
|
|
|
|
Contains three services: WITHDRAWAL, DEPOSIT, and INQUIRY.
|
|
|
A shell script that creates an ENVFILE for the Oracle Tuxedo server TMUSREVT.
|
|
|
Contains TRANSFER service.
|
|
|
|
|
|
Contains customized versions of tpsvrinit() and tpsvrdone() for all servers other than TLR.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Contains some environment variables for bankapp. Other environment variables are defined in ENVFILE, but because ENVFILE is set from within bankvar, you can control the entire environment for your application through bankvar.
|
|
|
|
|
|
|
|
|
A shell script that creates a UDL and a TLOG on the master site and a UDL on the non-master sites.
|
|
|
|
|
|
A shell script that creates ENVFILE for use by tmloadcf.
|
|
|
A program that generates ud-readable requests to add ten branches, thirty tellers, and two hundred accounts.
|
|
|
A program that generates ud-readable transaction requests from four services: DEPOSIT, WITHDRAWAL, TRANSFER, and INQUIRY.
|
|
|
|
|
|
A sample UBBCONFIG file for use in an MP mode configuration.
|
|
|
A sample UBBCONFIG file for use in a SHM-mode configuration.
|
|
|
A set of functions, such as getstrl(), that are commonly used by services.
|
|
|
|
The bankclt file contains the client program that requests Oracle Tuxedo services from the
bankapp application. This client program is text-based and provides the following options:
1The number in parentheses is the FML occurrence number for that field.
The do_tpcall() function (that begins on line 447 in
bankclt.c) follows:
{
long len;
char *server_status;
/* Begin a Global transaction */
if (tpbegin(30, 0) == -1) {
(void)fprintf(stderr, "ERROR: tpbegin failed (%s)\n",
tpstrerror(tperrno));
return(-1);
}
/* Request the service with the user data */
if (tpcall(service, (char *)fbfr, 0, (char **)&fbfr, &len,
0) == -1) {
if(tperrno== TPESVCFAIL && fbfr != NULL &&
(server_status=Ffind(fbfr,STATLIN,0,0)) != 0) {
/* Server returned failure */
(void)fprintf(stderr, "%s returns failure
(%s)\n",
service,server_status);
}
else {
(void)fprintf(stderr,
"ERROR: %s failed (%s)\n", service,
tpstrerror(tperrno));
}
/* Abort the transaction */
(void) tpabort(0);
return(-1);
}
/* Commit the transaction */
if(tpcommit(0) < 0) {
(void)fprintf(stderr, "ERROR: tpcommit failed
(%s)\n",
tpstrerror(tperrno));
return(-1);
}
return(0);
}
The do_tpcall() function performs the following tasks:
•
|
Calls tpcall() with the requested service name ( char *service) and the supplied FML buffer (the global * fbfr pointer).
|
•
|
If tpcall() fails with a server-indicated failure ( TPSVCERR), it prints the message from the server in the STATLIN FML field. The transaction is rolled back with tpabort() and it returns -1.
|
•
|
If tpcall() fails with any other error, it prints the error message and rolls back the transaction with tpabort() and returns -1.
|
•
|
If tpcall() succeeds, it commits the transaction using tpcommit() and returns 0.
|
Note:
|
The unsolfcn() function is invoked if there is an unsolicited message to the client. It only supports STRING buffer types and prints the message.
|
bankapp uses the Oracle Tuxedo program
ud(1), which allows fielded buffers to be read from standard input and sent to a service. In the sample application,
ud is used by both the populate and driver programs:
audit is a request/response client program that makes branch-wide or bank-wide balance inquiries, using the services:
ABAL,
TBAL,
ABAL_BID, and
TBAL_BID. You can invoke it in two ways:
•
|
audit [-a | -t]—prints the bank-wide total value of all accounts, or bank-wide cash supply of all tellers. Option -a or -t must be specified to indicate whether account balances or teller balances are to be tallied.
|
•
|
audit [-a | -t] branch_ID—prints the branch-wide total value of all accounts, or branch-wide cash supply of all tellers, for branch denoted by branch_ID. Option -a or -t must be specified to indicate whether account balances or teller balances are to be tallied.
|
The source code for audit contains two major parts: main() and a subroutine called
sum_bal(). Oracle Tuxedo ATMI functions are used in both parts. The program uses a
VIEW typed buffer and a structure that is defined in the
aud.h header file. The source code for the structure can be found in the view description file,
aud.v.
3.
|
/* Do tpgetrply to retrieve answers to questions */
|
auditcon is a conversational version of the
audit program. The source code for
auditcon uses the ATMI functions for conversational communication:
tpconnect() to establish the connection between the client and service,
tpsend() to send a message, and
tprecv() to receive a message.
bankmgr is included with
bankapp as an example of a client that is designed to run constantly. It subscribes to application-defined events of special interest, such as the opening of a new account or a withdrawal above $10,000. (The
bankmgr.c client is more fully described in the
README2 file of
bankapp and in the
bankmgr.c code itself.)
•
|
“What You Can Do Using the ATMI” in Introducing Oracle Tuxedo ATMI
|
•
|
Descriptions of the buildserver(1) command options used to compile and build each server with the main() defined by the Oracle Tuxedo system.
|
All bankapp services are coded in C with embedded SQL except for the
TRANSFER service, which does not interact directly with the database. The
TRANSFER service is offered by the
XFER server and is a C program (that is, its source file is a
.c file rather than a
.ec file).
All bankapp services of
bankapp use functions provided in the Application-to-Transaction Management Interface (ATMI) for performing the following tasks:
Five bankapp servers operate in request/response mode. Four of the five use embedded SQL statements to access a resource manager; the names of the source files for these servers (located in the
bankapp sample application subdirectory), include a
.ec filename extension.
The fifth server, XFER, for transfer, makes no calls to the resource manager itself; it calls the
WITHDRAWAL and
DEPOSIT services (offered by the
TLR server) to transfer funds between accounts. The source file for
XFER is a
.c file, because
XFER makes no resource manager calls and contains no embedded SQL statements.
|
|
|
|
|
|
|
Provides teller services, namely WITHDRAWAL, DEPOSIT, and INQUIRY. Each TLR process identifies itself as an actual teller in the TELLER file, via the user-defined -T option on the server’s command line.
|
|
|
|
|
AUDITC is an example of a conversational server. It offers one service, which is also called
AUDITC. The conversational client,
auditcon, establishes a connection to
AUDITC and sends it requests for auditing information.
AUDITC evaluates requests and calls an appropriate service (
ABAL,
TBAL,
ABAL_BID, or
TBAL_BID) to get the appropriate information. When a reply is received from the service called,
AUDITC sends it back to
auditcon. A service in a conversational server can make calls to request/response services. It can also initiate connections to other conversational servers, but this functionality is not provided by
AUDITC.
bankapp offers 12 request/response services. The name of each
bankapp service matches the name of a C function in the source code of a server.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
•
|
Chooses an ACCOUNT_ID for a new account based on the BRANCH_ID of the teller involved
|
|
|
|
|
•
|
Calls WITHDRAWAL to remove the final balance
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
•
|
Issues a tpcall() requesting WITHDRAWAL followed by one requesting DEPOSIT
|
|
|
|
|
|
|
|
VIEW buffer of aud.v as input
|
|
|
|
VIEW buffer of aud.v as input
|
|
|
|
VIEW buffer of aud.v as input
|
|
The following listings show pseudo-code for the algorithms used for the bankapp services:
BR_ADD,
TLR_ADD,
OPEN_ACCT,
CLOSE_ACCT,
WITHDRAWAL,
DEPOSIT,
INQUIRY,
TRANSFER,
ABAL,
TBAL,
ABAL_BID, and
TBAL_BID. You can use them as road maps through the source code of the
bankapp servers.
•
|
appinit.c contains application-specific versions of the tpsvrinit() and tpsvrdone() subroutines. tpsvrinit() and tpsvrdone() are subroutines included in the standard Oracle Tuxedo ATMI main(). The default version of tpsvrinit() calls two functions: tpopen(), to open the resource manager, and userlog(), to post a message that the server has started. The default version of tpsvrdone() also calls two functions: tpclose(), to close the resource manager, and userlog(), to post a message that the server is about to shut down. Any application subroutines named tpsvrinit() and tpsvrdone() can be used in place of the default subroutines, thus enabling an application to provide initialization and pre-shutdown procedures of its own.
|
•
|
util.c contains a subroutine called getstr(), which is used in bankapp to process SQL error messages.
|
In the bankapp source files all the services were incorporated into files that are referred to as the source code for servers. These files have the same names as the
bankapp servers, but are not really servers because they do not contain a
main() section. A standard
main() is provided by Oracle Tuxedo ATMI at
buildserver time.
2.
|
Run the buildserver command specifying each . o file with a separate invocation of the -f option.
|
•
|
“What You Can Do Using the ATMI” in Introducing Oracle Tuxedo ATMI
|
2.
|
Set TUXDIR to the root directory of your Oracle Tuxedo system directory structure, and export it.
|
3.
|
Another line in bankvar sets APPDIR to the directory ${TUXDIR}/samples/atmi/bankapp, which is the directory where bankapp source files are located. APPDIR is a directory where the Oracle Tuxedo system looks for your application-specific files. You may prefer to copy the bankapp files to a different directory to safeguard the original source files. If you do, enter the directory there. It does not have to be under TUXDIR.
|
4.
|
Set a value for DIPCKEY. This is an IPCKEY for an Oracle Tuxedo system database. The value of DIPCKEY must be different from the value of the Oracle Tuxedo system IPCKEY specified in the UBBCONFIG file.
|
Note:
|
Other variables specified in bankvar play various roles in the sample application; you need to be aware of them when you are developing your own application. By including them all in bankvar, we provide you with a “template” that you may want to adapt at a later time for use with a real application.
|
# Copyright (c) 1997, 1996 BEA Systems, Inc.
# Copyright (c) 1995, 1994 Novell, Inc.
# Copyright (c) 1993, 1992, 1991, 1990 Unix System Laboratories, Inc.
# All rights reserved
#
# This file sets all the environment variables needed by the TUXEDO software
# to run the bankapp
#
# This directory contains all the TUXEDO software
# System administrator must set this variable
#
if [ -z "${TUXDIR}" ] ; then
if [ ! -z "${ROOTDIR}" ] ; then
TUXDIR=$ROOTDIR
export TUXDIR
fi
fi
TUXDIR=${TUXDIR:?}
#
# Reset LANG if necessary
#
if [ ! -d ${TUXDIR}/locale/C -a -d ${TUXDIR}/locale/english_us ] ; then
export LANG
LANG=english_us.ascii
fi
#
# This directory contains all the user written code
#
# Contains the full path name of the directory that the application
# generator should place the files it creates
#
APPDIR=${TUXDIR}/apps/bankapp
#
# This path contains the shared objects that are dynamically linked at
# runtime in certain environments, e.g., SVR4.
#
LD_LIBRARY_PATH=${TUXDIR}/lib:${LD_LIBRARY_PATH}
#
# Set the path to shared objects in HP-UX
#
SHLIB_PATH=${TUXDIR}/lib:${SHLIB_PATH}
#
# Set the path to shared objects in AIX
#
LIBPATH=${TUXDIR}/lib:/usr/lib:${LIBPATH}
#
# Logical block size; Database Administrator must set this variable
#
BLKSIZE=512
#
# Set default name of the database to be used by database utilities
# and database creation scripts
#
DBNAME=bankdb
#
# Indicate whether database is to be opened in share or private mode
#
DBPRIVATE=no
#
# Set Ipc Key for the database; this MUST differ from the UBBCONFIG
# *RESOURCES IPCKEY parameter
#
DIPCKEY=80953
#
# Environment file to be used by tmloadcf
#
ENVFILE=${APPDIR}/ENVFILE
#
# List of field table files to be used by mc, viewc, tmloadcf, etc.
#
FIELDTBLS=Usysflds,bankflds,creditflds,eventflds
#
FIELDTBLS32=Usysfl32,evt_mib,tpadm
#
# List of directories to search to find field table files
#
FLDTBLDIR=${TUXDIR}/udataobj:${APPDIR}
#
FLDTBLDIR32=${TUXDIR}/udataobj:${APPDIR}
#
# Universal Device List for database
#
FSCONFIG=${APPDIR}/bankdl1
#
# Network address, used in MENU script
#
NADDR=
#
# Network device name
#
NDEVICE=
#
# Network listener address, used in MENU script
#
NLSADDR=
#
# Make sure TERM is set
#
TERM=${TERM:?}
#
# Set device for the transaction log; this should match the TLOGDEVICE
# parameter under this site's LMID in the *MACHINES section of the
# UBBCONFIG file
#
TLOGDEVICE=${APPDIR}/TLOG
#
# Device for binary file that gives the BEA Tuxedo system all its information
#
TUXCONFIG=${APPDIR}/tuxconfig
#
# Set the prefix of the file which is to contain the central user log;
# this should match the ULOGPFX parameter under this site's LMID in the
# *MACHINES section of the UBBCONFIG file
#
ULOGPFX=${APPDIR}/ULOG
#
# System name, used by RUNME.sh
#
UNAME=
#
# List of view files to be used by viewc, tmloadcf, etc.
#
VIEWFILES=aud.V
#
VIEWFILES32=mib_views,tmib_views
#
# List of directories to search to find view files
#
VIEWDIR=${TUXDIR}/udataobj:${APPDIR}
#
VIEWDIR32=${TUXDIR}/udataobj:${APPDIR}
#
# Specify the Q device (if events included in demo)
#
QMCONFIG=${APPDIR}/qdevice
#
# Export all variables just set
#
export TUXDIR APPDIR BLKSIZE DBNAME DBPRIVATE DIPCKEY ENVFILE
export LD_LIBRARY_PATH SHLIB_PATH LIBPATH
export FIELDTBLS FLDTBLDIR FSCONFIG MASKPATH OKXACTS TERM
export FIELDTBLS32 FLDTBLDIR32
export TLOGDEVICE TUXCONFIG ULOGPFX
export VIEWDIR VIEWFILES
export VIEWDIR32 VIEWFILES32
export QMCONFIG
#
# Add TUXDIR/bin to PATH if not already there
#
a="`echo $PATH | grep ${TUXDIR}/bin`"
if [ x"$a" = x ]
then
PATH=${TUXDIR}/bin:${PATH}
export PATH
fi
#
# Add APPDIR to PATH if not already there
#
a="`echo $PATH | grep ${APPDIR}`"
if [ x"$a" = x ]
then
PATH=${PATH}:${APPDIR}
export PATH
fi
#
# Check for other machine types bin directories
#
for DIR in /usr/5bin /usr/ccs/bin /opt/SUNWspro/bin
do
if [ -d ${DIR} ] ; then
PATH="${DIR}:${PATH}"
fi
done
buildserver(1) puts together an executable ATMI server built on the Oracle Tuxedo ATMI
main(). Options identify the names of the output file, the input files provided by the application, and various libraries that permit you to run an Oracle Tuxedo system application in a variety of ways.
buildserver invokes the
cc command. The environment variables
CC and
CFLAGS can be set to name an alternative compile command and to set flags for the compile and link edit phases. The
buildserver command is used in
bankapp.mk to compile and build each server in the banking application. The following sections describe the six
bankapp servers:
The ACCT server is derived from a file called
ACCT.ec that contains the code for the
OPEN_ACCT and
CLOSE_ACCT functions. It is created in two steps.
ACCT.ec is first compiled to an
ACCT.o file, which is then specified to the
buildserver command so that any compile-time errors can be identified and resolved.
1.
|
Create the ACCT.o file (performed for you in bankapp.mk):
|
•
|
The .c file is generated as follows: esql ACCT.ec.
|
•
|
The .o file is generated as follows: cc -I $TUXDIR/include -c ACCT.c.
|
•
|
The ACCT server is created by running the following buildserver command line.
|
•
|
The -r option is used to specify which resource manager access libraries should be link edited with the executable server. The choice is specified with the string TUXEDO/SQL.
|
•
|
The -s option is used to specify the names of the services in the server that are available to be advertised when the server is booted. If the name of a function that performs a service is different from the corresponding service name, the function name becomes part of the argument to the -s option. In bankapp, the function name is always the same as the name of the corresponding service so only the service names themselves need to be specified. It is our convention to spell all service names in all uppercase. For example, the OPEN_ACCT service is processed by the function OPEN_ACCT(). However, the -s option to buildserver does allow you to specify an arbitrary name for the processing function for a service within a server. Refer to the buildserver(1) reference page for details. It is also possible for an administrator to specify that only a subset of the services used to create the server with the buildserver command is to be available when the server is booted.
|
•
|
The -o option is used to assign a name to the executable output file. If no name is provided, the file is named SERVER.
|
•
|
The -f option specifies the files that are used in the link-edit phase. (For related information, see the description of the -l option on the buildserver(1) reference page.) The order in which the files are listed depends on function references and the libraries in which those references are resolved. Source modules should be listed before libraries that might be used to resolve their references. If these are .c files, they are first compiled. (In the example above, appinit.o and util.o have been already compiled.) Object files can be either separate .o files or groups of files in archive ( .a) files. If more than one filename is given as an argument to the -f option, the list must be enclosed in double quotation marks. Although the -f option takes only one file or one list of files (enclosed in double quotation marks) as an argument, you can include the -f option as many times as necessary on a single command line.
|
•
|
The -r option specifies the Oracle Tuxedo system SQL resource manager.
|
•
|
The -s option names the OPEN_ACCT and CLOSE_ACCT services (which are defined by functions of the same name in the ACCT.ec file) to be the services that make up the ACCT server.
|
•
|
The -o option assigns the name ACCT to the executable output file.
|
•
|
The -f option specifies that the ACCT.o, appinit.o, and util.o files are to be used in the link-edit phase of the build.
|
Note:
|
The appinit.c file contains the system-supplied tpsvrinit() and tpsvrdone(). (Refer to tpservice(3c) reference pages for an explanation of how these routines are used.)
|
The BAL server is derived from a file called
BAL.ec that contains the code for the
ABAL,
TBAL,
ABAL_BID, and
TBAL_BID functions. As with
ACCT.ec, the
BAL.ec is first compiled to a
BAL.o file before being supplied to the
buildserver command so that any compile-time errors can be identified and resolved.
1.
|
Modify the buildserver command used to create the BAL server as follows:
|
•
|
Use the -r option to specify the Oracle Tuxedo system SQL resource manager.
|
•
|
Use the -s option to name the ABAL, TBAL, ABAL_BID, TBAL_BID services that make up the BAL server. The functions in the BAL.ec file that define these services have identical names.
|
•
|
Use the -o option to assign the name BAL to the executable server.
|
•
|
Use the -f option to specify that the BAL.o and the appinit.o files are to be used in the link-edit phase.
|
The BTADD server is derived from a file called
BTADD.ec that contains the code for the
BR_ADD and
TLR_ADD functions. The
BTADD.ec is compiled to a
BTADD.o file before being supplied to the
buildserver command.
1.
|
Modify the buildserver command used to create the BTADD server as follows:
|
•
|
Use the -r option to specify the Oracle Tuxedo system SQL resource manager.
|
•
|
Use the -s option to name the BR_ADD and TLR_ADD services that make up the BTADD server. The functions in the BTADD.ec file that define these services have identical names.
|
•
|
Use the -o option to assign the name BTADD to the executable server.
|
•
|
Use the -f option to specify that the BTADD.o and appinit.o files are to be used in the link-edit phase.
|
The TLR server is derived from a file called
TLR.ec that contains the code for the
DEPOSIT,
WITHDRAWAL, and
INQUIRY functions. The
TLR.ec is also compiled to a
TLR.o file before being supplied to the
buildserver command.
1.
|
Modify the buildserver command used to create the TLR server as follows:
|
•
|
Use the -r option to specify the Oracle Tuxedo system SQL resource manager.
|
•
|
Use the -s option to name the DEPOSIT, WITHDRAWAL, and INQUIRY services that make up the TLR server. The functions in the TLR.ec file that define these services have identical names.
|
•
|
Use the -o option to assign the name TLR to the executable server.
|
•
|
Use the -f option to specify that the TLR.o and the util.o files are to be used in the link-edit phase.
|
Note:
|
In this example, the -f option is used to pass an option ( -lm) to the cc command, which is invoked by buildserver. The -lm argument to -f causes the math libraries to be linked in at compile time.
|
(Refer to cc(1) in the
UNIX System V User's Reference Manual for a complete list of compile-time options.)
The XFER server is derived from a file called
XFER.c that contains the code for the
TRANSFER function. The
XFER.c is also compiled to an
XFER.o file before being supplied to the
buildserver command.
1.
|
Modify the buildserver command used to create the XFER server as follows:
|
•
|
Use the -r option to specify the Oracle Tuxedo system SQL resource manager.
|
•
|
Use the -s option to name the TRANSFER service that makes up the XFER server. The function in the XFER.c file that defines the TRANSFER service has the identical name.
|
•
|
Use the -o option to assign the name XFER to the executable server.
|
•
|
Use the -f option to specify that the XFER.o and the appinit.o files are to be used in the link-edit phase.
|
The topics on creating the bankapp servers are important to your understanding of how the
buildserver command is specified. However, in actual practice you are apt to incorporate the build into a makefile; that is the way it is done in
bankapp.
bankapp includes a makefile that makes all scripts executable, converts the view description file to binary format, and does all the precompiles, compiles, and builds necessary to create application servers. It can also be used to clean up when you want to make a fresh start.
As bankapp.mk is delivered, there are a few fields you may want to edit, and some others that may benefit from some explanation.
1.
|
Review bankapp.mk, about 40 lines into the file, where you come to the following comment and the TUXDIR parameter:
|
2.
|
Set the TUXDIR parameter to the absolute pathname of the root directory of your Oracle Tuxedo system installation.
|
1.
|
Review the setting of the APPDIR parameter. As bankapp is delivered, APPDIR is set to the directory in which the bankapp files are located, relative to TUXDIR. The following section of bankapp.mk defines and describes the setting of APPDIR.
|
By default, bankapp is set up to use the Oracle Tuxedo/SQL as the database resource manager. This arrangement is based on the assumption that you have the Oracle Tuxedo system database on your system. If this is not the case, you should set the RM parameter to the name of your resource manager as listed in
TUXDIR/udataobj/RM.
2.
|
Check the nohup.out file to make sure the process completed successfully.
|
Note:
|
bankvar sets a number of parameters that are referenced when bankapp.mk is run.
|
This documentation describes the interface between bankapp and a resource manager, typically a database management system, and how to create the database for
bankapp.
bankapp is designed to use the Oracle Tuxedo/SQL facilities of the Oracle Tuxedo system database, which is an XA-compliant resource manager.
How you create the bankapp database depends on whether you bring up the application on a single processor (SHM mode) or on a network of more than one processor (MP mode).
2.
|
Execute crbank. crbank calls crbankdb three times, changing some environment variables each time, so that you end up with three database files on a single machine. As a result, you can simulate the multi-machine environment of the Oracle Tuxedo system without a network of machines.
|
2.
|
Run crbankdb to create the database for this site.
|
To run bankapp with an alternative XA-compliant resource manager, you must modify various files. This section describes the following:
Because all database access in bankapp is performed with embedded SQL statements, if your new resource manager supports SQL, you should have no problem. The utility
appinit.c includes calls to
tpopen() and
tpclose().
1.
|
crbank may be ignored by your alternate resource manager. Its only functions are to reset variables and to run crbankdb three times.
|
2.
|
crbankdb, on the other hand, requires close attention. The following code listing is the beginning of the crbankdb script. It is followed by an explanation of parts of the code that do not work with a resource manager that is not supplied with the Oracle Tuxedo system.
|
#Copyright (c) BEA Systems, Inc.
#All rights reserved
#
# Create device list
#
dbadmin<<!
echo
crdl
# Replace the following line with your device zero entry
${FSCONFIG} 0 2560
!
#
# Create database files, fields, and secondary indices
#
sql<<!
echo
create database ${DBNAME} with (DEVNAME='${FSCONFIG}',
IPCKEY=${DIPCKEY}, LOGBLOCKING=0, MAXDEV=1,
NBLKTBL=200, NBLOCKS=2048, NBUF=70, NFIELDS=80,
NFILES=20, NFLDNAMES=60, NFREEPART=40, NLCKTBL=200,
NLINKS=80, NPREDS=10, NPROCTBL=20, NSKEYS=20,
NSWAP=50, NTABLES=20, NTRANTBL=20, PERM='0666',
STATISTICS='n'
)
create table BRANCH (
BRANCH_ID integer not null,
BALANCE real,
LAST_ACCT integer,
LAST_TELLER integer,
PHONE char(14),
ADDRESS char(60),
primary key(BRANCH_ID)
) with (
FILETYPE='hash', ICF='PI', FIELDED='FML',
BLOCKLEN=${BLKSIZE}, DBLKS=8, OVBLKS=2
)
In the GROUPS section, specify appropriate values (that is, values that are recognized by your resource manager) for the
TMSNAME and
OPENINFO parameters.
1.
|
Edit the nt\bankvar.cmd and supply suitable values for the following environment variables:
|
TUXDIR : Root directory for the BEA TUXEDO system installation
APPDIR : Application directory in which
bankapp files are located
ORACLE_HOME : Root directory of the Oracle8 installation
DBNAME: default name of the database to be used by database utilities and database creation scripts
DBPRIVATE: indicates whether database is to be opened in share or private mode (yes or no)
FSCONFIG:Universal Device List for database
3.
|
Edit the TUXDIR\udataobj\RM file as follows:
|
Oracle_XA;xaosw;%ORACLE_HOME%\pro80\lib\msvc\sqllib80.lib
%ORACLE_HOME%\RDBMS80\XA\xa80.lib
5.
|
Edit the nt\bankapp.mak file as indicated in the following table.
|
|
|
|
TUXDIR=Root directory for the Oracle Tuxedo system installation
|
|
APPDIR=Application directory in which bankapp files are located
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the .ec.c section, Edit rules for creating C programs from embedded SQL programs, (use the proc compiler), set the following values.
|
|
In the .c.obj section, Edit rule for creating object files from C programs, set the following values.
|
|
8.
|
Edit nt\ubbshm as follows:
|
9.
|
In the GROUPS section of the configuration file, enter the following changes:
|
14.
|
Ensure that the view v$XATRANS$ exists on the database. (The view V$XATRANS$ should have been created during the XA library installation.)
|
15.
|
If the v$XATRANS$ view has not been created, create it as follows:
|
Execute the sql script ${ORACLE_HOME}/RDBMS80/ADMIN/XAVIEW.sql
16.
|
Create the bankapp database and database objects for Oracle RM:
|
•
|
Edit crbank-ora8.sql as follows:
|
17.
|
Write the code to create user2 and user3 with passwords PaSsWd2 and PaSsWd3, respectively, following the method described in the above steps:
|
•
|
UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference
|
•
|
“What Is the Configuration File?” in Setting Up an Oracle Tuxedo Application
|
Note:
|
If you bring up bankapp in SHM mode, you do not have to create the tlisten process or create a transaction log on another machine.
|
Once you have finished editing the configuration file, you must load it into a binary file on your MASTER machine. The name of the binary configuration file is
TUXCONFIG; its path name is defined in the
TUXCONFIG environment variable. The file should be created by a person with the effective user ID and group ID of the Oracle Tuxedo system administrator, which should be the same as the
UID and
GID values in your configuration file. If this requirement is not met, you may have permission problems in running
bankapp.
1.
|
To create TUXCONFIG, enter the following command:
|
TUXCONFIG can be installed only on the
MASTER machine; it is propagated to other machines by
tmboot when the application is booted.
If you have specified SECURITY as an option for the configuration,
tmloadcf prompts you to enter an application password. The password you select can be up to 30 characters long. Client processes joining the application are required to supply the password.
tmloadcf parses the text configuration file (
UBBCONFIG) for syntax errors before it loads it, so if there are errors in the file, the job fails.
The TLOG is the transaction log used by the Oracle Tuxedo system in the management of global transactions. Before an application can be booted, an entry for the
TLOG must be created in every file on every machine in the application, and a file for the log itself must be created on the
MASTER machine.
bankapp provides a script called
crtlog that creates a device list and a
TLOG for you. The device list is created using the
TLOGDEVICE variable from
bankvar.
1.
|
To create your TLOG and device list, enter the command on the MASTER machine as follows:
|
tlisten is the listener process that provides a remote service connection for processes such as
tmboot between machines in an Oracle Tuxedo application. It must be installed on all the machines in your network as defined in the
NETWORK section of the configuration file.
The nlsaddr value must be the same as that specified for the
NLSADDR parameter for this machine in your configuration file. Because this value changes from one machine to another, it is important that your
tlisten argument agrees with your configuration file specification.
Note:
|
Detection of an error in this specification is not easy. tmloadcf does not check for agreement between your configuration file and your tlisten command. If the two addresses do not match, then the application will probably fail to boot on the machine with the mismatched value of nlsaddr or on which the tlisten process has not been started.
|
The log file used by tlisten is separate from all other Oracle Tuxedo system log files, but one log can be used by more than one
tlisten process. The default filename is
TUXDIR/udataobj/tlog.
tlisten is designed to run as a daemon process. For suggestions about incorporating it in startup scripts or running it as a cron job, see
tlisten(1) in the
Oracle Tuxedo Reference Manual.
For bankapp, you may prefer simply to start it and bring it down as you need it. To bring it down, send it a
SIGTERM signal such as the following:
If no remote tlisten is running, the boot sequence is displayed on your screen as follows:
1.
|
Before booting bankapp, verify that your machine has enough IPC resources to support your application. To generate a report on IPC resources, run the tmboot command with the -c option.
|
The populate.sh script is provided to put records into the database so you can run
bankapp and test its functionality.
populate is a one line script that pipes records from a program called
gendata to the system server,
ud. The
gendata program creates records for 10 branches, 30 tellers, and 200 accounts. A record of the files created is kept in
pop.out, so you can use values in the database when forming your sample service requests.
•
|
tmboot(1) in the Oracle Tuxedo Command Reference
|
•
|
userlog(3c) in the Oracle Tuxedo ATMI C Function Reference
|
•
|
“What Is the User Log (ULOG)?” in Administering an Oracle Tuxedo Application at Run Time
|
•
|
“How to Boot the Application” in Administering an Oracle Tuxedo Application at Run Time
|
2.
|
Run the audit client program. To execute the audit client program, enter the following command:
|
specifying either -a for account balances or
-t for teller balances. If you specify a
branch_id, the report is limited to the branch specified; if you do not, the report includes data for all branches. For sample account numbers, branch IDs, and other values that you can provide as input to audit, use values listed in
pop.out, the output of the populate program.
3.
|
Run auditcon. To start the conversational version of the audit program, enter the following command:
|
driver is a script that generates a series of transactions to simulate activity on the system. It is included as part of
bankapp so you can get realistic-looking statistics by running
tmadmin commands.
To bring down bankapp, enter the
tmshutdown(1) command with no arguments, from the
MASTER machine, as follows: