RSE Trials (and Tribulations?)

In our latest EXTRA article we wrote about our favorite tool for developing RPG/COBOL/CL/DDS code--RSE, which is currently packaged in RDi, previously in RDP and WDSC.

In that article, we pointed out that there is a 60-day free trial for RDi. We've heard of some issues users have had related to downloading the trial and then turning the trial into a licensed program. Of course, the second part assumes, as we anticipate, that you will be sold on the value of the tool by the end of the trial period. So we thought we'd point you to a few hints and tips that we've found on both of those processes.

Downloading the trial code. The download page is easy enough to find here. There are a few things to keep in mind.

 

• You will need an IBM ID to do the download. It's free but a step you'll need to take before you can complete the download. You won't need your IBM customer number or anything so it's relatively painless to get an ID if you don't already have one.
• Later you'll see that there are two different ways to download--via Download Director or http. A link on the page describes some of the differences. Download Director seems to have better recovery options if you encounter problems during the download but your mileage may vary on that.
• Next you'll see that there are four different zip files (disk images) to be downloaded, each is more than 1500 MB. We've heard widely varying experiences of how long it takes to do the downloads. Suffice it to say that many (but not all) have found the download to be measured in hours rather than minutes. A couple folks' downloads have taken days! So be prepared for a wait. If you're just loading the base RPG/COBOL tools then you can install with only the first two disk images. However, when you go to apply Fix Packs, it may ask for the other two images because there may be fixes for those options. So although you will probably need all four disk images eventually, you can do your initial install once you have the first two. If you need help with what to do after downloading the disk images, take a look here. Choose Installing > Installing Rational Developer for i > Installing from an electronic image: task overview.
• It's also possible to install it via the internet without requiring a download of the disk images. This is the way we installed trials of earlier releases but this time the trial download page doesn't mention that. It does require a bit of manual intervention so if you want to try that option, take a look at the helpful guide, which was helpfully provided by Eric Simpson on the IBM developerWorks site. Jump down to the update on June 19, 2013, on that page for the details. You may find this faster if you're just looking to install RDi on one workstation rather than several.
• Next, let's say you have the trial installed and, perhaps with the help of our "RSE Quick Start Guide," you get started using it and get hooked. So you purchase a license to RDi. The license can be purchased in two says--via Passport Advantage (aka the software channel) or through the same way you order your hardware and operating system, probably from an IBM business partner (aka the hardware channel). We won't attempt to explain why you might buy it one way vs. the other because we're not really clear on that question ourselves. (If any of our readers can help answer that from your own experience, feel free to comment below.)
• Once you purchase your license, you will need to get a file that contains something called an Activation Kit. Once you get your Activation Kit, it's pretty straightforward how to use it. If you need guidance, the same link we referenced for help with the installation process has a section on "Activating your product." Getting the file containing the Activation Kit can sometimes be more challenging. Once again, a helpful IBMer, Edmund Reinhardt, this time, provided some documentation on that subject on developerWorks.

After you have installed and successfully activated RDi, enjoy the great features you find there. And if there are features you think it really needs that you don't find there, consider putting in an RFE (Request for Enhancement), as we blogged about some time ago.

Modernize? ... Schmodernize!!

What with our involvement in the upcoming IBM Modernization Redbooks publication, we've been paying even more attention than usual to the topic of application modernization. So when we saw this piece from fellow writer Alex Woodie highlighting a study on CIO's attitudes towards green screens we were intrigued.

This study was undertaken on behalf of Micro Focus who has long been a force in the COBOL world. In recent years, the company has focussed much of its attention on providing tooling for mainframe COBOL shops. In that regard they are not dissimilar from many of the modernization tool vendors in the IBM i space. Mainframes, COBOL and 3270s provide a very direct comparison with IBM i, RPG and 5250s, so we thought it would be interesting to see how the kinds of questions asked and the responses received matched our perceptions. Given that nearly 600 respondents from around the world completed the study, the survey size is certainly large enough to potentially provide some valuable insights.

Of course there are differences between the two platforms. Our externally described files, screens and reports mean that the maintenance burden is typically a little smaller than in a mainframe shop. Similarly updates in the RPG language have outstripped enhancements in the capabilities of the version of COBOL (i.e., the non-OO COBOL) that most mainframe shops use. That makes it a lot easier for us to deal with the programmer shortage by taking C, Java or PHP programmers and training them in RPG. We would not want to be running a COBOL shop and having to try to persuade young programmers to learn the language. That said though, we would expect many of the problems they face to be remarkably similar. A quick perusal of the survey results seems to bear this out.

For example in the section on "Why are green screen applications still used?" the results seem very much in keeping with our own experience. Some 55 percent are dissatisfied with their green-screen apps, but seem to consider the risks and costs of fixing the problem to be too high, particularly in light of the shortage of skills. Notice that this is not an absolute "there are no programmers" statement; rather it is a comment about a lack of programmers with the _skills_ to perform the task. Now where have we heard that before?

Indeed the follow-on chart highlights that most sites are likely to be using emulation products--even on phones (shudder) and tablets--than actually modernizing (6 percent) or replacing (5 percent) the old apps. We have a feeling that modernizing via intelligent refacing technology and/or Open Access based tools probably means that these numbers would be a little higher in the IBM i world but not perhaps by a huge margin.

There's a lot more of interest in this study but we'll highlight just a few more points.

