System iNetwork

Last week, in "A Quick Tour of the New RPG Features in IBM i 7.1," Scott Klement gave his take on Open Access (scroll to the bottom third of the article, the section titled "Rational Open Access: RPG Edition"), and many readers have also chimed in with their opinions about Open Access. You can see their comments, as well as Scott's replies, at the bottom of Scott's article.

Chris,

Your cons are simple repetition of the BCD and LANSA positions. Some of them are not cons.

Existing RPGIV application code is not necessarily what this is about. The pro is, that you can use your existing RPG skills to write to new UIs beyond the 5250.
And, looksoftware and Profound Logic have a solution that can merge with an RPG OA solution for apps where you have no code, or don't want to change your existing code, or want to use an OS command, menu or help screen.
And, if you do want to use RPG OA, and your handler can understand 5250, there is only one line of code and a compile that is required - not difficult.


Stateless programming is handled properly, if the handler can perform the functions needed for state. This is not a con at all. Besides, if you write new code, and you design with stateless in mind, this is not a con.


The two code bases would be an extraordinary situation. If you write the handler properly, it might be able to deliver either to the 5250 or to the new UI. If you build an appropriate modular architecture, the resulting n-tier solution would not require two versions of any code.


I reviewed the BCD and LANSA points in my blog at: http://blog.angustheitchap.com/?p=199


Trevor

Chris, one other note. There is a misconception being spread about the price of RPG OA. Depending on the tier level, the price is between $500 and $5000. The P05, where many 520 customers sit, will be the $500. Whether or not IBM should have charged for RPG OA (a contentious and ongoing debate), for a business, $500 is easily affordable for the benefits of RPG OA. It would be sad to think that customers were frightened away by the rumor that the cost was $1500. That rumor should be quashed immediately.

Trevor

There is nothing wrong with ROA:RE except 1 thing: Cost Structure.

I didn't say "price", I said "cost structure".

That is the "con", and in my mind its a show-stopper.

Can and will IBM fix the cost structure? Certainly they'll have to at some point.

Here's what will happen:

The 3rd-party trainers out there, most of whom are former IBMers who keep close-ties to IBM and still taught the party-line, will advocate ROA:RE as if "everyone progressive is doing it" when in fact, dozen or perhaps a few hundred shops at most, will implement it.

Then after about a year or 18 months of this, IBM will bundle it with v7r2 or v8r1 whatever the next release is called, and people will have a second look at it.

Don't get me wrong, I like ROA:RE and am very disappointed that IBM Rational has made the barrier to entry a $1500 tax. This is going to be a challenge unless (A) 3rd-pary vendors bury that cost in their product's lifecycle costs, or (B) Somebody figures out a (legal) way around the runtime lock-down.

Unless until that happens, well, I'll just be waiting it out while others are pretending everybody is using it "except you"

Trevor, I agree that some of the "cons" are not exactly cons.

I would even go as far as saying that two separate code bases would never be required. Even if the handler doesn’t do it for you, there are many simple ways to avoid keeping separate source code... from simple conditional compiling to having the programs be smart enough to detect the context they are running in. You can have the same program control 5250 and Rich User Interfaces, if you wish.

And in regards to stateless programming... RPG developers would rather not be coding in a stateless paradigm. RPG is a great top-down language. The handler should take care of managing state for you, not the developer. That’s why the RPG OA approach is much superior to traditional CGI stateless programming. You don’t have to worry about managing the state on your own – RPG does it for you. There is a great post by Jim Rothwell where he explains how top-down RPG and stateless requests work well together with RPG OA: http://systeminetwork.com/article/quick-tour-new-rpg-features-ibm-i-71#comment-416

"Existing RPG IV application code needs to be modified and recompiled"

True as far as it goes - but does a 1 line code change really count as "modified" in this context?

"May require two code bases to maintain for basically the same application"

Personally I would think it would take me 6 lines of additional code and one changed line to have a single program talk to real 5250s or to a handler.

1. 
   Clone the F-spec and add the user open option to both old and new. Add the handler keyword to one of them.


2. Add logic to open correct file

If real5250Used;

open 5250File;

Else;

open handlerFile;

EndIf;

Bob,


You used the word "price" here: http://imho.midrange.com/2010/04/22/rpg-open-access/ when you said "But at $1500 per system (the real price based on the product description on the IBM website)..."


