Fun with Pro*Cob

When we moved a very large Cobol application from MVS and DB2 to Solaris and Oracle, the question was what to do with all Cobol-code that checked the SQL-Codes. In our case the programmers didn't use a copybook with all the constants they neeeded. Most of the time the codes where there numerically. Sometimes SQLCODE got stored in other variables, and checked later. As you might already know, I don't fear patching things. So I decided to look at the code generated by procob. That looked very good. All I had to do was adding a call to a C function after every call to SQLBEX. In that function I saved SQLCODE to ORA-SQLCODE and put the mapped DB2-Code into SQLCODE. As I was on it, I enhanced it a bit more. I printed a stack-trace if there was an "unusual" SQLCODE. In case of a rollback I printed the last 20 statements. I also added a call to a C function before SQLBEX to save a hires timestamp. That way I could count the calls and time used of every server call (sql open, fetch, ...). Using an atexit handler I could walk through a list of all used SQL statements and log every statement (source file name and line number in the file before procob ran) that took more than 1% of the runtime of the program ordered by used time. So if someone comes up with "this and that job went very slow last night" I could easily see which statement produced the problem by looking at the last view lines of the log. That was a real killer feature.