System iNetwork

General

November 11, 2004

Feeling Grumpy...

This past week with WDSC has not been good, and believe me; you don’t want to share these experiences. So, as long as I’m going to vent, I might as well do it right...

I am now working on some of the “core” programs in our reservation application, code that has been around for a long time, has been heavily modified over time, and could REALLY use the advanced tools built into WDSC. Unfortunately, they are not “pure” RPG programs, they are SQLRPGLE members. They also make heavy use of copy members, compiler directives and program calls. The code is a mix of RPG and RPG/FREE, depending on when it was modified. I’d love to rewrite these, but don’t have the time; I’ll just have to patch in the changes and go on to the next program.

WDSC just doesn’t like these programs at all. I can use the LPEX editor, but that’s it. If I try to verify, use the Outline View, or the quick links from errors to the source, it has problems. We have been in contact with IBM for some of these for a while now, and had gotten the word that there was an update to the JVM and to a new version of WDSC. Both of these were installed, and the problems persist. NOT what I am used to from iSeries system software.

The Verifier and Outline Views create the worst errors; literally causing the entire WDSC environment to hang. There is no way to cancel out from within WDSC; you must use the Windows task manager to cancel the JVM task before your screen comes back. (It’s easy to see which JVM to cancel though, just look for the one using over 800MB of memory!) The quick links from the errors don’t hang the session; they just don’t go to the right line of the source member. This is really due to the way that SQLRPGLE members must go through a “precompiler” before being passed to the actual RPG compiler itself; and the precompiler inserts additional lines into your source, which throws off the line counters for WDSC.

With none of the advanced features of WDSC useable on these programs, I have gone back to PDM, at least until I am done with the SQLRPGLE programs. A secondary reason for going back to PDM is that it is much easier to copy source lines from one member to another. A couple “CC” entries in the from source member, a “B” or “A” in the target source, and you’re done! Why can’t WDSC manage to do this? Especially when “CC” and the “B” and “A” line commands already work within a single member? Don’t tell me to use the block copy, either. I tried that, and managed to miss the 1st character in the line, in the block I copied. When I pasted the text into the other program, it shifted everything to the left. Then the “intelligent” editing functions kicked in. I couldn’t just insert a space at the beginning of the line, because it would only shift the data in the current “field”, and not move the rest of the line. Since it hadn’t shifted the whole line, it then whined about invalid entries in the rest of the columns. This is improved productivity???

As long as I am up on the soapbox, let’s talk about the RPG language in general, and SQL and RPG in particular. What gives, IBM? Why is it so cumbersome to make these two tools work together? Why does MY source have to be “precompiled” before the RPG compiler can make sense of it? Don’t the SQL developers and the RPG developers talk to one another? Why am I forced to use fixed format RPG to code SQL statements, instead of allowing it to be in free format? A good program not only has the correct logic, but the source should have a visual appeal as well; being well indented, commented, and separated with appropriate white space. Shifting in and out of free format destroys the visual formatting, and discourages the use of the newer features.

Speaking of discouraging the use of the newer features of the language, the most aggravating omission in free format RPG is the lack of ANY support for MOVE, MOVEL, and MOVEA operations! Why bother to use free format, if you have to switch back to regular RPG just to handle multiple indicators, or move data into part of a field. I don’t have time to go back and convert by hand every line where I have used one of the MOVE opcodes, so why convert at all? Or, if I am writing new code, why make me handle arrays on my own, instead of giving me access to the functionality in the MOVEA opcode?

Another pet peeve is the TIME opcode. Give me a formatting option so I can create the same kinds of output in free format that the fixed format version creates! I have legacy database I still need to support, that use the old format for the time, but I can’t generate it in the new programming style. One of the MAJOR strengths of the AS/400 and iSeries platforms is that they did NOT force you to reprogram or convert your application and all its history, and that you could move to a new box or version of the operating system and ALL your old code still worked! This is very valuable to the customer, and by not supporting the legacy data formats you are making a serious mistake. Yes, you do need to support the new standards, and we do use them for new development, but please don’t handicap us when it comes to maintaining our existing databases and applications!

Another handicap is the lack of support for the GOTO and TAG opcodes. (This ought to generate some comments!) I know they are nasty, vile, outdated, and discouraged; BUT, they are all over much of our older code. This code was originally developed on the S/38, and it continues to run just fine. The applications are very stable, and don’t require much maintenance, but when they do, we MUST stick with fixed format; or rewrite the entire program. Flag them with a warning error or something, but add those opcodes! Why break something (with non-supported opcodes) which works just fine? Take the customer point of view, not the theoretical point of view; and maybe you’ll have more success getting the customers to use the new tools!

Anybody else out there feel a little grumpy and want to let IBM know about what they think of how the development tools ought to work???

