I have long implored others to abandon the use of common blocks for a myriad of reasons. They create a web of interconnections between the routines that use the common block (and which routines, exactly, are those? You can find out by grepping, but it is not immediately obvious). It is not clear at all which routine is responsible for changing the value of some variable stored in a common block. It is easy for the name of a variable intended to be local to clash with the name of a common block variable without realizing it.

But, sometimes, they provide a nice, quick solution for a problem that would otherwise require building a lot of infrastructure. I have been doing various types of profiling of a code recently. After finding the “hot” routines using PROFILER, I have been trying to narrow down to (and quantify the runtime of) the particular lines using up an appreciable amount of time. The problem is that I want the cumulative runtime for the lines over the course of executing many times during a run.

So I created a “profiling” common block with a time variable, initialized at the beginning of the program, which is incremented after the lines run each time. This can be reported at the end of the program. I have been moving the common block around to various routines to get times until I found the “hot” lines within the “hot” routines.

Full disclosure: this is not the only place I have used common blocks. MG_LOG, a routine that I use a lot, has a common block.