Coding Around the Problem

mainframe codeLate last year, I was working on a piece of code that was quite troublesome: I had a variable that was changing its value for absolutely no reason! I spent two days trying to explain how that value could possibly be changing, and got nowhere. The worst part: the program in question touched every record in the database when it ran, and if the value changed during the running of the program, records got orphaned.

The code in question started off as a mainframe application, but now it was C# code running against a SQL database and THERE’S NO WAY THAT VARIABLE CAN CHANGE. However, the vendor who built the ORM used unsafe pointers and GOTOs, so who knows… The other scary part is that the intended purpose of the program was to alter record keys, which is why it had to iterate over all of the tables in the database. For whatever reason, the value would reset to its original value after having updated about 20% of the tables and orphan all related table records from that point on. Needless to say that our customer was not thrilled with the outcome of the program since it hosed their data.

After bashing my head against a desk for several more days, I talked to the senior project manager about it. Having been a coder himself at one point and considering his generally “out of the box” thinking, he says to me “Why don’t you store the value in another variable, then when you get to the part of the program where the value changes, set it back to what it was supposed to be.” I said, “THAT’S CRAZY!” Well, I tried it and it worked. In the end, we ended up blocking the program so that people weren’t changing database keys to begin with, which is probably for the best. However, it was an interesting experience in programming the right way, getting the job done, and knowing when to change course.