Musing on Comments, Updates and Travel

Some days, ideas for this blog seem to flow like water ... and then there are the days like today.

What to talk about? Well, for openers a quick thank you to Mihael Schmidt and Aaron Bartell for pointing out some of the tools we missed in our recent review of the world of RPG-oriented Open Source software which appeared in last month's EXTRA. If you don't subscribe to EXTRA (and you should!) you can find the original article here  and Mihael and Aaron's comments here. Thanks, guys. We won't elaborate on why these particular gems were omitted from the original list as we've already done our groveling in the comments section mentioned above. 

One comment we haven't yet responded to, until now, was from IBM's Nadir Amra. Nadir pointed out that our comments on IBM's offering, in the area of consuming Web services in RPG, was somewhat disparaging. And, more to the point, that we had apparently missed out on some recent updates that meant that RPG stubs are now generated to make the interface simpler. Guilty as charged. We had completely missed that change, Nadir, and thanks for pointing it out to us. Since the C compiler is still needed though we are however going withhold judgement on the utility of the revised version until we've had time to give it a test drive. We'll report back here, or in EXTRA, when we have had a chance to do that.

The fact that we were completely unaware of this particular update though does highlight an issue that we've encountered a number of times recently -- unknown IBM i enhancements. Maybe the details of this upgrade were published somewhere but we were completely unaware of them -- and we'd known for a while that some changes were in the offing. Yet we still missed them when they happened. If you know of a reliable source for information on these kinds of "between releases" updates please let us know -- 'cos we obviously aren't catching them all.

As we write this, we're in sunny Livonia, MI. Or at least it was sunny when we arrived -- it's dark right now. We're here for the annual MITEC conference and are looking forward to meeting the faithful at tomorrow's gathering of the clans. Our System i Developer colleague Paul Tuohy is here as well so we'll get the chance to catch up on the latest news from his time at COMMON Europe in Milan a couple of weeks ago. If you're at the conference please come up and say "Hi" -- we always enjoy meeting our readers in person. This is always a great event and it makes a nice change to be able to drive to a conference for once. For us, it's a four-and-a-half-hour drive -- longer than we'd normally take but no longer than flying. Wel,l the actual flight is only 30-40 minutes, but when you factor in the drive to/from the airport and all the extra time you have to spend in security screening, etc., it actually turns out to be as fast to drive. 

On that subject, we don't know how many of you regularly cross the Canada/U.S. border as we do (or for that matter the U.S./Mexico border) but it always strikes us as strange that you get a much more intensive "grilling" when flying cross border -- with limited luggage -- than you do when driving across with a whole car load of stuff. Guess they have their reasons -- but it does seem odd.

Until next week, go forth and do good things.

Comments

[Thierry Bernard]

IBM has a Web page that is intended as the main place where enhancements will be communicated:
https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/IBM%20i%20Technology%20Updates

Have a nice day.
Thierry.

[Scott Klement]

Even the new wsdl2rpg.sh for the IWS client is still annoying. The C compiler is only part of the problem -- the otehr problem is that the source is all placed in the IFS. That includes CL code (which can't be compiled from the IFS, so you need to use CPYFRMSTMF to put it into a srcpf)

But it's much improved over the old one that generated pure C code and expected you to call it :)

[Jon Paris]

@Scott "But it's much improved over the old one that generated pure C code and expected you to call it :)"

Ignoring the C compiler issues, I'm still trying to determine how much (if anything) it saves me compared with using HTTPAI. Fatherhood issues aside, how would you compare them Scott? Do you think the learning curve for this (unfortunately also named as WSDL2RPG) is shorter? If not it is hard to see the benefit.

[Roger Anderson]

At one time, a partner & I (the Handerson Company), made a temporary career of converting S/36 COBOL to AS/400. It was then that I learned that to be efficient, you write programs to fix source code. We also installed a few AS/400s that replaced monster S/36’s w/ huge diskettes. I wonder how many places out there are still running S36/EE code?

[Scott Klement]

Comparing HTTPAPI and IWS Client (wsdl2rpg.sh) is like comparing apples to apple pie.

Sure, there's some stuff in common (namely, the apples) but there's a lot of differences. Apples can be used to make other things besides apple pie! And if you're looking for apple pie, it's a lot easier to buy the pie than it is to make it from apples.

HTTPAPI implements the HTTP protocol. HTTP can do many things. It's true that SOAP web services use HTTP (much as apple pies use apples) but there's more to them than that -- there's SOAP messages and WSDL files and the process of converting parameters into those two XML formats. HTTPAPI makes no attempt to do that part for you, and expects you to do it yourself. Whereas IWS client does all of that for you.... so, if you set the C compiler and IFS issues aside, of *course* it's easier to use.

But now suppose you don't want to call a SOAP web service. Maybe you want to call a REST or POX web service. Impossible to use IWS client for that. Likewise, suppose you want to use HTTP for something else? An ordinary file download, for instance... or maybe you want to fill in and submit a form on a web page (taking the place of a browser)? Possible with HTTPAPI, impossible with IWS client.

So the question is really "how difficult is it to construct an XML message in your program?" and also "how difficult is it to parse the returned XML message?" because IWS does that for you.... HTTPAPI does not. If you find those things to be relatively easy, then you'll prefer HTTPAPI because of the added flexibility. If you find those things to be very difficult, and you only need to call a SOAP web service anyways, you'll probably be happier with IWS.

So the extra hassle of converting IFS files to source members, and/or storing your source code in the IFS, and/or needing a C compiler... these things might be important, because they may add enough complexity that HTTPAPI is easier, even for SOAP messages.