Posted by at 6:01 PM | Comments (3)

November 1, 2004

Day 15

Day 15
Got my code back from yesterday's snafu. Only took be 15 minutes. Wow, if you keep recoding the same thing, you get better at it! :)

My learnings today:

I attempted to debug an interactive program in WDSc. The setup for the debug session was easy. Then it got to the point of actually doing something and I got a nice window that said it couldn't continue because I didn't have the necessary PTFs installed on the server. I click on the button to list the PTFs and there they were! OK, my fault, but back to green-screen and my trusty STRDBG command!

I went into Window/Preferences/LPEX Editor/Appearance and changed my default font size from 10 to 12. I also found that is where I can play with all my colors. They have a default color scheme that appears very similar to SEU green-screen. Go figure.

I had copied an HTML file from the IFS view in WDSc. The HTML file I opened was in the IFS. I then click on Save As and renamed it. I thought that is saved the copy in the IFS. I then couldn't find it in the IFS though I had been working with it on screen for days. I only found out it wasn't in the IFS when I ran my RPG program and it couldn't find the HTML file I was using as a report template. Come to find out that Save As saves the file to your local, working directory. From the Save As, I couldn't even navigate to any local drives or the IFS. I ended up doing an Export of the HTML file I'd been working on in WDSc and then I could specify the local drive or network drive (IFS). I then closed my open editor for the HTML and reopenined the file from the IFS view in WDSc. Not what I expected but probably my own fault for not knowing more about the environment. Heck, I thought I was doing good getting the font changed!

My recent projects involve IFS files and RPG. I have really enjoyed the fact that I can code and see the results in the IFS from the same environment. I used to have PDM/SEU up in emulation, Notespad in another window and Explorer in another. Now, I have WDSc and they are all open and available through simple navigation.

Posted by at 7:43 AM

October 19, 2004

Fast Views, Shortcut Keys, and more

One of the biggest changes from the PDM interface is that the WDSC is divided into many tiny “panes” or “views” , instead of the single view which takes up the whole screen in PDM. Until you learn to work effectively switching between the different views they are one of the biggest sources of frustration for a new user. I still hate to pick up the rat just to move between views, or open a window to type text into; but I am getting more used to having to do it. It still seems less efficient that pressing a function key or key combination, and then typing in your text; but at least I don’t have to stop and puzzle out which menu tree to navigate to find the option in the first place for MOST of what I am doing on a daily basis now.

I have also learned some tricks on getting the screens to behave the way I like. One of the most used now is activating the Table View, and then “parking” a shortcut to it over on the “Fast View” bar on the left side of the screen. (To park a view or window over in the Fast View bar simply click and drag the window header over onto the bar.) Once a view has been “parked”, it can be accessed by simply double clicking the shortcut. This is a much faster way to switch between views that what I used to do, and by being consistant in the order the views are “parked”; it doesn’t require me to interrupt my train of thought to read or navigate some kind of menu tree.

I haven’t had much success finding shortcut key combinations for things I do often, but two that stand out are CTRL-F for Find (inside the LPEX editor); and CTRL-SHIFT-i to quickly start an LPEX editor session. Now, if I could just figure out a way to combine the two...maybe with a macro...

I have found some other tricks, but these involve the mouse, and I wish there was a way to set my own shortcut keys to jump directly to a sub-menu selection within the editor or table views, rather than having to select something, then go to the menu button, then down to a specific menu item, and possibly even to a sub menu; and then back to the keyboard to type in additional information...(bet you can’t guess how much I LOVE the mouse!).

The first trick is from either the Remote Systems or Table Views, and involves right clicking a member or object within the view. One of the options in the drop down menu which appears is “User Actions”. These are very similar to PDM options defined with F16, and like the PDM options can have substitution variables for such things as the object name, library, member name, etc. By taking a little time and creating commands or CL programs to do some processing, I have been able to transfer some of my most frequently used PDM options over to the WDSC environment.

The reason I am doing some custom coding here relates to library lists. One of the biggest traps I have run across so far is the difficulty determining what library list is being used within each view or command. Instead of spending any more time fighting it, I just created a series of programs which set particular library lists, and then use the user options as a quick way to call these programs. MOST of the time, this seems to associate the compile library lists the way I want them, as opposed to just running an EDTLIBL command in the command view. For some reason when I try to run the EDTLIBL, it doesn’t seem to affect the compile options; then I chase my tail trying to figure out why the compile bombed, and it is only the library list... #%#%%#@

