Approaching .NET from VPlus
October 22, 2008
Medford, Oregon schools will be moving to the .NET architecture and Windows from their HP 3000 systems, according to Senior Programmer/Analyst Dave Vorgang. He asked the users who gather on the 3000 newsgroup to advise him about his project.
He said, "I have just began working on a project for converting our existing HP 3000 VPlus screens to use Fujitsu COBOL on the back-end and use .NET for the forms. What I plan to do is create routines to emulate the VPlus intrinsics.
"Our student system is homegrown. All done with COBOL/VPlus/IMAGE. I’ve been assigned the task of wrapping all the VPlus intrinsic calls to perform their vb.net equivalence — the idea being that we can simply take our existing COBOL apps, run them through a converter to convert them to Fujitsu, and then have my VPlus routines display the forms."
His first design demands 25 percent of the CPU resources to execute a Do Loop, "a routine which will perform the Vreadfields, which basically blocks execution of my application until _KeyEntered = True"
Advice from fellow users in the community arrived in short order, as contractors reported their .NET achievements and strategies.
Charlie Cookson, of Web Navigation LLC, told Vorgang
1) If you want to preserve your COBOL then you can create a .NET form and package up the data in the exact format the ViewRead would see it. On the HP 3000 you would have a listener program that would receive the data string. We used Minisoft’s Middleman to do this.
The receiving program would be a copy of your original COBOL where the string would be considered the return value from the View3000 Read. We used this method for several years.
2) We eventually took one screen at a time and did it completely in .NET. Again we used Minisoft for the connection. We did not use SlowDBC. We did DBFIND, DBGET, DBUPDATE, DBDELETE directly from the VB or C# code. This is very fast and allows all the features of a .NET application with the HP 3000 as a data server.
Then Paul Raulerson, a new 3000 fan but an experienced hand at Windows, gave a critique of the .NET code that Vorgang offered for examination:
Fujitsu COBOL has a WinForms designer that allows you to basically create the forms very quickly, and they of course run in .NET. You would need to recode small parts of your application to use input and output records (or some similar technique) to the screens. But honestly, you would find this far easier than trying to emulate the VPlus calls — albeit, it is not a terribly difficult task to do so.
However, I think you might be a bit unfamiliar with the Windows world, based upon your code. You never need to put the program in a loop looking for a keypress like you have; you would simply write a code “snippet” and attach it to the handler for the screen. Sounds a little weird, I admit, but quite easy to do.
Note that you don’t need to actually write the GUI screens in COBOL at all; you can do the screens very quickly in Visual Basic or some such and have then call the back-end Fujitsu COBOL programs. Visual Basic is easy to draw screens in. Very shallow learning curve.
Cookson then added
I have created CLASSES that my code calls that will update both the HP 3000 and my new SQL database. This allows me to dynamically keep both in sync. Eventually I turn off the H3000 update after all reports and screens have been converted to SQL.
By using .NET classes built to emulate the original HP intrinsic calls, you can do a mass change (usually with a little manual intervention) to convert your new calls. It still takes a little work and know how, but you can preserve your COBOL investment.