Re: ILR005E PLPA PAGE DATA SET FULL
- From: DASDBill2@xxxxxxxxxxxx
- Date: 27 Jul 2005 07:35:57 -0700
In a message dated 7/26/2005 7:22:57 P.M. Central Daylight Time,
ronhawkins@xxxxxxxxxxx writes:
>Bill,
>This is brand new information, but I am not sure that it is correct. You
>state that simply butting PLPA and Common up against one another will cause
>ASM to treat them as one single dataset. I really don't think this is
>correct.
My comments in this post are based on observation of GTF-traced ASM channel
programs intermixed with others on the same device as opposed to formal
education in ASM.
I don't remember stating what you say I did, I do remember someone else did,
but it's a minor point since having them up against one another is the key
to reducing overhead no matter who stated it, as then ASM is able to treat
them as one single data. IBM went to great trouble to improve ASM's I/O
performance, so I do not think it is out of the question that they added a few extra
instructions to check for the case where PLPA and Common are allocated
immediately adjacent to each other. I don't know for sure that they do this. It
could be verified with a GTF trace.
If ASM does do this, then both extents together can be logically combined
into one extent for the purposes of filling in the Define Extent CCW's
parameters. Whenever any DASD I/O is started via SSCH, if any data transfer is to
take place to/from user data tracks then one of three commands must appear in
the chain before the first data transfer: (1) Set File Mask, (2) Define
Extent, or (3) Prefix (X'E7'), the undocumented command that is new with 2105.
Prefix subsumes all the parameters of the Define Extent and the first Locate
Record (or Locate Record Extended), so I will use the term Define Extent to
mean either the DX or PFX command. DX is used on 3990 controllers and PFX on
2105s. A Seldom Ending Channel Program (SECP) is suspended when any CCW in it
is fetched by the channel with the Suspend flag bit on. This channel program
does not end then - it gets suspended. When this SECP is to be restarted
via Resume Subchannel (RSCH), you don't start off the next bunch of CCWS with
another Define Extent because then you would violate the controller's rules
for Define Extent - only one allowed per channel program. The DX parameters
were saved when the SSCH happened and the DX command was executed. So the
controller knows the lower and upper bounds for all future resumptions of this
SECP. If the two page data sets (PLPA and Common) were not allocated together,
then whenever you needed to switch from one to the other you would have to
terminate the SECP with one more RSCH and then start a new SECP with an SSCH
and a DX specifying the extent of the other page data set on the same volume.
So having them adjacent saves one RSCH, one interrupt, and the elapsed
controller time to execute another DX command, but this savings only occurs when
ASM needs to switch from one of these two data sets to the other. If PLPA is
only one cylinder and Common is huge (for very large values of huge), then
ASM will not need to switch very often, so this overhead savings would hardly
ever happen.
>AFAIK the Seldom Ending Channel Program running to the Common Page Dataset
>will complete for any access to another dataset on the volume that wants to
>use that exposure.
Right. If a user wants to read/write data set X on a paging volume while
ASM has an active SECP running, IOS signals ASM which then terminates its SECP
with an RSCH that has only a NOP CCW in it with the Suspend flag bit off.
This causes the channel to end the SECP and generate an interrupt. Then IOS
does a SSCH to get the user's I/O started. Having any non-ASM data set on a
paging volume will impact paging from/to that volume whenever the non-ASM data
set is accessed. The same is true for any two data sets on the same volume.
If data set X is critically important, whether it is a DB2 file, a catalog,
a PDS, or a page data set, any accesses to data set Y on the same volume will
cause performance hits with whatever is accessing data set X. The exact
mechanism is slightly different if X is a paging data set, but there is impact.
> It doesn't matter if it is the PLPA page dataset or a
>backup of my CD collection titles. On a dedicated volume, the Seldom Ending
>Channel Program completes less often because the one Cyl PLPA minimises the
>activity to PLPA.
By "completes" I think you mean "ends" as opposed to "is suspended". When a
SECP is suspended, all that is necessary to restart it is an RSCH. But when
it "ends", it must first "be ended" by doing one more RSCH with only a NOP
CCW that has the Suspend flag bit turned off. This extra RSCH also causes an
interrupt which must be processed. If there is no other data set on the
volume being accessed, then the SECP can truly run forever, meaning it never
needs to "end", but it does get suspended. ASM transfers a maximum of 30 pages
per SECP, so whenever the 30th page is transferred then the SECP will be
suspended by adding a NOP CCW with the Suspend flag bit on.
Minimizing [my American spelling] the activity to PLPA in order to cause the
Common page data set to be used rather than PLPA is a totally separate issue
from how often the SECP must be ended as opposed to just suspended.
> Doesn't matter if it adjacent to Common, or on the last
>CYL of the volume - it will still cause the Common Page Dataset Channel
>Program to delete.
I think you meant something other than "delete", but I can't be sure what it
was.
>Greg Dyck posted a discussion on Seldom Ending Channel Program seven years
>ago, which included his advice on configuring PLPA and Common Page
Datasets.
>http://bama.ua.edu/cgi-bin/wa?A2=ind9809&L=ibm-main&D=0&O=D&X=2DEDDB1329D229
>429A&Y=ronhawkins%40i-cable.com&P=46510 is an interesting read. (Watch the
>wrap).
I read it. He gave no details on how allocating the two data sets adjacent
helps performance.
>It also reminded me that long running ASM Chains are not a good thing.
Long running chains, whether ASM or not, or not a good thing generally.
They could cause other applications to have to wait a very long time to do a
short I/O to the device being used by the long running chain. If a chain runs
long enough, it could also cause other sharing systems that want to do an I/O
to the device to experience the dreaded MIH message (Missing Interrupt
Handler) - Start Pending. If this I/O stays pending long enough, the other system
may try to stop the I/O that will never start by doing a HSCH (Halt
Subchannel). Then you will see the even more dreaded MIH - Halt Pending message.
This often causes operators and some sysprogs to go ballistic and think the
hardware is melting down. The same phenomenon, as viewed from another sharing
system, is caused by device reserve that doesn't get released for a long time.
If you have enough real storage or are a clever programmer using PCI
(explained below), you can build a chain that will run for 30 minutes and read in
every track on the device.
> Until the Channel Program ends or suspends none of the page-ins in that
chain are
>available to use.
I'm not sure that this is how ASM works, but if it does work this way then
it doesn't need to, because after the CCW is executed to transfer each page in
or out the very next CCW can have the PCI flag on (Program Controlled
Interrupt), which will cause an interrupt which is signalled to ASM so that ASM
will know that the read/write CCW for that page has ended successfully, and ASM
could then safely use that page if it was a page-in.
> It's like a train - doesn't matter how many carriages
>there are, everyone finishes the journey at the same time.
The PCI flag bit allows for some carriages to arrive before the engine,
caboose, or other carriages, but only if the engineer driving the engine chooses
to do so and writes the appropriate clever code.
Bill Fairchild
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Follow-Ups:
- RE: ILR005E PLPA PAGE DATA SET FULL
- From: Ron and Jenny Hawkins
- RE: ILR005E PLPA PAGE DATA SET FULL
- Prev by Date: Re: 54 Processors?
- Next by Date: Re: Routine name/srb
- Previous by thread: Re: ILR005E PLPA PAGE DATA SET FULL
- Next by thread: RE: ILR005E PLPA PAGE DATA SET FULL
- Index(es):