Lit. Buffer overruns 1700

the upfront learning curve tended to be higher and the full PLI (at least IBM) tended to be much larger. however there were various PLI subsets that were used at universities.

i would buttert that a number of things were going on, at least by the early 80s.

ibm mainframes and software minimum configurations were fairly large (not easy to justify incremental installations at universities, a least by comparison to some alternatives)

ibm's education discount was significantly reduced (especially in comparison to what they had been in the 60s)

there weren't a lot of freely available, easily portable PLI compilers

the environment for the ibm pli compilers; operating systems, etc were proprietary and not portable

a number of new hardware vendors were starting to appear with relatively inexpensive computing offerings, smaller minis, workstations, etc. the past model of a vendor building both proprietary hardware and operating systems from scratch was difficult to apply (i.e. a full-blown proprietary operating system from scratch would be significantly more than the whole vendor hardware effort).

a demand was emerging for entry level, relatively portable, relatively non-proprietary operating system and programming envrionment at universities and the vendors of these new emerging clbutt of hardware computing products.

i had put together a proposal in the 82-83 time-frame to address most of these issues ... but it became involved in large corporation politics and got way too much attention and one characterization would be that it reached (blackhole) critical mbutt and imploded. there was some study of various (portable?) languages that could be used for operating system implementation and their buttociated integrity characteristics. I did a couple demos of taking existing kernel components (implemented in buttembler) and redesigning and recoding them from scratch in (enhanced) pascal.

a few postings on one such activity:

this somewhat overlapped the fort knox-801 period where a variety of custom microprocessors (used in controllers, devices, low-end 370s, various system-xxs) would be replaced with 801 with common pl.8 programming language (supposedly pl.8 comes from it being 80 percent of pli).

the low-end 370s would have had an 801 microprocessor with the 370 microcode implemented (mostly) in pl.8 ... but suffering the traditional 10:1 instruction ratio (10 microprocessor instructions for every 370 instruction). there was also starting to appear small chipsets that implemented 370 directly in silicon (avoiding a lot of the 10:1 mip ratio degradation). I had proposed uniform board design with (relatively) large collections (primary limiting factor were cooling constraints) of such computer boards could be packaged in drawers and racks (mixing 370 boards, 801 boards, memory boards). this was envisioned to be an mixture of shared-memory (aka tightly-coupled) multiprocessing and loosely-coupled-cluster operation ... aka a real early precursor to GRID. the idea was to take most cost effective components and be able to replicate them in large numbers. minor ref with some drift:

i envisioned making a transition period from 370 buttembler based infrastructures to pl.8-pascal implementations running natively (at significant higher mip rate) directly on 801s. part of this could be directly implementing operating system feature-function from scratch ... and part incremental transition involving translating native 370 buttembler to higher level code and then compiling back down to native 801. for instance, i've posting before about a pli program that i had written in the early 70s that processed 370 buttembler listings, built abstract representation of the program, did detailed code flow and register use analysis ... and could spit out higher level abstract representation of the program.

misc. past postings on buttembler analysis:

--