Note: This topic does not apply to
WebSphere MQ.
For a great majority of the applications that use XARs, the process of implementing an XAR is simple and straightforward,
requiring only that you define the XAR in
Enterprise Server. For more information about defining an XAR, see
To define an XAR for an
enterprise server region.
However, for a more complicated application, you need to plan ahead and design the required XAR(s) to accommodate the complexity
of such an application.
This can require modification and recompilation of application source code, and compilation of XAR switch module source code,
which is provided with our
Enterprise Developer product. For more information on this process, see the
Planning and Designing XARs topic in your
Enterprise Developer documentation.
After building a
Micro Focus RM switch module in
Enterprise Developer, you can include it in an XAR definition in
Enterprise Server. An XAR definition includes an xa_open string, which is where you include specific RM syntax for the underlying RM.
In addition to the RM-specific xa_open string syntax, we provide several options that enable you to fine-tune your XAR definitions
to yield maximum efficiency when running applications on
Enterprise Server.
XARs support the following RM switch module types:
- SQL Server
- IBM DB2
- Oracle
- Generic one-phase commit for ODBC
- PostgreSQL
Before configuring an XAR for an
enterprise server region, we suggest that you consider the following:
- Is the application using MFDBFH datastore(s) with transactional files but no embedded SQL?
- If your application does not use any embedded SQL, you are ready to define your MFDBFH XAR(s) as described in
Micro Focus Native Database File Handling and Enterprise Server Region Database Management.
- Does the application require more than one XAR?
- This depends on what database(es) the application accesses, and how the application interacts with it.
- Does the application use MFDBFH with DB2 and embedded SQL with DB2?
- In this case, you must compile your embedded SQL code using the XAID compiler directive for, for example, online
CICS or
Web Services applications and batch processing. This applies whether MFDBFH CICS transactional files are used or not.
- Does the application use MFDBFH datastore(s) with transactional files and/or have embedded SQL code that requires
more than one XAR of the same RM switch module type?
- If your application does not require more than one XAR of the same RM switch module type, and it does not use MFDBFH transactional files, then you are ready to define your XAR(s) in your
enterprise server region
.
However, in some scenarios, more than one XAR of the same type might be required for
CICS, IMS, or IMTK container-managed service interface types that require embedded SQL database access. In another scenario,
you might be using MFDBFH to store COBOL transactional files in a database along with executing embedded SQL applications.
This likely requires recompilation of application source code.
See
Working with Multiple XARs for more information.
- Is the
embedded SQL
application coded to use distinct XARs?
- Typically, the SQL code
is stored in distinct source code modules – some modules used with only one database, and others used with another. Code
constructed in this fashion can be compiled for each program module using the XAID compiler directive option set to the value
of the appropriate XAR ID. This eliminates the need to change code.
- Is it best to use a static or dynamic RM switch module in an XAR?
- This depends on how the XAR is accessed by the application(s). See
RM Switch Module Registration for more information.
- Should transactions be run locally or globally?
- This depends on the types of transactions executed. See the
LocalTX=(T|F) section in
SQL xa_open string Configuration Options for more information.
- When and how should user credentials be obtained and applied?
- You can configure an XAR to use xa_open-supplied user credentials, or to determine user credentials based on the current user.
For more information, see
User Impersonation for CICS and JCL and the
UserP=(T|F) section in
SQL xa_open string Configuration Options.
- Are any of the required XARs used in only batch jobs, and you are not using MFDBFH?
- If so, consider identifying these XARs as batch-only resources, which can save considerable overhead, and eliminate the need
to recompile using the XAID compiler directive option. For more information, see the
BatchOnly=(T|F) section in
SQL xa_open string Configuration Options.
- How do
Enterprise Server Service Execution Processes (SEPs) work with XARs?
- Each CICS, IMS MPP, or IMTK container-managed SEP implicitly establishes a connection to each enabled XAR in the region;
however, when an XAR definition contains
BatchOnly=T, these SEPs do not interact with that XAR. For more information, see the
BatchOnly=(T|F) section in
SQL xa_open string Configuration Options.
Generally, batch SEPs are explicitly provided XAR connections with some variations possible, depending on the batch application.
See
Emulations of Mainframe Utilities for more information on IKJEFT01 jobs or other batch utilities. See
MVS Emulation for more information on DSNALI or DSNRLI applications.
With IMS BMPs, you can get similar behavior if the DFSRRC00 PARM names a preferred XAR. In this case, IMS BMPs connect only
to that XAR; otherwise, the application implicitly establishes a connection to each enabled XAR in the region.
- How do the SEPs monitor the connection to the XA Resource Managers?
- Each time a transaction is triggered, each SEP will verify the connection to all active XA resources unless they are excluded
from the monitoring processing. If the connection is lost, the XA reconnect process attempts to reconnect a number of specified
times at specified time intervals. If the connection is not reestablished after the set number of retries the XA entry is
disabled. You can use Dynamic XA to re-enable the resource manager. See
Enterprise Server XA Reconnect for more information.
For more information about configuring an XAR, see
To define an XA Resource (XAR) for an enterprise server
region.
Important: If you are using a dynamically registered RM switch module for either IBM DB2 or Oracle, and you plan to use User Impersonation,
you must recompile your application source code with the XAID compiler directive option before deploying the application to
Enterprise Server. See
XAID for more information.
Note: The
WebSphere MQ module provided is a built module, not a source code file. It is available in both your development and deployment environments.
See the
WebSphere MQ topic for more information.