Can you show where you found $1500 for the "cost structure"? That would go a long way to quash the rumor.


Trevor

First hint at pricing I've seen comes from The Four Hundred

"....The Open Access tool is priced based on the traditional OS/400 software tiers...On a P05 system, the feature costs $500; on a P10 system, $1,000; on a P20 system, $2,500; and on P30 through P60 systems, $5,000...."

Hopefully that's per system, and not per partition as stated in the Announcement Letter
"...IBM Rational Open Access: RPG Edition is required on partitions where programs using I/O handlers are being run."

In the cons you wrote "Limited to IBM i 6.1 and 7.1" but according to Profound Logic's Profound UI can be used in 5.3 and 5.4 as well with their pre-compiler.

Yehuda

you guys are lucky....at least you have the option to use it if you want. As a COBOL shop we will have to wait for IBM to be so kind as to release a COBOL edition.

Or start learning RPG, of course.

Here's the Pros for OA:

Buying latest version of IBM ILE development software -
allows customer with source code to their programs to disable any file access (display files and/or physical files and/or printer files) in an RPG program and hardcode the name of a program to call instead of performing the IO command.

Buying a product from a vendor -
allows you to have a program name to hardcode into the RPG code on the line of the file you want to disable to let the product perform alternative actions.

Buying a runtime license from IBM -
allows IBM to allow the disabled file to be passed to a product you paid big bucks for to do whatever you paid them for.

With pros like that, who needs cons?

I reject the concept that an RPG shop can't go through their code and comment out an EXFMT and call a program, vendor product or open source, passing data structure of the file and statuses. It's not that RPG shops can't or don't want to make a program call, they don't have a program to call.

Having said that, I want every one of these vendors and consultants to succeed with their products. How many freakin GUI products do we have to have before people stop saying we don't have a GUI interface? I think we'd put about any other server system in existence to shame with our plethora of GUI products, every imaginable niche, tier, and yes now even run time, it's all covered, from screen scraping to e-server CGI to CGIDEV2 to PHP to Java JSP to Java J2EE implemented in every imaginable possibility from open source to CASE development platforms.

And I hope they all do well, including this latest tweak from IBM. It's got its pros, just like every other possible solution. By the time an iseries shop buys into one of these vendor solutions, the run time license is peanuts, I'm sure. IBM essentially has a runtime license on other solutions such as Websphere, so as always we have to add everything up and see if its a compelling value.

OA adds a pricey tweak to our already innumerable GUI options. I hope it wins over and keeps top tier customers. But I think it will take viral open source iseries solutions to appreciably increase our customer base again.

rd

An even easier option, IMHO, to determine which file to open is the use of switches. It is an old technique that doesn't get much use these days but you can essentially suppress I/O for a file simply by turning a switch on or off prior to the RPG call. This does require a CL wrapper so it may not be appropriate in all situations.

Jack,


The configurator tool is how you order new Power servers. I used it and configured a P05 level Power6 server, with RPG OA. I got this price.


The price for a P05 level is $500, there is no software maintenance cost identified in the configuration, and the most I can add to the cost is $30 if the customer wants the software to be expedited.


There appears to be no hidden costs, no related costs, and since RD Power is not required to use the RPG OA runtime, that is not included.


The price list is:
- P05 = $500
- P10 = $1000
- P20 = $2500
- P30 and higher = $5000


The "price" or "cost structure" of $1500 remains an unsubstantiated rumor.


Trevor

Trevor,

I think the pricing Cozzi is talking about comes from the same place I have been reviewing pricing of RPGOA: http://www-01.ibm.com/cgi-bin/common/ssi/ssialias?infotype=an&subtype=ca&htmlfid=897/ENUS210-114&appname=isource&language=enus#h2-ordinfx

I am not quite sure what to make of that page as its NOT easy to make out what the price is. Add this to the list of things that I predict will cause significant lack of adoption for a cool compiler feature - all because IBM can't market or sell themselves out of a paper bag. I am not trying to be negative, but convey the reality that unless IBM changes to get with the times that they will only ever continue to lose market share in this space.

AaronBartell.com

Aaron,

I followed the links - not so hard at all, and this is what I got: http://angustheitchap.com/RPGOAprices.png


