Ah, I just found something interesting. You can designate a filter to look
in the library list for the source member (I might go with *CURLIB, I
haven't decided yet). That filter is shared between connections through
the magic of filter pool references, so I define a filter once for the
various source members in my project and have two connections, one called
Development and one called Production. Those connections define the
library list for production or development libraries, and the filters
magically show the member at the level it exists at. I'm not as concerned
with the compile library list because I can tell RDi to use the custom
Implementer ICOMPPDM command (you could use your own compile command to set
the library list I suppose) to run the compile with the correct library
list. I might even be able to run an Implementer checkout with this.
Selecting all these members for promotion in Implementer will still be a
challenge that people that don't use it are probably not interested in
hearing about.
From: Dave Shaw <daveshaw@xxxxxxxxxxxxx>
To: Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries <wdsci-l@xxxxxxxxxxxx>
Date: 08/21/2013 02:34 PM
Subject: Re: [WDSCI-L] Working with projects
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
The project filters are over the project library, so it's only the
Implementer checkouts that put members where the filters can show them.
When Implementer checks a member out, it places a copy in the project
library - we never edit the production member and, in fact, we're not
authorized to be able to save to the production source files. Once the
promotions are completed, the members and objects are no longer visible in
the filters. If we need to go back to see what we changed, we either look
at the promotion history in Implementer or at our SOX documentation for the
project. Project filters are only over the project libraries. Filters
over production libraries are for reference (open for browse) only.
So, Implementer is essential for promotions, and it's the preferred way to
get the members into the project libraries in the first place (although we
can copy out of the production source files if we need to without doing
Implementer checkouts).
Note that we don't yet have the Implementer RDi plugin - we still do the
checkouts and promotions from the green screen. I don't know yet how our
process will change when we start using the plugin. We may need to do
something with reference filters over production to use the plugin for
checkouts.
Dave Shaw
________________________________
From: "darren@xxxxxxxxx" <darren@xxxxxxxxx>
To: Rational Developer for IBM i / Websphere Development Studio Client for
System i & iSeries <wdsci-l@xxxxxxxxxxxx>
Sent: Wednesday, August 21, 2013 2:12 PM
Subject: Re: [WDSCI-L] Working with projects
Is Implementer fairly separated from that process? I mean, you've
constructed the list of members you're going to work with using filters, so
you type those in again to check-out and then select them manually again
from the big list of everything you have checked out to promote them to
production?
From: Dave Shaw <daveshaw@xxxxxxxxxxxxx>
To: Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries <wdsci-l@xxxxxxxxxxxx>
Date: 08/21/2013 01:41 PM
Subject: Re: [WDSCI-L] Working with projects
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
We have a project system with an in-house tool we call I5DE that creates a
project library and project library list for each project. In RDi, most of
us create a separate connection for each project, which calls an api to set
the defined library list. We then create project filter pools and filters
over the project library. We use Implementer to check the sources and
objects for the project out to the project library, make the changes using
RDi (or green screen, for those who haven't moved up to RDi yet), test in
the project libraries using data extracted from production into the project
library, promote the approved changes using Implementer, and then delete
the completed projects - libraries, filters, pools, and connections.
Production is locked - we can't change it, but many of use have reference
filter pools and filters for finding things we need in production, for when
we can't remember names well enough to use Ctrl-Shift-A. Works fairly
well, although copies of large data files in the project libraries make it
something of a space hog at times.
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/wdsci-l.
midrange.com
