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.

Weak sectors on CDs

Here is a very good explanation of the weak sector problem on CDs:
http://ixbtlabs.com/articles2/magia-chisel/. It is used in some copy protection schemes like SafeDisc. It reminded me of weak data I produced on the C64 where GCR-encoding  was done in software. So you could easily write something that is not well formed. Doing this led to sectors that contained different data every time you read them. Very funny. And confused every copy program I know of.

I love Oracle

I have to admit it. But it was not a love on first sight when I met version 7. But I think that it was more due to fact that it was partly misused in that project for things that should have been done with standard Unix features.
Things I like about Oracle:

• + Multi-version read consistency
• + No limit to the number of locks
• + Always use row locks if useful
• + No lock escalation (row->page->table)
• + Fast startup, even if you have a large uncommitted transaction. I could tell you a funny story about a DB2 doing recovery at start-up for more than 24h.
• + Nice web interface to pinpoint most problems easily. ( Although the old non web Enterprise-Manager was much faster)
• + Very nice tools for developers to find performance problems (statspack, automatic monitoring with awh*, trace-events!)
• + Very good support. Although the first answer is normally kind of a standard question, I always got to the point where they acknowledged the bug and fixed it.
• + They work hard to make it a better product even at the core level.

Some of the things I don't like:

• - AQ is slow as hell. We used AQ heavily in one part of our application with  small messages. When I looked at a statspack report I couldn't believe it. 700 buffer_gets_per_exec on average to fetch a single message!
• - Sometimes it's hard to find out what you have to licence. Although I like the fact that I could try out every feature, I would like to be able to limit it's functionality to just the things that I licensed or plan to license.