Okay, I see what you mean by "native" now and I do agree with that. In
another forum I had posted that I thought it would be nice to have an XML
data stream option.

The basic idea was to have something like an H spec that you could specify
you would like the data stream to be transmitted as XML instead of the 5250
data stream. This would give you the option to use just about any language
(even scripting languages) to parse the XML and display it as desired.

Thanks for all input on this. It's actually made me re-think how this could
work. I do see how you might be able to have a native option. I do think
some kind of data stream that can be interrupted would be nice though. That
way if IBM came out with a Windows only, anyone could develop something else
for Linux and/or Mac.

James R. Perkins

On Mon, May 11, 2009 at 20:02, M. Lazarus <mlazarus@xxxxxxxx> wrote:


See inline:

At 5/11/09 11:38 AM, you wrote:
I guess I need to understand what you mean by "native". I don't think
something that only runs on Windows or only runs on Linux is a viable
solution these days. I would think that would be up to the developer what
to develop the GUI for.

The client can theoretically be any platform. By "native" I mean
that the languages and API's will directly support sending the
commands and maybe even the content of the GUI. A simple approach
could be some DDS extensions, accessible via an extension to the
EXFMT keyword. But I don't want to get into the implementation
now. I just believe that folks in the IBM labs have the smarts to
implement this, if IBM chooses to allow it. Plus, it's long overdue.

The output of VARPG is Java. Why not just use Java instead of trying to
VARPG to output Java? I know it's another language to learn, but I think
is MUCH better for UI than RPG ever can/should be. I think making RPG to
style will break how great it is for back-end business rules.

Java has a different paradigm, has different syntax, and can have
performance issues. RPG'ers do not want to have to deal with another
complex language in order to get a GUI implemented.

I agree though that third party products are not the way to go. I don't
think there is any good way to convert what's already done to some nice

Why not? A little tweaking should be all it needs.

It just plain needs to be re-written. I think that's where we need to
our thought process. We don't need to convert some DDS written in 1989 to
some fancy UI.

Maybe via a CSS type of control file?

It just needs to be redeveloped. It would be very expensive
and not really an easy thing to do, but waiting just makes it worse.

I don't know how expensive it would be, since IBM has developed
several products that might be able to be utilized (e.g. the VARPG
components), nut I do agree that it needs to be done and really soon!


James R. Perkins

On Sun, May 10, 2009 at 21:18, M. Lazarus <mlazarus@xxxxxxxx> wrote:


There are quite a few vendors that provide GUI enabling
utilities. They all have downsides, including: Cost, effort to
integrate, keeping the green screen and GUI code is synch, needing to
learn another language (in some cases.)

A GUI is not necessarily stateless. Why can't DDS be event
driven? The basic converted functionality can be stateful. VARPG
has shown that RPG can do the job. One of the wonderful features of
this system is that the major functionality is INTEGRATED.

Us developers would definitely use an integrated, native GUI. Some
of the necessary keywords are already in DDS (useable by the
almost(?) defunt WSG product.)

One caveat is that it all the components must be a no-charge part
of the OS, so software vendors can write to it without concern that
their customer base would not have the LPP.

As an aside, I just spoke to a colleague that is going through a
similar situation with his clients. With the younger management
making decisions, they are looking to move away from their trusty IBM
midrange computer and looking at something snazzier. It's a losing
battle! Even the traditional Midrange Faithful are deserting. This
hasn't happened in such large numbers until the last few years.

If we use a third party product, we much pass along the costs of
that product to the customer. That tends to make our product price
uncompetitive. So, even though we might be in the running with a
shiny GUI, we then lose on the price.

I hope that IBM wakes up before it's too late and realizes that an
integrated GUI is now a core requirement, not a fancy add-on.


At 5/10/09 01:44 PM, you wrote:
I have not been on a sales call, but most ERP vendors these days do
GUI. It's usually just ran through something like Seagull and in
general I
don't usually like them, but it's there.

There are several GUI options. You can write a nice GUI in .NET,
Faces/Pages, Swing, or even CGI.

Well, they (IBM) had VisualAge RPG which not many people seemed to
(before my time so I don't really know why). They have HATS and
not really a great option but it's there. Now there is EGL.

The main problem as I see it is that most vendors don't usually want
re-write all their displays. That's what really needs to happen. I
any feasable way to convert DDS to some fancy GUI. A native GUI needs
event driven which DDS and usally the controlling RPG are not. When
presses F3 you can't just lock the screen up and do what you would in

So, you would have to re-create all your DDS and display controlling
programs anyway. Why does that have to be native? Why would it not
has much if not more sense to use an already created and proven

James R. Perkins

On Sat, May 9, 2009 at 21:04, M. Lazarus <mlazarus@xxxxxxxx> wrote:


At 5/8/09 01:06 PM, you wrote:
I personally don't think that RPG needs a nice GUI like others do.

Why do you say this? Have you gone on a sales call where your
competition has the GUI and you don't? I have and it's not
pretty. The non-GUI software barely has a chance. That's just the
reality for most decision makers. They want brand new software
looks and feels brand new.

In the past IBM has tried to give us this and very few people did
anything with it, so they gave up and how can blame them.

Did anyone find out WHY it failed? Was it too expensive? Too
difficult to implement? To resource hungry? Too limited in

I'm betting that it was one or more of the above reasons. That
does NOT mean that we don't want / need a native GUI to make us
competitive. The same way that IBM woke up and included TCP/IP as
integral part of i5/OS or risk losing the entire midrange business,
they need to recognize that an integrated, native GUI is crucial to
remaining viable.


This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.