"Imagination is a valuable asset in business and she has a sister, Understanding, who also serves. Together they make a splendid team and business problems dissolve and the impossible is accomplished by their ministrations."
--Alice Foote MacDougall

I don't get enough opportunities to quote women of business, and I thought I'd rectify that particular oversight this month with a quote designed to illuminate the concept of teamwork. In software development, teamwork means many things, but to anyone who has been burned by the loss of crucial source code, the word teamwork brings to mind the concept of "source management."

In this article, I will...

• Compare and contrast source control and change management
• Present an overview of the base capabilities that are included in WDSC
• Point to a few open-source alternatives
• Mention the vendors who play in the iSeries source management arena

(Note to vendors: If I missed your product, please let me know so that I can remedy that in the discussion section.)

Source Control and Change Management

The first thing to do before going any further is to identify the differences between source control and change management. There are superficial similarities in that both keep track of multiple versions of your source code, but after that, the two diverge dramatically.

Source Control

Source control systems are exactly that: They control your source code. Most often, they're used to synchronize source code changes to make sure that multiple programmers in a team don't walk on each other. Some are lock models: When a source module is checked out, it is locked, and nobody else can touch it until it is checked back in. Revision Control System (RCS, written in the '80s) or Source Code Control System (SCCS, written in the '70s), available on most UNIX platforms, both use the lock model. But the most common system in use today on both UNIX and non-UNIX machines is Concurrent Versioning System (CVS), which, as its name implies, allows more than one concurrent modification. If more than one programmer modifies a source member, CVS will attempt to merge changes.

Note: The phrase "most common" is a little misleading. CVS is actually built on top of RCS, so technically, anywhere CVS is used, RCS is used as well. However, I think it's safe to say that more sites use the CVS-RCS combo than RCS (or SCCS) alone.

So, vagaries of the locking mechanism aside, one basic facility of source control systems is the ability for programmers to check out code from the repository, modify it, and check it back in for other developers to use. The other primary feature of source control systems is the ability to create branches. This is not a universal feature, but CVS supports it. In branching, you are allowed at any point to fork the development process and create a separate version, as shown in Figure 1.

Figure 1: This product has four versions: the main one and three branches. (Click images to enlarge.)

Keeping track of versions can be complicated. In Figure 1, for example, the changes that were made between 1.2 and 1.3 of the main product are not included in any of the branches. To get those changes, you'd have to merge the branch with the main line, and that's not an easy process. In general, I try to avoid branching, but it's sometimes unavoidable, especially if you're a software vendor and you need to have unique versions for specific clients.

Change Management

OK, source control in a nutshell is check out, modify, check in. That's about it. No compiling, much less testing or deploying. That's where change management software comes in.
Change management (also known as software change management or software configuration management) is much broader in scope. The concept evolved out of various development methodologies, such as the Product Development Life Cycle (PDLC), which was quite popular in the 1980s. The differences between change management and source control fall into several areas.

First, the objects controlled include not only source code, but any object in the system. This can be compiled programs, user documents, technical specifications, test plans, you name it. Anything used during the development process is subject to manipulation by the change management process.

Second, the process includes specific stages, such as development, quality assurance, and production. For each object, each step of the process is owned by someone whose responsibility it is to be sure that the object passes any required tests before it's passed to the next level (called "promotion"). For example, once a developer determines that a program has passed the required unit tests, the object is promoted to quality assurance. The QA person is then in charge of functional or system testing in order to ensure that the program does what is intended and works with the rest of the system.

There are other differences as well, which are handled differently by different tools. Most products allow you to create your own set of steps (sometimes called a "workflow") to define how your business handles software issues. Some even go so far as to allow multiple workflows based on the incident type: Is this an enhancement or a bug fix? Some products provide the capability of creating shippable media, some generate documentation of moves, some provide the ability to identify other required resources. The variety of features is large, and what you need really depends on your own shop standards.

CVS Integration--The Base Capabilities of WDSC

So how does all this relate to WDSC? To start with, WDSC comes with basic source management capabilities that it inherited from Eclipse. It's been a long time since I used base Eclipse; I use WDSC almost exclusively for my development (with the occasional segue into the iSeries green-screen for things like SDA and WRKDBF). But a little investigation verified that the CVS capabilities of WDSC are equivalent to the basic features of Eclipse.

These are not as nice, in my opinion, as the built-in capabilities of VisualAge for Java (VAJ) were. VAJ had its own repository structure and its own built-in source control mechanism. It not only tracked changes automatically, but also allowed you to easily "stripe" (or "tag") a project to indicate a specific release. This functionality allowed me to easily go back and look at the specific code for a release. CVS has many of these capabilities, but they often require a little more manual intervention. With VAJ, most of the work was done under the covers, and I got used to that.

