System iNetwork

September 2004

September 30, 2004 10:25 PM

It requires determination.

Don't start your journey with the expectation that WDSC is PDM with a pretty face. You'll be disappointed. Instead, be determined that you will be able to generate code, debug, and compile your programs. Be determined enough to flounder around for a while in menu bars, drop downs and context menus until you find the option you are looking for. You will learn a whole lot just looking around for the option you need.

Be determined to give yourself time to learn to use the new tool properly. If your first project in WDSC is one with a tight deadline, you're likely going to be frustrated.

Submit a compile of a simple "hello world" program. If you were fortunate enough to make an error, the error listing will indicate that to you. Select the error, watch your cursor. No, it's not PDM.

Soon you will need to enter some iSeries commands, maybe nothing more than EDTLIBL. A little trial and frustration and you find how to do this without going green screen. Things start falling in place but it takes determination to stay the course.

After a few days of "flying solo", read some of the documentation and examples available various places. This helps give you the warm feeling that you are doing things properly or may give insight to a different and better way of performing a task.

Take a piece of paper and divide it in two columns. First column is a list of functions you can do in PDM that you can't in WDSC. Second column is a list of things you can do in WDSC and not PDM. My list started out with slightly more items under column two even though I only used WDSC a few days. Soon, I was removing items from column one as I learned how to it in WDSC. My columns remained static for a while until I learned about User Actions. I really started to clean up column one after that. I found I can tailor WDSC for the current project I am working on or for my global settings. I can make it work the best way for me.

My initial thoughts were those of how slow I was in getting anything done. I'm improving now by learning ways to keep frequently needed tasks available through the remote system explorer and user actions.

I'm getting more comfortable with it daily but it does require determination.

Posted by on September 30, 2004 at 10:25 PM

September 23, 2004 5:54 PM

Initial impressions

Welcome to our account of our journey into the wilderness. While we can’t quite say that we are going where no man has gone before, this sure isn’t the information superhighway, either. We are actually going to attempt to use this “new-fangled” product, and will let you know how it works. (As well as using this convenient soap box to let IBM know how it works!)

I have already spent many hours installing, learning, using, and cussing this new development environment. Right now, there are a few features that I like; but MANY that are very annoying. I suppose some of this is inevitable, given the many years IBM had to polish the PDM tools we all know and love; yet I have to wonder why they could not have given us a way to replicate ALL of the PDM functions, instead of just some of them. Or, maybe the functions I can’t find are just hidden too well; and as I find them I will let you know where they are so you don’t have to spend hours searching for them too.

One of the first things you will notice is that the performance (assuming your iSeries has decent response times) of the WDSC environment is MUCH SLOWER than PDM. It takes much longer to start up, and to get lists of libraries, objects, and members. Even after upgrading my laptop (an IBM A31 Thinkpad w/1.6GHz processor) to a gigabyte of memory, it is still slow.

The second thing you will notice is that the product is incomplete. Many of the tasks you could do easily from within PDM are not included in the base product, and you must purchase additional Eclipse toolsets to duplicate the functionality in the base PDM product. We have purchased a 3rd party toolset to help us view jobs, spool files, and give us SQL access to the database from within Eclipse. This product was a VERY early addition to the toolset, right after the memory upgrade!

I suspect that IBM will be adding features over time which will address some of the shortcomings of the development environment as it stands today; and that we will learn more about the Eclipse platform and LPEX editor, and be able to customize some features on our own. It’s not all that bad if your only task is writing code, but how many developers are lucky enough to say that’s all they do? We all have other responsibilities, including assisting users, monitoring performance, testing and documentation, etc. These other tasks (which could easily be handled with a quick entry on the command line at the bottom of the PDM screens) now force us to exit out of our development environment (usually by using the mouse to click into a 5250 session, complete the task, and then use the mouse again to return to the WDSC environment). This takes much longer than typing the command, and pressing F12 when finished to return right to the place you were at when you were interrupted.

