Slide 2
MaTriX – Mask Trans­for­ma­tion Toolbox

MaTriX is our tool for the moder­ni­sa­tion of proprie­tary, antiqua­ted user inter­faces which, for example, are based on IFG, SCREEN COBOL or CICS. MaTriX automa­ti­cally replaces these masks by contem­po­rary, standar­di­sed techno­lo­gies. There­fore we use modern web technologies.


Even today mainframe masks still have the charm of the 1970s and 1980s:

  • The mask window is often limited to 80 x 25 characters.
  • Function keys play an important role in naviga­ting forward and backward and alter­na­ti­ves are selec­ted by the ticking input fields.
  • Entries cannot be checked until after sending the mask, reaction during an entry is not possible.
  • Modern GUI design features such as menus, links, combo boxes etc. do not exist.
  • Where appro­priate, the size of the message that is used for the data trans­fer between proprie­tary mask system and online programs is limited to a certain (small) number of characters.

Using MaTriX, mainframe masks can be repla­ced by contem­po­rary, standar­di­sed web technologies.

Beispiel für eine Mainframe-Maske

Example of a mainframe mask


MaTriX stands out for the follo­wing features:

Use of modern web technologies
MaTriX uses modern techno­lo­gies such as HTML5, Ajax and common JavaScript frame­works when develo­ping Web 2.0‑based interfaces.

The client display is browser-based
No software has to be instal­led on the clients, which contri­bu­tes signi­fi­cantly to cost savings. This also supports a large number of possi­ble client architectures.

Integra­ted WYSIWYG mask editor 
The mask editor designed as a web appli­ca­tion enables the conve­ni­ent develo­p­ment of inter­faces accor­ding to the WYSIWYG princi­ple and offers exten­sive design elements.

Automa­ted migration of mainframe masks
If the mask descrip­ti­ons are available in a form in an automa­ti­cally processa­ble form, these can be trans­fer­red automa­ti­cally to the new technology using the mask migration tool integra­ted into MaTriX.


Migration of screen masks of the legacy system with MaTriX is carried out largely automa­ti­cally which, in general, signi­fi­cantly reduces project costs and duration as against a manual conver­sion. On the one hand, the origi­nal mask descrip­ti­ons (e.g. IFG, SCREEN COBOL) are the start­ing point here, but on the other hand, it is the COBOL message struc­tures that define the inter­face between the server programs created in COBOL and the masks. The precon­di­tion for this is that the mask descrip­ti­ons are available in a reada­ble, meaning automa­ti­cally proces­si­ble form.

The mask migration tool (MMT) converts the mask despric­tions and saves them for future proces­sing in XML format.

During conver­sion, the masks are not imple­men­ted 1:1. Several modifications/optimisations are carried out such as:

  • Custo­­mer-speci­­fic CI is conside­red. The layout is stored in CSS files and “pulled on” straigh­ta­way during the migration of masks.
  • Fixed positio­ning is trans­fer­red to a grid layout.
  • Table struc­tures in the origi­nal which, for example, are based on data fields with OCCURS clause in COBOL are trans­fer­red to speci­fic data tables with sorting/filter and scroll option.
  • Elements with certain value ranges are equip­ped with speci­fic patterns which indicate wrong entries to the user already during runtime.

Subse­quent works at the masks will be carried out using the MaTriX mask editor.

Before-after example 1: Mask “User Overview”

Vorher-Nachher-Beispiel 1: Maske “Nutzerübersicht”

Before-after example 2: Mask “User Management”


For editing the moder­nised screen masks, the MaTriX mask editor is used. This works on the WYSIWYG princi­ple which means that there is no need to learn a mask descrip­tion language. Analog­ous to known graphi­cal HTML editors, the user is allowed to create and process the masks via mouse inter­ac­tion, menus and toolbars. In doing so, a wide range of design elements is supported:

  • Text display elements with and without links to the message that defines the inter­face between server programs and the masks
  • Text input elements with links to the message (optio­nal with given patterns to limit possi­ble user inputs)
  • Buttons, radio buttons, check­bo­xes, select boxes, combo boxes, field sets with message link
  • Calen­dar (for date input)
  • Images in various graphic formats
  • Links that can be deposi­ted with JavaScript actions
  • Grids for the positio­ning design elements
  • Speci­fic tables for the display of message data with exten­sive confi­gu­ra­tion options. These tables allow, amongst other things: 
    • Sorting of data
    • Searching within the data (filte­ring of data)
    • Defining the currently visible data area by activat­ing a scroll function or scroll bar.

Various attri­bu­tes of indivi­dual elements (colours, fonts, etc.) open up a wide range of design features. Instead of fixed X/Y coordi­na­tes, a flexi­ble grid layout is used for the positio­ning the elements.

The MaTriX mask editor
Confi­gu­ra­tion of the mask elements by speci­fic dialogues
Linking of the display and input elements with message data fields
Overview of mask elements
Format­ting of the mask elements accor­ding to CI requirements
previous arrow
next arrow
The MaTriX mask editor
Configuration of the mask elements by specific dialogues
Linking of the display and input elements with message data fields
Overview of mask elements
Formatting of the mask elements according to CI requirements
previous arrow
next arrow


MaTriX consists of diffe­rent compon­ents whose inter­ac­tion is shown in the follo­wing graphic:


MaTriX – data sheet

Success Story: “Successful Migration Project “Moder­ni­sa­tion of User Inter­faces at MAN Truck & Bus SE

“Oberflä­chen­mo­der­ni­sie­rung mit MaTriX”
Abstract for 14th “Workshop Software-Reengi­nee­ring” 2–4 May 2012 in Bad Honnef, published in:
Software­tech­nik-Trends, volume 32, part 2, May 2012