Re: IBM getting rid of RPG -- MIDRANGE-L

    All you seem to be doing is describing why the interactive CPW is worth
more to you than batch CPW. Joe has described some of the solutions to point
out that you are not at all restricted to using the environment you feel IBM
has done such a good job on providing. But you keep pointing out that to you
it is better.
    Then in the end you complain that IBM wants to charge for it. For what
other purpose will a vendor provide a solution?
    All the things that you describe as reasons for your being "unable" to
implement Joe's suggestions are things that are unavailable from other
vendors. But it bothers you that IBM would charge for them.
    IBM has not pumped up the price for doing what you want! Lucky guy! You
can still do all those things for less this year than last! All IBM has done
is started offering cheaper agreements for those who don't want to do the
things you do.
    I think you've done a great job of explaining why the services you use
are worth more than the services used by others. I'm sure now you look at
it, you can understand why IBM might charge more. Right?

Chris Rehm
javadisciple@earthlink.net
If you believe that the best technology wins the
marketplace, you haven't been paying attention.


----- Original Message -----
From: "Steve Richter" <srichter@AutoCoder.com>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, July 30, 2001 9:39 AM
Subject: Re: IBM getting rid of RPG


> Rob,
>
> The Joe Pluta approach adds value/functionality to our platform.  That is
a
> good thing. And as he and you point out, there are solutions to each
> situation I describe.  but there are also costs.
>
> Simplicity is one cost.
>
> I can use sda to create a simple menu, create commands that front some
> report producing rpg pgms, add these commands to the menu, insert some
> selective prompting to the commands and in little time I have something
> functional and easy to use for the user.
> To move this to the web, out of the reach of cfint, I have to scrap all of
> this. Something that was simple and effective has to be replaced.  The web
> solution, in my view, has to be just as simple.
>
> re wrkoutq, wrkwtr, wrksbmjob ...The possible loss of a common user
> interface is another cost.
>
> If I can launch ops nav with parms that tell it to display a particular
> outq, that would be an adequate alt to "wrkoutq outq(xxxx)".   Writing a
> custom java script version of WrkOutq is a solution, but the cost is
likely
> to be the common user interface. Each web page version of WrkOutq will
work
> differently. End result: user confusion.
>
> ( There is also the $ cost of the custom approach. Writing the web version
> of WrkJobq takes time = money. WrkOutq ??Outq(xxx) is free. )
>
> re exception handling.  consider a cl pgm. the default excp handler
enables
> cancel, ignore or retry of a failed stmt.  Enables you to investigate the
> cause of the error, then retry or ignore the error so the pgm can continue
> running. Very simple and effective. Any excp handling code you put in the
> pgm actually interferes with this process. I welcome a technical
discussion
> of how to link the interactive web user with the excp messages of the
batch
> running pgm, but be prepared for a long discussion<g>.
>
> All these problems because ibm wants to play its cfint games.
>
> Steve Richter


+---
| 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
+---