A second “mouse” trick is used to quickly view /COPY members when the cursor is positioned on the line. Once the cursor is on the specific line, you can right click either in the source line, or in the sequence area; and a menu option appears to let you either edit or browse the copy member! This is actually a time saver, even counting the time that it takes to download the member from the iSeries server. Don’t try to find this in the help text, it is not there. I remembered having gotten to it once, somehow; and tried searching for /COPY, thinking that the menu tree/item would be described, but no such luck. I had to go ask a coworker if they remembered how, and between us we finally figured out that the cursor MUST BE on the line with the /COPY statement before the menu item shows up, and only THEN can you choose to browse or edit the member.

I just now had one of those AHA! moments, thinking about how that worked...
PDM is basically oriented in a verb/object style; and WDSC is just the opposite. With PDM, you would press F15 to indicate you wish to browse (verb); and then you select the object to be browsed (type it in or press F4 for a list). WDSC works in reverse – once you select the object (/COPY statement containing a member name), WDSC will then allow you to select an action appropriate for that object. Maybe this insight will make it easier to find the “hidden” stuff??? This may seem elementary to a programmer used to thinking in object oriented style, but it is not a trivial adjustment if you expect the program to be similar to PDM, for example.

The final mouse trick for today is to double click on the header tab of a source member you have opened with the LPEX editor. This quickly shifts the editor into full screen mode, so you can see more of your program at one time. Double clicking the tab again will return you to the same panels you had when you double clicked the 1st time; allowing you to quickly show or hide the outline and error views. (Would it be too much to ask to have this function available as shortcut keys???!!)

If you have been following this blog, you know we have been getting comments on these entries; some favorable, and some not so favorable. Please keep in mind that we are NOT experts using this tool, just a group of programmers thrown into the deep end and forced to learn to swim while still supporting the users. While we are trying to present a fair picture of the tool, the truth is that it does have a steep learning curve, especially for people comfortable with PDM. The more we use the tool, the better we like it, but it is not always a positive experience the first time you try something! The encouragement several people have expressed is very welcome and appreciated, and helps keep the frustration level in check. Especially useful have been some of the tips on where to find more information and other WDSC resources. Be sure to read the comments as well as our text! We probably won’t try to answer specific questions, but if enough people are looking for the same thing we may try to go into more detail in a specific area.

Question for the day... I wonder if this would run any faster if we were connected to one of the new model i595s?

Posted by at 7:21 PM | Comments (3)

October 7, 2004

Diary entry 2

Day 12

Start working on my first real project at work. I easily copied some source code from other members and started a maintenance screen program. I needed a new file, DDS screen and RPG/SQL maintenance program. I wanted to see if I could find out how to get the equivelent of the screen designer so I loaded the DDS source and pressed F1. I used the search button to search on "design screen". The first time help has to index from on-line sources, it will take about 5 minutes to load the index. The indexer says it only happens one time.

When working with DDS source, I noticed the + for field positioning based on the end of the prior field position gives me an error. Found out from IBM this is actually a bug in the editor that hasn't been reported. Let's see how long it takes to get fixed!

It is good to know that the member is locked. While editing in WDSc I went to PDM and tried to access the member. I got the message that the member was in use.

Also learned from IBM today that my inability to see the compile options on my first install could be due to a corrupt workspace. A workspace is a series of files and folders usually found in \my documents\IBM. I exited WDSc, renamed the folder 'workspace' to 'workspace_orig' and then restarted WDSc. It worked! I was able to copy my filters from 'workspace_orig' to 'workspace' and that was OK but I couldn't copy the files from my user commands over initally. We'll see if IBM comes up with a way to do that. Luckily, I only had one!

Day 13

Back from vacation and Oh how I missed WDSc! OK, a little blog sarcasm. I thought it was pretty cool that when I start WDSc, it remembers my view, layout and environment (or so I thought). I could see that my library list was just as it was when I exited WDSc previously. Then I made a change and compiled and got a whole bunch of errors ... more than normal for a couple of lines of code change. Turns out that compiler couldn't find any of my files. Why not? I asked. The library list was set. I even emailed a screen shot to IBM. Turns out, the way the default preferences are set, it restores the "view", but that is it. The library list isnt' really set. You can turn this off in preferences so it doesn't appear to load your last session's environment. I still think it is a bug. If it shows the environment, it should set the environment. I'd take the extra 15-20 seconds hit at load if it really restored my environment.

Day 14
I'm in WDSc all the time now. I've had to change some of my thinking on how I spend my time as it takes a little longer to load. But, once loaded, I've become very comfortable with the basic editing functions. I'm still not sure how to split screens to show the same source in two different windows but I'm sure it is there. The HELP hasn't been much help in this area yet.

I used Code Designer to make some screen changes. This is going to take some getting used to! I need a good tutorial on using Code Designer for screens, that is for sure.

I still can't get my compile error messages to go to the source line. I get an error message about a file not being found in qtemp. Tom is getting it too. I send screen shots to IBM to have them check into this one. I have to switch back to command line to review source compiles.

