It's time for us dinosaurs to get out of the tar pits. RDi is here to stay.

By Joe Pluta

We've heard lots of reasons not to use the GUI tools IBM has (not so) gently nudged us toward: WebSphere Development Studio Client for System i (WDSC) was way too much tool for RPG developers. It was too big, too slow, too cumbersome, too limited. Even if those were valid reasons, they have been alleviated bit by bit with each release, culminating in the final breakup of the tool into various offerings, including Rational Developer for i (RDi).

By Joe Pluta

I so had to avoid saying something like "Bananas for Eclipse" in the title, but I restrained myself.

Time to Get Back to the Technical Details

With all that has transpired in the community over the past year, we've spent a whole lot of time recently concentrating on some non-technical or at best tangentially technical topics. The whole V6R1 AD repackaging scheme, while crucial to the financial planning of your company, has less to do with development than with paying for it. And while I've gotten some great comments on those articles, I've also been hearing a pretty regular refrain that I ought to be covering more technical topics.

"But out of the gloom springs the holy

And beautiful Fountain of Tears."

--O'Shaughnessy

By Chris Smith

I have a handkerchief in my pocket just in case someone wants to cry. The fact that IBM will stop marketing Websphere Development Studio Client (WDSc) and WDSc Advanced Edition (WDSc AE) and end support for these products altogether in just two years could cause a few tears to be shed.

Now that you have a working environment, it’s time to do some work! You’ll see how to compile in this tutorial.

Welcome to the fifth tutorial in the WDSC Basics introductory series.

Up until this point, you've configured your workbench, connected to the host, opened source, and set up your environment. Now, we're getting near the end of the basics, and it's time to actually start doing the things that we do as programmers. In this fifth installment, you'll learn how to compile a program and how to check for errors. You'll see how the compile process affects your environment and how you can check your results.

After all that hard work, a reward. This tutorial introduces you to the next great advance in debugging technology: System Entry Points.

Welcome to the sixth and final tutorial in the introductory series "WDSC Basics." You've set up your environment and edited source. You've even compiled it. Finally, it's time to get to the real work: debugging. And while the debugger is an entire topic unto itself, in this last installment, I'm going to let you in on one of the great technological advancements in i5/OS: Service Entry Points, or SEPs. An SEP is simply the fastest and easiest way to debug a program anywhere on the machine, whether it's interactive or batch, in a trigger or in a stored procedure. It's the closest thing to magic that I've seen in a long time, and this tutorial shows you how to take advantage of it.

You can connect and edit, but now it’s time to manage your source. This tutorial shows you how.

Welcome to the fourth in our series of ongoing WDSC tutorials.

In previous tutorials, I showed you how to configure your workbench and connect to your host and, most recently, how to open a source member for editing. Programming is more than just editing source, though. In this fourth tutorial, I'll show you how to manage your environment, including creating a library and copying a source file, all from within WDSC. I'll even show off the versatility of WDSC by giving you a couple of alternate ways to do the same things.