lab exercises - pudn.comread.pudn.com/downloads142/doc/618733/tux-a11-80/a11-lab-guide.pdf · the...

Copyright © 2001, BEA Systems, Inc

BEA TUXEDO Application Administration

TUX-A11-XX-01

Lab Exercises

BEA Systems, Inc. Educational Services

BEA Tuxedo Application Administration

TUX-A11-XX-01 Copyright © 2000, BEA Systems, Inc 2

Copyright © 2001, BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from BEA Systems, Inc. Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the BEA Systems License Agreement and in subparagraph (c)(1) of the Commercial Computer Software-Restricted Rights Clause at FAR 52.227-19; subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (d) of the Commercial Computer Software--Licensing clause at NASA FAR supplement 16-52.227-86; or their equivalent. Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. Trademarks or Service Marks BEA, BEA eLink, BEA Jolt, Distributed Application Framework, and Enterprise Middleware Solutions are trademarks of and are developed and licensed by BEA Systems, Inc., Sunnyvale, California. TUXEDO is a registered trademark of Novell, Inc., exclusively licensed to BEA Systems, Inc. OpenView is a registered trademark of Hewlett-Packard Company. SunNet Manager and Solstice are trademarks of Sun Microsystems, Inc. in the United States and other countries. IBM and NetView are registered trademarks of International Business Machines Corporation. Oracle is a registered trademark of Oracle Corporation. Informix is a registered trademark of Informix. Cabletron Spectrum is a trademark of Cabletron Systems, Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. All other company names may be trademarks of the respective companies with which they are associated.


Document Edition Part Number Date Software Version Comment 1.0 Sep 2001 BEA Tuxedo 6.5, 7.1,8..0 Initial Labs Version


TUX-A11-XX-01 Copyright © 2000, BEA Systems, Inc i

Contents

General Lab Instructions ............................................................. 3 Lab Instructions ........................................................................ 3 Environment Variables ............................................................. 3 Lab Directories ......................................................................... 5

INSTL–Lab Installation and Verification ...................................... 7 Part 1 – Copying the Lab Files ................................................. 8 Part 2 – Viewing the Tuxedo Documentation ......................... 10 Part 3 – Verifying the Lab Machine Environment ................... 10 Part 4 – Building Tuxedo Programs for the Lab Workshops .. 11

DEPL–Deploying a Basic Tuxedo Application .......................... 13 CONF–Configuring Application Servers.................................... 17 ADAC–Administration and Additional Configuration ................. 21 CLNT–Configuring /WS Support ............................................... 25 SECU–Configuring Tuxedo Security......................................... 29 MMC–Multiple Machine Configuration ...................................... 33 SRVG–Server Groups and Data Dependent Routing ............... 37 TRAN–Configuring Transactions .............................................. 41 CQUE–Administering Queues .................................................. 45 MIBS–Accessing MIBs.............................................................. 51 PERF–Performance Considerations ......................................... 55 DOMS–Multiple Domains........................................................... 59



General Lab Instructions This guide contains general instructions for the lab workshop exercises for the BEA Tuxedo Application Administration course. The course lab exercises can be performed on a system with either BEA Tuxedo 6.5, 7.1, or 8.0 software installed. The lab exercises can be performed in a variety of classroom environments, both public classrooms and on-site customer locations. The lab exercises are supplied for two generic platform types – UNIX (Sun, HP, other versions) and Microsoft WindowsNT/Windows2000. The lab machine/s used should have been previously set up for the class; the BEA Tuxedo product and a C compiler should be installed. On Windows systems, the only C compiler tested with the labs is Microsoft Visual C++ 6.0. The lab exercises are labeled with the same abbreviated module name used for a particular Module in the student material, for example INSTL. Each exercise describes the objective and the steps for performing the exercise. Consider the time suggested for each lab as a “guideline” and not a requirement. Your instructor will end the lab session when it is appropriate.

Lab Instructions

Instructions for each lab are usually common for both Windows and UNIX and any differences are noted in the instructions. The first set of actions that you will perform for any lab is common to all labs and are: 1. Open a Windows/DOS command window or UNIX shell window. 2. Change directory to the lab exercises directory – the lab refers to the <xyz> lab directory:

[Windows]: cd <root-directory>\exercises\<xyz> [ UNIX]: cd <root-directory>/exercises/<xyz>

3. Edit the setenv command script file that sets the environment variables: [Windows]: setenv.cmd [ UNIX]: setenv.ksh

4. Execute the setenv command script file: [Windows]: setenv [ UNIX]: . setenv.ksh (Note the <space> between . and setenv.ksh)

Environment Variables You should make sure that the environment variables shown below are set. In Windows, you can edit your system environment variables through the Control Panel so that these are always set when you startup a DOS or shell command prompt. The actual paths may differ for your system, for example Tuxedo might be installed in D:\ instead of C:\ as the table below suggests. Set environment variables according to your computer-specific installation directories. For the PATH environment variables, we suggest that you add the paths listed in the table below to the



beginning of the variable because you might have other software installed that may interfere. If you choose not to change the environment variables and use the provided setenv.bat or setenv.ksh file, you may need to edit this file to reflect your actual installation folders. For Windows systems:

Env. Variable Windows Example Description TUXDIR C:\tuxedo Tuxedo installation directory TUXCONFIG C:\tuxa11\exercises\depl\tuxconfig Location of TUXCONFIG PATH %TUXDIR\bin;%PATH%

Path should include the Tuxedo bin directory

TUXDIR should be set on supported Windows platforms when Tuxedo 6.5 or 7.1 is installed. Tuxedo 8.0 installation does not set these environment variables and they have to be set either in the Settings-> Control Panel-> System->Environment control panel or before executing a Tuxedo program. In the lab exercises, we will usually set them for each lab exercise. For UNIX systems:

Env. Variable UNIX Example Description TUXDIR /opt/tuxedo71 Tuxedo installation directory TUXCONFIG /home/stu01/exercises/abcs/tuxconfig Location of TUXCONFIG PATH .:$TUXDIR/bin:$PATH

/opt/.. or /usr/..

Path should include these Tuxedo related directories… … and any C compiler directories…

<include directory path>

$TUXDIR/include Usually specified in the compile command

LD_LIBRARY_PATH (SVR4, Solaris) SHLIB_PATH (HP-UX) LIBPATH (AIX)

$TUXDIR/lib:$LD_LIBRARY_PATH $TUXDIR/lib:$SHLIB_PATH $TUXDIR/lib:$LIBPATH

Add the Tuxedo library directory to the library search path

LANG C or En_US

If you get Tuxedo catalog errors, you may need to reset this to “C” instead of En_US; check which of these two directories has been installed under the $TUXDIR/locale directory

TUXDIR – obtain the directory name where Tuxedo has been installed on the UNIX system from the Instructor or the UNIX Administrator.



Lab Directories The parent directory for the lab exercises contains files used to build the lab exercises. It also contains the exercises and solutions sub-directories. Each lab exercise directory is under the exercises directory in a different lab-specific sub-directory (this directory will be the application directory, APPDIR). A lab exercise directory is named to match the corresponding module name, for example DEPL but the lab directory name is in lower-case as in “depl”. Each lab exercise directory contains the files required for the lab exercise described. These files include template files (that you need to complete) or completed files: - a template configuration file named UBBconfig.template - a template file, setenv.cmd.template (Windows) or setenv.ksh.template

(UNIX), for setting the environment variables - client and/or server source program template files, <name>.template - completed client or server programs, <name>.c, or executables, <name> in UNIX or

<name>.exe in Windows. The UBBconfig.template configuration file requires the following information to be filled for each lab: machine name The configured system name for this machine TUXDIR The directory where the Tuxedo product is installed APPDIR Application directory, which is the current lab exercise directory TUXCONFIG The TUXCONFIG file in the <APPDIR> directory You will need to change the value of these parameters to the appropriate values and complete any other lab-specific directions. You can obtain the machine name from the %COMPUTERNAME% environment variable or from the Network control panel [Windows], or [UNIX] by ‘uname –n’ or ‘hostname’. Note that for Windows systems, the machine name specified in a Tuxedo configuration file should always be in upper case – example, GUMBY and not gumby. A corresponding lab directory in the solutions sub-directory contains the UBBCONFIG configuration solution files for the lab exercise. You should try to avoid using the solution files unless you are really stuck or the Instructor is busy with other students. The Instructor is there to help you ! Each lab solution directory contains solution configuration files for Windows and UNIX for each lab exercise, generically represented by the lab directory <labname> below. These solution files use the following values for the above information in the solutions: machine name The node name for the system: NODE1 TUXDIR Tuxedo install directory:

[Windows] c:\tuxedo



[UNIX] /opt/tuxedo APPDIR Application directory, the current lab directory: [Windows] c:\tuxa11\solutions\<labname>

[UNIX] /home/student/tuxa11/solutions/<labname> TUXCONFIG The TUXCONFIG file in the <APPDIR> directory: [Windows] %APPDIR%\tuxconfig

[UNIX] $APPDIR/tuxconfig

To use a lab solution, copy the solution files to the equivalent lab exercise directory; replace the above values in the solution files with values appropriate for your lab machine and follow the instructions to run the lab exercise



INSTL–Lab Installation and Verification

Reference Course Section(s): INSTL, Lab Guide: Getting Started

Suggested Time: 40 minutes

Objective The objective of this exercise is to install the labs and make you familiar with the lab exercise environment.

Description You will install the lab exercises from the Student CD supplied with your course materials and become familiar with the lab machine environment. Installing the labs consists of two main tasks – copying the labs from the Student CD and then compiling the C source programs to generate the client and server executable programs for the platform being used for the lab exercises. You will also become familiar with the Tuxedo documentation layout on the Student CD. Finally, you will follow some simple instructions to verify that Tuxedo has been installed on your machine.

Summary There is no lab exercise directory or files associated with this lab exercise. You will need the Student CD packaged with your course materials.

• Copy the labs from the CD-ROM to your lab machine

• View the Tuxedo documentation with a browser

• Verify that Tuxedo is installed on the lab machine

• Build the client and server executable programs for use in the other lab exercises



Steps

Part 1 – Copying the Lab Files (This step may already have been done for the class – check with the Instructor.) 1. All the code and template files that you need to accomplish the Lab Workshop exercises are

supplied on the Student CD-ROM that is bundled with the course Student Materials. This CD is in a PC format and may not be readable on most UNIX machines. • On a Windows system, load the Student CD. • On a UNIX system, the tar file containing the lab exercise files may have already been

copied from the CD to a directory on the system – check with the Instructor. 2. Install the Lab Workshop exercise files: To install the lab exercises on a WindowsNT/Windows2000 system • Create a <lab root directory> such as C:\tuxA11 on your student machine. • Copy the contents (directories and files) from the labs directory on the student CD to this

<lab root directory> on the Windows system: select all files and directories, and drag and drop them into the newly-created labs directory.

• The files copied to your lab directory will be copied as read-only. To change the read-only attributes, open a DOS/Command window and change directory to your lab root directory. Type the following command to change the read-only attributes on all the files:

> attrib –r *.* /S • In the DOS/Command window, verify that the Microsoft Visual C++ 6.0 compiler is installed

by typing “cl”, the command to run the compiler; if it is installed, the banner heading from the compiler will be printed in the window.

• If the previous command fails, try to find and execute the following command file to set the correct system environment. This file is typically located in:

C:\Program Files\ Microsoft Visual Studio\vc98\bin\Vcvars32.bat

Try the previous step again. If this still fails, the Visual C++ compiler may not be installed on the PC you are using. Notify the Instructor.

To install the lab exercises on a UNIX system • If the System Administrator has already transferred the tar file from the Student CD to the

UNIX system, make a copy of the tar file in your lab root directory using the cp command: > cp \…\TUX-A11-XX-01-labs.tar .

• If not, transfer the labs\UNIX\TUX-A11-XX-01-labs.tar file from the student CD to the student’s <lab root directory> on the UNIX system being used. You can use FTP binary mode to transfer the file. An example of <lab root directory> is /home/student01.

• Use tar to uncompress the TUX-A11-XX-01-labs.tar file: > tar xvf TUX-A11-XX-01-labs.tar



3. This completes the copy of the lab files to your directory. For both Windows and UNIX systems, the previous steps will create a directory structure underneath the <lab root directory> containing the lab directories corresponding to the Modules in the Student Guide. The root directory should contain the following sub-directories plus some other command files that will be used to build the client and server programs:

The formats for directory names are (using the Windows path name convention):

• Exercises described in the lab guide: <root-directory>\exercises\ <xyz> • Solutions to exercises in the lab guide: <root-directory>\solutions\<xyz>

where <root-directory> represents the root directory where the labs were installed, and <xyz> and <XYZ> are the lab directory name and the associated module name respectively. There is another step to be done before the lab exercises can be performed – build the client and server program executables to be used for each lab exercise. This is described later in this lab exercise. 4. This completes the copying of the lab files to your machine.



Part 2 – Viewing the Tuxedo Documentation

5. We will now examine the Tuxedo documentation supplied on the Student CD. [If the course is being delivered on a UNIX platform, the Tuxedo docs may have been transferred to a UNIX directory.] Using Windows Explorer or other File Manager, move to the following directory on the Student CD :

[Student-CD] \Tuxedo Docs\ xxx where xxx is either v6_5, v7_1, or v8_0 depending on whether Tuxedo release 6.5, 7.1, or 8.0 respectively is being used in the class.

6. Double-click on the index.htm file in the above directory. This will start-up a browser

program and bring up the Tuxedo documentation index page. The display will be different for

the different Tuxedo releases but there will be common displayed items, including a link to

the (ATMI) Reference section.

Click on the Reference link. Under Reference Topics, you should see several sections such

as Command Reference – Section 1. The Tuxedo reference documentation is organized

into sections very much like UNIX man pages.

7. In the course slides you will see references to items such as tmadmin(1). This means that

the reference information for the Tuxedo command tmadmin is in Section 1 of the reference

documentation. The Tuxedo file formats are in Section 5. Click on this link.

The displayed page shows all the BEA Tuxedo File Formats, Data Descriptions, MIBs, and

System Processes listed in alphabetical order.

8. Click on one of the topics, such as UBBCONFIG(5), displayed in the left column. The

displayed page shows the details of the Tuxedo Configuration file format including all the

required and optional parameters.

Part 3 – Verifying the Lab Machine Environment 9. Open a DOS/Command or Shell window. Display the current environment variables:

• On Windows type: set | more

• On UNIX: env | more



10. Check the listed variables to see if the TUXDIR variable is set. If not, set it – (if needed, ask

your Instructor for the location of the Tuxedo directory on your PC or UNIX system):

[ On Windows] set TUXDIR=<Tuxedo installed directory>

[On UNIX (ksh)] export TUXDIR=<Tuxedo installed directory>

11. If necessary, add the Tuxedo bin directory to your command execution path:

[ Windows] set PATH=%TUXDIR%\bin;%PATH%

[UNIX (ksh)] export PATH=$TUXDIR/bin:$PATH Also, set and export the LIBRARY PATH as appropriate (see the UNIX Environment Table for information on some UNIX systems) to include $TUXDIR/lib.

12. Type the Tuxedo administration command tmadmin with the –v option :

tmadmin –v

This should print out the Tuxedo license information such as

If a message similar to the one above was printed on your console, your environment

variables were set correctly and Tuxedo is installed on your machine.

13. If you get Tuxedo catalog message errors, you may also need to set (and export) the

environment variable that defines the locale, for example:

LANG=C [for US English]

14. This completes the initial lab installation.

Part 4 – Building Tuxedo Programs for the Lab Workshops You will now build all client and server executable programs to be used in the lab exercises. These programs need to be built as the lab exercises can be run on a number of platforms, using different versions of operating system and C compiler. The next step requires that the environment is suitably setup - Tuxedo must be installed, the Tuxedo Software Development (SDK) license installed must be valid, and a C compiler must be installed. 15. After installing the lab files, to compile all C programs in the solutions directories and build

the executable programs: - cd to the <root-directory> that contains the exercises and solutions sub-directories



- edit the appropriate buildlabs script file [Windows] buildlabs.bat [UNIX] buildlabs.ksh

to set the environment variables identified there - In the <root-directory>, run the appropriate buildlabs script (examples are below):

[Windows]: Note that you have to supply the root directory name if you did not set it in the buildlabs.bat file.

buildlabs [<root-directory>] [UNIX]: Note the {space} between {. } and {buildlabs.ksh}

. buildlabs.ksh

Windows Example: cd c:\tuxa11 (In a DOS Window) [Edit/set the appropriate environment variables in the buildlabs.bat

file; run the bat file as shown below.]