As I continue writing this blog, you may hear me refer to “the rat”. “The rat” is the term I use for the mouse, when I am FORCED to use it because I must navigate to a new panel, scroll down a list, change to a new session, etc. ALL the programmers here are very familiar with a command line interface, and are very productive with it. It is VERY inefficient to remove your hands from the keyboard, move the mouse, type a few characters, move the mouse, etc. You spend a lot of time trying to EXACTLY position the cursor, and then even more time moving your hands back to the keyboard. One of the things I am most disappointed about is the lack of shortcuts (or perhaps an index to them so we know what they are) which can be used without having to touch the rat! If you are developing stuff for the web and designing the browser interface, the mouse is a great tool, and necessary. If, however, all you wish to do is open up a known source member, make a few changes to the text, and then save and compile it; it should not take ANY mouse movements to do this. (IBM, are you listening?)

So far, the experience has not been as pleasant has I had hoped it would be when we found out we were going to be using the new tools. The learning curve is VERY steep, even for someone with experience with other PC based development tools. It is not all bad news, however; and I will share some of the features that I really like about it in the next installment. Until then...

Posted by on September 23, 2004 at 5:54 PM | Comments (7)

September 20, 2004 11:30 PM

WDSc Survivor Web Log Debuts!

Here comes a reality series so scary that we caution iSeries and i5 programmers with weak hearts or pacemakers that it could be hazardous to your health. Five ordinary RPG programmers from the same company will share their tale as they move from the beloved comfort of PDM/SEU to the new and somewhat frightening world of WebSphere Development Studio Client (WDSc). Over the next several months, they'll recount their triumphs and joys, defeats and frustrations as they commit to using WDSc. Follow along with their WDSc Survivor blog as these courageous programmers take on the most monumental change in their development careers. And please use this blog to share your thoughts and experiences, too! Also, watch iSeries NEWS magazine for upcoming WDSc articles from the intrepid five.

The Setup

Kampgrounds of America, Inc. (KOA), has been a long-time IBM midrange shop, beginning with the System/38. Most of its software has been developed in-house, primarily with RPG and DDS. The main accounting system is packaged (and we have an unwritten rule not to modify third-party software). IBM has placed the term "legacy" on KOA's applications, but the team prefers the term LOVELY (Low Overhead, Very Efficient, Lotsa Yield). Specifically:

• The current code base is primarily RPG — with RPG III, RPG IV, and RPG free variations. Since RPG free's advent, the team has used RPG free to develop new projects. For smaller programs written in prior RPG versions, the team uses Linoma's RPG Toolbox to convert from RPG III or IV to RPG free when there's a need to enhance the application.


• The team uses a lot of embedded SQL in the RPG applications.


• The team uses RPG-CGI (with the CGIDEV2 tool from IBM Italy) and Net.Data for Web application development. No, not .NET, but IBM's Net.Data — a simple, effective Web development tool that's free! KOA has been a user and fan of Net.Data since it first came out.


• The team doesn't use Java. KOA uses RPG-CGI and XML to exchange data with its partner.

The Cast

Jef Sutherland, Vice President, Information Services, has been programming in the midrange environment for 18 years. Besides RPG and other iSeries development options, Jef has worked with VisualAge for RPG (VARPG) and Visual Basic (VB) on PCs.
Favorite saying: "Java is a four-letter word."
Favorite song: "Blurry," by Puddle of Mud

Tom Thomson, Programming Manager, has been programming in the midrange environment for 17 years. In addition to RPG development and Web development for iSeries, Tom says he's struggled with CODE 400, yawned with VARPG, dabbled with VB, and really enjoyed playing with VisualAge for Java (VA Java).
Favorite saying: "Shut 'er down, Clyde. She's a-pumpin mud!"
Favorite song: "Clair de Lune"

Dave Flint, Programmer/Analyst, has been programming and providing hardware support on IBM midrange systems since 1978, including Systems/32, 34, 36, 38; AS/400, and iSeries. Dave also has experience with Microsoft SQL Server, MicroFocus Cobol, Paradox, Powerbuilder, and various code-generation packages.
Favorite saying: "If you believe that, I have some real estate for you."
Second-favorite saying: "AS/400 means never having to Ctrl-Alt-Del."
Favorite song: "Anticipation," by Carly Simon

