Kill RPG, the AS/400 lives on (was Re: Midrange Computing is liquidating.)

This buys into the assumption that everyone who uses RPG is tied to green
screen apps.

Once you move into the client/server/N-tier architecture, this cannot be true.
Even today, with Joe Pluta's RPG revitalization, IBM's free CGIDEV2 library,
Brad Stone's e-RPG, data queues, and sockets, you now take RPG into the server
arena.

Here, you can't kill RPG just because it "happens" to run the vast majority of
green screen apps. As a matter of fact, you cannot penalize RPG whatsoever, as
long as you stay away from display files (this is where the CPFINT governor
kicks in, I believe - what were the results of that hypothesis?). Every
program needs to open, read, and write files. If the governor doesn't affect
data queues or socket connections, you should be safe using RPG for server
apps.

A solution would be to use a combination of e-RPG/CGIDEV2 for back-end
processing, and Joe's Java servlet revitalization to move to the N-tier
architecture. If done right, you could seamlessly migrate from green screen to
browser/java based without changing the application. (Side note: can an RPG
program make a CGI request without going through the browser, I am thinking
about a socket connection. It would need to "emulate" a HTTP connection, I
suppose. I know nothing about how to do it, just thinking out loud.)

I don't believe the linking of green screen apps and RPG is the right answer.
You might as well say the same thing about cobol, or even C when using
standard in/output. This is perception, not reality.

I don't know to classify this as a rant, observation, or even a real idea. I
just can't believe that killing RPG will make the AS/400 stronger, in light of
the above.

Loyd

On Fri, 27 Jul 2001 21:36:44 -0700, John Rockwell <midson@earthlink.net>
wrote:

>Here's a thought.  What if IBM thinks the only way the iSeries can survive is 
>by
>getting rid of RPG?  The thinking would go something like this.
>
>   1. Customers are tied to their legacy applications by the programs they've
>grown accustomed to.
>
>   2. These legacy applications taint the iSeries when it's competing against 
>the
>latest technologies because competitors dismiss
>       them as old green screen applications.
>
>   3. Most of these green screen applications are in RPG and a lot of the more
>valuable ones are interactive in nature.
>
>   4. Now what happens if we suddenly make a seemingly unrelated marketing
>change, breaking the pricing of the AS400 into
>       two separate features, batch and interactive, and then charge a fortune
>for the interactive segment.  And let's make it even
>       more interesting by tuning CFINT so it really does succeed as a governor
>when you move to versions 4.5.
>
>   5. How long will it take for RPG and the high price of the interactive 
>feature
>to be linked together, making new technologies
>       like Domino, JAVA, et al, more appealing because they conveniently run 
>in
>batch as far as the AS400 is concerned (even
>       though this changes the definition of batch a bit)?  Thus through a 
>little
>sleight of hand the argument changes from language
>       vs. language (with a company usually having to rely on its own in-house
>programmers judgment) to an argument simply
>       over dollars (with a company having more than enough accountants to 
>make a
>case against the legacy).
>
>Just thinking out loud of course.  It also makes me wonder about the 
>requirement
>that you have to move to 4.5 (where the governor works very well) to get to an
>820 box.  Some weekend when no ones on the system I'm going to start a bunch of
>interactive jobs, set them to 0 priority, and see if they can give the 
>governor a
>run for its money.  (Of course I won't change the class priority value in case 
>I
>have to re-IPL to get QINTER functioning again.)

--  
"The killer doesn't see the world like everyone else."
"How does he see it?" "Differently." --Millennium
lgoodbar@ispchannel.com  ICQ#504581  http://lgoodbar2.pointclark.net/
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---