Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express
- From: "news" <greg@xxxxxxxxxxxxxxx>
- Date: Tue, 16 Oct 2007 23:09:26 +1300
"Robert" <no@xxxxxx> wrote in message
news:7hh8h358vkj137oeocabhvd5ausrqp2kgj@xxxxxxxxxx
On Tue, 16 Oct 2007 11:32:09 +1300, "news" <greg@xxxxxxxxxxxxxxx> wrote:Hmmm, thats what I Thought. I guess 20 odd years of coding makes for a bit
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.
of a mammoth conversion task.
The suite is made up of over 200 executables which draw on over 600 copybook
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
files for reusable code.
I'm hoping a complete restructure isn't in order or this project won't fly.
My goal is if it prints from windows it also prints from my programs.
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.
However as I want to port it to linux it will have to take this into account
in design.
See above this may already be the case.
3. Refactor programs to reasonable size, one function per callable
program. Separate user
interface from application logic.
Possibly, but I need the users to get something in a timely fashion with a
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.
low risk of introducing bugs. This strategy would seemingly suck a lot of
cash on testing before I could get the new code generating any new revenue.
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.
Because Linux has a big chunk of the server market. E-commerce is expanding,
If I can provide the reliabilty and stability of a COBOL based financial
system for e-commerce systems to write to directly I believe there will be a
market for it.I can provide poit of sale through to Balance Sheet on one box
with one core business logic.
I don't ever intend to design a non-webform version of this software. I
intend to leapfrog that technology and never offer it to the market at all.
As far as I'm aware, the browsers available for linux are in many ways
superior to those in windows, particularly in security. At the end of the
day whilst everyone likes "Pretty" most serious business people will opt for
solid and functional when trusting their financial transactions to a
computer system.
AJAX is a java orientated tool. I'm yet to figure if I can get it to work
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
with Net Express
This step was not necessarily to be coded using COBOL. My thoughts were more
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.
based around Linux and is ability to secure the ISAM data files as part of
the registration process of signing up to the web service. This may or may
not be done via COBOL. The code I envisaged would simply look to a different
directory for the datafiles depending on which user was logged in.
Typically I do that bit and pay myself stuff all. :(
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.
They are so used to the console interface that many have threatened me with
death if I change it. :)
We are talking of Java enabled Cellphones sending XML data to the linux
server (I mentioned earlier) to load Payroll transactions and automated SMS
messaging from that server to communicate job locations and descriptions
organising casual remote workers. That seemingly has them excited if not in
love! Can't really be done without new tools!
Thanks for taking the time to reply you have given me a bit more to think
about.
.
- Follow-Ups:
- References:
- Prev by Date: Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express
- Next by Date: Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express
- Previous by thread: Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express
- Next by thread: Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express
- Index(es):
Relevant Pages
|
