I hate server migrations

Some time ago, the backend Unix server had to be upgraded from 32-bit to 64-bit architecture. All the C and C++ programs had to be recompiled and tested. What were the changes specifically targeted at?

The ints and the longs.

The programs were connecting to the Sybase database using some of the Sybase libraries. And some of the libraries were obsolete, requiring more changes. Specifically, stuff about DBINT and CS_INT (used for binding database values to program variables). I’m not going to talk about the technical details of the migration.

The point is that the programs were written with DBINTs in mind. Then a creative programmer some time in the past decided to use CS_INT instead of DBINT, thus creating a dissonance in the system of programs. The creativity was splattered here and there, and there lies the difficulty.

The migration changes typically involved casting or changing an int variable to a long variable. Due to the, uhm, lazy incompetence of the programmers of yore, the programs were written in lax mode. Meaning all sorts of compilation errors were allowed to pass by the then lenient 32-bit compiler.

The new 64-bit compiler, however, would have none of that. It threw out a long list of errors that would have choked the printer were it to be printed. Suddenly, function declarations, strict type casting and the like were back in fashion.

In particular, the libraries supporting CS_INT were no longer available or not supported. I had to translate CS_INT to DBINT for the programs, in addition to the compilation errors. If there was ever a time for being consistently wrong, this was it.

If all the programs were using DBINT, the changes might be many, but they’d be similar. When some of the programs used DBINT, and others used CS_INT, I had to deal with two sets of error corrections. And both types of casting errors needed to be dealt with differently.

Sometimes, tedium is better than frustration. I’m just glad that was over.