Friday Oct 07, 2016

Tuxedo Mainframe Transaction Publisher

With all the technology advances and more and more apps moving to cloud, a vast number of mission-critical back-end apps are still running on mainframes. These applications are often the backbone of business as mainframes are seen as providing needed performance, reliability and scalability. With new UIs being developed using newer technologies in Java and many other programming languages and running on open systems, integration of mainframe applications with such front-end applications is a real problem. This problems needs a solution, which is at par, if not exceeds, the performance, reliability and scalability of mainframes.

Tuxedo mainframe transaction publisher is a solution which enables one to integrate CICS/IMS applications running on system Z with outside world. Integration is bi-directional: one can invoke external Web services, SOAP or Rest APIs, from CICS/IMS transactions or one can expose CICS/IMS transactions as Web services (again SOAP or Rest). In addition, TUXEDO MTP enables one to directly integrate with oracle Service Bus. Using this integration you can also use 2-phase commit XA transaction across the transaction life cycle and across the OSB, Tuxedo and mainframe.

The picture below describes the architecture of this integration:

Let’s consider a use case.

You have a requirement to access a CICS transaction, CustEnq, from a mobile app and your mobile app needs SOAP/http access to CustEnq transaction running on mainframe.

Let’s first look at what is in Tuxedo MTP. It consists of following three components:

Tuxedo: Tuxedo provides the core messaging infrastructure.

SALT: This is the Web services gateway for Tuxedo, responsible for communication with Web services clients and/or external Web services. All the conversion from XML and/or JSON to COBOL copybook format happens in this gateway. This gateway also interacts with TMA on the other side.

Tuxedo Mainframe Adapter (TMA): This is the mainframe gateway, which provides bi-directional connectivity to mainframe applications. There are two components of this adapter: GWSNAX runs on the open system side (i.e. on a Unix or Windows machine) and CRM, which generally runs on the mainframe where your mainframe application is running. CRM is a proxy for Tuxedo on mainframe and responsible for interacting with mainframe transactions.

Now, after you have gone through the installation Tuxedo MTP, the first step is to get the COBOL copybook for CustEnq and import it into Tuxedo Services Console. Using the console, you can identify which fields are needed in the request message and which ones are needed in the response message. If you need all fields from the copybook in both request and response messages, you do not need to anything. Based on the copybook definition, Tuxedo MTP generates a number of artifacts, including transaction definition, which is loaded in Tuxedo metadata repository. Once you specify a few other parameters such as Web service name, binding for Web service etc. , Web service definition and domain configuration are generated, which are loaded in SALT and TMA configurations respectively. A WSDL for the CustEnq transaction is also prepared, which can now be used by the mobile app. This is all that is needed to access CustEnq as SOAP/http Web service. No programming is needed whatsoever – not even for data conversion from/to XML or JSON. Similar steps are required to access CustEnq as Rest API or to access external Web services from mainframe transactions.

For detailed information about configuration, see Tuxedo documentation at:  Mainframe Transaction Publisher.

Why you should use Tuxedo MTP as opposed to other solutions available in the market? Here are a few benefits of using Tuxedo MTP:

1. No coding required solution: Tuxedo MTP is a configuration driven solution. No coding is required whatsoever. This makes it simple and extremely quick to deploy this solution to extend reach of your mainframe transactions.

2. Tuxedo MTP has negligible overhead on the mainframe MIPS. We all know that mainframe MIPs are really expansive to use and increasing MIPs usage is the last thing you want to do. With Tuxedo MTP, the only component installed on mainframes is a CRM process, which acts as proxy. Almost all of the processing is done on the open system side by the GWSNAX gateway.

3. Built-in RASP features: With Tuxedo MTP, reliability, availability, performance and scalability come default with it. Tuxedo gateways can be easily configured for redundancy and for scale out/up. Tuxedo MTP can also be configured to work in sysplex environment. 

Monday Oct 03, 2016

Introducing Oracle Tuxedo 12.2.2 Services Console

Oracle Tuxedo 12.2.2 introduces a new console,  Tuxedo Services Console.  Purpose of this console is to provide a functional user interface for Tuxedo services management, including service definitions, export, import etc.   In the current release, the console is specifically used to manage Tuxedo metadata repository, export or import Web services (SOAP and/or REST) and for mainframe transaction publishing.  This post briefly describes each of these functions of the console and then describes how you can start using the console with your application. 

Metadata repository editor:

While Jolt has had a repository for Tuxedo service definitions since Jolt’s inception in late 90’s, concept of metadata repository was introduced in Tuxedo core with introduction of SALT Web services. Tuxedo metadata repository contains application service definitions, which include input/output/error buffer types and associated fields and types.  The service definitions are used to generate WSDL, convert XML or JSON messages into Tuxedo buffer types and vice-versa.   The console enables add/edit/delete of service definition entries in the metadata repository.  It also enables one to discover service definitions in existing applications at runtime. Discovered definitions are automatically entered into the repository.  

The console provides a consolidated view of all services available in the repository as well as services, which are exported or imported  as SOAP or RESTful Web services.

