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*...

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

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*...

On 10/5/2021 1:04 AM, pete dashwood wrote:
> 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.
>

Pete, did you mean $600 or $600K ... just curious!

On 6/10/2021 05:09, Kerry Liles wrote:
> On 10/5/2021 1:04 AM, pete dashwood wrote:
>> 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.
>>
>
> Pete, did you mean $600 or $600K ... just curious!
Hi Kerry,

On 10/5/2021 7:05 PM, pete dashwood wrote:

....original thread snipped

>>
>> Pete, did you mean $600 or $600K ... just curious!
> 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
> environment.
>
> 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.
>
> Cheers,
>
> Pete.
>

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

NZ dollars? lol

On 7/10/2021 05:20, Kerry Liles wrote:
> On 10/5/2021 7:05 PM, pete dashwood wrote:
>
> ...original thread snipped
>
>>>
>>> Pete, did you mean $600 or $600K ... just curious!
>> 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
>> environment.
>>
>> 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.
>>
>> Cheers,
>>
>> Pete.
>>
>
> Thanks for the extensive clarification Pete ...
> I now understand why $600 was *NOT* a typo :)
>
> NZ dollars?  lol
No, US... :-)

Pete.

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

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*...

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.
>

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.