The iSeries has always been unique for software development. What other platform can you think of that provides the information about compiled objects that OS/400 does? For virtually any object on the system (that you've created), you can easily determine the source library, file, and member from which it was created by issuing the appropriate DSP* command. For many readers, this feature, along with a formal source and library naming scheme and external documentation, serves as their version management system. That's fine--until you throw server-side Java into the mix. When you do, you'll find that you no longer have that wonderful OS/400 feature available to link the object to the source, since OS/400 maintains that information only for objects stored in the QSYS file system. Objects in the Integrated File System (IFS) are not tracked as closely by OS/400, so the Java class files you put there when deploying your latest Web application immediately become disassociated from their source. A shop using the oral tradition documentation system is now at a disadvantage, since OS/400 isn't there to pick up the slack. As the number of Java programs increases, so does the complexity and severity of the problem. And though I keep using Java as my example, the problem is applicable to any part of an application stored in the IFS. What's a poor IT guy (with a limited budget) to do?
Once again, the oasis for elegant and inexpensive solutions, open source, comes to the rescue--this time in the form of a project called Concurrent Versions System (or CVS for short).
Versions, Releases, and Mods--Oh My!
Before I embark on this journey through the wonderful world of CVS, let me define a few terms, since their usage here is different than in the context of an iSeries.
First is the term "source file." On the iSeries, a source file is a single physical file that contains individual source members. This concept is unique to OS/400--most other operating systems, and the open-source community, consider one source file to contain the code for a single, discrete object. The latter is the meaning I'll use for this article.
Next, the terms "version" and "release" in the open-source world vary quite a bit from the definitions that IBM utilizes with the iSeries software. IBM uses "version" to refer to major feature additions (or rewrites), as in Version 2, 3, 4, or 5 of OS/400. IBM uses "release" and "modification level" to refer to feature enhancement and bug-fix levels within a given "version." In open-source projects, each source file (remember: that's one source element) has a version. A "release" is a snapshot of all of the components comprising an application, which, when assembled as a group, cause the application to perform to a certain specification. To minimize the resulting confusion, I'll use this standard in this article.
With that in mind, consider that, for any home-grown application, there are at least two different releases. The first is what the users asked for (I'll call that release 1), and the second is what they really wanted (I'll call that release 2). I'm not being flippant here--I've been in this business for over 20 years, and my users have consistently asked for changes once they realized that they really could "have it their way" and learned what a computer is truly capable of. It is the transition between release one and two, when source files are changing, that can become a bit hairy for the developer. Without some kind of system to manage the current state of each source file (and the changes made between states), the developer can become confused and productivity can suffer.
Concurrent Versions System
Having defined the terms, I'll now turn my attention to CVS. This software will automatically manage your source files as you go from "release 0" to "release 1" to "release 2" and beyond. Notable features include the following:
It will track all changes to a source file, providing you with an audit trail and change history log. Thus, you'll be able to fall back to earlier versions of a source file should things not go the way you'd like in your working copy of the file. Perhaps the easiest way to think of it is as a journaling system for source files.
- It will keep track of the version of each of the application's component files that went into a specific release of the application. If you ever need to recreate a particular version (I'll discuss why you might want to do that later), you can do so.
- It allows multiple developers to work on a given project at the same time. In fact, multiple developers can be working on different copies of the same file and, assuming that they are working on different sections of the same file, it will seamlessly merge the various changes into a single copy. Conflicts between developers' changes can be resolved at the time the merge is attempted.
Managing a Project
So how can you use CVS to your advantage? I won't discuss installation and configuration of CVS in this article, since most modern distributions install it along with the other development tools. And setting up a CVS server isn't a particularly challenging proposition either, especially if it's on your development box. But its configuration does depend on your particular circumstances. If you need it, you can get both the software and installation/configuration instructions directly from the CVS Web site.
Once your CVS server is up and running, it's easy to place one of your current projects under its management. Figure 1 shows a directory containing the structure of one of my Web applications.
|
Figure 1: There is nothing special about this project's directory.
The contents include directories for the source code and JSP files, as well as scripts to issue the commands to build the project under both Linux and Windows. To place this project under the management of CVS, I need only issue the command (from within the directory):
Once the command has completed, I issue the following list of commands:
mv myproject myproject_org
cvs co myproject
This moves me up to the parent directory of the project, renames the original project directory, and then "checks out" the project from the CVS repository. If I move into the newly created project directory and take a look, I'll see what is shown in Figure 2.
|
Figure 2: Note the CVS directory. It indicates that this project is now under the management of CVS.
What CVS has added is the directory "CVS." Pay no attention to the man behind this curtain. The directory contains information that CVS needs to do its job. But be sure that you don't delete it. Its presence does indicate that you've successfully put your first project under the control of CVS.
All you need to do now is simply let CVS know of any files or directories that you have added since you imported your project. Whenever you add a new file or directory to your project you issue the following command:
Similarly, if you delete a file or directory, you issue this command:
Then, CVS will dutifully note the demise of the object. Once you have reached a reasonable stopping point (which you can define--perhaps at the end of each day or whenever you have completed a series of changes), you issue the following command to post your changes back to the server:
At that time, CVS will connect to the server, prompt you to enter text describing the changes you have made, and then put your changes back into the repository. You need not worry that you've forgotten to do the appropriate "CVS" add or "CVS remove" commands because CVS will let you know about anything it doesn't recognize.
If you are collaborating on this project with other programmers and want to ensure that your copies are in sync with theirs, simply enter this command:
Anything that has been committed from the other developers will make its way down to your system.
Once you've finished working on the project, simply issue this command:
At this point, CVS will ensure that you have no uncommitted changes and then delete the directory from your system.
That's it! Even though CVS is a fairly sophisticated piece of software, the commands outlined above are all you need for the basics. There are many other commands available, some that list the change log, others that list the differences between the various versions of the file. A more detailed introduction to CVS can be found on IBM's DeveloperWorkssite. And, of course, there's always the complete manual at the CVS Web Site.
Special Feature
Earlier, I mentioned that CVS would enable you to revert to a particular release of an application. You may be wondering why you'd want do such a thing. Let's say that you've deployed the first release of your software and are now working toward the second release. During your development, one of your users comes to you with a bug you didn't notice before. Unfortunately, your source files already are beyond the point where you can easily fix the bug and still have the application work properly. How can CVS help you solve this problem? Whenever you have a release completed, CVS will note all of the files that are in the project and their current version level if you issue this command:
When you find yourself in need of a given release, you can specify it when you check out the project:
Once you have the requisite version on your system, a quick
will create a branch you can work on that's separate from your current development version. The best part of this is that CVS will enable you to merge the patches you make into your current version. Check the CVS manual for details on how to take advantage of this feature.
If you are wondering how CVS handles files and directories that have been subsequently deleted, you needn't worry about them. When you indicated to CVS that you wanted to remove a file, it saved it in a directory called "attic." So they will magically reappear when you need them.
What Does This Have to Do with iSeries?
Those of you who are still primarily developing ILE programs on the iSeries may be wondering what advantages CVS can offer to you. Good question! Consider that CODE/400 (IBM's latest foray into development tools) can work on local copies of software. Even if the final destination of your source is to be in an iSeries source physical file, you still can take advantage of CVS during the time that the source lives on your local PC. And now that V5R2 of OS/400 permits source code to be stored in and compiled from the IFS, it would seem that CVS is more of a natural fit. Even if you can't find a use for the open-source version management system, there are always commercial versions that do speak iSeries natively.
A good version management system can make your development efforts much easier, particularly when several people are working on the same project simultaneously. The low cost of CVS makes your decision to add it to your toolkit a no-brainer.
Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 20 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He recently co-authored the book Understanding Linux Web Hostingwith Don Denoncourt. Barry can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online