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



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.






As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.