Was FORTRAN buggy 4349

i've told stories before about automated regression tests

for resource manager

but that included a lot of validation of the resource management algorithms and control functions (under broad range of conditions, configurations, and workload ... aka including a lot of dynamic adaptive stuff) ... in addition to various kinds of failure modes.

early heavy stress testing resulted in numerous kernel failures. the result was rewritting the whole kernel serialization-syncronization infrastructure (to eliminate all observed failure modes) ... which was more code and significant more module hits ... than the resource manager itself. in later release, the code other than resource management ... was moved into the base system.

the final sequence prior to release involved 2000 benchmarks that took 3 months elapsed time (and the last 1000 involved an alrorithm that was looking for possible anomolous and boundary conditions ... which selected the next benchmark workload-configuration based on results of the benchmarks to date).

the base system process shipped maintenance tapes every month (called PLCs or program level change). initially they wanted resoure manager shipped monthly in sync. with standard PLC. I argued for only every three months. The resource manager was a research project ... releasing it as a product was much more of a hobby activity ... I wasn't part of any development or support organization. I also argued for requiring at a minimum 100 benchmarks for each updated PLC release of the resource manager ... and as a part-time effort, I wasn't prepared to do that every month.

as to the issue of moving (a lot of integrity, serialization, syncronization and other code, like a bunch of stuff for kernel organization for supporting smp)

code out of the resource manager into the base system, there was a separate issue.

the original unbundling and starting to charge for software on 23jun68 plus 1 (as a result of various gov. and other litigation efforts) argued that it should only be for application code ... and that kernel code should continue to be free.

as things evolved during the 70s, there was beginning to be pressure to start charging for more and more code. the resource manager got chosen to be guinea pig for charging for specific kernel components (which eventually evolved into charging for all kernel components) ... and i got to spend time with business people working on policies for charging for kernel software components.

so in this transition period, the resource manager (and eventually other pieces) were charge for ... while the base kernel was free. moving over half of the code that had been in the initial resource manager into the base system ... wasn't just a packaging issue ... since it also met that the code went from "charged for" to "free".