A Quick Cheat Sheet for Reloads
Using Webforms to Convert 3000 Screens

3000 Screen Conversions to Windows .NET

By Mike Howard
Unicon Conversion Technologies

Before 1998, all of our customers were asking us to migrate their mission-critical applications to Unix. What a difference the last 10 years have made. Today our customers’ new platform of choice is predominantly Windows. This is true for migrations from the smaller DEC VAX systems though the midrange HP 3000 systems and up to IBM mainframes. It’s true that over 25 years we have migrated more customers to Unix than Windows. But today that ratio is changing fast.

The decision is purely the customer’s choice. So why do more of our customers choose Windows? Each has their own reasons, from finding it easier to recruit Windows-knowledgeable staff than Unix staff; to consolidating all systems onto one platform type throughout the organization; to wanting to establish a Visual Studio .NET shop.

So what does an HP 3000 application look like after it is migrated to Windows? To a large extent that question is answered by what method is chosen to perform the migration. But the most obvious distinction in appearance are an application’s screens. Let’s take a look.

    Screens are perhaps the most important aspect of a successful migration project, because this is the primary interface to the user community. It is imperative to ensure that the migrated screens satisfy the needs of the users. Screens can be converted to look and feel almost exactly as they did on the HP 3000. Or they can be enhanced with additional GUI functionality. Sometimes screens are migrated as-is for one department and with a new GUI for another department.

     For example, users in a department who are used to speed-typing data into the system may find it very detrimental to their job function to have to deal with the point and click of a mouse. On the other hand, some users may find it beneficial to be given selection list boxes or dropdown selection boxes to help them better manage their data input process. 

     On the HP 3000, a user logs onto the system and then, often through use of a menu system, calls the program that contains the screens the users want to use. The program presents the screen to the terminal and in the accept case waits for the user to enter the data, at which point the user will hit a function key, and the program will continue on to the next instruction in the logic path.

    Thus, the HP 3000 online application code is procedural code. Throughout the process the program is fully resident in the memory (in-state) and it is always in command of the processing, and the screens will be presented to the terminal by the program in the order determined by its logic path.

    Although screen processing can be performed by using COBOL and statements, most HP 3000 programs use VPlus intrinsic calls to perform screen functions. VPlus forms are maintained separately from the COBOL program.

    HP 3000 VPlus screens can be converted to three types of Windows screens: COBOL SCREEN SECTION screens, Winforms, and Webforms.

    COBOL SCREEN SECTION screens are the standard way of processing screens in COBOL. The SCREEN SECTION is a relatively new section that comes after the LINKAGE SECTION in the DATA DIVISION of the COBOL program. The screen is defined in the SCREEN SECTION, then presented to the terminal by DISPLAY screen-name and ACCEPT screen-name statements in the program. SCREEN SECTION screens are contained entirely in the COBOL program and maintained as part of the program.

    Winforms are from Microsoft. They are created and maintained in Visual Studio, using the standard Visual Studio IDE, and of course they have full GUI facilities. That means Winforms are maintained completely outside the COBOL program. When the program wants to use a form it invokes the form.

    The calling of a SCREEN SECTION screen or a Webform screen in a converted COBOL program is similar in concept to calling a VPlus form. The program is in full control and the screens are presented to the user terminal as the program executes along its logic paths. This is a normal procedural code process just like the HP 3000’s COBOL uses. And just like the HP 3000 system, the user logs onto the Windows server from a PC which is connected over a network. The only difference is that instead of using terminal emulation software to connect to the server, the user connects using a Windows Terminal Services connection or a Citrix WinFrame connection.

Next: Webforms in action, and stateless processing distinctions