buildlabs c:\tuxa11 [Note that the root lab directory name is required as a parameter if not set in buildlabs.bat]

UNIX Example: cd /home/student01 (ksh) [Edit/set the appropriate environment variables in the buildlabs.ksh

file; in the command line below note the <space> between “.” and buildlabs.ksh)]

. buildlabs.ksh

16. When the build command script is successfully completed, verify that it has built the client and server executables by looking at the files in a lab directory such as ‘adac” under the exercises subdirectory. There should be some executable program files (*.exe in Windows, executable files in UNIX). If necessary, you can re-run the buildlabs command file again at any time.

17. This completes the lab installation and familiarization. Review the notes in the General Lab

Instructions section at the beginning of this Lab Guide to become familiar with the generalized instructions for the rest of the Lab Workshop exercises.



DEPL–Deploying a Basic Tuxedo Application

Reference Course Modules: DEPL


Objective You will be following instructions to make you familiar with the computer and lab exercise environment, and to configure and run a basic sample application to verify the successful installation of the Tuxedo product. In doing so, you will also be deploying a simple Tuxedo application. You will be performing some of these instructions in this lab without fully knowing the details, such as the configuration file, that will be explained later. An important objective of this lab exercise is to make you comfortable with the lab environment and begin to use some of the basic Tuxedo commands.

Description The configuration for this lab is a basic single machine (SHM mode) application with one client and one server. This basic application, which is shipped with the BEA Tuxedo product, is called simpapp. It consists of the simpcl client that sends a text string, supplied by the user, to the TOUPPER service implemented in the simpserv server. The TOUPPER service converts the text string to uppercase and returns the resultant text string to the client for display to the user. The following files are provided • command script files to set the appropriate environment variables (setenv.cmd for

Windows, setenv.ksh for UNIX) • a template Tuxedo configuration file, UBBconfig.template • a client source program, simpcl.c (that you will copy from the Tuxedo product directory) • a server source program, simpserv.c (that you will copy from the Tuxedo product

directory)



Steps 1. The working directory for this lab is depl in the lab exercises directory.

• Open a [Windows] DOS command or [UNIX] shell window and “cd” to this directory.

2. Edit the appropriate setenv command file replacing the remarks within <> with appropriate values for TUXDIR, APPDIR, TUXCONFIG :

[Windows] setenv.cmd

[UNIX, Korn shell] setenv.ksh

Set the environment variables using:

[Windows] >setenv [Note: Runs the setenv.cmd file]

[UNIX, Korn shell] $. setenv.ksh [Note: <space> between “.” & “setenv.ksh”] 3. Copy or rename the UBBconfig.template file to UBBconfig.

[Note: This configuration file is almost identical to the one supplied with the simpapp application, except that we are using the configuration file name convention that we will use for the rest of the lab exercises.]

4. Edit the UBBconfig file:

• set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the machine name in the MACHINES section.

5. Build the TUXCONFIG file using the command:

tmloadcf -y UBBconfig Ignore the warning message “WARN: Missing SERVICES section”. If you encounter any other errors, edit the configuration file and correct the errors. Re-build the TUXCONFIG file.

6. Copy the client and servers programs, simpcl.c and simpserv.c, from the TUXEDO

sample applications directory into the lab directory (depl): [Tuxedo 6.x]

Windows: copy %TUXDIR%\apps\simpapp\simpcl.* UNIX: cp $TUXDIR/apps/simpapp/simpcl.* .

[Tuxedo 7.1, 8.0] Windows: copy %TUXDIR%\samples\atmi\simpapp\simpcl.* UNIX: cp $TUXDIR%/samples/atmi/simpapp\simpcl.* .

Repeat the appropriate command above to copy simpserv.* to the current directory.

7. Build the client program executable using the buildclient command:

buildclient -v -f simpcl.c -o simpcl



This builds a Tuxedo client executable, simpcl, from the C source file, simpcl.c.

8. Build the server program executable using the buildserver command:

buildserver -v -f simpserv.c -o simpserv -s TOUPPER

This builds a Tuxedo server executable, simpserv, from the C source file, simpserv.c, that will provide a service called TOUPPER when it is started. This server is defined in the Tuxedo configuration file.

9. Boot the application using the Tuxedo command:

tmboot -y

10. Run the Tuxedo administration command line utility program, tmadmin:

• Use the printserver subcommand to view the active servers

• Use the printservice subcommand to view the information on services

• Exit from tmadmin with the quit subcommand

11. At the command line prompt, run the client and observe the input text string returned as an uppercase string:

simpcl “hello tuxedo”

12. Re-run the tmadmin program, and run the same sub-commands as before to observe any difference in the statistics printed. (Hint: We submitted a request for the TOUPPER service that was completed successfully and was performed by the SIMPSERV server). Exit the tmadmin program.

13. Shut down the Tuxedo application system:

tmshutdown -y 14. Tuxedo messages are logged in a file called the userlog or ULOG file. The file is named

ULOG.mmddyy where mmddyy are the two-digit month, day, and year respectively. For example, the file for August 9, 2001 would be named ULOG.080901. We will cover the details of the ULOG file later; for now, be aware that this log file exists and contains valuable error and information messages logged by the Tuxedo system.

The ULOG file is a text file and you can examine it with any text editor or with commands such as type or more.

Windows: type ULOG* | more

UNIX: more ULOG* Look up the details of some of the logged messages (such as the LIBTUX_CAT:262 message) in the Messages section of the Tuxedo documentation on the Student CD.



CONF–Configuring Application Servers

Reference Course Chapter: CONF


Objective This lab exercise is intended to provide experience in configuring a functional basic application consisting of essential configuration components and to observer the synchronous client-server communication mechanism.

Description This lab utilizes an SHM configuration with one client and three servers. The clientdb program calls a service (specified on the command line) and then prints out information when it receives a reply back from the server. It operates in a synchronous mode – it sends a request for the service and then waits for the response before sending the next request. The three servers provided are SvrInq, SvrUpdate, and SvrDelete and the services each provides simulate the inquiry, update, and delete operations to a database in a typical application. The following files are provided:

• template command script files to set the appropriate environment variables (setenv.cmd for Windows, setenv.ksh for UNIX)

• template Tuxedo configuration file, UBBconfig.template

• application executables (one client and 3 servers): clientdb; servers SvrInq, SvrUpdate, and SvrDelete



Steps 1. The working directory for this lab is conf in the labs exercises directory.

2. Edit and set the environment variables.

3. Copy or rename UBBconfig.template to UBBconfig.

4. Edit the UBBconfig file, supplying the required information, and build the TUXCONFIG

file:

• set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the

machine name in the MACHINES section

• add a server group GROUP1 with group number 1

• add three servers (SvrInq, SvrDelete, SvrUpdate) and with SVRIDs of 10, 20,

and 30 respectively. Configure each server to belong to server group GROUP1.

• Build the TUXCONFIG file.

5. Boot the application.

6. Run the synchronous client for each advertised service name to verify operation and compare the response times of the services.

The clientdb client program is run with the following parameters:

clientdb –s <service> -i <count> -w <seconds> -v

where <service> is Inq, Delete, or Update

<count> is the number of requests to send (default = 1)

<seconds> is the wait time in seconds between requests

and –v specifies verbose mode to print out response times in seconds

For example, to submit four requests to the Inq service, waiting one second between requests and have the response times printed on the console, we would use:

clientdb –v –s Inq -i 4 -w 1

Run the clientdb program with the parameters above.

7. Repeat the previous step with each of the other service names, Delete and Update.

8. Run the Tuxedo administration command line utility program, tmadmin:



• Use the psr subcommand to view the server information

• Use the psc subcommand to view the services information

9. Shut down the application system.

10. Examine the ULOG file to observe the messages indicating the start-up of the servers.



ADAC–Administration and Additional Configuration

Reference Course Chapter: ADAC


Objective This lab exercise is intended to provide experience in using some other useful sub-commands of the Tuxedo administration command utility, tmadmin, and in configuring additional options for application servers. The lab also explores the use of the ULOG file and allows the student to observe the asynchronous client-server communication mechanism.

Description This lab utilizes an SHM configuration with one client and one server. The client calls a service (specified on the command line) and then prints out information when it receives replies back from the servers. The client program (clientdba) operates in an asynchronous mode. It sends multiple (asynchronous) requests without waiting for the response to an earlier request and then gets the responses back at a later time. The server provided is the SvrInq server to simulate an inquiry operation to a database. The following files are provided:



• application executables (1 clients and 1 servers): clientdba, SvrInq



Steps 1. The working directory for this lab is adac in the labs exercises directory.

2. Edit and set the environment variables. 3. Copy or rename UBBconfig.template to UBBconfig. 4. Edit the UBBconfig file, supplying the required information:

• In the RESOURCES section, set the SCANUNIT to be 10 (the default) and SANITYSCAN value to be 6 (this means that a sanity scan of the Bulletin Board will be preformed every 6*10=60 seconds by the BBL process)

• set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the machine name in the MACHINES section

• add a server group GROUP1 with group number 1 • add one servers (SvrInq) that belongs to GROUP1 and with a SVRID of 10. The server

should be configured with the standard CLOPT parameter to advertise all services when it is booted. The server should also be configured to be restartable, the value for the number of times it is restartable (MAXGEN) should be set to 4, and the grace period (GRACE) should be set to be 120 (seconds).

5. Build the TUXCONFIG file.

6. Boot the TUXCONFIG application.

7. Run the asynchronous client clientdba to submit multiple requests to the Inq service and note the order in which the requests are sent and are completed. The clientdba client sends it’s requests asynchronously so it does not have to wait for the server to respond before sending another request. The clientdba takes several parameters:

clientdba –v –s <service-name> -i <count> -w <seconds>

where

-s <service-name> causes the service service-name to be called

-i <count> is the number of requests to send (default = 1)

-w <seconds> is the wait time in seconds between requests

and –v specifies verbose mode to print out response times in seconds

Submit four requests to the Inq service, waiting one second between requests, and obtain the response times printed on the console:

clientdba –v –s Inq -i 4 -w 1



10. Kill the SvrInq server using [UNIX] kill or [Windows] Task Manager. Wait for about 60 seconds. Check (using tmadmin) to determine if the server was re-started. After what approximate period of time did the server restart and which Tuxedo component re-started it ?

11. After the SvrInq is re-started, kill it again. Now immediately, perform

tmadmin

>bbclean

What was the difference from the previous step ? Why ?

12. Shut down the application system.

13. Edit the configuration file:

• Add the configuration entry in the MACHINES section that will cause the user log file to be called “<machine_name>.mmddyy” (instead of the default ULOG name), where <machine_name> is the machine name for this system.

• Modify the SvrInq server entry so that a minimum of 2 servers and a maximum of 5 servers are started when the application is booted.

14. Build the TUXCONFIG file from the modified UBBconfig file.

15. Boot the TUXCONFIG application.

16. How many SvrInq servers were started ?

17. Run the asynchronous client as before. Were additional servers, above the configured minimum, started to handle the increased load ?

Using tmadmin, start two more servers (a total of 4 active servers) and re-run the client program again. Was there any improvement in any of the response times as reported by the client program ?

18. View the user log file created. Identify the entries that indicate the start-up of each server.

19. At the command line, enter the following command to view the IPC resources allocated to the running Tuxedo application:

ipcs

20. Shut down the Tuxedo application.

21. Enter the ipcs command again to verify that all IPC resources used by the Tuxedo application have been released.

22. If time permits, re-boot the Tuxedo application and explore the use of other tmadmin commands.



CLNT–Configuring /WS Support

Reference Course Chapters: CLNT


Objective This lab exercise is intended to provide experience in using network addresses in Tuxedo configurations and in configuring /WS clients in Tuxedo applications.

Description The configuration for this lab includes an SHM environment with one application server and one WSL listener. The listener is configured with two WSH handlers. The WS client requests a service with a text string as data. The service checks whether the text string is an expected string and returns either success or failure. The following have been provided:

