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



<snip>

Maybe I'm wrong but the way I understand it is that RPG IV is the
version
of RPG that supports ILE, but that just by using the coding techniques,
ie. %found, doesn't make it a true ILE program. She agrees that we
should
modernize, but sees no real compelling argument to learning binder
language, activation groups, and all the other ILE specific information
when the code being written already makes use of everything RPG IV has
to
offer except for ILE binding using prototypes. She thinks that simply
separating reusable functions into program objects is enough.

</snip>



I think my point would be that it is impossible to implement reusable
functions using program objects or at least such a nightmare that I
would never want to do it.



Take a simple problem. Where I used to work, we had very complex
pricing. Calculating a price took hundreds of lines of code.



Previously, programmers went in and wrote logic in an order entry
program to calculate the price. Then along came somebody else and need
to have the logic in another program (gee, does this sound familiar?) so
they copied the logic from the order entry to another program and then
somebody else wants it in another programs so programmer copies to
another program. Each version slightly different and, of course,
somebody needs a slight change in logic and weeks of work. Welcome to
the monolith world.



Based on what your boss is suggesting, we create a program and put the
logic in a program in there. There is just one big catch. Programs have
a single point of entry with one set of parameters.



Now when I did the analysis for the problem, I realized I had the
following functions:



1. Get Base Price. Receives Item number.
2. Get Customer Price. Receives customer number, item, effective
date. This function calls Get Base price to get the base price.
3. Get Discount Detail Count. Return count of discount details.
4. Get Discount Detail Record. Returns one record of discount
given.



So know the question arises, how do you implement this using a program?
Each has it own parameters and get Discount Detail gets called once per
discount detail. The only possible way to implement this is using a
program with every parameter on every call and include a flag that says
which function you really want and then switch to the proper function.
Talk about your basic nightmare.



But this is easy to implement in a service program. You simply have 4
procedures and Get Customer price can simply call Get Base Price to get
the base price and you can call Get Discount Details in a loop and
performance is never going to be an issue.



You simply cannot implement reusable logic in programs. You must have
the capability of a service programs and the fact that you have multiple
entrance points (Procedures) and the speed of a procedure to implement.
If you try to break a program down into little small programs each doing
one thing, the overhead would kill you and almost instantly you start
running into problems like above where program b needs to call program a
and results of b need to accessed by d, etc. Trying to do this with
programs is a certified way to insanity. Even if you told someone to do,
in the end they wouldn't. They would go back to putting all the logic in
each program like they used to because it would get so crazy so quick
they couldn't deal with it.



And, of course, using subprocedures even with your program means you can
build black boxes. Known set of inputs and known set of outputs with
it's own set of local variables.



Service programs and modules provide a method to easily build reusable
code. Why not use it? The hard part is the thinking. Learning to
abstract a problem down to more and more abstract code.



Of course, the true is that all this pretty academic. Because most of
the people programming on the AS/400 refuse to change (like your boss
and mine and all the programmers in my shop), the AS/400 is a dead duck.
Companies are simply not going to continue to pay programmers to write
monolith code and pay the cost of maintaining it which is why we see
more and more companies leaving the machine or putting the 400 in the
back room and new development being done on Windows or Unix where people
are willing to use modern programming methods.



Want the proof? Try to find a job doing anything except maintaining old
dead code and most of that is just until the company can get off the
AS/400. I don't know how many companies I have talked to lately that are
planning to dump the AS/400 and they just want somebody to keep the old
stuff running until they can get rid of it and, oh yea, we will bring
you over when we switch. Sure.



The fact that we even have to have these discussions means the AS/400 is
dead. ILE has been available for 13 years (I started using 13 years ago)
and we are having to argue over whether we should be using it.



Such a shame. The finest computer in the world.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.