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

Hi Steven

Glad the article helped a little.

I, too, saw Tom's first concern with performance, and had suggested he go to ASNA with his questions. Not sure where he got on that, hence your question, right?

Profound is not using anything new at 6.1 for DSPF DDS, they're actually leveraging an old keyword that never got used except for Workstation Gateway, as I recall. They've called it a Rich Display File - nice way to extend things.

I, too, am convinced that OA can be a good approach for some things - in addition to your list, data integration with non-i data sources, from web services to RDBMS' of any stripe.

As I've seen it, OA has a couple basic issues - I don't think it uses buffering for IO the same way as native does, but someone at IBM will have to confirm or deny that. That's not so much an issue for WORKSTN or PRINTER file types, but it could be for DISK types. I have to think some about how my handler could buffer things, at least so far as delivering rows back to RPG. Maybe the OA engine could make multiple requests while other things are being processed, eh?

As to WORKSTN types, you can always write your own - a daunting task, as Joe points out. Personally, I think most shops that would write their own handlers will do DISK-type handlers, which are much easier to manage - albeit not without landmines.

Regards
Vern

On 6/27/2011 12:13 AM, Steven Spencer wrote:

Hi,

Vern

Not sure if it will add to your investigation, but you might look at
the special report I wrote on Open Access - it was in the April 2011
issue of System i News. Admittedly, it was sponsored, but I was
given full freedom to be even-handed in my presentation of the 3
main WORKSTN-type handlers vendors. I also present my experience
writing a DISK-type handler. I'm open to any private conversation on
this, as well.

Your article has been helpful. And I am pretty much convinced that
these products are a good modernization program for those who do not
want to rewrite RPG program logic. You can, conceivably get a number
of advantages at a maybe reasonable cost.

1) initial light modernization on the fly (without losing green screen options)

2) PC integration .. email, Word, Google Maps, Excel etc. immediately
available as if you were in a PC program (with some programming
calls)

3) More advanced modernization using the tools of the vendor (which
vary widely in concept and implementation)

4) Application enhancement .. including integrating additional data
sources, creating graphs and tables, etc.

However, Tom was referring to a performance hit he was getting, one
that was too great a cost. Even one second would be a major concern.
This could have been an early implementation with bugs or
difficulties, or it could be an inherent architectural bottleneck of
adding the output layer. (Presumably ASP.NET refers to the ASNA
product.) So this becomes the first question. The same question
would apply to any product, in the context of workstation IO, where
screen response time is critical.

One of the big advantages of the newer AS/400s over the old SSP 5363s
is that we are much closer to immediate response on screen I/O. And
on short processing stuff in between screens (like reports). And
that is something that we do not want to lose.

The ASNA product is new, not in the field, and they offer an online
proof-of-concept using their AS400 online, but then you can not tell
the source of a delay. Now ASNA has a rich techie heritage going
back to the 36, for awhile it looked like they were pushing Microsoft
a bit too hard for my tastes, the new Open Access product (Wings)
seems to correct that problem, in that it does not grumble that you
have and like the iSeries.

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

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 (e.g. Profound having you create
enhanced DDS source, which I understand is an IBM programming feature
on 6.1. Or ASNA encouraging various work in Visual Studio, where
programming skills are shared with a large base.) However there is
nothing non-proprietary about the basic concept. So a lot of your
investment of time and energy is going to be linked to a specific company.

Steven Spencer
Queens, NY

Tom Deskevich wrote:

I am doing some testing with a product that uses a ASP.NET

handler and RPG OA . There seems to be a bottle neck once it

attempts to take over the interface via OA. Am experiencing an

average 3 second response time on simple applications. When I look

at the call stack, I can see the program opening the files.

But then I see a 2-3 second extra delay over that. We have a
decent server and i. Any insight would be helpful, thanks.

Steven
And here is one reason I write all this. Do you have a little report
back ? I could write you privately, but I'm sure others would want
to know if you made headway on this, or gave it up, or what.