• template command script files to set the appropriate environment for the workstation and server variables (setenv-cws.cmd for Windows, setenv-cws.ksh for UNIX for the /WS‘client; variables (setenv-sm1.cmd for Windows, setenv-sm1.ksh for UNIX for the server side)

• a template Tuxedo configuration file, UBBconfig.template; comments indicate adding workstation-support configuration entries: setting MAXWSCLIENTS, adding and configuring the WSL server.

You will initially use your system as both the Tuxedo server machine and the Tuxedo workstation client machine. The WS client request will be transferred through a network protocol stack on the machine back to itself and then on to the server as if the latter was on a different machine connected via a network.

• A client executable, clientws (note that the program source code clientws.c does not have any /WS code dependencies in it; it could also be built to run as a native client)

• A server executable, serverws On individual Windows machines, you may use any (>4096) port number, such as 9055, for the WSL listening network address. If the lab exercises are being performed on a shared UNIX system, the Instructor will coordinate the use of TCP/IP network port numbers to avoid conflicts among students.



Steps 1. The working directory for this lab is clnt in the labs exercises directory.

2. Edit the appropriate setenv file setenv-sm1 and set the appropriate environment variables; run the setenv-sm1 file to set the environment variables.

3. Copy or rename the UBBconfig.template file to UBBconfig. Edit the UBBconfig

file, supplying the required information: • set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the

machine name in the MACHINES section • in the MACHINES section, add an entry to support a maximum of 5 workstation clients • add a WSL server entry to support 2 WSH’s and with a listening address


5. Boot the application. 6. Open another command/shell window. This will be the “workstation” window that will act as

if you are running the client from a remote /WS machine. 7. In this new workstation window, change directory to netw in the labs exercises directory as

before. ��Edit the appropriate setenv-cws file and set the appropriate environment variables ��Run the setenv-cws file:

Windows: >setenv-cws

UNIX: $. setenv.ksh

��The /WS client, clientws, has already been built (Note that the –w option was used to specify a /WS client instead of a native client):

��Run the /WS client in the workstation window:

clientws

You should get a message stating that the tpcall succeeded.

If the tpcall fails, examine any messages printed in the client window and examine the ULOG file/s to determine the cause of the failure. Correct the problem and run the client program again until it is successful.

8. Run the tmadmin command.

• Use the pclt sub-command to view the active clients. You would usually see native clients. In fact, tmadmin itself is a client as shown in the pclt output. In this exercise you also see the WSH client processes, that act as the proxy (native) clients for the remote /WS clients.



9. Next, reset the WSNADDR to point to the WSL address (node name and port number) of the student partner next to you. Re-run the client program (first verify that your student partner has booted his/her application) and verify that it connects to your partner’s application.

10. When both of you have managed to connect to each other’s application (machine) through the remote machine’s WSL, shut down the application.



SECU–Configuring Tuxedo Security

Reference Course Chapter: SECU


Objective This lab exercise is intended to provide experience in configuring and using the BEA Tuxedo-provided authorization server, AUTHSVR. This lab exercise also involves the use of access control lists (ACL) using the Tuxedo-provided utility programs (tpgrpadd, tpusradd, tpacladd).

Description This lab uses a ping service that, if successful, returns the client’s APPKEY. The APPKEY is a token that is passed with client requests after the client has successfully logged-on to the Tuxedo application. The client solicits an application password, user-id, and user password, and passes this information to the application when it first connects to Tuxedo. If the client fails to log-on, an error message is displayed. If the log-on is successful, the client calls the GETAPPKEY service that returns the APPKEY and the client displays the APPKEY. Otherwise, it displays “Could not retrieve APPKEY - Service access denied.” The configuration includes an SHM environment with a single server. An AUTHSVR is configured, and BEA Tuxedo user accounts are set up with ACLs enabled to control access to the one service. The following files are provided:

• template command script files to set the appropriate environment for the workstation and server variables (setenv.cmd for Windows, setenv.ksh for UNIX)

• template Tuxedo configuration file, UBBconfig.template with comments to add Tuxedo security configuration options (SECURITY, AUTHSVC, etc.)

• application client and server executables (clientsec, serversec)



Steps 1. The working directory for this lab is secu in the labs exercises directory.

2. Edit and run the appropriate setenv file to set the environment variables.

3. Copy or rename the UBBconfig.template file to UBBconfig.


• set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the

machine name in the MACHINES section

• in the RESOURCES section, configure the appropriate security parameters for

Mandatory ACL (this also includes application password security) and the appropriate

authorization service provided by the Tuxedo AUTHSVR server

• in the SERVERS section, add the entry for the AUTHSVR authorization server


• Enter an application password when prompted (you may choose any password but make a

note of it as you will require it later)

• Re-enter the same password when prompted again

6. Create a security group (choose a group number and name) and add it using:

tpgrpadd -g <groupnumber> <groupname>

7. Add a new user (choose a user-number and user-name); when prompted for a password, choose any password. Make a note of the username and password you enter as you will need it later.

tpusradd -u <usernumber> -g <groupnumber> <username>

8. Create a new Access Control List using the tpacladd command:

tpacladd -g <groupnumber> -t SERVICE GETAPPKEY


10. Run the client:

clientsec

You will be prompted for the application password, the user name, and the user password. Enter values for each when prompted. Observe that the client returns its APPKEY.

11. Run the client, supplying incorrect values when prompted. Observe that an error is returned indicating a failure to log-on to Tuxedo.



12. Delete the user from the Tuxedo security file:

tpusrdel <username>

13. Run the client again using the correct application password and the user name and password you just deleted. Observe that an error is reported now that the user is not in the database.

14. Shut down the application.

LAB EXERCISES

Copyright © 2001, BEA Systems, Inc

MMC–Multiple Machine Configuration

Objective To configure a multiple machine Tuxedo application and to become familiar with the Tuxedo administration commands for transferring the Master role to a backup.

For this lab, you will partner with another student to perform the exercise.


Description The configuration for this lab is a two-machine MP configuration, one server group on each machine, and one server in each group. The application is a simple “Ping” service. A server gets its server-id and operating system process-id (PID) during initialization. Each time the “Ping” service is called, it replies with its Tuxedo server-ID and PID. The client (clientping) calls the “Ping” service in a continuous loop with a one-second sleep between calls, and displays the server instance that responded. The client checks for and reports any errors.

The following files are provided:

• Application executable programs (clientping, serverping) on this machine (these applications may need to be transferred to the second machine’s APPDIR and rebuilt )

• setenv files for the supported environments

• A mostly-complete UBBconfig template file, with 2 groups and 1 server in each group, with comments to add a backup machine’s LMID to the MASTER parameter

• Makefile(s) for the Windows and UNIX environments to re-build the applications on the second machine, if necessary

For this lab, you will partner with another student to perform the exercise.

If you are using an individual Windows workstation, work with your partner and replace the tag <Replace with Machine-Name 2> in the UBB file with your partner’s (other) machine %COMPUTERNAME%. You may do the lab together on either machine or work on the configuration independently until you need to test. For NLSADDR port number, you may use a number such as 3050; for NADDR use a number such as 9003.

If you are using a UNIX machine to perform the labs, your Instructor will provide you with the information on the second UNIX machine (hostname, Tuxedo install directory, and the student exercise directory) to be used on the secondary machine. Your Instructor will also assign you TCP/IP portnumbers so there are no conflicts on the shared UNIX systems.



Steps

The working directory for this lab is is mmc in the labs exercises directory.

1. On UNIX: Open a shell window on the primary system you have been using for the lab exercises.

On Windows: Open a DOS/Command window.

2. Change directory to the exercise working directory above.

3. Edit the setenv file setenv-sm1 appropriate for your environment (either .cmd or .ksh) and complete the required environment settings. Run the command file to set the environment variables.

4. Set up a lab exercise directory (APPDIR) for the non-Master machine of your (partner’s) configuration:

• On Windows: Create a sub-directory called sm2 and copy the server executable file, serverping.exe, to this directory. This sub-directory (sm2) will be the APPDIR for the non-Master machine and the TUXCONFIG file for this machine will be placed in this directory. Both you and your partner can create a configuration environment independently and then boot/test each other’s MP configuration in turn.

• On UNIX: This will be on the second UNIX machine being used. Your Instructor will provide the necessary information and you could be using a different UNIX user-id and application directory. This directory will be the APPDIR for the non-Master machine and the TUXCONFIG for this machine will be in this directory.

5. Copy or rename UBBmp.template to UBBmp. Edit the UBBmp file:

• set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the machine name in the MACHINES section for the Master machine (this is the machine that you are working on)

• set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the machine name in the MACHINES section for the non-Master machine (in a Windows environment, this will be your Partner’s machine although you may also be setting up a similar APPPDIR on your machine for the testing of your Partner’s UBBmp configuration)

6. Build the TUXCONFIG file using the tmloadcf -y UBBmp command.

7. On UNIX: Start the tlisten process on this primary (master) machine with (use the NLSADDR address/portnumber specified in the UBBmp file):

tlisten -l //<primary_machine:portnumber>

On Windows: In the Control Panel, double click on the TUXEDO Administration icon. Under the Listener tab, verify that the Listener (tlisten) service is running and that the port number matches the NLSADDR in the UBBmp file; if not, stop and remove the current



Listener and then add and start a Listener with the correct port number. Alternatively, you can start tlisten in the DOS/command window using the same command as for a UNIX system.

This completes the initial preparation on the master machine.

8. On Windows: Your Partner will have set up the non-Master machine (from your UBBmp configuration point of view) and you can skip to Step 10.

9. On UNIX: Open another shell window on the non-Master UNIX system being used. Change directory to the directory specified in the UBBmp as the APPDIR for this machine. Copy the lab exercise files to this directory. If it is a different platform than the Master machine, you will need to rebuild the server executable on that platform.

• Edit the setenv file setenv-sm2.ksh and complete the required environment settings for this machine. Run the command file to set the environment variables on this secondary machine.

• Rebuild the client and server programs (although only the servers are really required):

�� [UNIX] make –f make.mk all

• Start the listener process (or service on Windows) using the NLSADDR address specified in the UBBconfig file.

tlisten -l //<secondarymachine:portnumber>

This completes the preparation on the UNIX non-Master machine.

10. Check with your Partner that the non-Master machine’s APPDIR is setup. From the Master machine, boot the system using the tmboot -y command. Verify that the application has been started on both machines.

11. On the Master machine, run the client clientping and observe the client output:

clientping

12. Shutdown the server group on the Master machine.

13. Rerun the clientping client from the primary/Master machine and observe the client output. To which servers are the service requests now being routed ?

14. Restart the server group that was shutdown on the Master machine.

We will now perform the Administration task of switching the Master role to the backup machine and back again.

15. From the Backup (non-Master) machine, run tmadmin. Transfer the Master machine role to the backup machine. The backup machine is now the Master machine.

16. From the (original) Master machine, transfer the Master role back to this machine.




SRVG–Server Groups and Data Dependent Routing

Reference Course Module: SRVG


Objective This lab exercise is intended to provide experience in using the features of Server Groups to configure and perform Data Dependent Routing (DDR), and to configure and migrate servers to a backup machine.

You will work with your student partner (from the previous lab exeercise) to perform this lab exercise.

Description This lab uses a funds transfer application. For simplicity, the servers do not use a real database. Instead, the Account IDs and balances are maintained in memory structures that are initialized from the supplied data/text files, one for each server. Each server advertises a deposit service and a withdraw service. Each service accepts an account number and an amount, performs the function, and returns the new account balance. The client accepts “from” and “to” account numbers, and a transfer amount. It implements the transfer by calling the withdraw and deposit services in sequence. It then prints the new balance for each account. The configuration includes an MP domain with two groups and one server for each group. Each server group is configured to run on one machine, with the option of being migrated to the other machine as a backup. The following files are provided:


• template Tuxedo configuration file, UBBconfig.template; both server instances are in a single group. Comments guide you to configure one of the instances in a second group, add a ROUTING section, and add the ROUTING option to the *SERVICES section

• Application executables (clientddr, serverddr)

• An FML32 file (ddr32fml)

• Data files for the servers (acct1.data, acct2.data)



Steps 1. The working directory for this lab is srvg in the labs exercises directory.

2. Edit and run the appropriate setenv file to set the environment variables. 3. Copy or rename UBBconfig.template to UBBconfig. Edit the UBBconfig file,

supplying the required information: • In the RESOURCES section, modify the OPTIONS parameter to enable server group

migration • set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the

machine name in the MACHINES section for the two machine entries • two server groups TRANSFER1 and TRANSFER2 are already configured with LMID’s

SITE1 and SITE2 respectively. Each group contains one server, serverddr. Modify the server group entries so that each server group has a backup LMID to support server group migration.

• add a ROUTING section to the configuration file. In this section, add a routing entry called ACCOUNT_ID that will route service requests based on the FML32 field ACCOUNT, with account numbers 1-10 being routed to the TRANSFER1 group and numbers 11-20 routed to the TRANSFER2 server group.

• in the SERVICES section, add the ROUTING parameter to the DEPOSIT and WITHDRAW services to reference the ACCOUNT_ID routing entry



We will first perform the Data Dependent Routing part of this exercise.

6. Run the client program:

clientddr

• Enter “1” as the account number to transfer money from, “11” as the account

number to transfer money to, and an amount to transfer.

7. Run the client program again and try different account numbers in the configured account

number ranges; verify the correct routing of client requests to each of the servers by

observing the tmadmin statistics.

We will now perform the Server Migration part of this exercise.

8. Using tmadmin, migrate the server group, TRANSFER1, from the primary to the secondary/backup machine: tmadmin >d -m all



>psr >shutdown -R -g TRANSFER1 >migg TRANSFER1 >psr >quit

9. Rerun the client and observe that the requests are still routed to the correct server group on the backup machine.

10. Shut down the application when you have verified that the DDR configuration is correct and that the server migration was performed successfully.



TRAN–Configuring Transactions

Reference Course Module: TRAN


Objective This lab exercise is intended to provide experience in configuring a Tuxedo transaction application and to observe the content of the TLOG that indicates active transactions.

Description The configuration includes a SHM-mode application with the null Transaction Management Server, TMS, provided with the Tuxedo product; . The null TMS server is useful in providing servers, that do not access a Resource Manager, the capability to participate in a transaction by returning a successful or unsuccessful return from the service – a successful return allows the transaction to be committed while an unsuccessful return means that the transaction must be aborted. We will also build our own copy of the null TMS to experience the process of building a simple TMS server. Typically the Application Developer or Database Administrator will build the custom TMS server since the process requires some knowledge of the RM (such as Oracle) libraries.

The application is a hotel reservation system. There are two clients: • clientfrequent requests the FREQUENTPROGRAM service (not associated with any

RM) to check and report its number of frequent stay points • clientreserve reserves a free room using its frequent stay points. It begins a

transaction, calls all four services in transaction mode, and then commits the transaction. It first calls the FREQUENTPROGRAM service to ensure that it has enough points, then the ROOMAVAILABLE service to ensure that it can secure a room, then the PAYMENTVERIFICATION service to ensure that its credit card is valid, and finally, the RESERVATION service to actually book the room. Any errors are reported throughout the transaction activity.

There are four services, one per server. 2 servers are in one group with the null TMS, a third server is in a second group also with the null TMS, and a fourth server is in a third group not configured with a TMS. The following files have been provided:



• template command script files (setenv.cmd for Windows, setenv.ksh for UNIX)

• a template Tuxedo configuration file, UBBconfig.template; a functional non-transactional version with comments to guide you to add the transaction-related parameters (MAXGTT, TLOG, TMS, etc.)

• Client (clientfrequent, clientreserve ) and server ( serverfrequent, serverpayment, serverreserve, serverrooms) executables

Steps 1. The working directory for this lab is tran in the labs exercises directory.

2. Edit the setenv file appropriate for your environment (either .cmd or .ksh) and complete the required environment settings. Run the command file to set the environment variables.

3. Copy or rename the file UBBconfig.template to UBBconfig. Edit UBBconfig:


• add the entries for the TLOG: TLOGDEVICE: use the file TUXFS in the <APPDIR> TLOGNAME: use TLOG TLOGSIZE: use 100 blocks

• add a transaction management server called “TMS” to the server groups APPGRP1 and APPGRP2. No OPENINFO/CLOSEINFO strings are required for this TMS.


5. Using tmadmin, create the device list (Tuxedo filesystem) TLOGDEVICE (use the same pathname as in the UBBconfig entry). Next create a Transaction Log (TLOG) for this logical machine in the TLOGDEVICE:

$tmadmin

• use the crdl sub-command to create the Tuxedo device list with a size of 500 blocks

[UNIX] <TLOGDEVICE> is <APPDIR>/TUXFS

[WINDOWS] <TLOGDEVICE> is <APPDIR>\TUXFS

>crdl -z <TLOGDEVICE> -b 500

• use the crlog sub-command to create the log file for the logical machine specified in the UBB configuration file (LMID=SITE1)

>crlog -m SITE1



• and exit >quit

6. Examine the Tuxedo RM file to gain familiarity with its layout and entries. Look for the entry

for the null TMS (defined by the tag NONE in Tuxedo 8.0). Do not make any changes to the

RM file.

[Windows] %TUXDIR%\udataobj\RM file

[UNIX] $TUXDIR/udataobj/RM file

7. Build a new TMS in the APPDIR using the buildtms command; use the “NONE” tag in the current RM file and an output file name “TMS”. This new TMS executable is actually a duplicate of the null TMS server provided by Tuxedo in <TUXDIR>/bin but we will go through the process of building our own copy so as to gain experience with the buildtms command.

buildtms –r NONE –o TMS


9. Run the first client:

clientfrequent

10. Run the second client:

clientreserve

11. Bring up tmadmin in another window/shell to observe the active transaction’s GTRID entry in the TLOG. Start tmadmin, enter the pt subcommand and note that there are no entries. Then run the clientreserve client again in one window and while it is running successively press <enter> in the tmadmin window to re-execute the pt subcommand. Note the entry for the transaction in the TLOG and that the entry is subsequently removed when the transaction completes.

12. Examine the ULOG file.




CQUE–Administering Queues

Reference Course Module: CQUE


Objective This lab exercise is intended to provide experience in configuring and administering application queues in the /Q subsystem.

Description The configuration for this exercise is a single-machine domain with two server groups (one for the queue group, and one for the application group), two Tuxedo clients, and a Tuxedo server. The application includes two clients. clientenqueue reads a file of names and addresses and for each record enqueues an FML32 buffer to the disk-based queue, ZIPCODEFINDER. The Tuxedo-supplied server TMQFORWARD checks for any enqueued records and forwards them to the service (ZIPCODEFINDER). The service compares the city name for one of 10 preset values, adds the matching zipcode to the record, and replies; the reply is stored in the ReplyQ queue. clientdequeue reads the reply records from the ReplyQ queue and display the records to the user. The following files have been provided:

• template command script files to set the appropriate environment with comments for defining the QMCONFIG environment variable for the supported environments (setenv.cmd for Windows, setenv.ksh for UNIX)

• template Tuxedo configuration file, UBBconfig.template; comments for adding the /Queue components and transaction components (a second server group, TMQUEUE, TMQFORWARD, TLOGDEVICE, TMSNAME, MAXGTT, etc.)

• An FML32 definition file (recordfml)

• Application client executables (clientenqueue, clientdequeue, serverzip); an input data file for the clientenqueue client address.data

Note that you will need another unique IPCKEY for the queue space, in addition to the one you have been using, for this lab. On Windows, use a different number (> 32K) from the IPCKEY used in the UBBCONFIG file. On a shared UNIX system, the Instructor will coordinate the use of an additional IPC key for the queue space.



Steps

1. The working directory for this lab is cque in the labs exercises directory.

2. Edit the setenv file appropriate to your platform – configure the QMCONFIG environment

variable to point to the file QUEFS (in the APPDIR directory) to hold the queuespace. Set the

environment variables by running the setenv command file.

3. Copy the file UBBconfig.template to UBBconfig. Edit UBBconfig:


• in the MACHINES section, add the entries to define the transaction log: TLOGDEVICE: use the file TUXFS in the <APPDIR> TLOGNAME: use TLOG TLOGSIZE: use 100 blocks

• A second server group (QUEUEGRP) is configured with 3 /Q TMS (TMS_QM) servers. Configure the OPENINFO parameter for this server group using the queuespace name TESTQS.

• Add the /Q servers TMQUEUE, TMQFORWARD, and define the CLOPT parameter: for the TMQUEUE server, alias the queuespace TESTQS to the service TMQUEUE; for the TMQFORWARD server, the service/queuename is ZIPCODEFINDER and the idle time between checks of an empty queue is 10 seconds.


5. Create the transaction log (TLOG) using tmadmin.

Use the crdl sub-command to create the Tuxedo device list with a size of 500 blocks

[UNIX] <TLOGDEVICE> is <APPDIR>/TUXFS

[WINDOWS] <TLOGDEVICE> is <APPDIR>\TUXFS

tmadmin

>crdl -z <TLOGDEVICE> -b 500

• use the crlog sub-command to create the log file for the logical machine specified in the UBB configuration file (LMID=SITE1)

>crlog -m SITE1 >quit

6. Run qmadmin to interactively create the queue device file QUEFS (in the APPDIR directory), the queuespace TESTQS and the queues ZIPCODEFINDER, ReplyQ, and ErrorQ, using the parameter values specified below:

• Run the qmadmin utility by entering the following:



qmadmin

• You should see the following information followed by the utility’s command prompt:

qmadmin - Copyright (c) 1996-1999 BEA Systems, Inc.

Portions * Copyright 1986-1997 RSA Data Security, Inc.

All Rights Reserved.

Distributed under license by BEA Systems, Inc.

TUXEDO is a registered trademark.

QMCONFIG=C:\tuxa11\exercises\safq\QUEFS

>

• Create the device by entering the following (Windows style pathname is shown; use

the UNIX pathname for UNIX environments):

crdl <APPDIR>\QUEFS 0 1000

• You should see the following information followed by the utility’s command prompt:

Created device C:\ tuxa11\exercises\safq\QUEFS, offset 0, size 1000 on

C:\tuxa11\exercises\safq \QUEFS

>

• Create the qspace by entering the following:

qspacecreate

• Now enter the following information at each appropriate prompt (use a different

IPCKEY than the one used in the UBBCONFIG file) :

Queue space name: TESTQS

IPC Key for queue space: 55532

Size of queue space in disk pages: 800

Number of queues in queue space: 3

Number of concurrent transactions in queue space: 25

Number of concurrent processes in queue space: 10

Number of messages in queue space: 100

Error queue name: ErrorQ

Initialize extents (y, n [default=n]): y

Blocking factor [default=16]: 16



• Open the newly created qspace by entering the following:

qopen TESTQS

• Create the ZIPCODEFINDER queue by entering the following:

qcreate

• Now enter the following information at each appropriate prompt – to accept the

default, type <Enter>:

Queue name: ZIPCODEFINDER

Queue order (priority, time, fifo, lifo): fifo

Out-of-ordering enqueuing (top, msgid, [default=none]): none

Retries [default=0]: 2

Retry delay in seconds [default=0]: 30

High limit for queue capacity warning (b for bytes used, B for blocks used,

% for percent used, m for messages [default=100%]): 80%

Reset (low) limit for queue capacity warning [default=0%]: 0%

Queue capacity command: < enter>

No default queue capacity command

Queue 'ZIPCODEFINDER' created

• Create the ReplyQ queue by entering the following:

qcreate

• Now enter the following information at each appropriate prompt:

Queue name: ReplyQ








Queue capacity command: <Enter>




Queue ’ReplyQ’ created

• Create the ErrorQ queue by entering the following:

qcreate

• Now enter the following information at each appropriate prompt:

Queue name: ErrorQ








Queue capacity command: < Enter>


Q_CAT:1438: INFO: Create queue - error queue ErrorQ created

Queue ’ErrorQ’ created

• Close the qspace by entering the following:

qclose

• Exit the qmadmin utility by entering the following:

quit

7. Boot the application: tmboot -y

8. Run the client program, clientenqueue – this program stores requests in the ZIPCODEFINDER queue and specifies the ReplyQ queue for storing any reply messages:

clientenqueue

9. Run the client dequeue program (i specifies the number of times the program will check the queue, w specifies the wait time between checks).The clientenqueue program dequeues messages from the queue ReplyQ in the TESTQS queuespace:

clientdequeue –i 30 -w 1

10. Run the clientenqueue program again. After it completes, use the qmadmin facility and some of the subcommands (qlist, qinfo, qspacelist,..) to view information about the queues and queuespace.



11. Run the clientdequeue program and observe the queue entries printed out.


13. Remove the queuespace’s IPC data structures using the ipcrm command:

qmadmin

>ipcrm TESTQS

>quit



MIBS–Accessing MIBs

Reference Course Module: MIBS


Objective In performing this exercise, you will become familiar with formatting and making basic Tuxedo MIB requests. A Tuxedo system application consists of distinct components, each of which can be administered using a Management Information Base (MIB). MIB instructions can be issued as part of the application, or as part of the tasks of a Tuxedo Administrator. A complete reference of the MIBs available for the Tuxedo product can be found in the Tuxedo reference documentation.

Description The configuration for this lab is a SHM domain with one server group and two Tuxedo servers, SvrInq and SvrUpdate. There are no supplied clients with this lab – to run a client, you will run the Tuxedo ud32 utility program which is a client program that takes input data and formats a request to the MIB interface (.TMIB service) based on this data. The following files are provided:


• template Tuxedo configuration file, UBBconfig.template;

• Application server executables (SvrInq and SvrUpdate)



Steps�1. The working directory for this lab is mibs in the labs exercises directory.

2. Edit the appropriate setenv file and set the environment variables including the following:

Note: The environment variables below set the field tables needed to allow ud32 to interface with Tuxedo MIBs:

If you are working on Set these environment variables

UNIX FIELDTBLS32=Usysfl32,tpadm,evt_mib FLDTBLDIR32=$TUXDIR/udataobj

Windows FIELDTBLS32=Usysfl32,tpadm,evt_mib FLDTBLDIR32=%TUXDIR%\udataobj

3. Copy the UBBconfig.template file to UBBconfig.

Edit UBBconfig, set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the machine name in the MACHINES section. Build the TUXCONFIG.


5. Use the tmadmin psr command to verify that all processes have been started.

6. Create a file called getAllServers.dat that describes a MIB request that will retrieve information about all servers. Ensure the fields on a line are separated with ONE tab character, and that there is ONE blank line (additional <cr>) at the end of the file:

SRVCNM .TMIB TA_OPERATION GET TA_CLASS T_SERVER <blank line>

7. Use the following command to execute the MIB request, and redirect the results to a text file

(this runs ud32 as a non- privileged client/user):

ud32 <getAllServers.dat >AllServers.txt

8. Inspect the AllServers.txt file.



9. Copy the getAllServers.dat file to a new file called getMyServerOnly.dat. Add an additional line to this new MIB request file to retrieve specific information for the SvrInq server, as follows (separate the fields on a line by ONE tab):

SRVCNM .TMIB TA_OPERATION GET TA_CLASS T_SERVER TA_SERVERNAME SvrInq <blank line> Note that you can also run ud32 interactively by not specifying the standard input file and then typing the commands one line at a time followed by the additional <cr> for the blank line. The extra <cr> causes ud32 to build the request buffer from the input.

10. Execute the following ud32 command and record the values one of the server’s

TA_SRVGRP and TA_SRVID attributes in the following table:

ud32 < getMyServerOnly.dat

SERVERNAME TA_SRVID TA_SRVGRP

SvrInq

11. Using the above entries, create a new MIB request file called

deactivateMyServer.dat with the following entries:

SRVCNM .TMIB TA_OPERATION SET TA_CLASS T_SERVER TA_STATE INA TA_SRVID <value from above table> TA_SRVGRP <value from above table> <blank line>

Note: Setting a server to an INA(CTIVE) state is the same as shutting down the server with the tmshutdown command .

Run the MIB request file with the following command and observe the output:

ud32 <deactivateMyServer.dat

Why did the TMIB request fail to be executed ?

Now run the MIB request file with the following command: ud32 -C tpsysadm <deactivateMyServer.dat



Use tmadmin with the psr command to verify that the server process has been properly shutdown.

12. Now try to reactivate the SvrInq server with the following:

SRVCNM .TMIB TA_OPERATION SET TA_CLASS T_SERVER TA_STATE ACT TA_SRVGRP GROUP1 TA_SRVID <value from configuration file> <blank line>

13. Now try to add another server with the following entries:

SRVCNM .TMIB TA_OPERATION SET TA_CLASS T_SERVER TA_STATE NEW TA_SRVGRP GROUP1 TA_SRVID 11 <blank line>

14. To activate the new server set its state to ACTive with:

SRVCNM .TMIB TA_OPERATION SET TA_CLASS T_SERVER TA_STATE ACT TA_SRVGRP GROUP1 TA_SRVID 11 <blank line>

15. Use the tmadmin psr command to verify that the server process has been properly

configured and started. Examine the ULOG file. 16. Shutdown the application.



PERF–Performance Considerations

Reference Course Chapter: PERF


Objective This lab exercise is intended to provide experience in using the configuration options related to performance tuning Tuxedo applications

• Setting up MSSQ sets

• Turning on the server high-water/low-water mark server auto-start option

• Turning on the CLOPT -r option for recording service times

Description The configuration includes a SHM application with multiple instances of a server. The following files are provided:

• template command script files to set the appropriate environment for the workstation and server variables (setenv.cmd for Windows, setenv.ksh for UNIX)


• Client and Server executables (clientdba, SvrInq)



Steps

1. The working directory for this lab is perf in the labs exercises directory.

2. Edit and run the appropriate setenv file to set the environment variables.

3. Copy or rename the UBBconfig.template file to UBBconfig. Edit the configuration file to reflect your environment: set appropriate values for IPCKEY, TUXDIR, TUXCONFIG, APPDIR, and for the machine name in the MACHINES section



6. Run the asynchronous client to request the Inq service:

clientdba –v –i 10 –s Inq –w 0

Note the times reported by the client.



• Configure the SvrInq server as an MSSQ set with a minimum of 2 and maximum of 10 servers

• Also configure the MSSQ set to automatically start servers for:

a) High Water Mark: 6 messages; Create Time: 5 seconds

