Nice summary Nathan.

I think you have hit it square on.

What many people miss is that if the vast majority of RPGers were going to write and use subprocedures for everything outside of basic RPG I/O they would have done it by now. Lets face it, subprocedures have been around for 10+ years and are still not extensively used in more than perhaps 30% of shops. The reasons why are many and varied but certainly include the fact that a large number of programmers have continued in the belief that if the web etc really mattered to them then IBM would have given them op-codes. Open I/O is the closest to that option that we are going to see - if it can't move those folks then there really is no hope. But even for those of us who do use subprocedures, Open I/O still offers some very interesting possibilities.

Jon Paris

On 22-Oct-09, at 10:36 AM, midrange-l-request@xxxxxxxxxxxx wrote:

Well, it's true that one can do just about anything with procedures that IBM has traditionally done with open, read, write, etc. But IBM's interface is more familiar, streamlined, and consistent.

It appears to me that Open I/O could signal a new level of cooperation between IBM and 3rd party vendors to extend RPG's reach to new devices and databases. If a file name, record name, and device type were passed to an Open I/O handler, along with an I/O buffer, then it would be possible for 3rd parties to write generic Open I/O handlers to implement various data management and device management operations while maintaining a familiar, streamlined, and consistent programming interface.

This topic has triggered a number of ideas about extending RPG's reach to other database platforms, and UI devices.

This thread ...


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

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