MaTriX is our tool for the modernisation of proprietary, antiquated user interfaces which, for example, are based on IFG, SCREEN COBOL or CICS. MaTriX automatically replaces these masks by contemporary, standardised technologies. Therefore we use modern web technologies.
MOTIVATION
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 navigating forward and backward and alternatives are selected 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 appropriate, the size of the message that is used for the data transfer between proprietary mask system and online programs is limited to a certain (small) number of characters.
Using MaTriX, mainframe masks can be replaced by contemporary, standardised web technologies.
FEATURES
MaTriX stands out for the following features:
MaTriX uses modern technologies such as HTML5, Ajax and common JavaScript frameworks when developing Web 2.0‑based interfaces.
No software has to be installed on the clients, which contributes significantly to cost savings. This also supports a large number of possible client architectures.
The mask editor designed as a web application enables the convenient development of interfaces according to the WYSIWYG principle and offers extensive design elements.
If the mask descriptions are available in a form in an automatically processable form, these can be transferred automatically to the new technology using the mask migration tool integrated into MaTriX.
AUTOMATED MASK MODERNISATION
Migration of screen masks of the legacy system with MaTriX is carried out largely automatically which, in general, significantly reduces project costs and duration as against a manual conversion. On the one hand, the original mask descriptions (e.g. IFG, SCREEN COBOL) are the starting point here, but on the other hand, it is the COBOL message structures that define the interface between the server programs created in COBOL and the masks. The precondition for this is that the mask descriptions are available in a readable, meaning automatically processible form.
The mask migration tool (MMT) converts the mask desprictions and saves them for future processing in XML format.
During conversion, the masks are not implemented 1:1. Several modifications/optimisations are carried out such as:
- Customer-specific CI is considered. The layout is stored in CSS files and “pulled on” straightaway during the migration of masks.
- Fixed positioning is transferred to a grid layout.
- Table structures in the original which, for example, are based on data fields with OCCURS clause in COBOL are transferred to specific data tables with sorting/filter and scroll option.
- Elements with certain value ranges are equipped with specific patterns which indicate wrong entries to the user already during runtime.
Subsequent works at the masks will be carried out using the MaTriX mask editor.
MASK DESIGN
For editing the modernised 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 description language. Analogous to known graphical HTML editors, the user is allowed to create and process the masks via mouse interaction, 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 interface between server programs and the masks
- Text input elements with links to the message (optional with given patterns to limit possible user inputs)
- Buttons, radio buttons, checkboxes, select boxes, combo boxes, field sets with message link
- Calendar (for date input)
- Images in various graphic formats
- Links that can be deposited with JavaScript actions
- Grids for the positioning design elements
- Specific tables for the display of message data with extensive configuration options. These tables allow, amongst other things:
- Sorting of data
- Searching within the data (filtering of data)
- Defining the currently visible data area by activating a scroll function or scroll bar.
Various attributes of individual elements (colours, fonts, etc.) open up a wide range of design features. Instead of fixed X/Y coordinates, a flexible grid layout is used for the positioning the elements.
Message structures define the interface between server programs and masks in the legacy system. During migration, these message structures are separated from the COBOL programs. The message compiler analyses these messages existing in source code and stores the information gained thus (field name, field type, nesting of fields, …) in structured form (message information).
The mask editor is intended for the creation of new screen masks and for the visual and functional revision of converted screen masks. These are stored in XML format.
The mask compiler translates these XML files into JavaScript (mask files). In doing so, it also refers to the stored message information to convert the symbolic message field names into offset and length of the field in the message.
The mask migration tool (MMT) converts the mask descriptions and message structures (COBOL) and saves these mask information for further processing in XML format.
The mask server establishes the connection between web browser and web service during runtime. It makes the generated mask files as well as other fixed resources (images, CSS files, fixed JavaScript libraries, HTML files, …) available to the client. It can receive messages from the browser, forward them to the web service, receive the answer and send these back to the browser.
Success Story: “Successful Migration Project “Modernisation of User Interfaces at MAN Truck & Bus SE”
“Oberflächenmodernisierung mit MaTriX”
Abstract for 14th “Workshop Software-Reengineering” 2–4 May 2012 in Bad Honnef, published in:
Softwaretechnik-Trends, volume 32, part 2, May 2012