× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.







Great information from Buck and Simon and all else contributing. Thanks
people.

As for the RF question: we are running Teklogix under their OS called
TEKTerm...soon to be converting to a "Mocha-Soft" type emulation which will
rid us of the workstation controller and provide colorization for the
hand-helds...which will definetly enhance the WMS operations. Since this
system runs on a Windows CE platform, I see no reason why we couldn't web
face these thin client screens and run the jobs out of the web-faced "batch
mode" without performance hindrance.

IBM is telling us that as long as you have a minimum of 500 CPW, there
should be no performance issues whatsoever with any interactive
applications running in the web-faced batch environment. Our WMS
environment is a heavy-duty transactional system (aren't they all?) and my
only concern was how each program would react responsively if they were
converted. I have seen attempts at Java-based WMS systems before and they
all have been miserable failures...the more layers you run through, the
more trouble you get into when every function key is asking for multiple
database and program exchanges. However, with RPG still running on the 400
and just the screens serving HTML pages, I think this is no problem.

The new box we are looking at will have 2000 CPW batch...60 interactive.
The discount we are being told is 70 percent off if we purchase IBM's
web-facing configurator. At a 100k purchase, that is severe. Why aren't
more people jumping at this offer? That was the main point of the original
post...any reason to balk at this?

Anyway, thanks again for all the responses. Our community is still the best
IT family on the planet.

-----web400-bounces@xxxxxxxxxxxx wrote: -----


To: web400@xxxxxxxxxxxx
From: "Buck Calabro" <buck.calabro@xxxxxxxxxxxx>
Sent by: web400-bounces@xxxxxxxxxxxx
Date: 05/11/2004 05:00PM
Subject: [WEB400] Re: Web-Facing and 5250 removal

> Web-Facing is simply a process of building/converting
> a Graphical User Interface (GUI) on top of a
> new or existing business application.

The term 'web-facing' and its ilk has been adopted by who knows how
many people as a generic term meaning 'uses a web UI.'  This is all
too often confused with the IBM product called WebFacing which is part
of WDSCi.  It reads the DDS source and creates Java servlets and jsp
pages for deployment on WAS or Tomcat.

JWalk is a screen scraper, which is a process of reading the 5250 data
stream and interpreting the look & feel based on what it sees.
Neither WebFacing nor JWalk change the underlying RPG programs which
make up the application, but at least WebFacing uses industry standard
Java to create its UI.

Why is this important?  With IBM's WebFacing, you can convert your
application once, and re-use the converted components (JSP, servlets,
classes) in your own design.  You've already deployed WAS and Apache
and have literally all the infrastructure you need to add brand new
servlets to the application.

With a screen scraper, you get none of that and you are 'locked in' to
their solution.  You can't incrementally add to your existing deployed
web code base because you haven't got any.  When you want to make a
change, you must go back to the DDS and make your changes there.
Modern screen scrapers all have some way to customise the look of a
screen, which often means that once you've changed the DDS you have to
revisit the 'customiser' and make the GUI panel look good again.

What to choose?  It all boils down to the reason you are contemplating
a web UI.  If you don't want to pay for a leased line and want the new
office in Guatemala to access your app via a browser, you have a
different set of criteria and problems than if you are trying to use
Java because it meshes with the corporate goal of interoperability
with some other vendor's application, which in turn is a different
problem than being an ISV who needs the cachet of a web based product
in order to make sales.

In general, the screen scrapers are very easy to use and deploy, but
they have quirks in their recognition engines which are 'customised'
so the panels look good.  There's often a double maintenance penalty
(DDS and customiser) but since everybody knows DDS already it isn't
seen as that big a deal.  Scrapers often don't need source code, and
handle IBM panels like WRKSPLF.

The re-facing crowd often require source, and often make changes to
it.  Almost invariably, those changes can be reused to enhance the
application in the future.  Because they use source, they don't have
to make a guess about what the panel should look like, and thus have
fewer glitches in the recognition engine.

If your company wants to go to the web in a real way (learn Java,
learn web infrastructure, good change management) then choose one of
the re-facing products (PSC or WebFacing come to mind).  If you aren't
going to invest the effort in becoming web experts, then choose a
scraper (JWalk, Newlook and I think aXes fall into this category.)
 --buck



_______________________________________________
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.