Search390.com
Expert Question of the Week
August 6, 2001
=====================================
SPONSORED BY: Storage Decisions 2001
=====================================
Storage Decisions 2001 brings together the top storage industry
analysts and expert technologists to give you specific how-to advice
to set storage strategy, make key decisions and manage storage
effectively. This exclusive conference is FREE to those who qualify.
Apply today at www.StorageDecisions2001.com.
=====================================
=====================================
FEATURED TOPIC: Storage Management
=====================================
We understand that making storage decisions for your company can be
difficult. Therefore, we've put together a collection of resources to
help, including information about the upcoming Storage Decisions 2001
conference.
http://search390.techtarget.com/featuredTopic/0,290042,sid10_gci758921,00.html
--------------------------------------------------------------------
Welcome to Search390's Expert Question of the Week newsletter.
Remember, no question is too simple for Ask the Experts! If you have
a 390-related question, send it to [EMAIL PROTECTED] Selected
questions will be answered by our experts.
This week's question was answered by Mark Zelden, search390's OS/390
Systems Programming Expert.
THIS WEEK'S QUESTION:
Q: We are experiencing performance problems caused by system dumps in
the last three months on several of our systems. The dumps are from
CICS and are not dumping CSA and are generally not large dumps. The
delays are due to paging that (I believe) are caused by stealing by
the dump process. UIC is 180-200. The system has 395 MIPS with
storage of 1456M central and 1024 expanded. This seems like problems
we had way back in MVS 4.1 or 4.2.
A: You need to look at several things.
The most important thing to look at is your paging subsystem. The
impact of SVC dump processing on the system is related to how much
available storage (real and expanded) there is at the time of the
dump. If there is insufficient storage to contain the dump, then the
paging subsystem must be robust enough to minimize the impact.
Special code does exists in the system to manage DUMPSRVs real
storage and make it the first to go to aux.
A ROT (rule of thumb) is that your page data sets should not be more
than 30% utilized. This is a general rule that affects paging
performance. Also, page data sets should not share volumes with other
data sets so ASM can use suspend/resume processing to minimize
overhead. During any paging-burst, like an SVC dump, it's not so much
the size of the page data sets that matters, it's bandwidth. The more
page data sets you have, the better off you are. Make sure you have
at least four or more local page data sets that are large enough and
are on good performing devices. If you only have one or two local
page data sets and a "loved one" has to wait for a single page behind
an SVC dump, its performance will be impacted.
The second thing is to make sure you are not using the "Q=YES" option
for SDUMPs. You can verify this with the "DISPLAY DUMP,OPTIONS"
operator command. Q=YES will quiesce the system (set the system
nondispatchable) while dumping SQA and CSA (note that an individual
dump request can still do this on its own, but this option forces it
for all dumps). You can force "Q=NO" for all dumps with the CHNGDUMP
operator command. CHNGDUMP Q=NO makes some SVC dumps more difficult
to diagnose, but will reduce the impact to other address spaces not
participating in the dump. If you have a reoccurring problem that
requires CHNGDUMP Q=YES, IBM (or other vendor) support should tell
you to set that option.
One other thing to check is your DAE (dump analysis and elimination)
options. You should use the SUPPRESSALL parameter (as opposed to
SUPPRESS) to suppress as many dumps as is possible. If you specify
SUPPRESSALL, DAE will suppress more dumps because the VRADAE key in
the SDWA is not required to suppress a dump. If you omit both
SUPPRESS and SUPPRESSALL, DAE will not suppress any dumps. DAE
options are controlled by the use of the ADYSETxx PARMLIB member and
the "SET DAE=" operator command.
--------------------------------------------
If you have a question for Mark, submit it here:
http://search390.techtarget.com/ateQuestion/0,289624,sid10_tax287555,00.html
============================================
search390 OPERATING SYSTEMS DISCUSSION FORUM
============================================
Can anyone help search390 user "evanjaye," who posted the following
question on our search390 Operating Systems Discussion Forum:
"Hello. I am an aspiring IT professional whose latest project is the
following: Compare a specific functionality between 3 different
Operating Systems (eg. file systems, device mgmt, etc.). Can anyone
give me a topic and 3 OS's that I can use?"
To post feedback for "evanjaye" or check out other hot topics for
discussion, go to
http://search390.discussions.techtarget.com/WebX?50@@.ee83ff6.
============================================
search390 TIPS CONTEST
============================================
Have a great tip of your own that you'd like to share with the rest
of us? Then send it in. Our tip of the month contest has been
extended through the end of August, so there is still time to take
home the fabulous T-Rex remote control dinotronic dinosaur.
To submit your tip today, go to
http://search390.techtarget.com/tipsSubmit/1,289485,sid10,00.html
========================================================
If you would like to sponsor this or any TechTarget newsletter,
please contact Gabrielle DeRussy at [EMAIL PROTECTED]
========================================================
If you no longer wish to receive this newsletter simply reply to
this message with "REMOVE" in the subject line. Or, visit
http://search390.techtarget.com/register
and adjust your subscriptions accordingly.
If you choose to unsubscribe using our automated processing, you
must send the "REMOVE" request from the email account to which
this newsletter was delivered. Please allow 24 hours for your
"REMOVE" request to be processed.
