DBMaker and COBOL Green Screens

COBOL applications predate all standard GUI (Graphical User Interfaces). Therefore, it is not surprising to view the countless programs and applications that were developed using traditional green screens. As technology has advanced, it has become more difficult for running, stable COBOL applications to continuously improve the user interface, leading to user complaints about a perceived "old" design. This difficulty is based, in part, on the following reasons:

Lack of Graphical COBOL Syntax
The COBOL language standards have not fully embraced graphical interfaces. This has caused a delay in years while developers have waited for COBOL vendors to support a graphical syntax. As that support has come, it has often been too late: some COBOL vendors provided a reasonable DOS style graphical interface only after Microsoft Windows had already become the standard.

End-users understand that implementing a new technology can take time. But when application developers do not have the correct syntax for years after a standard is implemented, the delay becomes unacceptable to the end-users. This means that there is ever increasing pressure on the developers to provide "some" kind of solution, even if this means a complete re-write of the application in a language that will support the current standard GUI.

Graphical Design tools do not work well with COBOL
There are many tools, which can be used to develop graphical information in current standards, such as Java, XML, HTML, or in other more traditional 4GL style displays. Such tools do not integrate well with COBOL at all. This is based on expectations (tools expect to interface with data streams, not programs), as well as differences in design (Tools which are not setup to deal with procedurally linked languages like COBOL). While some vendors like Micro Focus have developed interfaces to Graphical design tools, the conversion requirements can be too expensive.

End-users can see and use the tools in many places, but NOT with a COBOL application. This leads COBOL applications to be viewed as not acceptable options as business processing solutions.

Large Body of Work
COBOL applications have been in production for many years. These applications have expanded functionality based on their long production runs. While this shows the value of the language, it also means that there are many systems, and interfaces in the current version of the application. This means that conversion is difficult, simply because there is so much to convert.

Difficulty of a Code Freeze
Even while users are expecting a conversion of the application to a modern graphical format, they expect maintenance releases to continue on a regular basis. The inability to stop all other development (code freeze), so work can concentrate on graphical conversion issues, means that many applications cannot be converted easily.

DBMaker helps Resolve Green Screen Issues

While DBMaker is not a GUI development tool, moving to DBMaker will save significant development time and relieve end-user pressure for application conversion. GUI development tools (Java, XML, HTML, etc.) are already designed to access data from DBMaker; so they can provide a solution very quickly. Providing an Open database will relieve some of the end-user pressure, as it will give them flexibility they need. As a DBMaker solution (installed database with completely converted data) is completed in very little time, without a Code Freeze, the savings (of flexibility and expanded tool use) will be quickly realized. DBMaker helps developers to more efficiently provide the graphical interfaces expected today.