System iNetwork

snip: IBM Rational product enhancements to RPG-enable programs simply to work with a broad range of client applications, including web services, mobile devices and XML.

Translated: We will have our Java programmers, that don't write RPG code except to test the RPG tools they write in Java, develop a new Java front end to your RPG. We will have our Websphere Application Server front ending your RPG which will run at reasonable speeds once you upgrade to V7.1.

Ok, so maybe today I am slightly jaded by IBM's way of how they think they are modernizing RPG when in fact they are simply putting Java facades over them - that's not give RPG any lifeblood, it just has the potential to lessen the steady blood loss of the language on the platform.

IBM, we don't want more Java programmer tooling for RPG shops! We want tools that work natively on the IBM i that doesn't require us to pony up on the Java half-life of information.

Aaron Bartell
http://mowyourlawn.com

Aaron,

Wouldn't that be PHP ? :-)

Regards,
Richard Schoen
RJS Software Systems Inc.

I think the language about future enhancements to make RPG able to "work with a broad range of client applications, including web services, mobile devices and XML" is referring to making it easier to code RPG to USE web services and write to mobile devices, etc. I'm not sure if Java will be involved or APIs written in compiled C. I think this is the "Open IO" set of features and should not be confused with some form of "web enablement".
The good news is the statement of commitment to the platform.

We'll learn more as more details are released.

Aaron,

It kind of surprised me to read your jaded interpretation of Ross Mauri's comment about planned RPG enhancements for next spring.

My interpretation was that he was referring vaguely to IBM's "Open I/O" architecture which was sketched out by Ian Jarman at the recent RPG & DB2 Conference. Wouldn't you agree? My understanding is that you attended the conference, and that Barbara Morris also mentioned IBM's work on "Open I/O", while there.

I'm not privy to IBM's specification for Open I/O, but it appears to signal a new level of cooperation between IBM and 3rd parties which may desire to write specific and generic I/O handlers for IBM's device file interface?

It appears to me that with the right kind of Open I/O handlers RPG programmers could potentially communicate with browsers and other types of contemporary devices, using essentially the same interface that they've traditionally used to communicate with 5250 workstations, ICF devices, disk files, and printers.

That's to say that RPG programmers might pair /F specs with traditional I/O op-codes to communicate with contemporary devices and clients.

Does that mean that IBM will be writing I/O drivers for all types of clients & servers that RPG programmers might desire to communicate with? I'm not getting that impression. Depending on the degree to which IBM opens the device file interface, and the degree of interest of 3rd parties to take advantage of that, we could see quite a few new device drivers for various contemporary devices from various sources.

The thought occurred to me that you might be interested in writing a native generic device driver to support XML clients and servers, for example.

-Nathan.

The more commitment to the platform the more are the chances it will disappear, anyone remembers the Burroughs machines running the banking industry in the 70th… text screen even though converted to web pages are obsolete, new programming and display technologies will replace the existing one… like the car replacing the horse and carriage new nonpetroleum cars will replace the existing one… that’s life…

Nathan, I have been using CGIDEV2, aka easy400, for over 5 years now and I have always been able to do anything I wanted with it when building web applications. For example, many of the functions now found in the IBM V6R1 Navigator for the web I made myself but my cgidev2 base solution performs much, much faster than IBM's !
Although IBM is still very reluctant towards their CGIDEV2 offering it is in my mind, together with php, the way to go. And no, I am not anti JAVA ! I have used open source in JAVA a couple of times and it worked great. But I do not think you should use JAVA to solve ALL problems, especially not when performance is critical as in interactive web applications.

Antoon, php is the way to go for interactive applications, imho. With Php, you can embed cascaded style sheets and on-the-fly generated java script and not to forget the inherent html event handling which all together give the user the best browser experience he/she can get.
For printing apps, same php application, only instead of the browser you use a html print processing program to print out the most sophisticated documents.
What about good old batch? Easy, the way to go are stored sql procedures, written in RPG but in a later stage converted to procedural SQL language like SPL (ibm flavor), PL/SQL (oracle) or T-SQL (ms).
There you have a possible architecture for the future imho.

