Robert A. Rosenberg wrote: > You are confusing two separate schemes. In my case the data was written > in standard order. Since I was using BDAM (it might have been BSAM where > I was supplying the record number I wanted) I just REQUESTED the records > in reverse order (after I used the EXCP CCW string to find the last > record on the current track). > > HASP WROTE the records in the order (and numbered as in the Count > Section) 1 4 2 5 3 6 (assuming 6 blocks per track). This allowed it to > read the full track in two revolutions of the drive. If it had tried to > read a normally numbered track the channel was too slow to catch the > next record on that revolution. The out-of-sequence-interleaved > numbering allowed the channel to catch up and be ready for the next > block before it passed the read head. By JES2 days the channels were > fast enough to keep up with the DASD (as well as there being cached > buffering and read-track commands/etc.).
in the early 70s, the stuff for page-map support of cms filesystem (originally on cp67): http://www.garlic.com/~lynn/subtopic.html#mmap picked up the earlier pathlength stuff i had done for stylized fastpath ccw for cms disk i/o (that eventually turned into diag 18) ... but it also eliminated a lot of the overhead of simulating real i/o operations in virtual memory environment (prefetch & lock/pin of pages before starting the complete i/o, unpinning all the pages when done, etc). the other thing was that cms file i/o only did chaining when file records were sequential and contiguous. i had originally done the chaining logic for page i/o for cp67 ... where each page transfer was independent operation and multiple could be chained together for optimal disk operation ... regardless of the original order or source of the request. this met that different requests for the same shared area from different tasks could be chained together ... or that chains could be re-ordered (i.e. multiple records for the same file could be randomly ordered on the same cylinder ... page mapped interface would queue the request ... and optimal reordering and chaining would fall out in the standard page support). there was also some tricks about looking at system contention and dynamically deciding to build huge i/o transfers ... and/or delay stuff ... part of the stuff was that using the paging interface ... you could have asyncronous operation transparent to the application ... by using virtual memory hardware to provide necessary serialization control. note that in migration of os/360 to virtual memory environment ... resulted in similar need to do all the real i/o simulation processes for virtual memory environment. as mentioned before ... one time when we were doing some stuff 3rd shift in pok machine room ... I think it was Ludlow was working on VS2/SVS prototype ... basically using 360/67, taking mvt and cobbling together a little bit of single address space layout and a low-level page fault and replacement handler. the other part was taking cp67's CCWTRANS and hacking it into the side of MVT for doing all the steps for translating and shadowing CCWs, fetching/pinning virtual pages, untranslating, unpinning. etc. a few old posts about hacking cms disk i/o pathlength as undergraduate: http://www.garlic.com/~lynn/99.html#95 Early interupts on mainframes http://www.garlic.com/~lynn/2003.html#60 MIDAS http://www.garlic.com/~lynn/2003k.html#7 What is timesharing, anyway? http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
