Thank you all for the comments but I was not clear about my problem description.
My company has already made the decision to convert several COBOL/VSAM legacy systems to COBOL/DB2 after evaluating all their advantages and disadvantages. My job now is estimate how much we have increase the CPU to define the budget.
We have strong experience in DB2 and, through the bold DB2 configuration, reach high DB2 hit ratios, close to 100%; we have very fast DB2 applications with low CPU consumption and therefore we have hesitation in saying that, after conversion, there will be an important CPU consumption growth because with DB2, in function of its greater ability to cache than VSAM, we will certainly have lower CPU consumption of I/O operations since we today have DB2 applications with very low physical read occurrences against high occurrences of VSAM files I/O operations.
The process basically will consist of converting the Cobol/VSAM commands to SQL commands:
– Cobol OPEN <file> will be eliminated
– Cobol CLOSE <file> will be replaced by SQL CLOSE CURSOR
– Cobol START <file> will be replaced by SQL DECLARE / OPEN CURSOR
– Cobol Random READ will be replaced by SQL SELECT/INTO (eg the original question)
– Cobol REWRITE will be replaced by SQL UPDATE
– Cobol WRITE will be replaced by SQL INSERT
– Cobol DELETE will be replaced by SQL DELETE
Well, I hope this clarifies my problem then please help me find some DB2 versus VSAM CPU consumption benchmarking of similar processes.
Thank you very much.
I have the same answer as before. There is no direct comparison.
One is an access method. The other is an RDBMS.
you cannot compare an OPEN VSAM FILE with OPEN DB2 CURSOR. They are not (repeat not) the same thing. The OPEN CURSOR will actually read data and get ready to deliver it to your application. It may access many, many tables in that one cursor; and join the data and filter it and sort it and perform functions on it (e.g. SUM), and transform the data (e.g. CASE), and deliver unto your program something that is not at all equivalent to a VSAM OPEN and READ.
If I even try to compare a VSAM KSDS READ with a DB2 SINGLETON SELECT (which might seem like a valid comparison) and IF the SQL did nothing other than deliver the data (no functions, no joins, no nothing) just a simple SELECT INTO, you then must take the DB2 optimizer into account and update the catalog statistics appropriately. DB2, might read all the data to find a row. Or, it might use an index to go directly to the row. Or it might use part of an index to get to the rows (note plural).
for example, if I want to total some of the records in a VSAM file. I need to read every record into my program, check if it is what i am looking for, if it is add it some counter, go read another record.
to do this in SQL I might have ONE statement like this:
SELECT SUM(some_field) as TOTAL_THESE_ROWS
Now, we know that DB2 must physically read every row. The buffer manager will have to read all the rows, but he will read them asynchronously. And while that is happening, the data manager will make a lot of the decisions to decide if this is a row (record) we want. then and only then will the field we are working with be passed to the RDS (relational data system) to be summed into the total. Once all that work is done the one field called TOTAL_THESE_ROWS will be returned to the application.
There just is no comparison. You cannot compare an access method with an RDBMS.
I truly understand your frustration. But it cannot be done with any hope of getting a meaningful result.
If you are truly replacing VSAM with DB2 and doing it “one to one” then you are maybe trying to use DB2 as an access method. And that is a waste.
For example, in your list of “comparisons” you list VSAM READ with DB2 SELECT followed by VSAM REWERITE with DB2 UPDATE. IN VSAM you gotta read it before your rewrite the changed data. In DB2, you can just UPDATE it. You do not have to read it.
But if you are replacing one VSAM operation with one DB2 operation, then you are trying to use DB2 as an access method.
And it will cost you more with DB2 than with VSAM.
This would not neccessarily be true if you use DB2 as an RDBMS.