b) Low Water Mark: 3 messages; Terminate Time: 15 seconds

• Configure the SvrInq servers to record service times to a common file Inq.err

(Hint: Where do the serice times get recorded, and how do you specify specific stdout and stderr files for a server ?)

11. Rebuild the TUXCONFIG file.

12. Re-boot the application.

13. Run the asynchronous client again:

clientdba –v –i 10 –s Inq –w 0

Note the response times and compare them to the previous ones. Verify that all servers in the MSSQ set are indeed processing requests.

14. To truly note the benefit of the MSSQ set and see additional servers started up and shutdown based on the number of queued messages, run the asynchronous client with a large number (up to 50) requests and run multiple copies of the clients if necessary:

UNIX: clientdba –v –i 50 –s Inq –w 0 &



Windows: start /B clientdba –v –i 50 –s Inq –w 0 Use the tmadmin commands to verify the distribution of requests and the number of servers running at any time. To do this, run tmadmin in a separate window/shell.

15. Generate the service time statistics report gathered by the servers with the txrpt utility:

txrpt < Inq.err

16. Compare the times reported in the txrpt report with the times reported by the clientdba program. What is the reason for the difference?

17. If time permits, experiment with the above configuration using different parameter values and observe the results. For example, specify load values instead of the number of messages for the high water and low water marks.

