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


  • Subject: Re: What are the benefits of ILE?
  • From: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Tue, 10 Jul 2001 14:56:45 -0700
  • Organization: Pacer International

Speaking specifically of your interface, in another language I had
written the interface in each of the source files.  When I decided to
change the interface look and feel I had to go through each of the
source files (250+) and change each one.

I then decided to build a library (Service Program) and have each
program call the functions (procedures) in that.  I went through each
of the 250 programs one last time changing the calls to the external
function (external procedure) and compiled.

Since then, when I decided there was a better way to do something in
the interface I only had to change one source file and recompile the
library (service program).  A great benefit.  Also, I found that it
was a very small matter to have the interface function (procedures)
read a file on startup and determine how it should look.  Then it
was very simple to write a user interface so that each individual
user could set how they wanted their interface to look.  Anytime
they wanted.  A definite bonus, which would not of happened if I
hadn't put the interface in the library (service program) in the
first place.

I found that it was so easy to maintain the actual programs then not
having to worry about the interface at all, just have them place the
calls.

Anything that is going to be called by more than one program should
be stuck in a module at the very least, a service program, IMO is
better.  

Regards,

Jim Langston

Me transmitte sursum, Caledoni!

SCarter@rsrcorp.com wrote:
> 
> I guess my question sparked more debate than I really intended....
> 
> What I was looking for is when do you decide something is right for a
> subprocedure or is it just
> so menial that it is silly to do this.
> 
> My main focus is that the higher ups are talking about doing a rewrite of
> our system.....
> Most of the code is old (many of the dates in seu are 87 88), no use of
> copy books, no vendor
> software (all in house).
> 
> example 1:
> 
> Payroll system we have a program that creates a list for payroll personnel
> of who is going to be paid, how much and so on.
> The actual program uses the axact same code to actually write checks but in
> a different source... Obviously the problem
> here is that when some thing changes we have to change 2 seperate source
> file and recompile blah,blah,blah.
> This seem perfect for using subprocedures/service programs in a rewrite..
> 
> example 2:
> we want to standardize interfaces across the system.  is it worth it to
> create service programs to handle the screen interface
> or is this just an extra level of complexity that would get in the way?
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.