Re: Basic source control for RPGLE/CLLE/DDS

Thanks Scott,

Your process sounds simple enough - A script either side of the compile
option to get the source on and off the i as required. Do you use the
iProjects feature of RDi? I was hoping somebody would say that was worth
the effort of learning because it appears to copy sources to the i before
compile, but everywhere I've seen uses various scripts they maintain
themselves.

When you copy the source back to the i for compile, do you have to remember
to copy the /COPY books as well or do you keep a copy of the /COPY books on
the i at all times? I'm reticent to leave source on the i because I don't
want colleagues to think "i'll just make a quick change here" and the
change gets lost because it didn't get back to the repository for whatever
reason.

I knew about the DBGVIEW compile option, but I was wondering if the
debugger can be told to look somewhere else for the source. I think RDi has
that possibility but it has to be setup manually for every debug session
and then there is a question about whether the source is the same as the
object was compiled from. You are probably right that DBGVIEW is the best
option.

The os upgrade is out of my control, and not really in my area of expertise
either. We require an upgrade to at least v7.1 to allow encryption of data
at field level on the database itself, but (I think I've heard) our
hardware isn't capable of running v7.3. No idea about v7.2. If I were in
control I would've gone to the top version and got the hardware upgrade to
handle it, but as you can probably guess from my OP the purse strings are
tight and/or the purse is empty.


-Paul.




On 14 July 2016 at 05:24, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx> wrote:

Paul,

Here's what I've done:

1) Write a script that copies all source in a given library to a matching
IFS directory structure

2) Use that IFS directory structure as your git sandbox.

3) Write a script that copies the opposite way, back to source members.


This way, you can use git as normal in the IFS structure. Clone/pull from
your master repo on the network, run the program to put it into your source
members, and work with it as normal. If you make changes, you can then use
the program to copy it back to the IFS, commit it, and push back to the
master repo.

Git does not do compiles, so you can use the normal IBM compiler commands
(or RDi, or PDM or whatever) it doesn't matter to git.

If you don't want the source after compiling, just delete it. You can
easily re-clone the git repo if you need it again.

For debugging, I would compile with DBGVIEW(*LIST), that way the debugging
source is embedded in the object, so there is no need for the source to be
on the system.

I don't understand why you'd update from 6.1 to 7.1? Why go from an OS
that is 3 releases out of date to one that is 2 releases out of date?!?!
There is absolutely no advantage to running an outdated version of the OS
-- and the more out of date you are, the harder it will be to get current.

-SK



On 7/12/2016 7:39 AM, Paul Bailey wrote:

Hi,

Has anyone had any success converting a set of source files in libraries
on
an IBM i to a source controlled environment using Git?

If so:
- How did you create the default repository at the start?
- How do you compile the objects on the i? (I understand DDS might be a
problem unless the source member is copied back to the i)
- The source shouldn't be hanging around on the i after compile, so do we
need to clean up source files after every compile?
- When we need to debug the objects on the i, how does the debugger find
the source?

I have os v6.1 and RDi v9.5.x at my disposal, possibly upgrading the os to
v7.1 in the "near future". We currently have all our Git repos on network
storage and (unless otherwise warned) I intend to do the same with this.

We are also looking at commercial products to do all this for us, so any
vendor suggestions could be useful (I already know about Softlanding,
ARCAD, MKS, Rational Team Concert and Aldon), but cost is a major obstacle
for this and most of the additional features are not wanted.


-Paul.

--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.