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

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 future then please respond to the sender to this 
effect.

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