It must be nice to be one of you folks who work on one of those projects where you can just use your brain to understand all the relationships among data structures and various pieces of code or where you can make sure that you only ever work on code where you can be sure that it's structured cleanly with nice small functions that can be tested individually.
Out here on the wild frontier we're stuck working on code that was written many many years ago by people who weren't quite so clever as the average slashdot poster. These people left behind badly structured code with inelegant data structures and comments that don't accurately describe how the code works. This code consists of several tens of thousands of lines in the component I'm directly involved with and several hundreds of thousands of lines in the larger project.
So while it sure would be swell if all the functions were small, the data structures elegant, the code tidy, and the comments accurate, that's just not the way it is for many of us.
And it pains me to say, but much of the debugging we do is done using printf() because most debuggers are such unredeemable sacks of $#!].
I do much of my debugging using msdev from VC++ v6, and I find it to be even less useful than the CodeView debugger that I used in 1987. There's a few things that are better but there are a lot of things that are worse. How can I get msdev v6 to show some of my variables in hex and some in decimal? Is this such an esoteric request that the developers at MS couldn't be expected to anticipate it?
The number of things that the MS debugger can't do that I could do in 1992 using IBM's VisualAge C++ debugger is even longer. Is this progress?
why can't we have dynamically re-sizing log files?
That is probably coming in the future. The reason logs are capped at 4G (or 32G, depending on the version you're running) is likely because back when DB2 was designed, disks were small and expensive and admins would want a way to limit the amount of disk space consumed by the logs. In any case, if you have a transaction that has not completed in the time it takes for 32G worth of other transactions to occur, you may have a design flaw with your application.
it's too easy to get into a state of questionable integrity, at which point DB2 stops. Just run a LOAD statement and leave out the word 'UNRECOVERABLE' - bam! Tablespace is in backup pending state and you can't access the data.
That behaviour is there to preserve data integrity. Loads aren't logged, so you will have to create a backup image that contains your loaded data. Either specify COPY YES on the LOAD command so you'll get a load image that can be applied at rollforward time, or back up the tablespace you loaded data into. Otherwise you will end up with data that can't be recovered in the event of a disk crash/building burning down/etc.
On-line backups have only just been added to the Unix version of DB2
Online backups have been in DB2 for years. Perhaps you mean to say "incremental backups"?
Slashdot Mirror
It must be nice to be one of you folks who work on one of those projects where you can just use your brain to understand all the relationships among data structures and various pieces of code or where you can make sure that you only ever work on code where you can be sure that it's structured cleanly with nice small functions that can be tested individually.
Out here on the wild frontier we're stuck working on code that was written many many years ago by people who weren't quite so clever as the average slashdot poster. These people left behind badly structured code with inelegant data structures and comments that don't accurately describe how the code works. This code consists of several tens of thousands of lines in the component I'm directly involved with and several hundreds of thousands of lines in the larger project.
So while it sure would be swell if all the functions were small, the data structures elegant, the code tidy, and the comments accurate, that's just not the way it is for many of us.
And it pains me to say, but much of the debugging we do is done using printf() because most debuggers are such unredeemable sacks of $#!].
I do much of my debugging using msdev from VC++ v6, and I find it to be even less useful than the CodeView debugger that I used in 1987. There's a few things that are better but there are a lot of things that are worse. How can I get msdev v6 to show some of my variables in hex and some in decimal? Is this such an esoteric request that the developers at MS couldn't be expected to anticipate it?
The number of things that the MS debugger can't do that I could do in 1992 using IBM's VisualAge C++ debugger is even longer. Is this progress?
So if you play a DVD of This Is Spinal Tap on it, will the Stonehenge monument come out to be the right size?
IBM *did* post a Linux score. What do you think this entire thread is about?
That is probably coming in the future. The reason logs are capped at 4G (or 32G, depending on the version you're running) is likely because back when DB2 was designed, disks were small and expensive and admins would want a way to limit the amount of disk space consumed by the logs. In any case, if you have a transaction that has not completed in the time it takes for 32G worth of other transactions to occur, you may have a design flaw with your application.
it's too easy to get into a state of questionable integrity, at which point DB2 stops. Just run a LOAD statement and leave out the word 'UNRECOVERABLE' - bam! Tablespace is in backup pending state and you can't access the data.
That behaviour is there to preserve data integrity. Loads aren't logged, so you will have to create a backup image that contains your loaded data. Either specify COPY YES on the LOAD command so you'll get a load image that can be applied at rollforward time, or back up the tablespace you loaded data into. Otherwise you will end up with data that can't be recovered in the event of a disk crash/building burning down/etc.
On-line backups have only just been added to the Unix version of DB2
Online backups have been in DB2 for years. Perhaps you mean to say "incremental backups"?