This PowerUp blog entry was written by Bruce Guetzkow. He has been an IT professional for more than 25 years, mostly with Power Systems servers running IBM i and its predecessors. He is currently Webmaster for the Wisconsin Midrange Computer Professional Association, an advisor for the Programmer/Analyst Track and Adjunct Instructor at Gateway Technical College in Kenosha, Wis., and an independent consultant for GmanTech Consulting in Delavan, Wis.
Proper management of source and objects is crucial to delivering quality applications. Having mismatched source and objects mean never being sure that the changes you’re making will work as planned. Even the most carefully planned manual process can be prone to errors.
Change management is an application designed to ensure a consistent, reliable process to maintain business environments. This is important whether you are part of a large team or the sole developer in an organization.
All developers should know that objects need to be created in a well-defined sequence: physical files, then logical files, printer and display files, etc. The sequence does not change with each update unless new objects are added to the mix, as happened when the Integrated Language Environment (ILE) introduced modules and service programs to IBM i. The sequence is logical and not difficult to understand, it is just tedious to deal with when installing application changes. These rules, which can be defined within change management tools, will be followed for each application update. They can also be modified should a future need arise.
When IBM first launched the AS/400 server, its applications were typically very simple. Companies could easily build their own tools to manage source and objects. Today's applications involve complex designs, incorporating components that may not even reside on a Power Systems box. Even those that exist solely within the IBM i framework may include parts stored on the Integrated File System (IFS), which may require special handling. While companies may still be able to build their own tools, as new technologies continue to emerge and be adopted, these tools must also be adapted to meet those challenges.
Without endorsing any specific vendor, several excellent change-management products are available that not only manage traditional source and objects but also newer Web-related ones. In addition, many of these tools also make it easy to keep various working environments in-sync, such as production, development and multiple test environments. If your development or test environment is different from your production environment, are you sure you know what you’re developing or testing?
Change management is not a function of the size of a development team. Some people believe that change management is not necessary for a small development team as everyone knows what the others are doing and contention for source and objects can be resolved simply by shouting over the cubicle walls. Even as a one-man development team, I felt that having change management tools was a necessity to keep environments viable. In addition, I could always be assured that source and objects were installed in a consistent manner. If a particular object had special requirements, such as an override or temporary creation of a dependent object, the change-management solution, once instructed, would always remember those requirements for subsequent changes.
If you aren’t using any change-management process (homegrown or vendor-developed) to manage your development process, consider how much time you spend with each application update. I believe that the return on investment will be quickly recovered with the time savings and certainty of knowing that your process has properly updated all environments.
Proper management of source and objects is crucial to delivering quality applications. Having mismatched source and objects mean never being sure that the changes you’re making will work as planned. Even the most carefully planned manual process can be prone to errors.
Change management is an application designed to ensure a consistent, reliable process to maintain business environments. This is important whether you are part of a large team or the sole developer in an organization.
All developers should know that objects need to be created in a well-defined sequence: physical files, then logical files, printer and display files, etc. The sequence does not change with each update unless new objects are added to the mix, as happened when the Integrated Language Environment (ILE) introduced modules and service programs to IBM i. The sequence is logical and not difficult to understand, it is just tedious to deal with when installing application changes. These rules, which can be defined within change management tools, will be followed for each application update. They can also be modified should a future need arise.
When IBM first launched the AS/400 server, its applications were typically very simple. Companies could easily build their own tools to manage source and objects. Today's applications involve complex designs, incorporating components that may not even reside on a Power Systems box. Even those that exist solely within the IBM i framework may include parts stored on the Integrated File System (IFS), which may require special handling. While companies may still be able to build their own tools, as new technologies continue to emerge and be adopted, these tools must also be adapted to meet those challenges.
Without endorsing any specific vendor, several excellent change-management products are available that not only manage traditional source and objects but also newer Web-related ones. In addition, many of these tools also make it easy to keep various working environments in-sync, such as production, development and multiple test environments. If your development or test environment is different from your production environment, are you sure you know what you’re developing or testing?
Change management is not a function of the size of a development team. Some people believe that change management is not necessary for a small development team as everyone knows what the others are doing and contention for source and objects can be resolved simply by shouting over the cubicle walls. Even as a one-man development team, I felt that having change management tools was a necessity to keep environments viable. In addition, I could always be assured that source and objects were installed in a consistent manner. If a particular object had special requirements, such as an override or temporary creation of a dependent object, the change-management solution, once instructed, would always remember those requirements for subsequent changes.
If you aren’t using any change-management process (homegrown or vendor-developed) to manage your development process, consider how much time you spend with each application update. I believe that the return on investment will be quickly recovered with the time savings and certainty of knowing that your process has properly updated all environments.
We're using Turnover, and it's pretty reliable. However, it doesn't have enough support for SQL database objects. I'm not sure if it's a limitation on our software or just something we have not implemented. Also, there is support for service programs and modules, but no support I know of for binding directories and binder source. Which change management software are you using Bruce?
Posted by: Brian Lannoye | December 19, 2012 at 03:40 PM
Turnover does support sql. You need to find the tech note on sql. We have all sorts of sql objects and have for years. Yes there is support for binding dirs and binder source also. We use binder source a lot.
Posted by: Chris Nickchen | January 03, 2013 at 11:59 AM
I am the VP Americas for Arcad Software and I have replace Turnover at several accounts. If you would like Brian I would be glad to have a discussion.
Posted by: Floyd Del Muro | January 09, 2013 at 03:52 PM
I am with Arcad Software and we can manage SQL and the build dependencies in our Skipper Pack. Feel free to reach out if you would like to have a discussion Brian.
Posted by: Floyd Del Muro | January 09, 2013 at 05:38 PM
Great Article Bruce and look forward to seeing you at WMCPA conference.
Posted by: Floyd Del Muro | January 09, 2013 at 05:39 PM
CM is a programmer's best friend. It doesn't matter how many programmers you have promoting objects. We wrote our own web based CM system and love it. It does only what we need. I can't imagine having to move objects from test to production (on another machine) without it.
Posted by: Jeb Bouchard | January 10, 2013 at 07:18 AM
Raz-Lee's recently released Change Tracker product complements CM products by ensuring they haven't been circumvented, whether accidentally or on purpose. Small shops without a CM may get by using this product only. Object and related source files are monitored as are IFS files and even IBM PTFs! See http://www.razlee.com/products/security/change%20tracker/change-tracker.php .
Posted by: Eli Spitz | January 17, 2013 at 02:33 AM
Hello!
Huge experience also from our side to help you in your Change Management projects with MDCMS!
Several successful cases in the whole Americas region and Europe, replacing TO or Arcad.
Do not hesitate to contact me for further details!
Best regards
Posted by: Rafael Cano C. | January 17, 2013 at 03:33 AM
An excellent and concise article.
I work for Rocket Software (vendor of IBM i solutions: Rocket Aldon Lifecycle Manager, Rocket LegaSuite, and Rocket iCluster) and declare an interest.
Development on IBM i, around the world, remains healthy. In the last 12 months we’ve seen excellent growth in customers new to commercial CM solutions and customers replacing an old products. Customers large and small. This doesn't surprise me, particularly with the complications brought about by need to comply, to modernise & ‘go mobile’, to produce the higher quality code, and ever increasing business targets.
We frequently hear that some vendors in this arena have discontinued all but essential maintenance of their CM products. IMHO such vendors clearly have something other than the best interest$ of their customers in mind.
SQL is just one area where IBM continues to make significant advances on its i. It’s also an area where some vendors are at pains to provide continued support. Other examples include support for iASP technology and Digital Signatures.....but there are many more.
Are your development efforts restricted by the lack of support from your existing CM product / process? If not now, it’s a valid assumption to make that they will be in the relatively near future. How will this affect your ability to take advantages of new IBM i features? To provide advantage to your business?
Rocket Software invests significantly in the research and development of its IBM i Change Management solution. This superb platform continues to be a key area in our future development plans.
In line with my counterparts above, please contact me if you’d like to know more about how we can help you, and your business, become more successful.
http://aldon.rocketsoftware.com
Posted by: Chris White | January 21, 2013 at 02:56 PM
First, let me apologize for not responding to you all sooner. Normally I try to respond to each and every comment, but with the holidays, I got terribly distracted.
I have used both SoftLanding's Turnover & Arcad's Skipper and have found both very full-featured. Off the top of my head I can't remember the level of SQL support (I'd be surprised if any of the major players didn't support it), but I know they both support binding directories in some fashion.
I purposely didn't want to mention names in the article as I don't want to come off as being in the pay of anyone. Each has its strengths and weaknesses, but all of the major players do a good job. Where I'm working now there is no CM product...I'm doing what I can to change that.
Thanks for all of the comments...keep them coming!
Posted by: Bruce Guetzkow | January 23, 2013 at 06:58 PM
Brian,
We are also a TurnOver shop and manage our SQL objects with TurnOver. You need to look at Supplement 17 - Managing SQL Objects.
Hope this helps,
Posted by: Bill Poulin | January 24, 2013 at 09:39 AM
We have been using Aldon LMi since 2005 and I have been very pleased with this software. Prior to using it we always seemed to end up with a problem in production because either a logical file was built over the development version of a file or the program source did not match the production version, or worse yet, the productions source had been corrupted. Now we have the confidence that when we check out an item we have the correct version and the changes tested in development will work the same in production.
Posted by: Frederick Deutsch | February 07, 2013 at 06:34 AM
Bruce,
Nice article. I made a similar argument a bit more humorously a few years ago here in an article titled "Programmers Should Love Change Management Software... Seriously!" at http://www.mcpressonline.com/programming/change-management/programmers-should-love-change-management-software-seriously.html.
Posted by: Marty Acks | March 14, 2013 at 06:52 AM