RE: Native GUI (was Saving the System i: Fight Rather Than Switch) -- MIDRANGE-L

Mark,

I think the sticking point is that I don't think 5250 or fat clients are
the way to go if one wants the iSeries to have a modern look & feel,
which is what triggered this whole native GUI discussion.  And
developing for more than one of the three options is by necessity going
to take more resources (time/people/money) than developing for just one.
Anything that takes more resources will reduce profitability unless one
can demonstrate a positive ROI on the additional work.

Really, there's nothing inherently wrong or incorrect about any of the
approaches.  But if it's reasonable to expect a browser to be on the
client and not reasonable to expect consideration to be made for a dumb
tube, emulator, or fat client, then developing for the browser first and
possibly only becomes obvious.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of M Lazarus
Sent: Monday, December 11, 2006 9:37 AM
To: Midrange Systems Technical Discussion
Subject: RE: Native GUI (was Saving the System i: Fight Rather Than
Switch)

John,

 I'm not sure where we disagree.

1) Dumb terminals:  IBM has not (yet) discontinued support for 5250
devices.  That makes it mandatory for even a GUI'ed application to be
able to detect the device type at the other end of the line and generate
the appropriate data stream.  This type of detection is already in place
when using the more advanced DDS keywords, such as mouse support.

2) Browser: This is the most ubiquitous access method to the web and
many applications.  Regardless of client OS, you'll most likely find
decent browsers available.  This is a "must have" option for native GUI
generation.

3) Thick client GUI: There are probably many shops that would forgo the
simplicity of a browser in order to have more control over the look and
feel of the output.  Also, it could probably save some network traffic.


 Support for #1 and #2 are required, #3 would be nice.  What major
obstacles do you see preventing IBM from implementing any of these
options?

 -mark

Mark,

I have to disagree.

To set the stage for my response, here's a little about my employer:
- We're a global company in business since 1783 with offices in 45+ 
countries and in many cases more than one office per country.
- Literally thousands of employees who work in small offices of 2-15 
people.  22K+ employees worldwide.
- Dozens if not hundreds more who work out of their home.
- Lots of clients, but the bulk of them are companies you've heard of.
Banks and other financial services firms, global companies with all 
kinds of product offerings from software to telecomm to restaurants to

consumer goods.
- The production servers (iSeries, Windows, etc.) are not in an 
on-site data center.  There are no 'local' users.
- IT services are a critical part of our offerings to clients.  We 
absolutely have to be able to deliver applications to the above 
entities regardless of where they are located, what they are running, 
and how they connect.

With that said:

1. Dumb terminals are a dead end.  It's way past time to move on.  It 
doesn't matter if they're more reliable, cheaper, more efficient, or 
have other superior traits.  They've lost the battle.  This isn't just

my opinion and I don't say it because terminals don't work for my 
situation; it's the opinion of the market.  Goodbye, Betamax.  For 
those of you who still use dumb tubes, I have to ask in what way do 
they NOT promote the idea of the iSeries being an ugly, old, outdated

system?

Also, there're no reasonable capability to support mobile and 
home-based workers.  Without raising a lot of concerns over security, 
buying a lot of extra equipment, and other things there's no ability 
to deploy access via dumb terminal to customers.

Smart terminals - the ones that connect via Ethernet, run embedded 
Windows/Linux/whatever, and offer native browser support and limited 
app capabilities - do not fall in to the dumb terminal category.

2. There's too much development and support overhead for thick

clients.

It's a constant battle to stay compatible with whatever desktop 
operating systems are popular and to keep working with patches and 
updates to those OSes.  Windows, Mac, and Linux all come in multiple 
flavors and supporting and those flavors tend to vary a lot.  Windows 
is dominant yet Linux is gaining ground and Mac is holding on.  Do you

eat the costs for developing for all of those or do you potentially 
ignore your customers who are Mac shops to save the development effort

of writing a Mac port of the app?  What happens when the next Windows 
service pack comes out?  Vista support?  Windows 95 support?  What 
happens when your app is accidentally declared to be spyware or a 
virus by some well-meaning-but-wrong update to an anti-malware engine?
Because that's what your customers are running, is your help desk 
ready to support every desktop OS with every possible patch 
combination from the last 12 years?  If not, which segment of your 
customer base will move to suppliers who will support them?

3. Much like "the network is the computer", the browser is the client.
Your development efforts are simpler and the end result is far less 
dependent on (although not _independent_ from) the client

architecture.

