VX/DECFORMS – DECforms IFDL Compiler and FORMS$

Compilation pipeline

The build flow runs offline, once per form, and produces C++ that is compiled and linked into the application alongside the Form Driver:

The generated .cpp defines one extern "C" void Form__<NAME>() entry point that preserves the original IFDL identifiers in the generated symbol names, so the form keeps its name and structure across the migration.

Command-line flags

Generated C++

The generator emits an include of vxFormsDef.hpp, forward declarations for every response, group, icon, and field, and a single Form__<NAME>() entry that initialises the library and calls the forms_* builders:

#include "vxFormsDef.hpp"

static void FunctionResponse__KEY_F10__8();
static void Group__ACCOUNT_LIST__1();
...
    forms_Dispatch(__FIELD_DEFAULT, __PROTECTED, ...);
    forms_GroupDisplayAttributes(__VERTICAL_SPEC, __DISPLAYS, 5, __SCROLL_BY_PAGE, ...);
    forms_DeclareFunctionResponse(...);
    forms_PictureFieldDeclaration("BALANCE", ...);
    forms_Literal(__TEXT, ...);
    forms_EndGroup();

extern "C" void Form__ACCOUNT_INQUIRY()
{
    forms_LibraryInitializer((void **)&FDp, sizeof (*FDp), main_map_table);
    ...
}

Top-level declarations

Response steps

IFDL example

A teller sign-on form for a banking application: a Form Data block, a Form Record, a Layout with a viewport, a key-bound function, a named attribute, and a Transceive Response. Keywords are case-insensitive, and %VT100, %CARRIAGE_RETURN, and %Bell are implementor keys.

Form TELLER_SIGNON

    Form Data
        PROGRAM_TITLE     Character(40)
        PROGRAM_DATE      Character(14)
        TELLER_ID         Character(12) Value " "
        BRANCH_MSG_FLAG   Character(1)  Value " "
        BRANCH_MSG_LINE   Character(80) Value " "
        SIGNON_ATTEMPTS   Signed longword
    End Data

    Form Record TELLER_SIGNON_REC
        SIGNON_ACTION_FLAG Character(5)
        TELLER_ID          Character(12)
        SIGNON_ATTEMPTS    Signed longword
    End Record

    Layout TELLER_SIGNON
        Device Terminal Type %VT100 End Device
        Size 24 Lines by 80 Columns

        Viewport Message_Viewport
            Lines 24 Through 24
            Columns 1 Through 80
        End Viewport

        Function Select_Item
            Is %CARRIAGE_RETURN %KP_ENTER %SELECT
        End Function

        Attribute Prompt_Attr
            Is NoBlinking NoBold Reverse NoUnderlined
        End Attribute

        Transceive Response TELLER_SIGNON_REC TELLER_SIGNON_REC
            Let PROGRAM_TITLE = "        Teller Sign-On"
            Let PROGRAM_DATE  = SCREEN_DATE
            Display Heading_Panel On Heading_Viewport
            Display Signon_Panel  On Main_Viewport
            If BRANCH_MSG_FLAG <> " "
                Then Message BRANCH_MSG_LINE
                     Signal %Bell
                     Let BRANCH_MSG_FLAG = " "
                Else Message " "
            End If
        End Response

Field data types

Selected IFDL keywords

The lexer recognises 286 single-word keywords in total, plus multi-word and implementor-key tokens.

Callable services

Arguments are passed as VMS-style string descriptors, which the runtime adapts and converts to C strings internally. Because the signatures and descriptor conventions match the OpenVMS DECforms Form Driver, the application code that calls them does not change.

FORMS$ENABLE option keys

The forms_ builder library

The generated C++ targets a runtime library of builder and dispatch functions declared in vxFormsDef.hpp. Representative entry points:

S32  forms_DeclareForm ( __CallBack, const char *szFormName );
S32  forms_DeclareField( __CallBack, const char *szFieldName );
S32  forms_Dispatch    ( U32 Parameter, ... );   // variadic, keyed on __VERB
S32  forms_Display     ( U32 Parameter, ... );

