There appears to be multiple questions in this one little thread.
The following is what I generally recommend for many of our large
customers. Your Mileage will vary.
1. If you are lucky enough to have 70 million identical transactions running
on your system, and they all have a SLA of 100% < .1 second, then I guess
the Region Goal is working for you. If you are like most other sites, with
different transactions with different SLAs, and the potential for the work
to
grow, I'd still recommend Transaction Goals. Since you can set it up by
region(s),
it is not difficult to determine what is needed, and define it. I would
suggest a
Default Service Class with the majority of the transactions defaulting into
it, a
Service Class with "loved" transactions (a select handful), and a Service
Class for
"not loved" transactions (those driving slow devices or those that really
look like batch).
You can have Production vs. Development vs. Ad-hoc specifications. You can
have High, Medium,
Low specifications as appropriate.
NOTE: Look for any presentation at the Share web site from Steve Samson for
the why you want to do
this aspect of the discussion. Cheryl Watson's QSP doesn't really
segregate CICS work; but it
was designed for a Quick Start. If you were fortunate enough to take any
of her Performance
Classes, I think there was some good information on proper Service Classes.
You'll find several
of my WLM Share sessions at the Share web site, or email me privately and
I'll send them to you.
2. It is the general recommendation that you have no more than 25-35 ACTIVE
Service Class Periods
on an LPAR (could be a few less, could be a few more). For CICS/IMS
Transaction Service Classes,
you do have to consider the Online Topology. Single AORs may have a
different Goal, as compared
to a MRO topology, as compared to a complex topology connecting to DBMS or
WAS subsystems. Also,
do not combine CICS Regions managed to the Region and Transactions into the
same Service Class.
Same NOTE from #1.
3. I also recommend combining TSO and the Interactive USS work into the same
Service Class (with 2 or
3 Periods- please avoid the 5 or 7 period varieties). Be sure to take the
long-running Daemon work
and assign it to a similar Started Task Service Class (SYSSTC, STCHI, etc.).
4. I also recommend NOT dumping unnecessary work into SYSSTC. Not managing
work to a goal might work
on a under-utilized system, but not really what you want to do. IRLMs do
belong in SYSTEM or SYSSTC
(LOCKs should be processed at the highest priority). Some might say that
the MSTR address space of
the susbsystem can go into SYSSTC. Some put DB2DIST in there. I like
having 1 or more DB2 managed
Service Classes based on Availability or SLA requirements.
----------------------------------------------------------------------
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
