Search code examples
zosmvs

IBM Window Services (DWS) csrevw function on MVS


I'm working on IBM MVS (z/OS) and trying to make Window Services working. On the function CSREVW I don't understand what the purpose of the parameter pfcount. Acording to the documentation this will ask to the window services to read more than one block after my program references a block that is not in my window. But how the window services is suposed to know that I tried to reference data that are not in my window? I mean, it can't know that I'm reading data out of my window if i don't call CSREVW or CSRVIEW again.

Maybe my major issue is that I have trouble to understand english but this seems clear to me...

Here is the link to the documentation, this is explained at pages 23-24 : http://publibz.boulder.ibm.com/epubs/pdf/iea3c102.pdf

I know this is a very specific problem about an IBM service and I apologize about that.

Thank you ! Tim


Solution

  • I think the problem you're having is that you need to understand a little bit about how the underlying objects behind the windowing service work in virtual storage.

    At the core, the various windowing services work to give you what amounts to a "private" page dataset. You allocate and reference storage, but the objects in that virtual space aren't really in memory - the system's page fault mechanism brings them in as you reference them. So yes, you're accessing data within a "window", but in reality, the data you expect to see may not be "paged in" at that moment.

    Going a little deeper, when you first allocate the object, the virtual storage it's mapped to has all of the pages marked "invalid" in the underlying page table entries. That means that as soon as you touch this storage, a page fault interrupt occurs. At this point, the operating system steps in and resolves the page fault by brining the necessary data into memory, then your program continues, oblivious to all of this processing on your behalf. You're correct that you're just referencing data within the window, but there's a lot under the covers going on to support this.

    This is where PFCOUNT comes in...

    Let's say you have structures that are, say, 64K long inside your virtual window. It would be sloppy and slow to reference each page of this structure and cause a page fault each time. Much better would be to use PFCOUNT to cause the page you reference and all 15 other pages needed by your object to be paged-in with a single operation. Conversely, if your data was small and you were highly random about how you access it, PFCOUNT isn't going to help you - the next page you reference could be anywhere, and it's actually wasteful to have a large PFCOUNT since you end up bringing in a lot of data you never use.

    Hope that makes sense - if you'd like a challenge, take yourself a system dump and examine the system trace entries as you reference data...you'll see a very distinct pattern of page faults, I/O and resumption of your program, and hopefully it will all make sense to you.