Remember, a scheduling environment consists of one or more flags and
their required state.
Based on your description below, you seem to be close. However, there
does seem to be some overkill here. I think the SCHENV for each CICS
region, DB2 region,... is overkill.
May I suggest that one SCHENV be created to each of your 16 environments
with the required state for all of the "pieces" being on for the SCHENV
to exist. Each required CICS, DB2,... would be a resource. This will
limit you to 16 SCHENV. Far easier to keep track of than 192.
E.G. SCHENVA, CICS1 ON, CICS2 ON, ADABAS1 ON is a valid schenv. Jobs run
freely.
SCHENVA, CICS1 ON, CICS2 ON, ADABAS1 OFF is not valid schenv Jobs
do not run.
You still have a flag for each required resource, but in order for the
schenv to exist, all flags must be on.
If my suggestion is too simplistic for you, there are "in-between"
states that could be set up according to your needs.
I concur with the Bruce's recommendations of automation and having the
same list of schenv (and same required states) on both dev/test and
prod.
HTH,
<snip>
We are considering using scheduling environments for the first time and
are
concerned that we might be over-doing it a bit.
In a test and development LPAR, we have 16 test/development
"environments"
that each consist of 3-8 CICS regions, 2-5 ADABAS instances, and a
connection to a DB2 subsystem. The total is about 100 CICS regions, 80
ADABAS
instances, and 6 DB2 subsystems. To cover any possibility, we would
define a
scheduling environment and resource for each of these address spaces
(186),
plus a scheduling environment corresponding to each development
environment (16). We believe that this covers the spectrum of batch
jobs that might
need anywhere from a particular CICS region (open/close files) to an
entire
development environment (regression test job streams).
Is this a reasonable approach or overkill? We would appreciate your
comments and suggestions as we don't want to create a monster.
Chester Hood
Nissan Americas
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
