Re: IBM i "Open I/O" Architecture

LOL Nathan

I meant that my observations are not official. Open IO is coming, as you said.

I don't think IBM are providing anything specific to HTML - that'd be up to you or a vendor, who would likely use existing techniques, but they'd be hidden behind this feature. Someone in your shop would have to know how to use, say, CGIDEV2 or the CGI APIs, in order to work with web pages. But the rest of your developers would not have to worry about those details - they'd just have to have a file to declare on an F-spec that'd define the various parts of a page that can be defined with a fixed-format record. The CGI function for pulling URL variables into a PF now seem like a similar concept. I don't know to what level that formats would need to be defined - tags? Will there be a format for anchors, another for table rows, another for divs, etc.?

I haven't thought much about the DSPF thing, but I think that whatever is handled in I/O buffers now would be a part of this. With web pages, the input comes from forms, right? Or hand-entered URL's? Your EXFMT would send the page out through the handler, and then get form data back. Maybe you'd have more output-only and input-only segregation in your record formats. CGIDEV2 with its place-markers suggests a paradigm for this.

It seems that not all opcodes are needed for every implementation. An idea just rose in my brain - wouldn't it be nice to be able to retrieve messages from the joblog using the OPEN/READ/READP/CLOSE opcodes? Or be able to use the very fast user index and user queue low-level techniques without having to know all the gory details of DEQ/ENQ?

I think this has potential to allow lots of things formerly difficult to do. We shall see. Guess I like the idea!!!

Vern

Nathan Andelin wrote:

Vern,

You make some interesting observations. If a programmer must add a keyword to an "F" spec, or make any other change to existing programs in order to use Open I/O, then that might preclude it from being used as an alternative to screen scraping, as not everyone has source code. If however Open I/O handlers are defined similarly to external triggers or exit point procedures, that opens up other possibilities - no source code changes needed.

What I/O elements would be exposed to Open I/O handlers? In the case of display files, you have constants, output, input, both I/O, and indicator settings. Would row & column attributes be passed to Open I/O handlers?

Would IBM supply new procedures to generate formatted HTML, and supply a new interface with the HTTP server? Or would folks continue to use something like CGIDEV2 to generate HTML and handle HTTP server I/O?

Open I/O is not official yet? In addition to Ian Jarman's presentation, Ross Mauri mentioned it today in his IBM i 7.1 announcement.

I'm not inclined to give heed to people who say RPG shouldn't be used for anything new.

-Nathan



----- Original Message ----
From: Vern Hamberg <vhamberg@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Tue, October 20, 2009 7:24:17 PM
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.