Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Programming   |   Topic List   |   Previous   |   Next   |   Contents

   Programming a BEA Tuxedo Application Using COBOL

The client must explicitly invoke TPINITIALIZE in order to take advantage of the following features of the TPINFDEF-REC record:

• Client Naming

• Unsolicited Notification Handling

• System Access Mode

• Resource Manager Association

• Client Authentication

Client Naming

When a client joins an application, the BEA Tuxedo system assigns a unique client identifier to it. The identifier is passed to each service called by the client. It can also be used for unsolicited notification.

You can also assign unique client and user names of up to 30 characters each, by passing them to TPINITIALIZE via the TPINFDEF-REC record. The BEA Tuxedo system establishes a unique identifier for each process by combining the client and user names associated with it, with the logical machine identifier (LMID) of the machine on which the process is running. You may choose a method for acquiring the values for these fields.

Note: If a process is executing outside the administrative domain of the application (that is, if it is running on a workstation connected to the administrative domain), the LMID of the machine used by the workstation client to access the application is assigned.

Once a unique identifier for a client process is created:

• Client authentication can be implemented.

• Unsolicited messages can be sent to a specific client or to groups of clients via TPNOTIFY and TPBROADCAST.

• Detailed statistical information can be gathered via tmadmin(1).

Refer to Writing Event-based Clients and Servers for information on sending and receiving unsolicited messages, and the BEA Tuxedo C Function Reference for more information on tmadmin(1).

The following figure shows how names might be associated with clients accessing an application. In the example, the application uses the cltname field to indicate a job function.

Unsolicited Notification Handling

Unsolicited notification refers to any communication with a client that is not an expected response to a service request (or an error code). For example, an administrator may broadcast a message to indicate that the system will go down in five minutes.

A client can be notified of an unsolicited message in a number of ways. For example, some operating systems might send a signal to the client and interrupt its current processing. By default, the BEA Tuxedo system checks for unsolicited messages each time an ATMI call is invoked. This approach, referred to as dip-in, is advantageous because it:

• Is supported on all platforms

• Does not interrupt the current processing

As some time may elapse between "dip-ins," the application can call the TPCHKUNSOL call to check for any waiting unsolicited messages. Refer to Writing Event-based Clients and Servers for more information on the TPCHKUNSOL call.

When a client joins an application using TPINITIALIZE, it can control how to handle unsolicited notification messages by defining flags. For client notification, the possible values for NOTIFICATION-FLAG are defined in the following table.

Refer to TPINITIALIZE(3cbl) in the BEA Tuxedo COBOL Function Reference for more information on the TPINFDEF-REC flags.

An application can access the BEA Tuxedo system through either of two modes: protected or fastpath. The client can request a mode when it joins an application using TPINITIALIZE. To specify a mode, a client passes one of the following values in the ACCESS-FLAG field of the TPINFDEF-REC record to TPINITIALIZE.

Resource Manager Association

An application administrator can configure groups for servers associated with a resource manager, including servers that provide administrative processes for coordinating transactions. Refer to Setting Up a BEA Tuxedo Application for information on defining groups.

When joining the application, a client can join a particular group by specifying the name of that group in the grpname field of TPINFDEF-REC.

The BEA Tuxedo system provides security at incremental levels, including operating system security, application password, user authentication, optional access control lists, mandatory access control lists, and link-level encryption. Refer to Setting Up a BEA Tuxedo Application for information on setting security levels.

The application password security level requires every client to provide an application password when it joins the application. The administrator can set or change the application password and must provide it to valid users.

If this level of security is used, BEA Tuxedo system-supplied client programs, such as ud(), prompt for the application password. (Refer to Administering a BEA Tuxedo Application at Run Time for more information on ud, wud(1).) In turn, application-specific client programs must include code for obtaining the password from a user. The unencrypted password is placed in the TPINFDEF-REC record and evaluated when the client calls TPINITIALIZE to join the application.

Note: The password should not be displayed on the screen.

You can use TPCHKAUTH(3cbl) to determine:

• Whether the application requires any authentication

• If the application requires authentication, which of the following types of authentication is needed:

  • System authentication based on an application password

  • Application authentication based on an application password and user-specific information

Typically, a client should call TPCHKAUTH before TPINITIALIZE to identify any additional security information that must be provided during initialization.

Refer to Using BEA Tuxedo Security for more information on security programming techniques.