Stategy for (Large?) 16bit COBOL code conversion to Net Express
- From: "news" <greg@xxxxxxxxxxxxxxx>
- Date: Tue, 16 Oct 2007 11:32:09 +1300
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?)
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)
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.
2. Write a module to replace ASSIGN PRINTER to handle printed output.
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.
4. Port to Linux using MONO (.NET framework for Linux)
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.
6. Alter Code to handle security for system to run as a web application
in a bureau environment.5. & 6. may occur simultaneously.
7. Port to a relational database (Probably Postgres) for easier 3rd
party reporting.
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.
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.
Comment to help me assess if the project is indeed feasible would be greatly
appreciated.
Thanks in Advance.
Greg
.
- Follow-Ups:
- Prev by Date: Re: netcobol question
- Next by Date: Re: Do you have a Knowledge Officer?
- Previous by thread: Value of being smart was Re: Iraq
- Next by thread: Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express
- Index(es):
Relevant Pages
|
