"Real ILE" ( tangent from RPGIII compiler vs. Visual Basic) -- MIDRANGE-L

>> The solution? Smart people should make more babies. But then you
>> wouldn't have time to do all that programming, would you ?
>> Just my two cents.
>> Greg Fleming

Boy, don't I try but resistance is incredible. 

I'm like you Greg. I have no formal training in programming. Just learned on my 
own. My only advantage (disadvantage) was that I have a bad short term memory 
and I cannot keep twenty things in my head at the same time so I had to develop 
the concepts of structured programming in order to keep track of what I was 
doing. In other words, I had to learn to do functional decomposition to keep 
track of things. Break things down into small pieces. Have each piece do one 
thing. When ILE and RPG IV came along, it was just natural. The first time I 
started to play with RPG IV and procedures, I really thought I had died and 
gone to heaven. Finally a real programming environment where I can do real 
software engineering. 

The trick to ILE RPG is not the syntax of the language itself or even ILE 
environment. The trick is understanding the concept of software engineering 
itself and those are taught everyway. The basic principles have been around 
since the early 70's. The trick is to train your mind so that each time you see 
a problem, you begin to break it down into small and smaller pieces. The 
process is called abstraction. 

Each time that you break a problem down, it gets more abstract. The trick is, 
when does the cost of greater abstraction outweigh what you are gaining.

A simple example. I hope I am not insulting anybody here.  

You need to write data to the IFS, say a file formatted for Excel that you want 
the user to be able to get from Netserver.

Your first thought is to just write an AS/400 table and then use a CPYTOIMPF or 
something like it but now you have to deal with all the issues of copying an 
AS/400 table to a byte stream file so my first thought is "Wouldn't it be 
easier if I could just write the data to the IFS directly". First level of 
abstraction.

So you do some research and you discover that you can write directly to the IFS 
using Unix API's so you find some code and insert it in your program to write 
to the IFS but before that happens, you realize that you can break this code 
down and hide how it works in a subprocedure. You can do information hiding. 
You simply build a string and call a procedure to Write to the IFS. How does it 
work. You don't really care. It just works and you can test it independently. 
It has a known set of inputs and a known set of outputs and can be described 
without the use of conjunctive verbs (AND OR). You are now at second level of 
abstraction.

But, at the point, naturally your mind should say, "Wait a minute. I am going 
to use this over and over. Maybe I should take this set of procedures (Open, 
Write, Read, Close) and put into a separate module and every time I need to use 
them, I can just bind in the module." The next level of abstraction. 

Of course, the next level of abstraction is it occurs to you that it would be 
better to put this stuff into a general purpose library where everyone can use 
it and where you can make changes to the code or add new procedures without 
effecting the programs that are using it. A service program.  So you take the 
module you created and bind it into a service program. At this level you 
probably cannot abstract any further, at least, in not in ILE RPG. 

In an object oriented language, the whole concept of the file is abstracted 
away. It is just a byte stream. How you write to a file is the same as how you 
write to a socket is the same as how you write to an XML file. You tell it you 
want to write to a file and it handles how that is done. 

The whole point here is that at each level, things are more abstract. At the 
first level, you are doing something very specific. Creating a table for one 
problem and issues a CPYTOIMPF for that specific file. 

The second level has you write directly to IFS but the code is imbedded in your 
program. (Monolith programming). Again very specific to the problem you are 
working on. 

Third level is more abstract because you have to think about how these routines 
will work without specific code. For example, on OPEN, how do you pass how to 
open. 

At each level, you have to think about all this.

Won't go any further. My point here is this process can be applied to any 
problem and is just basic software engineering. Most people never get past the 
monolith stage. 

When you get done, you have a high level decision maker and a series of 
subprocedures each doing one thing and as you work, you start putting more and 
more common logic in a service program so the programs really just become 
drivers calling the logic in a service program. 

For example, quantity on hand. Why put the calculation in every program? Wait a 
minute, there are other inventory calculation! Why not put them together! You 
break down and break down, always with the idea of hiding information. How 
something is done can be hidden away and if you need to change it, you can. 

Look for discussions of information hiding. Everything is really about hiding 
information. Look for books on the subject. 

Other posts have mentioned that the new paradigm is ILE, not RPG but I would 
probably disagree with that. ILE is part of the new paradigm but the real core 
is procedures being added to RPG. C has always had them. Cobol sort of has them 
but the real revolution was RPG IV and the ability to use procedures. Suddenly 
everyone can do software engineering instead of trying to learn a language like 
"C" designed to write operating systems.  

Procedures and ILE allow us to, for the first time really, to implement 
software engineering principles on the AS/400. Procedures allow us to build 
black boxes. To do information hiding. Add service programs (Libraries of 
procedures) and we have a real revolution.

I guess the bottom line of this long post is, study software engineering 
principles. If you start applying those principles, the language and the syntax 
just begin to make sense. Why you would need to use a module. Why use a service 
program. How to use a subprocedure. How to write a subprocedure all come from 
applying the principles. It just makes sense. 

Without understanding concepts, it all makes no sense.