I have a single DB2 subsystem called DB2T in which many schemas are defined. The same tables exists in different schemas. We are creating new test regions by creating new schemas.
As part of this task,while creating a routine for a COBOL stored procedure, we are specifying the collection ID and the WLM environment. If the same COBOL stored procedure(no code change) is used for testing by multiple testing teams simultaneously, how do we define the routine? Since each team has a different schema/qualifier already, can we have a common WLM environment ? Or a new WLM environment has to be defined for each testing team(eventhough they use a different schema)?
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
WLM is managing system resources at the LPAR level. As usual, something of a balancing act is required -- define too few resources for WLM to manage and your system won't disntinguish sufficiently between workloads; define too many resources for WLM to manage and your system is spending more time on resource management than it should. The rough rule of thumb is that similar workloads should be classified together -- production online, production batch, qa, development online, and development batch (as an example). If you start breaking development batch into too many pieces for WLM to manage, you're going to be confusing the overall picture and possibly preventing WLM from managing the system adequately.
It all depends upon whether or not your site management thinks there is benefit from having different WLM policies for the different environments -- if not, use a single one but if so, use as few as will satisfy the management imperative.
As far as performance is concerned, the number of users and SPs are less, so I believe I can use the same WLM. But with 2 routine definitions of same stored procedure, using different schemas and same WLM, can 2 teams test simultaneously?
Another concern is, if incase I am changing the SP(stored procedure) and moving it to a different load library, will that affect the WLM environment usage?
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
I think you completely misunderstand WLM. WLM has absolutely nothing to do with individual load libraries -- in fact, "load library" is not even in the MVS Planning: Workload Management manual index. The number of users does not matter to WLM, either -- WLM is looking at EVERY job, EVERY started task, EVERY CICS task, EVERY DB2 task, EVERY TSO user, EVERY Unix System Services process running on that particular LPAR.
When you say "using different schemas and same WLM", what on earth do you mean? There is ONE and only one WLM policy in effect on a machine at any given time, and it governs batch work, started tasks, CICS, DB2, IMS, TSO, Unix System Services, and everything else being done on that LPAR. You may classify a particular workload into one WLM service class or another (based on name or job class or ...) but those service classes are all part of the one WLM policy.
WLM policy is set and controlled by the site -- and every site pretty much has its own WLM policy set. If you need to know specifics about your site's WLM policy, you absolutely cannot get those answers from this -- or any other -- forum as only someone working AT YOUR SITE will know the answers.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
DB2 stored procedures run in what are called WLM-controlled regions. This is in contrast to the past when all DB2 stored procedures ran in the DB2SPAS (DB2 Stored Procedure Address Space). So this question has nothing to do with WLM per se.
There may be other ways to set up multiple test regions, but the approach I have seen is to set up a separate WLM-controlled region for each test environment.
but the approach I have seen is to set up a separate WLM-controlled region for each test environment.
Yes! .... but the TS already misworded the whole shebang... he/she does not have different test environments in the <common> sense ( a DB2 subsystem for each test environment )
he/she simply has <one> test environment/DB2 subsystem with different owners for each occurrence of some set of tables
my suggestion in this case just stack all the SP into the same WLM pool, after all is just a test db2 subsystem
it would be different for a production system where some fine tuning could be required,
( different WLM pools with different policies/performance targets )
