RE: Green screen - it's time is over/CODE/400 -- MIDRANGE-L

I'm hardly an apologist for CODE/400, Al, but there are definitely
circumstances where CODE/400 shines when compared to SEU.  SEU is still the
hands-down winner for quick changes.  CODE/400, on the other hand, allows
multiple windows open simultaneously, VERIFY, the ability to insert errors
into your active source, the ring manager (groups of source members) and
>>23 lines.

I have a source member naming convention and have developed several dozen
utilities to manage and work with source.  Those tools and PDM offer some
functions, but when you have to do a lot of work on a single member,
CODE/400 works well.

When it's behaving, it's great.  But the communications interface,
particularly on non-LAN connections, is not very reliable.

-----Original Message-----
From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On
Behalf Of barsa@barsaconsulting.com
Sent: Tuesday, November 13, 2001 9:11 PM
To: midrange-l@midrange.com
Subject: RE: Green screen - it's time is over


I don't think that green screen is really over.

I have a client in the arbitrage business.  They had historically used an
application to generate printed reports on the "stuff" that they were
trading on an AS/400 620, with legacy applications written on COBOL.

They decided that to get a faster turn around (i.e.: increase profit), they
had to scrap the AS/400 application, and get a new application where the
data was presented interactively to the user, and the user made trades
interactively, with dramatically less turn around time.

They decided to start with a clean slate and assume that the 400 was dead.
They looked all around the industry for the most programmer productive
platform for interactive custom programming and fast and easy of numerical
data entry.  What did they find?  The AS/400 green screen!!  Surprise,
surprise.

They don't care about sex appeal, all they care about is money. The 400 was
selected as the least expensive platform to do the new development (even
when you exclude the benefit of their existing expertise), the 400 green
screen was 7 to 10 times less expensive to develop for than any other
platform.  They further determined that 5250 architecture "dumb"
workstations were the fastest mode of data entry, and as speed/time is
money, that's what they picked.

Cost to develop the new applications (pure program development):  $1M.
ROI                                           4 days.

Yes, they had to upgrade the 620 CPW (110 approximately) to a 720 with 560
CPW interactive and 2000 CPW batch, but who the @#$% cares, when the ROI
was 4 days.  OK, add another $500K for new hardware, so the ROI is now out
to a ridiculous 6 days.

Is the customer willing to be used as a reference account, no-way-Jose.
The 400 is a competitive advantage.

The 400 lives, green screen lives, and profit is a good thing.

BTW, I have two displays on my desk, a 3489 and a PC.  I literally never
use the PC for green screen data entry or SEU.  I've tried, but failed to
get into CODE/400, primarily because I cannot get over the apparent
productivity hump that PDM provides.

Al - on the way back from Rochester

Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com






                    "Walden H.
                    Leverich"                 To:
"'midrange-l@midrange.com'" <midrange-l@midrange.com>
                    <WaldenL@TechSoftIn       cc:
                    c.com>                    Subject:     RE: Green
screen - it's time is over
                    Sent by:
                    midrange-l-admin@mi
                    drange.com


                    11/13/01 10:36 AM
                    Please respond to
                    midrange-l






Joe,

With regard to your complaints against ODBC, can you be more specific? Are
you referring to client side code that actually updates the database (SQL
UPDATE, DELETE, INSERT) or would you include using ODBC to call stored
procedures on the AS/400?

I'll agree that I don't want my client side code (be it JSP, ASP, VB,
Powerbuilder, Java, whatever) making direct updates into my database, but I
don't see a problem using ODBC to call stored procedures. Use ODBC to call
stored procedures (especially through ADO) is relatively simple. Case in
point, I have an ASP-programmer in my office now calling stored procedures
on an AS/400. He wouldn't know an AS/400 if it fell on him. I say "call
this
sp" and he codes up the necessary ASP code. I could replace that AS/400
with
a SQL Server box and his code would never know the difference.

-Walden

PS. Actually, ODBC is dead. OLE/DB is the new replacement. However, I see
them used interchangeably.

------------
Walden H Leverich III
President
Tech Software
(516)627-3800 x11
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Tuesday, November 13, 2001 12:41 AM
To: midrange-l@midrange.com
Subject: Green screen - it's time is over


