EXE$ – Operating System Interface

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.

Architecture and how it maps to the host

VX/EXE$ is a linked runtime library, not a server or daemon. It is archived into libvxrt.a, 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.

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.

No service to administer. 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.

Layering

The runtime sits between the unchanged application and the host operating system:

Caller

Migrated applicationUnchanged SYS$ and EXE$ calls

Runtime

VX/EXE$ in libvxrt.aRoutes each in-process call to the matching service family.

01Timers and timeClock, timer, and time conversion services.

02Event flagsEvent flag allocation, state, and synchronization.

03Queued I/O driversDisk, terminal, network, and mailbox device I/O.

04Process and informationProcess, queue, and system information services.

Host

Host operating systemFiles, sockets, threads, and clocks.

The call wrapper

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 SYS$ 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.

U32 SYS_D_GETTIM(void *sm_time) {
    VX_BEGINS;                          // open trace scope
    U32 rc = EXE_D_GETTIM(sm_time);     // call the inner executive worker
    VX_RETURNS(rc);                     // close trace scope, return the condition code
}

EXE$ and SYS$: the alias model

On OpenVMS, the EXE$ names are the executive-mode entry points that the SYS$ 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 SYS$ form wrapping the worker in the runtime trace scope and the EXE$ form exposing the bare inner call.

// one worker, two OpenVMS names
__AliasF(SYS_D_GETTIM, SYS$GETTIM, sys$gettim);
__AliasF(EXE_D_GETTIM, EXE$GETTIM, exe$gettim);

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 COB$ 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.

The exported EXE$ entry points

The load-bearing detail for planning a migration is that the EXE$ surface is small and specific. These are the executive entry points exported directly under the EXE$ prefix; each is also available under its SYS$ name.

EXE$ entry point	SYS$ equivalent	Purpose	Status
`EXE$GETTIM`	`SYS$GETTIM`	Return the current system time in 100 ns units.	live
`EXE$SYNCH`	`SYS$SYNCH`	Synchronize on an event flag and I/O status block.	live
`EXE$QIO`	`SYS$QIO`	Queue an asynchronous I/O request on a channel.	live
`EXE$CANCEL`	`SYS$CANCEL`	Cancel an outstanding I/O request on a channel.	live
`EXE$GETQUI`	`SYS$GETQUI`	Retrieve queue information.	live

Executive and system forms are not identical. The SYS$ form is wrapped in the runtime trace scope while the EXE$ 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.

File and record verbs live in VX/RMS. Record operations such as open, close, get, put, connect, and rename are OpenVMS RMS services, not executive entry points, and are provided by VX/RMS. Use this page for system services and the executive interface, and VX/RMS for record and file management.

SYS$ system service reference

VX/EXE$ exports the OpenVMS system-service callable interface. Each service is available under its SYS$ name, the Fortran trailing-underscore aliases, and, for the executive entry points listed above, an EXE$ 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 Stubs and unimplemented services.

Time and timers

SYS$ routine	Purpose
`SYS$GETTIM`	Return the current system time as a 64-bit value in 100 ns units.
`SYS$ASCTIM`	Convert a binary time value to an ASCII string.
`SYS$BINTIM`	Convert an ASCII date and time string to binary format.
`SYS$NUMTIM`	Convert a binary time to a numeric seven-word vector.
`SYS$SETIMR`	Set a timer that sets an event flag or delivers an AST on expiry.
`SYS$CANTIM`	Cancel a pending timer request.
`SYS$SCHDWK` / `SYS$CANWAK`	Schedule or cancel a scheduled process wakeup.

Event flags and synchronization

SYS$ routine	Purpose
`SYS$SYNCH`	Wait for the completion of a queued request using an event flag and I/O status block.
`SYS$WAITFR`	Wait for a single event flag.
`SYS$WFLAND` / `SYS$WFLOR`	Wait for a logical AND or OR of a set of event flags.
`SYS$SETEF` / `SYS$CLREF` / `SYS$READEF`	Set, clear, or read an event flag.
`SYS$ASCEFC` / `SYS$DACEFC`	Associate or disassociate a common event flag cluster.

