RE: RE: Using activation groups

I see, Might I suggest a simpler solution. Allow/require the users that
access the two parts of the system to signon twice, once into "production"
and once into "development". System Rqs 1 works ok for this, but a second
Client Access session would be better.

-Walden

-----Original Message-----
From: mcsnet!midrange.com!midrange-l-owner@Mcs.Net
[mailto:mcsnet!midrange.com!midrange-l-owner@Mcs.Net]On Behalf Of David
Morris
Sent: Friday, January 16, 1998 1:17 PM
To: MIDRANGE-L@midrange.com
Subject: Re: RE: Using activation groups


Programmers & analysts that switch between production and test.  When we had
two
machines this was not an issue.  Now we have some analysts that spend the
majority
of their time researching user questions and verifying information.  We use
SQL quite
a bit which leaves files open until you sign off.  We also have server
programs that
access files which are duplicated between test and production.  We leave
these files
open all day.  RCLRSC will not close files open by SQL.  Problems can occur
when
these files are open from a test library and the analyst switches into the
production
environment.  This is what we are trying to fix by setting a different
activation group for
test and production.

Thanks for your interest,

David Morris

>>> "Walden Leverich" <walden@techsoftinc.com> 01/16 6:23 AM >>>
David,

I'm not sure what the activation group name has to do with the environment
(test, production, etc.) Activation groups are segments WITHIN a job. Even
if you have an activation group named abc123 in two jobs there is nothing
shared between them. If one of these activation groups was in a production
user's job running the program from library PRDPGM and one was in a
developers job running the same program out of PDM from library DEVPGM you
would not have any problems.

What am I missing?

-Walden

-----Original Message-----
From: mcsnet!midrange.com!midrange-l-owner@Mcs.Net
[mailto:mcsnet!midrange.com!midrange-l-owner@Mcs.Net]On Behalf Of David
Morris
Sent: Thursday, January 15, 1998 4:41 PM
To: MIDRANGE-L@midrange.com
Subject: Using activation groups


I was wondering how people are defining activation groups.  We originally
planned
to use *CALLER for all programs and service programs and set the activation
group
based on our menu interface program.  Depending on environment and authority
we
call an interface program from our menu.  We intended to assign our
activation group
based on the interface program's activation group.  In this way we could
completely
separate test/production and payroll/financials/other.  We didn't think
about QCMD
and PDM.  Quite a bit of testing goes on where calls are made from these
programs.

We have four options at this point.  1.  Get IBM to allow a dynamic
activation group.
Highly unlikely.  2. Specify an activation group on all of our programs.
All programs
would have to be duplicated in test/production environment.  3.  Create a
new interface
program that would be called when testing that would use our menu interface
program
to complete the call.  This requires out programmers to be more disciplined.
4. Some
option we haven't thought of yet.  This requires

How have you dealt with this?    An option to specify ACTGRP(*CALLER/*NEW if
caller default) would be perfect.  Of primary concern is the ability to
prevent test and
production environments from overlapping.  Secondary is the ability to
install a change
(requiring a triggered RCLACTGRP) during business hours.  The least
important is the
ability to reclaim resources as users switch between job area.   Being able
to assume
the menu program is a boundary is also nice to have.

Thanks

David Morris




!

!

!

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
uucp

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---