0

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

Timothée
  • 77
  • 7
  • You do not seem to mention DB2 anywhere so why tag it? Also, are you sure it is os/390 and not Z/OS as os/390, under that name, is no longer supported. – NicC May 16 '18 at 11:03
  • Sorry about the tag, it was because I'm working with DB2 but this specific problem is not related to DB2, you're right. Yes it is z/OS – Timothée May 16 '18 at 11:54

2 Answers2

0

From the manual

,pfcount Specifies the number of additional blocks you want window services to bring into the window each time your program references data that is not already in the window. The number you specify is added to the minimum of one block that window services always brings in. That is, if you specify a value of 20, window services brings in up to 21. The number of additional blocks ranges from zero through 255. Note that you get 1 block without asking.

NicC
  • 293
  • 1
  • 6
  • This is not really clear. When am I suppose to references data that is not already in the window? You can't move a view without ending it and creating it again with a fixed offset and span. So referencing data out of a window should never appen. – Timothée May 16 '18 at 11:58
0

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.

Valerie R
  • 1,769
  • 9
  • 29