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

Reeve,

Thanks...

Knowwhatchamean...  I never got a chance to try CODE on V4R5, so now I'll
think I'll just wait 'till I get V5R1 installed.  (Probable date: Q2,
2002...;-)

I NEVER got the verify to work, unless it didn't reference any DB files.  I
saw others with same error.  I admit it was probably a set up problem, but
played with settings, re-installed several times, etc.  Now just because it
runs on a PC doesn't mean it should BEHAVE AS A TYPICAL PIECE OF PC CRAP
SOFTWARE, IMNSHO.  It should behave like a piece of rock-solid 400 software.
Work first time, every time...

===> BTW, did you get any results from writing IBM?

I'll take your word, and really work hard on CODE.  I liked the principle.
But I had better luck with Flex/Edit.  It ran...  Never used it much,
because Aldon killed it before I got good enough at it.

RANT(*ON)

That's the thing the folks up in Toronto don't understand, I don't think.
When you know something like the back of your hand, like SEU, AND you can do
it with one hand tied behind your back (and I've had to do that), AND you
have to take the triage approach to self-education...  What you're looking
for is for CODE to have an option for an IDENTICAL look-and-feel as SEU.  I
actually started working on that myself, but got sidetracked...

Before anyone flames me, yes...  I do understand the problem of lack of
resources, not enough time, harder to program a PC, yada, yada, yada...
Same problems I face at work, too...

But I remember a survey on News/400.  SEU had 80% of the market share.  If I
had a market like that, and basically it's a captive market, I would do
ANYTHING to make it easy to get them to convert.  It seems arrogant, to me,
that the designers of CODE at least APPEAR to view that 80% of 400
programmers with disrespect.  To view that massive number of people and
assume that they just have their heads someplace, and can't see the
advantages of CODE.  When, more than likely, it is a combination of that,
and the fact that the product is NOT user-friendly enough.  (By definition,
otherwise this 80% of 400 coder WOULD HAVE SWITCHED, by now.)  The
definition of user-friendly enough IS determined by this 80%, not the folks
up in Toronto, BTW.

RANT(*OFF)

So what we have here is an accounting problem.  CODE may not be a profit
center.  If it was, how much money would it be worth to get 80% x number of
400 programmers using CODE?  Say.. at $100 a pop?  Then the cost of
providing an option for IDENTICAL look-and-feel looks awfully minimal.  In
fact, it seems penny-wise, and pound-foolish, to me anyway, that this hasn't
been done yet.  JMNSHO.


There are many more posts I'd like to get back to, but "the old lady that
lives in a shoe"...  Well, her cupboards are bare...;-)

===> What anyone sees in this Open Source movement...  well, it's simply
beyond me...  Not questioning whether there are ANY advantages, but the
disadvantages far outweigh any percieved advantages, IMV.


jt


"Have a GREAT day...!  And a BETTER ONE TOMORROW~~~:-)" (sm)


> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Reeve Fritchman
> Sent: Wednesday, November 14, 2001 1:11 AM
> To: midrange-l@midrange.com
> Subject: RE: Green screen - it's time is over/CODE/400
>
>
> Well, it depends upon what your very special error is!  I had problems too
> (/COPY statements) but Violaine isolated it to a problem with the real
> compiler code and some of the "H" options.  Of course, a first-time verify
> is slower than a 170 with a cranked-down CFINT and the cache function is
> crude (it's not smart enough to know what source member/files
> have changed).
>
> I don't have time for troubleshooting either; hell, I don't have time for
> anything productive now that I'm reading your posts!  I was fired by the
> Farr-Coulthard show at the Rochester March pre-announcement meeting; came
> back; tried to get the damn thing to work; and ended up writing a
> letter to
> the iSeries High Commander questioning the Group's commitment to AD tools.
> But CODE/400 is one of those times when effort and persistence is worth it
> and I think the Toronto group is doing the best they can, given
> the lukewarm
> support of the iSeries management group.  Of course, CODE/400
> means nothing
> to the rest of IBM because it's not Linux...
>
> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On
> Behalf Of jt
> Sent: Tuesday, November 13, 2001 11:38 PM
> To: midrange-l@midrange.com
> Subject: RE: Green screen - it's time is over/CODE/400
>
> Reeve,
>
> You got VERIFY to work...?!?  I watched post after post on the IBM
> newsgroup.  People all had the same exact error as I got, on the
> same exact
> line.  This went on for months.  Never was resolved.  This was
> around Feb to
> May of this year.
>
> I'd try it every now and then with the same result.  I don't have
> that kind
> of time.  Since that was the main feature I was looking for, I
> gave up.  And
> I don't generally give up easy.
>
> (I should say it was GREATLY improved on when I looked at it in
> years past,
> but...) I want to put my time into learning how to make best use
> of a tool,
> not figuring out how to make it work.  Maybe some places have dedicated
> staff for that kind of troubleshooting.  I don't.
>
> jt
>
> "Have a GREAT day...!  And a BETTER ONE TOMORROW~~~:-)" (sm)
>
>
> > -----Original Message-----
> > From: midrange-l-admin@midrange.com
> > [mailto:midrange-l-admin@midrange.com]On Behalf Of Reeve Fritchman
> > Sent: Tuesday, November 13, 2001 11:19 PM
> > To: midrange-l@midrange.com
> > Subject: RE: Green screen - it's time is over/CODE/400
> >
> >
> > 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.
> >
> > _______________________________________________
> > 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.
>