Re: HPSPO query

Discussion created by ca.portal.admin on Feb 17, 2006

I am glad you have asked this question as it is all very confusing I
will attempt to explain my understanding of the whole thing and the hope
some one will correct me.

First pre HPSPO

Protect ON at system level and ON at program level. CPU overhead is
horrendous I did a TPNS run and the CPU increase was 100% plus. When I
mention this to some CA people and they did comment that it could be
The reason for the massive overhead is the way works.
With protect on at the system level IDMS tasks cannot have user storage
in the same OS page so for a single IDMS task all it's user storage is
in OS pages that do not contain storage for any other task or any system
These are pages owned by the task.
When protect is on at the program level before IDMS gives control to the
program it will change the protect keys of all the pages owned by the
task to the sysgen alternate key then change they key it is running is
to the alternate key. Then if the task tries to write outside the pages
it owns the OS gives a S0C4.
The change key for the pages is very CPU expensive and happens at every
IDMS call thus the massive CPU overhead

Protect ON at system level and OFF at program level.
As I stated above protect on at system level will allocate user storage
to unique MVS pages. This CA say make the internal allocation of
storage, in CPU terms, more efficient but can mean that you need large
storage pools for user storage. Since protect is off at the program
level no protect key changes are required so no CPU overhead.

Protect OFF at system level. This means that IDMS tasks can share OS
pages for USER storage and CA say that this increases the CPU for the
allocation of USER storage. With protect off at the system level than
the program level protect option is ignored.

Now Post HPSPO

I believe that all I have said above is still true.

What HPSPO does is provide a mechanism to stop applications corrupting
program pools and system storage pools.

For it to be active you must have USER only storage pools.

What I think happens is that IDMS sets all the pages in the USER only
storage pools to the sysgen alternate protect key and this is done just

Before IDMS gives control to a user program all it now does is change
the execution protect key to the sysgen alternate protect (not CPU

The application CAN overwrite other application storage but NOT any
program pools or system storage.

So a bad application program can cause other application programs to
have problems but cannot cause a CV abend due to corrupting IDMS control
blocks etc.

That is my understanding.

I welcome all comments and contradictions