RE: Free OS/400

["jt" <jt@xxxxxx>]

Interesting thread.

IMHO, the iNation has a lot more to do with the future success of the
iSeries than a lot of people want to believe.

I was told that one of the difficulties getting the iNation approved by the
Server Group is exactly what a lot of people have said here.  There is a
huge movement within IBM, starting with Mr. Palmisano (who BTW runs the
day-to-day operations, not Mr. Gerstner).  That movement believes that
hardware will become a commodity, software will be free, and IBM will make
their shareholders happy by making a killing on services.  Mr. Palimisano
has been in the 400 Division, but he was in charge of the Global Services
Group, before he took over the reins as COO.  He made it a "star" and that
has done a lot for his "stellar" rise towards the top of IBM.  Mr. Gerstner
recently identified him as the "emerging leader" to take over for him as
CEO, when he retires soon.

So I was told, in effect, that the iSeries is an island within the "Deep
Blue" sea of openness.  The iSeries is the only all-IBM solution that IBM
offers.  You'd think that would be considered a huge advantage to the
iSeries, but evidently it isn't an advantage, at all, in some people's eyes.

(And when you're talking about IBM's strategy, the first thing you have to
start with the idea that there is ***no one single strategy***, though they
might try to present it as if there was.)

The key, to me anyway, is that the iNation _did_ get approved, and it does
exist (even if, at times, it seems to exist in name only).  Given the state
of affairs within IBM, that seems pretty huge to me.

The other thing I wonder about is what Don was asking a while back:  what's
up with this "OS/4I"?  I'd have no way of knowing, but I wonder if is
related to Power4.  The next generation iSeries chip (which I guess the
pSeries is already using).  If so, that could be important, because IBM's
invested tons creating the Power4.  It would be good for OS/400 to be
intimately tied to the Power4, but maybe that's just wishful thinking.


As far as your particular post below, Joe:  yep, yep, yep, and more
yep...:-)

But on the theory you have to crawl before you walk before you run:  I hope
we can at least start prototyping some solutions to the 5250 problem, prior
to trying to finalize any standardized application definition language.
IMHO, the experience gained would be an invaluable lesson, and would help in
flushing out an ADL.  Plus, I think your talking about major league support
issues if you want programmers (and their employers) to buy into this ADL.
IMHO, the resources to do this kind of operation would/will be a lot easier
to come by if there was some demonstrable success in tackling the 5250
problem.

But your idea sure has interesting prospects, and I'd sure be more
interested in committing to a project like this (if time and circumstances
down the road allow).


Thanks, all.

jt



-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of Joe Pluta
Sent: Friday, June 29, 2001 1:10 PM
To: MIDRANGE-L@midrange.com
Subject: RE: Free OS/400


> It would be neat if someone were providing an integrated client and server
GUI environment.  No one really is yet.

And this, folks, would be the REAL plum of an open source type of project.
Not the little quibbles about whether e-RPG or HTTP or data queues is the
way to support a GUI.  Heck, you should be able to CHOOSE which one of those
you want.  Instead, we should be developing an "application definition
language" that allows us to dynamically design an n-tier application without
worrying about the plumbing details.

<APPLICATION name="OrderStatusInquiry">

<PANEL name="CustomerPanel">
  <FIELD name="customer" prompt="Customer number"/>
  <ACTION choice=03 prompt="exit">
</PANEL>

<TRANSACTION name=getStatusForCustomer>
  <REQUEST>
    <FIELD name="customer" validate="Lookup(CUSTFILE)"/>
  </REQUEST>
  <RESPONSE>
    <SET maxOccurence=20>
      <FIELD name="orderNumber" drillable sortable/>
      <FIELD name="orderDate" sortable edit=*date/>
      <FIELD name="status"/>
    </SET>
  <RESPONSE>
</TRANSACTION>

<PANEL name="OrderPanel">
  <TABLE>
    <FIELD option heading="opt">
    <FIELD name="orderNumber" heading="Order" drillable sortable/>
    <FIELD name="orderDate" heading="Date" sortable edit=*date/>
    <FIELD name="status" heading="status"/>
    <OPTION choice=02 panel="OrderEdit" parms="customer, orderNumber">
    <OPTION choice=03 panel="OrderCopy" parms="customer, orderNumber">
  </TABLE>
  <ACTION choice=03 prompt="exit">
</PANEL>

</APPLICATION>

How the rest of the panel is fleshed out it is sort of inconsequential.  You
could have a corporate standard that does most of the work, or on the other
end of the spectrum you could feed the definitions into a WYSIWYG editor
that you can then use to finish off the UI design.  Or you could have a
combination of both, a skeleton with the ability to pretty up the
presentation.

The server side would be similar.  You could have a corporate standard that
generates RPG code, or COBOL code, or even SQL stored procedures.  The end
result is not the hard part; the hard part is a standardized definition that
we can then use regardless of the architectural design we choose.

This, to my mind, is the direction we need to start thinking.  Rather than
spending a whole lot of time on which GUI is the best, I think we need to
really decide what we want our next generation of application development
tools to look like.  And some fancy GUI designer with a bunch of SQL wizards
is not the way to go.

IMHO.

Joe


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---