There is not a $1500 in sight.


Here was the flow of URLS..


Take your link, and it says:
Information on charges is available at
http://www.ibm.com/support
Choose the option entitled Purchase/upgrade tools.


I clicked that, and clicked on Purchase/upgrade tools. I got:

https://www-304.ibm.com/ibmlink/ttpu/displayTTPUPage.wss?lc=en&cc=US
(I clicked on Look up IBM standard hardware and software prices (Price) excluding PLM and System z products) I got:


https://www-304.ibm.com/ibmlink/stdprice/STDPrice.wss?lc=en&cc=US
(I typed 5733-OAR in Product number and clicked Search)


https://www-304.ibm.com/ibmlink/stdprice/STDPrice.wss?function=1&type=1&product=5733-oar&part=&refno=&submit=Search&lc=en&cc=US

If you click on that link I provided there ARE prices in the $1500 range. How do we know which prices are correct being you found some on another page besides the ones on the link I provided?

Also, when I clicked on this link it not only required me to log in, but I had to fill out a form and then it said it would *email* me more information. What in the world is going on here!?!?!

https://www-304.ibm.com/ibmlink/stdprice/STDPrice.wss?function=1&type=1&product=5733-oar&part=&refno=&submit=Search&lc=en&cc=US

How did you end up getting that screen shot?

I feel like you are calling a heart a spade. You can't resolve an issue unless you recognize the issue is in fact an issue. I feel like you are placating IBM's process when in fact we should call it out and find who we can talk to and fix the issue. I am not try to solely be a complainer. I am trying to first complain and then do something about it, but you are just keeping us all in the complaining phase by not living in reality that there is in fact a problem - a problem that IBM should be told about and can probably fix (or at least they SHOULD fix).

Looking forward to an Australian beer with you at COMMON :-)

AaronBartell.com

Aaron,

There is definitely a problem with the ordering system. And certainly, the concept of whether or not to charge for RPG OA is a question that should be asked.

However, RPG OA is not about the ordering system, or is it about the price. Somehow, somewhere, the argument about the price seems to be overwhelmingly a reason NOT to adopt RPG OA. My point is, that argument is beyond ridiculous. Based on what RPG OA can do, the price from IBM is an easy justification.

We should be talking about how RPG OA can help us, but there are some people behind a wall of "I ain't paying for nuthin". Funny, really.

Trevor

Trevor got with me offline and conveyed that I was looking at feature codes this whole time! Argh! It was a under a column named "Feature Charge" and had a value of $1565. I with draw my declaration that there is pricing on that page and slap myself for not being able to decipher IBM pages.

Thanks for keeping me in check Trevor. Stay tuned to my blog as I continue my efforts at getting order and pricing info for RPGOA.

AaronBartell.com

I'm still a little confused about pricing. The pricing is broken out by software tier (P05, P10, etc.). No problem with that. It's further broken out by product base, 1 year, and 3 year. Then it's further broken out by initial purchase, and upgrades. Is anyone else confused?

Regarding the justification of the price, someone compared the it to the price of a PC, and I responded in the following blog:

http://ibmsystemsmag.blogs.com/idevelop/2010/04/open-access-stirs-emotions.html

I understand that different users will have different criteria for justifying a cost, so I'd be interested in hearing what makes IBM's price a non-issue? What specifically might justify the cost?

-Nathan.

I don't want to begrudge IBM making money. The i operating system is a quality OS, the best there is I think any iseries person will agree, and IBM keeps adding quality to it with every release.

RPG Open Access could play out as an extremely marginal pricey tweak for a small subset of iseries customers with source code to their 5250 interactive programs but uncomfortable commenting out an EXFMT and replacing it with a call to a third party program. The number must be exceedingly small.

The point of webfacing was that recompiling the interactive programs wasn't an attractive option, for reasons that could vary from not having known to be reliable source code to regulatory reasons of having to retest and validate for production every interactive program the business has.

That the iseries customer has the source code and ability to recompile but doesn't have the ability to comment out EXFMT commands and replace with a call passing the scfreen data structure may be some kind of belief lurking in decision making places, but is not true. Once you have an example of one call, they are all the same.

Further to that fuzziness in decision making places is the typical bias toward Unix and a belief that C/C++ is a real language, epitomized with the IBM statement that RPG Open Access handlers will typically be written in C/C++. That rises as much passion in me as the insulting API charge.

