On Sat, Jun 8, 2019 at 12:53 PM Jim Mulder <[email protected]> wrote:
> If you will have the storage fixed for a longer period of time than you
> would want
> a CONFIG STOR....,OFFLINE to be delayed, then you should specify LONG=YES.
>
I all my years as a sysprog, back to OS/VS1, I have _never_ had the need to
take storage off line.
> Similarly, in that case, you should use SYSEVENT TRANSWAP instead of
> SYSEVENT DONTSWAP to become nonswappable.
>
Thanks. I had forgotten about that.
>
> Note that specifying FIX=LONG on STORAGE OBTAIN does not FIX the
> storage. It is simply a hint to RSM that you intend to do a
> PGSER FIX, LONG=YES later, so that if RSM backs the page before that,
> it will try to use a frame that won't require the page to be moved when
> you subsequently do FIX it.
>
Ah. Thanks. So, in my case, I will issue the PGSER immediately after the
STORAGE OBTAIN.
I am guessing that I am overdoing this thing. But I "feel better" about
page fixing 1 Meg of real { LOC=(1,PAGESIZE1M) } for the duration of my
program than I am doing iterations of PGSER functions to FIX and FREE. I
don't know the CPU cost of the PGSER. Also, I plan to do a SYSEVENT
TRANSWAP after doing the FIX so that I can get & store the real address of
the page frame once. This will reduce the time I need to be in supervisor
state to 1 instruction at the beginning of the program.
As a reminder, this is in support of my rewriting MVSCPCMD (issue CP
command via Virtual Console Facilty -- diag x'08' ) to use what I consider
to be more modern instructions & facilities. Which I am doing strictly
because I am bored out of my mind while our new management (just got bought
by United Healthcare) decides what they are going to do with our I.T.
department. The UHG company we are now a part of, United Healthcare One,
doesn't even have an I.T. department. Their I.T. is handled by another UHG
company - Optum. I don't know anything, but I wouldn't be surprised to be
involuntarily "retired" in a couple of years.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
> Poughkeepsie NY
>
>
--
This is clearly another case of too many mad scientists, and not enough
hunchbacks.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
