WLM Stored Proc Appl Env Names

Charles Crockett

WLM Stored Proc Appl Env Names
We are setting up stored procs for the very first time (never used DB2
SPAS, so conversions is not an issue) so going with WLM, and primarily
plan to run IBM procs only (ie. PQ62695 for DB2 Connect and maybe
utilities - SYSPROC.DSNUTILS), we don't plan (right now) to write any
in-house procs. We run 3 single image DB2s, no data sharing.

1. Would people recommend that we include the subsystem name in the
Appl Env Name? Or is it desirable to reuse the same Appl Env Name in
multiple DB2 systems?

2. If people use the &IWMSSNM for multiple DB2 systems, what problems
does that create on the Proc Name if that is coded for a single DB2
system?

Any other tips of how one might do things differently, if you had it to
do all over again?



Charles Crockett D1
DB2 Contractor assigned to
Information Technology Services
Wisconsin Public Service Corp
(920) 433-2258 (voice)
(920) 433-5747 (fax)
e-mail: [login to unmask email]

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Avram Friedman

Re: WLM Stored Proc Appl Env Names
(in response to Charles Crockett)
Non SYSPLEX non datasharing
I suggest different WLM application environments for each DB2 subsystem.
In addition plan on having many application environments per DB2
subsystem.
The example you mention DSNUTILS requires its own application
environment.
The operating system commands to quiese, start and stop WLM application
environments are used frequently. To limit there scope to a single user
application area or other division one needs several WLM environments.
As I recall the default configuration specified in install job DSNTIJSG
uses about 6 environments for V7.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Charles Crockett
Sent: Tuesday, December 14, 2004 2:21 PM
To: [login to unmask email]
Subject: WLM Stored Proc Appl Env Names

We are setting up stored procs for the very first time (never used DB2
SPAS, so conversions is not an issue) so going with WLM, and primarily
plan to run IBM procs only (ie. PQ62695 for DB2 Connect and maybe
utilities - SYSPROC.DSNUTILS), we don't plan (right now) to write any
in-house procs. We run 3 single image DB2s, no data sharing.

1. Would people recommend that we include the subsystem name in the Appl
Env Name? Or is it desirable to reuse the same Appl Env Name in multiple
DB2 systems?

2. If people use the &IWMSSNM for multiple DB2 systems, what problems
does that create on the Proc Name if that is coded for a single DB2
system?

Any other tips of how one might do things differently, if you had it to
do all over again?



Charles Crockett D1
DB2 Contractor assigned to
Information Technology Services
Wisconsin Public Service Corp
(920) 433-2258 (voice)
(920) 433-5747 (fax)
e-mail: [login to unmask email]

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Barbara Koenen

Re: WLM Stored Proc Appl Env Names
(in response to Avram Friedman)
We actually went from a proc naming scheme linked to subsystem name to a
generic proc naming scheme, once my z/OS sysprog got it through my head
that WLM AE definitions are sysplex wide.

If you do not want to share WLM AE definitions among subsystems, then
you can link proc names to subsystem names. If you do want to use the
same WLM AE for more than one subsystem, we found we needed a more
generic proc name.

This is assuming your DB2s are all in the same sysplex. If not, it
doesn't matter, since your WLM AE definition can point to different
procs if they are on different sysplexes.

For example, we had subsystems DB2A and DB2B in a sysplex. We had
initially set up WLM AE WLMENV1 pointing to proc DB2AWLM0 and WLM AE
WLMENV2 pointing to proc DB2BWLM0, thinking we needed WLMENV1 for DB2A
and WLMENV2 for DB2B.

We now have a naming scheme more like this:

WLM AE WLMENV1 points to proc WLMENV1
WLM AE WLMENV2 points to proc WLMENV2

We do use &IWMSSNM which passes in the correct subsystem name when
executing the proc. In that case it doesn't matter what subsystem name
you have coded in the JCL. I have base subsystem name in all my proc
JCL, e.g. DB2A.

Thus if we have SP calls using WLMENV1 from both DB2A and DB2B at the
same time, you'll see 2 instances of started task WLMENV1 running.

That may be the only confusing part. You have to look into the started
task output to see what subsystem each instance was started by.

