Re: Opinions Wanted -- WEB400

IBM's "WebSphere or nothing" approach and suggesting that more people would
update more applications if IBM would support CGI (CGIDEV2 and other
options) within the tools to give people a lower cost of entry to the web
world.

The problem is that you've got RPG programmers who have been working in RPG and CL and probably nothing else for 30 years, then suddenly they're in a position where they need to show that they can efficiently make GUI apps or they'll be looking at replacing the system with Windows.

So now what happens? Following the IBM party line, they have to basically start over from scratch, learn Java and the other details like servlets, XML, etc. The result is software that runs at a fraction of the speed, has an ENORMOUS learning curve because they've got to learn at least one completely new language, etc.

It's easier and cheaper to buy a package for Windows, and hire some Windows programmers to maintain it. Doing it this way, the project will be done quickly, and you won't have to wait for the learning curve since the Windows programmers are used to GUI programming.

Of course the software may not fit the business needs as well as they would if an iSeries programmer had done it... plus teh OS sucks :)

If IBM made it easy and intuitive for RPG people to write web apps, WITHOUT having to buy separate software at additional expense, and without expecting the customers to also do that they'd have a much better chance of competing.

Of course, CGIDEV2 does that now, today. Unfortunately, IBM's support for it isn't very good and comparitively few people even know that the option is available to them.

As part of the piece I'd like to include some specific, and preferably
practical, suggestions as to enhancements that IBM could make.

I also don't like the way that CGIDEV2 is designed. It exports a lot of functions that aren't related to CGIDEV2 that cause conflicts if you happen to be using the same functions elsewhere. The 'ERRNO' subprocedure is an example of that... A large percentage of my applications use the various unix-type APIs, and none of them can be integrated with CGIDEV2 because CGIDEV2 exports a procedure called "ERRNO" that creates a conflict.

Likewise, they've got definitions for the IFS APIs in the CGIDEV2 /copy file. That conflicts with any app I already have that uses those. (And they didn't even do a good job with the IFS API definitions... using variables instead of constants, etc.)

Personally, I'd like every routine, constant, data structure, etc in CGIDEV2 to contain the prefix "CGIDEV2_" i.e. instead of updHTMLvar(), call it CGIDEV2_updHTMLvar(). If every bit of CGIDEV2 that's exported and available from other programs has that prefix, there'll be no conflicts.

Also, don't use names like "HSPECS" "TEMPLATE", etc for the /copy members. Use a meaningful name!!!

Also, there's absolutely no reason why QC2LE has to be in the binding directory in the H specs when working with CGIDEV2, so why the heck is it in the /copy member? Just because you needed that when compiling CGISRVPGM2 doesn't mean that your callers need it! Not that it hurts anything, mind you, it's just confusing to have unnecessary functions... it confuses programmers into thinking it's necessary when it's not.

These flaws lead to other people creatig their own CGI service programs. I know that Bob Cozzi and Brad Stone both have their own alternatives to CGIDEV2. Personally, I do use CGIDEV2 but I have to have a srvpgm that acts as a wrapper to avoid the name conflicts...

Since so many people do it differently, it'll never be "required knowledge for RPG programmers". For example, you can reasonably expect that if you hire an RPG programmer, he'll know how to use the CHAIN op-code. You can't reasonably expect that he'll know CGIDEV2 because it's a separate option, and because so many different alternatives exist.

That makes it seem like GUI apps in RPG are something of an afterthought, once again making it different for RPG programmers to compete with Windows, Java, Linux, etc programmers.

Not sure if what I'm saying is constructive or just a rant :) But hey, at least it's food for thought...