I agree with Nathan and others such as Antoon. I was thinking Aaron possibly was referring to EGL (which if he was he describes well), but I did not interpret "RPG enable" as that at all.

All in all I appreciate the statement of direction from Ross Mauri and the the more technical previews from for example Barbara Morris as mentioned here.

rd

I acknowledge that CGIDEV2 is a powerful & efficient tool. And I support native IBM i tools and interfaces over ones that move workloads to other platforms.

But it appears to me that Open I/O may have more potential for broader appeal, as a more familiar, streamlined, and consistent interface for a potentially broad range of contemporary devices, in addition to traditional 5250 workstations, IBM i database and printer files, and inter-system communications.

Coding an /F spec is more streamlined, familiar, and consistent than calling procedures that load HTML templates into memory. Reading record formats is more streamlined, familiar, and consistent than calling procedures to individually get form fields or query string parameters and store them in program variables. Writing record formats is more streamlined, familiar, and consistent then individually updating HTML template tags.

Open I/O interfaces may appeal to RPG programmers who for one reason or another have not begun using procedures.

Then there's the appeal of it coming out of Toronto and integrated into the RPG compiler, and supported by folks like Barbara Morris.

-Nathan.

I may catch some flak for this next suggestion but it's also intriguing to consider:

/free
read myDbRecord;
write myHTMLPage;
/end-free

Such that the RPG compiler automatically maps fields from the database record buffer to the browser record buffer when the "read" is evoked.

And where the Open I/O handler linked to the browser device automatically formats numeric fields according to edit codes defined for the browser record, when the "write" is evoked.

I'm not aware of any other language, framework, or platform having such a streamlined interface. And one that might be so consistent for any number of contemporary client devices.

That type of consistency and efficiency has been a halmark of RPG productivity. It makes other languages, frameworks, and platforms appear backward in comparison.

But some have already expressed fear that such a streamlined interface might lead to more programs that don't separate UI logic from DB & business logic. Oh, well.

-Nathan

Nathan, I think that's what OPENIO should be all about. I posted something similar in the forums.

In your example, the HTML is just as externalized as DDS (and would require a similar externally defined framework).

It should be interface independent however, so that the input / output fields can be mapped to any interface, with the interface determined by OS when the session starts.

That's what I think of in OPENIO. I have no idea what they're actually going to do though.

rd

Regarding ugeerts advice: "the way to go are stored sql procedures, written in RPG but in a later stage converted to procedural SQL language like SPL (ibm flavor), PL/SQL (oracle) or T-SQL (ms). There you have a possible architecture for the future."

I have been thinking along similar lines recently, that we should begin writing our RPG code that we want to expose as external stored procedures in such a way as to be easily converted into pure SQL procedures for portability purposes. But today I think IBM SPL is weaker and less versatile than Oracle PL/SQL, and I prefer SQLRPGLE to SQL SPL. If you think about it, RPG with embedded SQL is much like an SQL procedure except that it is more powerful, more versatile and, to my mind, capable of being more elegant.

It's just not cross-platform, not even on the IBM Power Systems (thanks to IBM); perhaps it should be.

What SQL is cross-platform? IBM ported a DB2 engine for the MySQL database so PHP SQL for MySQL would work unchanged. Look at any software with SQL and it will specify specific databases that it will work against, rarely DB2 mentioned, much less DB2/400. No cross-platform in there, despite the unending hype.

I was at a major iseries vendor in 1994 as they tried to port their product as "cross-platform" to major databases on Unix. Funny stuff. I never cease to be amused at the SQL hype, nor cease to be dismayed as vendors water down software to lowest common denominator to try to have the largest potential market for less and less potent software.

It's the customers who lose on this, and I think a big reason for drop in sales of software.

I think that's why SAP, Peoplesoft, and JDE continue to lead as they have COBOL or RPG infrastructure. Obviously SQL is used for the point and click BI crowd, but I'm talking about the software that creates the data to point and click at.

rd

I was approached by a community person about my comments earlier in this post because they thought I was bashing the recently announced "RPG Open I/O". After re-reading the original blog entry I can totally understand where they are coming from.

