Migrating OpenVMS System Internals: Locks, Transactions & Messaging

• Full compatibility with the OpenVMS DMQ (PAMS) API set
• Implementation on top of Oracle MQ for reliability and scalability
• Enhanced support for Linux, including AST replacement mechanisms
• Optimized for low-latency inter-process communication (IPC)

VX/RTR enables seamless migration of OpenVMS RTRV2 applications to Linux RTRV3 by utilizing the VX/RT Asynchronous Backplane. It provides a transparent compatibility layer that ensures existing applications can run on modern Linux environments without code rewrites.

For a real-world example of successful RTR migration, see our Ford migration case study.

• Full mapping of RTRV2 API calls to RTRV3
• VMS AST handling implementation on Linux
• Transparent compatibility layer for existing applications
• Integration with VX/RT Asynchronous Backplane

VX/RTR integrates seamlessly with VX/RT APIs and the broader VX/RT ecosystem to provide comprehensive OpenVMS compatibility on Linux platforms.

To learn more about VX/RTR and how it can streamline your OpenVMS RTR migration to Linux, contact us for a detailed assessment and migration roadmap.

VX/MSG is a VMS/OpenVMS message file compiler that translates message definitions (.msg) into indexed memory files on Linux, ensuring full compatibility with SYS$ API calls. It enables seamless application migration while preserving original messaging functionality and generates 3GL message constants for multiple programming languages including C, C++, BASIC, Fortran, COBOL, and PASCAL.

This tool simplifies VMS modernization by maintaining message-handling capabilities without requiring code modifications. Contact us to discuss your VMS message migration requirements.

VX/MSG generates message constants for C, C++, Fortran, COBOL, BASIC, and Pascal programming languages.

VX/MSG provides full compatibility with VMS SYS$ API calls including SYS$GETMSG, SYS$FAO, and SYS$FAOL for message retrieval and formatting.

VX/MSG compiles VMS/OpenVMS message files (.msg) into indexed binary files (.dat and .idx), creating an efficient storage and retrieval system that mirrors the VMS SYS$MESSAGE system.

VX/MSG supports message display via VX/DCL, allowing messages to be viewed and retrieved similarly to VMS environments.

VX/MSG creates an indexed file format consisting of .dat and .idx files that contain binary message data along with indexing information for fast retrieval, ensuring efficient message storage and access.

VX/LCKMGR is a fully compatible OpenVMS lock management system designed for Linux environments. It ensures identical functionality to OpenVMS lock management while leveraging Sector7's high-speed AST backplane for enhanced performance.

This solution supports core OpenVMS lock manager functions like SYS$ENQ(W), SYS$DEQ(W), and SYS$GETLKI(), enabling seamless integration with existing OpenVMS applications during migration to Linux. Contact us to discuss your OpenVMS lock manager migration requirements.

VX/LCKMGR supports all major OpenVMS lock modes including Protected Read (LCK$K_PRMODE), Protected Write (LCK$K_PWMODE), Concurrent Read (LCK$K_CRMODE), Concurrent Write (LCK$K_CWMODE), Exclusive (LCK$K_EXMODE), and NULL (LCK$K_NLMODE).

In stress testing, VX/LCKMGR demonstrated exceptional performance by handling 80,000 lock conversions per second on a 1997-era quad-core Opteron server.

VX/LCKMGR supports essential $ENQ/$DEQ codes including LCK$V_VALBLK (Value Block), LCK$V_CONVERT (Convert Lock), LCK$V_NOQUEUE (No Queue), LCK$V_SYNCSTS (Sync Status), LCK$V_SYSTEM (System Lock), and LCK$V_RECOVER (Recovery Mode).

VX/LCKMGR provides comprehensive diagnostic capabilities including real-time lock request logging and replay functionality. The system can log all lock requests and replay them for performance tuning and diagnostic purposes.

Additionally, it offers real-time display of all lock requests, making it easier for system administrators to track lock statuses and manage resources effectively. Companies like Telstra have benefited from similar real-time monitoring capabilities during their OpenVMS migrations.

VX/LCKMGR supports $GETLKI codes for retrieving lock information including LKI$C_LENGTH (Lock Length), LKI$_BLOCKEDBY (Blocked By Lock), LKI$_BLOCKING (Blocking Lock), LKI$_LCKCOUNT (Lock Count), and LKI$_LOCKID (Lock ID).

