VX/TUXEDO - Tuxedo for x86 OpenVMS, wire compatible with Oracle Tuxedo
Overview
VX/TUXEDO is Tuxedo for OpenVMS x86: an ATMI and FML runtime, server framework and Oracle-compatible TDOMAIN and /Workstation protocol stack that runs natively on OpenVMS x86 and speaks Oracle Tuxedo's own wire protocols. For TDOMAIN and /Workstation service calls it is wire compatible with Oracle Tuxedo 22.1.1. A VX/TUXEDO domain on x86 exchanges calls with Oracle Tuxedo domains over TDOMAIN in both directions, and unmodified Oracle Tuxedo /Workstation clients connect to it and call its services.
That means a Tuxedo estate does not have to move in one step. Bring your OpenVMS Tuxedo services to x86 one domain at a time, while the rest of the estate, its Oracle Tuxedo 22.1.1 domains and their clients, keeps running and keeps calling them. Your C services compile against the same ATMI and FML32 headers and build with the same buildserver command, and in measured head-to-head runs on the same Linux host, VX/TUXEDO handles more calls per second than Oracle Tuxedo 22.1.1.
<div class="s7-tech-embed" data-technical-mega-embed="1" lang="en">
<h2 id="wire">Wire compatible with Oracle Tuxedo</h2><p>
VX/TUXEDO does not translate or proxy. It speaks the same protocols Oracle Tuxedo speaks, in Oracle's own frame layouts,
so Oracle's own gateways and clients talk to it directly. Every row below is verified live against
Oracle Tuxedo 22.1.1, and TDOMAIN calls with STRING and FML32 buffers, <code>TPFAIL</code> replies and
gateway failover also run natively from OpenVMS x86 against Oracle.
</p><div class="table-wrapper"><table><thead><tr><th>Protocol</th><th>What interoperates</th></tr></thead><tbody>
<tr><td>TDOMAIN (Oracle's GWTDOMAIN domain gateway)</td><td>Both directions: Oracle Tuxedo domains call services hosted by VX/TUXEDO, and VX/TUXEDO services call Oracle-hosted services through Oracle's gateway.</td></tr>
<tr><td>/Workstation (WSL and WSH)</td><td>Unmodified Oracle Tuxedo /Workstation clients connect to VX/TUXEDO and call its services.</td></tr>
<tr><td>Typed buffers on the wire</td><td>STRING, CARRAY and X_OCTET buffers, FML32 buffers carrying the seven core field types (short, long, char, float, double, string and carray), and FML buffers with string fields.</td></tr>
<tr><td>Call styles</td><td><code>tpcall</code>, <code>tpacall</code> / <code>tpgetrply</code>, <code>TPNOREPLY</code>, and application failures returned as <code>TPFAIL</code>.</td></tr>
<tr><td>Domain resilience</td><td>Oracle Tuxedo domains configured with <code>FAILOVERSEQ</code>, domain-level failover, mirrored gateways and <code>DMKEEPALIVE</code> fail over to, fail back to and keep alive their links with VX/TUXEDO domains, which answer Oracle's keepalives in Oracle's own format. Links reconnect after a drop.</td></tr>
</tbody></table></div>
<h6>Verified against real Oracle Tuxedo</h6><ul>
<li>The protocols were captured from live Oracle Tuxedo 22.1.1 and reimplemented to match it: 586 captured Oracle reply frames, Oracle's forwarded <code>tpforward</code> reply among them, decode and re-encode byte for byte.</li>
<li>A live regression gate on Linux runs VX/TUXEDO's TDOMAIN protocol code through 17 scenarios against real Oracle Tuxedo 22.1.1 (STRING, FML32, CARRAY, X_OCTET, FML, <code>TPFAIL</code>, <code>TPNOREPLY</code>, null replies, long service names, outbound calls from VX/TUXEDO, reconnect, failover, failback, mirrored gateways, keepalive), and passed all 17 on 29 October 2026.</li>
<li>From native OpenVMS x86 to Oracle Tuxedo, TDOMAIN calls with STRING and FML32 buffers and <code>TPFAIL</code> replies pass in both directions, including failover from a primary to a secondary gateway.</li>
</ul>
<h2 id="migrate">Move one domain at a time</h2><p>
Because VX/TUXEDO is a peer on Oracle's own protocols, a migration is a sequence of small, reversible
steps rather than one cut-over:
</p><ol>
<li>Build your OpenVMS Tuxedo services on x86 with VX/TUXEDO, against the same headers.</li>
<li>Join the new x86 domain to the existing estate through TDOMAIN. Oracle Tuxedo domains reach its services through their own GWTDOMAIN gateways.</li>
<li>Keep /Workstation clients where they are: unmodified Oracle Tuxedo clients connect to VX/TUXEDO.</li>
<li>Move the next domain when the last one is proven. Nothing else in the estate has to change at the same time.</li>
</ol>
<h2 id="build">Same headers, same build</h2><ul>
<li><code>atmi.h</code>, <code>xatmi.h</code>, <code>fml.h</code>, <code>fml32.h</code> and <code>userlog.h</code> mirror Oracle Tuxedo 22.1.1: the same function signatures, error numbers, constants and structure layouts, so services and clients recompile against them.</li>
<li><code>buildserver</code> takes the same command shape (<code>buildserver -k -o IMAGE -f OPTFILE -s @MAP</code>) and the same service map files, with OpenVMS <code>.OPT</code> link files on x86.</li>
<li><code>mkfldhdr32</code> and <code>viewc32</code> build your field tables and VIEW definitions.</li>
<li><code>tmloadcf</code> and <code>dmloadcf</code> load your UBBCONFIG and DMCONFIG text, and on Linux <code>dmunloadcf</code> prints a loaded DMCONFIG back byte for byte as Oracle's does, checked on 85 DMCONFIG files. <code>tmboot</code> and <code>tmshutdown</code> start and stop the application from DCL.</li>
</ul>
<h2 id="atmi">ATMI and FML, measured against Oracle</h2><p>
Each part of the runtime was built by measuring what Oracle Tuxedo 22.1 actually does, then matching
it, so services behave the same way on x86.
</p><div class="table-wrapper"><table><thead><tr><th>Area</th><th>VX/TUXEDO</th></tr></thead><tbody>
<tr><td>Service calls</td><td><code>tpcall</code>, <code>tpacall</code>, <code>tpgetrply</code>, <code>tpcancel</code>, <code>tpforward</code>, <code>tpreturn</code>, <code>tpadvertise</code> / <code>tpunadvertise</code>, <code>tpinit</code> / <code>tpterm</code>, <code>tpgetcallinfo</code>, priorities and blocking time</td></tr>
<tr><td>FML and FML32</td><td>The field-manipulation library, byte-compared with Oracle Tuxedo 22.1 fixtures: boolean expressions, <code>Fread</code> / <code>Fwrite</code>, VIEW functions and XML converters</td></tr>
<tr><td>Typed buffers</td><td>STRING, CARRAY, X_OCTET, XML, FML, FML32, VIEW, VIEW32 and RECORD buffers for COBOL-style records</td></tr>
<tr><td>Buffer export</td><td><code>tpexport</code> and <code>tpimport</code></td></tr>
<tr><td>Server lifecycle</td><td><code>tpsvrinit</code>, <code>tpsvrdone</code>, <code>tpsvrthrinit</code>, <code>tpsvrthrdone</code> and <code>tprminit</code>, measured against Oracle in 26 scenarios</td></tr>
<tr><td>Server management</td><td>Oracle-compatible <code>CLOPT</code> (<code>-A</code>, <code>-p</code>, <code>-o</code>, <code>-e</code>, <code>-r</code>), <code>MIN</code> / <code>MAX</code> scaling, restart, <code>MAXGEN</code> and <code>GRACE</code></td></tr>
<tr><td>Load balancing</td><td><code>LDBAL</code>, <code>LOAD</code>, MSSQ sets and data-dependent routing, reproduced from measurements of Oracle's own choices</td></tr>
<tr><td>Repository</td><td><code>tpgetrepos</code> / <code>tpsetrepos</code>, byte-compared with Oracle</td></tr>
</tbody></table></div>
<h2 id="openvms">Native on OpenVMS x86</h2><p>
VX/TUXEDO runs natively on OpenVMS x86-64 V9.2-3, built with VSI C++ and DECthreads. On 15 October 2026
the native OpenVMS suite passed in full: 41 tests and 14 probes across 45 modules, with outbound TDOMAIN, configuration
loading and the schema tools executed on the x86 system itself. <code>tmboot</code>,
<code>tmshutdown</code> and the supervisor are driven from DCL, so the application starts and stops the
way an OpenVMS operator expects.
</p>
<h2 id="performance">Faster than Oracle Tuxedo</h2><p>
Measured head to head against Oracle Tuxedo 22.1.1 on the same Linux host: the same application source
compiled for each product, four servers in one MSSQ set, an application-shaped mix of FML32 services,
every reply checked for its expected fields and row counts, and four repetitions with the product order alternated.
</p><div class="table-wrapper"><table><thead><tr><th>Measure</th><th>Oracle Tuxedo 22.1.1</th><th>VX/TUXEDO</th><th>VX/TUXEDO advantage</th></tr></thead><tbody>
<tr><td>Calls per second, 1 client</td><td>36,819</td><td>50,170</td><td><span class="ac-live">1.36×</span></td></tr>
<tr><td>Calls per second, 16 clients</td><td>216,782</td><td>390,546</td><td><span class="ac-live">1.80×</span></td></tr>
<tr><td>Median round trip, 1 client</td><td>23.6 µs</td><td>17.4 µs</td><td><span class="ac-live">26% lower</span></td></tr>
<tr><td>CPU per call</td><td>29.3 µs</td><td>19.9 µs</td><td><span class="ac-live">32% less</span></td></tr>
<tr><td>Client memory (RSS), 1 client</td><td>18.3 MB</td><td>14.0 MB</td><td><span class="ac-live">23% less</span></td></tr>
</tbody></table></div><p>
Every run counted only if it was valid: server log completions equal to the clients' successful calls, scheduler
counts exact and no protocol errors.
</p>
<h2 id="related">Related tools</h2><ul>
<li><a href="/technical/vx-acms-application-control-management-system">VX/ACMS</a>: ACMS transaction processing for Linux.</li>
<li><a href="/technical/vx-rtr-openvms">VX/RTR</a>: Reliable Transaction Router.</li>
<li><a href="/technical/openvms-dmq-pams-for-x86-linux">VX/DMQ</a>: DECmessageQ (PAMS) for x86 and Linux.</li>
<li><a href="/technical/vx-sql-cobol-with-embedded-sql-to-pro-c-or-ecpg">SQL$PRE (VX/SQL)</a>: Rdb embedded SQL on OpenVMS x86.</li>
</ul>
</div>