I am part of the team that IBM is working with to determine how "RPG Open I/O" should be constructed (well, I get to give opinions - obviously IBM will take them for what their worth :-), and I am very interested at seeing that effort succeed because it lays the groundwork for additional enhancements and also tells the RPG community that IBM is still in fact putting money into the language.

My comments were directed at IBM's past efforts at making RPG web service capable (i.e. IWS, Java+PCML, Axis C client, EGL front end, etc). Ross Mauri never mentioned RPG Open I/O by name in that announcement, but I can see now how that could be what he meant, or, it could be enhancements to IWS being that RPG Open I/O is more of a interface than a deliverable product. That's probably all I can say on the subject, but again, I am VERY much wanting to see this "RPG Open I/O" effort push through and succeed.

Aaron Bartell
http://mowyourlawn.com

It is true that SQL is not as cross platform as Java, Ralph, and I assume everybody knows that, so I didn't bother to point it out. But it is "substantially" cross platform, the more so as you stay closer to ANSI standards and away from vendor-specific innovations. Some products, like Cognos, include ANSI and vendor-specific capabilities for customers to choose from.

SQL is a crucial technology and it is widely used. Oracle now owns PeopleSoft and JDE, so we may expect a transition into SQL where it is not yet used. IBM suggests using SQL more and native IO less, and we know they are investing a lot more in SQL than native IO.

Where I work we have done benchmarks comparing SQL solutions to native IO solutions in order to select the better option. So far, in every option SQL outperformed native IO.

But a point I was trying to make is that if IBM wants to assure us that they value RPG, they should make it available for all operating systems running on the Power Systems. In support of that point I suggested that SQLRPGLE is often a better solution than a pure SQL procedure. I value RPG not for its native IO capabilities, but for all its other strengths.

Bold new move for DB2 for Linux/Unix/Windows: When I mentioned that I felt DB2 SQL PL was weaker than Oracle PL/SQL, I was thinking specifically of the ability to do array processing, which as far as I can tell is not yet available for DB2 for the i as of v6.1, but I have learned is now available for DB2 for Linux/Unix/Windows.
Earlier this year IBM released DB2 9.7 for LUW which includes the bold enhancement of Oracle compatibility. This version of BD2 now runs Oracle syntax and has Oracle capabilities as well as traditional ANSI-based DB2 features. This is an extraordinary move and I think a very wise one.
So this is apparently the situation on the Power Systems: There are three operating systems, Linux, Unix and IBM i; RPG is limited to the IBM i and the bold enhancements to DB2 SQL PL are limited to Unix and Linux. It's almost as if the reasoning is: the IBM i doesn't need the SQL PL enhancements because it has RPG, and Linux and Unix do not need RPG because they have an enhanced SQL PL.

This is good stuff, but I think there's room for another perspective. To me it seems the future of programming, like platforms for that matter, is about 'horses for courses'. Possibly a British expression, but you can guess what I mean. I'm not altogether convinced now that a single RPG (or COBOL or even Java) program should do what it does as an application and at the same time interact with a Web page. Nor am I convinced that all database I/O should be native OR SQL. In differing circumstances we need both.

If a new RPG compiler feature allowed a Web page to be a special file, or something similar, we might be pushed backwards into the Web 1.0 paradigm rather than the more sensitive, glued-together, and potentially multi-contibutor Web 2.0 paradigm. Why? Because we need a content-contibutory approach rather than dynamic page posting in a modern rich application.

My spin is that rather than generalize the IBM i platform it should specialize to become an instrument in the serving orchestra rather than attempt to be the illusive (and rather unsatisfactory) 'one man band'. It could be that brilliantly for 5250, but for the Web? No, unfortunately we need the virtuosity of the different orchestra players.

Specifically? I think a mixture of languages and I/O techniques in purposeful functional modules tuned to the task in hand is both feasible and desireable. The brute force for convergence of software into virtually a one-size-fits-all approach is daft. And just as daft to try to make RPG (or IBM i) fit everything as it is to bang the Java/SQL drum constantly.

Give me creative diversity any day.

Cheers Anthony

That was excellent reading and an excellent thought. Point taken, considered, and approved.

