From Newsgroup: comp.lang.cobol

On Tuesday, April 10, 2012 at 1:27:39 PM UTC+12, Pete Dashwood wrote:
Six years on (2018) we have come a long way. PowerCOBOL can be migrated fully automatically (without the need to cut and paste scriptlets back into
the PowerCOBOL projects) and all of the following are now available:
1. Convert your PowerCOBOL sheets into Windows Forms and maintain them in Visual Studio. (Our tools create a VS project for the Form automatically, and generate C# Designer code that duplicates the original PowerCOBOL sheet, as required for Windows Forms.)
2. EXTRACT ALL of the COBOL code (Scriptlets) and automatically salvage it into code-behinds that can be invoked from the new WinForms. You can convert your existing scriptlets, AND/OR add new functions in a .Net language (C#/VB.NET or COBOL). All of your existing business logic is refactored into OO COBOL without any coding required on your part, and you do NOT need to invest in a CIL generating compiler (COBOL for .NET), but you CAN use such a compiler if you already have one. (You don't have to be expert in OO COBOL or C# because the Tools write all the code for you and do all the "heavy lifting" in both Languages.)
3. Your existing ISAM/VSAM/KSDS datasets can be moved to an optimized Relational DataBase in 3NF, and the new RDB can be loaded automatically WITHOUT you needing to write ANY code. (LOAD Programs are generated in standard COBOL so you can easily build your own filters into the load process...)
4. You can generate a Data Access Layer (DAL) that uses ESQL OR LINQ with exactly the same interface for either, and invocable from your COBOL. (NO coding required)
5. Your existing codebase (now in the form of the code-behinds from 2 above) can be refactored automatically so that all reference to the Indexed files is converted into invokes of the DAL. This is done fully automatically (on request) with no coding from you.
The "end-point" is a modern Windows .Net system with a "3 tier" (GUI, Business logic, and Data) separation layers design, refactored automatically from your current PowerCOBOL system.
The GUI layer is in Windows Forms, the Data Layer is in ESQL or LINQ (but you never maintain it anyway; the DAL objects do every action that is possible against a database...), and the Business logic remains in the original Scriptlet COBOL, but can now have C# or VB.NET added to it if you wish to phase out COBOL dependency. You can certainly stay with COBOL if that is your preference.
You "own" all of the code generated by our tools, exactly as if you had written it yourself.
The cost is less than you will pay for a new CIL generating .Net COBOL compiler...
You can have your choice of RDBMS, but we recommend SQL Server, and Migration will cost considerably less if you go with that.
There are videos and walkthroughs on our website and you should look at https://primacomputing.co.nz
There is now a clearly defined path to get you away from dependency on PowerCOBOL and into a modern .Net environment, at a price that is much less than you might imagine.
Pete.

In response to a client request, I am looking at an exit strategy for Power COBOL users.

It will use some existing tools and some new ones which PRIMA will develop.

Here's an outline:

1. Convert existing indexed files to Relational Database - existing.
2. Load the exisiting data to the new database - existing.
3. Generate a Data Access Layer comprised of objects - existing.
4. Modify all of the PowerCOBOL Project Event code to use the new DAL - existing.

All of the above is fully automated and requires no manual effort EXCEPT for item 4. Because of the nature of PowerCOBOL projects it is not possible to update the project directly. Our tools extract the event code from the project, make the necessary changes to it and load it into a schedule which must be manually cut and pasted back into the project. This is more of a clerical task than a programming one.

5. Separate the Power COBOL screens out from the project. We have a prototype which will analyse the PowerCOBOL screen and create it as a .Net screen.

The .Net screens can be maintained and manipulated with the Visual Studio Design Surface and have many more (and much more powerful) facilities than are provided by Power COBOL. People who have used the Power COBOL screen design facilities (dragging and dropping controls onto a design surface) will have no problem with using VS; it works the same way... All of the event code is automatically moved to a single .DLL (for each screen) which can be maintained in standard Fujitsu NetCOBOL. So, the PowerCOBOL project becomes a NetCOBOL .DLL (with each of the existing event processes defined as Methods and the .Net screen automatically connects the existing events to the COBOL .DLL) - New tool currently being developed but has passed Proof of Concept.

At this point, there is no need to use the Power COBOL IDE or Projects any more. The event code is in standard COBOL (no need for a .Net COBOL compiler), and the screens are in .Net. (You can use VB.Net or C# as the "glue", but it is really pretty much transparent. Your previous Power COBOL projects now become .Net projects and run as .Net Assemblies. The "Business Logic" is in the event code and this is now a COBOL .DLL that runs under the Interop services of .Net.)

Layers and Objects.

Obviously, introducing a separation layer between the Presentation (screen) and the Business logic tiers means that enhancing screens is very easy and even dropping a Metro interface for Win 8 into the Presentation layer is greatly simplified. (Design the Win 8 screen in Expression Blend or Visual Studio and use Javascript or C# to glue the events to the new tiles. The actual event processing can still be in COBOL if that is what you want.)

It is very unlikely that Alchemy will continue support for Power COBOL indefinitely and the above is a viable strategy for getting out from under.

The whole idea is to minimize the cost of this migration (especially for small businesses and independent developers) and it can be accomplished for around one third the cost of a .Net COBOL compiler. Note that Visual Studio Express (FREE) provides all of the facilities required to develop your screens and wire them to COBOL event processing; your existing NetCOBOL compiler will maintain the event code (instead of Power COBOL) so the only cost you incur is for the PRIMA Tools which we are discounting heavily for people trying to get off Power COBOL.

The options are to continue using COBOL as the event processing language, or to convert the COBOL to a more modern language. (Java or C#)

(Refactoring standard COBOL is a much simpler exercise than trying to refactor Power COBOL.)

If you are currently interested in moving off Power COBOL, or think that you might be in the future, please contact PRIMA:

info@primacomputing.co.nz

Tell us something about yourself, (type of company, or sole developer), approximately how many Power COBOL projects you run currently, how many indexed files you use and which RDBMS you would prefer. (We currently offer SQL Server and Oracle as standard but will provide ANY ANSI compliant RDBMS at additional cost.)

People who register an interest now, will receive updates and information, free trials, and very large discounts on the existing tools.. (People who help us with the development of the final product (Step 5, above), will get the final product for free.)

Register now. This offer is LIMITED. (I can't keep it open indefinitely.)

Pete.
--
"I used to write COBOL...now I can do anything."

--- Synchronet 3.20a-Linux NewsLink 1.114