System iNetwork

November 2004

November 29, 2004 12:29 PM

Thankful for beta test code...

One of the advantages we have as part of this effort to describe our experiences with WDSC is that we have a channel to report problems directly to the development team inside IBM. This past week they really came through, and fixed a nasty bug with a memory leak (which was probably the source of the Outline View locking up.) We are now beta testing it for them, and so far it is looking good. Great job IBM!

Because the Outline view is now usable, I am back in the WDSC environment, and it is helping. Since the bug fix (which should be available on their web site in the near future), WDSC takes much less time to load, and the individual functions seem to work faster as well. One item we discovered during this process is that there are diagnostic logs which may grow very large over time, and just clearing the log files will make a significant difference in the startup speed for WDSC. Another tip to help keep it from locking up is to use one of the compile options 1st, to be sure that the library list for WDSC is correct, and that it can find all the files and /COPY members that it needs to create its indexes with.

Now that I am using the Outline view more, I have some ideas on what I would like to see it do, that are not in it right now. We will be having an internal discussion on developer topics later this week, and will probably send in to IBM a list of features we would like to see after that meeting. One of the first things on my list would be a quick way to jump back and forth between the editor in full screen mode, and the related outline view (right now I can go from full screen to the multiple window view, but there is no key combination to shift back to the previous editor session AND shift into full screen mode.) The other big item would be a “find” option in the outline view; so that I don’t need to scroll through data structures, fields, files, etc looking for a field name, or could quickly position to a subroutine in a long list of them. (These are minor items compared to the bug they just fixed; so thanks again guys.)

And now, back to the code...

Posted by on November 29, 2004 at 12:29 PM | Comments (3)

November 11, 2004 6:01 PM

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 on November 11, 2004 at 6:01 PM | Comments (3)

November 10, 2004 2:38 PM

A cool tool

I've found a neat tool: Tritton's USB to SVGA product. It allows me to have two monitors really easy, without having to install another graphic card interally. I drug out my old 21" BIG monitor and hooked it up to the Tritton USB adapter and Whammo!, I had two monitors. This is way-cool with WDSc. I put green-screen on one monitor and WDSC in another and I can look at both at the same time in full-screen sized windows. If you've got old monitors laying around and $80, it is worth it! Now I need to convince my wife I need two 19" LCDs.

Posted by on November 10, 2004 at 2:38 PM

November 1, 2004 7:43 AM

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 on November 1, 2004 at 7:43 AM