Tommy Tsui wrote:
hi all,
we found that many jobs abended with 878-04 after upgrade CPU from 2064 to
2094 (first day batch) . There are no error when runnng on 2064 machine. any
shop have this problem??
Is there any control-block changed after upgrade CPU??/
any comment will be appreciated
<snip>
You didn't mention whether any software changes were concurrent with the
upgrade. Typically, at least some supporting PTFs are installed for a
server upgrade, and often other configuration changes are made
concurrently. Both can affect the virtual storage map and lead to what
you see.
In addition to added code in PTFs, which can move the NUCLEUS and LPA
boundaries, some modules are loaded into the nucleus only when the
configuration requires them, which can likewise move the NUCLEUS's upper
and lower ending boundaries, but I've no clue whether that could or does
apply to your particular configuration change.
Got an RMF report that shows the storage boundaries from before, and one
from after? No? How about a dump from which you can find and/or format
the GDA (Global Data Area)? Basically, you want to look at the amount
of CSA and ECSA before and after in addition to the amount of SQA and
ESQA before and after, and, I suspect, figure out what to specify to
regain adequately-sized storage areas.
Note that (E)SQA allocation requests will be satisfied from (E)SQA if
available, and from (E)CSA afterward if necessary. To be unable to
satisfy the allocation request, you have effectively run out of both.
The (E)CSA areas are ended on segment (1 MB) boundaries, and that can
add considerably to the amount of available (E)CSA you specify. In the
event that the sizes of other storage areas (Nucleus,
FLPA/PLPA/MLPA/LPA, SQA) conspire to move the end of your (E)CSA
specifications closer to their nearest 1 MB boundaries, the amount of
available space can be reduced considerably. The worst case is to
*just* cross one going in the wrong direction (toward the 16 MB line in
both cases), in which case you can lose nearly 1 MB of CSA, ECSA, or both.
You should be cognizant of your virtual storage map, and periodically
adjust your (E)CSA specifications to plant the end of both *specified*
areas somewhere near the middle of two segment boundaries. This will
generally keep day-to-day changes from making you cross a boundary
unaware, helping prevent surprises. In my opinion, doing this as part
of migrating to each new release is a good idea and likely to be
adequate most of the time. However, I have not tested this assumption
in a production environment in over 15 years, and your mileage may vary.
This topic from Init & Tuning might be helpful, too:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e280/49.8?ACTION=MATCHES&REQUEST=csa&TYPE=FUZZY&SHELF=EZ2ZO10j&DT=20070516223132&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
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