Ken Kantorowicz, Programmer/Analyst, has been programming in the IBM midrange environment since 1988. Ken also has experience with Cobol from his IBM mainframe days and has been dabbling with Web design and PHP.
Favorite saying: "Not today."
Favorite song: Any classic rock

Kyle Newell, Network Administrator, came to KOA four years ago to become an iSeries programmer. But the network needs of the company quickly became a full-time job. Kyle has picked up RPG, but he doesn't use it regularly. He has a strong background in Linux and PHP programming.
Favorite saying: "Bring it on!"
Favorite song: "Slither," by Velvet Revolver

The Plan

Covering the basics, the team must first:

1. Get the requirements for WDSc for the team members' PCs. At the least, they expect they'll have to add memory to the PCs.


2. Install and configure WDSc on their work PCs and do the same at home, because a couple of them work quite a bit from home.


3. Be able to create and maintain their source. They store all source in a single member; source isn't broken out by source type, such as QDDSSRC or QPRGSRC.


4. Compile the source, including RPG, DDS, and CL source types.


5. Review compile logs to figure out why they can't remember to put a semicolon at the end of their RPG free code.


6. Design and change screens.


7. Debug the application.

Getting beyond the basics, the team plans to evaluate:

1. The value of IBM training. They'll send their programming manager to school after they've been using the product.


2. Performance of WDSc against PDM/SEU. For instance, the team has a preconception that it will take longer in WDSc to get started working on source. With PDM/SEU, they can begin editing source from a sign-on screen in 15 seconds using emulation. Starting WDSc, a "healthy-sized" PC application, should take longer before they can begin editing. However, with WDSc, after starting and loading the source members that they need, basic editing, syntax checking, and working the compile logs should be quicker than with SEU.


3. Any time savings that they recognize in their daily programming.


4. Other projects the team might want to use WDSc or Eclipse to implement.

Posted by dcronk on September 20, 2004 at 11:30 PM | Comments (16)

Getting Started

Day 1

Checked our current cds. Went to the web site on CD. Knew we were out of date on CDs. Called BP to get refresh at no charge. $30 to expedite, free refresh as we were already an existing customers. Also sent required PTFs to my operator to make sure they can get on before we install.

Day 4

Started going back to iSeriesNews and the printed publication and actually READING the articles that George and Phil from IBM have written on WDSc.

Day 7

Installed WDSCe client. Started at 11:37 am. Spent a few minutes running through the README files, which I rarely do. I found it was easy to get to the minimum/recommended requiremets sections as the README procewss is a web document instead of a text file. I answered a few calls and walked away from the desk a couple of times so I might have not answered the buttons as often as I could have but the WebSphere install part took until 12:05 and estimated 1.46meg.

The next part of the install was for Code/400, VaRPG and iSeries extensions. That part of the install estimated it needed ~500 meg. The second part of the install took until 12:38 to complete. I did not select to install HATS, which was another option.

All in all, the install took about 1 hour, but there were no gotchas, no lockups.

When finished, I rebooted and was glad to see only one new XP menu option installed. I hate when one install created multiple new menus in XP and you have to figure out which ones are the new ones.

I'm not much of a manual reader, I just go! I started the client. The first time it took 1 minute to start up. But, I could quickly see that this was not code/400! On the left side a navigation panel helped me quicly connect to my iServer though I had options to connect to an WinServer, Linus server or iSeries. Nice touch and easy.

Day 10

Noticed that I don't have the compile option when I right click on any source. When I click on the Compile menu options, it says Compile->Dummy. I think IBM is trying to tell me something.

Day 11

I did the install on my home computer and accessed source from home using WDSc going through my VPN. No problems. On my install at home though, I have the Compile options so whatever happened on my laptop install from before isn't normal. I'll have to figure that one out!

Posted by on September 20, 2004 at 3:30 AM | Comments (1)