RE: RPG - I'm not dead yet! -- RPG400-L

John, I think you just made the argument that no one should every use a new language or a new tool/method in an existing language because if they do they are taking the risk that that new language or method will not catch on and there will not be anyone but the original coder who can ever support that application.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of 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.

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