When investigating systems, often legacy financial and business systems, my simple descriptions in the prior videos begin to break down as we dive deeper: these systems are not always simple. Here’s what to look for next.

Most of the program logic sits under the Perform Until End of File section. As systems developed, programmers recognized common program patterns for this phase, with small variations in logic. They began to externalize some of the logic definitions, to parameter files, which could be updated more easily than hard-coded logic.

They also recognized the process of reading the files was the longest part of processing time; IO was the slowest part of these systems. And so they attempted to do multiple things with each record as they had it in memory.

They might:

  • List them on transaction listing reports
  • Accumulate their amounts or count things for control report and control record processes
  • Produce business reports using them, like a trial balance, or other reports
  • Even perform back-up operations

It is often these additional functions that begin to confuse modern developers, because it seems the programs are not modular.

Yet if one understands the read until end of file construct of the mainline routine, one can start to see the pattern of how these functions are performed. Doing so exposes the orderliness of these systems, many of which are still in use today, particularly in financial services.

This is Episode 160 of Conversations with Kip, the best financial system vlog there is. Literally learn more–about ledgers and financial systems–at LedgerLearning.com.

Up next:  Data Discovery in Tabulating Systems