Re: RPG - I'm not dead yet!

[john e <whattssonn@xxxxxxxxx>]

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