A minimalist appraisal of this product is that IBM is charging a premium for an API that allows web facing to not have to figure out what's on the screen. Once figured out for each screen, anythuing can be done with data ala the handler as having the data passed to you in a data structure.

My minimalist appraisal is that IBM figures that if they add an API to the i operating system (the OS/400 - i5/OS operating system where API's were added as the Supreme Being intended) that supplants need for the webfacing product, then they will replace that revenue with an API charge. That is just embarrassing.

Imagine if IBM tried this with Linux. Oh wait, they can't, Linux is open source. Imagine if Microsoft charged for driver API's, which is what this sort of is but even less than that. Well, they do charge for API development tools but imagine if every Windows customer, or even just the businesses that are deserting IBM in droves to replace the iseries with Windows, had to pay a "run-time" license to Microsoft to use a Windows program that used one of Microsoft's precious API's. You can imagine how that would go over. On the other hand, Microsoft would probably create a server for it and you'd have to buy another Windows server instead. So I'l let that analogy rest there.

But this could play out entirely differently, and I truly hope it does. The thing that has hurt us the most has been lack of a standard GUI interface, and this piggybacks the standard interface exceedingly well. Albeit it is within 5250 data space, and that very few web pages will match up with an intense 5250 screen as our users want, and that in reality the interactive programs will have to be rewritten to match up more with the various web page tabs and AJAX calls that can come in, this is a standard interface that makes third party interfaces transparent. That's an exceedingly good thing.

I will add that the actual 5250 external screen DDS equivalent was done correctly with CGIDEV2, but although CGIDEV2, PHP, and other open source solutions such as Java servers are still the probable technologies that will drive iseries web serving use, it would be great if something like Profound UI and equivalents from others are seen as a standard interface for the iseries even though different third party products are involved, because programming is standard, not to mention the same powerful programming that made the AS/400 what it is.

rd

As Mark Duignan of Lansa has pointed out, in my post of April 26th I over simplified the RPG needed to avoid dual maintenance. Of course RPG's requirement for unique format names precludes such a simple solution. Even using qualified names would require conditioning on each I/O operation.

But thinking about it reminded me that there is an even simpler option - use conditional compiler directives so that a single file definition can be used but with the HANDLER keyword made conditional. e.g.

Main F-spec entry

 /If Defined(HandlerVersion)

   HANDLER ....

 /EndIf

You'll end up creating two program objects this way of course which would require some other corrective action (like separate libraries for example) but it can be done. My feeling is that there aren't enough real 5250s left in the world for this to be a real problem. Once people decide to switch they will switch everything I suspect.

Perhaps more to the point, one argument that could have been made wasn't. Namely that if you intersperse menus or non-RPG generated screens in the mix that RPG OA can't help with that. Both Look and Profound have solutions for this but it would have been a more valid criticism.

Of course it is quite likely that I've got this wrong too as it is not yet 11am and my brain does not fully engage until at least 2pm.

and a few cups of coffee, Jon :) It turns out it's even more complicated than that, or much simpler depending on how you look at it, at least with ProfoundUI (with tradeoff being high quality output for intended display). I will add a bit more detail on this in the forum thread.

The WRKSTN DDS is generated by the ProfoundUI (ProUI) web page Designer program. It has no actual DDS line and column output specifications. It won't display to a 5250, and a 5250 DSPF DDS won't be handled by the ProUI handler.

So in an RPG program that could display to either, you'd have two different WRKSTN F specs and record formats, once built by Designer based on the Designer web page layout which would have the HANDLER keyword, and the other being the original or a new one created for 5250. Both would have USROPN statements on it.

A decision must be made in the RPG program as to what the user display is, and the appropriate WRKSTN F spec opened. I guess checking of job is running in QINTER is clue to open 5250 WRKSTN F spec, although I don't know offhand how it gets submitted to QINTER versus a batch subsystem with no WRKSTN open yet.

In addition, at least for ProUI, web pages designed for mobile devices or any other different layout will be designed separately and have its own DSPF DDS, and RPG program must determine output device and open appropriate WRKSTN F spec.

