RE: Advantages of Service program

Here we go long winded again. Replying by number.

1. The solution is design. Breaking the problem down to small pieces. If a 
function does one thing and one thing only, changes that you make are likely to 
be changes that you need to make. If you have a function(procedure) that 
calculates inventory turns, you are not likely to need to change it unless you 
change how inventory turns are calculated and if you change it you are likely 
to be either fixing an existing bug or changing how the calculation is done and 
anybody who uses that function would need to have the corrected function. 

If you need to calculate inventory turns in two or more different ways, then 
they are not the same function. So the question becomes, why do I have two 
different ways to calculate inventory turns? Maybe I need to break the problem 
further, or I need two functions. One to calculate turns using the Green method 
and to calculate using the Blue method and an internal function that does the 
actual calculations with a parameter that controls how the calculation is done. 
Etc, etc. 

If the function does more than one thing (The rule I use is that I have to be 
able to describe what a function does without the use of conjunctive verbs (and 
or)), then I could end up with a situation where changing part of the function 
could screw up something else. Poor design. 

2. The problem with programs is simple. Programs only have one entrance point 
and that is the *ENTRY point. Think about the IFS problem. You need a function 
that writes to the IFS in text and one in binary. You need a function that 
reads from the IFS in text and binary and you need function that checks to see 
if a directory exists. How do you code that with one entrance point. Each one 
has different parameters. You could try different programs but then what 
happens with common logic? It rapidly disintegrates into a mess. That why when 
I look at most calls to programs used for functions, I see huge monolith 
programs doing sometimes hundreds of functions. 

Service program allow multiple entrance points (One per exported procedure) so 
you can have a module bound into a service program XVIFSP that allow you to 
write text and another procedure that writes binary and internally there may be 
one routine that implements the actual write.

In addition, when I first wrote my IFS service program, I only supported text 
reads and writes but then one day I needed to read and write binary data so I 
only needed to add two new procedures to support that and because I used 
binding scripts, none of the programs using the existing functions where 
touched. Only the new program used the new functions. Try doing that with 
programs. What a nightmare.   

All of this ignores all the things you can do with a procedure, Long names, 
value parameters, varying string, optional parameters, etc, etc. The list goes 
on and on. Using procedures in service programs gives you flexibility you could 
never dream of in a program. 

The other issue is simply speed. I ran a test the other day making a call to 
procedure 15 million times. It took it 29 seconds for an average of .00000054 
per call and that is passing a long Value parameter. In contrast, a call to a 
program takes somewhere close to 100 ms per call. Making the same 15 million 
calls would run for hours and would knock your system to its knees.

When you break a problem down to small pieces, you end having to make many 
small calls. ILE is designed to do just that. 

The other thing to remember is that modules are used to group together things 
that need to be grouped together. You could group together in one module IFS 
and Inventory Turns but that doesn't make much sense. You would have IFS 
grouped together in one module and maybe Inventory functions in another module 
but the grouping also applies to grouping modules together. You could but why 
would you put an IFS module in the same service program as Inventory functions? 
You won't. Like things in like service programs. Again, you are isolating 
change.

It is a matter of balance. You don't want too much stuff in one service program 
nor do you want to go the other way and have too many service programs. So 
again, design. You have to think about all these questions. 
 
If you look at some of my earlier posts about how I organize modules and decide 
what goes into a module, you will see examples of how I have attacked this 
problem. 

I am currently working a Dynamic Arrays service program on the side and I am 
having to deal with all these issues. What service am I going to provide, what 
will each function do, how do I communicate data between the caller and the 
service program. How do I support find and sort, etc, etc, etc. Lot of thinking 
to do. Trying to make it easy to use but still powerful. That is tough. 

-----Original Message-----
From: ganeshkumar.murugesan@xxxxxxxxx
[mailto:ganeshkumar.murugesan@xxxxxxxxx]
Sent: Monday, February 07, 2005 10:11 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Advantages of Service program



Your explanation is wonderful. But I have a few more doubts in this.

1. Suppose I write a service program with 4 modules inside it. Consider
that 100 other programmers are using the service program. Suddenly I
make some changes to one of the modules in the service program. Just
imagine what will happen to all those programs, which uses this service
program. Maybe they didn't want that change to happen. They will get
unexpected results because of the change I made to the service program,
without their knowledge. They actually don't want some unexpected
results but they will be getting it because I have done some changes.

2. Let us consider there are no service programs. So we just have
modules and procedures. In such a case, won't it be simpler to code a
separate logic inside a separate program instead of coding it inside a
module. You can attain the same results using a program. So why to go
for modules instead of individual programs which can contain the same
piece of reusable code.

