System iNetwork

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 November 11, 2004 6:01 PM