End-to-end FULLY AUTOMATED PowerCOBOL Migration to .Net. NO Code required. Mouse clicks only.

Skip to first unread message

pete dashwood

Sep 22, 2021, 3:00:15 AM9/22/21
This is now available from PRIMA.


Let's say you have a number of PowerCOBOL projects that are running a
number of applications and subsystems.

You've invested years in designing PowerCOBOL Sheets (screens) and
writing Scriptlets in COBOL to drive those Sheets.

You use indexed files for your random access.

Your concerns are:

1. Support for PowerCOBOL could be pulled at any minute.
2. The indexed files are not easily accessible with today's standard
tools and you need to write a PowerCOBOL Scriptlet every time someone
wants to know something...
3. There is NO provided migration path to get you off of PowerCOBOL.
4. You are considering moving to Python or Java, but the cost would be
horrendous, and you simply CAN'T drop some of the business processes
that are encapsulated in the PowerCOBOL projects.

<sound of a distant bugle floats on the breeze... its the PRIMA cavalry...>


1. You can have a properly designed Relational Database, that is
optimized, and in 3rd Normal Form, created and built in MS SQL Server.
(Other RDBMS can be accommodated but it will cost more...)

2. The database described in 1. can be loaded with the existing data on
the indexed files, using load programs generated by our tools, in seconds.

3. The Tools can generate a Data Access Layer (in COBOL using Embedded
SQL or in C# using LINQ) that can maintain every possible action against
every tableset on your database. There will be a single DAL object for
every tableset and it is compiled code, so it is much faster than
interpreted script when it comes to access.

4. For each of your PowerCOBOL Projects:

1. ALL of the sheets in the project have been converted into standard
Windows Forms, with no change to the events and processes so that the
functionality under .Net is exactly as it was under PowerCOBOL. In some
cases, better, more powerful .Net controls on the sheets have replaced
the old PowerCOBOL controls. (No extra charge... a free upgrade, and
your option).

2. ALL of the Scriptlets that drove the old sheets, and encapsulated
many of your Business Rules have become Methods in a single Class that
drives the new WinForm. There is an OO COBOL Class for EACH Win Form. It
is referred to as a "code-behind".

Code-behinds don't HAVE to be in COBOL. We are looking at Python and C#
or even mixed languages. The Converted Forms have COBOL code-behinds but
it can be converted or mixed with other languages if required. New Forms
are developed as WinForms in exactly the same way as Windows development
proceeds around the world, using Visual Studio design surface to drag
and drop Windows Controls.

3. We Transform ALL of the COBOL indexed IO in the code-behinds, into
method invokes of DAL objects. Your system moves easily to .Net
WinForms using a Data Access Layer against a modern, optimized RDB.

You are free from dependence on PowerCOBOL and have brought your system
into the 21st century. You can continue writing your code-behinds in
COBOL or you can use a newer language; there are many options.

There is no proprietary run time that your converted system can't run
without; ALL of the source code is available to you, and you have full
rights over it. (It is YOUR code, exactly as if you had written it...)
You can generate changes using the Tools or you can code changes by
hand, you are NOT LOCKED IN!


You can outsource your migration to us, you can undertake it yourself
using our tools (leased or owned) with or without help from us, or you
can do it all manually. We'll even give you advice, at no charge, that
will save you a great deal of money and tears...

Having tried it manually on a number of occasions, I can assure you that
using the PRIMA tools is better... :-)

Please drop me a line if you find any of the above to be of interest, or
forward this mail if you know anybody who might.

This is the culmination of many years of effort; I hope someone can use it.

Here's a quick video showing the move to WinForms. I haven't done one
yet for the full e-2-e described above.




I used to write *COBOL*; now I can do *anything*...


Sep 28, 2021, 8:04:12 AM9/28/21
What is the price or terms?

pete dashwood

Oct 5, 2021, 1:04:58 AM10/5/21
It depends on how many PowerCOBOL projects you have, how many sheets are
in each one, how many indexed files are used (if you want to go to
Relational Database as well as Windows Forms), and how many third party
(non-standard PowerCOBOL) controls are on your sheets.

Things like the degree of COBOL expertise available (OO COBOL knowledge
is useful, but not essential... We can help people transition from
PowerCOBOL skills to the new Windows skills...) and how well organized
the existing system is, can also affect the cost.

Just as a ballpark, if you have, say, 5 PowerCOBOL projects with an
average of 4 sheets in each, and they are using 4 indexed files, with no
third-party controls, it will cost you around $600 to move everything
into Windows .NET and start using an optimized RDB in third Normal Form,
via a true Data Access Layer.

The deliverables include ALL source code, ALL object code, and full
documentation. There are no proprietary modules needed to run your new
system, no licensing of any generated code, and no middleware
dependence. Your new system is exactly as if you had written it
yourself, in COBOL.

(Please don't try and extrapolate from these figures; it gets cheaper as
it increases... All I'm trying to do here is show that migration is
possible for less than the cost of your COBOL compiler and support...)

You will need the Native Code generating Fujitsu NetCOBOL for Windows
compiler (which you already have if you are using PowerCOBOL (any
version 7+)). If you want to use a Managed Code generating compiler
(Fujitsu or Micro Focus are the main 2) you will need to talk to us.
Once you have migrated, you can use the FREE Managed Code generating MS
compilers for C#, VB.Net, or Python, "as well as/instead of" COBOL, for
future development and maintenance.

There are many additional add-ons you can get and the price of these
varies, depending on how much business you do with us. For example, we
can offer a DAL layer written in C# and using LINQ instead of embedded
SQL with COBOL. It has tested around 6 times faster than ESQL for some
operations, and around 1.7 times faster on average.... Although you can
see the source code of the DAL objects, you don't normally maintain
them, so the language they are written in is irrelevant.

This gets you off dependency on PowerCOBOL FOREVER!

But it does so without losing ANY of your existing functionality or
Business Rules.

If you are seriously interested, mail me privately and we can have a
Zoom session about it and I can get a better idea of what you need and
what it will cost. Maybe a Proof of Concept will help to give you a
better understanding of the whole migration process using our tools.



PS I don't like marketing our products through this forum because that
is not what it is for, so would appreciate it if we can take this offline.

Kerry Liles

Oct 5, 2021, 12:09:21 PM10/5/21
Pete, did you mean $600 or $600K ... just curious!

pete dashwood

Oct 5, 2021, 7:05:57 PM10/5/21
Hi Kerry,

