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

On Oct 17, 4:20 pm, Rene_Surop <infodynamics...@xxxxxxxxx> wrote:
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?

Reading a 16bit DataFile coming from a 32bit NetExpress Cobol program
could "somehow" read ISAM files directly, but it will MESS UP your
index files during updating/writing (direct IO). It will make you
"think" it is possible.... but disaster will come when updating/
writing the indexed files.

Having done this several times and never having a problem with doing
so I consider your comment to be uninformed.

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.

This is a program code mods. If you have the old conventional PIC 99
(YY) coding, it needs proper monitoring (a lot plus QA/testing)....
especially when interest rates are concerned.

Moving back to your deployment platform, it is very clear to me that
Linux is not the mature enough. As the forum advises, you will end up
searching for "unknown" printer drivers. Might as well focus on
Microsoft OS.

Having had zero problems accessing many different printer types I find
you comment to be uninformed.

Certainly there are 'Winprinters' that are useless, but as these are
designed for casual home use they are of no consequence to business
users.

AJAX in Microfocus NetExpress works well. I am going to let you view
our example (link below) that uses pure ASP/AJAX and Microfocus COM
generated program in the background that handles data input/outputs.

http://infowaters.infodynamicsconsult.com

At first, the COM (Cobol component will load in the background, so you
will notice a delay) will initializes and will execute faster on
succeeding request. You could include your own security afterwards.

Rene


.

Relevant Pages