This doesn't mean you should stay in deer-in-headlights mode and do nothing. You know you need to move forward, but how best to break the inertia? How about starting by reading this article? Here, I'll provide a simple, high-level view of this often perplexing subject. In doing so, I'll help you clarify your business case for a 5250-to-Web initiative, present a variety of important considerations when researching any vendor solution, and give you a quick look at the different types of available vendor solutions.
Reasons for Moving from 5250 to the Web
Some reasons to move applications to the Web are obvious, while others are not. See how your own needs match up, and don't be surprised if you discover reasons for getting graphical that you didn't expect.
Many users, especially those who have entered the job market during the past 10 years, expect an application to have a graphical look and feel. Although the business logic of a green-screen application may be cutting edge, it will likely be judged as ancient technology.
For practical reasons, it is critical to support the users who can relate to software only while resting their hand on a mouse, and in many organizations, these folks are becoming the majority. First, training is faster when staff is using a familiar interface; second, graphics on the screen can enhance software's ease of use, which may translate into increased user productivity.
But it's not just daily users whose productivity can improve because of a GUI. Managers and executives are more prone to dive into the application when it has a GUI interface, thereby getting to know their business processes better and extracting decision-critical information in ways they never expected.
Better Data Presentation
Browser-based screen presentations can consolidate data from multiple screens (or even multiple applications) onto a single page, because the data isn't constrained by 20 rows and 80 columns of fixed-size characters (27x132 if condensed). This, of course, can make information access more efficient, especially when graphics are added to organize and navigate the data. For instance, with consolidated information, customer service reps can view comprehensive information about customers and their orders on a single screen, eliminating the need to jump between screens.
In addition, in a business world where financial, manufacturing, and distribution operations are rarely under one roof and on one system, seamless integration from disparate systems and locations has become a necessity. With a graphical presentation, information from a variety of sources is more easily consolidated and presented.
Whether you're developing a complete online e-commerce site for customers to create, change, and view orders or you're designing function-specific portals for vendors, partners, and staff, e-business is high on the list of why companies need browser-based functions in their applications. New opportunities and efficiencies can be realized when you include selected data from your legacy applications in a Web portal.
E-business can provide significant cost-savings by lessening the frequency of manual intervention when transactions occur. The manual entry of information from emails, faxes, and phone calls into your applications is always a point of vulnerability for errors. When information can be input directly into an application, the potential for error (and the costs associated with errors) drops dramatically.
With an online presence, not only can transactions be created and changed online, but a broad geographical presence is made available for your roving staff. Your salespeople can review orders and solve problems (or prevent them) while they are on the road, and staff can update data from remote locations.
Centralized Application Delivery
Rather than install every application on every machine that uses it, you can deliver and maintain the application from a central location via a Web application server. The benefits include a single point of software maintenance, simplified security and data backup, easy integration of data from multiple locations, and less use of resources on your remote servers. And if you also sell your applications, delivering them via the Web on a "subscription" basis can open a whole new pool of potential customers.
Reduced Interactive Workload
Green-screen 5250 applications require the use of interactive processing, for which IBM, of course, charges a premium, and it is likely that this premium will just keep rising. For instance, the newest entry-level iSeries 810 with the Enterprise Edition option, giving you all of the interactive processing that you want, costs $44,000 more than the machine with the Standard Edition, in which you pay extra for any interactive processing that you want.
Many of the tools that turn 5250 applications into a browser-based interface move the interactive processing to batch subsystems, which means that you can either forego adding more interactive CPU on your existing machine or completely skip it on a new machine. In some cases, this can more than pay for your 5250-to-Web initiative.
Considerations When Evaluating 5250-to-Web Solutions
Once the business reasons for moving to the Web are clear to you, it's time to consider your specific needs and to assess your limitations; these include costs, skill sets, and time constraints. Many products can help you move from 5250 to Web, and each was built to solve some particular need, although it may not necessarily be your need. Avoid a black-and-white approach to these solutions, and don't let vendors push you. As is the case with most areas of IT, there is no magic bullet.
The first thing to remember with any kind of IT purchase is that vendor service is a critical consideration and should carry a good deal of weight when making a purchasing decision. Before buying, ask for references and speak to customers who have solved challenges like your own.
Also, when looking for a solution, make sure it satisfies four critical considerations in light of your business needs: functionality, user acceptance, system compatibility, and accommodation of future needs. Let's take a closer look at these.
It's critical to evaluate the level of presentation that you want from the browser before looking at solutions. One application may only need Web-accessed terminal emulation, while another just needs simple screens in which function keys are converted to buttons and prompt fields are transformed into pull-down lists, while a third requires the delivery of a true "Web" look, feel, and functionality.
You also need to consider whether your applications need to concurrently support a green-screen presentation. If so, be sure to understand whether the solution will require you to maintain two sets of source code.
It is important to know at the outset whether all or just some of your applications need to be enabled for browser access. Of the ones that do, does the entire application need a makeover or only portions? Understanding this can make a big difference in the kind of solution that you choose. There are tools and even suites of tools that can support a variety of needs.
Finally, within the realm of functionality, you need to consider how well the solution interacts with whatever Web application server you intend to use. If you don't have a Web application server and the solution that you choose requires one particular server, make sure you are willing to be bound by this.
It is critical when selecting a solution that you consider the skill set of those who are to implement solution. How much will your IS staff have to learn? If you have only RPG programmers, depending on the type of solution you need, you may need to consider whether you want to spend the time and money to have them learn Java or other skills.
Keep in mind that some available solutions can utilize the existing skill set of your RPG programmers and will often provide a mechanism to batch modify your source code, if needed.
If your programmers need to add new skills, it is vital that the vendor be available to support them during this process. You also need to consider the general skill set of the end-users of your applications. Perhaps the bulk of your customer's users are satisfied with your green-screens because they only have to key data into a few simple fields, or maybe most users simply scan and verify information. Despite all the reasons to go to GUI, there are still applications where this still may not be a necessity.
Finally, if you are buying a solution that also provides tools for new development, consider how the solution fits into your application development cycle. And don't forget to consider how the tool will fit into your change management procedures.
The final straw that often pushes companies to a browser-based presentation is the necessity of adding expensive interactive processor capacity. As mentioned previously, moving to a browser-based interface can fully cost-justify the 5250-to-Web transformation process, because many of the tools that "reface" them move this processor load to batch processing. This means that you can put off adding an interactive processor, and if you are looking to upgrade to one of the newest iSeries machines, you may be able to get away with buying the Standard Edition rather than the Enterprise Edition, thus saving thousands of dollars.
Even if you are able to dramatically reduce or eliminate interactive processing by moving to a browser-based presentation, you also have to consider whether you have enough CPW to do the job. Different tools will require different amounts of CPW capacity.
When selecting a solution, also keep in mind whether the converted application will require a fairly recent version of OS/400 in order for it to become GUI. If your newly "Web-ified" application needs to run on other iSeries machines that have an older release of the operating system, this may present a problem.
Accommodation of Future Needs
Before looking at solutions, think about what you might need to achieve with the Web delivery of your data in the foreseeable future. For instance, you may soon need to interface with data from other applications--even applications that are not your own (e.g., data from partners, suppliers, governmental agencies, etc.).
Also consider that different user interfaces (UIs) might be needed down the road. Different UIs have come and gone over the years, and who knows what the next hot UI will be. You may not want to buy a solution that locks you into one particular UI, as this could mean having to purchase a different solution later in order to accommodate a whole different UI.
It is important to understand that the interchangeability of UIs can typically be accomplished only if the business logic layer is separated from the presentation layer in your applications. Some available solutions can retrofit your code with some amazing universal adapters; however, the source of your programs will likely need to be modified. Solutions are available that can batch convert your source to make this modification. Still, such a retrofit can require a great deal of extra work, and some solutions require that you support two sets of source code if green-screens are still required.
General Categories of 5250-to-Web Solutions
Now that you know why you might want to go graphical, and now that you have a basic understanding of the crucial considerations of such an initiative, let's look at some of the different types of 5250-to-Web solutions that are available. For the purposes of comparison, these solutions can be loosely grouped into four major categories:
- Emulation offers simple Web access to a 5250 data stream. The characters on a green-screen are presented in a Web browser, so the look and functionality of the screen is essentially the same as if it were being accessed through standard terminal emulation.
- Reface (non-intrusive transformation) turns green-screen output graphical without the need to change the source code. Function and Enter keys are typically replaced by buttons, prompts are replaced by pull-down lists, etc. This option is often chosen when source code is not available.
- Replace (intrusive transformation) allows the output portion of the source code to be "replaced" by a high-speed messaging function that acts as a "universal adapter," letting you have the display output sent to just about any kind of user interface that you want. Replace solutions always require some source code modification.
- Rewrite completely recodes existing applications or creates new applications to natively include the new graphical presentation layer.
Many existing vendor solutions include one or more of these categories. Although I've listed below some in each category, the list is not all-inclusive. To begin finding out about more vendors, see the MC Press Vendor Directory.
Warning: When you're evaluating a vendor solution, you're likely to see a snazzy demo in which some of your display-only-data screens are rapidly transformed into graphical presentations. Before being too "wowed," be sure to have the vendor transform a few of your more complex screens so you can see how these will behave.
For those situations where the goal is simply to eliminate thick-client software, like Client Access, and have all internal users access applications through a Web browser, an enhanced terminal emulation product with Web access capabilities can be the answer. The benefits are simpler workstation configuration and easier access of applications via LAN, WAN, and VPN. When looking at emulation solutions, make sure they will emulate function keys.
• Mochasoft 5250
• Teamstudio Screensurfer
• CABEL AS to Web
• Seagull BlueZone
• IBM Host On-Demand
• IBM iSeries Access for Web
• ADVANCED BusinessLink GUIStyle
• Jacada Terminal Emulator
Reface (Non-intrusive Transformation)
Reface tools essentially transform each screen in a legacy application into a graphical presentation by taking the character-based output specifications of each screen and converting them on the fly into HTML and/or JSP equivalents. With solutions that fall into this category, there is no need to modify source code; therefore, developers can manage a single set of code and let the refacing tool do the rest.
You might think this is the same as the screen-scraping tools of the 1990s, but reface technology has evolved a long way from the laborious, tedious, and functionally limiting process of yesteryear.
Reface tools either work from the DDS or take the actual 5250 display output. With few exceptions, these tools require an interactive processor because the 5250 output is still being generated.
With reface tools, developers don't need to have Java or Visual Basic skills. In fact, modern reface tools typically define the output with an intuitive design template or style sheet (also called a graphical style repository) in which you define a set of rules to guide the look and properties of the screen. Many tools also include a WYSIWYG design function.
The upside of reface tools is a quick, non-intrusive facelift for your applications that requires few if any additional skills and doesn't require you to have or change source code. The downside is that they still require an interactive processor, they typically require a fairly large footprint on the host, and if you want to significantly modify the browser-based screen output of the tool beyond what can be achieved with the design template, you are on your own to know at least HTML and possibly Java.
• BOScom Jadvantage
• California Software BABY/iSeries
• IBM Host Access Transformation Server (HATS)
• IBM WebFacing
• Jacada Integrator
• Linoma aXes
• looksoftware newlook
• ResQNet ResQNet
• Seagull JWalk
Replace (Intrusive Transformation)
Replace tools require that the existing legacy source code is modified to have the output portion of the code (the 5250 data stream) "replaced" by a high-speed messaging API that acts as a universal adapter. In other words, the display file I/O requests are replaced with API calls within your source code. In order to accomplish this, the business logic is separated from the presentation logic in the code.
Of course, the downside of replace tools is that you need to modify the output portion of all of your application's source code, although most replace tools include utilities to help you automate this. Still, there can be a fair bit of up-front maintenance required. Additionally, if you also need to support green-screen users, depending on the tool that you choose, you may find yourself managing two sets of source code.
The benefits of using this kind of tool, however, can be significant:
- Eliminate the application's interactive workload by replacing the 5250 data stream. This is about the only way to achieve this without a full rewrite. The exception is IBM's WebFacing solution, but only when running on the newest model iSeries machines.
- Use just about any kind of existing user interface as well as any other that comes along. This is especially useful if your current or future requirements include sending application data to various kinds of information portals.
- Achieve a true Web look and feel, which is often not available in a reface tool.
- Minimize the hit on system resources when you need to make data available in an event-driven environment (e.g., the general public via the Web). Because the code is modular, as each request for data occurs, the required fields are passed, data is processed, a response is sent to the requestor, and the job terminates.
Rewriting involves recreating existing applications from scratch or building brand new applications that allow your choice of a graphical presentation layer to be natively included. Various development products can also transform legacy source code (e.g., RPG, COBOL, etc.) to another language (e.g., Java), which helps when migrating apps--although the automation of source code migration can be a tricky process.
Rewriting tools are useful not just for developing larger applications, but especially for smaller browser-based initiatives that include pieces of legacy data. In these cases, XML, SOAP, and other protocols are often used to port data from a variety of applications residing on different platforms into the end product. Again, depending on what you want to do (either now or in the foreseeable future), be sure that the tool you choose can accommodate your needs.
• ADVANCED Businesslink Strategi
• BCD ProGen WebSmart
• Computer Associates Advantage 2E
• Freestyle-400 Freestyle-400
• Genexus GeneXus
• Jacada Studio for iSeries
• System Objects Jbuilder for iSeries
• LANSA for the Web and LANSA Integrator
• mrc mrc-Productivity
• Profound Logic RPG Smart Pages
• Relational-Data RelationalWeb
• Seagull LegaSuite
• IBM WebSphere Development Studio
Now that you've taken in the 30,000-foot view of the 5250-to-Web world, you should be able to constructively explore your business reasons for this initiative and more closely understand your own constraints. With this knowledge, you can begin to absorb more of the details on this subject both from industry resources and by picking the brains of vendors who can be an extremely valuable resource of information and education on the subject--especially when you know what questions to ask. As you expand your understanding, you will be able to more objectively assess vendor solutions and find the right tool or combination of tools that will be both affordable and suitable to your needs.
Best of all, you will confidently leave the crowded ranks of the "5250-to-Web perplexed" and begin to realize all of the benefits that these technologies have to offer.
Some additional resources:
- The MC Press Vendor Directory
- E-Deployment: The Fastest Path to the Web by Joe Pluta, available from MC Press
- IBM Redbook: Tools for Application Reface & Redesign