The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
paulgboul...@aim.com (Paul Gilmartin) writes: > So that's where CMS got that idea. But z/OS device independence is eroding. > Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing > QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the number of z/OS > utilities that balk at "DD PATH=...", not because their QSAM calls couldn't > perfectly well handle it, but merely because they're afraid to try. a lot of CMS design reflects CTSS heritage. CMS then adopted a lot of os/360 applications ... and therefor had to do a layer of OS/360 simulation (especially for assembler and compilers). more information ... cp67/cms version 3 (oct70) users guide: http://www.bitsavers.org/pdf/ibm/360/cp67/GH20-0859-0_CP67_Version_3_Users_Guide_Oct70.pdf os macros .... pg 294 Later after the moph to vm370/cms (and cambridge monitor system renamed conversational monitor system) ... there was some amount of DOS simulation also added. There was also some joke about CMS 32kbyte os/360 simulation code ... did almost as good as the 8mbyte mvs os/360 simulation code. The biggest change from cp67/cms to vm370/cms ... was reorging the kernel with application program loading at x'12000' to take advantage of (original) 370 (64k) r/o shared segment support. Application programs then were moved to starting at x'20000' ... and cms kernel "shared code" moved to start at segment boundary at x'10000' (segment 0 was then data and non-shared code ... since virtual page zero couldn't be shared, and therefor virtual segment 0 couldn't be shared). however, all the effort came to *NOT* ... before the full 370 virtual memory architecture could be announced and shipped ... retrofitting the full 370 virtual memory architecture to 370/165 ran into all sorts of problems. 165 petitioned for dropping several features to gain back a lot of the schedule; and one of the things dropped was 370 r/o shared segment support. that forced m370 to quickly come up with a quick&dirty hack using storage protection keys ... to simulate the original 370 virtual memory r/o segment protect. with the addition of dos simulation ... for running dos programs in cms ... there then had to be option to specify whether non-cms service requests went thru os simulation or dos simulation ... aka "set dos on" http://publib.boulder.ibm.com/infocenter/zvm/v5r4/topic/com.ibm.zvm.v54.dmsa5/hcsd2b00514.htm in the wake of demise of FS and the head of POK convincing corporate to kill vm370, shutdown the burlington development group and moving all the people to POK (justification was that otherwise wouldn't be able to make mvs/xa ship schedule) .... there was joke that head of POK was major contributor to vax/vms (i.e. the people that didn't move to pok ... but went to DEC to work on vax/vms); endicott eventually was able to obtain the vm370 product mission ... but had to reconstitute the organization from scratch. the issue here was that one of the people in burlington (that didn't move to pok) had done a pretty complete os disk i/o routines for os disk r/w, vtocs, handle most kinds of files, understood and could process PDS, etc (aka wasn't os/360 file simulation in cms filesystem, but supported full os/360 operation on os/360 disks). All of that evaporated/disappeared with the shutdown of burlington development group. -- 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
