Monthly Archives: July 2010

Etowah River Run

Today’s Etowah River Run was a hot and humid affair.  I chuckled as I read the weather report on my Droid near race time.  80 degrees and 87% humidity seemed right, but it was the NWS Heat Advisory that caught my attention: “stay in an air-conditioned room and stay out of direct sunshine.” Seemed as good a time as any to run a 5K!

We got a quick perspective check, though, as backpack-clad 24-hour racers from the nearby Gold Rush 24 Adventure came running by just before the start of the 5K.  We 5K’ers cheered them on heartily: cheers of encouragement, and of celebration that we would be done 50 times sooner.

Yet the course was flat and fast, the race is for a good cause, and it has become quite a tradition around Canton.  Turnout was good in spite of the heat, as this is race gets good participation from local cross-country teams (it falls in the training season, just before Saturday meets begin).  This was the second year that Lydia and I ran it, so we knew what to expect.

The one twist to this course is that the first mile is the fast one, with a long downhill.  This means it takes longer to “thin out” the crowds, and runners don’t fall into position until after mile 1.  A lot of folks let that pull them into too fast a pace and end up paying for it in the last half.  I reminded Lydia beforehand not to do that; she managed her pace well, and was strong at the finish.  And what an exciting finish!

After I was done, I stayed near the finish line and watched for Lydia.  As the timer cleared 27 minutes, I walked over and checked the card baskets.  There was nothing yet in the under 10 girls basket, so I knew if Lydia finished at her usual pace, she could grab a first place age group award.  I soon saw her running in, looking great, in first place!  About 20 yards behind her was a girl about her age gaining on her.  She overtook Lydia, and Lydia kicked into a faster sprint and passed her again.  It went back and forth until they passed the finish line side by side, shoulder to shoulder.  It was a dead tie as far as I can tell.  But, while in the chute, the girl grabbed a place card first, which put her in first and Lydia in second.  Lydia was a bit disappointed, but it was the most exciting finish in the race (yes, I’m a bit biased).

Officially, Lydia placed second at around 29:20.  I ran it in 24:35, and was happy enough to run a sub-8 5K while under a heat advisory.

After Lydia collected her award, we prepared to leave, but she then asked to stay for more door prizes.  Great suggestion!  I had forgotten how good and plentiful the prizes were at this race. Lydia won a $25 Walmart card, and I won a $50 Phidippides card.  And the race T-shirt is a good one.  It’s cotton, not technical, but it’s a nice design and an improvement over previous years.

Overall, it was a great morning, and we’ll run it again next year.  Surely, it will be cooler.

Painted into a Corner

I’ve had such good success with DB2 9.7 LUW under 64-bit Linux that I didn’t hesitate to install it on my new development laptop (Windows XP 32-bit, the corp-rat standard).  I immediately upgraded to Fix Pack 2, of course: never install fix level zero of anything.  I created and loaded a few databases and was on my way.

But it didn’t take long to notice some very bad behaviors.  I saw frequent CPU, memory, and I/O spikes, mostly in db2syscs and db2dasstm. On two occasions, all database operations froze without recovering, and db2syscs suddenly became a diehard: I couldn’t kill it from the Service Control Panel, Task Manager, or even pskill.  Windows shutdown then froze, requiring a hard power off.

This sent me on a fact-finding mission.  First stops: the Windows Event Viewer and db2diag.log.  Since I had not changed diagpath, I had to remind myself that instance information files are no longer under SQLLIB (with Windows, they’re now under Documents and Settings\All Users\Application Data\IBM\DB2). I spotted a huge and growing db2diag.log, at diaglevel 3.  It was flooded with messages like:

 

2010-07-23-13.26.00.052000-240 I82554H352         LEVEL: Error
PID     : 260                  TID  : 536         PROC : db2dasstm.exe
INSTANCE: DB2                  NODE : 000
EDUID   : 536
FUNCTION: DB2 Tools, DB2 administration server, SchedulerThread_run, probe:5
DATA #1 : String, 50 bytes
Cannot complete scheduler thread’s initialization!

 

The db2diag flooding would certainly account for the CPU, I/O, and memory spikes, but I’m not sure about the periodic freezes.  But it’s one thing at a time, and couldn’t stop until I had a clean db2diag.

Fortunately, I found a fellow victim who reported the same issue just yesterday.  The root cause was that the DB2 Admin Server (db2dasstm) did not have required authorities on toolsdb.  This was surprising, since I let db2setup create and configure it.  But I’ve been accustomed to chanting the grant dbadm mantra since the introduction of SECADM, so I typed it out.

But in this case, it wouldn’t work. I couldn’t get into toolsdb with an authorization ID that had SECADM in order to do the grant. I tried stepping into it first via SYSADM/SYSADM_GROUP, but no dice. And toolsdb was unique in that SECADM was only granted to some bogus “SYSTEM” ID.  Thank you, db2setup, for painting me into a corner!

To fix it, I had to drop and re-create the toolsdb, following the proper steps to keep DAS happy.  A couple of db2admin stop/starts later and I had a small and steady diag log.

Time will tell if additional problems remain that contributed to the freeze problem (so far, so good), but I learned an important lesson: never let the DB2 installation program create the toolsdb.

Severe but Curable

On average, over 22,000 children die each day from preventable, hunger-related causes.  This fact that receives so little media attention should be among our most urgent priorities.

Over half of these deaths occur on the African continent, so as the World Cup turned attentions there, I sought answers to why the tragedy of hunger persists so cruelly and what can be done about it.  My reading included Richard Stearns’ The Hole in Our Gospel and Thurow and Kilman’s Enough: Why the World’s Poorest Starve in an Age of Plenty.  Taken together, these provided a well-rounded mix: the heart and perspective of a luxury goods CEO turned children’s champion, and pragmatic detail from on-the-ground Wall Street Journal correspondents.

