We've probably discussed this before, but I thought it was worth another
mention. I didn't realize the impact this had on my z/OS 1.8 migration
until yesterday (migration was from z/OS 1.6 and the APAR was for
z/OS 1.7, z/OS 1.7.1 and z/OS 1.8). The PTF for OA14391 came
applied / accepted in my ServerPac.
This can get confusing...(read APAR OA14391)
On z/OS 1.3 - z/OS 1.6 and z/OS 1.7-z/OS 1.8 prior to OA14391, if
REGION=0 was specified the default MEMLIMIT was set to NOLIMIT.
>From the JCL reference (even in 1.8):
"If no MEMLIMIT parameter is specified, the default is the value defined
to SMF, except when REGION=0K/0M is specified, in which case the default
is NOLIMIT."
So based on this, my IEFUSI looked for STCs with REGION=0 and did
nothing in regards to MEMLIMIT - leaving them with MEMLIMIT=NOLIMIT.
My IEFUSI only allows REGION=0 for STCs and since it always gave them
the maximum PVT and EPVT available prior to 64-bit, I adopted the
same philosophy of allowing all the 64-bit storage also. So far, so good.
After my z/OS 1.8 migration (with the APAR applied) suddenly all these
REGION=0 STCs get the MEMLIMIT set to approximately the EPVT size
with IEFUSI+REG=0 being the source of the MEMLIMIT value (where
the source was previously REGION=0).
>From APAR OA14391 and now The MVS Extended Addressability Guide:
"| Just before the job runs,
| the system looks for a
| MEMLIMIT setting in the
| IEFUSI installation exit.
| That setting overrides
| all other settings
| However, if REGION=0 was specified,
| resulting in maximum MEMLIMIT for the
| job, but IEFUSI provides a finite
| REGION without limiting MEMLIMIT, the
| system sets MEMLIMIT to approximately
| the same value as the REGION setting
| in the IEFUSI exit. "
Even though I remember updating 2 of my execs (REXXSTOR and
RXSTOR64) late last year for the new MEMLIMIT source that was introduced
in that APAR (IEFUSI + REGION=0) I didn't realize what this really
meant until yesterday when I ran my RXSTOR64 exec on one of my
z/OS 1.8 LPARs.
So I've updated my IEFUSI to force MEMLIMIT=NOLIMIT for STCs with
REGION=0. This is essentially the same behavior I've had since I updated
my IEFUSI for MEMLIMIT under z/OS 1.4.
After reading this you may be concerned, but probably there is not much
reason to be. From what I have seen, all IBM z/OS code ignores IEFUSI
and sets MEMLIMIT as an auth program (also see past discussions in the
archive related to DB2). I don't think the most recent CICS TS does that
however and neither do some ISV products that use 64-bit (DATACOM for example),
so this could have a potential impact on your shop.
<plug>
If you want to examine what is on your system, pick up a copy of my
RXSTOR64 exec from my web site or CBT file 434.
</plug>
BTW, when running RXSTOR64 on z/OS 1.8 I noticed that Health Checker
allocated 64-bit shared storage, but has no objects allocated (unless my
code is wrong or the control blocks are wrong). I wonder why.
Cheers,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
