Re: Rotational Positional Sensing (RPS)
-snip Does anyone know for sure which was the last DASD subsystem that cared about Rotational Positional Sensing (RPS) values? ---unsnip--- IIRC, that would be the 3390 (real, not emulated). To my knowledge, none of the RAID configurations care much about RPS data. -- 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
Re: Rotational Positional Sensing (RPS)
In a message dated 7/24/2007 11:16:19 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: -snip Does anyone know for sure which was the last DASD subsystem that cared about Rotational Positional Sensing (RPS) values? ---unsnip--- IIRC, that would be the 3390 (real, not emulated). To my knowledge, none of the RAID configurations care much about RPS data. The 3390 is not a subsystem. It is a device type. The subsystem in question would have to be one that is capable of driving a 3390, which include 3990, 9340, 9390, and 2105. IBM does not market RAID configurations to mainframe customers. It markets DASD subsystems that work according to the documentation in their control unit reference manuals, which say, or at least strongly imply, that sector values are still used. The real disks involved are RAID, but that's irrelevant. RAID configurations also do not care about the cylinder or track numbers that are known to the software running in the mainframe, but that doesn't mean the software can ignore these numbers. The DASD sub system reads an entire track into cache storage and then accesses that data as if it were on a real, SLED device type and according to the CCWs coming from the mainframe's central storage. When the subsystem needs to access the real disk(s), it maps the mainframe's CCHH and other control information into the appropriate commands and control information for whatever real RAID disks are inside the subsystem. RAID disks are FBA, so RAID configurations don't care about software's block sizes either. So no, the RAID does not care about sector numbers, but yes, the IBM DASD subsystems do. Bill Fairchild Plainfield, IL ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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
Re: Rotational Positional Sensing (RPS)
Does anyone know for sure which was the last DASD subsystem that cared about Rotational Positional Sensing (RPS) values? I would guess 3390-SLEDS connected to 3990-6's. - Too busy driving to stop for gas! -- 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
Re: Rotational Positional Sensing (RPS)
Using a sector number of x'00' effectively disabled RPS on devices that did care. Edward Jaffe wrote: Richards.Bob wrote: Do you know of any DASD subsystem that does not publish RPM information? I thought not. They still care. grin But kidding aside, I would suspect the last time it really mattered it would be a real 3990-3390 SLED. Am I missing something in your question here? I assume RPS sector numbers are *ignored* for ESS and newer devices. But, the IBM documentation does not confirm my assumption. Rather, they still fully document the RPS factors that are returned, how to calculate the sector value, etc. I noticed the tuning Redbook said that RPS delays cannot occur on ESS. But, says nothing about what, if anything, the sector number you (are expected to?) provide might be used for. Setting the sector number to x'FF' in the ECKD locate record parameter list disables the use of RPS. I'd like to see us do that for all modern DASD devices. -- Chris Langford, Cestrian Software: Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. z/FM - A toolbox for VM MVS at http://zfm.cestrian.com -- 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
Re: Rotational Positional Sensing (RPS)
In a message dated 7/24/2007 1:12:43 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Using a sector number of x'00' effectively disabled RPS on devices that did care. Not true. It forces the controller to position the track at index point, the very beginning of the track. A sector value of X'FF' is the only value that causes the controller to bypass setting an angular position. Of course, this could also be bypassed by not having a set sector command or a locate record command with a sector value of X'FF', but then you defeat the original intended purpose of RPS. Bill Fairchild Plainfield, IL ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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
Re: Rotational Positional Sensing (RPS)
Actually x'00' disconnects until position is just before index point so the following search Id starts with index point count at 1, maximum scan for the Id will be one revolution till next time index point is detected. Using x'FF' will not disconnect and search id starts at current position which could be just after index point so maximum rotation could be almost two revolutions till index point is detected twice. (IBM Mainframe Discussion List) wrote: In a message dated 7/24/2007 1:12:43 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Using a sector number of x'00' effectively disabled RPS on devices that did care. Not true. It forces the controller to position the track at index point, the very beginning of the track. A sector value of X'FF' is the only value that causes the controller to bypass setting an angular position. Of course, this could also be bypassed by not having a set sector command or a locate record command with a sector value of X'FF', but then you defeat the original intended purpose of RPS. Bill Fairchild Plainfield, IL ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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 .. For: [EMAIL PROTECTED] -- Chris Langford, Cestrian Software: Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. z/FM - A toolbox for VM MVS at http://zfm.cestrian.com -- 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
Re: Rotational Positional Sensing (RPS)
In a message dated 7/24/2007 1:43:48 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Actually x'00' disconnects until position is just before index point so the following search Id starts with index point count at 1, maximum scan for the Id will be one revolution till next time index point is detected. Using x'FF' will not disconnect and search id starts at current position which could be just after index point so maximum rotation could be almost two revolutions till index point is detected twice. All correct. Whether a disconnect occurs or not, and how many revolutions are the maximum search, RPS is not disabled for a sector value of X'00' and an angular position is established very near index point. No angular position is established if the value is X'FF', and the track's angular position is wherever it happens to be at that instant. How much rotation occurs after the angular positioning either occurs or is ignored depends on where the track is positioned, the next command, and what is on the track. The original intent of RPS was to disconnect until some point just before where the needed record was expected to be, then reconnect, thus minimizing the connected search time while maximizing the disconnect time which would allow other running channel programs to use the same channel. X'FF' does not cause a disconnect because a disconnect is not needed because there is no rotation needed to get to where the needed record is expected to be because wherever the track is at that instant is where the record is expected. Bill Fairchild Plainfield, IL ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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
Rotational Positional Sensing (RPS)
Does anyone know for sure which was the last DASD subsystem that cared about Rotational Positional Sensing (RPS) values? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Rotational Positional Sensing (RPS)
Do you know of any DASD subsystem that does not publish RPM information? I thought not. They still care. grin But kidding aside, I would suspect the last time it really mattered it would be a real 3990-3390 SLED. Am I missing something in your question here? Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Monday, July 23, 2007 7:30 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Rotational Positional Sensing (RPS) Does anyone know for sure which was the last DASD subsystem that cared about Rotational Positional Sensing (RPS) values? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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
Re: Rotational Positional Sensing (RPS)
Richards.Bob wrote: Do you know of any DASD subsystem that does not publish RPM information? I thought not. They still care. grin But kidding aside, I would suspect the last time it really mattered it would be a real 3990-3390 SLED. Am I missing something in your question here? I assume RPS sector numbers are *ignored* for ESS and newer devices. But, the IBM documentation does not confirm my assumption. Rather, they still fully document the RPS factors that are returned, how to calculate the sector value, etc. I noticed the tuning Redbook said that RPS delays cannot occur on ESS. But, says nothing about what, if anything, the sector number you (are expected to?) provide might be used for. Setting the sector number to x'FF' in the ECKD locate record parameter list disables the use of RPS. I'd like to see us do that for all modern DASD devices. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Rotational Positional Sensing (RPS)
In a message dated 7/23/2007 7:16:04 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: I assume RPS sector numbers are *ignored* for ESS and newer devices. Some are definitely NOT ignored and some other values may be ignored. The ones that are not ignored are the ones that are invalid; i.e., higher than the highest allowable number but also not equal to X'FF'. If your channel program has an invalid sector number, the ESS will fail your channel program with unit check - invalid parameter. If your number is valid, however, it would seem that the ESS will ignore it. This is an arguably preposterous choice of one or the other of only two actions. I personally think this is carrying downwards compatibility too far. Bill Fairchild Plainfield, IL ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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
Re: Rotational Positional Sensing (RPS)
Ed, Now that I can see why you asked the question, FWIW, I concur with your recommendation. I suspect Bill is correct about downward compatibility, but what person in their right mind would connect ancient devices to a current system. Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Monday, July 23, 2007 8:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Rotational Positional Sensing (RPS) Richards.Bob wrote: Do you know of any DASD subsystem that does not publish RPM information? I thought not. They still care. grin But kidding aside, I would suspect the last time it really mattered it would be a real 3990-3390 SLED. Am I missing something in your question here? I assume RPS sector numbers are *ignored* for ESS and newer devices. But, the IBM documentation does not confirm my assumption. Rather, they still fully document the RPS factors that are returned, how to calculate the sector value, etc. I noticed the tuning Redbook said that RPS delays cannot occur on ESS. But, says nothing about what, if anything, the sector number you (are expected to?) provide might be used for. Setting the sector number to x'FF' in the ECKD locate record parameter list disables the use of RPS. I'd like to see us do that for all modern DASD devices. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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
