|
Problem(Abstract) |
If you experience the following error:
IEF352I Address Space Unavailable condition or IEA602I ADDRESS SPACE
CREATE FAILED and you see that a high number of reserved address spaces
are being used, then this is a hardware problem. Starting with z/OS® 1.9,
REUSASID=YES is an alternative for this problem. |
|
|
|
Cause |
The root cause of this problem stems from the hardware
prior to z/OS 1.9. Starting with z/OS 1.9, there is an alternative by
using the REUSASID=YES keyword on the START command.
Review the MVS® Extended Addressability Guide for an explanation on
RSVNONR. You can find the MVS Extended Addressability Guide by going to
the IBM®
Publications Center and searching publications for "MVS Extended
Addressability Guide" to find the publication for your specific z/OS
release.
There is a LXSET SYSTEM(YES) macro in the IBM® WebSphere® Application
Server Daemon. The MVS Extended Addressability guide points out that
address spaces that use SYSTEM(YES) on the LXSET will be nonreusable for
the life of the IPL.
The WebSphere Application Server Control Regions (CRs) use SYSTEM(NO).
However, the RRS address space PC's over to the CRs and the CRs PC over to
RRS. Since the WebSphere CR address space IDs are "known" by the RRS
address space, these WebSphere CR ASIDs that were brought down will not be
reused until RRS (and other resource managers involved) is recycled or you
IPL, prior to z/OS 1.9 and the use of the REUSASID=YES keyword.
This may be a condition more limited to a test system in that in a
production system since you are more likely to recycle WebSphere
Application Server Control Regions in a test system whereas in production
they would be recycled less frequently.
Prior to z/OS 1.9, this behavior of reserving ASIDs from reuse is dictated
by the current hardware design. The hardware is attempting to prevent a PC
into an address space which has been dismantled and reconstructed for some
other purpose like a TSO user or OMVS shell. z/OS 1.9 introduced the
REUSASID=YES keyword on the START command to make the address space
reusable. |
|
|
Resolving the
problem |
You can resolve or avoid this problem by doing one of the
following:
1. You can increase RSVNONR in your IEASYSxx PARMLIB member. See the
MVS Initialization and Tuning Reference for the details. You can
find the MVS Initialization and Tuning Reference by going to the IBM
Publications Center and searching publications for "MVS
Initialization and Tuning Reference" to find the publication for your
specific z/OS release.
Find a balance between the MAXUSER and RSVNONR parameters in the parmlib
member IEASYSxx. If you increase the value of RSVNONR this will increase
the number of ASIDs that are available. The combination of MAXUSR, RSVNONR
and RSVSTRT must not exceed the maximum number. The balance comes in
making sure there is enough CSA storage to handle the numbers you choose.
If you make changes to these IEASYSxx settings, you will need to IPL to
pick up the changes.
2. Another alternative is to shut down and restart RRS and the other
resource managers(DB2®,WebSphere MQ, etc) to allow the ASIDs to be added
back to the pool. The WebSphere Application Server for z/OS environment
should be stopped also prior to shutting down RRS. You can determine how
disruptive this is in your environment.
3. Starting with z/OS 1.9, you can use the REUSASID=YES keyword on the
START command to make the address space reusable. Please refer to the z/OS
1.9 level of the MVS® Extended Addressability Guide publication and
search on REUSASID for additional details. The REUSASID=YES is currently
only an alternative for WebSphere Application Server for z/OS servers that
are started with the MVS Console START command. Servers that are started
through the Administrative Console currently do not have the option to use
this keyword. If this is considered in the future for the WebSphere
Application Server for z/OS product, this technote will be updated with
details of availability of such an option. |
|
|
|
|
|
|