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.