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.
>
midrange.com