However we decided this bit of look up was worth not having to set up
separate WLM AE definitions for each subsystem in a sysplex. Even if
you are only using them for the IBM delivered SPs, some of those want
their own WLM AE, so either you'd need several for each subsystem, or
just share them.


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Tuesday, December 14, 2004 1:21 PM
To: [login to unmask email]
Subject: WLM Stored Proc Appl Env Names


We are setting up stored procs for the very first time (never used DB2
SPAS, so conversions is not an issue) so going with WLM, and primarily
plan to run IBM procs only (ie. PQ62695 for DB2 Connect and maybe
utilities - SYSPROC.DSNUTILS), we don't plan (right now) to write any
in-house procs. We run 3 single image DB2s, no data sharing.

1. Would people recommend that we include the subsystem name in the Appl
Env Name? Or is it desirable to reuse the same Appl Env Name in multiple
DB2 systems?

2. If people use the &IWMSSNM for multiple DB2 systems, what problems
does that create on the Proc Name if that is coded for a single DB2
system?

Any other tips of how one might do things differently, if you had it to
do all over again?



Charles Crockett D1
DB2 Contractor assigned to
Information Technology Services
Wisconsin Public Service Corp
(920) 433-2258 (voice)
(920) 433-5747 (fax)
e-mail: [login to unmask email]

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Cathy Taddei

Re: WLM Stored Proc Appl Env Names
(in response to Barbara Koenen)
I use the DB2 subsystem name in the WLM application environment name,
and the proc name is the same as the application environment name. For
each DB2 subsystem, I have 2 application environments: ssidWLM, and
ssidSP1. I use ssidWLM for all DB2 system-related stored procedures (I
go through DSNTIJSG and edit all application environments to be the
same, except for the one with NO WLM). I use ssidSP1 for user stored
procedures. This makes it very easy for developers to find their output
from Cobol DISPLAY's (which I discourage) or their abend dumps.

So far this has worked very well, although I was tinkering with some
REXX stored procedures and having issues (don't remember exactly what
they were), so I may be persuaded to create a separate AE for Rexx in
the future. The MVS setup is a snap, the only pain is security. But
overall, I am very satisfied with the way this has worked for us. Our
use of stored procedures has been very limited -- if we start using them
a lot more, I might decide to create more application environments for
them, and would create ssidSP2, and so forth.

Regards,
Cathy

p.s. If you allow developers to do Cobol DISPLAY's, then define their
stored procedure with RUN OPTIONS 'MSGFILE(SYSOUT,FBA,121,0,ENQ)'. This
will make them serialize on SYSOUT and prevent perplexing problems.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Charles Crockett
Sent: Tuesday, December 14, 2004 11:21 AM
To: [login to unmask email]
Subject: WLM Stored Proc Appl Env Names

We are setting up stored procs for the very first time (never used DB2
SPAS, so conversions is not an issue) so going with WLM, and primarily
plan to run IBM procs only (ie. PQ62695 for DB2 Connect and maybe
utilities - SYSPROC.DSNUTILS), we don't plan (right now) to write any
in-house procs. We run 3 single image DB2s, no data sharing.

1. Would people recommend that we include the subsystem name in the
Appl Env Name? Or is it desirable to reuse the same Appl Env Name in
multiple DB2 systems?

2. If people use the &IWMSSNM for multiple DB2 systems, what problems
does that create on the Proc Name if that is coded for a single DB2
system?

Any other tips of how one might do things differently, if you had it to
do all over again?



Charles Crockett D1
DB2 Contractor assigned to
Information Technology Services
Wisconsin Public Service Corp
(920) 433-2258 (voice)
(920) 433-5747 (fax)
e-mail: [login to unmask email]

------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

======

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Myron Miller

Re: WLM Stored Proc Appl Env Names
(in response to Cathy Taddei)
My client does something similar. We have ssidENVx for the WLM name and append
a 1 on the WLM name for the actual SP region where ENVx is the application
environment for the developer - relates to the Table schema. We have a large
number of Stored procedures and this has been working very well.

Myron
--- "Taddei, Cathy" <[login to unmask email]> wrote:

