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. The CCW architecture allows for an infinite number of CCWs to be chained together. The channel subsystem honors the chaining flags by adding 8 to the real address of the current CCW to get the address of the next CCW to use to continue the I/O operation, and this process will never stop until some real limitation is reached, such as the end of real storage, or the job's submitter dies before the one I/O request ends and the operator cancels the job, hopefully without the dump option. :-) Bill Fairchild Franklin, TN
----- Original Message ----- From: "Harry Wahl" <[email protected]> To: [email protected] Sent: Monday, December 9, 2013 4:41:21 PM Subject: Re: "hexadecimal"? "You would need a lot of real storage and billions of CCWs, but it's theoretically possible." You wouldn't need billions of CCWs, you could use the "READ MULTIPLE CKD" command (X'5E') or the "READ TRACK" command (X'DE') and have one read CCW per track along with whatever setup and positioning CCWs are necessary. These CCW commands are what DUMP/RESTORE programs use. Of course, if something unexpected occurs, e.g. an unformatted or malformed track, your chain would be interrupted, but the chain could then be restarted. What Bill is suggesting is more than theoretical, it is quite common. Harry > Date: Mon, 9 Dec 2013 20:30:17 +0000 > From: [email protected] > Subject: Re: "hexadecimal"? > To: [email protected] > > In a command channel program, you can chain any number of CCWs together, each > of which can possibly transfer up to X'FFFF' bytes. It's theoretically > possible to have one very long chain that copies an entire EVA DASD to > somewhere else in only one I/O request; i.e., only one SSCH. You would need > a lot of real storage and billions of CCWs, but it's theoretically possible. > Bill Fairchild > > ----- Original Message ----- > > From: "Scott Ford" <[email protected]> > To: [email protected] > Sent: Monday, December 9, 2013 10:53:03 AM > Subject: Re: "hexadecimal"? > > Bill, > I thought you could chain ccws > > Scott ford > www.identityforge.com > from my IPAD > > 'Infinite wisdom through infinite means' > > > > On Dec 9, 2013, at 10:42 AM, DASDBILL2 <[email protected]> wrote: > > > > Channel programs have always been able to transfer anywhere from zero to > > 65,535 bytes per CCW. Most access methods do not support any CCW byte > > count greater than approximately 32K. > > To render my first sentence more up-to-date, I should say channel programs > > running in command mode have always been able... etc. (since transfer mode > > channel programs have no CCWs in them). > > > > Bill Fairchild > > Franklin, TN > > > > ----- Original Message ----- > > > > From: "Paul Gilmartin" <[email protected]> > > To: [email protected] > > Sent: Sunday, December 8, 2013 8:25:50 PM > > Subject: Re: "hexadecimal"? > > > >> On Sun, 8 Dec 2013 20:01:20 -0600, Joel C. Ewing wrote: > >> > >> If the real requirement is that the parameter address must point to a > >> location containing what the PoOp describes as a half-word binary value, > >> then the manual should state precisely that. > >> > > Thanks for bringing this thread back to my original concern when I > > started it (I never imagined! ...), however interesting the digressions > > to HFP and ternary logic may be, and for stating that concern more > > clearly than I did. > > > > There should also be mention of the allowable range of values: > > 0<n<=32760? 0<n<=BLKSIZE? 0<n<track-size? 0<n<=65535? > > (The last is the maximum supported by channel programs, or was.) > > Are unsigned halfwords supported? This became an issue about the > > advent of the 3380. > > > > Clearly the present text of the manual engenders confusion and > > dissent. > > > > -- gil > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