Queued I/O, channels, and devices

SYS$ routine	Purpose
`SYS$QIO` / `SYS$QIOW`	Queue an asynchronous I/O request, or queue and wait for completion.
`SYS$CANCEL`	Cancel outstanding I/O on a channel.
`SYS$ASSIGN` / `SYS$DASSGN`	Assign or deassign an I/O channel to a device.
`SYS$ALLOC` / `SYS$DALLOC`	Allocate or deallocate a device.
`SYS$MOUNT` / `SYS$DISMOU`	Mount or dismount a volume.
`SYS$BRDCST` / `SYS$BRKTHRU`	Broadcast or break through a message to one or more terminals.

Queued I/O is backed by per-device driver modules built into libvxrt.a for disk, terminal, network, and mailbox devices, with a shared support layer and a driver thread providing asynchronous completion.

Process control

SYS$ routine	Purpose
`SYS$CREPRC` / `SYS$DELPRC`	Create or delete a process.
`SYS$SUSPND` / `SYS$RESUME`	Suspend or resume a process.
`SYS$HIBER` / `SYS$WAKE`	Hibernate the current process or wake a hibernating process.
`SYS$SETPRI` / `SYS$SETPRN`	Set process priority or process name.
`SYS$FORCEX` / `SYS$EXIT`	Force another process to exit, or exit the current image.
`SYS$DCLEXH` / `SYS$CANEXH`	Declare or cancel an exit handler.
`SYS$DCLAST` / `SYS$SETAST`	Declare an AST, or enable and disable AST delivery.
`SYS$PROCESS_SCAN`	Build a process-scan context for use with the information services.

Information services

SYS$ routine	Purpose
`SYS$GETJPI` / `SYS$GETJPIW`	Get job and process information.
`SYS$GETDVI` / `SYS$GETDVIW`	Get device and volume information.
`SYS$GETSYI` / `SYS$GETSYIW`	Get system information.
`SYS$GETUAI`	Get user authorization information.
`SYS$GETQUI` / `SYS$GETQUIW`	Get queue information synchronously or asynchronously.
`SYS$GETMSG` / `SYS$PUTMSG`	Retrieve or format a system message.

Logical names, memory, and interprocess services

SYS$ routine	Purpose
`SYS$CRELNM` / `SYS$DELLNM` / `SYS$TRNLNM`	Create, delete, or translate a logical name.
`SYS$CRELNT`	Create a logical name table.
`SYS$EXPREG` / `SYS$CRETVA` / `SYS$DELTVA`	Expand the program region, or create and delete virtual address space.
`SYS$CRMPSC` / `SYS$MGBLSC`	Create and map a section, or map a global section.
`SYS$CREMBX` / `SYS$DELMBX`	Create or delete a mailbox for interprocess communication.
`SYS$SNDJBC` / `SYS$SNDOPR`	Send a request to the job controller or to the operator.
`SYS$FAO` / `SYS$FAOL`	Formatted ASCII output, direct and list form.

One implementation, every name form. Because each service is exported under its SYS$, Fortran, and (where applicable) EXE$ and COB$ names, a mixed-language application links against the same worker set without per-language shims.

Status codes and return model

Every service returns a 32-bit VMS condition value. Applications that inspect these codes keep working unchanged, because VX/EXE$ returns the same SS$_XXX symbols and preserves the VMS severity convention: a successful status is odd, a failure is even, so existing ODD(status) tests behave exactly as they did on VMS. A representative set of the codes the system services use most:

Symbol	Decimal	Meaning
`SS$_NORMAL`	1	Successful completion.
`SS$_ACCVIO`	12	Access violation on a call argument.
`SS$_BADPARAM`	20	Bad parameter value.
`SS$_NOPRIV`	36	Insufficient privilege for the operation.
`SS$_INSFARG`	276	Too few call arguments supplied.
`SS$_INSFMEM`	292	Insufficient dynamic memory.
`SS$_IVCHAN`	316	Invalid channel number.
`SS$_TIMEOUT`	556	Timeout period expired.
`SS$_UNSUPPORTED`	3658	Service or sub-function not implemented.
`SS$_INVARG`	4042	Invalid argument.

Return by value, and by convention. The condition value is returned by the call and follows the standard VMS odd-equals-success rule. Code that branches on ODD(status) or compares against a named SS$_ symbol needs no change on the new platform.

Stubs and unimplemented services

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.

SYS$ routine	Purpose on VMS	Behaviour
`SYS$CMEXEC`	Change to executive access mode.	stub: returns success and does nothing
`SYS$NEWPROC`	Create a process.	stub: returns success, no process created
`SYS$LCKPAG`	Lock pages in physical memory.	stub: returns success, pages are not locked
`SYS$ADJWSL`	Adjust the working-set limit.	stub: no-op, echoes the requested value
`SYS$SNDSMB`	Send a request to a symbiont.	stub: returns success, no request sent
`SYS$CREATE_REGION_64` / `SYS$DELETE_REGION_64`	Create or delete a 64-bit virtual region.	unsupported: reports unsupported and exits the image
`SYS$GETRMI`	Get resource-management information.	unimplemented: aborts if called
`SYS$START_TRANSW` / `SYS$END_TRANSW` / `SYS$ABORT_TRANSW`	DECdtm distributed transaction control.	stub: marks the status block and returns success, no transaction manager

Silent success versus hard stop. 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.

Compatibility and deliberate divergences

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.

Capability	Status	Note
Time and timer services	live	System time, conversions, timers, and scheduled wakeups.
Event flags and synchronization	live	Local and common event flags, wait-for combinations, and I/O status synchronization.
Queued I/O and channel management	live	Disk, terminal, network, and mailbox drivers behind the QIO family.
Process control and ASTs	live	Create, delete, suspend, resume, hibernate, wake, and AST delivery.
Information and queue services	live	Job, device, system, and queue information queries.
Logical names and interprocess services	live	Logical-name creation and translation, mailboxes, and message formatting.
Page locking and working-set control	out of scope	Accepted as no-ops; the host manages memory residency.
64-bit region create and delete	out of scope	Reported unsupported; the call exits the image.
Distributed transactions (DECdtm)	out of scope	Accepted but inert; there is no transaction manager.
Resource-management information	out of scope	The query is unimplemented and aborts if called.

Deliberate divergences from native OpenVMS

These are behaviours that differ by design because the host is Linux rather than OpenVMS:

Executive versus system form. The SYS$ entry point is wrapped in the runtime trace scope; the EXE$ entry point is the bare inner worker. They service the same request but are not identical for instrumentation.
Privileged memory services. Page locking and working-set adjustment are no-ops, because residency is managed by the host kernel rather than by the application.
No executive mode. The change-mode service returns success without switching modes, since the host has no VMS access-mode model.
Record and file verbs are elsewhere. Open, close, get, put, connect, and similar record operations are RMS services provided by VX/RMS, not executive entry points on this interface.
Condition values, not signals. Errors are returned by value as SS$_ codes; there is no VMS condition-handler dispatch behind the calls.

Quick reference

EXE$ executive entry points

EXE$GETTIM

EXE$SYNCH

EXE$QIO

EXE$CANCEL

EXE$GETQUI

Representative SYS$ services

SYS$GETTIM

SYS$ASCTIM

SYS$BINTIM

SYS$SETIMR

SYS$SYNCH

SYS$WAITFR

SYS$SETEF

SYS$CLREF

SYS$QIO

SYS$QIOW

SYS$CANCEL

SYS$ASSIGN

SYS$CREPRC

SYS$DELPRC

SYS$HIBER

SYS$WAKE

SYS$GETJPI