18. Shut down the application when you have completed the lab exercise.



DOMS–Multiple Domains

Reference Course Module: DOMS


Objective The Domains facility allows independently administered BEA Tuxedo applications (domains) to interoperate. The Tuxedo administrator may need to manage multiple application environments, or domains. In this exercise, you will be introduced to the process of setting up two domains, called marketing and engineering and have clients in one domain access to services in the other domain.

Description The configuration for this lab consists of two independent SHM domains, defined by separate configuration files, running on the same machine. Each domain will be configured with one server group and one server and there will be one client per domain. The domains will be connected through a network connection as if the domains were on different machines but messages between the domains will be transferred back to the machine through the network protocol stack). Note that each domain will require a separate setenv environment file and therefore it is convenient to use a separate window for each domain when performing this lab. The following files are provided:


• template Tuxedo configuration files for two domains – engineering (eng) and marketing (mkt): UBBeng.template, UBBmkt.template

• template Tuxedo domain configuration files for the two domains – engineering (eng) and marketing (mkt): domeng.template, dommkt.template

• Server executables (SvrInq, SvrDelete)

• Client executable (clientdb) If you are performing the lab exercises on a shared UNIX system, the Instructor will coordinate the use of an additional IPC key for the second domain and TCP/IP network port numbers for domain communication.