The services console also serves as a replacement for the Jolt repository editor.  In Tuxedo 12.2.2, we have deprecated Jolt repository and its associated editor.  This means, you must migrate Jolt repository to Tuxedo metadata repository and use this console as the repository editor.    

Export/Import of Web services: (SOAP and RESTful):

The console makes it much easier to export an existing Tuxedo service via a intuitively design user interface.  Existing application services can be exported as SOAP/http or as RESTful Web services.  The console also enables import of external SOAP/http and RESTful Web services into a Tuxedo application by importing an existing WSDL for SOAP/http services and by importing a JSON definition for RESTful Web services.

Mainframe Transaction Publisher:

The console enables export of mainframe transactions as SOAP/http or RESTful Web services.  Mainframe transactions could be running on an IBM mainframe in CICS or IMS applications. In order to export such transactions as Web services, one just need to import COBOL copybook for the transaction and perform a few additional steps to export it as a Web service.  No coding required. Similarly if an application requires access to an external SOAP or RESTful Web service,  it can be done via the console by importing WSDL or REST service definition into the console.    For more information see

The console also supports export of mainframe transaction via Oracle Service Bus.  

How do I get started with the console?

It is relatively simple to get started with the console if you already have a running application. It’s a two or three step process depending upon what you want to use the console for.

#1: Given that we are talking about metadata all around, you need to make sure that TMMETADATA server is already configured in your ubbconfig.  If not, add this server to your ubbconfig.   An entry for TMMETADATA will look like following:


CLOPT="-A -- -f my_meta.repos"

my_meta.repos is a file of your choosing where you want metadata repository stored. If you already have a metadata repository, you could use that repository here. 

#2:  You need to have TMADMSVR added to the ubbconfig.  TMADMSVR serves http related to the console.  Note TMADMSVR is not a general purpose http server – its purpose is very specific to the console.  An entry for TMADMSVR will look like the following:


CLOPT="-A -- -a http://localhost:4011"

http://localhost:4011/admin/index.html is the URL to access the console.  

#3:  If you are going to use the console for METADATA repository editing, then you are done. You can start using the console now using the URL mentioned in step #2. However, if you are going to use console for export/import of SOAP or RESTful Web services, then you need to have SALT gateway configured in ubbconfig.  GWWS is the SALT provided system server, which must be added to the ubbconfig.  An entry for GWWS would like the following:


CLOPT="-A -- -i GWWS1"

Now you are all set.  You can start using the console using the URL mentioned in step #2. 

What is the minimum software level needed to use the console:

The Services console is available and fully functional in Tuxedo and SALT 12.2.2 GA version.  It is recommended that you install Tuxedo RP004 or above and SALT RP002 or above in order to get the most benefit out of the console. 

Frequently asked questions:

1.    1. Must I use SALT in order to use the new console?  

        No.  SALT and a corresponding license is required only if you are planning to export/import web services and/or mainframe transactions.  You don’t    even  need to install SALT product in order to use the console, if SALT functionality is not needed.

2. Do I have to use the console in order to use metadata repository server in Tuxedo 12.2.2. 

While the console makes it much-much easier for you to edit the repository, it is not required that you use the console. 

3. I have a lots of services in my current Jolt repository.  Do I need to reenter those services in the new repository? 

You can use tmunloadrepos to create a text version of  Jolt repository and then use tmloadrepos with this text version to load the definitions into the Tuxedo metadata repository.  Any differences in the entry format is taken care of automatically. See for more information.  

4. What happens to the JREPSVR, which is configured in my application?

JREPSVR is not used anymore. Services provided by JREPSVR are now included in TMMETADATA server.  If you have JREPSVR already configured in ubbconfig, you can simply remove it from ubbconfig and instead add TMMETADATA in its place. 

  5. Do I need to change my Jolt client code in order to upgrade to Tuxedo 12.2.2? 

        No change in Jolt client code, whatsoever, is needed. 

        6. I need to export a mainframe transaction running in CICS application on IBM mainframe.  However, my organization has standardized on Oracle      Service Bus.  Can the Tuxedo Services Console still help me with this?

  Yes.  The console provides functionality to import COBOL copybook for the mainframe transaction and generate all the artifacts required to deploy business and proxy services to the OSB.  The process is similar to what you will do to export such transactions via SALT.  It is just that instead of generating SALT configuration, we generate OSB artifacts for deployment into a running OSB instance.

Tuesday Sep 27, 2016

Oracle Tuxedo User Group North America - Invitation to the meeting

WHEN: Thursday, October 20th, 2016
WHERE: Bridgewater, NJ (New York City Metro Area)

Dear Tuxedo Customers and Partners:

We are pleased to invite you to the Oracle Tuxedo User Group meeting to be held this year at our offices in Bridgewater, NJ.  Your participation in this one day event will help shape the Oracle Tuxedo product family in the direction our most important users, YOU, want it to go.  Not only that, we are confident that it will help you network with other Oracle Tuxedo users and learn from each other. 

