Warren how's your new job???? -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Warren Brown Sent: Tuesday, December 10, 2013 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "hexadecimal"?
In the 70s 'TCAM' it used PCI to function the entire time TCAM was running. There was only one channel program that handled all requests. If TCAM ran out of work, the channel program would TIC to location 2 which cause a channel program check. TCAM STAE routine would recover. ________________________________ From: DASDBILL2 <dasdbi...@comcast.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, December 10, 2013 11:24 AM Subject: Re: "hexadecimal"? I Totally agree with using PCI to implement this insane channel program, which, if it could honk through 2,000 tracks per second and never end prematurely, would take about 23 days to complete. And 2,000 tracks per second is achievable now, so by the time a fully populated EAV is available the sustainable data transfer rate might have improved to where it would take less than one day to complete. Bill Fairchild ----- Original Message ----- From: "Tony Harminc" <t...@harminc.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, December 9, 2013 7:21:53 PM Subject: Re: "hexadecimal"? On 9 December 2013 18:04, DASDBILL2 <dasdbi...@comcast.net> wrote: > My phrase "billions of CCWs" was assuming you already knew how to read a full > track with only one CCW. A fully > populated EAV can have 16 to the 7th power cylinders and each cylinder can > have 15 tracks. One Read Track CCW > (and not Read Multiple CKD, which is too primitive) per track would require 4 > 026 531 840 CCWs, which is four billion, > which is "billions". And each CCW would need 56K bytes of real, fixed > storage for the life of this I/O request. That's > 228 terabytes of real storage, which is the main reason why I called this > channel program theoretical. In the real world, PCI would be used to modify the channel program on the fly. It would presumably be copying the data to another device (tape or disk), and as long as that output device could keep up, there's no reason for this to be a theoretical-only scheme. Much the same thing, on a smaller and slower scale (though perhaps not much smaller relative to the hardware of the day) was done by APL\360 with its terminal I/O. The terminal read channel program was unending, with new buffers being chained in based on PCI interrupts. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
