On 12/10/2021 11:38, pete dashwood wrote:
> On 9/10/2021 06:02, JM wrote:
>> A terça-feira, 5 de outubro de 2021 à(s) 06:04:58 UTC+1,
>> dash...@enternet.co.nz escreveu:
>>> On 29/09/2021 01:04, JM wrote:
>>>> A quarta-feira, 22 de setembro de 2021 à(s) 08:00:15 UTC+1,
>>>> dash...@enternet.co.nz escreveu:
>>>>> This is now available from PRIMA.
>>>>>
>>>>> RIGHT NOW:
>>>>>
>>>>> 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...>
>>>>>
>>>>> WITHIN DAYS:
>>>>>
>>>>> 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!
>>>>>
>>>>> AND YOU WROTE NO CODE!!
>>>>>
>>>>> 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.
>>>>>
>>>>> https://primacomputing.co.nz/videos/xpcompareHB.mp4
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Pete.
>>>>>
>>>>> --
>>>>> I used to write *COBOL*; now I can do *anything*...
>>>> What is the price or terms?
>>>> Thanks
>>>>
>>> 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.
>>>
>>> Cheers,
>>>
>>> Pete.
>>>
>>> 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.
>>> --
>>> I used to write *COBOL*; now I can do *anything*...
>>
>> 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.
>>
>
> 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.
>
>
>
It was this exchange which prompted me to write the Migration Cost
Calculator.

Background for PowerCOBOL:
https://www.linkedin.com/pulse/cleaning-up-powercobol-prima-computing-nz-ltd/

The actual Calculator:
https://primacomputing.co.nz/PRIMAMetro/MigCalc/MigCalc.aspx

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.

Cheers,

Pete.

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