Aaron Bartell wrote about the new RPG Open Access (RPGOA) feature available for IBM i.
The biggest problem with RPGOA is the cost … it’s not included in the base OS or RPG compiler. The cost is $500 – $5000, based on your system tier.
As the IBM i community has demonstrated repeatedly … charging extra for features that used to be, or should be, included is a significant barrier to adoption.
One point that Aaron brings up is, in my opinion, quite important … as an ISV (Independent Software Vendor), how do you demo software on a customers system if they don’t have RPGOA installed? Do they have to purchase RPGOA just to run a trial or proof of concept for a software product?
Imagine having to pay $25 for the .net framework on a Windows machine (and it was licensed on a per system basis). How many people would be using any products developed using .net?
Don’t get me wrong … I think RPGOA is a great idea … and could be a great driver for the IBM i. But if it doesn’t get adopted by the users it’s going to die on the vine.
Couldn’t agree more! Charging for RPGOA is a surefire way to ensure it’s never used. Funny thing is the pricing was apparently put in place as a method for “measuring industry acceptance”! Well, sure, _IF_ you’re willing to pay for it you’ll likely use it, but the cost is simply a barrier to entry that will ensure it never achieves widespread adoption!
You guys are too funny. The noise around RPGOA has been spectacular. It has been well received by vendors, many of whom are adding it to their repertoire. The webcasts about RPGOA have been very well subscribed. This is something that has been dreamed about by the i community for so many years, that it is going to be taken up by TONS of people. The $500 is a VERY good investment…
Watch closely, $500 is NOTHING, especially when it is paid for with a server upgrade. Besides, David, neither you OR Walden will ever have to fork out the $500, so why are you complaining?
I expect Aaron will soon have an open source driver for it!
It’s only $500 for the lowest processor tier.
The actual cost is mostly irrelevant … are you going to pay $500 just to get a software DEMO?
MKS can do a full demo of it’s software on ANY IBM i system without requiring the customer to buy any extra software. The language runtime’s are included in the base OS and the Java runtime is free. I’m sure Walden can demo his companies software similarly.
Why charge extra for the RPGOA runtime?
Since it’s so cheap, why not just include it in the base OS and hide the cost. That way EVERYONE gets the necessary runtime and vendors don’t have that hurdle for their handlers.
ROA is a great concept and hopefully a wonderful implementation.
But at $1500 per system (the real price based on the product description on the IBM website) I think its going to be a non-start.
I love what Profoundlogic is doing with it, for example, but if Apache was $1500 per system (and it is not) would people be putting websites on the 400? They barely do now (Or the new name for it, which I think is “IBM Power system running IBM “i””, but “400” is easier and more people know what that means.
Anyway, I hope it’ll be successful, and I know it will be. But that will happen in about a years time when IBM moves the cost into RDP or the compilers or something else and people don’t see that extra charge to us Aaron’s “free software”.
Oh, here’s a free Excel Handler, but you have to pay IBM $1500 to use it. Sorry.
We’ll see what happens, but probably history will repeat, as it usually does, and no significant number of users will be getting.
Why do I think this? Because shop after shop after shop are leaving the platform based solely on software maintenance costs. Adding another $1.5k to that will just push more end-users over the edge.
@Trevor — Even if we accept that the cost is “low”, be that $500, or $5000, I grant that either could be “hidden” at an upgrade time. The larger problem is that there’s no way to “try” this software. How’s the in-shop developer supposed to play with it at lunchtime? How will this get into shops as a skunk-works project — much like PHP did years ago?
@David — What??? I assumed the _runtime_ support was always there. I assumed what cost was the compiler support. Are you saying that if I haven’t paid for RPGOA on my system then I can’t _run_ a program that someone else developed?
>I expect Aaron will soon have an open source driver for it!
I will most likely write about it because it is quite exciting.
But just like how the health care bill was passed, this step by IBM set a unsettling precedence. I am not trying to make the pricing issue the pinnacle of RPGOA, but I will be darned if I am not going to let IBM know about it. And I am not just doing it via blog postings. When George announced it to the ISV’s in the private meeting I made sure I voiced my concerns then. It is NOT the amount that is the issue – it is the complications of adoption that is the issue. Just like initial exposure to IBM i is an issue, this will have the same issue and suffer a similar fate. Not trying to rain on any parade, just choosing to live in both the reality of cheering for a great thing and also the reality of it being poorly marketed/sold.
On the same note, RPGUI is making strides and will have infrastructure that will provide the same capabilities of RPGOA (i.e. persistent jobs). In the end, the code components the ISV’s have to write is almost the same before and after RPGOA’s existence. The thing that RPGOA gives is familiarity to the long term RPG coder.
AaronBartell.com
@Walden, according to IT Jungle …
BUt David, we don’t know if IBM is going to charge you $500 for a demo of RPGOA – so far, that is all speculation. Until we know, why are we complaining about it?
As for the number of companies with a P05 tier – the lowest, I expect you would be surprised that the majority of servers out there are 520s, and will be either P05 or P10. $500, or more for the P10, is simply not an issue from a business perspective. For an individual, it may be, but not for businesses who would spend $500 to write native RPG code to a browser!
I agree with Aaron, it is the principle of the cost that is the problem, not so much the amount. But, in the end, Rational makes decisions that piss us off, but we can only do something about it by positively discussing it. Speculation such as Walden’s (the pricing was apparently put in place as a method for measuring industry acceptance) is simply not going to help get Rational to change their mind.
Have you, Aaron or Walden contacted Rational to ask about these prices? Or, are we all just listening to the so-called pundits? Especially when they quote the wrong prices and spread FUD. I think the truth is somewhat different than what most people are speculating…
There isn’t any mention of a trial version … they’ve always offered the 90 day trial for RDi & RDPi. Based on previous experience, this indicates that there is no trial version.
I agree with this too.
Me? No. RPGOA is not even close to a business requirement for me.
My problem with the pricing is strictly from a principal perspective.
I really really wish that Rational had not charged for the product – I’d rather have seen a boost in the compiler price if they had to make money on it but …
The vast majority are going to pay $500 or $1,000. Not a huge amount. I’m less worried by the amount than the fact that IBM’s ordering process is generally so horrible that folks may try ordering it and give up.
I suspect that many business partners writing a new lease will just include it.
One thought on the “demo mode”. Since OA is a regular product won’t it be capable of being loaded and used for the normal 60 (or is it 70?) days anyway? At least that way folks could test it out.
I tried posting this on Aaron’s blog, but hasn’t yet appeared there:
‘Like everyone else, I’ve been following the discussion regarding “Open Access”. And like many predicted, it turns out to be some kind of enhanced SPECIAL file support. On steroids. Deep down, it all boils down to mapping RPG I/O operations to a special “handler” procedure, but with little beyond what you get with just calling the procedure directly. There are some differences: First, you get the extra overhead of a few extra procedure calls before you get to the handler. Second, you’re limited to the operations provided by the I/O opcodes.
‘One iSeries analyst commented to me (I hope not in confidence!) that Open Access is intended for those companies that haven’t yet embraced web-based UI’s. My response to him was this: If a shop hasn’t yet started using web-based UI’s in spite of all the currently available options, nothing’s going to move them. (He didn’t have a good answer to that comment.)
‘This is just idle speculation, but maybe the price tag is intended to give Open Access some legitimacy in the eyes of those particular customers? That is, if it has a cost, perhaps these shops will think it has value?’
Anyways, I’ve been thinking further on the subject, and here are some more of my thoughts:
First, I think Jon may be right that most shops will pay the extra amount.
Second, I can’t help but think IBM has made a big mistake here. Is Open Access supposed to make web-enablement easier? Look, anyone who has done the least bit of web programming should know that the RPG I/O model is a poor fit to the transactional web model. Web-based communication (via SOAP, XML-RPC, HTTP, etc.) is more like program or procedure call than like RPG I/O. Why hasn’t IBM done more to make web calls a better fit to RPG’s calling mechanism?
In other languages, the web protocols are often abstracted out, and you write your web service as a normal function or procedure. And you call your web service like a normal procedure or function call. That’s the kind of capability RPG needs.
I don’t think the enhanced SPECIAL file support is necessarily bad. I just don’t see the point. And it just seems like an unfortunate diversion from what’s really needed. In other words, RPG and iSeries will suffer from lost opportunity, while other languages and systems continue advancing.
Hans
@Trevor — Nope, haven’t checked w/IBM. For me the cost is ZERO or NOT ZERO. And a not zero cost will simply be an impediment to adoption.
@Hans – I checked my blog but didn’t see any pending posts. Feel free to post it again to make sure it wasn’t a browser glitch.
On your comments concerning making web-enabled easier, I think the only way it really makes it easier is if an RPG Open Access vendor adds a persistence layer. ProfoundUI has put in a persistence layer as has RPGUI (which is nearly ready for it’s next release). The other thing that always takes a lot of time is the UI layer construction (i.e. HTML CSS JavaScript). If an RPG web programmer can have those two things taken care of for them then they actually have a much more efficient (as in man hours) programming stack than any other that I can think of. Because not only do you have those two aforementioned features but also the integratedness of DB2 IBMi – something no other platform can boast of that I know of.
What are your thoughts on that being you have lived the RPG compiler team life and also know the open source world outside of the IBM i community?
AaronBartell.com
Here is my latest update on trying to obtain RPG Open Access: http://mowyourlawn.com/blog/?p=237&cpage=1#comment-30374
Note that I am not using my “ISV string pulling” to obtain RPG Open Access and instead going after it according to what IBM is telling me via their web pages.
I don’t quite have the right to piss and moan yet, but I believe at this point IBM has failed us. I will continue on to see what it takes to actually get it (though I don’t really want to spend $500 to prove a point – anybody want to make a donation to my cause?)
AaronBartell.com
Aaron: Persistence is, of course, probably the biggest problem facing application developers. And also, yet another area where I think Rochester has dropped the ball. Back in the late 70’s, they developed an operating system based on the principle of single level store. But what capabilities did they give to the RPG programmer? An ISAM-like file I/O model. Basically, few of the advantages of SLS are available to the programmer. The programmer has to deal with persistent data via reads and writes.
And now, we are generally stuck with SQL. It’s ubiquitous, but it basically sucks. Again, other languages and systems are exploring alternative mechanisms. For example, there’s the ZODB (Zope Object DB) where objects are automatically serialized, stored, and retrieved as necessary, in a manner totally transparent to the programmer.
Or more conventionally, there’s the object-relational mapper in Django. There, the programmer defines the database using Python syntax, and never has to write SQL code (unless really necessary).
Even Perl has had “tied hashes” for ages. The idea is that the hash is associated with a database file. Accessing an element of the hash results in a keyed read from the file, transparent to the programmer.
I guess my point here is that the trend on the bleeding edge seems to be towards abstracting out the actual file operations.
Regarding the integrated nature of the DB on i, I don’t really see it as much of an advantage. Consider the vast majority of Linux distros. Most come with a choice of free, open-source DBMS’s, including PostgreSQL and MySQL, as well as GUI tools for dealing with these DBMS’s.
Hans
@Hans – Integrated DB’s are a huge time savings. I never have to worry about connection pools, for example. Also, because it is such an integral part of the IBM i infrastructure it is paid more attention by IBM in my opinion, and thus just works better. DB2 on IBM i “just works” and I don’t have to finagle with it like I do other DB engines. I don’t know your background, but when you get into maintaining a seriously large home grown ERP application, well, DB2 on IBM i is an excellent DB where others just aren’t as good in the same respects. For the hobby programmer that uses a lot of open source, well then the proprietary DB’s are as appealing.
On the topic of transparent table mappings and DB persistence. I am not sure how comfortable I would be without my READ/CHAIN and WRITE/UPDATE opcodes because they allow me to declare exactly what I am doing vs. programming on assumption that records have been updated.
AaronBartell.com
Aaron: True, the integrated DB on i does have some advantages.
On persistence, even if you’re doing an UPDATE, there are still points of failure that might cause the record to not be updated. So I don’t see any difference between UPDATE, and, say, “h[i]=obj”.
More later… Got to go.
Hans
@Hans – I do know that errors can still happen, but the fact that you have a lock on that record before doing an update makes a big difference in my book.
In your example, does the DB update occur as soon as the h variable is updated with obj? This is where ORM (Object Relational Management) solutions would try to queue up requests to the server and if you wanted it to literally happen you would need to follow it up with a flush of some sort. These types of ORMs (i.e. Hibernate) can get really fickle and bring down an entire Tomcat server because of a badly cached object (which is sometimes Hibernates fault and sometimes the programmers fault).
What I would say in the end is that RPG DB2 IBMi has had a loooooong time to marinade (i.e. bugs/issues worked out) where as the up and coming engines have a lot of mud puddle jumping to do before they get it right – granted it should take them less time than it took IBM because they don’t have to learn everything from the ground up perse.
AaronBartell.com
Aaron: I agree that the other forms of persistence have problems too. My point is that IBM gave us a nice persistence framework via single level store, but failed to provide a useful, high-level interface for persisting data. Instead, persistence is primarily through the database.
But I think we’re digressing. To get back to your original point: “On your comments concerning making web-enabled easier, I think the only way it really makes it easier is if an RPG Open Access vendor adds a persistence layer.”
I think what you’re talking about is maintaining session state, right? Well, that has to be done regardless of the framework. So I’m not sure I get your point.
You also mention UI construction, and again, that has to be done regardless of the framework. I don’t see the connection with Open Access, which is basically just a way of calling some procedure using an RPG I/O style interface.
But like I said before, RPG I/O is a poor fit to the whole web-based transaction model. If the goal was easier web-enablement, then the better approach would be to link web transactions with the procedure calling mechanism.
>then the better approach would be to link web transactions with the procedure calling mechanism.
Ah! I like where you are going. So how about this…. what are your thoughts about dynamically activating/invoking exported sub procedures using system API’s? Note that RPGOA has no bearing on this really.
AaronBartell.com
“But like I said before, RPG I/O is a poor fit to the whole web-based transaction model. If the goal was easier web-enablement, then the better approach would be to link web transactions with the procedure calling mechanism.”
Have you actually looked at the demo for Profound’s stuff Hans? Because if not, maybe you should take a look at the demos on the web and see how innovative they’ve been in confronting the challenges. Then tell us what is missing.
Seems to me they have provided a pretty nice balance between using the familiar existing 5250 style model and extending it in areas which make sense like predictive data entry and population of pull-downs etc. At some point in any data entry/update process there comes a time when the user has to push a button and say “go to it baby”. The 5250 model works pretty well in that scenario. It seems to me that far too often web apps do stuff not becuase that interface makes sense to “real people” but becuase it was cute and the designer had seen it on someone else’s web site.
Given the extensions that a tool like Profound’s provides, do you really think that the end users (who right now are dealing with green screens) are going to be that upset becuase every last nuance of what web 2.0 could do for them can’t be fully expressed? My guess is they will be happier than pigs in the brown stuff.
Sometimes I think we all get way too tied up in the technology and forget that there are real people out there using this stuff.
It’s interesting to read such a wide variety of perceptions about RPGOA. Leading producers of screen scrapers seem to be ecstatic about removing some of the constraints they’ve been under for years. They will now be able to capture I/O buffers, before 5250 data streams would otherwise be generated, and get around the constraints inherent therein. That’s such a huge relief. It’s worth IBM’s price.
IBM is fomenting the position that RPGOA is a new product, separate from the RPG compiler, and perhaps even leveraging the constraints of screen-scrapers to make that point, and justify a separate price. But that’s rather contrived. It doesn’t make sense to characterize it as being separate from the compiler, technically.
My perception is that RPGOA is a new interface for “calling” programs and procedures, via traditional I/O op codes, which is a feature of the RPG compiler. Trying to position RPGOA as “larger” than that, is a bit contrived. That’s the part that rubs me.
It won’t be long before producers of I/O handlers will be offering the option of calling their handlers through a procedure interface. Or, if they prefer to evoke handlers through traditional I/O op codes, they may pay IBM extra for that option. The folks at Profound Logic already alluded to that; indicating that they could support clients that were on releases, earlier than 6.1.
When RPG programmers begin understanding that they have the option of evoking I/O handlers directly, via procedure interfaces, as an alternative to IBM’s I/O op codes, they’re likely to call RPGOA the “F” spec tax, or something along those lines.
I debated several days about raising that point, or not. I really think that RPGOA has a lot of technical merit, and I hate to denigrate that in any way, but it’s only a matter of time before producers of I/O handlers begin offering procedural interfaces, in addition to RPGOA interfaces, with no functional differences, where the RPGOA interface will become to be seen as “overhead” – due to IBM’s extra licensing requirements.
-Nathan.
Please note – this is not “aimed” at youNathan — but you gave me an appropriate kick-off quote!
” Trying to position RPGOA as larger than that, is a bit contrived. Thats the part that rubs me.”
It is called marketing. Why is it such a problem for so many people?
For the first time in many many years (the introduction of /Free?) we have something in the RPG arena that folks are excited about. Why is that so wrong?
Name any new technology that hasn’t been hyped beyond its capability! Our own David here busily tweets away … talk about an overhyped technology looking for a worthwhile use – not to mention a business model!
Is OA the second coming? No.
Will it be useful for many people? Yes.
Is it generating a lot of buzz? Yes – and about time something did.
My biggest fear in all this negativity is that the RPG-haters among TPTB at Rational will look at all the comments from the naysayers and simply say “To heck with them – they aren’t happy no matter what we do”. I know if I worked at Rational I’d be feeling that way right about now.
We seem to have got stuck in whine mode – and it is not becoming. Folks don’t like it – fine – ignore it. Why do so many folk feel the need to go so negative in public? I can understand it from the perspective of vendors who didn’t jump on board and are perhaps upset over all the exposure their competitors are getting, but for all the RPGers out there to be so negative – it is just beyond my comprehension.
“It wont be long before producers of I/O handlers will be offering the option of calling their handlers through a procedure interface. Or, if they prefer to evoke handlers through traditional I/O op codes, they may pay IBM extra for that option. The folks at Profound Logic already alluded to that; indicating that they could support clients that were on releases, earlier than 6.1.”
What Profound have said is that they can generate all the required field moves and API calls and stick them in in place of the EXFMT or whatever. We wrote code years ago to do that and I believe Joe Pluta’s product is based on that same notion. But nobody is going to code by hand to that kind of interface. Those who are willing to do so did it long ago – they’ve moved past that point.
“When RPG programmers begin understanding that they have the option of evoking I/O handlers directly, via procedure interfaces, as an alternative to IBMs I/O op codes, theyre likely to call RPGOA the F spec tax, or something along those lines.”
What if in 6 months IBM drop the charge and absorb it into the compiler cost? Which frankly they should have done anyway. Then there’s no tax.
The “tax” is pretty small anyway. Probably 95% of shops are covered in the P05 and P10 tiers – so $500 or $1,000.
If they would rather code directly to APIs than pay that tax then you have to ask yourself why they haven’t already done so? Remove the handler concept (unless you replace with a pre-processor which is another whole bag) and there’s nothing available now that we haven’t had for years. So why would people suddenly start doing it now?
It is not a silver bullet – but if it makes Joe Average think “I can do that” – then it has achieved something that nothing else to date has been able to do. And that is an achievement in itself.
“It is called marketing. Why is it such a problem for so many people?”
—
“What part of lie = marketing don’t you understand?”
That’s a quote from Simon Coulter. It gave me a chuckle the first time he said it, and many times since. I hope it has the same effect here.
I should add that I’m very positive about the technical aspects of the of the interface, and have spoken about that in a number of settings. It has been a little amusing to hear Lansa and BCD speak against the technical elements. I don’t share their concerns. It sounds like they missed the boat, even though they were evidently included in a rather exclusive inner circle of ISV’s.
@ Jon Paris on April 26th, 2010
Jon, well said. We are our own biggest enemies if some of the whinging around this subject on the net is analysed…
The choices we have is really very simple: use it or don’t use it, based on the ROI and value proposition. US $ 500,00 is a non issue for people making business decisions based on value.
The promise ROA holds is probably the biggest and most exciting thing that has happened with RPG for a very, very long time imho.
Marinus,
For some of us, the value proposition boils down to something like the following:
open NAME;
read NAME;
write NAME;
close NAME;
vs.
open(‘NAME’);
read(‘NAME’,buffer);
write(‘NAME’,buffer);
close(‘NAME’);
Where the RPG procedure interfaces are essentially equivalent to the RPGOA op code interfaces, both functionally, and ease of use. Would you go to the trouble of licensing and installing an additional product for the op code interface?
-Nathan.
You missed all of the EVALs for filling the buffer Nathan.
Unless all of the fields in “buffer” come from a single file, at some point they had to be copied into it. In many cases the fields in the buffer will have come from multiple files – as long as the field names matched, the WRITE (for instance) would have gathered all the data from the different files and placed it in the buffer. With the function/parm method that has to be coded by hand.
“You missed all of the EVALs for filling the buffer Nathan.”
—
I thought we already covered that in the Linkedin discussion, Jon. Don’t get stuck on the way CGIDEV2 works, or any similar interface. I haven’t missed any EVALS for filling in the buffer.
I really am talking about a procedural interface that is essentially equivalent to an RPGOA interface, in functionality, and simplicity.
I should admit that it’s not the same as RPGOA. It wouldn’t set values for %found(), %eof(), or %error(), for example, although equivalents may be provided.
My only question is whether people would find the RPGOA interface worth the additional, and optional licensing requirements of IBM. Otherwise, it wouldn’t be worth my time to plugin to the RPGOA interface. I’d only offer and support the procedural interfaces.
I do understand why producers of screen scrapers are gung-ho about RPGOA, in that it removes some difficult constraints, with minimal impact to existing programs.
But my interest is not screen-scraping, or any derivative of it. My interest is new applications, following new event models and design patterns.
-Nathan.
I owe you all an apology. In my excitement, I completely ignored that other people may come from a completely different perspective, with different requirements.
My excitement stems from the possibilities it opens up from a modernization perspective, not ignoring new development, and then so from a tool/technology provider perspective. In my experience few installations have the skills or luxury to develop and leverage the kind of code that Aaron and Nathan is intimating – they are too busy developing/delivering business functionality (and so they should be).
Add to this the advanced architecture that some tools inherently have to provide multi channel delivery from a single base, you will start to appreciate my excitement. Do yourself a favour and go study specifically what looksoftware is doing with ROA, one single handler and then leveraging the inherent capabilities of their architecture. You will be impressed and probably as excited as I am.
Why?? Suddenly the average development shop can focus on delivering business functionality, without any concern of how it will be delivered, as the possibilities are lirerally endless.
And as a foundation going forward, ROA is a very, very good, solid step in the right direction. Plus what Toronto is signaling is a clear intention to assist us in leveraging RPG. That specifically excites me, as we all know what RPG is capable of…
-[ Without prejudice.
I just cannot believe what I am reading here!! I should know better in this static, myopic, IBM manipulated & controlled “i” eco system. You need a new plank to respond and lead the OA RPG debate. Look no further than the parallel universe of the World Economic or carbon emissions crisis. Both are happening. Yet, old world incumbents are trying to apply protectionist economic and environmental policy from the entrenched positions they are desperately trying to sustain and protect. Get real! The world has changed and is continuing to do so at an ever increasing quantum rate. First it was flat, then the globe was painted red, long live the empire!
Once upon a time the only psudo information decisions were based on came from IBM and to a lesser extent vendors. Those days have passed. The emperor is a naked ape. See comments inline below. ]-
>>
Please note this is not aimed at youNathan but you gave me an appropriate kick-off quote!
Trying to position RPGOA as larger than that, is a bit contrived. Thats the part that rubs me.
>>
-[ Rubbing something and it is not an itch. ]-
>>
It is called marketing. Why is it such a problem for so many people?
>>
-[This marketing is lies served as propaganda. It only works on the weak minded, lazy and uninformed. The revolution is in full swing. Steve Jobs is the new Che. IBM is the British labour party. Trevor Perry is Gobels. ]-
>>
For the first time in many many years (the introduction of /Free?) we have something in the RPG arena that folks are excited about. Why is that so wrong?
>>
-[ If this had happened 15 years ago it may have had some legs and a future. Now it is back to the future. RPG folks, how condescending! It is wrong. It is out of step with the development options and reality of now and the future. ]-
>>
Name any new technology that hasnt been hyped beyond its capability! Our own David here busily tweets away talk about an overhyped technology looking for a worthwhile use not to mention a business model!
>>
-[ Twitter is dead and oh so, so over. An aberration that has no bearing on business or life, try as the hype may. A contrived mechanism designed to waste time that morphs you into an insecure & vacuous dweeb. Try HTML 5 or Lua? ]-
>>
Is OA the second coming? No.
>>
-[ Second? This implies OA RPG is in the blessed race, it is not. ]-
>>
Will it be useful for many people? Yes.
>>
-[ OA RPG is useful to desperate vendors only. Look elsewhere for innovation.
This is a game of blind mans bluff by IBM and its mealy mouthed consorts. They are stuck on episode one of Dr. Who while the rest of us are watching Avatar in 3D at iMax. ]-
>>
Is it generating a lot of buzz? Yes and about time something did.
>>
-[ IPad & Android generate buzz (hype)! OA RPG is just static coming from that big white noise generator, IBM. OA RPG supporting vendors are like the kid in Poltergeist in front of the TV. ]-
>>
My biggest fear in all this negativity is that the RPG-haters among TPTB at Rational will look at all the comments from the naysayers and simply say To heck with them they arent happy no matter what we do. I know if I worked at Rational Id be feeling that way right about now.
>>
-[ Yea, like Rational have their fingers on the pulse. The days of IBM labs parting the Red Sea and leading the faithful into the wilderness are myth. In its hay day Rational had a Duck Soup product portfolio at best. ]-
>>
We seem to have got stuck in whine mode and it is not becoming. Folks dont like it fine ignore it. Why do so many folk feel the need to go so negative in public? I can understand it from the perspective of vendors who didnt jump on board and are perhaps upset over all the exposure their competitors are getting, but for all the RPGers out there to be so negative it is just beyond my comprehension.
>>
-[ Ignore it? Ok will do. I have better things to do with my dime. The exposure the OA RPG vendors are getting will cause carcinoma. Get real! There is no such thing as an RPGer anymore, they only exist on the dole or pension. ]-
>>
It wont be long before producers of I/O handlers will be offering the option of calling their handlers through a procedure interface. Or, if they prefer to evoke handlers through traditional I/O op codes, they may pay IBM extra for that option. The folks at Profound Logic already alluded to that; indicating that they could support clients that were on releases, earlier than 6.1.
>>
-[ Pay IBM? I have been paying the IBM ferry man for decades and now have two pennies as eyes. Like I am desparate to code for older releases. Just like I am desperate to code for the current release, NOT! What dark comedy is this, Waiting for Godot? ]-
>>
What Profound have said is that they can generate all the required field moves and API calls and stick them in in place of the EXFMT or whatever. We wrote code years ago to do that and I believe Joe Plutas product is based on that same notion. But nobody is going to code by hand to that kind of interface. Those who are willing to do so did it long ago theyve moved past that point.
>>
-[ I know what place Profound can stick it. Ahhh, the good old days, the dark ages. Joe Pluto is as relevant as a moon landing.
As a well repected vendor I know opined, “RPG developers are beggars at the feast and should be DAMN GRATEFUL for any scraps Rational throw their way!” ]-
FWIW: I just heard from a reliable source … there is NOT a trial for RPGOA.
Whoa Bob!
Such vitriol!
Why spend so much time commenting on what we think, if you are in such absolute disagreement? Neither party will convince the other, so why the effort?
The architecture is still light years ahead of the competition…
And RPG wipes the floor with ANY other language in high volume commercial transaction processing.
Take care!
>>
Whoa Bob!
Such vitriol!
>>
-[Being subtle masks reality.]-
>>
Why spend so much time commenting on what we think, if you are in such absolute disagreement? Neither party will convince the other, so why the effort?
>>
-[Can but try. Spent time commenting just as I have spent longer waiting for IBM to address a long standing/fundamental system shortcoming. Innovation happens at blazing speed elsewhere, but not here and not by IBM. I am somewhat jaded by this fudge given investment in platform.]-
>>
The architecture is still light years ahead of the competition
>>
-[Ahh, in the day. New era dawns relentlessly.]-
>>
And RPG wipes the floor with ANY other language in high volume commercial transaction processing.
>>
-[Wow, big claim. Insular perspective fostered in this eco system. The language is on life support!]-
>And RPG wipes the floor with ANY other language
>in high volume commercial transaction processing.
Perhaps. And BetaMax was better than VHS, LaserDisc better than DVD, HD-DVD better than BluRay, and tube-amps sound better than MOSFETs.
But at the end of the day the “better” technology is the one that survives. And the one that survives is the one that has more market share, and that’s the one that is _perceived_ as betting better (usually because of marketing). RPG lost that race long ago.
-Walden
ROA is a new way to interface apps, like the iPad is a new way to interface apps.
Until no products are finished to use the new way’s capacities, most people have difficulties to embrace its value.
But there is no doubt both ways offer new possibilities, one for its architecture, the other for its touch & feel.
UPDATE Q1 2012: This issue is now mute. IBM heard the voices of the ‘folks in the tenches’, and has now delivered OA without charge.