Obviously any automatic handling of normal web pages for mobile devices and such is beyond scope of both the RPG program and the ProUI handler. ProUI handler would render normal web page and what happens to it after that is out of its control.

But to have different layouts for different devices would require a WRKSTN F spec DDS record format for each one as created by Designer when you lay it out, and only the appropriate one opened by the RPG program based on some external criteria.

I don't know how others are handling that aspect of it, but if mapping a set layout, say the original 5250, to different layouts at the handler level, probably only able to work within 5250 constraints. As I'll add to the forum thread, ProUI is not constrained by 5250 limitations.

rd

Handlers may be difficult to write

I talked to an IBMer about the handlers ... and it's not a case that they may be difficult to write ... it's that they will be difficult to write.

When I mentioned the pricing issue ... I was told, by the same IBMer, that a lot of people argued against the price, but the higher ups made the decision.

Jon

Thanks for that!

Out of professional courtesy I privately point out that what you were saying was wrong.

You then use it as a public opportunity to plug companies that I compete with.

That’s a bit rich don’t you think?

Would you concede that what LANSA said about this in the first place was at least reasonable?

It was about having two executables. The various way(s) you can get them is all kind of moot.

What is not moot is the cost - it's not just about having another executable or library - it's also about the cost of restructuring, retesting and redeploying as well.

(PS: I think am entitled to get a product plug in as well on this occasion?)

david, thanks for that info about many IBM'ers arguing against the price but being overridden by higherups. That helps a little. My take is we have to add all the pieces together to get a final price, and IBM just keep making it more and more difficult and hence more unlikely.

As far as the will be difficult part, I guess a generic engine for converting any 5250 to a web page is not something everyone would want to write, but both with ProfoundUI and CGIDEV2 web page formats are set up ahead of time to fill in and output.

Other third parties already have generic screen to web page conversions. So I think a bit of the will be hard is thinkig about the intended market of someone who would pay IBM to call a third party program for them. Yeah, they might not be inclined to write a CGIDEV2 program even though it's dead simple.

rd

A POSSIBLE WAY TO GET READY FOR RPG-OA?

If you are planning for RPG-OA then you should know that there are a bunch of 5250 DDS keywords that IBM have created to support defining GUI features and constructs. If you start or already using them in your RPG applications right now you may gain two significant benefits:

(1). YOU CAN START USING THEM RIGHT NOW TO GET READY FOR RPG-OA

You can begin implementing them prior to V6R1, start understanding how best to use them and how to code RPG applications around them. You can test them with CA/400 and with various other products. This will position your applications well when you are able to start using RPG-OA

(2). SOME DEGREE OF RPG-OA HANDLER INDEPENDENCE

Since these are all IBM standard DDS keywords they form a 5250 DDS -> GUI base line you can work from.

Anything you get beyond the baseline from an RPG-OA handler is great - but if you stick to the baseline of supported behaviour you should (in theory at least) be able to swap between RPG-OA handlers later should you need to.

===============================================================================

The standard IBM DDS keywords listed below allow you to define and perform these foundational GUI operations:

- Define a menu bar with drop down menu options.

- Define radio button groups.

- Define drops downs for you users to select entries from.

- Display push buttons and their associated accelerator keys.

- Insert HTML into your screen (eg: ranging from a Google map to a product picture to JavaScript code – This actually the fallback GUI control because you can literally do anything you can do in a web page with it. People may use this in very creative ways).

- There could be more GUI options - you would need to read the DDS manual I guess.

===============================================================================

Some of the DDS keywords are listed below. They may ease your path in RPG-OA later when you are in a position to use it. The ones with a ?" mark have a purpose that it not entirely clear. They may or may not be GUI related. You can find these DDS keywords in your DDS reference guide.

(This list is pretty boring so skip it and come back later if you are still interested in this topic) .....