Oracle Tuxedo product family had several major versions of the product released in the last few years, each version rich in features and functionality, such as cloud enablement and monitoring/management via TSAM Plus. Tuxedo continues to be actively developed with Tuxedo 12.2.2 version released earlier this year.  We would like to provide product update, share our roadmap, and enable you to share in the Tuxedo user community’s experience with the products.

Agenda Topics:

· Introductions
· Tuxedo Update from PM Team (recent releases, investments)
· Customer/partner Use Cases
· Mainframe Modernization using Tuxedo/ART
· Monitoring Tuxedo apps the right way
· Get more out of your Tuxedo apps – Tuxedo in Private/Public Cloud
· Product Demos (focused on recent updates, including app migration to OPC)
· Open Discussion (Q&A, requirements)

Time: 10am – 4pm, lunch will be provided

RSVP: Please register by October 7th via email to Deepak Goel and include the following information: Full name, Company represented, Email address, Mobile phone. Registration and attendance is free.

Please also indicate if you will attend Networking Dinner at 6pm following the User Group meeting.
Dinner venue: TBD

Monday Sep 05, 2016

Oracle Tuxedo at Oracle Open World 2016 in San Francisco, CA

We will be at Oracle Open World from September 18 to 22nd, 2016 showcasing latest and greatest features from Tuxedo 12.2.2, released earlier this year. See for a full listing of sessions, Hands-on-labs and demo related to TUxedo product family. In addition, this will be an opportunity for you to engage with product managers and architects in 1x1 conversations. Hope to see you there....

Monday Aug 01, 2016

Tuxedo Event Broker

The Tuxedo event broker is an often overlooked component of Tuxedo.  It is extremely powerful and can be used to solve a variety of problems.  This series of blog entries will cover how the event subsystem in Tuxedo can be used.

Events in Tuxedo are essentially named buffers that can be published to subscribers.  The Tuxedo event brokers implement publish (post) and subscribe model with events being delivered to subscribers using a variety of mechanisms.  Application components interested in receiving notification of an event being posted can register a subscription.  Subscriptions and the associated delivery or notification of events is handled by two Tuxedo system servers, the System Event Broker (TMSYSEVT) and the User Event Broker (TMUSREVT).  The only difference between a system event and a user event is how the event is named.  Tuxedo system event names all begin with a period ".", whereas the names for user events must start with anything other than a period.

An application typically uses the tpsubscribe() API to register a subscription for an event, although the MIB can be used to create a subscription as well.  Subscriptions includes a regular expression that is used to indicate what events the particular subscription is interested in receiving.  Along with the regular expression, a filter based upon the contents of the associated buffer can be defined to further refine which events the subscription is interested in receiving.  For fielded buffer types, the filter is a boolean expression composed from the fields in the buffer.  For STRING buffers it is a regular expression that is applied to the buffer contents.  When an event is posted using tppost(), the event name is compared against the regular expression of all subscriptions.  If the event name matches the regular expression and the filter evaluates to true or matches in the case of a STRING buffer, then the posted event is delivered to the subscribers. Any Tuxedo buffer type can be associated with an event and the type of buffer associated with any particular name can change from event posting to event posting. 

Events can be delivered in a variety of ways.  A client can subscribe to have events delivered to its unsolicited message handler.  Events can also be delivered to a service, placed on a /Q queue, written to the ULOG, or passed to a command line.  For example, this call to tpsubscribe("DEPOSIT", "AMOUNT > 10000", NULL, NULL) by a Tuxedo client would cause all events named DEPOSIT that have a field named AMOUNT that is greater than 10000 to be delivered to the clients unsolicited message handler.

Subscriptions to /Q queues or to a service using tpsubscribe() require a event control structure parameter that defines either the service name or the queue information necessary for the event broker to deliver the event notification.

More in my next post...

Thursday Nov 05, 2015

Announcing the Tuxedo Advanced Performance Pack

Well now that the busyness of OpenWorld is behind us, it's time to spice things up here on the Tuxedo blog.  The Tuxedo team is pleased to announce the availability of the Tuxedo Advanced Performance Pack.  This add-on option for Tuxedo improves application performance, availability, and manageability.  I'll briefly describe the features and benefits of this new option, but for more details please see the newly published white paper.

The Tuxedo Advanced Performance Pack has three major categories of enhancements:

  • Core enhancements that all Tuxedo applications can leverage
  • Oracle Database related enhancements for those applications using Oracle Database
  • Oracle RAC using XA distributed transaction enhancements for customers using Tuxedo and RAC with XA transactions

Together these enhancements can improve application performance by a factor of 2x to 3x, without any changes to application code.  In fact, all of the features provided by the Tuxedo Advanced Performance Pack are enabled simply by making a small change to the Tuxedo configuration file. 

