These methods exist between full-on interpreters and plain old source code. These methods require a different mind-set than the typical average programmer. More than once, I have seen an average programmer stumble over the difference between parameters that control program flow and the statements that implement program flow. Those programmers often complain that "I cannot tell what this does because both sides the of IF statement are variables." For example,
IF PRGM_CMD = DRLC_VERIFY THEN
* perform driver's license input
MOVE CVS_CONTINUE TO DRLC_STATUS
PERFORM DRLC_VERIFY_RTN
UNTIL DRLC_STATUS <> CVS_CONTINUE
END_IF
Initial Run-Time Parameters
Most IT people understand config files for initial conditions and preferences. Typically, the values trigger IF statements which set run-time parameters. Such values can save hours of code changes because simple changes to data in the file can change the behavior of the program.
Flexibility
User Preferences
No Code Changes and No Migrations
Initial Values for Records
Avoid program changes
Effective Dating handles the passage of time and transition between periods
Calculated Initial Values
At APU, one manager insisted on dismantling the automated initialization of batch jobs. That manager believed that humans should input the various values. Human intelligence and inspection was better than automated, unfeeling, unintelligent calculations. That argument contributed to my leaving APU for two years. Ironically, I gave four months notice, and that manager left ten weeks before I did. Various contractual obligations and some fun kept me from staying and from returning soon.
For a given clerk or a given batch job, many simple calculations can smooth logons and inputs. A computer is so much faster and so much more precise than a human in many tasks. We established a few fundamental relationships for each user. Which school of the three: GR, UG, or DC; a few exceptions had no school. The school pointed to a term or semester. The term pointed to enrollment dates. Which role was primary and which secondary: in turn, these pointed to GL accounts by first pointing to mnemonic fincodes, like GRTUIT. Each clerk had a default printer. For a batch job, the combination of the job, the clerk, and the school determined the default initial values, which the clerk could override.
Well Named Literals
The programmer should employ standard literals for standard situations. When a literal occurs several times, the programmer should consider declaring a specific literal. The letter Y often means Yes, but when programs deal with other meanings, the programmer should declare literals. The prefix of CVS indicates that this field is a control value and not actual data.
For example, 07 CVS_Youth Value "Y".
07 CVS_Nylon Value "N".
When an entire module has a collection of common literals, the designer should create a file to include them. In the example, finding Size=Youth and and Material=Nylon makes understanding the meaning much easier than wading thru a bunch a letter Y's and N's, especially when the program can include more than one meaning for the letter Y.
Business Dates
Some accounting systems place a high value on periodicity. Even though a month has ended, transactions for the month might remain. Having the program calculate the business date allows such back dating. The business date greatly aids testing; for example, the programmer can set the business date to a future data in order to see what might happen in the next month.
Effective Dated Parameters
Having initial values in records greatly relieves the need for program changes, but the march of time requires monthly, seasonal, and annual changes of the records. By having an effective date on each record, the tyranny of time diminishes. As the calendar approaches the end of the year, with effective dates, the administrator can load the tables for the next year months before January. Likewise, even after the new year, the processes can be run for the past year.
Program Self-Awareness
Each program should have an internal record or object which describes the program itself. This aids in statistics and logging. This promotes the practice of having the program look up parameters for itself.
Crosswalk or Translation Tables
This is a no brainer and many import and export programs follow this method. Having effective dates provides maturity.
The O'Hare model works better than simlpe Active and Inactive for Translation Table
O = Obsolete; no longer valid for new records; required from some old records
H = Historical, valid for new records if the clerk knows the code
A = Active
R = Restricted; not allowed; possibly this code and another together form a vulgar word
E = Exception; similar to A but some trigger fires within the lookup routine
I = Inactive; think O'Hare International
Cascade Report Algorithm
About 1970, after a challenge by Greg Hopwood and Fred Tonge, I wrote an assembly language program which incorporated a somewhat dynamically selectable sort and total options. For a given record with keys, I put the descriptors of the keys into an array. When the clerk launched the batch job, the clerk chose the precedence of the keys, which in turn controlled the control-breaks of the report. A change of values in a top precedence key would trigger subtotals of all of the lower keys. This method enables one report program to produce multiple outputs. The footer of the report displays the precedence of the keys as chosen for the particular run of the program. A report with six keys can produce 64 variations, but not all might be useful.
Consolidated Logic
Suppose that a situation has five yes-no fields which control processing. At most there would be 32 possibilities if all of the fields have expected values. Using consolidated logic, a program would turn the five fields into a key field and the result would be like 'MyProgram' + YYNYN
Then the program would look up the key in a table and retrieve an action token, like PRINTDOC or SKIP or ERROR.
A case statement would then continue processing.
No deeply nested logic statements
Independence between the flags
Changing the table changes the logic and the flow of the program
Mini-Parsers
Most data comes in discrete fields. Nevertheless, some kinds of data, like websites, require routines to parse and wade thru the sites. Artificial intelligence also requires parsers to process human inputs. A very successful project at Richey Electronics employed parsers to find pages and to interrogate embedded tables. Obviously, any often repeated functionality begs to be formalized, but parsers appear here as another aspect of semi-interpretive methods.
Data Formatters
Since data comes as discrete fields, combining those field sometimes becomes a common functionality, and so formatting often becomes a candidate for libraries.
Loosely Linked
For years, the concept of loose coupling has been promoted. Object oriented programming has further promoted the idea because some data is private; not all routines have access to all data. Loose Linking continues the concept by separating the idea of linking from the syntax. For example, the system might have several common remote processes which rely on distinctly different technologies. Rather than calling these processes directly, a routine in the the program places its own token, data for the desired process, and the token that represents the process on the stack and then gives control back to the main interpreter. The main interpreter takes token for the report process and finds the caller. When the caller returns, the main interpreter puts the data from the called remote process on the stack and then the token of the routine. As programs grow, this tactic simplifies the calling techniques at a small cost of indirection. State Machines often supply such tokens.
State Machines
A state machine can save hours of programming, miles of code, and isolate functionality. All of my cash register programs used status machines for primary logic. Similarly, this method handles document processing programs like time-card approvals, HR documents, license processing, and many other situations where a document flows thru a network of status values. (Some people might think stages instead of status values.) The following table has a program ID, a clerk ID, initial status, possible next status, and several more fields. The record status field allows a manager to turn off or on a record without deleting the record. The effective date allows the table to contain logic for consecutive periods of time, like months or years. Most payroll and tax programs have at least two years of table so that the transition between year goes smoothly.
Program |
Clerk |
Rec. Effect. Date |
Rec. Status |
Seq |
Status Initial |
Status Next |
Button on Screen |
Message |
Reply to continue |
Action 1 |
Action 2 |
my2prgm |
employee |
14/01/01 |
A |
01 |
draft |
saved |
SAVE |
|
|
logfile |
|
my2prgm |
employee |
14/01/01 |
A |
02 |
saved |
pending |
SEND |
hours < 40 |
Y |
verify |
|
my2prgm |
employee |
14/01/01 |
A |
02 |
draft |
delete |
DELETE |
Are you sure |
Y |
|
|
my2prgm |
employee |
14/01/01 |
A |
03 |
saved |
pending |
SEND |
print copy |
Y,N |
verify |
|
my2prgm |
employee |
14/01/01 |
A |
03 |
draft |
draft |
EXIT |
Save or Lose |
Y,N |
|
|
my2prgm |
employee |
14/01/01 |
A |
06 |
saved |
saved |
DELETE |
Are you sure |
Y |
|
|
my2prgm |
mgr |
14/01/01 |
A |
03 |
pending |
approved |
APPROVE |
alert employee |
Y |
|
|
my2prgm |
mgr |
14/01/01 |
A |
03 |
pending |
saved |
RETURN to employee |
Are you sure |
Y |
|
|
my2prgm |
mgr (self) |
14/01/01 |
A |
01 |
draft |
saved |
SAVE |
|
|
|
|
my2prgm |
mgr (self) |
14/01/01 |
A |
02 |
saved |
pending |
SEND |
print copy |
Y,N |
verify |
|
my2prgm |
PRsupr |
14/01/01 |
A |
01 |
approved |
finished |
FINISH |
|
|
process |
logfile |
my2prgm |
PRsupr |
14/01/01 |
A |
04 |
approved |
pending |
BACK to mgr |
|
|
process |
logfile |
my2prgm |
PRsupr |
14/01/01 |
I |
08 |
approved |
rejected |
REJECT |
Unusual |
Y |
process |
logfile |
my2prgm |
PRsupr |
14/01/01 |
A |
08 |
finished |
no more |
--- |
|
|
|
|
my2prgm |
PRsupr |
14/01/01 |
A |
09 |
rejected |
no more |
--- |
|
|
|
|
The Payroll System (PR) and the Cash Register (CR) at The Federated Group performed calculations by reading tokens. The CR could read and verify a large ASCII file, which the VP of Stores could read and modify. Likewise, the PR contained large arrays to contain tokens, values, and formats. The Payroll Manager could specify calculations by inputting formulas like these:
PYGROSS = HRREGTTL * RTREG + HROVRTTL * RTOVR + HROV2TTL * RTOV2
PYGROSS = PTGROSS + CMGROSS + OTGROSS
USINCTX = USINCTX_YRDT - USINCTX_YRPD <<US Income Tax this check = year to date owed minus year to date paid >>
Tax Tables and More
The typical manager understands the common practice of having multiple years of tax tables in a payroll program. Similar advantages apply to many other time-effected calculations. The SRN tuition calculation module contained multiple tables for multiple semesters and multiple kinds of calculations. The Herbalife Tariff module heuristically calculated several shipping routes and then chose the most profitable. The APU admissions module could compare records about incoming students with similar records and with existing students. The AQMD address verifier matched incoming addresses against patterns.
Address Verification
Current databases contain so much information that several service offer a list of all the mailing addresses in the United States. Most addresses are confirmed; some might be inactive like an abandoned house; others might be influx like new construction. This technique is not so amazing as it is representative. The college name matching module at APU helped clerks determine the official name and ID of colleges by allowing the clerk to input related names: Fullerton State pointed to California State University-Fullerton.
Data Warehousing