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.