The core enhancements include:

  • Self-tuning Lock Mechanism to automatically and dynamically set the value of SPINCOUNT to optimize the access to Tuxedo semaphores such as the Bulletin Board lock. 
  • Shared Memory Interprocess Communication - Instead of using System V IPC message queues to communicate between processes, the Tuxedo Advanced Performance Pack provides a facility to use shared memory based messaging.  The result is a reduction of buffer copies normally needed with IPC queues to zero copy messaging, all in user mode.  For applications using large buffers, the performance improvement under heavy load should be dramatic.
  • Tightly Coupled Transaction Branches Spanning Domains - This feature allows Tuxedo to use the same GTRID for distributed transactions that cross domain boundaries, such as one Tuxedo domain calling another Tuxedo domain, or WTC calling a Tuxedo domain.  This allows the sharing of locks and updates to resource managers preventing things like deadlocks that might have otherwise occurred.  As well when used with RAC, if the participating domains were connected to the same RAC database, then RAC will respond with XA_RDONLY for all branches but the last, speeding up transaction commits.
  • Concurrent Global Transaction Table Lock - This feature moves the synchronization of access to the Tuxedo global transaction table (GTT) out from under the Bulletin Board semaphore, to its own semaphore.  As well each transaction in the table has it's own semaphore to allow concurrent updates to the entries.  This eliminates and lock contention for applications making heavy use of XA transactions.

These next set of features benefit Tuxedo applications that utilize Oracle Database:

  • Instance Awareness - Although technically a feature of the Tuxedo Advanced Performance Pack, it's real benefit is in what other features it allows.  Essentially this feature lets Tuxedo know the details of Oracle Database connections.  In other words, what database, service, and instance any given Tuxedo server is using.
  • FAN Support - The Tuxedo Advanced Performance Pack introduces a new Tuxedo server, TMFAN, that connects to Oracle Database ONS to receive FAN notifications.  With this information, Tuxedo can make intelligent decisions based upon the configuration and state of a RAC database.  This enables the following features:
    • Planned Maintenance - When TMFAN receives a notification of planned maintenance for a RAC instance, TMFAN directs the Tuxedo servers connected to that instance to switch their connections to another instance to provide uninterrupted availability.
    • Unplanned Outages - The TMFAN server will get an ONS notification that an instance has failed, and as a result will remove Tuxedo servers connected to that instance from service routing selection.  The affected Tuxedo servers will be told to switch their connection to another instance and resume processing.  Thus eliminating in most scenarios any outage by client applications.
    • RAC Load Balacing - FAN periodically notifies RAC clients about how their load should be distributed across RAC instances.  When TMFAN receives a load balancing advisory, it attempts to ensure that the Tuxedo load for that database adheres to the advisory by changing the routing of requests, and changing the number of connections to each instance.
    • End-to-End Application Tracing - One of the more difficult jobs for a database administrator is identifying the source of problems.  With this feature, Tuxedo will automatically tag Oracle Database sessions with the name of the Tuxedo server, service, and client information.  Thus a dba can quickly locate Tuxedo applications, servers, services, or clients that are causing performance problems and work with the development team to remediate those problems.

Finally these features help applications that use Oracle RAC with Tuxedo distributed transactions:

  • Common XID - The tightly coupled transaction branch feature allows a GTRID to be shared across domains.  This feature extends that to allow the use of a single XID across Tuxedo servers and domains when requests end up using the same RAC instance.  The result is that in many cases instead of having a number of separate but related GTRIDS, and potentially a number of different transaction branches for the same RAC database, all requests if possible use the same instance and the same XID.  Ultimately this could result in a single one phase commit instead of a protracted cross domain two phase commit.
  • Partial One Phase Read-Only Optimization for RAC - Distributed transactions that span RAC instances have separate transaction branches for each instance involved in an XA transaction.  When a transaction manager prepares these various branches, Oracle Database does an optimization where it reports XA_READONLY for all branches but that last.  This feature leverages that capability by preparing all transaction branches but one.  If all other branches report read-only, then the final branch can be committed with a one-phase commit, bypassing the prepare step and the transaction log write.  This can substantially improve the performance of applications that primarily use RAC.
  • XA Transaction Affinity - This feature attempts to minimize the number of RAC instances involved in a distributed transaction.  During the routing of a request, Tuxedo will give preference to servers that are connected to a RAC instance that is already enlisted in the transaction.  The result is a smaller commit tree and the potential for a one phase commit if RAC is the only resource manager involved in the transaction.  As well, minimizing the number of RAC instances involved in the transaction minimize the amount of cross instance traffic within RAC.
  • Single Group Multiple Branches - Normally Tuxedo associates a single transaction branch with a Tuxedo server group.  This presents difficulties if the server group is using a RAC based database service as RAC does not allow a single transaction branch to span RAC instances.  This feature allows a Tuxedo server group to use multiple transaction branches if necessary.  The result is that Tuxedo servers using XA transactions with RAC can now use database services that are offered on multiple instances.  If the particular Tuxedo server a request is routed to is associated with a new instance for the transaction, the Tuxedo Advaned Performance Pack will create a new transaction branch for the newly enlisted instance.

All of these features add up to huge improvements in application performance, application availability, and simplified management.  Tuxedo servers using XA can now fully utilize the features of Oracle RAC including non-singleton services to improve performance and availability.  The integration of FAN into Tuxedo means that Tuxedo can dynamically respond to changes in RAC load and configuration, without any operator intervention.   Together they provide an unbeatable combination of performance, availability, and manageability.