SYS$GETDVI

SYS$GETSYI

SYS$GETQUI

SYS$CRELNM

SYS$TRNLNM

SYS$CREMBX

SYS$FAO

Name forms and status codes

SYS$XXX

sys$xxx

Fortran trailing _

EXE$XXX

COB$XXX

SS$_NORMAL

SS$_ACCVIO

SS$_BADPARAM

SS$_NOPRIV

SS$_IVCHAN

SS$_UNSUPPORTED

Queue, wait, and read-time skeleton

A migrated program links this unchanged against libvxrt.a. Note the ODD() status test after each call and the event-flag synchronization after the queued write:

// timestamp and queue a write to the funds-transfer journal device
status = SYS$GETTIM(&now);                       // current system time, 100 ns units
if (!ODD(status)) goto fail;

status = SYS$ASSIGN("BANKING$JOURNAL", &chan, 0, 0);
if (!ODD(status)) goto fail;

status = SYS$QIO(efn, chan, IO$_WRITEVBLK,       // queue the asynchronous write
                 &iosb, 0, 0,
                 record, record_len, 0, 0, 0, 0);
if (!ODD(status)) goto fail;

status = SYS$SYNCH(efn, &iosb);                  // wait for completion via the IOSB
if (!ODD(status)) goto fail;

SYS$DASSGN(chan);                                // release the channel

On this page

Architecture and how it maps to the host

Layering

The call wrapper

EXE$ and SYS$: the alias model

The exported EXE$ entry points

SYS$ system service reference

Time and timers

Event flags and synchronization

Queued I/O, channels, and devices

Process control

Information services

Logical names, memory, and interprocess services

Status codes and return model

Stubs and unimplemented services

Compatibility and deliberate divergences

Deliberate divergences from native OpenVMS

Quick reference

EXE$ executive entry points

Representative SYS$ services

Name forms and status codes

Queue, wait, and read-time skeleton

Frequently Asked Questions

Curious about how Sector7 can facilitate your application migration? Explore our FAQs for expert insights.

Free Code Assessment

What is VX/EXE$ and how does it help with OpenVMS migration?

VX/EXE$ provides a call-compatible implementation of OpenVMS process execution and image management APIs for x86 and ARM Linux. It enables seamless migration of OpenVMS applications that rely on EXE$ routines for process control, file handling, and execution workflows while maintaining compatibility with existing OpenVMS logic.

Organizations can migrate critical applications without major modifications, preserving productivity and minimizing development costs. Contact us to discuss your OpenVMS migration requirements.

Which OpenVMS EXE$ APIs does VX/EXE$ support?

VX/EXE$ supports comprehensive OpenVMS EXE$ APIs including process execution, file management, data retrieval, and system interactions such as EXE$CREATE, EXE$DELETE, EXE$QIO, EXE$READ, EXE$WRITE, and EXE$GETTIM.

Does VX/EXE$ maintain OpenVMS process control semantics on Linux?

Yes, VX/EXE$ maintains OpenVMS process control semantics to ensure consistent behavior on Linux, preserving the original application logic and execution workflows.

What process execution capabilities are available in VX/EXE$?

VX/EXE$ supports process connections, synchronization, resource management, queue operations, and time management functions including EXE$CONNECT, EXE$SYNCH, EXE$GETQUI, and EXE$ASCTIM.

How does VX/EXE$ handle file operations and data management?

VX/EXE$ provides comprehensive file management through APIs like EXE$OPEN, EXE$CLOSE, EXE$COPY, EXE$RENAME, EXE$TRUNCATE, and EXE$UPDATE. These functions enable applications to perform complete file lifecycle operations while maintaining OpenVMS compatibility.

Organizations like Telstra have successfully migrated complex file management systems using similar OpenVMS compatibility tools.

How does VX/EXE$ integrate with the VX/RT ecosystem?

VX/EXE$ seamlessly integrates with VX/RT to provide full OpenVMS execution and image management capabilities on x86 and ARM Linux platforms.

