[email protected] (WILLIAM H BLAIR) writes: > Donald Ludlow WAS indeed the principal author > of OS/360 IOS. In fact, he wrote ALL of the > code that actually survived and was shipped. > There was another gentleman who CLAIMED to be > the "author" of IOS (whom I knew personally), > but everything he did had to be redone by Don > (or mostly, in fact, simply thrown away). > > Mr. Ludlow moved to Raleigh, NC and worked on > SPF (as it was then called), incorporating the > SUPERC FDP into ISPF/PDF as what we know today > as options 3.12, 3.13, and 3.14 (a "recent" > enhancement adds 3.15). > > He wrote some of the slickest, tightest S/360 > Assembler code I've ever seen or had to modify > learning a lot about device channel programming > from it (and from him).
this is reference to getting request to find people that had been involved in the decision to convert all 370s to virtual memory (i.e. MVT storage management was so bad, that region sizes typically had to be four times larger than actually used, as result typical 1mbyte 370/165 only ran four regions, going to virtual memory, could get four times as many regions with little or no paging) http://www.garlic.com/~lynn/2011d.html#73 Ludlow was doing initial implementation of MVT for VS2/SVS ... work done on 360/67. Basically not that different of running MVT in a 16mbyte cp/67 virtual machine. Build table for single 16mbyte virtual address space at startup and a little bit of page I/O (not hihgly optimized because anticipating little or no actual paging). Biggest amount of code was same as CP/67 ... (EXCP/SV0) got channel programs built with virtual addresses ... and so had to make a channel program copy replacing the virtual addresses with real addresses ... and basically borrowed the code from CP/67 and hacked into EXCP. Slight topic drift, in my previous post in this thread, I mentioned doing bullet proof input/output supervisor for doing bldg14 disk engineering testing and bldg15 product test http://www.garlic.com/~lynn/2019h.html#52 S/360 They had previously tried MVS, but in that environment MVS had 15min MTBF requiring manual re-ipl. This is later email just before 3380 customer ship ... FE had regression test of 57 simulated errors that were expected to occur in normal operations. MVS was still failing in all 57 error (requiring manual re-ipl) with no indication of what cause the failure in 2/3rds of the case ... old email http://www.garlic.com/~lynn/2007.html#email801015 I did an internal report of all the changes/fixes needed to support any amount of on-demand concurrent dasd development testing (previously they were running 7x24 pre-scheduled stand-alone testing) ... and (unfortunately) happened to mention the MVS 15min MTBF ... which brought down the wrath of the MVS group on my head (I was told initially they tried to have me separated from the IBM company). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