First, 89 percent have had complaints from end users about green-screen applications. Those of our readers who adhere to the "sometimes green is best" philosophy might be surprised by that.

Second, some 66 percent stated that using green screens negatively affected staff satisfaction levels, with some 19 percent of them saying that impact was significant in hiring, training and retaining staff. The survey goes on to study the roots of these problems in more detail which provides interesting reading. 97 percent said that end user satisfaction would either probably or definitely increase if the green screen applications were updated.

Third, while most of the IT departments surveyed consider themselves innovative, only 28 percent believe that their users consider any updates to existing applications to constitute "innovation."

So updating the user interface to existing applications is good. But to be considered innovative, users expect more, such as mobile apps or "technology that has new or surprising features and functions" (whatever that means!).

It is perhaps a sad reflection of this crazy world that modernizing what you have is not seen as innovative. We're not sure if that reflects a lack of vision on the part of the responders or simply that having a new "Now you can 'friend' us easily from your phone" app is now considered business critical.

Take a look at the study. We'd be interested on hearing how well it maps to your own experiences.





 

Offer Alternatives, Don't Whine

Last night we attended a meeting organized by our city aimed at gathering public feedback on potential changes to the road adjacent to our house. The traffic volume has increased radically over the last few years and it has become increasingly obvious that something needs to be done to alleviate the problems this is causing.

The most depressing thing about the meeting was not the attitude of the city staff and consultants--they seemed to be trying very hard to explain the issues and potential solutions and seemed to be amenable to alternatives. The problem we had was with the attitudes of the whiners who only had one message, "No." This despite the fact that they are complaining loudly about the problems that the current traffic volumes are causing them. But they just seem to expect all the issues to disappear magically without any changes. In other words they are not interested in offering alternative solutions, they seem to just want to whine.

In some ways it reminded us of some of the discussions that have occurred over the years within our IBM i community. There are many examples ranging from the pricing and capabilities of RDi, new features in RPG, advertising (or the lack thereof) and more. Much of the time people just seem to want to complain rather than offer alternatives. We know we've been guilty of this ourselves on occasion.

The result we suspect, is that in certain areas of IBM the IBM i community are just regarded as a bunch of whiners who will never be happy no matter what.

Part of the problem of course is that our options for directly addressing issues to IBM are somewhat limited. Gone are the days when you could have a chat with your local SE or salesman and they would pass the complaint up the management chain on your behalf. Some users, such as members of the Large Users Group and ISVs have direct access chains, but the rest of us are more limited.

However, a number ways exist to let your voice be heard by those who count. And trust us, they make a difference.

One way is to use COMMON's requirements system and you don't have to be a member of COMMON to use this. The requirements system can be found here. COMMON consolidates this feedback and takes it forward to IBM.

If you have an IBM customer number you can also "talk" directly to IBM via what IBM refers to as the Design Change Request process.

If your requirements relate to Rational tools, such as RDi, you need to use the Request for Enhancement process. Start from here and select "Rational" as the brand and "Developer for Power Systems" as the product. The last couple of releases of RDi have specifically included features requested via this process.

Last but not least you can always comment directly on the blogs of the IBM i movers and shakers such as IBM i's lead architect Steve Will.

Many ways are available to let IBM know of your concerns, wants and needs, but whatever approach you take, remember that specific, practical suggestions and requests are welcome and useful. Whining is rarely welcome or useful.

P.S. Many thanks to those of you who have responded to our request for feedback in last week's post about testing. We're hoping more of you have some kind of testing in place for your applications! We'd love to hear from more of you. It's not too late.

Testing, Testing, Testing ...

We've recently been involved in a number of discussions concerning the testing of IBM i applications. One thing that became apparent very quickly was that nobody seems to have a really clear view of the current "State of the Nation" in IBM i-land--at least as far as testing methodologies and practices are concerned. And before you can even have that discussion you really need to define just what you mean by testing in the first place. Unit testing? System testing? Regression testing? Code coverage? Usability testing? And on and on.

Then there is the whole area of testing tools. For sure any number of options exist for automating testing of Web applications. After all a Web app is a Web app regardless of whether it has the best system in the world driving it (IBM i, in case you have any doubts) or one of those inferior platforms. But how to you know whether the database was updated properly from that Web app? And it doesn't help with code coverage and other areas such as testing batch applications or green-screen interactive applications, etc.

To help us in trying to form a clearer picture of the current state of the art, we decided we would ask you, our noble readers, to help us fill in the gaps.

So here's what we're looking to find out.

1. Does your shop have any formal testing plan in place or is it just down to whatever the individual developer feels the need to do?
2. Do you do formal unit testing? And if so do you use RPG Unit or similar tooling?
3. Do you currently use automated tooling to assist in testing interactive applications--either Web or green screen? And if so, is it homegrown or purchased software?
4. What about code coverage? How do you ensure that all possible code paths have been tested?
5. Do you have formal regression testing plans?
6. Any other testing related issues/practices that apply to your shop?
7. Do you develop code just for your own company's use or so you work for a software vendor? We ask that because we suspect there may be different testing requirements/practices in place based on that.

We really would like to know as it seems that testing is a long-neglected area and we'd like to better understand what is going on out there. Please help us out by posting your comments. If you prefer to remain anonymous for fear that your comments will inflame your fellow developers (or worse still, your management) you can do so, it all depends what display name you use when commenting. Thanks!