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. 

Blitter kills

The Amiga was an absolutely marvellous  machine. It had so fantastic special hardware for that time. It was incredible. Two of them where Copper and Blitter. A funny trick to hinder the debugger was to set up the Copper to tell Blitter to fill the memory of your running program with 0x00 the next time the cathode ray reaches a specific position. Your program regularly stopped the Copper from doing this. But if you stopped the CPU with a debugger, Copper and Blitter continue there work and killed your programm or other important things.

Borland C's affair with the Amiga

That was a very funny project of mine at that time. The point was that I was very excited about Borlands C-Compiler for the Atari-ST. It produced 68000-Code that was way better than any other Compiler for the Amiga. It didn't produce assembler text files but binary code directly. So the compiler was fast as well. So decided to port it to the Amiga. Well, I had no source code. I converted to compilers Object format, wrote a wrapper that handled the traps used on Atari's GEM and emulated them as needed. I thought the first trap would open the source file. Wrong! The first trap read the system time to initialise __DATE__ and __TIME__ macros.  I patched the routine that produced the object file to produce the symbol table, relocation information and so on in the Amiga format.
After everything was working I went on the next CEBIT to the Borland booth and looked for someone with no tie (you know the techies). I told him what I did and asked him if they would want to sell there compiler to Amiga market. He said "No", because they would have to support it and they didn't want to go into the Amiga market. But they wouldn't bother if I would sell this add-on as long as the original compiler is still needed.
Well, I didn't do that and so it was just used by very few people.

Early warnings

Once upon the time I was browsing through a book which disassembled the Amiga Kickstart-ROM (well I don't remember it's name but it was long before the very nice Amiga Guru-Buch came out). What I saw there, immediately caught my  attention. If the filesystem on a new mounted filesystem had a specific problem it would try to load a program to fix it. The interesting point was, that it first tried to load from that filesystem! If it couldn't find it there it tried the system-partition. Some hours later I had a floppy that upon inserting it into your Amiga immediately showed a very nice custom Guru-Meditation. I showed this floppy to a friend of mine who was astonished as well because the Amiga had no known feature to automatically start a program upon inserting a floppy. It was very hard to keep it from starting it. Luckily viruses where more a theoretic thing at that time. We had copy protection on our mind. It would be very funny to start the game immediately upon inserting the disk.

WX

I just remember that the Motorola 68000 build into the ATARI-ST had a very small cache. It could be used for a funny trick to hinder the debugger. If you just wrote the next instruction with a move the 68000 executes the instruction that was there before. But if you used a debugger you would execute the new instruction. Obviously you had to make sure that no interrupts occurred.