In Eclipse, you create "projects" (not to be confused with iSeries projects, which I'll address in a moment). These projects can range in type from simple Java projects to entire J2EE enterprise projects. And you can use CVS to track the changes in any of these projects. In fact, in this regard, CVS is actually more than just a source management system. You can actually use it to store GIFs and JARs and anything else your project needs. Of course, the compare and merge capabilities only make sense for ASCII text, but that's to be expected. However, the basic ability to save versions of a project and then compare the components is available.

But, because iSeries source code generally resides on the host in source physical files, the CVS tools have no way of accessing iSeries code. Thus, the CVS capabilities of Eclipse by themselves don't provide much in the way of iSeries source management.

However, Eclipse is a hotbed for synergistic relationships. One of the interesting capabilities that comes about as the natural consequence of the interplay between the various features of the Eclipse workbench is the combination of iSeries projects and CVS. I won't go into detail on the concept of iSeries projects; suffice to say that the idea is to be able to drag a portion of your iSeries source down to your workbench to allow you to do offline development. One side effect is that now the source is located on your workstation in text files, which you can save in CVS just like any other source code. That includes the ability to do comparisons between versions or even to have multiple branches of the code.

There are some quirks with the iSeries project that prevent it from being perhaps as useful as it could be, but the fact is that now, with WDSC and CVS, you have your own free source control system for iSeries source code. Not a very pretty one, and not a particularly powerful one, but the price is right.

Note: In order to use CVS, you'll need a CVS server. This is simply a machine running the CVS server software. CVS versions are available for just about every flavor of UNIX or Linux out there. There is also a version for Windows called CVSNT, which I do not recommend. Personally, I think an inexpensive Linux box with lots of disk space is the most cost-effective method of implementing CVS.

Speaking of Price

Another cost-effective route is available as well. Once again, the options here are not going to fit as well with iSeries source code as they will with other types of projects, but since many are free, they're probably worth looking into.

Go to the Eclipse plug-in page for SCM to see a list of 19 projects, all but one of which are free or under the Common Public License (CPL), which is an open-source license that authorizes use in most environments. These projects range from small, single-author efforts to large, well-known, widely used tools. They provide different capabilities, including attaching to different source control systems, such as ClearCase and Perforce. (Yes, I know that Rational provides an Eclipse plug-in to ClearCase, but the open-source plug-in claims better integration and user interface.)

What About Commercial Products?

Whenever I give seminars or lectures on WDSC, I always stress the fact that most, if not all, iSeries tool vendors will be providing hooks to WDSC. It's simply common sense. Because every iSeries developer will have the license to this product, it's only logical that vendors will design products to plug into it. Rather than having to develop your own custom GUI, you can instead take advantage of the interface already provided by WDSC (which frankly is a lot better than any thick-client Java interface and is usually comparable with native Windows applications). And the first wave of commercial products is already out there: the change management tools.

There are a host of iSeries change management vendors. Some of them have already integrated their products to WDSC to varying degrees; others are contemplating it. Some of them have their own GUIs and may be unwilling to change. You'll need to contact the individual companies to find out the exact status of their WDSC plug-ins. Remember to ask about their compatibility with the new release 3.0 of Eclipse, which has significant enhancements to the UI. Be sure to ask the vendors which of the new UI features they take advantage of.

The vendors and products involved include the following:

• Softlanding--Turnover

• Aldon--LifeCycle Manager

 • Applied Logic--PDE/400
• ARCAD--Skipper
• Industrial Strength Software--ChangeMaster
• MKS--Implementer

Remember, not every product above is already integrated into WDSC, and even those that are have different levels of integration. You need to review each vendor's offering to determine which products best fit your requirements as well as find out what their plans for the future are.

Editor's Note: As always, you can find an extensive list of iSeries vendors and their products in the MC Vendor Directory.

So What Do I Suggest?

You have some good options, depending on your needs. CVS is fine for a certain project size and complexity. However, as projects grow and become more complicated--spanning multiple machines and operating systems--you may find yourself limited by the capabilities of the free software. The commercial versions tend to have more support for things like defect reporting and tracking. Then again, there are many free plug-ins for bug tracking out there, so you can't really decide based only on which features are present.

The point is that many solutions are available today, ranging from the free plug-ins available for Eclipse to high-powered commercial applications from traditional iSeries vendors. Now, you have to go out and look at the individual product offerings and decide which one best fits you.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step, with WDSc: Step by Step coming out this September. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..