> A bit late, but it should be possible to compromise. You need the new data stream to resemble the old, otherwise you basically have to start again from scratch with the whole application.
>
> I believe that you can get the data ordered the way you want/need (or at least the way it is now) by adding an ascending compound index on CO, ACCT, etc. and then setting the start point 10, 1000, etc.
>
> If this is likely to return an enormous dataset, you can break it into smaller packets by reading 100 or so records at a time. This would require an additional loop in the application to load the next set until done, but this is relatively simple (not much work).
> Whether the data is returned from a random SQL query or a stored procedure is irrelevant; it just needs parameters.
>

There are all kinds of possible solutions. Personally I don't think any
of them are as good as using the SELECT statement required to get the
job done. But, the Cobol guys have a point. We can't be spending 10 or
20 hours recrafting each program or we will never finish the
conversion. Something general, that works "well enough" is what we need
to get converted. We can address performance as necessary.

> I too have been a cobol programmer in a previous life, so it is possible to move on. Are they using COBOL.net?
>

I too was a Cobol programmer for many years. It still has its place.
Unfortunately, we have this problem of having to convert old,
non-structured code that was built for ISAM files to something
relational. It is a challenge.

We aren't using Cobol for .Net now but that is the ultimate goal. It
would seem to be the only reasonable way to interface the Cobol to a
database and other non-Cobol applications. We are using RM/Cobol with
embedded SQL for limited access to Firebird database right now. I had
to redo the Cobol bits of gpre to make it work but that isn't really a
viable solution to convert several thousand programs in a relatively
short time span.



[Non-text portions of this message have been removed]