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



John,

I am one of the developers you lumped in the "Every developer on the AS/400". I now more than RPG. I have programmed in Java and Visual basic, along with RPG. I take advantage of all the APIs/Service programs from "other" languages in my RPG programs. For example, I use HSSF POI to create and read Excel spreadsheets from RPG programs. So, your categorization of every AS/400 developer only knowing RPG is incorrect and shows how out of touch your are in certain perspectives.

That being said, I think this thread has gone on long enough and agree with a previous post stating that this has become nothing more than a urination contest.

-----Original Message----- From: john e
Sent: Wednesday, July 13, 2011 12:11 PM
To: RPG programming on the IBM i / System i
Subject: Re: RPG - I'm not dead yet!

and that should be a specialty within RPG programmers.
You're right it's not a specialty with RPG programmers (did i say that?),
it's human behavior yes.

But, having grown up with C (an "old" language) exposes one to more software
concepts (like local variables) than RPG.
Also, RPG/DDS/PDM etc is the same everywere, for the last 30 years.
The AS/400 environment is stable, doesn't change and no influences from
outside.
Every developer on AS/400 only knows RPG because that is the platform's
"only" language.
And most RPG developer only know other RPG devs, mostly.
So the AS/400 world is (like Mihael already said) is it's own little world,
with not much exposure to other techniques etc.

can a programmer make a financial system
without having the basic knowledge of the business rules in bookkeeping
and
the need for daily, weekly, monthly reporting etc.? IMO no!
No, he can't. Can he do it without technical knowledge. Yes!
Thats the problem. Anybody can grab a tool and produce some working
software.
And anybody does it, apparantly.
But i would not buy this software (because i have the technical background
to know it gives me problems later).
Why??
An example.
There is something like WinRPG.
An RPG programmer builds a windows program, in RPG!!
So it works. The customer is happy.
Then, in two years, while the customer is dependent on that software, he
needs a change.
IF he finds the original RPG programmer who built it he will be fine.
BUT if he doesn't, he will have a big problem because almost nobody can
support it, maybe even a regular RPG programmer.
So, was it a good business decision to build it with "the best business
language in the world"?
Or would the customer be better off when it was build with VB e.g.
It depends.
However, software almost always changes.
Software which does not change, is not used.
As a developer, i can learn enough about bookkeeping in two weeks to
implement such a thing.
As a bookkeeper, i can learn some programming in two weeks.
I would choose the former, that is (IMO) a better "business" solution.


IBM has tried to make such am OO influenced java based ERP system (San
So... what has this to do with this discussion.
I'm not saying everyone should do OO.
San Franscisco evolved into J2EE, so there is some "success".
However, the complexity of J2EE has nothing to do with OO or whatever but
everything with IBM, M$, etc.
It's making software as complex as possible, trying to "lock-in" the
customer.
And then selling tools to "help" with that.
Also good business, for IBM.

The simplicity of AS/400, and RPG in a way, is a good thing.


With "costs" i solely mean the man hours spent writing, analyzing, and
changing code.
Not transaction costs.

graphical mouse driven UI is
I never said anything about that.
This is stupid.

Of course, a UI for a business system must be keyboard oriented.
Has nothing to do with 5250 VS GUI.
But if you think that wrestling with subfiles and indicators is cost
effective, well go ahead!












On Wed, Jul 13, 2011 at 5:18 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

John,



What you are trying to say is that RPG programmers haven’t really developed
with the language and that should be a specialty within RPG programmers.



It’s not, its common human behavior, if start out using a shovel, you stick
to the shovel, even though you have a Catapillar to your disposal. My
sister
is a psychologist specializing in work routines and the implementation of
LEAN. I quote her "It's not hard to learn the rules for LEAN, but it is in
practice extremely difficult to implement LEAN"



Regardless of what platform we're talking about code is not rewritten just
because there is a new way of doing things. I doubt that more than 1% of MS
programmers even use Silverlight and is modernizing all previous code to
the
new browser-based standards or even implementing SOA and MVC.



Yes, as Joe states, many RPG programmers comes with a business background,
but who is better to design a system than people that understands what the
system should do or in other words can a programmer make a financial system
without having the basic knowledge of the business rules in bookkeeping and
the need for daily, weekly, monthly reporting etc.? IMO no!



IBM has tried to make such am OO influenced java based ERP system (San
Francisco) back in the late 1990s – it failed due to lack of performance
and
a fare to complex structure. Ask yourself the question “compared with
what?”



Cost, how do you measure cost? I have a friend that is CTO in a
multinational company with companies in 80 countries and a lot of different
ERP systems. His analysis clearly says that among these companies the best
performers in making money is those who runs legacy systems (many on IBM I)
and the worst performers is those that runs SAP. Cost can’t be isolated
into a single entity. You argue for graphical UI’s but if 5250 brings down
cost for a transaction so you save 50% of employees in your order entry
department I would argue that a graphical mouse driven UI isn’t the right
tool for the job.



People tends to forget that an ERP system is a Business Machine and like
any
other machine in the company its cost isn’t not only the initial investment
and the cost of the people that maintain it, but also the cost of the
people
that uses it – the more people needed to do the job, the greater cost.



In any company that has a production line you will find specialist that
constantly measures time and try to use LEAN technics to improve production
time to save money. If you apply the same techniques on an ERP system, from
construction of programs, maintaining the system to the efficiency of using
the system – you will have a quite different scenario of TCO or rather TCOT
(Total Cost Of Transaction) in other words, what is the total
administration
cost from an order enters the organization to the money is in the bank and
the transaction is completed – very few knows that.



Can you bring cost down, yes you can, but you will maybe be amazed that
most
tools doesn’t, and WYSIWYG tools are the worst because in most cases the
just create monolithic skeleton programs in many languages and creates
undocumented entities of the same data that resides elsewhere in the system
meaning not necessarily redundancy in data but redundancy in the metadata
that describes the data or rather worse differences in the description.



1000 descriptions of a “customer number”, whether it's in a database, a DDS
or an UI, is 999 to many. Worse if the descriptions aren’t the same. And
data has no value without a description or else please describe what this
data is about … 8362 ;-) (Don’t bother I give you the metadata – it’s the
four last digits in a credit card number, but could be anything else)



