m...@mentor-services.com (Mike Myers) writes:
> On thinking it over some, it had to be early 1968, ending around March
> or so (I just reviewed my CV and found I went to FE education in April
> of 1968). So maybe it was closer to Release 11 or 12. Wasn't release
> 14 actually 14/15 (not that that means anything, just a recollection)?

re:
http://www.garlic.com/~lynn/2010b.html#51 Source code for s/360

part of presentation at '68 boston Share meeting on bunch of performance
enhancements i had done at the univ to both mft14 & cp67. cp67 was
installed at univ. where i was undergraduate ... and also os/360 support.
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

i had been doing highly customized os/360 sysgen's attempting to
radically improve thruput ... as well as being able to do (at least)
stage2 sysgen in production jobstream. I did lots of re-ordering stage2
sysgen to carefully place files and pds members on disk to optimize disk
arm motion (i got about 3times thruput improvement for typical student
fortran job stream ... this was before watfor and student jobs going
thru standard fortgclg).

for cp67 ... i rewrote lots of kernel to significantly reduce
pathlength.

os/360 releases i did for mft were 9.5, 11, and then 14. combined 15/16
came out ... and i did a mvt generation (mvt was starting to get to
point that it was more reliable). big thing i remember about 15/16 was
that it introduced format enhancement and being able to specify cylinder
for vtoc (rather to defaulting to cylinder zero). I placed vtoc in
middle of system packs ... and then attempted to force placements
radiating out from the middle of the pack on both sides of the vtoc.

one of the problems were that typical PTF activity "replaced" PDS
members ... and 5-6 months of system PTF activity could significantly
degrade my carefully optimized thruput ... i.e. pds members being
replaced in system datasets ... creating lots of gas ... standard pds
compression didn't offer anyway of controlling member ordering. If I
wasn't planning on doing near term sysgen for new system ... i would
have to rebuild system to get back disk arm optimization.

end of '68, boeing was putting together basis of boeing computer service
(BCS) ... moving datacenters from cost center to P&L basis ... at least
on paper. As part of concept of "selling" services ... they wanted to
add CP67 online timesharing ... and be able to sell CP67 internally
within Boeing ... but also to external organizations (somewhat akin to
some of the other commercial online cp67-based timesharing service
bureaus that had been formed). Spring break, '69, they con'ed me into
teaching one week class for the burgeoning BCS technical staff. Boeing
then brought me in for summer ... they did some sort of paperwork that
listed me as mid-level fulltime employee (that got me special parking
lot privileges at boeing field). They brought in new 360/67 "simplex"
... installed in the hdqtrs machine room next to 360/30 that was doing
payroll (deal was also cut that for the summer work, i also got some
"special project" academic credit towards graduation).

The boeing huntsville two-processor 360/67 smp was also moved up to
seattle that summer. It had been running as two single processors with
modified version of mvt13. Boeing huntsville was supporting a lot of
long running 2250 graphics applications. os/360 had significant problem
with storage fragmentation with long running jobs. mvt13 had been
modified to run with 360/67 virtual memory tables ... it didn't do any
paging ... but used to re-org storage mapping to make it look contiguous
(countermeasure to os/360 storage fragmentation).

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar1970

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to