I/O should not be done directly to or from any page whose real page backing the virtual page is not fixed. If the real-to-virtual relationship is not guaranteed to last as long as the I/O operation runs, then an I/O request may start writing data out from the page, before the I/O finishes the operating system may change the real address backing the virtual page, and the data that is being written out will continue being written out from the original real page which may or may not be assigned to any virtual page at that instant. Nothing will crash as a result, but the data written out is almost certainly partly wrong, and it might be used to compromise the system's or user's data security.
If, however, you do a read I/O into a virtual page whose real address changes while the I/O is in flight, then the real address that was formerly used for the virtual page may or may not be assigned immediately to another page. If it is, then some randomly chosen other user will have one of his pages hosed. If it is hosed before that other user alters the page or before the operating system zeroes out the page (if this is necessary), then nothing bad will happen to that other user. But If the other user starts making use of that page while the I/O is still running, then the results are unpredictable and almost certainly really bad for that user. If it is not assigned to another user for a long time, then nothing will be hosed, but the user who did the read I/O will not be able to find some of the data that was read. In general, either of the above scenarios is double plus ungood. Depending on how the IXG macro works and on exactly what the doc said, it may be that the following is true: you code the IXG macro and point it to some DREF storage to use "as a buffer"; the IXG macro transfers control to a module that knows how to do I/O properly; this module acquires a small piece of FIXED storage for whatever I/O operation is necessary to find the member name; the module does the I/O, then copies the member name from the FIXED I/O buffer into the DREF page you told IXG to use; then the module frees up the FIXED storage it used behind the curtains before returning control to your program. The member name is now (Voila!) in the DREF storage, the I/O worked correctly, and nobody's storage has been hosed. Or it may be a doc error. Or it may be that no I/O is really necessary for the IXG service to find the member name. In any case, if the IXG service does I/O directly to a DREF page, then this is an APARable error. I suggest you re-read the macro's doc very carefully, and then use FIXED storage unless the doc clearly explains why DREF will work. Bill Fairchild -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Micheal Butz Sent: Wednesday, February 22, 2012 2:52 AM To: [email protected] Subject: Re: Difference between DREF storage and Page fixed storage Please explain I/O should not be done to DREF using "DREF storage as buffer area for I/O" When I used sysplex IXG macros to obtain member information the doc said use DREF storage -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Edward Jaffe Sent: Wednesday, February 22, 2012 2:46 AM To: [email protected] Subject: Re: Difference between DREF storage and Page fixed storage On 2/21/2012 10:47 PM, Jim Mulder wrote: > The operating system reserves the right to exchange the frame > backing any DREF page (LSQA or SQA) at any time. Which is why I/O should not be done to DREF storage, only to fixed storage. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 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: 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