Attribute and option keywords become implementor-key constants (for example __FIELD_DEFAULT, __PROTECTED, __DISPLAYS, __SCROLL_BY_PAGE) passed to forms_Dispatch and forms_GroupDisplayAttributes.

User escapes (PUEs and UARs)

User Escapes, also called PUEs, are custom routines written in any DEC-supported programming language and linked directly into the compiled form. The Form Driver calls them automatically in several scenarios: after field processing, before and after help requests, when function keys are pressed, and during screen refresh. In VX/DECFORMS these behave identically to those in the original OpenVMS DECforms, with the added flexibility that the IFDL compiler produces maintainable C++ into which external routines link directly, through forms_CallPEU().

Terminal support

The Form Driver is compatible with all VT terminals from VT100 upward, including DECterm under DECwindows, and can be extended for non-VTxxx terminals as needed. Its built-in C-based terminal drivers provide portability across Linux and Windows without relying on curses, termcap, or external terminal configuration files.

Display attributes

VX/DECFORMS reproduces the display capabilities of the DEC VT family:

• Character attributes: reverse video, bold, blinking, and underlined text.
• Line attributes: double-width and double-height characters, and scrolled lines.
• Screen-width attributes: both 80-column and 132-column modes, plus reverse video.
• Alternative character sets: full support for VT100 special graphics and line-drawing characters.

Form Driver capabilities

The Form Driver is the runtime component responsible for terminal input and output, displaying forms, managing screen manipulation, and performing basic input validation. It supports both field-based and full-form input and output, allowing values to be specified one field at a time or across the whole form, and eliminates the need for external terminal configuration files.

No application code changes

The migration process does not require changes to application programs. Once the form descriptions are recompiled, the application automatically uses the new forms through the runtime system. The existing FORMS$ calls link and run unchanged, and the Form Driver reproduces the original screen behaviour, so users cannot distinguish a migrated screen from the original OpenVMS DECforms.

Supported application languages

The VX/DECFORMS utilities support applications written in multiple programming languages and provide the procedures needed to adapt VMS descriptors for each. Callable from:

Integration with VX/RT

For applications that require full integration with VMS semantics, VX/DECFORMS works together with VX/RT, Sector7's runtime support libraries for Linux, which supply the VMS descriptor handling and system-service compatibility the Form Driver builds on. Migrated forms can also be presented in modern HTML5 browsers alongside VT-terminal output, broadening access to the legacy applications.

Compatibility status

Related tools

VX/DECFORMS is the base DECforms product. The FORMS$ callable API it provides is documented on the FORMS$ integration page, and TDMS-compatibility response steps are added by the separate VX/DECFORMS+ extension. Related forms and screen-management tools in the same space include VX/TDMS, VX/FMS, and VX/SMG.

Compile a form

vxforms --output=form.cpp form.ifdl          # IFDL to C++
vxforms --main --compile form.ifdl           # emit Form__Main, compile via vxforms.sh
vxforms --cvt-cdolst-ifdl=CDO.LST,out_dir     # CDD/CDO listing to IFDL
c++ -std=c++11 -c form.cpp # then link with libvxdf

Runtime call skeleton

FORMS$ENABLE(&FormPtr, &Device, &Session, &FormFile, &FormName, ..., &Options);
FORMS$TRANSCEIVE(&Session, &SendRec, &SendCnt, &RecvRec, &RecvCnt, ...);
FORMS$DISABLE(&Session, &RcvCtl, ...);

IFDL skeleton

Form <NAME>
    Form Data ... End Data
    Form Record <REC> ... End Record
    Layout <NAME>
        Device Terminal Type %VT100 End Device
        Size 24 Lines by 80 Columns
        Viewport ... End Viewport
        Function ... Is %KEY End Function
        Attribute ... Is NoBlinking Bold ... End Attribute
        <kind> Response ... End Response

FORMS$ services

Response types