On 6/16/2017 12:23 PM, Greg Wilburn wrote:
With RDi, it's easier to find the source members that need changed... but I'm not sure what is the best approach to get copies of them to work on (and test) in the new "environment". I'm not real familiar with some of the tools available in RDi.
To find the candidates, I use RSE to create a filter to the production
side. Right click > Show in Table. Click the inverted triangle at the
upper right and Subset... For this first pass I'll try text 'RAFILE'.
This gives me 24 of 945 objects (members).
I then write a User Action to copy them to my new test environment.
Right click one of the members > User Actions > Work with user actions.
Create a new Member action:
Action name: toX
Command: CPYSRCF FROMFILE(&L/&F) TOFILE(BUCKX/&F) FROMMBR(&N)
Create, Close
Select all the members in the subsetted list,
right click > User Actions > toX
Repeat these steps for as many different subsets as you need to capture
most of these members, then un-subset and pick the onsie-twosie that are
left out. It doesn't matter if the same member shows up in multiple
subsets; the CPYSRCF will quietly overwrite if you copy it again.
This will put the source members into your test environment. I'm a huge
fan of setting up a separate connexion for a project like this. Within
that connexion I'll have the new user/*jobd/*libl and it just... flows.
So, I create a new connexion:
RSE New Connection > IBM i...
Host name: aaa.bbb.ccc
Connection name: buckx
Finish
Right click buckx > properties
Under Host, change the user profile
Under Subsystems, add/change the library list. I tend to have a teensy
CLP that sets up my environment (*LIBL, Java CLASSpath, etc) so I put
that CLP in the Initial Command box. Libraries specified above that
modify the *LIBL set by the CLP; that is, the CLP runs first, then the
(implied) ADDLIBLE.
Now that I have a connexion, I create as many filters as make sense:
RSE > buckx > Objects > Work with members...
Library: buckx
File: QRPGLESRC
Member filter: *
At this point, I'm working with a regular RSE filter over the source in
test, my compiles go into test, and I'm in my 'normal' workflow.
I happen to have an in-house command to promote those changes back to
production, but there are other ways to go about that. I'll assume that
You Have Ways of making sure no one has changed the production source
while you worked with it... Use a User Action or any other means you
like to copy the source back to production.
I /could/ compile from test into production with one easy change. Go
back into the properties for the connexion. On the Commands tab at the
top, there's a place to put the Object Library. Flip that to PRODUCTION
and all of my compiles go to production, but from the source in buckx.
That'll look funny in a year or two when I try to determine what source
went into those objects, and DSPPGM says BUCKX. Whoops.
Instead, I stay in the RSE filter over buckx and create a new Compile
Command. Right click any member > Compile > Work with Compile Commands.
Create a new command:
Label: buckx (aren't I imaginative?)
Command: CRTBNDRPG PGM(PRODUCTION/&N) SRCFILE(PRODUCTION/&F) SRCMBR(&N)
REPLACE(&R) OPTION(*EVENTF) DBGVIEW(*ALL)
While at it, change the user/*LIBL in the connexion to the production
values. Disconnect and Connect the Connection to refresh RDi.
The 'secret' here is to hard code the production library into both the
source and object parameters of the compile command. Then, when I Show
in Table, Select All, and Compile with Compile Command BUCKX, RDi will
read the list from test (which contains every member I need, but not one
more) and compile in and from source!
That's one way to go about it.
midrange.com
