VX/DECFORMS+ – TDMS Compatibility Extensions

VX/DECFORMS+ is the TDMS compatibility layer for Sector7's VX/DECFORMS product. It extends the IFDL language and runtime so applications originally written for OpenVMS TDMS (Terminal Data Management System) can be migrated into the DECforms world without rewriting request logic that sets field display attributes at runtime.

Standard DECforms treats reverse video, blinking, bold, and underline as declaration-time display properties. TDMS request logic frequently asserted or cleared those attributes during a request instead. VX/DECFORMS+ closes that gap with new IFDL response steps, a layout-level compatibility mode, and diagnostic counters so unsupported behaviour is always counted and logged rather than silently dropped.

Architecture and pipeline

VX/DECFORMS+ sits on top of the base VX/DECFORMS compiler and libvxdf runtime. Form authors continue to write IFDL source; the extensions add new response steps to the IFDL grammar and route them through a single runtime entry point at execution time.

Stage	VMS / DECforms original	VX/DECFORMS+ on Linux	Role
Form source	`.ifdl` IFDL text	Same `.ifdl` text, now allowing `TDMS …` and `CHARACTER SET` response steps	Author or port the form
Compile	DECforms `FORMS` compiler	VX/DECFORMS compiler emits generated C that calls the `forms_*` runtime	Lower IFDL to runtime calls
Generated call	Attributes were declaration-time only	`forms_TDMSCompatibility(op, "field", "panel");` and `forms_Dispatch(__CHARACTER_SET, …);`	Runtime entry points
Runtime	DECforms shareable image	`libvxdf` resolves field to panel, sets flags, redisplays	Apply the attribute

The new response steps are legal anywhere an existing response step (for example Display, Message, Reset, or Signal) is legal: inside any Response … End Response block.

Three extensions. VX/DECFORMS+ adds TDMS field-attribute response steps, a CHARACTER SET response step, and a layout-level TDMS compatibility mode controlled by configuration or the forms_TDMSCompatibility() API.

TDMS field-attribute response steps

The core VX/DECFORMS+ extension lets migrated TDMS request logic set or clear display attributes on a named field of a named panel at response time, the way a TDMS request would have done on OpenVMS.

Syntax

TDMS [ NO ] REVERSE    FIELD field-name ON panel-name
TDMS [ NO ] BLINKING   FIELD field-name ON panel-name
TDMS [ NO ] BOLD       FIELD field-name ON panel-name
TDMS [ NO ] UNDERLINED FIELD field-name ON panel-name

field-name is a field defined on the current form; panel-name is a panel in the current layout on which that field is displayed. The NO variant clears the attribute; the bare form asserts it. All four attributes and both variants are recognised by the compiler and implemented in the runtime.

Example

A migrated TDMS request that reverse-videos an invalid account-type field and clears the highlight once it validates, expressed as VX/DECFORMS+ IFDL:

Internal Response FLAG_ACCT_TYPE_ERROR
    TDMS Reverse Field ACCT_TYPE On Account_Type_Panel
    Message "Invalid account type. Correct and re-enter."
End Response

Internal Response CLEAR_ACCT_TYPE_ERROR
    TDMS No Reverse Field ACCT_TYPE On Account_Type_Panel
End Response

Keywords are case-insensitive. Response block structure and step ordering match the surrounding IFDL exactly as in existing migrated forms.

Compiler lowering

The compiler lowers every TDMS step to a single call:

forms_TDMSCompatibility(<op-constant>, "<field-name>", "<panel-name>");

IFDL response step	Op constant	Effect
`TDMS REVERSE FIELD f ON p`	`forms_tdmscompat_k_reverse_field` (6)	Assert reverse video
`TDMS NO REVERSE FIELD f ON p`	`forms_tdmscompat_k_no_reverse_field` (7)	Clear reverse video
`TDMS BLINKING FIELD f ON p`	`forms_tdmscompat_k_blink_field` (8)	Assert blinking
`TDMS NO BLINKING FIELD f ON p`	`forms_tdmscompat_k_no_blink_field` (9)	Clear blinking
`TDMS BOLD FIELD f ON p`	`forms_tdmscompat_k_bold_field` (10)	Assert bold
`TDMS NO BOLD FIELD f ON p`	`forms_tdmscompat_k_no_bold_field` (11)	Clear bold
`TDMS UNDERLINED FIELD f ON p`	`forms_tdmscompat_k_underline_field` (12)	Assert underline
`TDMS NO UNDERLINED FIELD f ON p`	`forms_tdmscompat_k_no_underline_field` (13)	Clear underline

Runtime behaviour

forms_TDMSCompatibility() for a field-attribute operation performs a full end-to-end update:

Requires an active layout and active form (otherwise returns vxdf_s_abort with a diagnostic).
Requires non-empty field and panel names (otherwise vxdf_s_badparam).
Looks the panel up in the layout; an undefined panel is a counted error.
Resolves the field on the form; an undefined field is a counted error.
Finds the field's block-list entry on that panel; if the field is not displayed on that panel it is a counted error.
Sets or clears the corresponding display flag on the block-list entry.
Redisplays the field on the panel.
On success, increments the layout's iTDMSCompatLowered counter and logs the action.