Tuesday Sep 08, 2015

User Group Meeting Invitation

North American Tuxedo User Group Meeting 

The Oracle Tuxedo product management team would like to invite you to this year's North American Tuxedo User Group Meeting being held in Chicago on Thursday October 8, 2015.  Your participation in this one day event will help shape the future of the Oracle Tuxedo product family in the direction our most important users, YOU, want it to go.  Not only that, we are confident that it will help you network with other Oracle Tuxedo users and learn from each other. 

The Oracle Tuxedo product family has had several major releases over the last few years, each release rich in new features and functionality. Tuxedo continues to be actively developed with Tuxedo 12.2.2 version planned for 2016.  We would like to provide you with product updates, share our roadmap, and enable you to share in the Tuxedo user community’s experience with the products.

Agenda Topics:

  • Introductions
  • Tuxedo Update from PM Team (recent releases, investments)
  • Customer Use Cases (hear from other customers)
  • Mainframe Modernization using Tuxedo/ART
  • Tuxedo Extreme Performance Pack (new Tuxedo option)
  • Tuxedo in Cloud (direction, use cases)
  • Product Demos (focused on recent updates)
  • Open Discussion (Q&A, requirements) 

Additional Information

Address: Two Pierce Place, 17th Floor, Itasca, IL 60143
Time: 10am – 4pm, lunch will be provided

RSVP: Please register by September 18th by sending an email to and include the following information: Full name, Company represented, Email address, and Mobile phone.  Registration and attendance are free of charge. 

Networking Dinner following the User Group meeting. Details to be provided prior to the event.

Monday Jul 13, 2015

Oracle Fusion Middleware Innovation Awards

If you have cool application running on Tuxedo and think others would like to hear about it, submit a nomination for an Oracle Fusion Middleware Innovation Award.  These awards are given each year to customers that use FMW products in unique or interesting ways to increase business value.  If you have a Tuxedo based application that you believe is cutting edge, provides unique business value, or extreme performance, please submit a nomination.  Winners receive a free pass to Oracle Open World 2015, an Oracle Fusion Middleware Innovation Award trophy, priority consideration for placement in Profit magazine, Oracle Magazine, or other Oracle publications & press releases. and Oracle Fusion Middleware Innovation logo for inclusion on your own Website and/or press release.  All nominations must be received by 5:00 p.m. (PT), July 31, 2015.  If you need help in preparing your nomination, let me know.

Monday Jul 06, 2015

Tuxedo Sample Applications

Wow, it's been way too long since my last post.  I'll try to post more often.

I wanted to point out a little side project I've been working on that I thought maybe others might be interested in.  It's essentially a github project to create samples and scripts to help get people started with Tuxedo.  None of it meant for prime time, and it's all open source, i.e., meaning other contributors are welcome.  So far I have a few things working well.

Tuxedo and Docker

One of the subprojects within the github repository is a set of files to help using Tuxedo in Docker.  If you're not familiar with Docker, I highly recommend checking out their website.  It basically is a set of tooling around Linux Containers that makes it easy to create a container on your machine.  There is a Dockerfile and associated scripts  that allows one to download the Tuxedo installer and rolling patch kit, and create a Docker image with Tuxedo installed, patched, and ready to go.  The installation and patching of Tuxedo is all automated.  When you're done, you'll have a working Docker image.  To test it, there is a fully automated runme script for the Tuxedo simpapp application in the installers directory of the project.  Copy that into your Docker image and execute it.  It should copy, build, and run the simpapp application.  Check out the for more information.

Tuxedo and Vagrant

Vagrant is another approach to building test and development environments.  Instead of focusing on Linux Containers, Vagrant focuses on creating Virtual Machines, specifically VirtualBox virtual machines.  Although other runtime environments (providers) are supported by Vagrant, VirtualBox is supported out of the box, so to speak.  Inside the Vagrant subproject, there are files and scripts that will create a VirtualBox VM that has Tuxedo installed, patched, and ready to go.  Checkout the for more information.

Tuxedo and RAC

For those wanting to play with Tuxedo and RAC, there is another subproject called RAC that you can use to create multiple VMs that support RAC and Tuxedo.  This project builds upon another github project that helps you create a RAC cluster from 1 to N nodes and as well creates application VMs that can be used to run other things such as Tuxedo.  This project contains the files and instructions to create a RAC cluster and multiple Tuxedo machines that have the Oracle Database Instant Client installed.  Like the other projects, the actual installers for the Oracle projects must be first downloaded from OTN.  Once that is done and a simple edit made to the Vagrantfile to define the number of each type of machine and their memory configurations, two commands get you a working set of interconnected VirtualBox VMs that are running RAC and Tuxedo.  A very quick way to get started with Tuxedo and RAC.   Again, please see the file for more information.

As these are open source projects, please feel free to contribute.  The easiest way to do that is create a github account and request to join the TuxedoUsers github organization.