> I use the DB2 subsystem name in the WLM application environment name,
> and the proc name is the same as the application environment name. For
> each DB2 subsystem, I have 2 application environments: ssidWLM, and
> ssidSP1. I use ssidWLM for all DB2 system-related stored procedures (I
> go through DSNTIJSG and edit all application environments to be the
> same, except for the one with NO WLM). I use ssidSP1 for user stored
> procedures. This makes it very easy for developers to find their output
> from Cobol DISPLAY's (which I discourage) or their abend dumps.
>
> So far this has worked very well, although I was tinkering with some
> REXX stored procedures and having issues (don't remember exactly what
> they were), so I may be persuaded to create a separate AE for Rexx in
> the future. The MVS setup is a snap, the only pain is security. But
> overall, I am very satisfied with the way this has worked for us. Our
> use of stored procedures has been very limited -- if we start using them
> a lot more, I might decide to create more application environments for
> them, and would create ssidSP2, and so forth.
>
> Regards,
> Cathy
>
> p.s. If you allow developers to do Cobol DISPLAY's, then define their
> stored procedure with RUN OPTIONS 'MSGFILE(SYSOUT,FBA,121,0,ENQ)'. This
> will make them serialize on SYSOUT and prevent perplexing problems.
>
> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
> Behalf Of Charles Crockett
> Sent: Tuesday, December 14, 2004 11:21 AM
> To: [login to unmask email]
> Subject: WLM Stored Proc Appl Env Names
>
> We are setting up stored procs for the very first time (never used DB2
> SPAS, so conversions is not an issue) so going with WLM, and primarily
> plan to run IBM procs only (ie. PQ62695 for DB2 Connect and maybe
> utilities - SYSPROC.DSNUTILS), we don't plan (right now) to write any
> in-house procs. We run 3 single image DB2s, no data sharing.
>
> 1. Would people recommend that we include the subsystem name in the
> Appl Env Name? Or is it desirable to reuse the same Appl Env Name in
> multiple DB2 systems?
>
> 2. If people use the &IWMSSNM for multiple DB2 systems, what problems
> does that create on the Proc Name if that is coded for a single DB2
> system?
>
> Any other tips of how one might do things differently, if you had it to
> do all over again?
>
>
>
> Charles Crockett D1
> DB2 Contractor assigned to
> Information Technology Services
> Wisconsin Public Service Corp
> (920) 433-2258 (voice)
> (920) 433-5747 (fax)
> e-mail: [login to unmask email]
>
>
------------------------------------------------------------------------------
>
> This email is confidential and may be legally privileged.
>
> It is intended solely for the addressee. Access to this email by anyone else,
> unless expressly approved by the sender or an authorized addressee, is
> unauthorized.
>
> If you are not the intended recipient, any disclosure, copying, distribution
> or any action omitted or taken in reliance on it, is prohibited and may be
> unlawful. If you believe that you have received this email in error, please
> contact the sender, delete this e-mail and destroy all copies.
>
>
=====
>
>
---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
> page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
> "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
> The IDUG List Admins can be reached at [login to unmask email] Find
> out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raymond Bell

Re: WLM Stored Proc Appl Env Names
(in response to Myron Miller)
Charles,

You've already had some good comments on general setup so I won't rehash
that. But what I'd suggest - if no one else has already - is that you set
aside a WLM environment to run SPs that have to be APF-authorised.