VX/LCKMGR fully supports OpenVMS lock management functions but is limited to single-node environments. It does not operate across multiple nodes, which is important to consider when planning implementation in distributed systems.

VX/LCKMGR delivers exceptional performance with high-speed lock processing capabilities and comprehensive diagnostic tools. Organizations gain full OpenVMS lock manager compatibility while moving to modern Linux environments.

The system provides advanced logging, real-time monitoring, and replay capabilities that help optimize performance and troubleshoot issues. This enables seamless migration from OpenVMS while maintaining all critical locking functionality.

Financial institutions like BNY Mellon have successfully leveraged similar OpenVMS migration strategies. To explore how VX/LCKMGR can support your specific migration requirements, contact our team for a detailed consultation.

VX/MSG is a reimplementation of the OpenVMS message compiler for Linux. It translates OpenVMS message-definition files (.msg) into an indexed message database, preserving the original OpenVMS message-handling behaviour so migrated applications keep their messaging without a rewrite.

No. VX/MSG preserves the OpenVMS message-code layout, reproduces the SYS$MESSAGE file structure, and keeps the SYS$GETMSG, SYS$FAO, and SYS$FAOL calls compatible, so message handling migrates with minimal changes to application code.

VX/MSG works with the OpenVMS SYS$ message services used for retrieval and formatting, specifically SYS$GETMSG, SYS$FAO, and SYS$FAOL, so code that calls them keeps working after migration.

In its default mode VX/MSG compiles a .msg source into an indexed message database made up of a data file (.dat) and an index file (.idx), stored as SYS$MESSAGE:MESSAGES.SYS, matching the way OpenVMS stores messages.

VX/MSG can generate message-constant sources so application code references messages by name: a C source file (-c), a C header of #define constants (-h), and FORTRAN PARAMETER constants (-f).

VX/MSG runs as a normal build step on Linux. A makefile rule invokes the compiler to turn the .msg definitions into the indexed messages file, and it can generate language constant headers for the application build at the same time.

Yes. Because the database mirrors the OpenVMS SYS$MESSAGE layout, compiled messages can be inspected from VX/DCL (for example TYPE/PAGE SYS$MESSAGE:MESSAGES.SYS), which is useful for verifying a message compile during a migration.

VX/MSG returns well-defined behaviour rather than failing. An unknown message code returns the standard SS$_MSGNOTFND status along with default placeholder text, so applications handle a missing message the same way they did on OpenVMS.

VX/LCKMGR is Sector7's reimplementation of the OpenVMS lock manager for Linux. It provides the SYS$ENQ, SYS$DEQ and SYS$GETLKI system services and the arbitration daemon behind them, so migrated OpenVMS applications keep their existing locking logic and coordinate access to shared resources on modern Linux without a rewrite. Contact our team to review how it fits your estate.

No. Applications call the same SYS$ services with the same arguments and option flags as on OpenVMS. The lock modes, flag encodings and completion behaviour are preserved, so existing code that enqueues, converts and dequeues locks links and runs unchanged.

No. VX/LCKMGR is a single-node lock manager. One daemon on a node owns the resource and lock databases, and client processes reach it over a local message queue. It supports every OpenVMS lock mode on that node but does not perform cluster-wide lock mastering, so applications that depend on cluster coordination should be reviewed during migration planning.

All six OpenVMS lock modes: null (NL), concurrent read (CR), concurrent write (CW), protected read (PR), protected write (PW) and exclusive (EX). The full compatibility matrix and the grant, conversion and wait queue behaviour match the OpenVMS lock manager.

SYS$GETLKI returns detailed lock information through an item list, including the process, lock id, state, resource name, value block, and blocking and waiting relationships. This supports the same troubleshooting, monitoring and diagnostic workflows teams rely on with the OpenVMS lock manager.

The daemon can record every lock request to an audit log and replay it later for tuning and diagnostics, and it reports live statistics on request volumes and queue activity through the lckctl utility. Because replay reconstructs the request stream directly, bottlenecks can be investigated without re-running the original application.

The current build does not run a deadlock search. Applications that rely on the OpenVMS lock manager signalling a deadlock should be reviewed during migration, and where deadlock avoidance matters we recommend designing consistent lock ordering into the application. Our team can advise on the right approach for your workload.

VX/LCKMGR runs on Linux and supports up to 80,000 concurrent lock ids per daemon, with 16-byte and 64-byte lock value blocks and resource domains so unrelated applications can share one daemon safely. It is delivered as part of Sector7's OpenVMS to Linux migration toolset.