Using I/O subroutines to access DB2 tables

DB2 shops have been debating this one for years.

One problem with using subroutines for all I/O is that you lose DB2's ability to fetch just the column(s) you are interested in. I/O subroutines are usually pretty generic, essentially doing a SELECT * on the requested table. *

Performance geeks will complain about the CPU cost of fetching more columns than you really need. DBAs will complain that you are using DB2 as if it was IMS. And your data modelers, well, they'll just complain, as they always do, that you didn't implement their model properly.

The only one who won't complain will be your project manager, because the I/O routines save you coding time. (Assuming that the poor sap coding the I/O routine isn't working for him too.)

* I once saw an application where an attempt was made to mitigate this problem by requiring the calling program to pass an array of flags, each one corresponding to a column that was to be retrieved. As you can imagine, this bloated the code (no dynamic SQL allowed!) in the I/O subroutine to the point that the cure was worse than the disease.

How long should a process take?

"How long is a piece of string?" may be the flippant answer, but it's not a very useful one.

It is possible to predict, with a fair amount of accuracy, how long a process will take if you know how many records must be processed, what is being done to them, what type of machine it is running on, how many i/o buffers are available etc etc

Or, you can run the input file through DFSORT or other high performance utility.

If DFSORT can process a file in 10 minutes (even if it's not doing exactly the same processing...most business applications are I/O bound) and my Cobol program can do it in 15, then I don't spend much time tuning the Cobol because it is probably about as good as it is going to get.

That is just a rule of thumb of course. Your mileage will vary.