RE: IBM i "Open I/O" Architecture

From:
Mike Cunningham <mike.cunningham@xxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/20/2009 10:22 PM
Subject:
RE: IBM i "Open I/O" Architecture
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



Could this same architecture also be used as a native way to read remote
databases that are not currently accessible from a DDM file? Like do a
READ to a mySQL database running on a Linux server? That would be nice if
it could. Define the tables in the remote mySQL database to DB2 so the
compiler knew the layout then at run time the Open I/O routine would
actually do a READ of the mySQL table .

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Tuesday, October 20, 2009 9:24 PM
To: Midrange Systems Technical Discussion
Subject: Re: IBM i "Open I/O" Architecture

Nathan

This enhancement is intended to give RPG developers the ability to use
exactly the same opcodes they always have. As has been said, there will
likely be a keyword on the F-spec that indicates what will handle the
IO. It will still be record-based. It'll need to work with input and
output buffers. You still need to have an existing PF or LF or DSPF or
PRTF for the compiler to get record and field information from. It will
most likely use service programs - procedures will need to be written to
support the various IO opcodes, as Scott listed them. There will be some
mechanism to provide the handler with the information it needs to do its
job.

I hear mixed reviews - those who know how to write subprocedures using
various APIs might not see a need. I'm not in that camp - although it
COULD all be done with subprocedures, etc. I mean, you can always call
the CGI APIs to write out to a web page. You can always work with data
queue APIS or user space APIs. But this would make those operations
"native". Others think RPG is dead and no one should develop anything
new in it. They think this will be a flop.

I'm not sure now many regular shops will write their own - there is
opportunity however for open source and for vendors to provide the
handlers.

It does show that IBM is interested in the future of RPG, in my opinion.
It will be interesting

BTW, this is not anything official, so things could change.

Vern

Nathan Andelin wrote:

Thanks for that update, Scott - particularly the point about IBM

maintaining backward compatibility - existing programs won't break. From
your video I gather that Ian indicated that it's a pretty big deal for IBM
to "open" it's I/O architecture.

I wondered about possible similarities with SPECIAL file handlers, but

if I/O handlers are defined external to programs, it sounds more like
"triggers" or "exit points". Some time ago I was interested in using a
SPECIAL file for a utility I had in mind, but was discouraged that the
"file" or "record" name (I don't remember which) was not passed as a
parameter. Open I/O sounds a lot more promising.

Regarding the 5250 data stream, it has always been difficult to capture

& parse. It sounds like Open I/O may be a lot easier and more flexible.

-Nathan.




----- Original Message ----
From: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Tue, October 20, 2009 5:48:36 PM
Subject: Re: IBM i "Open I/O" Architecture

Nathan,

To the best of my knowledge, Mr. Jarman did not give out copies of his
slides to anyone at the conference.

I would've had better coverage myself, except that he kept droning on
about things that were irrelevant to my life and I was running out of
tape in my camcorder... I didn't know the point at which he was going
to suddenly jump into Open I/O... if I had known, I would've done a much

better job capturing it.

Ian actually didn't spend much time on it (to my frustration), so I
don't know how useful his slides would be to you, anyway.

Like all RPG enhancements, you can count on the fact that it won't break

any backward compatibility. Your existing files will continue to work
the way they always have.

The enhancement basically lets you write "handlers" that are routines
that get run when a setll/chainread/write/update/delete is done to a
file. It's very similar to the existing SPECIAL file support, except
that it will externally defined files, and can use ILE concepts (i.e.
call procedures in a service program) in addition to calling a program.

The expectation is that people will use this support to write code that
interfaces RPG with modern devices like browsers, iPhones (and other
phones), etc, and that it'll be usable as an ordinary file object from
RPG, so no special knowledge is needed to call it.

Personally, I visualize it much like the Windows support for printer
drivers. If you make a printer and want it to be used from Windows, you

write software (a driver) that contains the code to interface between
Windows GDI and the language the printer uses. Therefore, all programs
can write to GDI, and take advantage of your printer.

RPG Open I/O gives that capability to RPG programs. It provides support

wherein you you can write a "driver" (if you follow me) that will be
invoked when using record i/o operations. So an RPG programmer can take

advantage of your particular device (or I/O method of some sort) just by

interacting with it as a regular file.

Hope that makes sense.

--
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.

--
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.


--
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.