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

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-8ws 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

I've done Microfocus Cobol conversion and I knew certain issues.

To top it all, you have to focus mainly on "DataFile Conversion" from
16bit to 32bit. 16bit generated Cobol files ARE NOT compatible with
your NetExpress V5.00. So what you'll going to do is basically (a)
create a program based on your 16bit Cobol compiler and read ALL Cobol
datafiles into a flatfile and (b) create a program based on your
NetExpress V5.00 or 32bit Cobol compiler and read the flatfiles back/
write this time to 32bit datafiles.

As long as you have your file structure (or COPY files) intact, then
it will be no problem in data conversion. Concerning Cobol program
codes, nothing much is changed. Once your data conversion is done, you
could play with it using your "new" compiled 32bit Cobol programs. You
would probably need some compiler directives but for sure it would
only consist of at least 10% of the Cobol code change workload.

90% goes to DataFile Conversions.

Best of luck!

Rene

On Tue, 16 Oct 2007 11:32:09 +1300, "news" <greg@primesoft.co.nz> 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 Ne
t
>Express.
>
>Background
>
>I am the owner/operator of the company that owns the copyright to the sourc
e
>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 structu
ral 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 an
d
>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. Possibl
e
>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 element
s 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 th
e database ..
properly (normalized), NOT one table per indexed file. Third, rewrite data l
ayers 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 log
ic.

>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 underlyin
g
>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 outs
ide
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 overlo
oked 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-8ws 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.

Thanks Rene

I converted the first module and it seems to read and write to some test
ISAM files produced by the 16bit version. What symptoms of failure am I
likely to get?

We did a similar process to what you describe when we added the century to
dates when the year 2000 clicked over. If we have to I guess we can do it
again but I'd prefer not to.

Regards
Greg


"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1192499904.272716.5990@v23g2000prn.googlegroups.com...
> I've done Microfocus Cobol conversion and I knew certain issues.
>
> To top it all, you have to focus mainly on "DataFile Conversion" from
> 16bit to 32bit. 16bit generated Cobol files ARE NOT compatible with
> your NetExpress V5.00. So what you'll going to do is basically (a)
> create a program based on your 16bit Cobol compiler and read ALL Cobol
> datafiles into a flatfile and (b) create a program based on your
> NetExpress V5.00 or 32bit Cobol compiler and read the flatfiles back/
> write this time to 32bit datafiles.
>
> As long as you have your file structure (or COPY files) intact, then
> it will be no problem in data conversion. Concerning Cobol program
> codes, nothing much is changed. Once your data conversion is done, you
> could play with it using your "new" compiled 32bit Cobol programs. You
> would probably need some compiler directives but for sure it would
> only consist of at least 10% of the Cobol code change workload.
>
> 90% goes to DataFile Conversions.
>
> Best of luck!
>
> Rene
>

"Robert" <no@e.mail> wrote in message
 news:7hh8h358vkj137oeocabhvd5ausrqp2kgj@
4ax.com...
> On Tue, 16 Oct 2007 11:32:09 +1300, "news" <greg@primesoft.co.nz> wrote:
> 
>
> Yes, that's large.
Hmmm, thats what I Thought. I guess 20 odd years of coding makes for a bit
of a mammoth conversion task.
> 
>
> 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
The suite is made up of over 200 executables which draw on over 600 copybook
files for reusable code.
I'm hoping a complete restructure isn't in order or this project won't fly.
> 
>
> 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.
> 
>
> Many printer drivers that can do what you want without changing source
> code.
My goal is if it prints from windows it also prints from my programs.
However as I want to port it to linux it will have to take this into account
in design.
>
> 3. Refactor programs to reasonable size, one function per callable
> program. Separate user
> interface from application logic.
See above this may already be the case.
> 
>
> 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.
> 
Possibly, but I need the users to get something in a timely fashion with a
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.
> 
>
> 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.