CHCACCEL (Choice Accelerator Text) Specifies the text for the accelerator key on a single-choice selection field in a pull-down record. CHCAVAIL (Choice Color/Display Attribute when Available) Specifies the color or display attributes to be used when displaying the available choices in a menu bar or selection field. CHCCTL (Choice Control) Controls the availability of the choices for the field. CHCSLT (Choice Color/Display Attribute when Selected) Specifies the color or display attributes to be used when displaying a selected choice in a menu bar. CHCUNAVAIL (Choice Color/Display Attribute when Unavailable) Specifies the color or display attributes to be used when displaying the unavailable choices in a selection field. CHOICE (Selection Field Choice) Defines a choice for a selection field. GRDATR (Grid Line Attribute) Defines the color and line-type attributes for grid line structures in the file or record. GRDBOX (Grid Box) Defines the shape, positioning, and attributes of a box. GRDCLR (Grid Clear) Defines a rectangular area on a display within which all grid structures are erased. GRDLIN (Grid Line) Defines the shape, positioning, and attributes of a grid line. GRDRCD (Grid Record) Specifies that this record defines grid structures. No other display fields are allowed on records with this keyword. HLPID (Help Identifier) Specifies an identifier for the constant in the help for a field. HTML (Hyper Text Markup Language) Specifies if a data stream is a HTML. These HTML tags are processed on the HTML browser. This allows you to update applications to use on the Internet through the World Wide Web. MLTCHCFLD (Multiple-Choice Selection Field) Defines a field as a multiple-choice selection field. A multiple-choice selection field is a field that contains a fixed number of choices from which a user can select multiple choices. MNUBAR (Menu Bar) Defines a menu bar. A menu bar is a horizontal list of choices that is followed by a separator line. MNUBARCHC (Menu-Bar Choice) Defines a choice for a menu-bar field. A menu-bar choice represents a group of related actions that the application user can select. MNUBARDSP (Menu-Bar Display) Displays the menu bar. MNUBARSEP (Menu-Bar Separator) Specifies the color, display attributes, or character used to form the menu-bar separator line. MNUBARSW (Menu-Bar Switch Key) Assigns a CA key to the Switch-to-menu-bar key. MNUCNL (Menu Cancel Key) Assigns a CA key to be the cancel key for menu bars or pull-down menus. MOUBTN (Programmable Mouse Button) Allows an attention indicator (AID) to be associated with various pointer device events. PSHBTNCHC (Push Button Choice) Defines a push button within a push button field. See Chapter 6 - Creating a Graphical Look for Displays. PSHBTNFLD (Push Button Field) Defines a field as a push button field. A push button field is a field that contains a fixed number of push buttons. A push button is a button, labeled with text, graphics, or both that represents an action that starts when a user selects the push button. PULLDOWN (Pull-Down Menu) Defines a record as a pull-down menu for a menu bar. SFLCSRPRG (Subfile Cursor Progression) Causes the cursor to move to the same input field in the next subfile record when exiting this field. SFLCHCCTL (Subfile Choice Control) Controls the availability of the choices in a selection list. SFLEND (Subfile End) Displays a plus sign (+) or text (More... or Bottom) in the lower right location of the subfile. It can also display a scroll bar. SFLMLTCHC (Subfile Multiple-Choice Selection List) Defines a subfile as a multiple-choice selection list. A multiple-choice selection list is a potentially scrollable list from which the user can select one or more items. SFLRTNSEL (Subfile Return Selected Choice) Returns all selected choices in a selection list using the get-next-changed operation. SFLSNGCHC (Subfile Single-Choice Selection List) Defines a subfile as a single-choice selection list. A single-choice selection list is a potentially scrollable list from which the user can select one item. SNGCHCFLD (Single-Choice Selection Field) Defines a field as a single-choice selection field. A single-choice selection field is a field that contains a fixed number of choices from which a user can select one choice.

=================================================================================

Jon - in my RPG-OA research I came across the idea in this list.

It is interesting to me because I have encountered a surprising number of OS/400 shops using these DDS keywords.

It sounds safe and reasonable because the stuff it talks about is all defined and supported by IBM.

The idea of a defined set of behaviours that a customer can expect from a 5250 DDS based RPG-OA handler seems like a good idea to me.

After that the vendor specific handler would of course add value as it see fit - but this approach would define a minimum level of expected behaviour from things customers define in their DDS.

WDYT?

You see what I am getting at here? If there are minimum conformance standards, people can start to work towards RPG-OA right now. It also allows them swap between providers – choice being the key reason that standards have worked so well in other IT industry segments and platforms.

The PC and UNIX/LINUX guys cracked how important standards are to growing an IT market a long time ago. Think about interface standards that you have seen over the years – ODBC (data base), MAPI (email) and HTTP/HTML – the list is pretty long.