Cost is many things and I will try to give you another perspective. In the
start of AS/400 I made a financial system that has been installed in about
100 installations. With every sale there was/is a “Software Maintenance
Contract” with a fixed yearly payment.



Because it ran in many different scenarios the number of customer specific
changes grew making huge cut in revenue to maintain them.



In order to solve that problem I analyzed the changes done (typical by
copying a “standard” program to a customer specific library and then change
it) and found that most changes were done in the UI so customers didn’t
have
to have fields displayed that didn’t concern them.



Most customers aren’t concerned in extra fields in the DB that they don’t
use. If the fields in the DB is organized well they live happily with a
“subscription number” in their financial transaction even though the make
cars and doesn’t use it.



As a comment (The problem here with SQL is that it just add a column to the
table – I would like to use SQL to define my databases – but in a change
management point of view it sucks because you can’t insert a row in the
middle of a table so you end up with rows in the table that has no logical
horizontal dependency of each other – CGHPF can do it – you are able to add
ad ADRESS5 field as an extension of ADRESS4 field – or am I wrong?)



The problem was in the UI, I had to find somehow to hide special fields and
special functionality in order to build it in and thereby remove it from
the
customized library – so I constructed a way to customize 5250 screens and
implemented it and rewrote most of the programs – and the number of objects
in the customers own LIB went down from 30% to less that 1% - and the time
to implement a new version vent down from weeks to approx. 3 hours.



My bottom line is here that a well-organized table is much more
user-friendly that a non-organized and a well-organized DB is faster for
even a programmer to use than just a DB that consist of data that has been
added to the end during it existence.

On Wed, Jul 13, 2011 at 5:03 PM, <Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx>
wrote:

> I hate to chime in on this because of the "peeing match"...but
> Even only knowing RPG you can create modular programs so you're point is
> totally moot...
>
> Not all RPG folks love monolithic programs, and yes they can be written
in
> any language. You're trying to make a point that doesn't exist...
>
>
>
>
> From: john e <whattssonn@xxxxxxxxx>
> To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx
>
> Date: 07/13/2011 09:58 AM
> Subject: Re: RPG - I'm not dead yet!
> Sent by: rpg400-l-bounces@xxxxxxxxxxxx
>
>
>
> A concrete example.
>
> I am now working for a company where i build a new order system.
> I use RPGIV for this, and a layered (MVC) architecture (big word but
> alas).
> Green screen programs just have UI handling, nothing else.
> Business logic is in its own service program, etc.
>
> I am happy i'm "allowed" to set it up this way.
> Normally, it is even difficult to just introduce a service program with
> some
> utility procedures in it.
> Let alone an "MVC" approach.
>
> The reason i am allowed is because this customer has a more technical C
> background.
> And doesn't like RPGIII that much, especially the monolithic programs.
>
> So because the customer has a C background, i can set up a sane
> architecture.
> This really is an exception.
> Most of the time the customer knows RPG, and only RPG, and thus....
>
> Isn't that strange.
> A "technical" person likes it modularized.
> A "business" person (the ones knowing RPG and are fine with it) likes it
> monolithic.
>
> Apparantly the monolithic approach is more "business" like.
>
>
> On Wed, Jul 13, 2011 at 3:08 PM, Schmidt, Mihael
> <Mihael.Schmidt@xxxxxxxxxxx
> > wrote:
>
> > <quote>
> > Besides, if you are a programmer you are a TECHNICAL person first,
> business
> > second.
> > Yes, second.
> > Thats your job, computers, programming, yes?
> > Thats technical, first.
> > </quote>
> > IMO that is a fact that every programmer working on an IBM i platform
> > should be able to agree on.
> >
> > <quote>
> > We have enough business types making excel macros.
> > Then we have business types making RPG programs.
> > Thats why we have a big mess.
> > </quote>
> > That is the sad reality I have lived through the last couple of years.
> >
> > My 2 cents
> >
> > Mihael
> > --
> > This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> >
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>



--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.