Why RDi

"Why RDi"

A very common question is "Why should I abandon my current green screen tools that I am so proficient with and spend money and time learning a new environment?  There are many really cool features in RDi that developers like, but here I tried to focus on the business value of adopting RDi for RPG, COBOL, CL, and DDS development on IBM i.

Review the sections below for more details.

Overview

This article will give you an IBMer's perspective on how to justify the decision to buy RDi. But you don't have to take my word for it. Here are recent web articles from industry pundits (non-IBMers) that deal with the same issue.

  • Charlie Guarino, A hard dollars and sense ROI calculation for IBM's RDi (view article)
  • John Paris and Susan Gantner, Little Things Mean a Lot in RDi 9.6 (view article)
  • John Paris and Susan Gantner, Why RPG Developers are Adopting RDi (view article)

In the past I may have answered something like "PDM and SEU are old and Rational Developer for i is a modern tool for RPG and COBOL development." With the exception of a few leading edge IBM i developers, this answer generally doesn't go over very well (much the same way that I've learned "Because I said so" doesn't work that well with my kids). Over the past year I've transitioned to starting all RDi demos with two slides: What is RDi and Why use RDi? I'll explain the "Why RDi" here.

The short answer to why RDi can be summarized as:

  • Improve developer productivity
  • Common development tools platform
  • Improve developers skills

If you're happy with short answers, and want to take my word for it, you can stop reading now.

And finally here is an explanation of why RDi will save you money in a matter of weeks or months.

Back to top

Improve Developer Productivity

I believe improved developer productivity with RDi comes from the following areas:

Modern Development Features

Improving developer productivity is the number one reason why both developers and IT managers should consider switching to RDi. Earlier I mentioned that simply saying "RDi is modern tooling" doesn't work, which is true if that's all you say. But RDi is a modern development tool for RPG, COBOL, CL, and DDS and those modern development features do improve productivity. PDM and SEU were designed over 20 years ago. Over those 20 years there have been major advances in the area of application development tools. It still completely baffles my mind that SEU does not have an undo feature!

Here are some of those "modern features" that lead to improved productivity (a complete list would take way too long and is beyond the scope of this document):

  • Remote Systems LPEX Editor
    1. Color language tokenization: Source code is color tokenized based on language features so you can quickly (visually) see which lines are comments, whats language keywords, and whats user defined files, records, and fields.
    2. See more lines: When dealing with large (or even small) source members, the more source code you can see at once, the easier it will be to understand what the source code is doing. It also makes it less error prone to enter new source code because you don't have to guess (or page up / down) to see matching control structures.
    3. Outline view: The outline view serves many purposes. It provides a summary of the key definitions in the current source member: files, data structures, fields, key lists, subroutines and procedures (including definitions for records and fields pulled in from externally described files and data structures in ILE RPG). It provides quick access to cross reference information within the source member (ILE RPG only). Lastly, but just as important, it provides a quick way to navigate around the source member by clicking on definitions, or cross reference line numbers, in the outline view.
    4. Content assist and templates: You don't have to memorize the low level details for things like the order of parameters for keywords and built in functions(BIF), use content assist (Ctrl + Space) and the list of keywords (or opcodes, fields (ILE RPG only)) appears. Select the keyword or BIF you want and a hover dialog appears showing the required and optional parameters while you enter the values.
    5. SEU and workstation behavior: As much as possible, the Remote Systems LPEX editor has tried to implement SEU behavior to make the transition easier, and standard Workstation behavior. For example; you can use SEU prefix commands to copy and paste or you can use line selection and Ctrl + C / Ctrl + V.
    6. Undo and redo: All changes made in the editor since it was first opened can be undone using the standard workstation Ctrl + U keyboard shortcut. Undone changes can be redone using Ctrl + Y.
  • Integrated i Debugger
    1. Use service entry points to easily attach to ILE programs or service program procedures running in any type of application (interactive, batch, stored procedure, Web, client / server). Note: the debugger can be used for both ILE and OPM, service entry points are a feature specific to ILE.
    2. Monitor the values of fields in real time as you step through your program.
    3. Create launch configurations for programs that are commonly debug to make it faster to start debugging them.

Back to Productivity

Integrated Tools

There are many tasks a developer needs to do to develop software: search, edit source code, compile, and debug are just a few. These are not done in isolation, you may search to find a specific source member, then edit it. After editing you compile, fix any errors in the editor, and then may debug it. RDi integrates these tasks so developers can easily flow from one to the other. Here are some examples:

  1. Developers can launch remote text searches from the RSE. The results (source members and specific lines) of the search are displayed in the Remote Search view. You can right click on either the source member or matching lines in the view to get context specific actions. Double-clicking on a matching line opens the editor and positions to the matching line.
  2. Press F1 on a language opcode, keyword, or column and the help browser opens with context specific language help.
  3. While editing source members, you quickly launch remote compiles using the Ctrl + Shift + C keyboard shortcut. The compile is submitted to batch and you can keep working. When the compile completes, the compiler messages are automatically displayed in the Error List view so you don't have to go look at the spool file. Double click an error message and the editor opens, positions to the line with the error and inserts the error into the editor. After you modify the line, a check mark appears next to the line in the Error List view so you know you've addressed that error.
  4. Set debug breakpoints in the editor before starting the debug session. The debugger uses the LPEX editor to view source, so you still have access to the outline view and other editor features while debugging.
  5. For DSPF and PRTF DDS, there is the Screen and Report Designers that give you a WYSIWYG layout tool and a rich GUI that exposes the full power of DDS.

