× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



To me RPG OA is a Program Ephemera. It’s like CCP on System/3 where
everybody knew that this wasn’t going to last and CCP also completely
disappeared with the introduction of System/34-36-38 with RPG 5250 support
through FORMATS and DDS.



For those that may not know what CCP was, it was the first time IBM
midrange had a SW feature that could connect screens to the midrange system
besides System/3 Model 6 that has a build in simple terminal that later was
transferred to System/32 as the little window with 8x40 bytes of display –
the file was special and the device type was CONSOLE witch I by the way
think is still supported on IBM I. Luckily IBM chose not to build a RPG OA
based on CONSOLE even though it would be more relevant today because the
CONSOLE UI was much more up to date and user event driven than the 5250
screen dialog and a EXFMT instruction are ;-)



What I don’t like about RPG OA is that it binds the programmer to a couple
of proprietary vendors of handlers and thereby whatever these vendor tools
in their “black box” can do.



At the same time RPG OA binds the programmers mentally to a programming
technique nobody can say are main stream simply because it isn’t found in
any other system or programming language.



In other words, RPG OA puts a proprietary top layer of the program instead
of introduce a flexible low level service layer that may consist of a mix
of different vendor services/Open Source projects that can exist side by
side – some may call them classes/methods other service programs/sub
procedures – but they can coexist and be made to collaborate and that is
the important difference.



To give an example we had a discussion about XMLSERVICE and JSON some days
ago, I made a solution available within 24 hours by mixing XMLSERVICE sub
procedures with my own actually just for the fun of it.



Did anybody need to wait for release VX.RY.MZ - build this or that, that
may or may not support JSON in XMLSERVICE – nope - did it had to go into a
feature request or did it had to be justified in a budget meeting in a
proprietary company – nope – the solution just came from the soul, the
heart and the whole idea of sharing in Open Source – it was fun to download
XMLSERVICE, it was fun to make it work and it was fun to “crack the code”
and it was fun to make my JSON sub procedures to work with XMLSERVICE while
learning a lot of new tricks by understanding the code in XMLSERVICE.



Okay, XMLSERVICE is also a very top layered tool, but since it is Open
Source I was able to make simple exit points and “take over” – unlike any
proprietary tool that isn’t distributed with basic source.



The funny thing is that IBM owns and licenses CGIDEV2, XMLSERVICE and RPG
OA in very different ways have you thought about that ?

On Thu, Feb 2, 2012 at 3:27 PM, Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:

Bernd - Guten Tag!

Your response is very interesting to me. I'll have to think about it
some. I hope I understand what you've said.

My first thought is, there is still room and opportunity for the smaller
ISVs. I looked at your site - am I right? You have an ERP for industrial
laundry control? I didn't quite understand your concern about the
software needed to modernize, put against the relatively low cost of the
ERP license.

Last year, as part of my task of writing an article on OA, I spoke with
all 3 GUI vendors. I know a little and have guessed about some things.
They were all in the modernization business already, so they should have
been competition for you, if you offer modernization services, as I
believe you do.

So far as I can tell, ASNA is using OA with their long-standing process.
So is lookSoftware. I think Profound has taken a different direction -
still similar to their heritage but different now. We have used their
earlier product (RPG Smart Pages, I think) for a small piece of our
WebDocs product, and that tool generated the RPG code from a combination
of an SEU-like development tool and a graphical HTML design tool. The
generated code wasn't especially open to modification, in my opinion -
sorry, Alex - but it did it's job well. With OA they leave your RPG
alone but use a modified DSPF, and all this - I assume - goes through
their "handler" to go to the browser.

So I hope you will say more - you have an obvious concert - but maybe
there is opportunity for you, too. I don't suggest that you try to write
another tool to process the 5250 data stream - you didn't do that
before, correct? Even though tools like Webfacing and HATS and Seagull
and others have existed, too?

Regards
Vern

On 2/2/2012 12:38 AM, Bernd Dworrak wrote:
Joe and Jon,

if I would follow your argumentation, then a lot of small ISVs, that
have done a good work in the past could close their business.
Our customer's desire for graphical user interfaces was the reason why
RPG programmers have to worry about OA.
That is why I've asked our local IBM representatives for a tool, that
saves the tens of thousands hours of work that have been invested to write
logic that fits our customer's needs.
But how can one convince a customer to invest in software, that is
needed to modernize existing programs and pay tens of thousands of bucks
for it, if he only pays a fraction of it on the license fees for his ERP.
To rewrite all these things, that have been developed in the past goes
beyond the cost.
It is not a question of having the will to invest in training on new
methods, but a question of time and money.
But there is another reason why the use of these tools from Profound,
Look etc. are problematic: most things work quite fine when you have
rebuilt your apps, but you also know, that developing these apps is the
major task for ISVs.
There is too little support for the concerns of ISVs.
So remember: if I would follow your argumentation, then a lot of small
ISVs, that have done a good work in the past could close their business.

Bernd Dworrak, Dipl.-Phys.



-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
Im Auftrag von Jon Paris
Gesendet: Mittwoch, 1. Februar 2012 23:47
An: rpg400-l@xxxxxxxxxxxx
Betreff: Re: Open Access to be generally available as part of the RPG
compiler


On Feb 1, 2012, at 4:57 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

Now that OA is free, I think it's got the potential to really be a
great tool for a number of things. Some will still see it as a way to
modernize existing 5250 programs and I don't think that's a good use
of the tool except in the hands of dedicated modernization vendors.
But it certainly has the potential to allow enterprising developers to
provide access (there's that word!) to technologies that RPG
programmers might not otherwise be willing to invest in.

This is getting scary Joe - I couldn't agree with you more.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com




--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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.