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.
midrange.com