Back to Productivity

Program Understanding

Now that the basic search, edit, compile, debug cycle is covered in the RSE we've started to branch out into other tools that can help developers understand the structure of their programs. At one end of the spectrum there is the "show block nesting" editor feature that draws lines in the editor margin to match up the beginning and ending of code blocks. There is also the outline view discussed above which can help understand the definitions and structure of the source member currently being edited. At the other end of the spectrum is the application diagram which can:

  1. Visualize subroutine, procedure, and programs calls for a selected set of ILE source members
  2. Visualize module and service program bindings for a selection of ILE programs and service programs.

And of course, the application diagram is integrated with the editor so you can create a diagram from the contents of the editor, and quickly jump to definitions and calls in the editor by double clicking on entries in the application diagram.

Back to Productivity

Customizations

RDi was designed to be customized. This includes customizations for specific development projects and personal customizations. Some examples of project customizations include:

  1. Defining multiple connections, one per application (or environment) and configuring the persisted library list settings to automatically setup the correct library list for compiling members for that application.
  2. Setting up application specific library, object, and member filters that appear only under the corresponding connection(s). The RSE enables filter specific actions like searching and building an application diagram, allowing you to leverage these filters beyond just quickly getting access to the objects and members.
  3. Customizing compile commands and user defined actions specific to an application.

Ultimately, customizations for both projects and personal preferences can make development more efficient.

Back to Productivity

Back to top

Common Development Tools Platform

Rational Developer for i is but one of many application development tools based on Eclipse. Others include:

Very few, if any, IBM i shops have only RPG / COBOL development projects. Most also have some type of Web, client/server, or application integration (SOA / services) development projects as well. Many of the solutions for these use Eclipse based tools. Take Web development for example:

  • HATS
  • EGL using Rational Business Developer
  • JavaServer Faces or Web Services using Rational Developer for i Java Edition
  • PHP using Zend Studio

If other teams in the organization are using Eclipse based tools, then using Eclipse based tools (Rational Developer for i) for RPG / COBOL development allows organizations to standardize on a common development tools platform. This opens up future avenues for implementing common processes and tools (testing, requirements gathering, change management) across all development projects regardless of programming language and runtime platform.

Back to top

Improving Developer Skills

Improving developer skills is closely tied to the above idea of a common development platform. Developers can move to Rational Developer for i and continue working on the same development projects. In addition to the above benefits, this also increases the developer's skills: they are learning to use Eclipse based development tools. This provides a strong foundation for these developers to work on other Web, Java, or Web service projects in the future because these projects will also likely use Eclipse based tools. So the future learning curve is lowered; developers still need to learn the new technologies, but they don't have to learn a brand new development tool from scratch.

Using Rational Developer for i as your IBM i development environment can also help attract, and retain, new employees. The colleges that I know teach RPG programming do so using Rational Developer for i (which the students prefer over PDM and SEU). Showing these students a green screen development environment on the first day of work is not going to go over so well.

Supporting the latest language improvements

The ADTS tools were stabilized as of V6R1. This means that no new function has gone in to them for a couple of releases. In the mean time, the compilers have been adding tons of features to COBOL, CL, SQL and RPG. In particular RPG has added free-form declarations and there are myriads of other enhancements that SEU's syntax checker will not recognize. RDi is getting all of the investment dollars and is getting large improvements like code coverage analysis for all compiled languages and dynamic outline view for RPG. It is clear that staying on the green screen tools will mean falling behind.

Questions and Concerns About Adopting RDi

I don't ever recall presenting or demoing RDi and having someone say that they just aren't interested. Normally developers and managers alike are excited about the features and possibilities that RDi offers. However, it often comes down to the learning curve. Developers go back to their desks, get caught up in the day to day things that come up and never get the time to try, or become proficient in, using RDi.

RDi is a new development tool for SEU / PDM users, and there is a learning curve to become proficient in any new tool. Based on some case studies we did with WDSC (but also apply to RDi), the expected learning curve is around 3 weeks. Around 3 weeks is when developers that were surveyed reported they were just as productive with the RSE and they were with SEU and PDM. Afer week 3 the productivity with the RSE went higher.

Of course these results will vary depending on factors such as commitment and existing skills. There are things you can do to shrink the learning curve and maximize productivity, such as formal training and regular team meetings to share questions and tips. These are also summarized in the case study article.

One of the concerns we often hear from developers is the time it takes to use the mouse. The mouse is the easiest way to learn RDi; by "clicking around" you can explore the user interface and find lost of the features it contains. However, power users want to use the keyboard to quickly navigate around. The good news is the RSE is full of keyboard shortcuts to enable those power users, the bad news is it takes time to memorize them so they just come naturally. I rarely use the mouse any more when working in the RSE (which becomes a problem when I have to demo and nobody can follow what I'm doing). A good place to start is the System i Developer keyboard shortcuts "pinup" (you should print it and pin it up beside your workstation).

Back to top

Page Feedback