I also had my biggest failure today. I had made significant changes to the code in WDSc. I went to save and got a message box about the source on the server being updated since my last save. I didn't make any changes to the member, so I can't figure out why I got the message. Anyways, I thought I was taking the option to update my changes to the source member, but the default is to update my view of the WDSc code with the original source member code. I basically over wrote all of my code changes. There isn't an undo for this one! Rats! I lost about 1/2 hours worth of work.

Posted by at 7:18 AM | Comments (2)

October 6, 2004

Initial Impressions - the Good news

Following up on my original impressions, I promised to let you know about the features I liked, and to tell you where to find some of the hidden features of WDSC.
The first feature I FOUND that I really liked was the Outline view. This should show up as a window within the Remote Systems Explorer perspective, but it will be empty until you select a member for editing. Once you have a member open for editing in the LPEX editor, use the Refresh button in the Outline window and it will examine the active source member and produce a GREAT cross reference! Be sure you have downloaded the latest release of WDSC before using this, as they have fixed some bugs and added features which make it much better.
The different branches of the "tree" allow you to drill down for more information about files/fields, procedures, etc. The best part is that you can expand the procedure or subroutine nodes, and be presented with bulleted lists of where the routine is defined or referenced! You can use this view to QUICKLY understand and navigate between the function definitions, code, and places where it is called. (You can do the same thing in the LPEX editor by filtering a selection, but this is much faster once the view is refreshed.) One "gotcha" is that the outline view is cached on the local PC, so I ALWAYS refresh the outline before I use it, when I am starting to work on a member I haven't touched in a while.
Late last Friday I STUMBLED ACROSS a feature that would have been my choice for the default perspective as a PDM user. This is the iSeries Table View, found under Window/Show View/iSeries Table View. This brings up a prompt which allows you to select the library and/or file and/or member(s) to use to populate the list, JUST LIKE PDM! Even better, once the list is populated, you can RIGHT CLICK on a member name and a popup will give you access to the PDM options we are all so familiar with. There is a command line down at the bottom, and you can sort the view by clicking on the column headers, so you can sort by name, last change date, etc.
There are still a few rough edges in some of the options, as I have had intermittent problems getting the Position to... option working, and I would really like to be able to save my column layouts AND WIDTH SETTINGS; but these are minor compared to the HUGE benefits to anyone who is used to the PDM interface.
Another gotcha/feature to be ware of is the Find String option. If you select all the members in a source file, then run "Find String", it is time for a looooong lunch! A much better option if you will be searching more than a half dozen members is to use the Search/iSeries menu options on the main WDSC screen. This performs the search on the iSeries itself, instead of copying EACH MEMBER down, and then performing the search on the PC. The results of the iSeries search are shown in a separate window, and just like the outline view, if you click on the member name where the string was found, you are positioned to the exact line in the source code where it is used!
Now that I have found many of the tools I use every day, I am spending more and more time in WDSC. While I still have to go back to PDM for some things, the list has been narrowed considerably by finding the Table View and its associated options. I wonder what else they have hidden away for us to find...

Posted by at 11:43 AM | Comments (1)

October 1, 2004

Views from the youngest.

Welcome to my view of the journey into WDSC. I'm the youngest here at KOA to use this product so I figure I will have the easiest time getting used to it (a fact I remind the other guys of quite often). I'm the network administrator for KOA which means I spend most of my time playing with wires and routers and switches. I do like to program when I get the chance with most of my programming experience in HTML, PHP and PERL.

When I first came to KOA Jef did his best to make me a RPG programmer, but coming from the Windows/Unix world I had a tough time picking up the fixed form format of RPG III, luckily for me RPG IV and RPG free came out shortly after Jef got me started and I had a little easier time picking it up. Since I wasn't a true blue RPG programmer, though, I still struggled with SEU/PDM. Again luckily for me WDSC then came out and that is where I am at today.

Most of the programming I will use WDSC for will still probably be HTML, PHP and some Net.Data, I am going to try to get the programmers to throw me some bits and pieces of RPG from time to time.

So far I have installed WDSC on my PC. The install went smooth although the program uses quite a bit of disk space and requires a lot of RAM to be useful, makes me wonder if Microsoft had a hand in developing WDSC:) Once I had it installed I have created connections to our development iSeries and to a Linux machine that I do a little web programming on.

The connection I created to the iSeries was very straight foward. The connection to the linux machine required a little more work, but by following the instructions in the WDSC help I was able to get the necessary software installed on the Linux machine and then able to make the connection. Next we will see if I can do some actual programming. See ya next time....

Posted by at 3:36 PM

September 30, 2004

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 at 10:25 PM

September 23, 2004

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 at 5:54 PM | Comments (7)

September 20, 2004

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 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 at 3:30 AM | Comments (1)