What are the key migration benefits of using VX/EXE$?

VX/EXE$ preserves OpenVMS execution logic, provides full compatibility with process and file management functions, supports critical execution workflows, and enables direct porting without major application modifications.

What results can organizations expect when implementing VX/EXE$?

Organizations implementing VX/EXE$ achieve seamless OpenVMS application migration with preserved functionality and reduced development costs. The tool ensures applications requiring EXE$ services migrate without major modifications while maintaining productivity.

Companies like Allianz have successfully modernized their OpenVMS systems using comprehensive migration approaches. VX/EXE$ eliminates vendor lock-in and enables organizations to leverage modern Linux infrastructure while preserving critical business logic.

To explore how VX/EXE$ can support your migration project, contact us for a consultation.

What is VX/EXE$?

VX/EXE$ is the OpenVMS executive and system-service interface of VX/RT. It provides a call-compatible implementation of the OpenVMS SYS$ system services and the EXE$ executive entry points on x86 and ARM Linux, so OpenVMS applications keep their existing logic for timers, event flags, I/O, process control, and queue services.

Does VX/EXE$ require rewriting our application?

No. VX/EXE$ is call-compatible with the OpenVMS SYS$ and EXE$ routines, so applications that depend on those services can be recompiled and relinked without major source changes. They call the same routines, pass the same arguments, and read back the same VMS condition codes.

Which CPU architectures and platforms does VX/EXE$ support?

VX/EXE$ runs on x86 and ARM Linux. It is delivered inside the VX/RT runtime as part of the shared libvxrt.a archive, so it links directly into the migrated application rather than running as a separate service.

What is the difference between the EXE$ and SYS$ names?

On OpenVMS the EXE$ names are the executive entry points that the SYS$ system-service dispatchers call. VX/EXE$ preserves both, so code that links against either resolves. The SYS$ form is instrumented for tracing while the EXE$ form is the bare inner worker; both perform the same operation.

What kinds of services does VX/EXE$ cover?

It covers timers and time conversion, event flags and synchronization, queued I/O and channel management, process control and ASTs, information and queue queries, logical names, memory sections, mailboxes, and message formatting. Record and file operations are handled by VX/RMS.

Are there OpenVMS services that behave differently on Linux?

Yes, and they are documented plainly. A small set of privileged services, such as page locking, working-set adjustment, and change-mode, are accepted as no-ops because the host kernel manages those functions. The 64-bit region services and the resource-management query are reported as unsupported, so migration planning should account for them.

Does VX/EXE$ preserve OpenVMS status codes and error handling?

Yes. Every service returns a 32-bit VMS condition value using the same SS$ symbols, and the odd-equals-success severity convention is preserved, so existing ODD(status) tests and comparisons against named SS$ codes work unchanged.

How does VX/EXE$ relate to VX/RT and VX/RMS?

VX/EXE$ is the system-service layer of the VX/RT runtime, which provides OpenVMS compatibility on Linux. VX/RMS is the companion layer that provides the RMS record and file services such as open, close, get, put, and connect. Together they let OpenVMS applications run on x86 and ARM Linux without rewriting their system-level logic.

Transform Your Legacy Software Today!

Get In Touch

Unlock the potential of your legacy software with our expert migration services.

EXE$ – Operating System Interface

Overview

Architecture and how it maps to the host

Layering

The call wrapper

EXE$ and SYS$: the alias model

The exported EXE$ entry points

SYS$ system service reference

Time and timers

Event flags and synchronization

Queued I/O, channels, and devices

Process control

Information services

Logical names, memory, and interprocess services

Status codes and return model

Stubs and unimplemented services

Compatibility and deliberate divergences

Deliberate divergences from native OpenVMS

Quick reference

EXE$ executive entry points

Representative SYS$ services

Name forms and status codes

Queue, wait, and read-time skeleton

Related pages

Frequently Asked Questions

Transform Your Legacy Software Today!