EXE$ - Operating System Interface
Overview
VX/EXE$ is the OpenVMS executive and system-service interface of VX/RT, delivered as a call-compatible library that runs OpenVMS applications on x86 and ARM Linux without source code changes. It presents the OpenVMS SYS$ system services together with the EXE$ executive entry points that legacy code links to directly, covering timers, event flags, queued I/O, process control, information services, logical names, and queue services.
Underneath, VX/EXE$ is an emulation layer rather than a re-implementation of VAX or Alpha internals. Each service is written once as an inner worker and exported under its OpenVMS names through linker aliases, so recompiled programs call the same routines, pass the same arguments, and read back the same VMS condition codes as they did on VMS. Services that have no equivalent on a host operating system are documented plainly so migration planners know exactly where behaviour differs.
<!-- Webflow embed (min). Source: exe-page-technical/exe-tech-body-embed-dark.html → python3 website/embeds/minify_webflow_embed.py … -->
<div class="s7-tech-embed" data-vxexed-body-embed="1" data-technical-mega-embed="1" lang="en"><h2 id="architecture">Architecture and how it maps to the host</h2><p>
VX/EXE$ is a linked runtime library, not a server or daemon. It is archived into
<code>libvxrt.a</code>, the same runtime archive shared with the other VX/TOOLS routines, and
linked directly into the migrated application. There is no system-service process to administer:
every call is serviced in-process by the library, which presents the OpenVMS system-service and
executive callable interface on top of ordinary host facilities.
</p><p>
Each service is written once as a plain C or C++ function and then exported under its OpenVMS
names by the linker. Device I/O is backed by per-device driver modules compiled into the same
archive: disk, terminal, network, and mailbox drivers, with a shared support layer and a driver
thread providing the asynchronous plumbing behind the queued I/O family.
</p><div class="callout"><strong>No service to administer.</strong> VX/EXE$ has no daemon and no privileged executive to
install. The library runs in the address space of the migrated program, so deployment is a link
step rather than a service install.
</div><h6>Layering</h6><p>The runtime sits between the unchanged application and the host operating system:</p><style>.s7-tech-embed .process-flow {margin: 1.5rem 0;padding: 16px;border: 1px solid var(--s7t-border);border-radius: 10px;background: rgba(255, 255, 255, 0.01);}.s7-tech-embed .process-endpoint {display: grid;grid-template-columns: 72px minmax(0, 1fr);gap: 14px;align-items: center;padding: 14px 16px;border-radius: 8px;background: var(--s7t-surface);color: var(--s7t-text);}.s7-tech-embed .process-output {border: 1px solid var(--s7t-note-bd);background: var(--s7t-note-bg);}.s7-tech-embed .process-runtime {margin-top: 10px;}.s7-tech-embed .process-label,.s7-tech-embed .process-number {font-family: var(--s7t-mono);color: var(--s7t-accent);font-size: 0.76em;font-weight: 700;letter-spacing: 0.08em;text-transform: uppercase;}.s7-tech-embed .process-endpoint div,.s7-tech-embed .process-stage {min-width: 0;}.s7-tech-embed .process-endpoint strong,.s7-tech-embed .process-endpoint span:last-child,.s7-tech-embed .process-stage strong,.s7-tech-embed .process-stage span:last-child {display: block;}.s7-tech-embed .process-endpoint strong,.s7-tech-embed .process-stage strong {margin-bottom: 4px;color: var(--s7t-text);}.s7-tech-embed .process-endpoint span:last-child,.s7-tech-embed .process-stage span:last-child {color: var(--s7t-muted);font-size: 0.9em;line-height: 1.45;}.s7-tech-embed .process-stages {display: grid;grid-template-columns: repeat(4, minmax(0, 1fr));gap: 10px;margin: 10px 0;}.s7-tech-embed .process-stage {padding: 15px;border-top: 3px solid var(--s7t-accent);border-radius: 6px;background: var(--s7t-surface2);color: var(--s7t-text);}.s7-tech-embed .process-stage .process-number {margin-bottom: 10px;}@media (max-width: 800px) {.s7-tech-embed .process-stages {grid-template-columns: 1fr;}.s7-tech-embed .process-endpoint {grid-template-columns: 1fr;gap: 5px;}}</style><div class="process-flow" aria-label="VX/EXE runtime layering and service families"><div class="process-endpoint"><span class="process-label">Caller</span><div><strong>Migrated application</strong><span>Unchanged SYS$ and EXE$ calls</span></div></div><div class="process-endpoint process-runtime"><span class="process-label">Runtime</span><div><strong>VX/EXE$ in libvxrt.a</strong><span>Routes each in-process call to the matching service family.</span></div></div><div class="process-stages"><div class="process-stage"><span class="process-number">01</span><strong>Timers and time</strong><span>Clock, timer, and time conversion services.</span></div><div class="process-stage"><span class="process-number">02</span><strong>Event flags</strong><span>Event flag allocation, state, and synchronization.</span></div><div class="process-stage"><span class="process-number">03</span><strong>Queued I/O drivers</strong><span>Disk, terminal, network, and mailbox device I/O.</span></div><div class="process-stage"><span class="process-number">04</span><strong>Process and information</strong><span>Process, queue, and system information services.</span></div></div><div class="process-endpoint process-output"><span class="process-label">Host</span><div><strong>Host operating system</strong><span>Files, sockets, threads, and clocks.</span></div></div></div><h6>The call wrapper</h6><p>
Almost every system service follows the same shape: open a trace scope, call the inner worker,
then close the trace scope on the return value. The <code>SYS$</code> entry points are therefore a
thin, uniformly instrumented shell over the inner worker functions, which keeps behaviour
consistent and makes the runtime straightforward to trace during a migration.
</p>
<pre><span class="kw">U32</span> SYS_D_GETTIM(<span class="kw">void</span> *sm_time) {
VX_BEGINS; <span class="cmt">// open trace scope</span>
U32 rc = EXE_D_GETTIM(sm_time); <span class="cmt">// call the inner executive worker</span>
VX_RETURNS(rc); <span class="cmt">// close trace scope, return the condition code</span>
}</pre>
<h2 id="alias-model">EXE$ and SYS$: the alias model</h2><p>
On OpenVMS, the <code>EXE$</code> names are the executive-mode entry points that the
<code>SYS$</code> system-service dispatchers call. VX/EXE$ preserves both name forms so that code
which links against either resolves cleanly. A service that has both an executive and a
system-service form is written once as an inner worker and aliased under each OpenVMS name, with
the <code>SYS$</code> form wrapping the worker in the runtime trace scope and the <code>EXE$</code>
form exposing the bare inner call.
</p>
<pre><span class="cmt">// one worker, two OpenVMS names</span>
__AliasF(SYS_D_GETTIM, <span class="str">SYS$GETTIM</span>, sys$gettim);
__AliasF(EXE_D_GETTIM, <span class="str">EXE$GETTIM</span>, exe$gettim);</pre>
<p>
The alias mechanism also emits the Fortran trailing-underscore variants automatically, and a
distinct Fortran thunk where a routine needs to unpack F77 string-length arguments. COBOL callers
are served by a small set of <code>COB$</code> re-aliases over the same workers. The practical
result is that a single implementation is reachable from C, Fortran, and COBOL under the exact
names the original application used.
</p><h6>The exported EXE$ entry points</h6><p>
The load-bearing detail for planning a migration is that the <code>EXE$</code> surface is small
and specific. These are the executive entry points exported directly under the <code>EXE$</code>
prefix; each is also available under its <code>SYS$</code> name.
</p><div class="table-wrapper"><table><thead><tr><th>EXE$ entry point</th><th>SYS$ equivalent</th><th>Purpose</th><th>Status</th></tr></thead><tbody><tr><td><code>EXE$GETTIM</code></td><td><code>SYS$GETTIM</code></td><td>Return the current system time in 100 ns units.</td><td><span class="ac-live">live</span></td></tr><tr><td><code>EXE$SYNCH</code></td><td><code>SYS$SYNCH</code></td><td>Synchronize on an event flag and I/O status block.</td><td><span class="ac-live">live</span></td></tr><tr><td><code>EXE$QIO</code></td><td><code>SYS$QIO</code></td><td>Queue an asynchronous I/O request on a channel.</td><td><span class="ac-live">live</span></td></tr><tr><td><code>EXE$CANCEL</code></td><td><code>SYS$CANCEL</code></td><td>Cancel an outstanding I/O request on a channel.</td><td><span class="ac-live">live</span></td></tr><tr><td><code>EXE$GETQUI</code></td><td><code>SYS$GETQUI</code></td><td>Retrieve queue information.</td><td><span class="ac-live">live</span></td></tr></tbody></table></div><div class="callout"><strong>Executive and system forms are not identical.</strong> The <code>SYS$</code> form is
wrapped in the runtime trace scope while the <code>EXE$</code> form is the bare inner worker.
They service the same request, but the two entry points are not drop-in equivalents for tracing
and instrumentation purposes.
</div><div class="callout"><strong>File and record verbs live in VX/RMS.</strong> Record operations such as open, close,
get, put, connect, and rename are OpenVMS RMS services, not executive entry points, and are
provided by <a href="/technical/vx-rms-sys-routines-for-rms">VX/RMS</a>. Use this page for
system services and the executive interface, and VX/RMS for record and file management.
</div><h2 id="routines">SYS$ system service reference</h2><p>
VX/EXE$ exports the OpenVMS system-service callable interface. Each service is available under its
<code>SYS$</code> name, the Fortran trailing-underscore aliases, and, for the executive entry
points listed above, an <code>EXE$</code> variant. The tables below group the services by OpenVMS
functional area. The great majority carry an operative implementation; the specific services that
are accepted for source compatibility but do not perform their native function are listed
separately under <a href="#stubs">Stubs and unimplemented services</a>.
</p><h6>Time and timers</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$GETTIM</code></td><td>Return the current system time as a 64-bit value in 100 ns units.</td></tr><tr><td><code>SYS$ASCTIM</code></td><td>Convert a binary time value to an ASCII string.</td></tr><tr><td><code>SYS$BINTIM</code></td><td>Convert an ASCII date and time string to binary format.</td></tr><tr><td><code>SYS$NUMTIM</code></td><td>Convert a binary time to a numeric seven-word vector.</td></tr><tr><td><code>SYS$SETIMR</code></td><td>Set a timer that sets an event flag or delivers an AST on expiry.</td></tr><tr><td><code>SYS$CANTIM</code></td><td>Cancel a pending timer request.</td></tr><tr><td><code>SYS$SCHDWK</code> / <code>SYS$CANWAK</code></td><td>Schedule or cancel a scheduled process wakeup.</td></tr></tbody></table></div><h6>Event flags and synchronization</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$SYNCH</code></td><td>Wait for the completion of a queued request using an event flag and I/O status block.</td></tr><tr><td><code>SYS$WAITFR</code></td><td>Wait for a single event flag.</td></tr><tr><td><code>SYS$WFLAND</code> / <code>SYS$WFLOR</code></td><td>Wait for a logical AND or OR of a set of event flags.</td></tr><tr><td><code>SYS$SETEF</code> / <code>SYS$CLREF</code> / <code>SYS$READEF</code></td><td>Set, clear, or read an event flag.</td></tr><tr><td><code>SYS$ASCEFC</code> / <code>SYS$DACEFC</code></td><td>Associate or disassociate a common event flag cluster.</td></tr></tbody></table></div><h6>Queued I/O, channels, and devices</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$QIO</code> / <code>SYS$QIOW</code></td><td>Queue an asynchronous I/O request, or queue and wait for completion.</td></tr><tr><td><code>SYS$CANCEL</code></td><td>Cancel outstanding I/O on a channel.</td></tr><tr><td><code>SYS$ASSIGN</code> / <code>SYS$DASSGN</code></td><td>Assign or deassign an I/O channel to a device.</td></tr><tr><td><code>SYS$ALLOC</code> / <code>SYS$DALLOC</code></td><td>Allocate or deallocate a device.</td></tr><tr><td><code>SYS$MOUNT</code> / <code>SYS$DISMOU</code></td><td>Mount or dismount a volume.</td></tr><tr><td><code>SYS$BRDCST</code> / <code>SYS$BRKTHRU</code></td><td>Broadcast or break through a message to one or more terminals.</td></tr></tbody></table></div><p>
Queued I/O is backed by per-device driver modules built into <code>libvxrt.a</code> for disk,
terminal, network, and mailbox devices, with a shared support layer and a driver thread providing
asynchronous completion.
</p><h6>Process control</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$CREPRC</code> / <code>SYS$DELPRC</code></td><td>Create or delete a process.</td></tr><tr><td><code>SYS$SUSPND</code> / <code>SYS$RESUME</code></td><td>Suspend or resume a process.</td></tr><tr><td><code>SYS$HIBER</code> / <code>SYS$WAKE</code></td><td>Hibernate the current process or wake a hibernating process.</td></tr><tr><td><code>SYS$SETPRI</code> / <code>SYS$SETPRN</code></td><td>Set process priority or process name.</td></tr><tr><td><code>SYS$FORCEX</code> / <code>SYS$EXIT</code></td><td>Force another process to exit, or exit the current image.</td></tr><tr><td><code>SYS$DCLEXH</code> / <code>SYS$CANEXH</code></td><td>Declare or cancel an exit handler.</td></tr><tr><td><code>SYS$DCLAST</code> / <code>SYS$SETAST</code></td><td>Declare an AST, or enable and disable AST delivery.</td></tr><tr><td><code>SYS$PROCESS_SCAN</code></td><td>Build a process-scan context for use with the information services.</td></tr></tbody></table></div><h6>Information services</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$GETJPI</code> / <code>SYS$GETJPIW</code></td><td>Get job and process information.</td></tr><tr><td><code>SYS$GETDVI</code> / <code>SYS$GETDVIW</code></td><td>Get device and volume information.</td></tr><tr><td><code>SYS$GETSYI</code> / <code>SYS$GETSYIW</code></td><td>Get system information.</td></tr><tr><td><code>SYS$GETUAI</code></td><td>Get user authorization information.</td></tr><tr><td><code>SYS$GETQUI</code> / <code>SYS$GETQUIW</code></td><td>Get queue information synchronously or asynchronously.</td></tr><tr><td><code>SYS$GETMSG</code> / <code>SYS$PUTMSG</code></td><td>Retrieve or format a system message.</td></tr></tbody></table></div><h6>Logical names, memory, and interprocess services</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$CRELNM</code> / <code>SYS$DELLNM</code> / <code>SYS$TRNLNM</code></td><td>Create, delete, or translate a logical name.</td></tr><tr><td><code>SYS$CRELNT</code></td><td>Create a logical name table.</td></tr><tr><td><code>SYS$EXPREG</code> / <code>SYS$CRETVA</code> / <code>SYS$DELTVA</code></td><td>Expand the program region, or create and delete virtual address space.</td></tr><tr><td><code>SYS$CRMPSC</code> / <code>SYS$MGBLSC</code></td><td>Create and map a section, or map a global section.</td></tr><tr><td><code>SYS$CREMBX</code> / <code>SYS$DELMBX</code></td><td>Create or delete a mailbox for interprocess communication.</td></tr><tr><td><code>SYS$SNDJBC</code> / <code>SYS$SNDOPR</code></td><td>Send a request to the job controller or to the operator.</td></tr><tr><td><code>SYS$FAO</code> / <code>SYS$FAOL</code></td><td>Formatted ASCII output, direct and list form.</td></tr></tbody></table></div><div class="callout"><strong>One implementation, every name form.</strong> Because each service is exported under its
<code>SYS$</code>, Fortran, and (where applicable) <code>EXE$</code> and <code>COB$</code> names,
a mixed-language application links against the same worker set without per-language shims.
</div><h2 id="status-codes">Status codes and return model</h2><p>
Every service returns a 32-bit VMS condition value. Applications that inspect these codes keep
working unchanged, because VX/EXE$ returns the same <code>SS$_XXX</code> symbols and preserves the
VMS severity convention: a successful status is odd, a failure is even, so existing
<code>ODD(status)</code> tests behave exactly as they did on VMS. A representative set of the codes
the system services use most:
</p><div class="table-wrapper"><table><thead><tr><th>Symbol</th><th>Decimal</th><th>Meaning</th></tr></thead><tbody><tr><td><code>SS$_NORMAL</code></td><td>1</td><td>Successful completion.</td></tr><tr><td><code>SS$_ACCVIO</code></td><td>12</td><td>Access violation on a call argument.</td></tr><tr><td><code>SS$_BADPARAM</code></td><td>20</td><td>Bad parameter value.</td></tr><tr><td><code>SS$_NOPRIV</code></td><td>36</td><td>Insufficient privilege for the operation.</td></tr><tr><td><code>SS$_INSFARG</code></td><td>276</td><td>Too few call arguments supplied.</td></tr><tr><td><code>SS$_INSFMEM</code></td><td>292</td><td>Insufficient dynamic memory.</td></tr><tr><td><code>SS$_IVCHAN</code></td><td>316</td><td>Invalid channel number.</td></tr><tr><td><code>SS$_TIMEOUT</code></td><td>556</td><td>Timeout period expired.</td></tr><tr><td><code>SS$_UNSUPPORTED</code></td><td>3658</td><td>Service or sub-function not implemented.</td></tr><tr><td><code>SS$_INVARG</code></td><td>4042</td><td>Invalid argument.</td></tr></tbody></table></div><div class="callout"><strong>Return by value, and by convention.</strong> The condition value is returned by the call
and follows the standard VMS odd-equals-success rule. Code that branches on
<code>ODD(status)</code> or compares against a named <code>SS$_</code> symbol needs no change on
the new platform.
</div><h2 id="stubs">Stubs and unimplemented services</h2><p>
A small number of OpenVMS services describe privileged operations that have no equivalent on a
host operating system such as Linux. VX/EXE$ still exports these entry points so existing code
links cleanly, but they either return success without acting or report that the function is
unsupported. Migration planning should account for the routines below explicitly, because code
that depends on their side effects will not get them on the new platform.
</p><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose on VMS</th><th>Behaviour</th></tr></thead><tbody><tr><td><code>SYS$CMEXEC</code></td><td>Change to executive access mode.</td><td><span class="ac-no">stub: returns success and does nothing</span></td></tr><tr><td><code>SYS$NEWPROC</code></td><td>Create a process.</td><td><span class="ac-no">stub: returns success, no process created</span></td></tr><tr><td><code>SYS$LCKPAG</code></td><td>Lock pages in physical memory.</td><td><span class="ac-no">stub: returns success, pages are not locked</span></td></tr><tr><td><code>SYS$ADJWSL</code></td><td>Adjust the working-set limit.</td><td><span class="ac-no">stub: no-op, echoes the requested value</span></td></tr><tr><td><code>SYS$SNDSMB</code></td><td>Send a request to a symbiont.</td><td><span class="ac-no">stub: returns success, no request sent</span></td></tr><tr><td><code>SYS$CREATE_REGION_64</code> / <code>SYS$DELETE_REGION_64</code></td><td>Create or delete a 64-bit virtual region.</td><td><span class="ac-no">unsupported: reports unsupported and exits the image</span></td></tr><tr><td><code>SYS$GETRMI</code></td><td>Get resource-management information.</td><td><span class="ac-no">unimplemented: aborts if called</span></td></tr><tr><td><code>SYS$START_TRANSW</code> / <code>SYS$END_TRANSW</code> / <code>SYS$ABORT_TRANSW</code></td><td>DECdtm distributed transaction control.</td><td><span class="ac-no">stub: marks the status block and returns success, no transaction manager</span></td></tr></tbody></table></div><div class="callout warn"><strong>Silent success versus hard stop.</strong> Most stubs return success so surrounding logic
proceeds, but the 64-bit region services exit the image and the resource-management query aborts.
Confirm during assessment that a migrating application does not rely on any of these services
before it reaches production.
</div><h2 id="compatibility">Compatibility and deliberate divergences</h2><p>
VX/EXE$ covers the system services that production applications actually depend on, and is
explicit about the areas that behave differently on a host operating system. The matrix below
places each capability in exactly one bucket.
</p><div class="table-wrapper"><table><thead><tr><th>Capability</th><th>Status</th><th>Note</th></tr></thead><tbody><tr><td>Time and timer services</td><td><span class="ac-live">live</span></td><td>System time, conversions, timers, and scheduled wakeups.</td></tr><tr><td>Event flags and synchronization</td><td><span class="ac-live">live</span></td><td>Local and common event flags, wait-for combinations, and I/O status synchronization.</td></tr><tr><td>Queued I/O and channel management</td><td><span class="ac-live">live</span></td><td>Disk, terminal, network, and mailbox drivers behind the QIO family.</td></tr><tr><td>Process control and ASTs</td><td><span class="ac-live">live</span></td><td>Create, delete, suspend, resume, hibernate, wake, and AST delivery.</td></tr><tr><td>Information and queue services</td><td><span class="ac-live">live</span></td><td>Job, device, system, and queue information queries.</td></tr><tr><td>Logical names and interprocess services</td><td><span class="ac-live">live</span></td><td>Logical-name creation and translation, mailboxes, and message formatting.</td></tr><tr><td>Page locking and working-set control</td><td><span class="ac-no">out of scope</span></td><td>Accepted as no-ops; the host manages memory residency.</td></tr><tr><td>64-bit region create and delete</td><td><span class="ac-no">out of scope</span></td><td>Reported unsupported; the call exits the image.</td></tr><tr><td>Distributed transactions (DECdtm)</td><td><span class="ac-no">out of scope</span></td><td>Accepted but inert; there is no transaction manager.</td></tr><tr><td>Resource-management information</td><td><span class="ac-no">out of scope</span></td><td>The query is unimplemented and aborts if called.</td></tr></tbody></table></div><h6>Deliberate divergences from native OpenVMS</h6><p>These are behaviours that differ by design because the host is Linux rather than OpenVMS:</p><ul><li><strong>Executive versus system form.</strong> The <code>SYS$</code> entry point is wrapped in the runtime trace scope; the <code>EXE$</code> entry point is the bare inner worker. They service the same request but are not identical for instrumentation.</li><li><strong>Privileged memory services.</strong> Page locking and working-set adjustment are no-ops, because residency is managed by the host kernel rather than by the application.</li><li><strong>No executive mode.</strong> The change-mode service returns success without switching modes, since the host has no VMS access-mode model.</li><li><strong>Record and file verbs are elsewhere.</strong> Open, close, get, put, connect, and similar record operations are RMS services provided by <a href="/technical/vx-rms-sys-routines-for-rms">VX/RMS</a>, not executive entry points on this interface.</li><li><strong>Condition values, not signals.</strong> Errors are returned by value as <code>SS$_</code> codes; there is no VMS condition-handler dispatch behind the calls.</li></ul><h2 id="quickref">Quick reference</h2><h6>EXE$ executive entry points</h6><div class="kw-grid"><div>EXE$GETTIM</div><div>EXE$SYNCH</div><div>EXE$QIO</div><div>EXE$CANCEL</div><div>EXE$GETQUI</div></div><h6>Representative SYS$ services</h6><div class="kw-grid"><div>SYS$GETTIM</div><div>SYS$ASCTIM</div><div>SYS$BINTIM</div><div>SYS$SETIMR</div><div>SYS$SYNCH</div><div>SYS$WAITFR</div><div>SYS$SETEF</div><div>SYS$CLREF</div><div>SYS$QIO</div><div>SYS$QIOW</div><div>SYS$CANCEL</div><div>SYS$ASSIGN</div><div>SYS$CREPRC</div><div>SYS$DELPRC</div><div>SYS$HIBER</div><div>SYS$WAKE</div><div>SYS$GETJPI</div><div>SYS$GETDVI</div><div>SYS$GETSYI</div><div>SYS$GETQUI</div><div>SYS$CRELNM</div><div>SYS$TRNLNM</div><div>SYS$CREMBX</div><div>SYS$FAO</div></div><h6>Name forms and status codes</h6><div class="kw-grid"><div>SYS$XXX</div><div>sys$xxx</div><div>Fortran trailing _</div><div>EXE$XXX</div><div>COB$XXX</div><div>SS$_NORMAL</div><div>SS$_ACCVIO</div><div>SS$_BADPARAM</div><div>SS$_NOPRIV</div><div>SS$_IVCHAN</div><div>SS$_UNSUPPORTED</div></div><h6>Queue, wait, and read-time skeleton</h6><p>
A migrated program links this unchanged against <code>libvxrt.a</code>. Note the
<code>ODD()</code> status test after each call and the event-flag synchronization after the queued
write:
</p>
<pre><span class="cmt">// timestamp and queue a write to the funds-transfer journal device</span>
status = SYS$GETTIM(&now); <span class="cmt">// current system time, 100 ns units</span>
<span class="kw">if</span> (!ODD(status)) <span class="kw">goto</span> fail;
status = SYS$ASSIGN("BANKING$JOURNAL", &chan, 0, 0);
<span class="kw">if</span> (!ODD(status)) <span class="kw">goto</span> fail;
status = SYS$QIO(efn, chan, IO$_WRITEVBLK, <span class="cmt">// queue the asynchronous write</span>
&iosb, 0, 0,
record, record_len, 0, 0, 0, 0);
<span class="kw">if</span> (!ODD(status)) <span class="kw">goto</span> fail;
status = SYS$SYNCH(efn, &iosb); <span class="cmt">// wait for completion via the IOSB</span>
<span class="kw">if</span> (!ODD(status)) <span class="kw">goto</span> fail;
SYS$DASSGN(chan); <span class="cmt">// release the channel</span></pre>
<h6>Related pages</h6><ul><li><a href="/technical/vx-rt-apis">VX/RT APIs</a> for the runtime ecosystem that VX/EXE$ is part of.</li><li><a href="/technical/api-sys-interface-routines">SYS$ Interface Routines</a> for the wider system-service surface built on the same executive workers.</li><li><a href="/technical/vx-rms-sys-routines-for-rms">VX/RMS SYS$ Routines for RMS</a> for the record and file services behind open, close, get, and put.</li><li><a href="/technical/vx-jsp-vms-print-batch">VX/JSP OpenVMS Print and Batch</a> for the print and batch queues that the queue-information services report on.</li><li><a href="/technical/api-lib-general-routines">LIB$ General Routines</a> and <a href="/technical/api-str-string-interface-routines">STR$ String Routines</a> for the run-time-library companions in the same collection.</li></ul></div>
