| PLEX86 | ||
Was FORTRAN buggy 4318Was FORTRAN buggy 4319 It was more of not having the QA reporting to the same cost center manager. To settle disputes...
vm370 was completely shipped and maintained in source form. it officially ran on 370-135 thru 370-168 (maybe .2 to 3.5mips, better than order magnitude rnage in processor speed). it wasn't officially supported on 370-125 ... about 100kips and max. real storage 256kbytes ... however, i did a custom modification so a customer (datacenter in nyc for a Norwegian shipping company) did have a 370-125 vm370 install. Was FORTRAN buggy 4320 re: it was worse than that ... NJE grew up out of HASP networking, some amount of it had been done at TUCC. HASP had a... there were easily several hundred internal datacenters with eventually a couple thousand processors running the software (across an extremely large range of configurations and workloads). at one point there was a study that internal locations had source modifications to vm370 kernel that in aggregate was approx. twice as many lines-of-code as in the shipped product. Was FORTRAN buggy 4321 On Tue, 26 Sep 2006 11:29:58 -0500 in alt.folklore.computers, Charles TECO wasn't too bad if you programmed using indented source with comments like any other language, then "compiled"-squished the source .TES... share-waterloo had similar contributed library of customer kernel software modifications ... in aggregate which was also about twice the number of lines of code in the base, shipped product (i.e. customer datacenters had contributed their source kernel modifications to the share-waterloo library ... the total source lines of code changes were approx. the same aggregate lines of code as aggregate number of lines of code changes done by internal datacenters). recent post about complete source distribution and source maintenance including having done resource manager ... which was also complete source distribution (as updates and changes to base system). Melinda has long paper on here web site breastled "VM and the VM Community: Past, Present, and Future". At the same site there is also a paper "WHAT MOTHER NEVER TOLD YOU ABOUT VM SERVICE" (talks about source maintenance-update process). there have been some number of posts-threads this year describing the origins of vm370 multi-level source update process ... starting back with cp67 with the (single level) source UPDATE program. This evolved into the multi-level update process, originally in support of the cp67h & cp67i effort to support 370 virtual machines under cp67, original post: later editor applications were enhanced to apply set of multi-level UPDATE changes to the base source before starting edit process ... and then to save all new deletes, updates, replaces, and inserts were then saved as a new update (as an option ... as opposed to saving the complete modify file). a few posts mentioning the multi-level source update process
|
||||
Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||