Man, I thought I was long winded.  The same arguments have been being
repeated over and over here, to what avail I'm not sure.  But I thought I'd
try to recap a couple of the salient points, and then try to make something
constructive.

1. IBM did not one day say, "Let's charge extra for interactive!"  The
price
per CPW has been dropping for both interactive and batch machines.  It's
just that the batch machines are dropping much, much faster.  I don't know
IBM's philosophy, nor does anyone on this list, but I have a feeling it has
something to do with trying to get as much revenue as possible from the
green screen while at the same time moving away from it.  Which brings me
to...

2. Green screen is going away.  The old 5250 interactive feature, which
made
the AS/400 pretty much unique among the midrange world, is gone.  Dead.
Kaput.  You can still try to hang on to the old architecture, but it will
cost you.  That's the reality, no matter how much wailing and gnashing of
teeth happens here.  If you think you can change it, I suggest you get
together a coalition of people and talk to IBM.  Constantly rehashing the
argument here isn't going to do anything to change the reality of the
current situation.

And that's what I want to focus on for a moment.

The truth is that the AS/400, now spelled iSeries, is still the best
business platform available.  But its uniqueness no longer resides in that
wonderful integrated 24x80 window that we grew up with.  Instead, it lies
in
the ability to write powerful applications in languages with tight
integration to its incredible database.  Personally, I think IBM's
direction
of pushing everything to SQL is ludicrous, but it is silly for me to whine
about SQL.  Instead, I need to embrace it as best I can and work it into a
realistic development environment.

What I can do is to try to stop the proliferation of a couple of bad
elements:

ODBC.  Plain and simple, ODBC is a horrid idea for anything but the
occasional data mining application.  If you need to update data, do it
through servers.  In fact, learn to love the concept of tiered designs, and
build your applications accordingly.  It won't cost you a lot, and once you
have, it will be wonderful.  It sure beats SQL, which I have shown
repeatedly to be far inferior in performance to record-level access for any
transaction-based updates.

J2EE.  Enterprise Java Beans simply have little place in most applications.
The overhead is excessive, and a standard way of defining business objects
and the methods that update them simply hasn't been developed yet.  Until
that time, EJB is simply extra overhead.

If we avoid these two things, the iSeries, especially in its server
incarnation, beats any other machine out there hands down in total cost of
ownership, and in reliability and scalability.  If we join together to
develop some standard interfaces that allow data and programs on the
iSeries
to be incorporated into general n-tier distributed applications, then the
iSeries will easily take on all comers.

Or, we can continue to bemoan the loss of our beloved green screen.  We can
reminisce wistfully about nickel soda pops and drive-in theaters, while the
world zips on by with Internet enabled applications running on Microsoft
IIS
talking to whatever database server currently isn't crashing or locking up.
We can get used to unreliable systems and long delays while "indexes are
rebuilt" or "servers are synchronized".  We can twiddle our thumbs and
remember the good old days as yet another mission critical system succumbs
to some hacker's latest love child.

It's up to us.  The future is here, and in the future I see, the iSeries
has
a huge part.  But it's not going to be as just another ODBC server - it's
going to be as the central business logic processor of my networked
applications.  I may have Microsoft, I may have Linux - in fact I may have
many of those boxes, since I'll need failover for the toy operating systems
that run the Flash presentations that smooth-talking dot-com consultants
sell to management.  But when push comes to shove, my mission critical
systems are going to be written in RPG, run on DB2, and talk to the world
through secure messaging.

You with me?  If so, quit worrying about the demise of the green screen.
It's already happened, but we just haven't admitted it yet.  Right or
wrong,
the brave new world is upon us, and it's up to us to bring our platform
into
it.  And if we do... if we do, we'll have not only the best damned server
on
the market, but a whole new architecture that may just roll back some of
the
tide of bloatware that has tainted our industry and our profession ever
since the first release of Windows.

No, I may never write an entire operating system in 32KB again, but I can
fight to make sure that business rules aren't written in SQL and databases
aren't updated by Java Beans.  At least for a little while.  And that isn't
just tilting at windmills, I don't think.

Joe Pluta
www.plutabrothers.com

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.