× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I've been following this thread with significant interest and irritation. 
Devoting any more time and resources to enhancing OPM RPG is like putting
lipstick on a pig.

Scott sez:
>One of the things I constantly hear from programmers is that their boss
>will not let them convert from III to IV because "it will cost money".  In
>other words there is no perceived cost in staying where they are.
>
>There's a big cost to upgrading to RPG IV. You have to pay for training,
>you have to pay programmers for their time in making the conversion from
>RPG III to RPG IV, and for the time they spend testing.
>
>I think it's important to realize that it's the users and the customers
>who drive IT budgets.  How much money is spent on programming almost
>always depends on what the USER is going to get in return, NOT what the
>programmer is going to get.

I'd add that I've worked at at least nine different AS/400 shops since the
introduction of ILE RPG.  With the exception of one shop, none of the shops
have gone any futher than running the source code through the OPM->ILE
converter, if they bothered to convert to ILE at all.  There wasn't any
percieved cost-benefit for the migration.

At a recent gig, my team and I designed and wrote a series of ILE-based
extensions at the client's request.  The extensions were programs and service
programs that encapsulated their business rules in easy-to-use functions.  The
result was that the new functions *did* decrease the turnaround time for
delivering finished applications.  However, it took nearly six months to
propagate these changes through the minds of managers and programmers at the
client site.  

In other words, my team wrote a lot of neat stuff at the client's behest, but
the programmers couldn't be bothered to use the stuff we'd written.  They
already had an architecture and a development scheme that worked.  It wasn't
until I sat down and showed three of their top people that if they used the
stuff my team had written, they'd get more bang for their buck.  Essentially, I
had to rub their noses in it before they began to use the stuff.  Shortly
thereafter, they started writing their own extensions and the thing took off. 
But the animosity between old and new still makes me wonder if it was worth it.

>If the RPG IV screens are identical to the RPG III screens -- the users
>haven't gained anything.

The only time this isn't true is when you gain a significant increase in
performance. 

>This is what I was trying to say in the last message -- there needs to be
>an INCENTIVE.  There's got to be some advantage to the user or to the
>customer in order for the change to make sense.

This is dead on.  IBM's OPM to ILE migration path BITES because it's driven by
technology, not by function.  Naturally, the majority of AS/400 programmers
want to move to the new stuff.  It's important to keep yourself active and
vital, even on an isolated island like the AS/400.  However, since, as Scott
points out, the end user sees exactly the same thing in the end... why bother?

One of the biggest complaints I've heard from programmers over the course of
the last few years is that a refusal to move to ILE signifies that management
do not care for the AS/400 platform or for the programmers using the AS/400
platform.  

It's a tenuous leap of logic, but if you're a programmer who's been supported
and trained to learn OPM RPG or COBOL, and then suddenly are strongly
discouraged to enhance your skillset by learning new techology, it's difficult
not to be suspicious. And managers aren't stupid, they can suss out bad
feelings quickly.  One person said to me that his decision not to migrate to
ILE gave him the impression that "you're with us or against us" from the
programmers, and he was definitely on the "against" side.

>Make it easy for the programmers to give the users what they want...
>modern GUI interfaces instead of 5250, spreadsheets or PDF documents
>instead of green bar reports.  Make it rich, fast, and powerful without
>making it inordinately complicated.

I agree.  But now we've got a problem here-- where do the tools come from? 
We're talking about IBM.  Some neat goodies have come out of IBM (JTOpen, PASE,
the Eclipse framework...), but I can't think of any really good IBM-supplied
AS/400 tools that help create high-quality software that will excite users. 
WebSphere doesn't count because it's an IDE; it doesn't help the design
process.  No user gets excited about Java code in stacked tab dialogs.

Also, programming in the ILE paradigm is clunky!  Don't get me wrong-- for me,
ILE RPG beats OPM RPG hands down... but for God's sake, couldn't someone come
up with a better build tool than TMKMAKE?  That sort of Unix-y stuff just puts
off AS/400 people. (I finally had to come up with a clumsy manufacturing
header/detail bill-of-materials analogy in order to explain the concept of
TMKMAKE to a programmer at a previous gig.)

Eh... rip away.  I'm off the soapbox now.  

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.