This chapter covers booting the application and putting enough records into the database to simulate a real application.
When your application is defined to the point where you are ready to boot it, you should first run a check to make sure your machine has enough IPC resources to support your application. The tmboot and populate
Checking IPC Resources
tmboot
command has a -c
option that produces a report like that shown in Listing 9-1.
Listing 9-1
tmboot -c IPC Report
Ipc sizing (minimum /T values only)
Fixed Minimums Per Processor
SHMMIN: 1
SHMALL: 1
SEMMAP: SEMMNI Variable Minimums Per Processor
SEMUME, A SHMMAX
SEMMNU, * *
Node SEMMNS SEMMSL SEMMSL SEMMNI MSGMNI MSGMAP SHMSEG
------ ------ ------ ------ ------ ------ ------ ------
sfpup 60 1 60 A + 1 10 20 76K
sfsup 63 5 63 A + 1 11 22 76Kwhere 1 <= A <= 8.
The number of expected application clients per processor should be added to each MSGMNI
value. MSGMAP
should be twice MSGMNI
.
The minimum IPC requirements can be compared to the parameters set for your machine. The most likely place to find the settings on a UNIX system machine is in the file /etc/conf/cf.d/mtune
, but this can vary from one platform to another and between versions of the UNIX operating system. See the system administrator's guide for your machine for information about how to find and change these parameters. If you are using the BEA TUXEDO system on a Windows NT platform, there is a control panel that displays and sets IPC parameters.
As with most procedures in this guide, we start by setting the environment:
../bankvar
The variables particularly needed by tmboot
are TUXCONFIG
, APPDIR
, and TUXDIR
. The command to boot the complete application is the following.
tmboot
Running this command causes the following prompt to be displayed.
Boot all admin and server processes? (y/n): y
When you respond y
to the prompt, you get a running report that starts like this.
Booting all admin and server processes in /usr/me/appdir/tuxconfig
Booting all admin processes
exec BBL -A:
process id=24223 Started.
The display continues until all servers in the configuration have been started. It ends with a count of the number of servers started.
There are options that can be used to boot only a portion of the configuration. For example, if the -A
flag is used, only administrative servers are booted, but with no options specified, everything is booted.
In addition to the report on servers booted, tmboot
also sends messages to the ULOG.
We have referred previously to the ULOG
, but this is the first time it has actually played an important role in the process under discussion. It is called ULOG
(short for user log) because that is the default prefix; the actual file name of the log is ULOG
followed by the date in the form: .
mmddyy
. Log messages can be directed to ULOG
from user-written modules through a call to userlog
(3c), but the ULOG
is also used heavily by BEA TUXEDO system processes such as tmboot
.
The populate.sh
script is provided with bankapp
to put enough records into the database to work with. 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 file of the records created is kept in pop.out
, so you can use values that are in the database when forming your sample service requests. The script is run just by entering the following word.
populate
For more information about tmboot
, see Chapter 4, "Starting and Shutting Down Applications," in Administering the BEA TUXEDO System.
Chapter 7, "Error Management," of the BEA TUXEDO Programmer's Guide contains background information on the user of the userlog
. Throughout that guide there are examples of messages being sent to the log.
The following pages in the BEA TUXEDO Reference Manual are important:
tmboot
(1)