Thread: IBM DB2 v8.1 & Workload Manager
01-02-08, 11:46 #1Registered User
- Join Date
- Jan 2008
- Oklahoma City, Ok
Unanswered: IBM DB2 v8.1 & Workload Manager
I'm installing IBM z/OS v1r7m1 operating system on a IBM z/OS 2066 mainframe with DB2 version 8.1 as well.
I'm relatively new to IBM DB2 v8 and would like someone to advise me on IBM workload manager environments.
IBM shipped this system to us with DB2 installation job DSNTIJSG pointing to multiple wlm environments which are listed as: WLMENV, WLMENV1, WLMENV2, WLMENV3, WLMENV4 and WLMENV5.
In IBM's DB2 Installation process, IBM susggests using the following to name your DB2 WLM environments.
1st 4 characters, DB2A, name of DB2 SYSID, which I understand why.
5th character either D for Development, P for production.
6th character either E for Executable or B for Build.
7th for easy identification of the environment stored procedures types
* J = Java stored procedures
* P = C/C++ stored procedures
* S = SQL Stored procedures
* C = Cobol Stored Procedures
* R = Rexx stored procedures
* U = DSNUTILS & DSNUTILU procedures.
and the 8th a wild card 1 or 2 for the number of this environment.
All of IBM's SYSIBM.SQLxxxx procedures were pointing to WLMENV5, which I created a DB2APEJ1 with a numtcb=8, for Java Stored procedures. Am I assuming a correct environment type for WLMENV5 to xlink to DB2APEJ1 (Java stored procedures).
IBM shipped SYSPROC.DSNTBIND & SYSPROC.DSNTPSMP pointing to REXX_WLMENV, and I xlinked this to DB2APER1 for REXX and a NUMTCB=1. Am I assuming a correct environment for REXX_WLMENV to xlink to DB2APER1 (REXX stored procedures).
IBM DB2 v8 books suggested that SYSPROC.DSNUTILS & SYSPROC.DSNUTILU be in their separate WLM environment so I moved them from WLMENV1 environment to DB2APEU1 with a NUMTCB=1, based on IBM's redbooks. Am I assuming a correct separation for DSNUTILS & DSNUTILU to xlink to DB2APEU1 (Utilities stored procedure).
SYSPROC.DSNTJSPP wen from IBM's WLMENV3 to my DB2APEP1 for C/C++ Stored procedures. Am I assuming a correct separation for this to a C environment.
I'm unsure on where to place the following stored procedures and hoped that someone can advise as IBM's books limit any references to the following:
SYSPROC.DSNWZP, was WLMENV1, now = ?
SYSPROC.DSNWSPM, was WLMENV1, now = ?
SYSPROC.WLM_REFRESH, was WLMENV, now = ?
SQLJ.INSTALL_JAR, was WLMENV, now = ?
SQLJ.REMOVE_JAR, was WLMENV, now = ?
SQLJ.REPLACE_JAR, was WLMENV, now = ?
SYSPROC.DSNACICS, was WLMENV2, now = ?
SYSPROC.DSNACCOR, was WLMENV, now = ?
SQLJ.DB2_INSTALL_JAR, was WLMENV, now = ?
SQLJ.DB2_REMOVE_JAR, was WLMENV, now = ?
SQLJ.DB2_REPLACE_JAR, was WLMENV, now = ?
SQLJ.DB2_UPDATEJARINFO, was WLMENV, now = ?
Any suggestions would be appreciated or even a suggestion of which book to review, I've been through SG24-7083 and it's not much help on the incompleted ones listed above.
Thanks in advance for suggestions.
01-02-08, 15:19 #2Registered User
- Join Date
- Jan 2007
- Jena, Germany
It's hard to provide any real useful suggestions because we don't know how you set up your WLM environments. Did you follow exactly the suggestions you cited above?
I don't know the reason why the suggestion was given in the books to separate WLM environments based on the programming language. For PROGRAM TYPE MAIN routines, it wouldn't make any difference because the language environment is initialized when the procedure (or UDF) is called and then destroyed at the end of the procedure execution (assuming STAY RESIDENT NO). But maybe there are some caching effects to take advantage of - I don't know. You could place all procedures in just a few (or the same) WLM application environment. The only routines where you should be careful are DSNUTILU and DSNUTILS. Those procedures must run in an environment with NUMTCB=1 so that two concurrent calls don't collide.
To answer your question, you could run the following query to determine the host language for each procedure in question:
SELECT language, name FROM sysibm.sysroutines
SYSPROC.DSNWZP, was WLMENV1, now = DB2APEAx (A = Assembler)
SYSPROC.DSNWSPM, was WLMENV1, now = DB2APEAx
SYSPROC.WLM_REFRESH, was WLMENV, now = DB2APEAx
SQLJ.INSTALL_JAR, was WLMENV, now = DB2APEPx
SQLJ.REMOVE_JAR, was WLMENV, now = DB2APEPx
SQLJ.REPLACE_JAR, was WLMENV, now = DB2APEPx
SYSPROC.DSNACICS, was WLMENV2, now = DB2APEAx
SYSPROC.DSNACCOR, was WLMENV, now = DB2APEPx
SQLJ.DB2_INSTALL_JAR, was WLMENV, now = DB2APEPx
SQLJ.DB2_REMOVE_JAR, was WLMENV, now = DB2APEPx
SQLJ.DB2_REPLACE_JAR, was WLMENV, now = DB2APEPx
SQLJ.DB2_UPDATEJARINFO, was WLMENV, now = DB2APEPx
Personally, I think something like the following scheme makes more sense:
- put all DB2-supplied stored procedures (see DSNTIJSG) into one WLM application environment (except for DSNUTILU/DSNUTILS)
- for each product that comes with its own stored procedures, use a dedicated WLM application environment
- if necessary, you can use multiple environments per application
IBM DB2 Analytics Accelerator
IBM Germany Research & Development