[email protected] (David W Noon) writes: > All of the buffer fills and buffer flushes occur quite separately from > the application program. The EXCP macro is a wonderful thing.
A big problem with the EXCP semantics ... it had applications (and/or libraries running in application space) to build channel programs/CCWs in the application space. EXCP then takes the passed channel program pointer and initiates the I/O. In the move to all virtual memory ... the big problem is that channel programs (CCWs) execute with real addresses ... after virtual memory, all the channel programs were being built with virtual addresses. The original justification for moving everything to virtual memory was the horrible MVT storage management (regions required to be four times larger than typically used) ... typical 370/165 with 1mbyte memory ran four regions. Moving to virtual memory could increase number of regions by a factor of four with little or no paging, the increase level of concurrent activity significantly increasing system throughput (as disks were increasingly becoming system throughput bottleneck). Old post with quotes from person directly involved http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory The initial implementation VS2 release 1 (SVS) did a little bit of code to have single 16mbyte virtual address space ... with MVT layed out as if running in 16mbyte real machine. The majority of the code was in EXCP having to create a copy of the passed channel programs, substituting real addresses for the virtual addresses ... the code was borrowed by taking CCWTRANS from (virtual machine) CP67. The move to release 2, MVS involved (sort of) giving each application a 16mbyte virtual address space. However, the extensive MVT pointer-passing convention required giving 8mbytes of each address space half the 16mbyte for image of the MVS supervisor. Then because MVT subsystems were moved to their own separate address spaces ... to enable pointer passing convention between applications and subsystems, they had to be stuffed into the "common segment" to support pointer passing API convention. Starts out as single one mbyte segment, but because the space needed is somewhat proportional to concurrent activity, number of subsystems, etc ... it evolves to CSA ... larger systems with 4-6mbytes CSA ... leaving 2-4mbytes for applications. Late in 3033 period, CSAs were threatening to expand to 8mbytes ... leaving no available space in 16mbytes for application use. Also from CP67, charlie had invented compare&swap while working on CP67 fine-grain multiprocessor locking (compare&swap chosen because CAS are his initials). Initial attempts to get it included in 370 were rebuffed because the POK favorite son operating system people said it wasn't needed. 370 architecture people said to justify compare&swap, needed uses other than kernel locking. Thus were born the uses that still appear in the appendex of principles of operation ... including wait/post ECB ECB https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idas300/ecb.htm wait/post http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa600/tasks.htm -- 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