> 
>
> People will tell you to do the user interface with Java oriented tools
AJAX is a java orientated tool. I'm yet to figure if I can get it to work
with Net Express
> 
>
> 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.
This step was not necessarily to be coded using COBOL. My thoughts were more
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.
> 
>
> You overlooked testing, which will be more expensive than coding. You
> overlooked design,
> as well.
Typically I do that bit and pay myself stuff all. :(
> 
>
> 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.
>

news wrote:
> Thanks Rene
>
> I converted the first module and it seems to read and write to some
> test ISAM files produced by the 16bit version. What symptoms of
> failure am I likely to get?
>
> We did a similar process to what you describe when we added the
> century to dates when the year 2000 clicked over. If we have to I
> guess we can do it again but I'd prefer not to.
>

I don't know what symptoms of failure you're likely to get, but I bet
there'll be some. At a minimum, the 32-bit version won't be able to use all
it's nifty internal stuff against an older rendition. For example, our
32-bit ISAM creates SMALLER files than the flat file used in its creation!

We had to do the same thing: 16-bit ISAM files (Realia) to a 32-bit system
(Fujitsu). We couldn't read the input files directly, so we had to go
ISAM-FLAT-ISAM. The conversion was trivial.

news wrote: 
> My goal is if it prints from windows it also prints from my programs.
> However as I want to port it to linux it will have to take this into
> account in design.

Good God, why? One of the benefits of moving to Windows was many of our
compatibilty problems disappeared. We no longer care what kind of printer or
modem or whatever is connected; we build a print line and hand it to Windows
to sort out.

Linux has about 1/100 of the drivers for hardware that Windows has. Hardware
vendors often don't even bother with Linux drivers.

Users don't want to have to hire a 17-year old computer nerd to keep their
system running. If you try to peddle a commercial system based on Linux, you
automatically double the amount of service calls you can expect to receive.

If you want to piss around for your own enjoyment fiddling with Linux,
that's okay. But if you try to inflict Linux on a user, you're doomed.
DOOMED, I say.

(The fact that I own a wheelbarrow full of Micros~1 stock has no bearing on
this assessment.)


 
> Possibly, but I need the users to get something in a timely fashion
> with a 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. 
>
> 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.

Nonsense. Linux does have a recognizable share of the server market and will
continue to grow. Right now, it's about 25% (according to PC w), but
that's a smallish minority of the server market. Might as well be writing
code for the Macintosh.

In my view, betting the company on Open Sores operating systems is an
unnecessary gamble.


Other thoughts:

1. Moving to a GUI system will probably throw a big twist in the way you
design your programs. Some programs will be junked entirely and re-written
from scratch. This is because many things are SO much easier in Windows,
you'll say "I gotta have me some of that!" Perhaps many existing modules
dealing with various hunks of hardware (printers, modems, scanners, etc.)
will be scrapped because all those functions are now the responsibility of
the OS.

2. You'll find that calling on the OS to perform many tasks is a godsend.
Giant sections of exiting code will be tossed in the can and replaced with
one call to an API.

3. The logic of your programs will change. Many events will be occuring
simultaneously (updating a file, mouse movements, button pushes...) all
coming in at random times and you'll have to re-think your logic from
sequential processing to event-driven control. Once you get past the
barrier, it's automatic, BUT a straight sequential processing stream can get
terribly  when the user taps the "Pause" button.

4. The features you can offer will increase dramatically. One example: In
our system, a clerk records a special order for a customer. This special
order percolates through the system and eventually a box arrives from the
vendor. As the employee is checking in the shipment, the system
automatically sends an email to the original customer telling him his order
has arrived! Sending an email via DOS would be like pulling teeth; in
Windows, it's trivial.

You will need a programmer versed in Visual Basic. You will need to re-learn
installation tools for your software. You will have to shop for Active-X
add-in controls.

It won't be easy, but what's art without suffering.

HeyBub <heybubNOSPAM@gmail.com> wrote in message
news:13h9c4vc165qvc2@news.supernews.com...

>
> 3. The logic of your programs will change. Many events will be occuring
> simultaneously (updating a file, mouse movements, button pushes...) all
> coming in at random times and you'll have to re-think your logic from
> sequential processing to event-driven control. Once you get past the
> barrier, it's automatic, BUT a straight sequential processing stream can
get
> terribly  when the user taps the "Pause" button.
>


You know, this is something of a programming "urban myth".  Event-oriented
programming isn't something absolutely and "if-and-only-if" associated with
GUI programming.  If "News"'s systems are screen-driven then he's doing
event-oriented (EO) already.   Even if you have only the display & accept
verbs available you can do a crude rendition of EO.  All that's needed is to
write your program so as to assume something independent to handle the
screen-io functions (which all modern Cobol implementations provide); pass
on a message or a screen to the handler, set switches so you know where you
were and what you were doing in the program, then wait for something to come
back.  Your programming action will then depend on what you get and what
switches were set.  You certainly CAN program so as to have events happen in
a strict sequence in this environment - but so can you in any GUI
environment.

As well, many of the possible actions a user may take concern the screen but
not the underlying program.  I've yet to come across a situation where the
underlying program has to know about the window being resized or moved, for
instance; or about the mouse being moved.  That's the business of the screen
handler.  All the program needs to worry is about the data that gets sent to
it (including button pushes or scrolling selections or whatever).

I've been doing this sort of programming for eons.  Older followers of this
group that worked with Univac gear may remember TMS that ran on OS/4.  That
certainly qualified as EO - character-oriented green screens and 2400 baud
lines and all!

So: the PAUSE button: please give me an example of its use in a data-entry
screen!

Cheers
PL

Check the FILE-TYPE and INXFORMAT directives.  Micro Focus provides upward
compatibility for all index file types - back to Level II (1980's compiler).
Although the "default" and the "most efficient" may (or may not) be the same
from the 16-bit Microsoft Product to the current 32-bit Micro Focus product,
 MF
certainly DOES provide compatibility - if that is your goal.

FYI, in the online documentation there is a LONG list of all the directives 
that
can impact file-handling.

--
Bill Klein
wmklein <at> ix.netcom.com
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:13h9a2emejja115@news.supernews.com...
> news wrote: 
>
> I don't know what symptoms of failure you're likely to get, but I bet ther
e'll
> be some. At a minimum, the 32-bit version won't be able to use all it's ni
fty
> internal stuff against an older rendition. For example, our 32-bit ISAM
> creates SMALLER files than the flat file used in its creation!
>
> We had to do the same thing: 16-bit ISAM files (Realia) to a 32-bit system
> (Fujitsu). We couldn't read the input files directly, so we had to go
> ISAM-FLAT-ISAM. The conversion was trivial.
>

tlmfru wrote:
> HeyBub <heybubNOSPAM@gmail.com> wrote in message
> news:13h9c4vc165qvc2@news.supernews.com...
> 
>
>
> You know, this is something of a programming "urban myth".
> Event-oriented programming isn't something absolutely and
> "if-and-only-if" associated with GUI programming.  If "News"'s
> systems are screen-driven then he's doing event-oriented (EO)
> already.   Even if you have only the display & accept verbs available
> you can do a crude rendition of EO.  All that's needed is to write
> your program so as to assume something independent to handle the
> screen-io functions (which all modern Cobol implementations provide);
> pass on a message or a screen to the handler, set switches so you
> know where you were and what you were doing in the program, then wait
> for something to come back.  Your programming action will then depend
> on what you get and what switches were set.  You certainly CAN
> program so as to have events happen in a strict sequence in this
> environment - but so can you in any GUI environment.
>
> As well, many of the possible actions a user may take concern the
> screen but not the underlying program.  I've yet to come across a
> situation where the underlying program has to know about the window
> being resized or moved, for instance; or about the mouse being moved.
> That's the business of the screen handler.  All the program needs to
> worry is about the data that gets sent to it (including button pushes
> or scrolling selections or whatever).
>
> I've been doing this sort of programming for eons.  Older followers
> of this group that worked with Univac gear may remember TMS that ran
> on OS/4.  That certainly qualified as EO - character-oriented green
> screens and 2400 baud lines and all!
>
> So: the PAUSE button: please give me an example of its use in a
> data-entry screen!

It's not an urban myth. It's not even a programming myth. In a screen full
of controls, when one is selected, that's an "event." Another event may be
selected that modifies the first event.

Say:
Exiting a field triggers data evaluation logic. Meanwhile, the cursor
proceeds to the next field. The data validation logic on the first field
detects and error and informs the user. After the user acknowledges the
error condition, focus is returned to the first field. This triggers a lost
focus event on the second field which triggers the data validation logic for
the second field and so on...

Unless the programmer knows how these events are being aligned, much hair
will be pulled.

There's dozens of these "gotchas" that batch programmers, even CICS
programmers, are not familiar with.

As to an example of PAUSE being used in a data-entry screen, how about a
look-up feature that finds millions of records?