Up to Discussions in RPG Café

This Question is Possibly Answered

1 "correct" answer available (4 pts) 2 "helpful" answers available (2 pts)
5 Replies Last post: Oct 31, 2009 10:33 AM by my_name_was_taken  
Click to view B.Hauser's profile  
B.Hauser
16 posts since
Nov 22, 2008

Oct 22, 2009 12:31 PM

IBM i - Open I/O (for RPG)


Can we get more information about this topic, that Ian Jarman announced at the RPG and DB2 Summit?

Or where can we get more information?

Birgitta


Click to view PSA_Brad's profile  
PSA_Brad
2 posts since
Jul 23, 2009
1. Oct 22, 2009 2:02 PM Up Image in response to: B.Hauser
Re: IBM i - Open I/O (for RPG)
Even the information that Ian Jarman shared would be interesting for many of us to know.
Click to view tuohyp's profile  
tuohyp
1 posts since
Oct 23, 2009
2. Oct 23, 2009 6:58 AM Up Image in response to: PSA_Brad
Re: IBM i - Open I/O (for RPG)

Scott Klement had a video blog on the conference and caught some of Ians keynote - you will find it at http://systeminetwork.com/article/report-rpg-db2-summit

HTH

Paul Tuohy

Click to view B.Hauser's profile  
B.Hauser
16 posts since
Nov 22, 2008
3. Oct 26, 2009 1:22 AM Up Image in response to: tuohyp
Re: IBM i - Open I/O (for RPG)

Thanks Paul, I knew Scott's video blog and I also followed up the discussion in several forums (for example midrange-L), but I hoped there were already more detailed information available.

Birgitta


Click to view my_name_was_taken's profile  
my_name_was_taken
12 posts since
Sep 17, 2008
4. Oct 30, 2009 11:18 PM Up Image in response to: B.Hauser
Re: IBM i - Open I/O (for RPG)
Birgitta,

I'm not privy to the Open I/O specification, but I've always been impressed with how familiar, streamlined, and consistent that RPG's interface has been with traditional WORKSTN, DISK, and PRINTER device types. Depending on the degree to which IBM were to open that interface, we could see regular folks writing specific or generic "drivers" for contemporary and new types of devices, and RPG being used for more types of applications.

The SPECIAL device interface never seemed to gain much traction because it was geared more toward writing specific I/O handlers for just one file and one record format, and was constrained by entry point parameters. The name of the I/O handler was hard coded, using the PGMNAME keyword.

I'd like to see a more robust and extensible interface so that generic I/O handlers could be written for user defined device types. Say that we were able to register a new device type named BROWSER (or any other name) and associate a generic handler with it, such that the RPG compiler knew to call that handler for files referenced by "F" specs and all the regular I/O op-codes.

It would be nice if IBM were to provide a CL command to work with and maintain new device types which RPG programmers could reference on "F" specs. Perhaps the PGMNAME keyword could override the generic (default) I/O handler. Perhaps the the EXTFILE and EXTMBR keywords could override the file named on the "F" spec.

I think an Open I/O interface would need to include the file name, member name, and record name, in addition to the traditional parameters passed via the SPECIAL device interface.

I believe the interface would be more flexible and extensible over time if data structure exports were shared between the RPG program and the I/O handler rather than just program call parameters, since new exports could be added over time as more requirements come to light, without disrupting existing I/O handlers. Adding new data structure exports to bound service programs don't have to change the signature of the service program, for example.

I'd like the interface to include the indicator data structure (INDDS), so that I/O handlers could get and set indicators - pressing the F12 key on a browser could set the appropriate indicator before returning from a READ op-code, for example.

I'd like I/O handlers to be able to update a shared error data structure, and for the %error() BIF to return *on when an I/O handler expresses an error.

The file on the "F" spec would need to be multi-format capable, comparable to display and ICF files, in the case of browser and other UI device types.

I've addressed some of the needs of contemporary UI devices, but it appears to me that an Open I/O interface may have even more potential for enabling RPG programmers to interface with remote databases and other types of data.

I'm hopeful,

Nathan M. Andelin
Click to view my_name_was_taken's profile  
my_name_was_taken
12 posts since
Sep 17, 2008
5. Oct 31, 2009 10:33 AM Up Image in response to: B.Hauser
Re: IBM i - Open I/O (for RPG)
I'm personally not aware of any language, compiler, framework, or platform that offers a more familiar, streamlined, or consistent interface for device I/O than that offered in RPG for traditional device types. I'm hopeful that a comparable interface can be extended to regular folks who may be interested in writing generic "drivers" for contemporary and new device types.

One reason the traditional device file interface is so streamlined in RPG is because the "F" spec embeds references to externally defined "file" objects, which contain a wealth of meta data associated with the objects, which can be pulled in by IBM's traditional 5250 and data management I/O handlers. You can pack a lot of power into a streamlined interface that way.

Under Open I/O, what sort of meta data might be associated with a contemporary device? A generic I/O handler would need the meta data from the externally defined "file" object (file, record, and field-level keywords and definitions), plus additional.

What if we were writing a generic I/O handler for hierarchically structured XML files? We'd need a traditional multi-format *file object, but the I/O handler may also need a reference to the stream file, say /finance/xml/sales.xml which is linked to the traditional *file object. Whoever is responsible for writing the I/O handler may come up with a way of storing additional meta data like that, and linking it to a traditional *file object.

In RPG, an "F" spec could reference a multi-format file name and XML device type, for example, so that reading the file might go something like:

read customer;

dow not %eof(customer);
exsr customer; // process customer record
read order;
dow not %eof(order);
exsr order_header; // process order header
read item;
dow not %eof(item);
exsr order_item; // process order item
read item;
enddo;
read order;
enddo;
read customer;
enddo;

Again, I'm not privy to IBM's Open I/O specification, but these are some of the capabilities I'd like to see.

-Nathan M. Andelin

Actions

More Like This

Bottom Banner