Structural

Thurow and Kilman describe the structural problems that give rise to African hunger.  Bad policy decisions by governments, the World Bank, USAID, agricultural councils, and other groups lock many African nations into a cycle of dependency.  US crops that are dumped on the world market at heavily-subsidized prices undercut African farmers, driving them out of business.  Insistence on food-only aid exacerbates this problem; for example, during the 2003 Ethiopian famine, international aid trucks drove their loads of US grain past warehouses that were overflowing with the same unsold, unused staples grown by local farmers.  Approachable infrastructure problems lie festering.  More recently, subsidized Ethanol production diverted food to fuel, driving grain prices out of reach of the world’s poor.  As a result, the Green Revolution which decades ago lifted Asia out of hunger and poverty still evades Africa.

Spiritual

Richard Stearns decribes how it’s a spiritual problem.  He reminds us of our scriptural obligations (such as Matthew 25 and Isaiah 58) to provide for the poor and feed the hungry.  A gospel with a hole in it is one that accepts personal salvation but ignores the parables of the Good Samaritan, Lazarus, the Sheep and the Goats, and the 2,100 other Bible passages about caring for the poor.  Stearns describes how that conviction led him to leave a life of luxury and head World Vision.

Attainable

Spiritual and structural.  They’re both right.  And the solutions are well within reach.

Modifying food aid programs to allow local purchase may reduce US farm subsidies, but it will help African farmers become self-sufficient.  Providing African farmers the same financial security measures (such as futures and crop insurance) that farmers in developed nations enjoy will help shoulder their risks and smooth out the boom and bust cycles.  Relatively small investments in infrastructure (dams, irrigation, higher-yield seeds, and road improvements) can dramatically improve farming productivity.  Simple treatments and immunizations can very effectively prevent and confront the crises of malaria, tuberculosis, and AIDS.  Small yet powerful innovations like Plumpy’nut and the KickStart pump can be rapidly deployed.   These proactive and preventative measures are not only affordable, they’re collectively less expensive than remedial aid has been.

Making a Difference

But most of us can’t hop on a plane tomorrow to go build a dam or start a futures exchange in Africa.  So what can we do?  As Mother Theresa has said, “we cannot do great things on this Earth, only small things with great love.”

For some quick encouragement and ideas, read Chapter 10 of Enough.  If you don’t already support World Vision or a similar ministry, sponsor one or more children from their web site.  I’ve seen first-hand the effectiveness of World Vision’s work in the developing world, and I highly recommend them.  And if budgeting is an issue, consider your very prominent position on the Global Rich List; for example, if you make $35,000 annually, you’re richer than 95% of the world.

Global hunger is a large-scale, often overwhelming problem, but that’s no excuse for paralysis or inaction.  It can be solved, one step at a time, one person at a time.

Woodstock Freedom Run

The annual Woodstock Freedom Run is perhaps my favorite 5K, mainly because it benefits The Hope Center.  It certainly helps to have Woodstock charm, a flat course, and gracious weather for July (around 70 degrees at race time).  And it’s always a nice surprise to chat with so many folks that I don’t see often.  It feels like a family reunion.

Lydia won a second-place age group award at 28:09.  Stephen ran very well at 30:06 and was all smiles as he crossed the line, but he’s in the 11-14 group now, competing with 18-minute finishers.  At 25:32, I was certainly no threat to 15-minute defending champ Sammy Nyamongo, but enjoyed the race all the same.

It should return to July 4 next year, so if you’re not running the Peachtree, come out for this one.

Contrast

I happened to notice that an SUnit I added today was number 1,000.  Perhaps I should get free groceries for that milestone, but it reminded me just how much and why we take xUnits and test-driven-development (TDD) for granted.  I was a bit more aware, having spent yesterday working on a customer’s C++ code which had no xUnits or test scaffolding.

It really was a study in contrasts.

For the customer’s C++ code, I found myself fighting in the Visual Studio debugger mostly with overzealous constructors and destructors (folks, just instantiate and delete objects in constructors/destructors, don’t use them for wild stuff like reading registries, calling decryption libraries, and connecting and disconnecting from databases).  But the real hassle was having to run the code-compile-link-bounce-deploy gauntlet far too many times.  Often this isn’t bad (yes, incremental compile and auto build all help), but in this case, it took a lot set-up time getting data in the state it needed to be in before calling this code, and every code change required repeating that.  That’s usually true even of hot swap JVMs.

Compare that to my SUnit-driven VA Smalltalk code.  I wrote the test case and my first stub method before I wrote the code.  I ran the test, and of course, it failed (failed big, too: red, not yellow, due to an expected message not understood exception).  I re-ran the SUnit with Debug, and started filling in the code – in the debugger.  I added methods and even an entire class that didn’t exist before I started debugging.  I inspected objects and ivars and even changed a few to guide me through crafting and whittling at the code.  I ran it again and got to yellow.  One more “code it while debugging it” pass and the test went green.

Red, then yellow, then green.  My favorite development process.

I’ll soon upgrade my Visual Studio 2008 to 2010 and look forward to the new features it offers (thank you, Microsoft for finally bundling ASP .NET MVC, and for abandoning your own JavaScript kluges and just adopting jQuery).  But, decades later, it’s still nowhere near as productive as VA Smalltalk, VisualWorks, and Pharo, where you can write the code in the debugger while the system is still running and never have to stop it.

Why haven’t we learned?