When Is A Source Member Not A Source Member?
June 5, 2013 Susan Gantner
|
I do my coding using Rational Developer for Power Systems (a.k.a. RDP). Most of the time, I open the source code in the editor in RDP much like SEU users would, in the sense that I open my source directly from a member in a source file in a library on IBM i. When I save from the RDP editor, the source is saved back to that same member. Below is a picture of what my screen looks like when I’m working with RDP as described above. Note the highlighted library, source files, and members in the “Remote Systems” view (or window) on the left side.
(Click graphic to enlarge.) Sometimes, however, I work in a different way. I use a facility in RDP known as “i Projects.” When I’m editing code from an i Project, I open the source code from the project, which looks almost exactly the same but in reality is quite different. Take a look at the picture below and see if you can spot the differences.
(Click graphic to enlarge.) You probably spotted a few things, such as the fact that the library and source files aren’t labeled as such, and the data and display file objects don’t appear. Did you also notice that the window on the left side this time is called “i Projects Navigator”? Or it would be if I’d made the window wide enough for you to see the full name! The reason that the library and source files aren’t labeled that way is because that’s not what they are. In this picture SQLEMBELRN is an i Project name, not a library name. And QDDSSRC and QRPGLESRC are not source files, they are folders in the project. Likewise the “members” inside them are simply files in the respective folders. These folders reside on my local disk, not on the IBM i host. So when I open the source from the project, it is opening it from a file in my local workspace. After making some changes when I save the source, it will save it back to that file in my local project. But there is a lot more to this picture than just having the source code stored locally. The i Project is associated with the SQLEMBELRN library on the host and the two source folders and their files are associated with the source files and members of the same names in that library. So at any point, I can right click on the project name and take an option to “push changes” back to the host. That will find any files in any folder in my project that have changed and copy them all back into their respective source members on the host. It’s possible that I may have added source code for new programs in my project. In that case, the “push” action will create the member in the appropriate source file (based on which folder I created it in) and copy the source into it. I can even create new source files (actually local folders) in my project and let the push action create those new objects in my library for me. So in reality, my project contains a replica of source code on the host. Since there are two copies of the code (one on the host and one in my local workspace), there is always the potential that someone could have made changes to the source on the host while I was making changes to the copy of it in my project. In that case, when I try to push changes, RDP will warn me that I’m about to overlay recent changes on the host. At that point, I could use one of the source compare options available with RDP to figure out whether additional action is needed. Of course, if you’re using a change management facility with check-out capability that should never happen. You may be wondering, “Why would I want to make a copy of the code on my local system? Isn’t a source member on the host the best place for my code?” My answer is yes. A source member is a better choice as the permanent or ultimate home for my code. But there are often cases where I’ll also keep source code in projects, either temporarily or even longer term. For example, creating an i Project with just the source members I need for a particular task that I’m working on is sometimes an easy way to organize the various tasks I’m juggling. That way, I don’t need to keep sifting through long lists of source members in various sources files each day. I always have just a custom-built list of just the members I need for a particular job. For example, for one of my clients, I always create an i Project for each problem I’m assigned; the project name in that case is the problem number I’m working on and I bring in any source members that I think I’ll need to change (or at least study) to solve the problem in that project. When the problem is fixed and tested, then I can delete the project. There’s another reason that I often use i Projects. I travel a lot. So if I have the code I need to work on in an i Project, I can continue to study and edit code on an airplane without a network connection. If I’ve planned ahead a little so that I have any file definitions cached, I can even verify my code to find out if I’ll have any compile-time errors even without a connection. Then upon arrival, I can connect, push my changes to the host, compile, and test my changes. Sometimes I have projects that contain code examples that I plan to use in classes I’m teaching at a client site, perhaps even code used for lab exercises. One interesting thing I can do with code in that case is that I can push the source code to my client’s host system by making a quick change to the properties of my project to point to a different host, then push changes and, voila! RDP creates the source files and copies all the members from my project to the client’s system. If I have piqued your interest in using i Projects, then stay tuned for my next tip where I’ll show you how to create and populate your own projects and some best practices and tips on making good use of them. Susan Gantner is half of Partner400, a consulting company focused on education on modern programming and database techniques and tools on the IBM i platform. She is also a founding partner in System i Developer, a consortium of System i educators and hosts of the RPG & DB2 Summit conferences. Susan was a programmer for corporations in Atlanta, Georgia, before joining IBM. During her IBM career, she worked in both the Rochester and Toronto labs, providing technical support and education for application developers. Susan left IBM in 1999 to devote more time to teaching and consulting. Together with Jon Paris, she now runs Partner400, and appears regularly at many technical conferences, including System i Developer’s RPG & DB2 Summit. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page.
|
