Project Facelift is the 3rd iteration of our modernization technology for Green Screens 5250 Web terminal. First public release preview version is planned for February / March 2024.
What this technology makes different compared to other, and what are our thoughts about the approach we choose for this technology, can be found below.
So, why the Project Facelift is different?
There are two edges of a rainbow.
At one side there are products for "screen scrapping" converting 5250 terminal screens into UI. The easiest technology to learn and use, but also the most limited. In many cases, require specifically designed DDS to support such tools.
At the other side of the rainbow are powerful tools also with their own shortcomings such as learning path, price, DDS source requirement, requirement to recompile and literally use additional programming. Some of the products allows you to migrate 5250 DSP programs into service programs. They are often combined with some 3rdparty web UI tools (which are often close sourced, and some of them are abandoned or resource heavy, or taken by other companies and developed in other direction leaving you without proper support)
In either case, those technologies are vendor lock-in.
The Project Facelift sits right in the middle.
- Gives a lot of flexibility while in the same time
- does not require DDS source or creating / compiling replacement DDS,
- neither it is vendor lock-in (even being an integral part of Green Screens Server).
- It is based on Bootstrap CSS and browser natively supported WebComponents
- ...and finally, it will be fully open sourced under free MIT license
How does it work - bird's eye view ?
There are several layers used by Facelift Engine for 5250 modernization
- Automatic template generation from DSPF
- Display file and record usage detection on a live 5250 terminal
- Within the browser - Web GUI pre-procesing (non-GUI)
- Within the browser - Web GUI rendering
Our Facelift Engine has the ability to read and parse DSPF (a binary compiled screen DDS) and extract all the required data such as fields, constants, subfiles and window information. Including information about DDS records and even on/off flags.
This data is then used to generate XML document for each of DDS record structure. Even being an XML, such XML tags are also registered within the browser as a browser native WebComponents (no any plugin or desktop installation required).
From this....
A*..1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
A R SFLDATA SFL
A NAME 20A B 4 5
A RANK 10A B 4 27
A SERIAL 8A B 4 38
A
A*..1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
A R WINDOW1 SFLCTL(SFLDATA)
A WINDOW(8 25 10 50)
A WDWBORDER((*COLOR YLW) +
A (*DSPATR RI) +
A (*CHAR '+-+||+-+'))
A SFLPAG(4)
A SFLSIZ(17)
A SFLDSP
A SFLDSPCTL
A 2 5'Full Name'
A 2 27'Rank'
A 2 38'Serial Nbr'
A
A
A
A*..1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
A R SFLRCD SFL
A CTLFLD 1Y 0H SFLCHCCTL
A F1 4A O 6 10..into this
<dds-display lib="DEMO" obj="WIN1">
<dds-screen type="NORMAL">
<dds-record name="SFLDATA" end="45" start="4" top="4" bottom="7" rel="true" sfl="true">
<dds-element name="NAME" len="20" lines="0" type="B" col="4" row="4" dec="-1" format="A" attr="UL" adjust="RAZ,MF"/>
<dds-element name="RANK" len="10" lines="0" type="B" col="26" row="4" dec="-1" format="A" attr="UL" adjust="RAZ,MF"/>
<dds-element name="SERIAL" len="8" lines="0" type="B" col="37" row="4" dec="-1" format="A" attr="UL" adjust="RAZ,MF"/>
</dds-record>
<dds-record name="WINDOW1" end="47" start="4" top="2" bottom="2" rel="true" win="true" sfctl="true" border="+-+||+-+" color="YELLOW" attr="RI">
<dds-element len="48" lines="0" type="C" col="4" row="2" dec="-1"/>
<dds-element len="42" lines="0" type="C" col="26" row="2" dec="-1"/>
<dds-element len="48" lines="0" type="C" col="37" row="2" dec="-1"/>
</dds-record>
<dds-record name="SFLRCD" end="13" start="9" top="6" bottom="10" rel="true" sfl="true">
<dds-element name="CTLFLD" len="1" lines="0" type="H" col="255" row="255" dec="0"/>
<dds-element name="F1" len="4" lines="0" type="O" col="9" row="6" dec="-1"/>
</dds-record>
</dds-screen>
</dds-display>
There are multiple reasons we choose to use binary DSPF instead of DDS source. Here are just a few of them.
- DSPF is already compiled, meaning DDS is correct and ready to be used. We do not need to create and simulate the DDS parser. (IBM already did it, so why to reinvent the wheel).
- There are DDS commands such as SLNO (Starting Line Number) keyword which shift all elements by number of rows defined in SLNO. The Resulting DSPF has different values at the end than within DDS itself, and such cases will make parsing DDS even more complicated. There are more different cases such as EDTCDE is compiled into EDTWRD etc... Or... REF fields to external resource, once DSPF is compiled, data is already extracted and embedded into DSPF, so we don't have to.
- Some companies uses 3rd party vendors for development which does not want to provide DDS source and creates a vendor lock-in, limiting you in your choices.
Once XML templates are generated, it means we have all screen information about fields positioning and types, window and subfile definitions etc. Next step is where Green Screens server detects what DSPF is used and which records from DSPF are used. We use so-called Job Identifiers instead of a standard IBM APIs as they are several times faster, almost immediate, so detection is really rapid.
Along terminal data sent to the browser, additional data (LIB, DSPF, [REC1, REC2...etc.]) are sent, allowing Facelift Engine to load only the templates used by the current screen.
For example, if DDS contains 100 records, but the current 5250 screen uses only 2 of them, it means only 2 templates will be loaded (and automatically cached by the browser, making consecutive calls even faster). Templates (partials), each representing record are merged on request or alternatively custom loaded (aka templates override; similar to the PRINT file overrides), and are usually very small - 1-2 KB.
As screen template in average is 1-2KB, it means for 100 screens, 100-200Kb of data will be required. An average user does not use 100 screens in daily use. So, resource usage at the browser side is small. Native browser caching is used, additionally reducing network bandwidth usage (faster UI rendering).
Templates itself are automatic, however, depending on DDS style, not all screens will look nice. Some will require small adjustments, while others will require more work. All boils down to mixing and reordering HTML tags. So, in essence, it is web templating.
It was never our goal to create automatic screen scrapping or screen modernization, it is actually impossible. Anyone with more extensive knowledge about DDS and 5250 terminal protocol knows about that (otherwise, there will be already automatic modernization engines which actually works).
Our goal is to create an open-source independent engine, easy to learn and as an intermediate layer for all which has a plan to either migrate 5250 programs or to embed them into other web products as UI elements.
The whole technology is based on free and open-source Bootstrap CSS (without JavaScript part) and, optionally, our own provided set of free and open-source components for Bootstrap.
The biggest Facelift Engine benefit is it is a standalone engine that communicate with the underlying 5250 web terminal through native web browser messaging with JSON based metadata (dynamically created from web 5250, not loaded from server, as some products does).
That allows a few more important possibilities:
- Offline template modification, with screen extracted JSON data (for Green Screens Web Terminal, simply use mouse right click to extract screen data).
- If a company wants to migrate from RPG/COBOL and 5250 terminal to web services, web templates are reusable. Switching from 5250 integration into standalone UI is simple removal of a special web tag (WebComponent) from master template which is responsible for communication. Even better, for custom template development, anyone can create its own integration - as the whole engine will be released as open-source.
What can be achieved with Bootstrap and free open-source Green Screens WebComponents can be seen in our most complex demo, which source code can be also found on GitHub. The demo itself is also an offline demo of Green Screens Server Web Admin console production version.
Also, if you want to get a quick look into the previous modernization engine version, check out the offline demo on our website. Just click around to see the screens, also try to use ESC key to switch between UI and 5250 terminal.