Steps 1. The working directory for this lab is doms in the labs exercises directory.

2. Create two sub-directories in the doms directory: marketing and engineering

3. Copy the following files to the marketing subdirectory:

• setenv[.cmd or .ksh], ubbmkt.template, dommkt.template,

SvrInq, clientdb

4. Copy the following files to the engineering subdirectory:

• setenv[.cmd or .ksh], ubbeng.template, domeng.template,

SvrUpdate, clientdb

5. In this window/shell, change directory to the marketing directory and perform the

following steps:

• Edit the setenv file to reflect the appropriate values for this directory • Add a new environment variable BDMCONFIG; set it to bdmconfig [the domain

equivalent of the TUXCONFIG file] in this application directory <APPDIR> • Set the environment variables by running the setenv command file • Copy or rename the ubbmkg.template file to ubbmkg. Edit the ubbmkg file to

configure the application for the marketing domain. Be sure to assign a different IPCKEY for each domain.

��In the RESOURCES section set the DOMAINID to marketing ��In the GROUPS section configure a group (DMGRP) for the domain

administration process and another group (GWGRP) for the gateway administration processes

��In the SERVERS section configure three servers (DMADM, GWADM, GWTDOMAIN ) that manage the inter-domain communication, and the application server (SvrInq. Assign the servers the correct groups and server id’s.

��Build the TUXCONFIG file for the ubbmkt configuration.

• Now configure the marketing domain so that it is aware of the engineering domain:

��Copy or rename the dommkt.template file to dommkt. Edit this file to set the domain configuration parameters as follows. Use MKTDOM for the Domain Name in this configuration file; set the gateway group to be the same group you declared in the configuration file (GWGRP); set the type of the domain to TDOMAIN; set the DOMAINID to be the same as the domain id you specified in the configuration file, “marketing”.



Make the marketing domain aware of the remote domain “engineering” by configuring the *DM_REMOTE_DOMAINS section. Declare the remote domain as ENGDOM, set its type as TDOMAIN, set its DOMAINID to engineering.

��Declare the network addresses of the gateway processes for both domains in the *DM_TDOMAIN section (make sure that you use the hostname for your machine, and the correct port numbers):

MKTDOM NWADDR="//<machine name>:<port1>"

ENGDOM NWADDR="//<machine name>:<port2> "

��Export the local service to other domains with the following: *DM_LOCAL_SERVICES Inq LDOM=MKTDOM

��Import the Update service from the engineering remote domain:

*DM_REMOTE_SERVICES Update RDOM=ENGDOM

• Build the binary domain configuration file using dmloadcf. This generates the

bdmconfig file. 6. Start a second window/shell to work on the engineering domain. Change directory to the

engineering sub-directory. Copy or rename the ubbeng.template and domeng.template files to ubbeng and domeng respectively. Set up the engineering domain configuration:

• Edit the setenv file to reflect the appropriate values for this directory. Add a new environment variable BDMCONFIG; set it to point to file bdmconfig in this directory <APPDIR>.

• Configure the engineering domain in a similar way to the marketing one just completed.

Use engineering as the name of the DOMAIND Declare the same groups in the GROUPS section Declare and configure the same servers in the SERVERS section but use the SvrInq application server instead of SvrUpdate.

Build the TUXCONFIG configuration file.

• Copy or rename the domeng.template file to domeng. For the engineering domain, declare and configure it in the same way as the marketing domain:

In the *DM_LOCAL_DOMAINS section call the local domain ENGD, set the gateway group to GWGRP, set the type of the domain to TDOMAIN, set the DOMAINID to “engineering”.



��Make the marketing domain aware of the “marketing” domain using the *DM_REMOTE_DOMAINS.

MKTD TYPE=TDOMAIN DOMAINID=marketing

��Declare the network addresses of the gateway processes as in the marketing domain. *DM_TDOMAIN

MKTD NWADDR="//<machine name>:<port1>" ENGD NWADDR="//<machine name>:<port2> "

��We are exporting the Update service from the engineering domain so configure: *DM_LOCAL_SERVICES

Update LDOM=ENGD

��Import the marketing domain’s Inq service to this domain with: *DM_REMOTE_SERVICES

Inq RDOM=MKTD

��Build the binary configuration file using dmloadcf to generate the bdmconfig file.

7. In each of the two open windows, boot the marketing and engineering domains respectively.

Verify that both domains are running by inspecting the ULOG files, and using the tmadmin

and dmadmin administration tools.

8. Run the clientdb client program in each window and request the Inq and Update

service.

clientdb –s Inq –v

clientdb –s Update -v

After each run of clientdb verify from the statistics that the requests are being routed to the

correct domain for processing by the server in that domain.

9. When you are satisfied that your domain configuration is working, shutdown the domains.

lab exercises - pudn.comread.pudn.com/downloads142/doc/618733/tux-a11-80/a11-lab-guide.pdf · the...

Documents