Re: Has anyone done any processing with OA and WORKSTN device types?

Hi,

Steven

> Thanks, Joe for the explanation of why the handlers have to be quite proprietary. It is surely understandable, unless open source
> handlers some how get used in some product. My point was more simply about the limitation of the venders liking to use the word
> non-proprietary in the context of their products. That is true for parts of their implementation

Jon Paris

...unless IBM does away with the idiotic charges for OA there will probably not be be much open source effort.... The whole point of OS is to collaborate and share code. If there's a pre-req fee before you can join the development effort or even use the OS software, how many OS developers will bother? More people need to add their votes to the requirements to change this being gathered by COMMON - there are already a large number there - add your voice.

Steven
Thanks. Your point is excellent. A handler is a natural and superb open source project, especially since so much is going to be tied into the result. You can sleep at night that no legal beagles will upset the apple cart if your proprietary company goes out of business. Somebody can still tell exactly what is going on. IBM should wake up and smell some herb tea and figure out a way to get this going. I will add my voice, although I have been outside of COMMON for some years.

Jon Paris

Second - and more to the point of this post. IBM, in an attempt to get OA out of the door ASAP, did not define a standard for storing metadata regarding the interface. Many things are needed ranging from which fields overlap, which indicators control what function, how has a particular field been mapped to the UI, etc. etc. On the whole this is a good thing as any IBM standard would have been horribly over-engineered.

Steven
Right. I thought of that when they were saying .. "why doesn't IBM do a handler" ?

Jon Paris

Right now there is an effort underway among the OA vendors and other interested parties to define a storage mechanism and standards for such metadata.

Steven
And, in the long run, this would be a natural for both open source and vendor collaboration.

Jon Paris

In the intervening period each vendor will continue to do their own thing.

Writing a handler to provide an interface to a specific program/screen combination is doable as you are able to write the handler with full awareness of what is needed. Writing a generic handler, as the vendors do, that can deal with any combination is, as Joe noted, a much more difficult task. I wouldn't want to try it - although I have written a few handlers for other purposes.

One of the points raised by Joe (calling from one program to another when both use subfiles etc.) is not quite as difficult as it might be because of the simply elegant way in which OA handles state information. As long as any arrays etc. related to the subfile are stored within the file specific storage area then RPG effectively takes care of it for you as whenever the handler is called you are immediately connected to the file specific storage. This also makes it a simple task to write a handler that can be used for multiple files in a single program.

Steven
When I had the presentations, I pointed out that good RPG 2 code is the opposite style of subfiles. The fields are all placed into a single full-screen output after using a temp one-record workfile line-by-line to do the editing in output-input mode. Thus the result is that, for real action on the PC side (e.g. creating new graphs and tables) either the RPG code should be changed to subfiles, or you end up with the logic of breaking the screen down to sub-fields after the handlers. The vendors seemed to be unawares of this aspect.

However, I think we sort of agree, that short of RPG somehow handling output to the web and such (and we are a decade too late on that one) the OA architecture is an absolutely necessary ingredient to more substantive modernization without rewrite of all the internal techie code stuff that was developed for so wrong. It even has the potential to encourage new applications and enhancements to existing apps that were long stable.

Overall, I am reasonably impressed, while concerned over any possibilities of performance hits. And also wanting to consider the extent to which you might find yourself maintaining a dual screen environment (does not seem to be a major factor) and your working with database coding from two ends as you start to like the PC side (this is probably more with ASNA than the other products).

One problem is the cost of the proprietary products which I did not mention, and which has rather wild variation and can easily be prohibitive, in some cases, for a small shop as opposed to an enterprise rewrite (and all the in-betweens). While there is no particular need to go into details here now, I will say that this is a big factor.

Yours truly,
Steven Spencer
Queens, NY