Managing test regions in a large MVS environment

Jimmyboy · New User Joined: 31 Mar 2007 Posts: 3 Location: Canada

Hi all.

Does anyone have any experience, thoughts or ideas around managing team access to multiple test regions in a large MVS environment?

Cheers

Jim

dick scherrer · Posted: Mon Apr 02, 2007 9:08 pm

Hello,

It would be a good idea to post a lot more info.

From what you've posted, all i can offer is "Do good, avoid evil"

For us to offer suggestions, we need to know more specifics. Are there already multiple regions? How are they currently fdefined? Do you have database and/or vsam in some and not others? Are they clones of each other? Who created the current environment and why? Does the same team need access to multiple test regions? Why or why not? Have you defined unit, system, uat, and qa regions?

I'll wager several folks here have ideas, but until we have something to work with, you will probably not get the replies you'd like.

Jimmyboy · New User Joined: 31 Mar 2007 Posts: 3 Location: Canada

Thanks for the reply Dick. I can answer some of this now - others will have to wait for the initial project meeting.

There are already multiple regions and they are not all clones, and not all full copies of production. A team may use multiple regions for testing, and it is possible to have more than one team in a region at any given time. They have "ownership" of these regions and want to be able to hang on to them.

We have DB2 and some IDMS still hanging around. Some regions only have select subsets of our full range of systems. Some are heavily used and others hardly at all according to the last 4 months of usage (by MIPs).

In short - it's grown into a bowl of spaghetti over the years. We need to get a handle on it, standardize the use, clean up all the contatenations and implement a system that makes best use of the available resources.

More details when I can. Thanks!

Jim

dick scherrer · Posted: Tue Apr 03, 2007 1:03 am

You're welcome

If multiple teams are in the same region and each claims ownership, that could get ugly

While your group is still thinking, i suggest mapping out what needs to be done in the long run and take some stats on which transactions (and how many of them) are being run in each region. MIPS may not really tell the tale. A few really horrible transactions can eat a lot of cpu.

You might group the transaction activity by "application" and also by application team. Once you see the transaction distribution, you may see some obvious grouping/separation.

Database propagation (different teams may need separate test db's - even one team may need more than one test db) and batch initiators will need to be considered.

Something else that will help us is how many teams there are and how many people are on them.

When you know more, someone will be here.

Jimmyboy · New User Joined: 31 Mar 2007 Posts: 3 Location: Canada

This has been helpful already - thanks! More to follow.....

dick scherrer · Posted: Wed Apr 04, 2007 1:10 am

You're most welcome - we're here. . . .

graswant · New User Joined: 29 Apr 2006 Posts: 93 Location: Singapore

Hi Jimmyboy

I agree with Dick, I would like to add some more Ideas.....you must be using some security product like RACF, ACF2, Top secret..etc...You can use one of em and put different teams under groups....this will help you to decide the level of access.....Application like DB2, CICS etc. can be configured to pass security check from the Security product used by you on your companies mainframe.....Proper planing of the Idea will help you to take care of Future needs as well....

Correct me If I am wrong.....

Hope this will help .....

Gaurav