For the configuration stated, and without having to write support for
third party controls, I would expect it to cost around $600. That would
be if they outsource it to us. The tools can be purchased or leased
also, so clients can do it themselves, with or without assistance from
us. (We provide good levels of support whether they buy it or not and we
don't let people fail...) Obviously, if they buy the tools and support
from us, it will cost more than $600, but I keep the price to less than
the cost of a COBOL compiler with support from Fujitsu or Micro Soft.

That's the point of the automation... There is very little
labor-intensive work required by us; the tools write the code.

That is not to say there is NO work involved. The client will need to
organize and review COPY Books, and make a migration plan that addresses
the dependencies in their system. We can help with all of this

The most expensive migration we have done so far cost $12K and that was
for a PR1ME system, where we replaced their existing middleware with a
DAL, and they bought the tools to Transform 850 legacy PR1ME COBOL
programs so they could use the new RDB and DAL. There were 3 people
involved and they were all COBOL savvy. They were blown away by the
tools and the whole migration was done in less than 5 weeks.

People have told me that we should inflate our prices because it gives
us more credibility.

I prefer to get credibility through doing a small part of the migration
as a Proof Of Concept. Then it is a matter of record whether our claims
are true or not.

There is also a part of me that doesn't like to see people being
"punished" because they chose to use COBOL for development. People here
will know I have a soft spot for COBOL after writing it since 1967...

There are better solutions today but there should also be migration
paths provided by the vendors and I believe it is shameful that there
are not. The PRIMA toolset has been developed to fill that gap.

Normal COBOL is a pretty easy migration (we need COBOL '85 from ANY
vendor) and it really involves moving off indexed files into Relational
Database. The tools design and create the RDB, generate programs to load
it with the existing indexed (ISAM (PC or mainframe)/mainframe VSAM
KSDS) data, generate the DAL objects, and then transform the existing
programs so that all of the previous indexed access is replaced by
invokes of the DAL. It is a good step forward towards using standard
tools with the database, instead of having to write COBOL every time
someone needs to know something.

But PowerCOBOL involves a GUI interface. It was written by long-gone
contractors for Fujitsu, back in the last century and they did a very
good job. The actual PowerCOBOL development system is really good and
thousands of people around the world used it to create very nice
interactive GUI systems, driven by COBOL. Sadly, there has been no
product from GTS (the current Fujitsu agents in the Western world) that
will bring all the investment in screens and code into the modern

I realized this when I saw that my own PowerCOBOL developments had
nowhere to go and could only be replaced by writing new WinForm screens
from scratch and then trying to salvage the scriptlets in COBOL that
drive them.

The compound file structure used by Fujitsu PowerCOBOL projects makes it
VERY difficult to extract or update information in a PowerCOBOL system
directly. I saw this as a challenge and it took me over 6 months to
crack it... :-) The PRIMA tools manipulate PowerCOBOL project files
without problem.

So, there IS hope for people using PowerCOBOL, it CAN be salvaged and
modernized, and it doesn't cost a punitive arm and a leg.

Kerry Liles

Oct 6, 2021, 12:20:43 PM10/6/21
On 10/5/2021 7:05 PM, pete dashwood wrote:

...original thread snipped
Thanks for the extensive clarification Pete ...
I now understand why $600 was *NOT* a typo :)

NZ dollars? lol

pete dashwood

Oct 8, 2021, 4:31:22 AM10/8/21
No, US... :-)


Oct 8, 2021, 1:02:10 PM10/8/21
It seems very expensive to me! Our ERP developed in Powercobol has dozens of windows (some with very little code, others more complex) and maybe hundreds of files.
It is completely unfeasible, it is much cheaper to develop everything in another language (which is what we are starting to do - in this case in Webdev/Windev).
Thanks for the answer.

pete dashwood

Oct 11, 2021, 6:38:05 PM10/11/21
You asked for an idea of pricing but you never got a quote.
"(Please don't try and extrapolate from these figures; it gets cheaper
as it increases..."

If you had said you have hundreds of Projects and files I would have
given you a fixed price for the tools and shown you how to use them.

The ballpark I gave you was if you outsourced the work to us and did not
buy the tools.

I don't know what hourly rate you pay your people but we can convert
PowerCOBOL sheets in SECONDS...

Unfeasible? https://primacomputing.co.nz/PRIMAMetro/Testimonials.aspx

Never mind.

I wish you every success in your endeavour.

Thanks for enquiring.

pete dashwood

Feb 7, 2022, 8:31:12 PMFeb 7
It was this exchange which prompted me to write the Migration Cost

Background for PowerCOBOL:

The actual Calculator:

It seems strange to me that anyone would consider starting over from
scratch when they have "hundreds" of screens and files.

Sometimes we just do what we want to do... It isn't always logical.

Consider the hours of work to design and build screens in ANY GUI
environment; we can do this in SECONDS. Then look at moving the
scriptlet code into the new environment and wiring the events for the
forms. We can do that in SECONDS, too.

That's just the basics... We can get you a new optimized RDB to replace
your existing indexed files and refactor your existing codebase to
manage the RDB through a DAL...

Try putting your file count and screen count through the Migration
Calculator and you will see a realistic price if you off-load any or all
of these things to us.

Match it against the cost of your manual effort, even at a low hourly rate.

I honestly don't believe it will be cheaper to re-develop from scratch.
Reply all
Reply to author
0 new messages