iSoftwerks.factory

The first programs I wrote were on the S/3 Mod 15D. The largest program you could present to the system was 16K, unless you took advantage of the Shared Virtual Area (SVA) which would allow you to max out a program at 48K. Obviously with only 16K to play with, programs were generally limited to a single function, and typically complex processes would have to be built with a job stream of small programs, sequentially staged to execute against a common set of files.

The S/38 had few limits in terms of program size and IBM did encourage monolith code development. I only attempted about 3 applications before I realized the model was all wrong. Yes, loading everything into main memory at once does mean that execution is fast (assuming your monstrous program does not get paged out, which they invariably did). But the trade-off in terms of maintainability simply wasn’t worth marginal performance gains.

I began looking for a better model for programs where functionality could be driven by database entries instead of “hard-coded” instructions. I made a conscious attempted to strip common functions out of programs and externalize as many of those functions as subprograms. From that point forward, all my applications were modular in nature, limited in function and database driven.

I borrowed an idea from Bob Cozzi, Jr. to place program function keys into a database file and have a program react to the instruction on file, rather than react to the function key itself. I was able to externalize functions, separating function definitions from the program. The process was extended to include external program options and designed database files to contain program options and function keys, turning them into macro instructions.

At the time the AS/400 was introduced, the payback to this methodology became clear. Converting from the S/38, where F1 was an exit key to the AS/400, where F3 was the exit key, the programs designed with soft-coded functions did not require any changes, only the database file was updated—F1 entries in the function key database were simply updated to read F3, instead of F1. No programs or displays were changed in order to implement the new system standard of F3 as the exit function.

Shortly after the AS/400 arrived I incorporated a gate-level application security system into the code. This, in effect, made application security an external function, controlled by a database file. I also introduced external program help, by incorporating a generic help processor into the soft-coded function key processor. (The concept of externalized help processes took shape after a COMMON discussion with Carson Soule.)

As the IBM mid-range platform evolved, I began updating what I had come to think of as the soft-coded application model. I began developing a method of separating presentation from data. This was more of an evolutionary step, rather than a revolutionary step. Having created a mechanism for external options, function keys, application security, and help, web or not, the next logical step was to separate the presentation layer from the business rules of the data. With the advent of ILE, this became the suite of SOFTCODE service programs.