🚨 Oracle not porting Rdb to x86 and EOL on Itanium 12/2027 🚨
Technical Capabilities
Having trouble finding what you need?
Get in touch with us, so we can answer your specific questions directly.
Get In Touch

SYS$ - SYS$ Interface Routines

Overview

VX/SYS$ is a call-compatible implementation of the OpenVMS SYS$ system services for x86 and ARM Linux. It lets migrated OpenVMS applications perform system-level work such as device and resource management, process creation and control, event flags and locks, logical names, timers, privilege checks, and interprocess communication, while preserving the exact call signatures and VMS condition codes the original code depends on. VX/SYS$ is delivered inside VX/RT and links straight into the recompiled program, so there is no system-service process to install or administer.

Each service is written once as an inner worker and exported under its OpenVMS names through linker aliases, so recompiled C, Fortran, and COBOL programs call the same routines, pass the same arguments, and read back the same status values as they did on VMS. The SYS$ module itself provides more than 110 system-service entry points; together with the RMS file services and lock-manager services linked from the same runtime, an application sees the full OpenVMS SYS$ callable surface of over 150 routines. Services with no equivalent on a host operating system are documented plainly, so migration planners know exactly where behaviour differs.

<!-- Webflow embed (min). Source: sys-page-technical/sys-tech-body-embed-dark.html → python3 website/embeds/minify_webflow_embed.py … --> <div class="s7-tech-embed" data-vxsysd-body-embed="1" data-technical-mega-embed="1" lang="en"><h2 id="architecture">Architecture and the callable surface</h2><p> VX/SYS$ is a linked runtime library, not a server or a 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. Every call is serviced in-process by the library, which presents the OpenVMS system-service callable interface on top of ordinary host facilities: files, sockets, threads, and clocks. </p><div class="callout"><strong>No service to administer.</strong> VX/SYS$ has no privileged executive to install and no system-service process to manage. The library runs in the address space of the migrated program, so deployment is a link step rather than a service install. </div><h6>The callable surface</h6><p> The SYS$ module itself exports more than 110 system-service entry points. A migrated application, however, sees a wider callable surface of over 150 <code>SYS$</code> routines, because the file and record services and the lock-manager services are provided by sibling modules linked from the same runtime. Those siblings are documented on their own pages: the RMS-shaped services such as <code>SYS$OPEN</code>, <code>SYS$READ</code>, and <code>SYS$CONNECT</code> live in <a href="/technical/vx-rms-sys-routines-for-rms">VX/RMS</a>, and the lock services <code>SYS$ENQ</code>, <code>SYS$DEQ</code>, and <code>SYS$GETLKI</code> live in <a href="/technical/vx-lckmgr-vms-openvms-lock-manager-for-x86-intel-linux">VX/LCKMGR</a>. This page covers the system-service routines implemented in the SYS$ module itself. </p><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/SYS runtime layering and service families"><div class="process-endpoint"><span class="process-label">Caller</span><div><strong>Migrated application</strong><span>Unchanged SYS$ calls</span></div></div><div class="process-endpoint process-runtime"><span class="process-label">Runtime</span><div><strong>VX/SYS$ 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, mailbox, Ethernet, and TCP/IP device I/O.</span></div><div class="process-stage"><span class="process-number">04</span><strong>Process and information</strong><span>Process, memory, 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 queued I/O driver subsystem</h6><p> The I/O services are not a flat call table. <code>SYS$QIO</code> and <code>SYS$QIOW</code> validate the channel, then forward to an inner executive worker that routes the request to a per-device-class driver. Each driver is compiled into <code>libvxrt.a</code> and runs on a dedicated POSIX thread, with ASTs delivered by queuing onto the per-process AST dispatcher. </p><div class="table-wrapper"><table><thead><tr><th>VMS device class</th><th>Driver</th><th>Built by default</th><th>Role</th></tr></thead><tbody><tr><td>Disk</td><td><code>QIODSKDRV</code></td><td><span class="ac-live">yes</span></td><td>Block and file disk I/O.</td></tr><tr><td>Terminal</td><td><code>QIOTRMDRV</code></td><td><span class="ac-live">yes</span></td><td>Terminal and TTY I/O.</td></tr><tr><td>Mailbox</td><td><code>QIOMBOX</code></td><td><span class="ac-live">yes</span></td><td>Mailbox interprocess communication over a FIFO.</td></tr><tr><td>Network</td><td><code>QIONETDRV</code></td><td><span class="ac-live">yes</span></td><td>DECnet-style network I/O.</td></tr><tr><td>Ethernet</td><td><code>QIOETHER</code></td><td><span class="ac-v1">opt-in</span></td><td>Raw Ethernet I/O, enabled at build time.</td></tr><tr><td>TCP/IP (UCX)</td><td><code>QIOUCX</code></td><td><span class="ac-v1">opt-in</span></td><td>TCP/IP and DECnet via UCX, enabled at build time.</td></tr></tbody></table></div><p> A shared support layer and the driver-thread module provide the asynchronous plumbing behind the whole QIO family, so a queued read or write behaves as it did on VMS regardless of the underlying host device. </p><h2 id="name-forms">Name forms and the alias model</h2><p> Each routine is compiled once as a canonical internal symbol, then exported under the names the original application used through alias macros. A single implementation is therefore reachable from C, Fortran, and COBOL under the exact spellings that appear in the legacy source, with no per-language shim to write or maintain. </p><div class="table-wrapper"><table><thead><tr><th>Name form</th><th>Example</th><th>Who calls it</th></tr></thead><tbody><tr><td><code>SYS_D_xxxx</code></td><td><code>SYS_D_QIOW</code></td><td>Canonical internal symbol: the real routine body.</td></tr><tr><td><code>SYS$xxxx</code> (upper)</td><td><code>SYS$QIOW</code></td><td>VMS-style C and C++ callers.</td></tr><tr><td><code>sys$xxxx</code> (lower)</td><td><code>sys$qiow</code></td><td>VMS-style C and C++ callers.</td></tr><tr><td><code>F4_SYS_D_xxxx</code></td><td><code>F4_SYS_D_QIOW</code></td><td>Fortran callers, with trailing string-length arguments.</td></tr></tbody></table></div><p> Two alias macros wire these up. <code>__AliasF</code> binds the three C names to one symbol for routines that take no string arguments. <code>__AliasF4</code> binds all four names and adds the Fortran trampoline for routines that take descriptors, so F77 string-length arguments are unpacked correctly. </p> <pre><span class="cmt">// no string arguments: three C names, one symbol</span> __AliasF (SYS_D_GETTIM, <span class="str">SYS$GETTIM</span>, sys$gettim); <span class="cmt">// takes descriptors: adds the Fortran name and trampoline</span> __AliasF4 (SYS_D_QIOW, F4_SYS_D_QIOW, <span class="str">SYS$QIOW</span>, sys$qiow);</pre> <h6>Cross-language re-aliases</h6><p> A small set of routines carry extra prefixes for callers generated in other languages: </p><ul><li><strong><code>COB$xxxx</code></strong> re-exports let generated COBOL issue <code>CALL "COB$xxxx"</code>. These are identical wrappers of their <code>SYS$</code> counterparts, covering information and job-control services such as <code>COB$GETJPI</code>, <code>COB$GETSYI</code>, <code>COB$SNDJBC</code>, and <code>COB$TRNLNM</code>.</li><li><strong><code>EXE$xxxx</code></strong> exports expose the inner executive workers directly. Unlike the COBOL re-aliases, these are not identical wrappers: the <code>SYS$</code> form wraps the inner worker in the runtime trace scope, while the <code>EXE$</code> form is the bare inner call. The routines with both forms are <code>CANCEL</code>, <code>GETQUI</code>, <code>GETTIM</code>, <code>QIO</code>, and <code>SYNCH</code>.</li></ul><div class="callout"><strong>The executive seam is a separate page.</strong> The inner <code>EXE$</code> executive entry points that these system services wrap are documented in detail on <a href="/technical/api-exe-operating-system-interface">EXE$ Operating System Interface</a>. Use this page for the <code>SYS$</code> system-service surface, and the EXE$ page for the executive workers underneath it. </div><h2 id="routines">SYS$ routine families</h2><p> The system services group into the same functional areas an OpenVMS programmer already knows. The tables below list representative routines from each family; most carry an operative implementation, and 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><div class="callout"><strong>Where file and lock services live.</strong> The RMS-shaped file and record verbs (<code>SYS$OPEN</code>, <code>SYS$CLOSE</code>, <code>SYS$READ</code>, <code>SYS$WRITE</code>, <code>SYS$CONNECT</code>, <code>SYS$PARSE</code> and their siblings) are provided by <a href="/technical/vx-rms-sys-routines-for-rms">VX/RMS</a>, and the lock services (<code>SYS$ENQ</code>, <code>SYS$DEQ</code>, <code>SYS$GETLKI</code>) by <a href="/technical/vx-lckmgr-vms-openvms-lock-manager-for-x86-intel-linux">VX/LCKMGR</a>. They are callable from the same runtime but documented on those pages. </div><h6>Device, resource, and channel management</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><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 or resource, with advisory locks for multi-process use.</td></tr><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 an outstanding I/O request on a channel.</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$GETCHN</code></td><td>Get the channel number assigned to a device.</td></tr></tbody></table></div><h6>Process control and ASTs</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$DCLAST</code> / <code>SYS$SETAST</code></td><td>Declare an AST, or enable and disable AST delivery.</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$PROCESS_SCAN</code></td><td>Build a process-scan context for the information services.</td></tr></tbody></table></div><h6>Memory and virtual address space</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$EXPREG</code></td><td>Expand the program region.</td></tr><tr><td><code>SYS$CRETVA</code> / <code>SYS$DELTVA</code></td><td>Create or delete virtual address space.</td></tr><tr><td><code>SYS$CRETVA_64</code> / <code>SYS$DELTVA_64</code></td><td>Create or delete a 64-bit 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, backed by memory mapping.</td></tr><tr><td><code>SYS$MGBLSC_64</code></td><td>Map a 64-bit global section.</td></tr></tbody></table></div><h6>Event flags, timers, 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 a queued request to complete 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><tr><td><code>SYS$SETIMR</code> / <code>SYS$CANTIM</code></td><td>Set a timer that sets an event flag or delivers an AST, or cancel a pending timer.</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>Time and format conversion</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$FAO</code> / <code>SYS$FAOL</code></td><td>Formatted ASCII output, direct and list form.</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$GETSYI</code> / <code>SYS$GETSYIW</code></td><td>Get system information.</td></tr><tr><td><code>SYS$GETUAI</code> / <code>SYS$GETUAIW</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, messaging, and job control</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$CREMBX</code> / <code>SYS$DELMBX</code></td><td>Create or delete a mailbox for interprocess communication.</td></tr><tr><td><code>SYS$BRDCST</code> / <code>SYS$BRKTHRU</code> / <code>SYS$BRKTHRUW</code></td><td>Broadcast or break through a message to one or more terminals.</td></tr><tr><td><code>SYS$SNDJBC</code> / <code>SYS$SNDJBCW</code> / <code>SYS$SNDOPR</code></td><td>Send a request to the job controller or to the operator.</td></tr></tbody></table></div><h6>Privilege and security</h6><div class="table-wrapper"><table><thead><tr><th>SYS$ routine</th><th>Purpose</th></tr></thead><tbody><tr><td><code>SYS$CHECK_PRIVILEGE</code> / <code>SYS$CHECK_PRIVILEGEW</code></td><td>Check whether a process holds a specific privilege.</td></tr><tr><td><code>SYS$SETPRV</code></td><td>Set process privileges.</td></tr><tr><td><code>SYS$SETDDIR</code></td><td>Set the default directory for the process.</td></tr></tbody></table></div><div class="callout"><strong>Wait variants are included.</strong> The OpenVMS wait-synchronized <code>W</code> variants ship alongside their base calls, for example <code>SYS$QIO</code> and <code>SYS$QIOW</code>, <code>SYS$GETJPI</code> and <code>SYS$GETJPIW</code>, so code that relies on the original synchronization semantics needs no rework. </div><h2 id="conventions">Argument passing and status conventions</h2><p> VX/SYS$ preserves the OpenVMS calling conventions exactly, so recompiled code passes the same argument shapes and reads back the same results. Three conventions matter for a migration: string descriptors, item lists, and the condition-value return model. </p><h6>String descriptors</h6><p> All character arguments use the same VMS descriptor model as the STR$ library, in both 32-bit and 64-bit forms, classified automatically at the call. The same descriptor helpers extract or build a descriptor regardless of width, so a routine accepts whichever form the caller passes. The shared descriptor model is documented on <a href="/technical/api-str-string-interface-routines">STR$ String Interface Routines</a>. </p><h6>Item lists</h6><p> The information services and several others take a zero-terminated item-list array. Both the 32-bit and 64-bit item-list layouts are accepted and detected per element: </p> <pre><span class="kw">struct</span> ITL { <span class="cmt">// 32-bit form</span> <span class="kw">union</span> { <span class="kw">struct</span> { <span class="kw">short</span> Length; <span class="kw">short</span> Code; } Item; <span class="kw">long</span> terminator; <span class="cmt">// zero longword ends the list</span> } u; <span class="kw">void</span> *Address; <span class="cmt">// buffer for the item value</span> <span class="kw">short</span> *Length_Ptr; <span class="cmt">// OUT: actual returned length</span> };</pre> <p> Outputs are stored only when the caller supplies a non-NULL pointer, matching the OpenVMS convention that optional return arguments may be omitted. </p><h6>Status codes and the return model</h6><p> Every service returns a 32-bit VMS condition value. VX/SYS$ 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$_INSFARG</code></td><td>276</td><td>Too few call arguments supplied.</td></tr><tr><td><code>SS$_IVCHAN</code></td><td>316</td><td>Invalid channel number.</td></tr><tr><td><code>SS$_IVLOGNAM</code></td><td>340</td><td>Invalid logical name.</td></tr><tr><td><code>SS$_NOLOGNAM</code></td><td>444</td><td>No such logical name.</td></tr><tr><td><code>SS$_TIMEOUT</code></td><td>556</td><td>Timeout period expired.</td></tr><tr><td><code>SS$_SUPERSEDE</code></td><td>1585</td><td>A logical name superseded an existing definition.</td></tr><tr><td><code>SS$_UNSUPPORTED</code></td><td>3658</td><td>Service or sub-function not implemented.</td></tr></tbody></table></div><p> Most services return the condition value directly. A small number additionally raise conditions as VMS-style signals, catchable with the usual condition-handler establishment or a C++ handler, so code that relies on signalled conditions still works. </p><h6>Tracing scaffold</h6><p> Every routine opens with a trace-entry marker and returns through a matching trace-exit marker, so per-thread entry and exit records feed the runtime debug logger. The instrumentation is uniform across the whole service set, which makes a migrated application straightforward to trace end to end during cut-over. </p><h2 id="stubs">Stubs and unimplemented services</h2><p> The great majority of the system services carry a real implementation. A specific, enumerated set describes privileged or host-specific operations that have no equivalent on Linux. VX/SYS$ 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 on Linux</th></tr></thead><tbody><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$MOUNT</code> / <code>SYS$DISMOU</code></td><td>Mount or dismount a volume.</td><td><span class="ac-no">unimplemented: aborts if called</span></td></tr><tr><td><code>SYS$GET_SECURITY</code> / <code>SYS$SET_SECURITY</code></td><td>Get or set an object's security profile.</td><td><span class="ac-no">unimplemented: aborts if called</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$LCKPAG</code></td><td>Lock pages in physical memory.</td><td><span class="ac-no">no-op: 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">no-op: echoes the requested value, residency unchanged</span></td></tr><tr><td><code>SYS$CMEXEC</code></td><td>Change to executive access mode.</td><td><span class="ac-no">no-op: returns success, mode unchanged</span></td></tr><tr><td><code>SYS$SNDSMB</code></td><td>Send a request to a symbiont.</td><td><span class="ac-no">no-op: returns success, no request sent</span></td></tr><tr><td><code>SYS$SETRWM</code></td><td>Set resource-wait mode.</td><td><span class="ac-no">no-op: the flag is stored but not consulted</span></td></tr><tr><td><code>SYS$DELMBX</code></td><td>Delete a mailbox.</td><td><span class="ac-v1">partial: returns success but does not unlink the underlying FIFO</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><tr><td><code>SYS$GRANT_LICENSE</code></td><td>Grant a product license through LMF.</td><td><span class="ac-no">stub: returns a fixed token, no license 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, mount, and security queries abort if called. Confirm during assessment that a migrating application does not rely on any of these services before it reaches production. </div><h2 id="divergences">Compatibility and deliberate divergences</h2><p> VX/SYS$ covers the system services that production applications actually depend on, and is explicit about the areas that behave differently because the host is Linux rather than OpenVMS. 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>Device, resource, and channel management</td><td><span class="ac-live">live</span></td><td>Assign, allocate, queued I/O, and device information across disk, terminal, network, and mailbox drivers.</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>Event flags, timers, and synchronization</td><td><span class="ac-live">live</span></td><td>Local and common event flags, wait-for combinations, timers, and scheduled wakeups.</td></tr><tr><td>Time and format conversion</td><td><span class="ac-live">live</span></td><td>System time, ASCII and numeric conversion, and formatted output.</td></tr><tr><td>Information services</td><td><span class="ac-live">live</span></td><td>Job, process, device, system, user, 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>Memory and virtual address space</td><td><span class="ac-live">live</span></td><td>Region expansion, virtual address creation, and section mapping backed by host memory mapping.</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 kernel manages 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>Volume mount and security profiles</td><td><span class="ac-no">out of scope</span></td><td>Mount, dismount, and the security get/set queries abort 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>Privilege checks are advisory.</strong> Obvious cases return <code>SS$_NOPRIV</code>, but most services do not enforce the full SOGW protection mask the way VMS does.</li><li><strong>Quotas are not enforced.</strong> An exceeded-quota status is documented as possible but is essentially never produced.</li><li><strong>Clustering is absent.</strong> Node arguments are accepted but everything resolves to the local node; wildcard scans end with the no-more-nodes status.</li><li><strong>ASTs run on a dedicated thread.</strong> ASTs are serialized on a per-process dispatcher and cannot pre-empt CPU-bound mainline code without an explicit cancellation point, so code that relies on AST pre-emption sees different scheduling.</li><li><strong>Process IDs are not host PIDs.</strong> Use <code>SYS$GETJPI</code> to read the VMS process identifiers rather than assuming they match the host operating-system process IDs.</li><li><strong>The exit-status convention is preserved.</strong> <code>SYS$EXIT</code> follows the VMS low-bit rule, where an even code signals failure and an odd code signals success, which can surprise callers new to VMS.</li><li><strong>Access-mode arguments are ignored.</strong> An access-mode argument is accepted for prototype compatibility but not honoured, since the host has no VMS access-mode model.</li></ul><h2 id="quickref">Quick reference</h2><h6>Representative SYS$ services</h6><div class="kw-grid"><div>SYS$ASSIGN</div><div>SYS$DASSGN</div><div>SYS$ALLOC</div><div>SYS$QIO</div><div>SYS$QIOW</div><div>SYS$CANCEL</div><div>SYS$GETDVI</div><div>SYS$CREPRC</div><div>SYS$DELPRC</div><div>SYS$SUSPND</div><div>SYS$RESUME</div><div>SYS$HIBER</div><div>SYS$WAKE</div><div>SYS$SETAST</div><div>SYS$CRETVA</div><div>SYS$CRMPSC</div><div>SYS$SETEF</div><div>SYS$WAITFR</div><div>SYS$SETIMR</div><div>SYS$GETTIM</div><div>SYS$ASCTIM</div><div>SYS$BINTIM</div><div>SYS$GETJPI</div><div>SYS$GETSYI</div><div>SYS$GETQUI</div><div>SYS$CRELNM</div><div>SYS$TRNLNM</div><div>SYS$CREMBX</div><div>SYS$BRDCST</div><div>SYS$PUTMSG</div><div>SYS$SNDJBC</div><div>SYS$SETPRV</div></div><h6>Name forms and status codes</h6><div class="kw-grid"><div>SYS$XXX</div><div>sys$xxx</div><div>Fortran F4_SYS_D_XXX</div><div>COB$XXX</div><div>EXE$XXX</div><div>SS$_NORMAL</div><div>SS$_ACCVIO</div><div>SS$_INSFARG</div><div>SS$_IVCHAN</div><div>SS$_IVLOGNAM</div><div>SS$_TIMEOUT</div><div>SS$_UNSUPPORTED</div></div><h6>Queue, wait, and release 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(&amp;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(<span class="str">"BANKING$JOURNAL"</span>, &amp;chan, 0, 0); <span class="kw">if</span> (!ODD(status)) <span class="kw">goto</span> fail; status = SYS$QIOW(efn, chan, IO$_WRITEVBLK, <span class="cmt">// queue the write and wait for completion</span> &amp;iosb, 0, 0, record, record_len, 0, 0, 0, 0); <span class="kw">if</span> (!ODD(status)) <span class="kw">goto</span> fail; SYS$DASSGN(chan); <span class="cmt">// release the channel</span></pre> <div class="callout"><strong>Wait variants fold in the synchronization.</strong> <code>SYS$QIOW</code> is <code>SYS$QIO</code> followed by an implicit <code>SYS$SYNCH</code> on the same event flag or I/O status block, so the wait-mode variants need no separate <code>SYS$SYNCH</code> or <code>SYS$WAITFR</code> call. </div><h6>Related pages</h6><ul><li><a href="/technical/vx-rt-apis">VX/RT APIs</a> for the runtime ecosystem that hosts VX/SYS$.</li><li><a href="/technical/api-exe-operating-system-interface">EXE$ Operating System Interface</a> for the inner executive workers that the system services wrap.</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, read, and write.</li><li><a href="/technical/vx-lckmgr-vms-openvms-lock-manager-for-x86-intel-linux">VX/LCKMGR</a> for the lock and enqueue services behind <code>SYS$ENQ</code>, <code>SYS$DEQ</code>, and <code>SYS$GETLKI</code>.</li><li><a href="/technical/api-str-string-interface-routines">STR$ String Interface Routines</a> and <a href="/technical/api-lib-general-routines">LIB$ General Routines</a> for the run-time-library companions in the same collection.</li></ul></div>

Frequently Asked Questions

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

What is VX/SYS$ and how does it help with OpenVMS to Linux migration?

VX/SYS$ provides a call-compatible implementation of OpenVMS system service calls for x86 and ARM Linux. It ensures that OpenVMS applications can perform system-level operations such as resource allocation, privilege management, process control, and interprocess communication while maintaining execution compatibility on Linux.

This comprehensive solution preserves OpenVMS system service logic, enabling direct porting of applications without major modifications. For organizations planning their migration strategy, contact us to discuss how VX/SYS$ can streamline your transition.

Which OpenVMS system services does VX/SYS$ support?

VX/SYS$ supports over 150 OpenVMS system service calls including device and resource management, process creation, privilege checking, and system messaging functions.

How does VX/SYS$ handle OpenVMS system calls on Linux?

VX/SYS$ maintains OpenVMS system behavior by providing fully compatible APIs that ensure applications execute as expected without modification on Linux platforms.

What types of system operations can VX/SYS$ handle?

VX/SYS$ handles critical system operations including time conversion, device assignment, memory management, privilege validation, and interprocess communication on Linux.

How does VX/SYS$ integrate with the broader VX/RT ecosystem?

VX/SYS$ seamlessly integrates into the VX/RT ecosystem to provide full OpenVMS system service capabilities on x86 and ARM Linux. This integration ensures comprehensive compatibility for OpenVMS applications requiring system-level operations.

Companies like Telstra have successfully leveraged similar integration approaches for their critical system migrations. The VX/RT ecosystem provides a complete foundation for preserving OpenVMS functionality while transitioning to modern Linux infrastructure.

Can VX/SYS$ be customized for specific system requirements?

VX/SYS$ provides full compatibility with OpenVMS SYS$ functions and can be configured to support specific application requirements while maintaining standard OpenVMS behavior.

What challenges does VX/SYS$ solve for OpenVMS migrations?

VX/SYS$ eliminates the need to rewrite system service calls during OpenVMS to Linux migration. It preserves existing application logic and system interactions, reducing migration complexity and development costs.

What are the key benefits of using VX/SYS$ for system migration?

VX/SYS$ delivers significant migration benefits by preserving OpenVMS system service logic and providing full compatibility with SYS$ functions. This ensures seamless execution of system operations on Linux while minimizing development costs and reducing migration risks.

Organizations can maintain their substantial investments in OpenVMS applications while transitioning to modern, scalable Linux infrastructure. Companies like BNY Mellon have successfully modernized critical systems using similar approaches that preserve essential functionality while enhancing performance.

VX/SYS$ supports key OpenVMS system service tasks including device assignment, time conversion, privilege validation, and interprocess communication, ensuring comprehensive compatibility throughout the migration process. To explore how VX/SYS$ can benefit your specific migration requirements, contact our experts.

What is VX/SYS$?

VX/SYS$ is a call-compatible implementation of OpenVMS SYS$ system service calls for x86 and ARM Linux. It lets OpenVMS applications perform system-level operations such as resource allocation, privilege management, process control, and interprocess communication while maintaining execution compatibility on Linux.

How many SYS$ routines does VX/SYS$ provide?

The page lists 151 callable SYS$ routines, spanning device and resource management, process creation and control, privilege checking, memory and virtual-address management, event flags and locks, time and format conversion, and system messaging.

Do I have to change my OpenVMS application code to use VX/SYS$?

In the general case, no. VX/SYS$ is call-compatible with the OpenVMS SYS$ APIs and maintains OpenVMS system behaviour, so applications that rely on SYS$ routines run as expected.

Which hardware platforms does VX/SYS$ run on?

VX/SYS$ runs on x86 and ARM Linux. It integrates with VX/RT to deliver full OpenVMS system-service capabilities on both architectures.

How does VX/SYS$ relate to VX/RT?

VX/SYS$ integrates into the VX/RT ecosystem, which provides the runtime foundation for OpenVMS compatibility on Linux. Together they supply the full set of OpenVMS system services the application expects.

What kinds of system operations are covered?

The routines cover device assignment and resource management (for example SYS$ASSIGN, SYS$ALLOC), process creation and control (SYS$CREPRC, SYS$DELPRC, SYS$SUSPND), privilege checking (SYS$CHECK_PRIVILEGE, SYS$SETPRV), memory and virtual-address management (SYS$CRETVA_64, SYS$CREATE_REGION_64), event flags and locks (SYS$SETEF, SYS$ENQ), time conversion (SYS$ASCTIM, SYS$BINTIM), and system messaging (SYS$BRDCST, SYS$PUTMSG).

Does VX/SYS$ support both synchronous and wait-mode variants of these calls?

Yes. The routine set includes the OpenVMS W wait-synchronized variants alongside their base calls, for example SYS$QIO and SYS$QIOW, SYS$GETJPI and SYS$GETJPIW, and SYS$ENQ and SYS$ENQW, preserving the original synchronization semantics.

Are 64-bit memory and security services included?

Yes. The routine list includes 64-bit variants such as SYS$CREATE_REGION_64, SYS$CRETVA_64, SYS$DELTVA_64, SYS$MGBLSC_64, SYS$UPDSEC_64, and SYS$UPDSEC_64W, so applications using 64-bit address regions and security services carry over.

Transform Your Legacy Software Today!

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