Using Webforms to Convert 3000 Screens
December 15, 2009
By Mike Howard
Unicon Conversion Technologies
Second of two parts
Webforms, like Winforms, are from Microsoft. They are created and maintained in Visual Studio, have full GUI facilities and are maintained completely outside the COBOL program. But that is where the similarity ends. Webforms are full ASPX .NET and therefore employ a completely different method of processing.
With Webforms, the user PCs are not connected to the host through any terminal services software. The host server must have a Web server installed on it. User PCs connect to the Web server through a Web browser and the Internet or an intranet. The user typically has an icon on their screen that starts the app when the user clicks on the icon. This launches an instance of the Web browser and gives it the URL of the Web server and the name of the Webform to be displayed. The form displays on the user PC.
Now remember we fired up a Webform, not a COBOL program. The form is presented onto the screen but there is no application program running on the server. The user enters the data into the form and presses a function key or screen button and the Webform creates an event request and sends it to the Web Server. The Web Server receives the request and the Webform’s “code behind” processes the request by calling an application program to service that request. When the application program has performed its function, perhaps to obtain account information from the database using the account number entered by the user, it terminates and returns that information to the Webform code behind. The Webform code behind populates the form with the information and sends the form to the terminal.
The main thing to appreciate is that it’s the Webform that calls the application program to perform an event request. The application program performs the request and terminates. The program responded to the form. The form is in control, not the program. When the form is on the screen there is no application program running on the server. This is stateless processing. An application program cannot “call” a form to display on the terminal, it can only respond to a call from a form and return to that form. The form however can invoke or call another form to be displayed. This processing does not fit the procedural code of most HP 3000 programs.
Basically there are two competing methods involved here, the stateless processing of the Webform and the instate processing of the application procedural code. In addition, in the stateless process the forms needs to be in control of the programs and in the instate process the programs needs to be in control of the forms.
Engineered to make it stateless
To make it work, the HP 3000 application programs have to be re-engineered into objects containing the logic required to service a form request. This is a massive undertaking. To enable a Webform front-end to work with a converted HP 3000 procedural program back end, Unicon created an interface manager called the Procedural Code Interface Manager.
We used to offer our tools for do it yourself projects many years ago. Although the customers were always very happy with their results, we knew that they had incorporated many items that in time would prove problematic. Most DIY conversions are done by people with no prior migration experience and they haven’t yet learned what not to do, or what fits together better for the long run.
Today we only perform migration projects, although these are often very performed on a joint effort with heavy customer involvement. We do not simply present a predetermined shrink-wrapped option to the customer – we ask the customer what he would like to see his application system migrated to. If he doesn’t know, we provide him with a list for options with benefits and disadvantages. We then produce a migration plan specific to the customer’s migration needs.