Friday Oct 10, 2014

Tomcat and Tuxedo - Perfect together

Tuxedo provides numerous integration options to work with existing applications and other technologies.  For example the most recent release of SALT provides RESTful Web services for your Tuxedo services without writing or changing a line of code.  At Oracle Open World last week we demonstrated how you can leverage the Spring Framework and Tuxedo transaction management capabilities inside the Tuxedo Java server.  In this post I'll show how one can run Tomcat inside the Tuxedo Java Server and utilize Tuxedo services directly from Tomcat.  Although the example is trivial, showing calling the Tuxedo TOUPPER service from the simpapp sample application, it illustrates the minimal amount of effort necessary to run Tomcat inside the Tuxedo Java server and call a Tuxedo service.

To use the Tuxedo Java server, the server needs to be configured and added to the Tuxedo UBBCONFIG file.  A new server entry needs to be added similar to:

         CLOPT="-- -c TJSconfig.xml"

For this example, the minimum and maximum dispatch threads could be set to 1 as we're not hosting any Tuxedo services in this instance of the Java Server.  These lines could be added directly to the UBBCONFIG file for the simpapp sample application.

Next a configuration file is needed for the Tuxedo Java server to set things like classes to load, classpaths, and the like.  Here is a copy of TJSconfig.xml as used by the above server definition:

<?xml version="1.0" encoding="UTF-8"?>
<TJSconfig version="2.0">
        <server-class name="MyTuxedoJavaServer"></server-class>

This adds the Tomcat jar files to the classpath and adds a class called MyTuxedoJavaServer to the configuration.

Let's look at the source for MyTuxedoJavaServer and see how this class allows us to start up Tomcat.