Every failure path increments both iTDMSCompatUnsupported and iTDMSCompatWarnings and emits an error message naming the field, panel, and action. Nothing is silently skipped.

CHARACTER SET response step

DECforms defines CHARACTER SET character-set-name as a display and text attribute. VX/DECFORMS additionally accepts it as a response step, applying it to the current field or current panel block-list at response time.

CHARACTER SET character-set-name

The compiler lowers this step to:

forms_Dispatch(__CHARACTER_SET, __<character-set-name>, __End);

character-set-name uses the same DECforms character-set vocabulary the compiler already validates for the declaration-time attribute (for example PRIVATE_USER_PREFERENCE or PRIVATE_RULE). The runtime handles __CHARACTER_SET through the existing dispatch path; the extension is that it may now appear as a response step inside a Response block.

Layout-level TDMS compatibility mode

Beyond the per-field response steps, a whole layout can run in TDMS compatibility mode. This mode is enabled at layout declaration time or toggled at runtime, and pairs with per-layout diagnostic counters so migration engineers can see exactly how much TDMS behaviour a form exercised.

Enabling via configuration

At forms_DeclareLayout() time the runtime checks the config item VXDFTDMSCOMPAT. Because the name is VXDF-prefixed, it is read from the process environment or from the vxForms.conf config file. The search order is $VXFORMCONFIG, then ${HOME}/./vxForms.conf, then ${VXREL}/syslib/, ${VXREL}/lib64/, and /opt/vxrt/syslib/.

When set, the layout's TDMS compatibility flag is turned on, the aggressive compatibility flag is applied, and the runtime logs that TDMS compatibility mode is enabled for the layout.

# environment
export VXDFTDMSCOMPAT=1

# or in vxForms.conf (first file found on the config search path)
VXDFTDMSCOMPAT 1

Boolean config.VXDFTDMSCOMPAT is read as a boolean config item: present or true enables compatibility mode for the layout.

Controlling at runtime

forms_TDMSCompatibility() also accepts mode-control operations that take no field or panel arguments:

Op constant (value)	Effect
`forms_tdmscompat_k_query` (0)	Returns `vxdf_s_success` if compat mode is on, else `vxdf_s_notfound`
`forms_tdmscompat_k_enable` (1)	Turns compat mode on for the active layout
`forms_tdmscompat_k_disable` (2)	Turns compat mode off and clears compatibility flags
`forms_tdmscompat_k_aggressive` (3)	Turns compat on and sets the aggressive flag
`forms_tdmscompat_k_supported` (4)	Records a supported diagnostic; increments `iTDMSCompatLowered`
`forms_tdmscompat_k_unsupported` (5)	Records an unsupported diagnostic; increments `iTDMSCompatUnsupported` and `iTDMSCompatWarnings`

Diagnostic operations (4 and 5) take two string arguments: a feature name and a detail string.

Per-layout diagnostic counters

Each layout carries four counters so operators and migration engineers can audit TDMS compatibility usage:

Counter	Meaning
`iTDMSCompatFlags`	Active compatibility flag bits (including aggressive mode)
`iTDMSCompatLowered`	TDMS compatibility operations successfully applied
`iTDMSCompatWarnings`	Warnings emitted (parallels every unsupported operation)
`iTDMSCompatUnsupported`	Operations refused (bad parameters, missing field or panel, display failure)

This is the "never silently skip" contract in practice: an unsupported or unresolved TDMS operation is always counted and logged, never dropped.

The `forms_TDMSCompatibility` API

Generated application code and any hand-written integration call one exported runtime function:

S32  forms_TDMSCompatibility( U32 Parameter, ... );

Parameter is one of the forms_TDMSCompatibility_t operation constants (values 0 through 13). The varargs depend on the operation class:

Mode operations (0 through 3): no additional arguments.
Diagnostic operations (4 and 5):const char *feature, const char *detail.
Field operations (6 through 13):const char *field-name, const char *panel-name.

Return values

Status	When returned
`vxdf_s_success`	Operation completed successfully
`vxdf_s_notfound`	Query when compatibility mode is disabled
`vxdf_s_badparam`	Bad or missing arguments, undefined field or panel, field not on panel, or unsupported diagnostic
`vxdf_s_abort`	No active layout or form

Operation summary

forms_TDMSCompatibility(Parameter, ...);
//  Parameter 0  query
//            1  enable
//            2  disable
//            3  aggressive
//            4  supported(feature, detail)
//            5  unsupported(feature, detail)
//            6/7   [no] reverse field(field, panel)
//            8/9   [no] blinking field(field, panel)
//           10/11  [no] bold field(field, panel)
//           12/13  [no] underlined field(field, panel)

Divergences from TDMS and DECforms

VX/DECFORMS+ deliberately extends standard DECforms behaviour where TDMS migrations require it. The table below summarises the main differences and the reason for each.

Behaviour	Divergence	Reason
Display attributes as response steps	DECforms sets these as declaration-time attributes only	TDMS set them at request/runtime; the extension preserves that timing so ported request logic works unchanged
Field must be displayed on the named panel	The runtime edits the panel's block-list entry and redisplays; a field not on that panel has no entry to edit	Counted error rather than a silent no-op, so migration diagnostics stay honest
Unsupported operations are counted and logged, then rejected	TDMS would simply apply the attribute	Migration diagnostics: an operator or engineer must be able to see what did not carry over
`CHARACTER SET` as a response step	DECforms allows it only as a display attribute	VX/DECFORMS convenience extension for TDMS-style runtime attribute changes

Scope note. VX/DECFORMS+ implements TDMS field display-attribute response steps and layout compatibility mode. Automated import of TDMS request-block (.RLB) definitions into IFDL is a separate concern and is not covered by these extensions.

Feature status

Feature	Status
`TDMS [NO] REVERSE FIELD … ON …`	live
`TDMS [NO] BLINKING FIELD … ON …`	live
`TDMS [NO] BOLD FIELD … ON …`	live
`TDMS [NO] UNDERLINED FIELD … ON …`	live
`CHARACTER SET` response step	live
`VXDFTDMSCOMPAT` layout compat mode (environment / `vxForms.conf`)	live
Runtime enable / disable / aggressive / query operations	live
Supported / unsupported diagnostic operations and counters	live
TDMS request-block import / translation	out of scope for VX/DECFORMS+
Additional TDMS video attributes beyond reverse, blink, bold, underline	not in current grammar

Quick reference

IFDL response steps added

TDMS [ NO ] REVERSE    FIELD field ON panel
TDMS [ NO ] BLINKING   FIELD field ON panel
TDMS [ NO ] BOLD       FIELD field ON panel
TDMS [ NO ] UNDERLINED FIELD field ON panel
CHARACTER SET character-set-name

New and reused keywords

TDMS

REVERSE

BLINKING

BOLD

UNDERLINED

FIELD

CHARACTER SET

Keywords are case-insensitive. TDMS is new; the attribute and structure keywords reuse existing DECforms IFDL vocabulary.

Runtime entry point

S32 forms_TDMSCompatibility(U32 Parameter, ...);

Enable compatibility mode

VXDFTDMSCOMPAT

vxForms.conf

$VXFORMCONFIG

forms_tdmscompat_k_enable

forms_tdmscompat_k_aggressive

Diagnostic counters (per layout)

iTDMSCompatLowered

iTDMSCompatWarnings

iTDMSCompatUnsupported

iTDMSCompatFlags

On this page

Architecture and pipeline

TDMS field-attribute response steps

CHARACTER SET response step

Layout-level TDMS compatibility mode

Enabling via configuration

Controlling at runtime

Per-layout diagnostic counters

The forms_TDMSCompatibility API

Return values

Operation summary

Divergences from TDMS and DECforms

Feature status

Quick reference

IFDL response steps added

New and reused keywords

Runtime entry point

Enable compatibility mode

Diagnostic counters (per layout)

Frequently Asked Questions

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

Free Code Assessment

What is VX/DECFORMS and how does it help migrate DECforms?

VX/DECFORMS is Sector7's reimplementation of OpenVMS DECforms for Linux and Windows. It compiles your existing IFDL form definitions to C++ and provides the FORMS$ Form Driver runtime, so DECforms applications keep running with the same screens and behaviour after migrating off OpenVMS.

Does VX/DECFORMS require rewriting our application code?

No. The migration process does not require changes to application programs. Existing FORMS$ calls link and run unchanged, and once the form descriptions are recompiled the application automatically uses the new forms through the runtime system.

What is FORMS$ and does VX/DECFORMS keep that API?

FORMS$ is the DECforms Form Driver callable interface. VX/DECFORMS provides a library of FORMS$ APIs that mirror the original DECforms API, including ENABLE, DISABLE, SEND, RECEIVE, TRANSCEIVE, and CANCEL, so it stays compatible with the way OpenVMS applications call DECforms.

Are there any DECforms features VX/DECFORMS does not support?

It supports nearly all DECforms syntax. The one current limitation is right-to-left text formatting, which is not supported at this time. Everything else in the original feature set is preserved.

Which terminals does VX/DECFORMS support?

It supports all VT terminals from VT100 upward, including DECterm under DECwindows, and can be extended for non-VTxxx terminals. Its built-in C-based terminal drivers work across Linux and Windows without curses, termcap, or external terminal configuration files.

Related Boot Camp talk

Talk · 29 October 2026
VSI OpenVMS Boot Camp, Portsmouth 2026
Using AI to port, develop, debug and test VMS applicationsVSI OpenVMS Boot Camp, Portsmouth 2026 · 29 October 2026View the talk

Transform Your Legacy Software Today!

Get In Touch

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