Here's just one example - the PSHBTNCHC DDS keyword above. Without some baseline standards that say it must be supported you are going to get 10 different ways of doing something as foundational and simple as a push button. Possibly worse - the way that you handle the button in your RPG code is going to vary by RPG-OA handler (Note: I'm not going near the debate that says your RPG code should not even know that the button exists, let alone that someone clicked it – I will just accept the fact that some people will choose to code RPG that way).

"Someone" needs to say that the PSHBTNCHC keyword (or something like it) is to RPG-OA what the <button> element is to the W3C HTML specification – which is why you can reliably cause a button to display in all the web browsers. Vendors will extend this and may even have their own ways of adding "better" buttons (as do people creating HTML/JavaScript control libraries) – that's their value proposition – but there should be a minimum conformance standard in place.

I'm not saying the DDS keywords listed above are the right ones – I'm just saying they might be a starting point for getting some baseline conformance standards defined. They seem a reasonable choice to me because they are defined and supported by IBM, they define a foundational set of GUI constructs, lots of people use them and quite a few products support them – and as a bonus people can start to use them right now while they are waiting to move up to V6R1+.

If we get some baseline standards in place everyone will benefit from transparency, quality, defined behaviours, upward compatibility, choice, etc – but best of all some of the "magic" of standards that has produced things like the Internet and the fact that you can read this post in 5 different web browser on your PC, or even on your iPhone might rub off on the IBM i server market.

Jon – you have indicated frustration with the lukewarm reception that RPG-OA has received from vendors. You think they are against it. I don’t think that's the situation. They are neither for nor against it. They just think that it has no value proposition.

If you look at things like ODBC, MAPI, HTML, HTTP – which are all just interface definitions – their value proposition only exists in the fact that they impose minimum behavioural standard on the vendors. So maybe that's what's wrong with RPG-OA (WRKSTN)? Maybe some standards would create a value proposition for it? Standards bring predictability and a framework in which investment can be sensibly assessed.

You'd have to admit that some baseline standards would have HUGE benefits for the users of it in areas like transparency, guaranteed minimum usability levels, easier quality and functional assessment, being able to plan for it now, ensuring the vendors truly compete, etc?

The current "no standards" situation will be just like data bases before ODBC and SQL – a swirling opaque cloud of claim and counterclaim – often about things that have no real business value – with big dollops of BS occasionally mixed in.

Surely we can learn from recent history and our cousin platforms - standards actually work and everyone benefits in the end.

So this is my question to the forum –

Do you think "someone" should define some minimum conformance standards for the RPG-OA (WRKSTN) interface?

PS: I'd like to add a new item to Chris Maxcer's "Cons" list - there is no baseline or minimum set of conformance standards for RPG-OA (WRKSTN).

Some clarifications to last post …..

(1). There's a group of people who separate their UI definition/control from their business logic.

(2). There's also a group who don't. They want to continue to program to the DDS/RPG model they have always used (which is really the root of EXFMT and state discussions). They also believe that they can define and control GUI controls from that model.

The preceding post was written from what I think is now the expectation of group 2.

RPG-OA (WRKSTN) is also directed at group 2.

I think that group 2 now believe that they have now been provided with a sort of "just change the F spec and then plug and play" capability. Something for 5250 DDS that is like ODBC is to databases.

If you know how RPG-OA works (and what it was intended to deliver) then that statement might seem quite strange – but after reading the forums and talking to some RPG programmers I think that is what they now believe. For example, I think some RPG programmers now believe they can do a product proof of concept exercise by writing an RPG program and then try it out with the web handler from vendor A and then with the phone handler from vendor B – just by changing the F spec – which would be pretty cool. What has been delivered so far does not appear to exactly mesh in with that expectation.

With some agreed RPG-OA standards vendors could deliver to that expectation and the whole IBM i community (customers and vendors) would gain the same benefit as other platforms do.

Discussion of RPG-OA (DISK) and RPG-OA (PRINTER) seems to have gotten lost along the way. Has anyone seen any anywhere?

Nothing I've seen here, Mark. It's been a struggle I think in terms of general perception who don't follow forums, etc. that this is some kind of new IBM GUI interface, not understanding that it is an F spec keyword override to an exit call program for any file.

Of course info is available, COMMON had many good sessions, discussions like this delve into details, so info is out there.