public class MyTuxedoJavaServer extends TuxedoJavaServer {
    private TomCatThread tc = null;
    public MyTuxedoJavaServer() {
        // Create the thread that will be used to bootstrap Tomcat
        tc = new TomCatThread();
    public int tpsvrinit() throws TuxException {
        // Startup Tomcat
        return 0;
    public void tpsvrdone() {
        // Shutdown Tomcat

The constructor for the class creates an instance of the thread that will be used to bootstrap Tomcat. The only other two methods are the standard startup and shutdown methods called by the Tuxedo Java server at server startup and shutdown.  These methods simply start and shutdown the Tomcat thread.

Next let's look at the TomCatThread class that is used to bootstrap Tomcat.  It looks like: 

import org.apache.catalina.startup.*;
public class TomCatThread extends Thread {
    private Bootstrap bs = null;
    public void run() {
        try {
            bs = new Bootstrap();
            System.out.println("After starting Tomcat Thread.");
        } catch (Exception e) {
            System.out.println("Received exception" + e);
    public void shutdown() {
        try {
        } catch (Exception e) {
            System.out.println("Received exception while shutting down Tomcat thread" + e);

This class simply extends the Thread class and in its run method creates an instance of the Tomcat bootstrap, sets the home directory for Tomcat, and starts Tomcat running.  The shutdown method just stops the Tomcat embedded server.

Next we need a helper class to help keep track of the Tuxedo context that will be associated with each Tomcat thread.  To make a Tuxedo service call, or most other Tuxedo calls, a thread needs to be associated with an application context in Tuxedo.  This is done using the tpappthrinit() method that creates a new Tuxedo context and associates it with the thread.  We'll use thread local storage to store the created context to be used whenever the thread needs to make a Tuxedo call.  I've used a class called TuxedoThreads to maintain this association:

package todd;
public class TuxedoThreads {
    public static final ThreadLocal<TuxAppContext> userThreadLocal = new ThreadLocal<TuxAppContext>();
    public static void set(TuxAppContext tc) {
    public static TuxAppContext get() throws TuxATMITPException {
        TuxAppContext tc = userThreadLocal.get();
        if (null == tc) {
            // No Tuxedo context gotten for this thread yet, so get one
            tc = TuxAppContextUtil.getTuxAppContext();
        return userThreadLocal.get();

To access the thread's Tuxedo context, we'll simply call the get() class method and if the thread hasn't already created a Tuxedo application context, it will create one and store it in thread local storage.  Otherwise it just returns the previously created Tuxedo context.  One thing to keep in mind is that each thread Tomcat uses will eventually end up with a Tuxedo context.  This means that you need to allow for this in the MAXACCESSORS setting in the UBBCONFIG file.

All that left now is to either use the TuxedoThreads class in a JSP or servlet file or use it in another Java class that they call.  I'll opt for the later as it makes the JSP easier to read.  So here is the MyTest Java class that makes the Tuxedo service call to the TOUPPER service:

package todd;
public class MyTest {
    public String toUpper(String inStr) throws TuxATMITPReplyException,
            TuxATMITPException {
        // Get the threads Tuxedo context
        TuxAppContext tc = TuxedoThreads.get();
        // Create the Tuxedo request buffer and call the Tuxedo service
        TuxATMIReply rply = null;
        TypedString req = new TypedString(inStr);
        TypedString rplyData = null;
        rply = tc.tpcall("TOUPPER", req, 0);
        rplyData = (TypedString) rply.getReplyBuffer();
        return rplyData.toString();

The class has a single method that takes a Java String and it creates a Tuxedo TypedString buffer and calls the Tuxedo TOUPPER service.  It then gets the returned buffer and returns that to the caller.  Here is a trivial JSP using this class to uppercase a string: 

<%@ page import="todd.*"%>
<%@ page language="java" contentType="text/html; charset=UTF-8"
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Test of Tuxedo service call</title>
    <% MyTest foo = new MyTest(); %>
    Hello World uppercased is <%= foo.toUpper("Hello World") %>

The JSP simply creates an instance of the MyTest class and uses the toUpper method to get the upper case version of Hello World.

Wednesday Oct 01, 2014

Why is old bad?

I keep coming across situations where someone tells me that Tuxedo is old like that is a bad thing.  I'm old, well, maybe older, and it seems fine to me.  I like to think I'm like fine wines and single malt scotches that get better with age.  So why is old necessarily a bad thing?

I believe it comes from the notion that old technology has been replaced by something newer.  In a sense this is certainly true.  I don't see a lot of 8 track players these days because they were replaced by cassette tapes, which were replaced by CDs, which were replaced by digital audio players.  Yet there are purists who content vinyl records still offer the best sound quality, although my ears certainly can't confirm that.   

Most people would argue that Unix is modern technology yet Unix was first developed in 1969 making it one of the oldest technologies currently in use.  So why is technology that is 45 years old considered modern?   I believe it is because Unix has kept up with the times.  It has adopted to changes in hardware, operating system design, programming styles and the like.  Tuxedo was first developed in 1982 and likewise has kept up with changes in hardware, application server design, programming languages, and communication techniques.  So where is the difference?

For example, in the 1990s messaging, CORBA, and multi-threaded programming were all the rage.  Tuxedo adopted messaging, CORBA, and multi-threading.  In the 2000s SOAP based web services, the Service Component Architecture, and dynamic programming languages such as Python, Ruby, and PHP became popular and Tuxedo adapted to support those.  More recently Oracle introduced Engineered Systems where the hardware and software was designed to work together to optimize performance.  Tuxedo has been updated to leverage these engineered systems to provide enhancements that can dramatically improve application performance.  Recent releases of Tuxedo now offer support for developing applications in Java, support for RESTful based web services, and tight integration with Oracle Real Application Clusters.

The above may make it sound like Tuxedo lagged behind the technology curve, yet nothing could be farther from the truth.  The Open Group's standard for distributed transaction support known as XA primarily came from Tuxedo.  Service Oriented Architecture or SOA has also been the rage over the last decade, yet Tuxedo has been SOA based since its inception.  Everything in Tuxedo is a service.  This has allowed Tuxedo and Tuxedo applications to adopt newer technologies often with no application changes required.  A service written 20 years ago in C can transparently be used as a SOAP or REST web service with absolutely no changes to the service implementation.  That same service can also be called from Python and appears to the Python developer as just another method.  Want to re-implement that C service in Java without impacting any existing usage of that service?  No problem.

Another word for old that has mixed connotations is mature.  Like old, it can be a bad thing if it has remained unchanged.  However in the world of enterprise software maturity is usually a good thing as it brings with it stability.  Who puts a version 1.0 product into production?  I believe there are few products on the market that have as low a defect rate as Tuxedo has.  This is largely because the code is tested extensively by Oracle and used by the thousands of customers over the last 32 years.  As one customer stated in an Oracle Open World presentation a few years ago that in 15 years of using Tuxedo, they never had a production outage.  That's stability.

So I'm left wondering why is old bad?

Friday Sep 19, 2014

Tuxedo at Oracle Open World 2014

The Tuxedo team will be present in force at Oracle Open World 2014.  We have 7 sessions directly related to Tuxedo presented by engineers, customers,  architects, and product management.  Please add them to your schedule builder so you don't miss them.  They are:

Monday 2:45-3:30PM Moscone South 304
Oracle Tuxedo 12.1.3: What’s New and Why You Should Care [CON8261]

Come hear Frank Xiong - VP for the Tuxedo product family, describe what we've been working on.  He'll be joined by Deepak Goel - Tuxedo Product Manager, and Anastasio Garcia - Middleware, SOA & Delivery Manager from Telefónica España.

Monday 4:15-5:15PM Hotel Nikko - Nikko Ballroom III
Simplify and Optimize Oracle Tuxedo Application Deployments and Management [HOL9448]

Jared Li - Tuxedo development manager, and Chris Guo - Principle Member of Technical Staff will conduct a hands-on lab using Oracle TSAM Plus, Oracle Enterprise Manager, and Oracle Business Transaction Management to monitor, manage, and administer Tuxedo applications. 

Monday 5:45-6:45PM Hotel Nikko - Nikko Ballroom III
Use Java, the Spring Framework, and Oracle Tuxedo to Extend Existing C/C++/COBOL Apps [HOL9447]

A cast of thousands (Maggie Li, Chris Guo, Maurice Gamanho, and myself) will conduct a hands on lab demonstrating how easy it is to use Java and Spring to develop and extend Tuxedo applications. 

Tuesday 10:45-11:30AM Moscone South 200
Oracle Tuxedo Makes It Easy to Develop Composite Apps with Java, C, C++, and COBOL [CON8228]

Jared Li and Deepak Goel will present ways customers can develop composite applications that leverage the performance of C/C++/COBOL while still allowing the rapid creation of business logic in Java, all in a single environment.

Tuesday 7:00-7:45PM Moscone South 301
Oracle Tuxedo Monitoring and Management: Birds-of-a-Feather Meeting [BOF9641]

Come to a Birds of a Feather sessions where Deepak Goel, myself, and Mark Rakhmilevich will present some information on monitoring and managing best practices as well as an open discussion about how to best manage, monitor, and administer Tuxedo applications.

Wednesday 3:30-4:15PM Moscone South 200
The ART and Practice of Mainframe Migration and Modernization [CON8229]

Mark Rakhmilevich - Sr. Director Product Management/Strategy, Rui Pereira - Principal Sales Consultant, and Jeffrey Dolberg - Senior Principal Product Manager, will describe how customers are migrating their mainframe CICS, IMS and batch applications from costly IBM mainframe environments to open systems with Tuxedo and Tuxedo ART.

Thursday 9:30-10:15AM Marriott Marquis - Salon 14/15
Management and Monitoring of Oracle Tuxedo: Integrated, Automated [CON8273]

I will be presenting on the new features in TSAM Plus 12c that can be used to efficiently manage, monitor, and administer Tuxedo applications.  I will cover the recent integration of the Tuxedo observer for BTM, and how to decide on the right tool and strategy to address common performance and availability issues. 

And as always please stop by the Tuxedo booth in the Oracle DEMOgrounds in Moscone South.  We love to see customers and answer their questions.  This is your chance to meet product developers, product managers, engineering managers, and architects all focused on Tuxedo!

Hope to see you there!!

Todd Little
Oracle Tuxedo Chief Architect 

Saturday Mar 15, 2014

High Availability Part 6

This concludes for now my posts on improving the MTBF, just one of the two major factors in improving the availability of a system.  In my next post I’ll start to cover ways to decrease the MTTR, the other factor in determining availability.[Read More]

Thursday Jan 23, 2014

High Availability Part 5

Tuxedo provides an extremely high availability platform for deploying the world's most critical applications.  This post covers some of the way Tuxedo supports redundancy to improve overall application availability.  Upcoming posts will explain additional ways that Tuxedo ensures high availability as well as way to improve application availability of a Tuxedo application.[Read More]

Wednesday Jan 15, 2014

High Availability Part 4

To Err is Human; To Survive is High Availability

In this post I’d like to look at the various causes of unavailability or outages. The most obvious although often overlooked is that of scheduled system maintenance. Now whether that is included in your measurement of availability depends upon the stack holders for a system or application. The ideal systems have no scheduled maintenance that causes the system to be unavailable. That isn’t to say they don’t receive maintenance, but that the maintenance doesn’t cause the system to be unavailable. This can be done via rolling upgrades, site switchovers, etc. For now it suffices to say that this type of down time is intentional, known, and typically scheduled.

The interesting part comes in looking at other causes of unavailability, in particular those caused by failures. The most commonly thought of failure is that of a hardware failure such as a disk drive failing, or a server failing. These failures tend to be obvious and easily remedied. Most people then guess that software failures make up the next significant portion of failures. But as is all too often the case, the most common failures in highly available systems are those caused by people. Estimates place hardware failures at around 10% of the causes of an outage. This low percentage is largely due to the ever improving MTBF of hardware. Software is estimated to cause about 20% of outages for highly available systems. The remaining 70% of outages are attributable to human action, and increasingly these actions are intentional, i.e., purposeful interruptions of service for malicious intent such as denial of service attacks.

To give an example a study was done on replacing a failed hard drive in a software RAID configuration. A seemingly simple task, yet a surprising number of cases of replacing the wrong drive occurred in the first few times an engineer was asked to repair the systems. This indicates that putting procedures in place to repair a system isn’t adequate, but that actually performing the procedures several times is needed to eliminate human error. But more importantly it points out the need to eliminate human intervention as much as possible as any human intervention either for normal operation or for remediating a failure has a significant possibility of being done incorrectly. That incorrect intervention could be relatively catastrophic as in replacing the wrong drive in the above study caused a complete loss of data in some instances.

So what is the takeaway from this information? Minimize or eliminate human intervention as much as possible in order to minimize outages attributable to human error. Typically this means automating as much as possible any necessary steps to resume normal operation after a failure or even during normal operation. Every manual step taken by an administrator has some probability of causing an outage. It also suggests that repair procedures be well tested, preferably in a test environment that duplicates the production environment.

More on how Tuxedo can help solve these problems in my next entry.


This is the Tuxedo product team blog.


  • Oracle
« December 2016