Re: Saving the System i: Fight Rather Than Switch

Tom,

 Without working out the technical and design details, here's what I'd
like to see, as a starting point:  The ability for the system to output
to a browser without any changes to the program!  IOW, the system s/b
smart enough to know that I've got a browser vs. a 5250 device at the
other and of the pipe and output a browser data stream instead of a 5250
data stream.

 Obviously, as time went on, the technical community would be screamng for
extensions and enhancements, but that's a good thing.  Anything that
couldn't be mapped back to a 5250 function would have some sort of
default.

 I shouldn't need to know how to configure a web server or Websphere, etc.
 It should be as easy as doing an EXFMT.  No special thick client objects
to download, other than what's normally allowed in a browser.  That
eliminates screen scrapers.

 Look at the concept, not the strict definition.

 Have you tried to sell an enterprise wide transaction based application
lately (not a utility or admin type of application) - in the last 8 years
or so ?  It's a very tough sell compared to the slick looking
competition, even though it might a lot more / better / more solid
functionality.

 -mark

M Lazarus wrote:

 Having an HTTP server does NOT match my definition of GUI.  I want to
be
able to (at least start to) GUI'ize my applications by using the EXFMT
keyword (maybe w/ some extensions) and not have to have multiple
"threads" within the program whether the client is a browser or green
screen.

Since you separated HTTP server out, isn't EXFMT already doing
precisely what you just asked for to the (GUI) iSeries Access
emulator or even many competitive emulators? That is a "GUI" client;
just because its primary presentation area is rendered as a text
area doesn't disqualify it.

I'm still unclear on what is wanted. iSeries Access for Web? HATS?
VARPG?

When "EXFMT" is used as a basis, it seems to cloud the issue for me.

VARPG has (had?) a feature that would import existing DDS display
files into its GUI designer. The resulting GUI panels could be
pretty ugly if you left them in that initially imported state, but
there was no doubt that they were GUI. The elements could then be
modified in the designer for positioning, allowing user control over
font/color/size, controlling visible/invisible, essentially all of
the bits that make "GUI" GUI.

The programmer couldn't manipulate the resulting GUI panel elements
via EXFMT because that's not an available VARPG op-code. I suspect
that there are a few reasons why it made sense to leave it out of
the language.

I don't know why it couldn't be left in. I guess I just wonder what
the 'display client' would have to look like in order for EXFMT to
work in a predictable fashion if an existing emulator isn't acceptable.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
        253-479-1416
Fax    253-872-7904
http://www.powertech.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.