It is also fairly easily decoupled from the back-end application & 
database engines making n-tier deployments possible if desired.  Web 
server technologies generally make clustering easier, supporting 
horizontal as well as vertical scalability.  And Internet-based 
delivery can take advantage of existing services for things like 
performance boosting ( http://www.netli.com/ ).

The browser advantages get stronger when you want to deploy an app to 
your business partners/client/suppliers/remote workforce.  Encryption 
is handled via SSL; there's no programming and exceptionally little 
administration.  Standard ID/password or stronger multi-factor 
authentication is available.  Tools are readily available to 
automate/script HTTP conversations, making the task of automating 
secure data feeds easier.  And every company will open port 443 to 
your site for application access (try that with your fat client that 
needs ports
4730-4739 and port 2003 open or even worse - port 23 for TN5250).

Also, which architecture will let you deploy to your field workers or 
customers who want to use a cel phone for app access?  Don't laugh; 
thousands of people do it now.  If you're not going to support the 
mobile systems then you are again painting yourself/the iSeries as 
outdated.  PalmOS has Blazer, Opera Mini, and others.  Windows for 
SmartPhones/Pocket PC has some stripped version of IE.  BlackBerries 
and Symbian handhelds have browsers as well.  My PalmOS Treo has EvDO 
connectivity; up to 2Mbps speed to my phone.  I can easily stream 
video, download large email attachments, use it as a DSL-equivalent 
modem for my laptop, run Google Maps ( 
http://www.google.com/gmm/index.html?utm_source=us-et-more&utm_medium=
et &utm_campaign=gmm ), etc.  Why shouldn't I be able to check parts 
inventory or order status while at a client site?

If you write for the browser and you adhere to standards, you will not

have to do that much customizing to run on all of the above browsers.

Sure, browsers have compatibility issues as well, but they aren't 
nearly as difficult to work around as client-based applications are.  
And the whole point is that you are writing code to a single interface

that every employee, remote worker, customer, and supplier is already 
running on every device they own that has some sort of connectivity.  
This simplifies development.  It can also simplify the job of the help

desk which should lead to better employee satisfaction with IT and 
better customer satisfaction with your company.

Dumb terminals are dead.  Fat clients are only good in limited 
situations.  The browser is, at the moment, the only universally 
deployed and universally accepted application interface for delivery 
of host-base computing.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces+john.jones=am.jll.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+john.jones=am.jll.com@xxxxxxxxxxxx] On 
Behalf Of M. Lazarus
Sent: Sunday, December 10, 2006 1:47 PM
To: Midrange Systems Technical Discussion
Subject: RE: Native GUI (was Saving the System i: Fight Rather Than
Switch)

John,

  It needs to be able to detect what client is available and

requested.

Dumb terminal, browser or thick client.

  -mark

At 12/9/06 11:35 AM, you wrote:

GUI Schmooey.  The iSeries doesn't need a native GUI.  What it needs 
is

an integrated, high-performance web application server environment.
The present and future in application delivery is via browsers, not 
fat

clients or remote desktops or shell environments.

GUIs are for workstations.  Seriously, does your employer buy an OS 
for

the applications and user interface or for the administrator's 
convenience?  In a modern system the apps are web-delivered and the 
administrator uses some form of console supplemented by a browser or 
browser-like "console lite".

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Friday, December 08, 2006 10:52 PM
To: Midrange Systems Technical Discussion
Subject: Re: Saving the System i: Fight Rather Than Switch

Loyd.

Good point.  But a point I made a few hours back and buried in the 
activity on this thread is:

Since IBM did such a GREAT job on integrating all these things as you 
have well outlined, why did they NOT integrate the GUI ?  Why do we 
need to even seek alternatives that can (and sometimes have to) run on

other platforms? Had they done so, we wouldn't even be having this 
conversation. Most of us would be thumbing our noses at those poor 
folks who have to piece together a GUI application on Windows, Unix or

Linux.

Think of 5250 and how well it is integrated into the whole system and 
then imagine something that delivered the same basic result but in

HTML.


It'd be cool and perform perhaps better than any alternatives.

The i, as I understood it, was "integration".  IBM failing to 
integrate

a GUI into a System i "breaks" the i (Hmmm, sound like the "rain in 
Spain stays mainly on the plain....").  As I said a while back:

"Give me a native [System i] GUI that I can quickly develop, performs 
better than other technologies and allows me to go where other 
technologies cannot go, and we'll have not only a rockin' box, but a 
rockin' box that sells."

I believe that.

Pete Helgren


lgoodbar@xxxxxxxxxxxxxx wrote:

Even better. The value is in the integrated operating environment, 
as well as in consistency. As Aaron said, integrated security and 
job logging. Add in work management, output management, ease of 
backup and

recovery, the ease of system management, and that built-in database

thing.

Why do people clamor for Apple to unchain OS X from the Macintosh?
The

same reason why people here want to unchain OS/400 \ i5/OS from the

system I platform.

Now ask yourself: why doesn't IBM offer the greatest integrated OS 
and

database separately? The same reason why Apple locks OS X to the 
Mac
hardware: stability and consistency.

Argue all you want about IBM and Apple charging a premium for their

systems, but it is an integrated system. Since you control the 
hardware environment, you can optimize device drivers, the kernel, 
etc. for the environment. Simply, neither the IBM OS or Apple's OS 
X

would work as reliably on generic hardware.

The interactive tax... that another story.

Loyd Goodbar
Senior programmer/analyst
BorgWarner
TS Water Valley
662-473-5713
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx 
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Booth Martin
Sent: Friday, December 08, 2006 14:41
To: Midrange Systems Technical Discussion
Subject: Re: Saving the System i: Fight Rather Than Switch

Is the pricing value of the System i in the hardware, or in the 
consistency of the platform software over decades?

Steve Richter wrote:

On 12/8/06, Trevor Perry <tperry@xxxxxxxxxxxxxxxxxxxxx> wrote:

I expect that 4x faster is just a number you made up. And it was 
not

considering apples to apples.

 this quad core p5 has 4x the CPW of a single core i5:
http://www-03.ibm.com/systems/p/hardware/entry/550/91331efa.html

here is an ITJungle chart showing the i5 to be 2x the price:
http://www.itjungle.com/tfh/tfh110606-story02-fig02.html

you dont have to answer of course, but I would like to know what 
IBM is thinking in terms of pricing of the system i5.  The user 
and

vendor community could build a new GUI that works with green 
screen

apps, but such a thing would likely go nowhere if the base i5 
remains

geared down and over priced.

-Steve



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


This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in the future then please respond to the sender to this effect.