I think your Group 2 has to be broken down into those who design a different optimal screen layout for different intended device support, and those who plan on continuing to design for 5250 layout, perhaps even using keywords as you suggest, and counting on handler to rearrange as best it can for device.

I know with ProfoundUI that there is no rearranging, you have to determine display device support needed and open appropriate WRKSTN file laid out with that device size in mind.

I don't know that there are actually in Group 2 like that, so keyword usage as you suggest doesn't make a lot of sense except for any there may be.

Just FYI, I have used PSHBTNFLD in 5250, but not others. Was intended strictly for 5250, didn't expect webfacing and such to handle it very well. On other hand, with RPG OA, would be able to be handled well and how handled would be nice to have suggested standards as you point out, although have to watch out for lowest common denominator type stuff. In end laying out web page for destination will probably be only realistic high quality solution with whatever product, imo.

rd

There is one very big con, in my opinion, that is being missed. The RPG OA product does not have a trial period. You must purchase it to try it. I see this as a very big issue. If a developer wants to try a handler from a vendor, they must buy RPG OA before being able to try the third party product. Am I missing something here?

WELL, I am amazed. Here we are with RPG-OA and nothing but "moans". Just embrace it and generate new and modernised Apps on your i. If you thought it would be "open source", you're wrong. Pay the money, it's not a fortune and simply get on with it. No wonder our i platform is dying, you're all the "superman teeshirt and Jesus sandle brigade". Get real ... and, get on with it. QED.

"If a developer wants to try a handler from a vendor, they must buy RPG OA before being able to try the third party product. Am I missing something here?"

Sadly the answer is no Schadd - you are correct and it is an issue that I've ranted at IBM about.

Bernard, I like IBM's aggressive new i marketing pitch. May I subscribe to the newsletter?

rd

For me pricing will be the biggest concern.

I'm working for a small software house which writes and sells software tools.

Currently we are developing a tool that makes it easy for RPG programmers to write web applications without knowing anything about HTML and JavaScript. For realization we provide a bunch of RPG procedures to define variables and there is even a procedure that simulates EXFMT in an stateless environment (HTML and JavaScripts combined with AJAX technologies are generated on the fly). It would be nice to allow RPG programmers to use the "native" RPG-Opcodes instead of forcing them to learn and integrate new functions. In this way writing OAR-handler procedures and making them available would be a great deal.

We also have other tools where PDF files, IFS files or excel sheets are generated and handled.

We may be able to write handlers and make the live easier, while replacing complicated procedure calls with native OpCodes. It would be also possible to make those handlers available to our clients for their own use.

... but we'd need to force all of our customers to buy 5733-OAR. If a tool costs 5,000.-- $/Euro even an additional charge of 500.-- $/Euro makes a rise in price of 10%!!! (assumed 5733-OAR is not yet bought).

If we integrate OAR-handlers into our existing products, we need to force our clients to buy 5733-OAR with the next upgrade, otherwise the tool will not work anymore.

What will happen? No upgrade any more? we may loose our client? we need to take over the costs?

Birgitta

I already sent a comment but of some reason it was ignored. My comment was an answer to Schadd Gray and here is it again: You can test Profound UI without to buy RPG OA from IBM by using they pre-compiler.

Yehuda

That's helpful info, Yehuda. Thanks.

It also should make it clear that RPG OA is an optional interface and runtime fee. Vendors don't need it, but it's good when they include an interface to it. That would be my answer to Birgitta above.

Support it as an option and let the customer decide if they want to pay a bit extra for an IBM runtime interface to standard RPG IO. It's a good choice.

rd

"Pay the money, it's not a fortune".

It must not be coming out of YOUR pocket. I own a one man consulting business that specializes in this platform, and every product like this that comes down the pike not only costs me but my clients as well, and that's is a tough sell in this economy.

Besides, after thirty years with IBM I've seen at least a dozen "this is the next greatest thing" in development tools. The only ones that have stood the test of time are the ones bundled into the OS.

Adobe Dreamweaver CS5 about $500.00. Profound UI on a P10 about 20K.

I get exhausted when looking at i Series, no System i, no IBM i function and feature (and 3rd party) prices.

We System i programmers just want to catch up with the rest of the world without getting bent over (again).