Re: Turning green-screen apps into web apps

After evaluating one screen-scraper product, I am not much of a fan. It
doesn't give me the right feel of a web application with subfiles converted
to scroll bars and other little things. Don't get me wrong, I am amazed at
how well the product worked, but it didn't solve the usability problem we
wanted to fix.

What I would prefer (after that experience) is an API to the 5250 stream. I
could then call the application from a program I create. That way we have
more control over the look and feel, even if the back-end code would be a
PITA. We don't have people screaming for a web interface, just un-educated
comments about the "old interface" or the "DOS prompt". Anything new we
create for the web, would be designed for that purpose.

--
Mike Wills
http://mikewills.me


On Tue, Jan 11, 2011 at 7:50 AM, Michael Ryan <michaelrtr@xxxxxxxxx> wrote:

Hi Mike...OP IIRC..

I'm currently evaluating solutions for this very issue. I'm looking at
all the major players, and see them grouped into two main camps - the
screen scraper technologies and the development technologies. The
screen scrapers (BCD-Presto, Profound Logic-Genie, IBM-Webfacing/HATS)
have the advantage of relatively low cost and quick
adoption/implementation. They're not very easily extendable, though
they can be with Javascript and JQuery knowledge. They all seem to do
a pretty good job of converting the 5250 data stream to HTML on the
fly. Some of the issues are double maintenance (if you've customized
some screens, and then make big enough changes to the DSPF, you'll
need to readdress the screen customization), screen recognition (which
is largely a function of screen standardization), and lack of the look
and feel of a 'real' web app. But...it's easy to get your applications
to run in a browser, and everything you need is on the i. The other
solutions vary (and I'm looking at Advanced Business Link-Strategi,
looksoftware-newlook <what's up with the ee cummings format>,
mrc-m-power <more ee>), but include issues such as requiring code on
the client, requiring a separate Windows system, requiring Tomcat, and
the development effort/learning curve of a new application. These
issues aren't insurmountable by any means, but they're there. You can
certainly get a closer fit with the development products than you can
with the screen scraping products.

I haven't completed the evaluation yet, but am learning more about the
products. Feel free to contact me directly if you want more
information.

- Michael

On Tue, Jan 11, 2011 at 8:05 AM, <cozzi@xxxxxxxxx> wrote:

If you don't have the source, your only solution is something like HATS
or better yet, Presto from BCD.
If you have source, BCD's WebSmart might be a great choice.
I also like using JavaScript/Ajax and HTML. I'm not a fan of PHP, but
its pretty good on "i" and scales well (if you buy the fee-based
version, which is worth it).

Tools like my CGILIB in RPGxTools.com (or a smaller package like
CGIDEV2) can be very helpful and satisfying to RPG programmers as well
as help avoid the "RPG for the Web" complexities.
With CGILIB they get to actually write RPG code that does I/O to the web
rather than simply be a facilitator for another development process.

-Bob

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.