RE: Source Code management - Migrating packages

<all responses are assuming no outside entities rules/regulations (aka SOXS) apply>

All of our production source is, and always has been, (for over 20 years) in one set of source files in one library. Developers will pull the production source into their own library when making changes and then put it back to the production source when implemented.

We created our own, very basic, source control to do checkin/out functions and to keep previous versions of code (basically a copy file to an archive library whenever source is checked out)

We have TAATOOLS and use CMPSRC command when the need arises

"In your example, you say the values clause is only used in one application. How do you know that? You know the application and environment and can make that assessment. Is it documented?"
If any programmer can't scan an RPG source file, looking for a field name used on a screen and determine in 30 seconds that the field is never used outside that application, they should start looking for a new line for work. Of course my example was very simple and reality is never simple but we were talking about a 5-minute change. If the change involved a new value in a database field that is never a 5 minute change and in that case we have the Abstract toolset to help us evaluate the impact a new database field value would have and show us how many apps use that field.

I have not worked in many other environments but have done some, and have done some contract work for other businesses, and I have never used any professional source control product like Aldon/MKS/etc. I also know a fair number of people in this area from other shops and can't name one who uses a purchased source control package.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of lgoodbar@xxxxxxxxxxxxxx
Sent: Thursday, May 28, 2009 10:07 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Source Code management - Migrating packages

Yes.

When I started, I was the 4th or 5th person who inherited code (both
in-house and vendor software mods; we are not a software vendor). Source
could be in a standard source library, in a former developer's library,
a vendor "custom" library, or even in QGPL/Q*SRC. Sometimes the same
source member was in different places, and required reviewing all copies
to determine which was correct. DSPPGM and friends help, but sometimes
source was "work in process". If DSPPGM said member A was the source,
one occasionally found A, along with AOLD or AZZZ. Perhaps AOLD is the
"real" source for the compiled object, and A was unfinished mods. Who
knows?

We implemented Aldon in 2004. We had moved all the source we knew about
into our test LPAR. To use Aldon properly, we had to find "the one true
source" for each object and register it. This can save a lot of time in
finding the correct source for an object.

We've had up to four programmers on staff, now down to two. The suite of
tools, source comparison, single source definition browsing,
versioning/archive, are all worth it.

IMO, unless you're the person who wrote the code, and understand how a
program relates to the rest of your environment, five minute changes can
be dangerous. In your example, you say the values clause is only used in
one application. How do you know that? You know the application and
environment and can make that assessment. Is it documented?

I think Charles replied that SCM is useful for one developer, and I
agree. Let me put it another way. If you were programming in another
environment, would you use Subversion or another source control product
if you had the chance?

Personally, I would be interested to hear how Brad Stone or Scott
Klement manage their different software versions, being they both write
code for distribution. That would be the real-world "one person shop"
answer.

--Loyd



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Wednesday, May 27, 2009 3:18 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: Source Code management - Migrating packages

I would agree on all of this if you have to comply with SOX but if you
were non-SOX regulated, were writing software for use only by your
company, and were the only programmer in your shop, would you still do
this?

"five-minute changes" are not always bad. Say you have a values clause
on a screen that prevents someone from entering some value you are not
expecting and they need to be able to enter one new value. The field is
only used in that one app to control how the data is sorted. You just
need to change the values clause and the sort and the change is done,
the user (who happens to be the head of the department that needs this
changed made and has full authority to request and approve the change)
goes away happy. Would you send this through 5 layers of process and
approval just to make that change and add the cost of all that process
to your company?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
lgoodbar@xxxxxxxxxxxxxx
Sent: Wednesday, May 27, 2009 2:59 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Source Code management - Migrating packages

Source control is less about technology and more about proper controls
and discipline.

<snip>