- Mike Moegling

Anthony, nobody says PHP shouldn't be a one man band. Nobody says Java shouldn't be a one man band. Nobody says C# shouldn't be a one man band. But we shouldn't be able to put out web pages like they do because then we'd be a one man band?

Yes, there are a multiplicity of underlying technologies for them all to use in a web page, but RPG with CGIDEV2 interface and with new OPENIO interface is comparable to the languages mentioned, not the underlying infrastructure technologies.

rd

I sometimes have a hard time following metaphors about orchestras, and relating them to computer platforms, languages, and frameworks.

Except perhaps that the more information-technologies you mix together, the more conductors you need, the more work you do, the more expensive it gets, the less harmony you end up with, the more prepackaged music you buy, and the more Indian/Asian orchestra chambers you outsource to.

In contrast to the one man band metaphor, it appears to me that Open I/O may be more like a multi-purpose music synthesizer. The base instrument may still be a familiar keyboard designed for an individual musician, but it now sends out a variety of signals and produces a variety of sounds.

uGeerts, I do agree that php is great and I have used it on windows. I can assure you I look forward to learn more of it and use it on the i. But it is simply not true you can do things with php that you cannot do in CGI using easy400 ! I guess you have not used it a lot, go see :
http://www.easy400.net/

regards,
Antoon

In response to both Ralph's and Nathan's points, I'd say I agree in principle that it would be great to have all I want, as good as it can be, all in one platform and programming language. And yes, PHP, Java, C# all lay out their stall as being those kind of languages, and the IBM i (with its legacy going back to System 38) ought to be the general purpose platform you could do everything on.

Let's look at the platform first. The IBM i's future is as an operating system - not a hardware platform. For instance, my primary hosting center is based on a BladeCenter populated with Power and Intel blades, virtualized into i5/OS, Linux and Windows. The storage for all of this is a large IBM SAN and now even the tape devices are virtual. Where is the IBM i hardware platform in all this?

The strength of IBM i (namely as an O/S) is now - or soon will be I imagine - all that's left of it. I can mourn that or go with the flow, but I can't see I have a choice. But what a strength! If we can preserve this O/S on Power hardware we should do so at whatever cost.

On the language front again I think each has its merits. Portable Java isn't able to do pointer-based I/O (like CHAIN) but is great when driving SQL into retrieving a set of results. If you need to get just one row frequently from a 20 million row table and have a full key you need something like CHAIN unless performance is less important than application portability. And why would a forum like this be passing up the unique benefits of a server solution in favor of portability onto other platforms?

Look, the orchestra metaphor only goes so far. But in fairness so does the synthesizer one. My world-class trumpet player friend does not feel threatened by the trumpet voice on a Motif XS. He's better. Better because he's specialized and focussed, and that's what I was meaning above.

A rich application (Web 2.0 for instance) will attempt to glue together pages dynamically, so might use AJAX to refresh portions of a display. Fine, the IBM i can do all that really well (one-man band working so far, then). But I need to glue information from a scanned document database onto the page (not a strength of the IBM i IFS, so maybe Linux or Windows is better for this?). CRM, email, links to online payment providers etc. - these are best of breed on other platforms, so why must they run on the IBM i when they can interoperate?

The original debate springs from the universal I/O idea, and the possibility that RPG could get to interact with an HTML page natively. I like that, but doubt I will use it much as I really want Web 2.0. So I'm starting to use RPG really excellently to provide page content through AJAX. Right now the IBM i is doing all the other stuff too, but I'm saying that if another way was stronger I'd go for it - and leave RPG doing what it does best.

I get a funny feeling I'm defending IBM's abandonment of the i hardware platform, and justifying a trend a way from general purpose computers (originally the division of IBM that System 38 came out of) and towards virtualized appliance servers.

Yes - that's exactly what I'm doing.

Today there are no innovations on IBM i.

On the past there were some specific attractive features (OS/400,RPG/400, CGIDEV...).

Today most other systems (Linux, Unix, Windows) languages (C#, Java, PHP...) and databases (MySQL, Oracle, SQL Server) are close and still going further.

IMHO IBM i missed the boat.