Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express

On Tue, 16 Oct 2007 11:32:09 +1300, "news" <greg@xxxxxxxxxxxxxxx> wrote:

I'm looking for comment on any issues I may encounter in a conversion for
Microsoft COBOL V5 (Which was licenced off Micro Focus) and Version 5 of Net
Express.

Background

I am the owner/operator of the company that owns the copyright to the source
code. I am not a programmer (Although I understand the principals of
programming and suprise myself at what bugs I can fix)
The system is currently a PC Based Financial suite.
There are between 500,000 and a million lines of code (Is that large?)

Yes, that's large.

There are about 100 installations of the 16 bit version of the system.
Companys using it range from NZ$400M turnover to $100K turnover (What New
Zealand would regard as Small to Medim sized businesses)
ISAM data structure.
Current system is 16bit console based, stable and fast.
User Support for the product just won't die (They like it) However
development constraints such as memory issues of staying under 640K and
printing issues are getting more expensive to support.
I have an Evaluation Edition (Time constrained latest full version) of Net
Express and Visual studio 2005 loaded on a Windows 2003 Terminal server.
I have paid for and completed the initial phase of a proof of Concept. One
Module (100,000 lines of code compiled and has produced working executables
but not fully tested)

If you have one program with 100,000 lines of code, you have serious structural problems
that need to be remedied before attempting 3-6 below.

I now have to assess cost of several logical phases. i.e. assess the min and
max cost possible for each phase - This is where any issues I need to
consider would be valuable, I can't research what I don't know.
On completion of this analysis I will go out to the Userbase with an
indication of costs they will need to absorb.(several key players in this
group have been informed of this process) If I get support, the conversion
will go ahead, if not, I will create a strategy to exit the market.

Phases

1. Straight conversion to a 32bit console version of the system. Possible
consolidation of executables. No improvements. Users having memory issues
would no longer get these symptoms.

Very easy. It's just a recompilation. You don't need phases.

Converting data files is just a reorg. You don't need to change data elements in your
records.

2. Write a module to replace ASSIGN PRINTER to handle printed output.

Many printer drivers that can do what you want without changing source code.

3. Refactor programs to reasonable size, one function per callable program. Separate user
interface from application logic.

7. Port to a relational database (Probably Postgres) for easier 3rd
party reporting.

I would make this 4. First, move file IO into data layers. Second, design the database ..
properly (normalized), NOT one table per indexed file. Third, rewrite data layers to read
the database and return 'logical views' matching indexed files one for one.

Having done 1, 3 and 4, you have a foundation to build on.

3. Write a web interface using Net Express and hopefully AJAX to replace
the screen I/O of the current version. Duplication of look and feel of
exsisting interface envisagaged. Compile as a .Net application.

Easier than you think .. AFTER user interface is separated from business logic.

4. Port to Linux using MONO (.NET framework for Linux)

Why? Unix GUI isn't as good as Windows.

5. Revisit the user interface (3.) altering bigger sections of underlying
business logic to enable us to produce a "prettier" more flexible interface.
Possible conversion of some code to Object orientated code.

People will tell you to do the user interface with Java oriented tools

6. Alter Code to handle security for system to run as a web application
in a bureau environment.5. & 6. may occur simultaneously.

Do it yourself security is almost always third rate. Security should be outside
application code, primarily in the database. That's one reason why you first need a
database.

Progammer Strategy

1. Devide the tasks into managable portions.
2. Clearly define deliverables for each portion.
3. Go to Global tender for each Task using probably using outsourcing
websites (payment on deliverables or agreed milestones).
4. Coding done using my Terminal server.
5. Manage coding pactice, the meeting of timeframes, quality of
deliverables, documentation practices etc, using VoIP, video conferencing,
and remote control of RDP sessions, personally.

You overlooked testing, which will be more expensive than coding. You overlooked design,
as well.

Anyone interested at this level is welcome to make contact. Please be aware
that without support of the userbase that this project will be all over
within the next 6-8weeks as I won't have justified the purchase of the
development tools.

Show them mockups of pretty GUI screens with searchable lists and reports as spreadsheets.
They'll fall in love.

.