We do essentially what you've described on our two development systems --
each project has its own account, with designated home groups per user.
One account is designated for acceptance testing, while unit testing is
performed in the specific project accounts.  Another account contains all
the current production executable code, V/Plus forms, etc., and is
recreated every evening.  I'm not sure what you mean by a "system test
area", so I can't correlate that to any structure in our environment.

The key to keeping this all working correctly for us is the use of a source
librarian tool -- OCS/Librarian (Tidal Software) -- which allows source,
object, jobstream and other files to be tracked to help coordinate changes.
If a file is "checked out" by a user, another user may not check it out and
modify it.  (S)he may copy it to a work area and modify it, but it may not
be "checked in" because that copy is not tracked, and MPE security prevents
the user from moving the file back to the production source account.  Once
the original tracked file is checked in, the second user may then check out
the code, or the two project groups may collaborate to incorporate and test
both sets of changes.

Here's a typical development cycle using Librarian as we've configured it:

     - User checks out needed files to work area;
     - Completed code is compiled and unit tested within the project
account;
     - Source, object, jobs, etc., are moved to a "hold" account;
     - Job(s) and executable(s) are moved to acceptance testing account;
     - Test OK?
          "Check in" (move) files to production base account; multiple
versions are kept
          Release necessary files to production machine
        else
          "Fail" (move) the files back to the work area for corrections
          Repeat the acceptance testing steps until Test OK
     -  Production problems?
          Release prior version of files from production base account on
dev. system to production machine
          Correct problems in newest version

Of course, many variations of this are possible, but the key is careful
planning of the routes and steps necessary during the development cycle.
You could conceivably create another account to which completed code could
be moved for user training prior to releasing to production.  OCS (now,
Tidal) assisted us with on-site consulting and training to get our initial
environment and version control scheme implemented.

Other version control systems are available:  one of which I'm aware is
"VCS/3000" from Serena Software (650-696-1800), formerly Diamond Optimum
Systems.

Cordially,

Lee Gunter
============================================================
Supervisor, TRG HP/MPE Systems       Phone:503.375.4498
The Regence Group                    Fax:503.375.4401
mailto:[log in to unmask]
============================================================
All opinions expressed are just that -- opinions.
They're mine and mine alone.





From: Ron McFarlane <[log in to unmask]> on 08/11/99 04:43 AM

Please respond to Ron McFarlane <[log in to unmask]>


To:   [log in to unmask]
cc:    (bcc: Lee Gunter/BCBSO/TBG)
Subject:  [HP3000-L] Environments within MPE




I am looking for ideas on how to set up multiple environments on MPE for
the
various stages of the SDLC. I currently have a production and development
machine. On the development machine I split development and testing by
using
different accounts. the implementation is awkward and difficult. I feel I
need a person work space, a unit test area, system test area, acceptance
testing, user training and a production baseline for fail and fix. I now
have 40 people developing and we are getting in each others roads. I would
like to be able to set up "logical machines" if that is at all possible. I
would appreciate any ideas.



Thanks


Ron