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 repla­ces these masks by contem­porary, standar­di­sed techno­lo­gies. There­fore we use modern web technologies.

MOTIVA­TION

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­porary, standar­di­sed web technologies.

Beispiel für eine Mainframe-Maske

Example of a mainframe mask

FEATURES

MaTriX stands out for the following features:

  • MaTriX uses modern web technologies.
    Modern techno­lo­gies such as HTML5, Ajax and common JavaScript frame­works are used to develop Web 2.0‑based interfaces.
  • The client display is browser-based.
    In this way, no software needs to be instal­led on the clients which is a major contri­bu­ting factor for saving costs. In addition, a large number of possi­ble client archi­tec­tures (PC with Windows or Linux, Mac, Android systems, …) are suppor­ted by this.
  • MaTriX inclu­des a WYSIWYG mask editor.
    Using this, new inter­faces are intui­tively and comfor­ta­bly develo­ped accord­ing to the WYSIWYG principle. Exten­sive elements are provi­ded for designing the masks. The editor is designed as a web appli­ca­tion, local instal­la­tion on the client is there­fore not required.
  • MaTriX allows automa­ted migration of mainframe masks.
    If mask descrip­ti­ons are avail­able in an automa­ti­cally process­able form, these can be trans­fer­red automa­ti­cally to the new techno­logy using the mask migration tool integra­ted into MaTriX.

AUTOMA­TED MASK MODERNISATION

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 starting 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 avail­able 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 consi­de­red. The layout is stored in CSS files and “pulled on” strai­gh­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”

MASK DESIGN

For editing the moder­nised screen masks, the MaTriX mask editor is used. This works on the WYSIWYG principle which means that there is no need to learn a mask descrip­tion language. Analo­gous 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 accord­ing 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 TECHNO­LOGY

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

Message struc­tures define the inter­face between server programs and masks in the legacy system. During migration, these message struc­tures are separa­ted from the COBOL programs. The message compi­ler analy­ses these messages existing in source code and stores the infor­ma­tion gained thus (field name, field type, nesting of fields, …) in struc­tu­red form (message information).

The mask editor is inten­ded for the creation of new screen masks and for the visual and functio­nal revision of conver­ted screen masks. These are stored in XML format.

The mask compi­ler trans­la­tes these XML files into JavaScript (mask files). In doing so, it also refers to the stored message infor­ma­tion to convert the symbo­lic message field names into offset and length of the field in the message.

The mask migration tool (MMT) converts the mask descrip­ti­ons and message struc­tures (COBOL) and saves these mask infor­ma­tion for further proces­sing in XML format.

The mask server estab­lis­hes the connec­tion between web browser and web service during runtime. It makes the genera­ted mask files as well as other fixed resour­ces (images, CSS files, fixed JavaScript libra­ries, HTML files, …) avail­able to the client. It can receive messages from the browser, forward them to the web server, receive the answer and send these back to the browser.

DOWNLOADS

MaTriX – data sheet

Success Story: “Success­ful 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, publis­hed in:
Software­tech­nik-Trends, volume 32, part 2, May 2012

GO TO DOWNLOAD AREA