WLM_REFRESH is a very useful stored procedure. We've recently setup the
DSN8ED6 program which is a caller of WLM_REFRESH you can use in a similar
way to DSNTEP2. However it has to run from an APF-authorised library and,
as ALL the libraries in the WLM environment have to be authorised if one is,
we thought it easier/safer if each subsystem had its own WLM env. for
APF-authorised programs/libraries. So each WLM env. is called ssidAAAA
(where AAAA relates to the application's software version) with one
additional one called ssidAPF.

Developers refresh their own WLM env's now. One less monkey-task for us to
do.


Raymond Bell
Database Administrator

-----Original Message-----
From: Charles Crockett [mailto:[login to unmask email]
Sent: 14 December 2004 19:21
To: [login to unmask email]
Subject: WLM Stored Proc Appl Env Names


We are setting up stored procs for the very first time (never used DB2
SPAS, so conversions is not an issue) so going with WLM, and primarily
plan to run IBM procs only (ie. PQ62695 for DB2 Connect and maybe
utilities - SYSPROC.DSNUTILS), we don't plan (right now) to write any
in-house procs. We run 3 single image DB2s, no data sharing.

1. Would people recommend that we include the subsystem name in the
Appl Env Name? Or is it desirable to reuse the same Appl Env Name in
multiple DB2 systems?

2. If people use the &IWMSSNM for multiple DB2 systems, what problems
does that create on the Proc Name if that is coded for a single DB2
system?

Any other tips of how one might do things differently, if you had it to
do all over again?



Charles Crockett D1
DB2 Contractor assigned to
Information Technology Services
Wisconsin Public Service Corp
(920) 433-2258 (voice)
(920) 433-5747 (fax)
e-mail: [login to unmask email]

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

Legal & General Group PLC, Temple Court, 11 Queen Victoria Street, London, EC4N 4TP.
Registered in England no: 1417162

Legal & General Group Plc is a holding company, subsidiary undertakings of which are fully authorised as appropriate under the Financial Services and Markets Act in respect of their investment activities in the UK.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Charles Crockett

Re: WLM Stored Proc Appl Env Names
(in response to Raymond Bell)
Raymond:

If we use an approach like Cathy suggested, one AE for IBM distributed
system SP's (and if it uses DSNLOAD, that is already APF authorized),
and other AE's for application code, that would not be APF authorized,
we should be OK, correct?

Another aspect of WLM SP's, database DSNATPDB, what are the
requirements to imagecopy, reorg, monitor growth, restore at DR site,
etc.?

Charles Crockett D1
DB2 Contractor assigned to
Information Technology Services
Wisconsin Public Service Corp
(920) 433-2258 (voice)
(920) 433-5747 (fax)
e-mail: [login to unmask email]


>>> [login to unmask email] 12/16/04 03:59AM >>>
Charles,

You've already had some good comments on general setup so I won't
rehash
that. But what I'd suggest - if no one else has already - is that you
set
aside a WLM environment to run SPs that have to be APF-authorised.

WLM_REFRESH is a very useful stored procedure...

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raymond Bell

Re: WLM Stored Proc Appl Env Names
(in response to Charles Crockett)
Charles,

Sorry for not getting back to you earlier but I was out of the office last
Friday, exercising my right to get soaked to the bone shopping in Croydon.

Anyway, if you have one WLM environment dedicated to programs that have to
run APF-authorised you'll be in a good spot. So yes, you should be OK. As
for DSNATPDB I've never heard of it and we don't have one. Dunno what's in
it so I can't help you on that one.

As an aside we include the SCEERUN library in our SPs. I'm assuming it's
APF-authorised, because (I think) if you call a program that needs to be
authorised and any of the datasets in the steplib concat aren't authorised
the call will fail.

Good luck,


Raymond Bell
Database Administrator

-----Original Message-----
From: Charles Crockett [mailto:[login to unmask email]
Sent: 16 December 2004 17:13
To: [login to unmask email]
Subject: Re: WLM Stored Proc Appl Env Names


Raymond:

If we use an approach like Cathy suggested, one AE for IBM distributed
system SP's (and if it uses DSNLOAD, that is already APF authorized),
and other AE's for application code, that would not be APF authorized,
we should be OK, correct?

Another aspect of WLM SP's, database DSNATPDB, what are the
requirements to imagecopy, reorg, monitor growth, restore at DR site,
etc.?

Charles Crockett D1
DB2 Contractor assigned to
Information Technology Services
Wisconsin Public Service Corp
(920) 433-2258 (voice)
(920) 433-5747 (fax)
e-mail: [login to unmask email]


>>> [login to unmask email] 12/16/04 03:59AM >>>
Charles,

You've already had some good comments on general setup so I won't
rehash
that. But what I'd suggest - if no one else has already - is that you
set
aside a WLM environment to run SPs that have to be APF-authorised.

WLM_REFRESH is a very useful stored procedure...

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

Legal & General Group PLC, Temple Court, 11 Queen Victoria Street, London, EC4N 4TP.
Registered in England no: 1417162

Legal & General Group Plc is a holding company, subsidiary undertakings of which are fully authorised as appropriate under the Financial Services and Markets Act in respect of their investment activities in the UK.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm