Re: What goes where?

We have :

       lpar prod with the whole kit and kaboodle.
       lpar dev1, a copy of prod
       lpar dev2, another copy of prod

The development team was divided into 2 and each had its own dev lpar. Now the team is one, and it's even become a pain having 2 dev lpars as we often find ourselves having to switch from one to the other and back again in the middle of a project.

Would it be an idea to have :
       lpar prod with no source.
       lpar dev1, a copy of prod
       lpar dev2, another copy of prod but with source.

Instead of promoting to PRDLIBT like you suggest, just push the objects to lpar dev1.

Thanks.

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de rob@xxxxxxxxx
Envoyé : mercredi 30 juin 2010 14:50
À : Midrange Systems Technical Discussion
Objet : Re: What goes where?

Where then do you keep your production source?

Let's pretend your Production lpar has a library for
programs, printer files and that ilk called PRDLIBO.  And for
data files, data queues and other volatile data called
PRDLIBF.  Production lpar will have no PRDLIBS (for source).
Now your development lpar will have a mirror of this.  In
addition it will also have PRDLIBS for source.  It will also
have a library call PRDLIBT for testing.  And the developers
have their individual libraries.  With Change Management
software when you check out a source member(s) from PRDLIBS
it will copy them into the developers individual libraries.
They can develop, compile and test there.  Then then can
promote it up to PRDLIBT.  Run it through some more testing.
Then promote it up to production.  Which will move source to
PRDLIBS, and the proper stuff to PRDLIBO and PRDLIBF.  As
part of the promotion to production the proper stuff will get
promoted to PRDLIBO and PRDLIBF on the production lpar.  No
source gets moved to the production lpar.

What do you actually push on to the prod lpar? Just objects?

What about
modules?
Just objects.  No modules.  No point to it.

What's the point of DSPOBJD to get the source member used to

create the
object? Can it be easily found?
DSPOBJD died with OPM.  With ILE use DSPPGM or DSPSRVPGM.  If
you want to retrieve this stuff programmatically then there
are APIs for this.

Aren't there any issues with debugging? Aren't the source

files needed?
The source files are not needed.  See CRTBNDRPG DBGVIEW(*LIST)

Any more fors and againsts for separating source and objects

in this way?

Discourages changes on the production machine.
Increases security since less people have access to the
development lpar.
Increases security because developers will not have the
access on the production lpar they claim to need on the
development lpar.
RCLSTG always seems to run several hours longer on the
development lpar versus the production lpar.  Regardless of
processor, etc.  Therefore you're reducing the downtime of
the production lpar.
No source to get out of sync if on both machines.
No source on production lpar therefore less save time,
reducing backup outage.
No duplicate storage of source therefore less disk space consumed.
A separate test lpar will help reduce errors to production
data because some idiot hardcoded a library in a program, or
duped a logical wrong and it points to production data.  An
errant DDM file can still be a kick in the crotch.
No cycles taken up by compiles on the production machine.
Years ago, back when we ran AS/400's, I got a talking to
because a compile slowed down the machine.
You can test ptf's, new releases with the development lpar first.

Con:
You'll upgrade release levels on your development lpar.  If
you forget to compile to TGTRLS(*PRV) it won't work.  Easily
recovered by recompiling.
(And is often a setting in Change Management Software.)

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:   David FOXWELL <David.FOXWELL@xxxxxxxxx>
To:     Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>
Date:   06/30/2010 05:05 AM
Subject:        What goes where?
Sent by:        midrange-l-bounces@xxxxxxxxxxxx

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de rob@xxxxxxxxx
Objet : Re: CPYSRCF SRCCHGDATE

Do what we do.  Don't keep source on your production lpar.

Hey I've been thinking this over from time to time and I'm a
wonderin':

Where then do you keep your production source?
What do you actually push on to the prod lpar? Just objects?
What about
modules?
What's the point of DSPOBJD to get the source member used to
create the
object? Can it be easily found?
Aren't there any issues with debugging? Aren't the source
files needed?

Any more fors and againsts for separating source and objects
in this way?

Thanks.
--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.