This is now available from PRIMA.What is the price or terms?
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.What is the price or terms?
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*...
Thanks
On 29/09/2021 01:04, JM wrote:
A quarta-feira, 22 de setembro de 2021 à(s) 08:00:15 UTC+1,It depends on how many PowerCOBOL projects you have, how many sheets are
dash...@enternet.co.nz escreveu:
This is now available from PRIMA.What is the price or terms?
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*...
Thanks
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.
On 10/5/2021 1:04 AM, pete dashwood wrote:Hi Kerry,
On 29/09/2021 01:04, JM wrote:
A quarta-feira, 22 de setembro de 2021 à(s) 08:00:15 UTC+1,It depends on how many PowerCOBOL projects you have, how many sheets
dash...@enternet.co.nz escreveu:
This is now available from PRIMA.What is the price or terms?
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*...
Thanks
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,
Pete, did you mean $600 or $600K ... just curious!
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.
On 10/5/2021 7:05 PM, pete dashwood wrote:No, US... :-)
...original thread snipped
Hi Kerry,
Pete, did you mean $600 or $600K ... just curious!
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 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.What is the price or terms?
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*...
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*...
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:It depends on how many PowerCOBOL projects you have, how many sheets are
This is now available from PRIMA.What is the price or terms?
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*...
Thanks
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 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,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
dash...@enternet.co.nz escreveu:
This is now available from PRIMA.What is the price or terms?
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*...
Thanks
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 234:43:30 |
| Calls: | 6,624 |
| Files: | 12,172 |
| Messages: | 5,319,700 |