Tuesday, February 3, 2009

Preparing for FOCUS-to-WebFOCUS Conversions

If you are considering converting your FOCUS 4GL environment to the new web-based version, here are some things you need to know.

Many people want to understand the difference between FOCUS and WebFOCUS and come to my blog looking for a comparison between the two products, so let me start there.

Both are software products from Information Builders and both share a common 4GL processor. In fact, the vendor in recent years has been able to consolidate these two products into a single code base, which is fairly portable and independent of any particular operating system.

The FOCUS product was used both interactively and in batch. Online users could communicate with menus and screens for providing information or go directly to a command processor for simple ad-hoc requests. Programs could also be run using JCL or other batch control mechanism with parameters passed in or determined by the program itself.

There are two three broad components of the FOCUS 4GL, the main piece being a non-procedural language for reporting, graphing, analysis, and maintaining data. There is also a procedural scripting language (Dialogue Manager) that provides some logical control of the embedded non-procedural code, symbolic variable substitutions, and multi-step complex processes. These are critical to enabling WebFOCUS to perform complex, dynamically-generated web applications.

A third important component is the metadata and adapter layer, which hides the complexity of the underlying data structures, allowing developers and end users to write 4GL programs with minimal knowledge of the data.

Major Features of the Procedural Scripting (Dialogue Manager):
  • Symbolic variable substitutions (calculations, prompting, file I/O, etc.)
  • System variables (date, time, userid, platform, environment settings, etc.)
  • Calculations of temporary variables
  • GOTO branch controls and procedural labels (non-conditional as well as IF-THEN-ELSE conditional branching)
  • Embedded operating system commands
  • External file I/O
  • Green-screen interactive with the user (not functional in WebFOCUS)
  • Executing procedures (EXEC command and server-side code inclusions)

Major Features of the Non-Procedural Scripting (FOCUS 4GL):
  • Reports and output files (TABLE facility)
  • Graphs (GRAPH facility)
  • Joining files (JOIN facility)
  • Matching files (MATCH facility)
  • Database maintenance (MODIFY facility; non-screen features supported in WebFOCUS, otherwise replaced by MAINTAIN)
  • Statistical analysis (ANALYZE facility; was rarely used and not ported to WebFOCUS; recently R Stat support was added)
  • Environment settings (SET phrases)
  • Calculation of temporary columns (DEFINE and COMPUTE phrases)

FOCUS-to-WebFOCUS Conversion issues:
Despite the portable FOCUS 4GL that lies beneath the covers of WebFOCUS, there are still some considerable challenges to converting from legacy to web-based architectures. I have solved some of those problems for you by automating the process. Below are some conversion issues and their potential solutions.

1) Major architectural change (single technology stack to enterprise web stack)

Solution: architect a solution that minimizes change
Solution: for new WebFOCUS app path commands, automatically add to existing code

2) New end user environment

Solution: automatically convert existing 4GL programs for users; generate scripts for loading Managed Reporting Environment; provide user training

3) Persistent sessions not supported in web environment

Solution: analyze and determine how to replicate persistence (for example, loss of "global" variables)

4) Batch processing handled differently in web environment

Solution: replicate batch jobs using WebFOCUS ReportCaster scheduler/distribution product

5) Output report formats default to HTML, which does not respect original layout

Solution: automatically add stylesheets and PDF support

6) Dumb terminal green-screens not supported in WebFOCUS

Solution: for simple menus, convert to HTML
Solution: for simple data maintenance, convert to HTML and MODIFY
Solution: for complex data maintenance, convert to MAINTAIN

7) WebFOCUS eliminated some legacy FOCUS features (text editor, end-user wizards, type to screen, ANALYZE statistical facility, etc.)

Solution: analyze and develop work-around

8) New Graph engine

Solution: automatically add support for new graph rendering (third-party Java product)

9) If moving to new platform, multiple problems, including access to legacy data, embedded OS commands, file names, allocations, user-written subroutines, userids, printer ids, integrated third-party tools (e.g., SAS, SyncSort, OS utilities), etc.

Solution: analyze and automatically convert as much as possible

10) Organization typically wants to take advantage of new features quickly

Solution: automatically add some support during conversions (e.g., spreadsheets, dynamic launch pages to consolidate existing FOCUS code) -- in other words, get rid of the legacy product as quickly as possible by doing a straight replication, but try to give the business some new things in the process


Trying to manually convert FOCUS to WebFOCUS is just not a good approach. By utilizing a proven methodology and software toolkit for automating much of the manual effort, you will dramatically reduce the time, cost, skill-set requirements, and risk of doing the legacy replacement.

Be sure to read some of my other blogs on this topic.  A good place to start is here.

If you have questions, feel free to contact me.



You may also be interested in these articles:


No comments:

About Me

My Photo
Helping companies make better decisions via Business Intelligence. INTP working on the E&J. Traveler, reader, family guy, coffee drinker.