Please clarify these doubts.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Tuesday, February 08, 2005 5:51 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Advantages of Service program

This is very long winded. Sorry

In a word. Encapsulation. Again that word. Service programs allow you
take pieces of logic, hide them in procedures and to create libraries of
functions that hide information and to do it at a speed that is
comparable to running the same procedure in a bound module.

If you have had any experience with Microsoft DLL's (Dynamic Link Load
Library), a service program is the same thing. The same thing a DLL does
for you, a service program does for you but I must say, it is a lot
easier in ILE than Microsoft DLL's. Instead of putting your logic in
every program, you put the logic in one service program and the most
important part is that you can hide the logic. If the service program is
properly written, it hides how it works, i.e. it encapsulates the logic.


The problem with this and it is a bugaboo is that ILE RPG is a whole new
world, really a new language. A completely different way of thinking and
it takes time to learn how to think that way.

Instead of writing everything in one big program, you have to break
everything down into small pieces and procedures that do one thing.

An example would that you need to read and write to the IFS. When you
first look at the problem, you could just include all the logic in one
big program which is as far as most RPG programmer would go. Each time
they need to read and write to the IFS, they would just copy the logic
from the other program and have a another version that might or might
not be the same. Languages like RPG III made it very difficult to do
anything except write monolith programs. With RPG IV, we still can write
monolith programs but ILE RPG gives use the means to do something
completely different

But if you stop and think for second, it might occur to you that, "Hey,
that logic is the same logic I used before. Why not take that logic
(read and write to the IFS) and put it in another module? That way I
only have to include that module each time I need to read and write to
the IFS and if I need new functions, I can add them to the module.

The next logical step is it might occur to you that "Wait a minute, I
have to use that logic in many places and other people might be able to
use it and if I add new functions to the module, I have to rebind every
program so why don't I create a service program, then anybody can use
the logic?" That is exactly what a service program is about. If you
create the service program, other people can use it and if you find an
error in your logic, you can fix the service program without having to
create any program that uses it.

The trick here is that you really have to think. How are they going to
use the service program? What services do I provide? How do I handle
errors (Big one)? If you do it right, there is a huge payoff. Suddenly
each time to you need to read and write to the IFS, you just include the
service program and you don't have to worry about how the read and write
to the IFS works.

Anyway, my point is if you logically break a problem down to smaller and
smaller pieces, you naturally end at the service program. More and more
of the program logic ends up in the service program and that is what a
service program was created for. To support just that process.

Another example of using a service program. At a company I was at
previously, we had a very complicated price system and the logic to
price was buried in the order entry program. If you wanted to price, you
had to copy out the logic and adopt it for that environment. When I took
a look at the process is occurred to me that the pricing logic was
separate so I ended up with a service program that published three
services. GetBasePrice, GetCustomerPrice and GetDetails. GetBasePrice
just picked up a base price before any customer discounts,
GetCustomerPrice received a customer number along with the item. To get
the base price, I just needed to call GetBasePrice. If I wanted to
display the details of how the price was calculated, I could just call
Get Details and retrieve all the details.

Internally I had a lot of logic that was hidden in internal procedures
but the outside world only say the three procedures.

Now the only thing anyone had to do was call the service program for
prices and if I needed to change how the internal prices worked, I only
needed to change the internal logic and what was returned, a base or
customer price did not change. That is what a service program is for.
When done right, it is a beautiful thing. Done wrong, it is a mess.

The criminal shame is that we did not have this capability back twenty
or more years ago. Instead of writing monolith programs, everyone could
have learned to write using service programs and small pieces of logic.
What a price we pay. The rest of the world had it, but not us.

-----Original Message-----
From: ganeshkumar.murugesan@xxxxxxxxx
[mailto:ganeshkumar.murugesan@xxxxxxxxx]
Sent: Monday, February 07, 2005 2:57 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Advantages of Service program



Why to include modules in a service program instead of directly
including the modules in the program object using CRTPGM command. What
is the advantage of using service program apart from the initial load
performance point of view?





Confidentiality Notice

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain confidential or privileged information. If you are not
the intended recipient, please notify the sender at Wipro or
Mailadmin@xxxxxxxxx immediately and destroy all copies of this message
and any attachments.





--
This is the RPG programming on the AS400 / iSeries (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.




Confidentiality Notice

The information contained in this electronic message and any attachments to 
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or 
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or 
Mailadmin@xxxxxxxxx immediately
and destroy all copies of this message and any attachments.