×
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.
Thanks for your perspective, Jon. When Ian Jarman introduced Open I/O, did you get the impression that it was only an RPG language feature, or that IBM would be opening up its I/O architecture?
While an RPG program may have no idea beyond the display file I/O buffer, the system-level routines that are subsequently evoked by display file writes and reads, do. If Open I/O is more of an architecture than a language feature, then extended display file meta data could be included in the Open I/O interface - just a speculative thought.
In an earlier comment I inquired about whether the use of Open I/O might source code changes, and some speculated that it would - that it's intended for new types of applications, rather than a next generation of screen scraping - which may be fine. Personally, I prefer the idea of implementing Open I/O through additional keywords on the "F" spec, rather than something like an external trigger, because that would give the programmer more flexibility in using it for specific purposes, rather than globally - like triggers.
I like to think that Open I/O is more of an architecture, and that IBM will be opening it's remarkably streamlined interface for more purposes than the traditional ones.
-Nathan.
----- Original Message ----
From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Wed, October 21, 2009 9:17:17 AM
Subject: Re: IBM i "Open I/O" Architecture
Nathan,
Everyone who knows any of the real details behind the Open I/O
proposal is under non-disclosure. We'll have to be patient a while
longer before IBM do any real open-kimono on it.
That said, no harm in saying the kind of things you personally would
like to see!
When it comes to display files etc. you have to realize that the
buffer built by RPG has no knowledge of field positions on the screen,
attribute bytes (unless you put them in the stream) or anything except
the raw data and the indicators. So any "driver" that needed knowledge
of that would have to directly interrogate the DDS/Display file once
it gained control and use that information - it simply isn't present
in what RPG sends out.
Me - I'm excited by the prospects, if for no other reason that it is a
recognition by IBM that RPG needs to move forward to survive/thrive
and they can't do it all. Hopefully we'll see some open-source
initiatives in addition to vendor activity. As Ian said in his
presentation, the ISVs, Large User Group folks and other people who
have been disclosed have been enthusiastic about it - my one fear is
that IBM will over-engineer it.
Jon Paris
www.Partner400.com
www.SystemiDeveloper.com
As an Amazon Associate we earn from qualifying purchases.
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.