Migrating legacy COBOL to the .NET framework (Final)
|
Summing up the advantages of our approach...
- Our approach provides the same level of Database that you would get from
an expert Database Administrator.
The table creation tool has years of Relational expertise built into it. The Database you get is normalized and (optionally) optimized. It understands the Relational model and it understands COBOL. You can write your own code to access the new Relational Database (RDB) using embedded SQL (and the Toolset will create the Host Variables you need with its own DECLGEN tool), or you can simply generate the Data Access Layer and run the Transformation tool that will amend your existing codebase to use the DAL objects. The SAME DAL Objects are accessible from any language that implements the Component Object Model (COM) and can run on the Web and/or the Desktop.
- Our approach is affordable.
We can get you migrated for much less than the cost of a new .Net COBOL compiler. There are no
hidden charges or support costs; we give you a price, and we stick to it. We understand small business
and will spread your cost over time to assist your cash flow if you need that. You can
LEASE or BUY our toolset and support service.
We are happy to let you try the Tools for an agreed period or number of runs, but we prefer to
convert some sample flat files for you as a Proof of Concept. Running your own trials really
depends on how many flat files/Legacy COBOL programs you are looking to migrate. The Toolset is powerful
and many sites could easily do their entire requirement as a Demo over a weekend. For this reason, we
provide videos
showing the tools in action.
- Our approach recognizes the paradigm change between procedural COBOL legacy
and modern object oriented environments.
We investigated and analysed how to address this problem for some years, trying various approaches until we
arrived at the current one.
By making the old COBOL "object aware" and providing a data resource that can
be shared between the old and the new, everything can interact as objects. The implications of this are far
reaching and not immediately apparent. This represents a true migration to a new, modern, environment and
opens up many options for the future in terms of what languages future development can take place with.
Migrating in this way ensures that the migrated code is well suited to the new environment and the new object
oriented paradigm that is used by that environment.
- We will work with you and underwrite your migration with our Toolset, to ensure
you succeed.
PRIMA has a very large knowledge base regarding COBOL migration, acquired over decades and numerous successful Migrations. We know about which pitfalls to avoid and how to do so. If you are a programmer, analyst, or technical manager, you should check the full set of pages (4) on RDB and SQL, along with the PRIMA document "The COBOL Pathway to Relational Database" which is linked from those pages, here.
- There is no middleware. You own it!
There is no middleware intercepting calls to your indexed files at run time, neither are there "support"
routines necessary to run your legacy. Your code remains your own and all source code generated by our
tools remains yours as well. The generated code becomes part of your codebase.(We retain intellectual property
rights for the design of it, but you have a non-exclusive licence to distribute, amend, change, or delete, in
whole or in part, components generated by the Toolset.)
We recognise that your code belongs to you and we make no attempt to lock you in to our software. Everything
that our tools write for you, you COULD write yourself, but you could not do it as quickly as a single mouse
click can.
If you would like more information on the PRIMA Migration Toolset (maybe set up a Proof of Concept with us...), please click here...
Some Frequently Asked Questions (FAQs)...
What if my applications are all written in Fujitsu PowerCOBOL?
Support for PowerCOBOL has a big question mark over it. Moving to .NET has to be
an attractive option.
PRIMA has an extension to the Migration Toolset (available separately) for PowerCOBOL migration to .Net.
(Other target environments are also possible... talk to us.) This tool can analyze your existing
PowerCOBOL sheets and create a new Windows Forms project in Visual Studio, that replicates each
PowerCOBOL sheet in the .Net environment. You can modify the new Form (in C#) as if you had created
it yourself.
The tool also extracts ALL of the COBOL scriptlets from the existing sheet and builds a new OO COBOL class
which implements each scriptlet as a method. This class then becomes a "code-behind" for the new Windows
Form. You can maintain the code-behind in COBOL, exactly as you maintained the scriptlets in PowerCOBOL.
The generated code-behind is then scanned for all references to the PowerCOBOL GUI controls (attributes
and methods) and these references are replaced with invokes into a supplied "GUI Support Class" that
provides the equivalent functionality on the new Windows Form. There is NO CHANGE to the scriptlet logic.
Finally, the tool wires up all the events that were used on the PowerCOBOL sheet, to be activated on the
new Windows Form, and the final result is a Windows Form running in .Net with the same functionality
as was provided by the old PowerCOBOL sheet.
For complete details and a free DEMO download, click here.
What about our batch processes?
Batch processes have traditionally served 2 main purposes:
1. Producing reports that need bulk access across the data resource.
2. Applying large volumes of deferred transactional updates to master datasets.
Converting flat files to databases impacts both of the above. Reporting can be achieved by tools other than
COBOL, which are specifically designed for that job. For most Small/Medium Businesses (SMB) the daily volume
of transactions is not so large that it is necessary to spawn "back end" processes from them for
overnight batch running. The network provides for distributed, localized applications, which can complete their
processing very quickly.
Installing Relational Database Management Systems (RDBMS) on modern server hardware supports transactional
processing so well that most transactions (unless they are very poorly designed) complete in real time and
do not need overnight "support processing".
The goal should be to eliminate batch processing and aim to have the data repository reflect a true picture of the business
in real time. For organizations where the batch processing of transactions is unavoidable, at least for now, and it
is necessary to retain some COBOL batch programs, the Toolset automatically converts these to share the RDB.
Can't I just buy a .NET COBOL compiler and recompile all my existing stuff?
It is tempting to think so (and this was my initial thought when faced with moving my own large investment in
COBOL to the .NET environment, many years ago), but this is really non-viable.
The Network needs objects.
It is pointless to move monolithic batch processing type applications into a Framework that is designed to
recognise objects. If you are already using OO COBOL, then it makes good sense to transfer development to the
.NET COBOL environment and invest in a .NET COBOL compiler.
(However, the free OO compilers (Java, C#, VB.Net) are actually more powerful and better for OO development than
even the best OO COBOL compiler for .Net. You can cut maintenance time and cost if you plan to move off COBOL, but
it doesn't have to be done overnight.)
If you are currently not using the OO features of COBOL, you should NOT move to OO COBOL but rather
target a .NET language like C# or VB.Net. These compilers are free. You can refactor and wrap your existing COBOL
WITHOUT the need to buy .NET COBOL.
What if I don't migrate?
You will be tying the future of your business to the future of the
COBOL language.
Certainly, if you move to OO COBOL you can extend COBOL use for a few years yet, but the problem
is not with COBOL, it is the paradigm it is based on. The future is in objects and layers. If you don't
move to this environment you cannot utilise all the fantastic facilities, tools, and objects that are
available to your competitors.
I never heard of PRIMA Computing (NZ). What credibility do you have?
PRIMA was founded by Peter E. C. Dashwood in 1983, in the UK. Pete has been a computer programmer all his working
life (50 years...) and spent around 20 years working on COBOL sites all over the world. He moved
on to consultancy and project management and consulted to major blue-chip companies, mainly in Europe. He is a
well-known figure in COBOL circles and contributes articles and comment to web sites, forums, and magazines.
you can check his profile on LinkedIN, here.
With the advent of networked commercial systems he made the transition from mainframe technology to client/server
in the early 1980s, and PRIMA was originally set up to help mainframe sites understand the "New Technology" and to
promote the networked solution. During his career he has made many contacts, and PRIMA trades information with other
Subject Matter Experts. The company is now based in the Bay of Plenty, New Zealand, but has no difficulty in
servicing world-wide clients; in fact, sometimes the time differences can be advantageous and a solution can
be provided overnight while you are asleep. On site presence can be provided, but is seldom required. Video and email
communication is used frequently.
Overheads are kept low by smart
use of technology, and products and services are kept at prices within the reach of Small/Medium Businesses.
Feedback from clients has been unanimously good and you can see some of it here.
Look around this site and the associated COBOL21 site provided for people dealing with COBOL. It reflects
our approach and our "philosophy".
More about COBOL Modernization and Migration...
