Self-Discovery
No, Boomer, we're not finding ourselves again. But we do need to find our software. And our files. Especially the files that are more sensitive or critical. But also, importantly, the software.
Yeah, it's running, maybe it's even running just fine, but what's running? If we dare remove even one program will the whole fragile house of cards flutter to the ground in a useless two-dimensional pile? To avoid that fate, we carefully follow a few strands of spaghetti through their Gordian Knot, to little accomplishment. The whole thing, we decide, is best left alone like Fibber McGees's closet. (For the non-Boomers, Fibber McGee and Molly , was a mid-20th century radio show. The closet was always a total mess, known to produce a noisy avalanche when opened.)
Fear is a huge deterrent to progress. It stifles the urge to improve or, heaven forfend, to clean up our software and databases. Rooting around in the system is akin, it seems, to looking under the bed. If you never look, you can pretend there is no monster there.
Except, this analogy of closets and monsters loses its appeal when you consider that the success of the company, its competitive edge and sustainable growth, depend on the forward-going adoption of new technology. We're going to have to grab that boogeyman by the throat and harness it up to new gadgets and ideas. We do get away, for a time, by poking something in blindly and holding our ears. But if we can't see the beast, much less control it, we all know what ends up happening. Someone says, "Oh well. Let's just get something new." The company loses time, money and momentum. People lose their jobs. Often enough the whole effort fails and back we are, still dealing with the amorphous blob and now an angry upper management.
Most of us who might find ourselves on this page know that there is nothing stodgy about our Pick-like system itself. There's no newfangled gizmo we can't accommodate. Our software has been agile before it was a thing. In fact, many innovations come out of our talent pool. So, where does this idea of old, inflexible software come from?
It isn't the platform that has the problem. It's not our fault. It's our applications.
Many of our business applications were written when the whole idea of business applications was very new. There wasn't an older generation to guide us, there wasn't a lot of information about structure and efficiency. We were breaking new ground. And, ironically, the more successful our application has been, the longer it has been around, the more chefs have been in the kitchen, so the bigger mess. (Now that we're out of the closet and into the kitchen.)
So here we are and if we want to stick around, we better bolster the infrastructure so that it can hold up under the pressure of new demands. To do that, we must map out where the software is located, what's running and what's not and where the data is located and which is more sensitive in nature.
Nobody is going to convince you this could be an easy project. Or entirely automated. It's a time intensive, high concentration endeavor. But there are approaches that can be systematized and functions that can be tooled. The results are important. Let's talk about how it can be done.
First, we must know the underlying structure. This may mean that our software was written in an old 4GL that may or (mostly) may not still be around and supported. But even if it is not supported or actively marketed, there are structural standards that are documented and, at least relatively, consistent. If you have the old manuals, yes, start there. Pick through them for the structural underpinnings. Build yourself a chart of the standards and practices that were first adhered to. If you can't find the manual or can't stand reading it, reach out for other companies whose software had the same genesis as yours. Maybe you can share resources, divide and conquer a bit. There are a few of us old birds that have run into all of them and know a lot of things and a lot of people. (Yes, that's an invitation — if I can help connect people for this; I'm here for it.)
The absolute day zero thing to do, if you haven't already, is build a "little program" that logs program use and insert it as a called subroutine into ever blasted piece of software you can find on your system. This is a two part project. 1) write this little program (and test it within an inch of its life, it's going everywhere it better be harmless!) and 2) find all the places to put it. This project happens first and then it's busy collecting information for you while you go on to other things. Think of it like the step in a recipe where you place the sauce ingredients together and let them simmer while you chop the vegetables. Fruit, really. The low-hanging fruit. Find all the programs in a file called any prefix or affix to BP, PROGS, PROGRAMS, whatever. You can also look for any files that have compiled items. These will begin with underscore in the program names inside the file (Unidata) or will be in a corresponding .O suffix of the same file name (Universe).
- Write the subroutine that logs when this program ran,
- Write a program to stuff the subroutine call into all of your programs.
- Find all the programs and
- do it.
You may also have Procs or Paragraphs in the system, too. These will be items with PA, PQ, or PQN on line one. You may have control files or perhaps software files for your software development tools such as the XXPROCESS file in SB+. You can write a crawler program that digs around your system for these ideas. Then of course use human verification.
What does that program that you are calling from everywhere look like? It could go lots of ways — here's a very simple one:
Disclaimer: Programs are a very basic suggestion, use at your own risk. Better yet, write your own. [ Figure 1 ]
You could certainly log more information like who ran it last, but all we really need to know is that it runs, when and how often.
Now a program to stuff the call into other programs, too. It might look like this [ Figure 2 ]:
What you'll end up with, in all your programs (assuming attribute <2> of the program is a good place for this and it may NOT be if you have INCLUDES) [ Figure 3 ]:
Get this program inserted everywhere and let it run for a year — that way all of the year end programs are logged. In the mean time there are some other semi-automated things that can be done. This crawler program mentioned earlier. Building a matrix of programs that update files. Stratifying files by how important they are. Perhaps we can discuss those in another issue. Perhaps you've worked on a project like this and have something to add?
