RE: Returning from a procedure -- RPG400-L

Hoping I can save you some time. . .

Our IT depts went down this road about a year or two ago.  We developed one
service program per file with all of the different data access needs built
in.  For instance. . .

custDS = CstMstPF_getCustRecord(1); 

Or 

custName = CstMstPF_getCustName(1);

In doing something like this you will find out quickly that there are a ton
of ways to get at your customer files, like all the different logicals,
partial keys, etc.  In the end it is just a waste of time to build the
interface that close to the file, IMO.  It would be better to group your
files and provide services to those files, or SOA(Service Oriented
Architecture).  

For instance,  I just got done writing one service program that takes care
of all our XML processing.  Behind the scenes the service program is
accessing many files, but the interfaces I export are purely functional to
the programmer.  One example would be EDI_processXMLReq(xmlFile); - that
will receive in an XML file, parse it, log it, dispatch the appropriate
business logic program to process it, and return an XML response.  Within
the EDI service program I access all of the files directly with CHAIN's
READ's etc.  This gives me the same separation that I had in my CstMstPF
service program except for it provides services or actions instead of just
file access.

Maybe somebody has had better luck in this area, but that is what I have
found.  The real challenge becomes organizing your sub procs within the
right service programs and have it make sense to those utilizing the
finished products.

HTH,
Aaron Bartell

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Chris_Bougher@xxxxxxxxxxxxx
Sent: Monday, May 24, 2004 10:55 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Returning from a procedure


Thanks Scott. I was hoping you would say that I just wanted to verify.

On the performance, what I am trying to do is hide the database behind
accessor functions. Many times only a few fields are actually needed from a
file and I thought putting those in a service program would cut down on the
number of programs that access these files and make database changes easier
and, hopefully, transparent. I am only chaining the record if it is not
already in memory. My thinking is that if a user is getting many fields from
the service program they will access them for the say key in order. I am
interested in your thoughts on this idea.

Thanks
Chris Bougher



 

                      Scott Klement

                      <klemscot@klements        To:       RPG programming on
the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>                
                      .com>                     cc:

                      Sent by:                  Subject:  Re: Returning from
a procedure                                                
                      rpg400-l-bounces@m

                      idrange.com

 

 

                      05/24/2004 11:39

                      AM

                      Please respond to

                      RPG programming on

                      the AS400 /

                      iSeries

 

 






> When you return a value from a procedure are you returning the value 
> or a reference to the value?

Assuming that you're referring to data returned by the "return" op-code,
rather than a parameter, you're ALWAYS returning a value.

Even if you return a pointer, you're returning the value of the pointer.
(Though, granted, the address stored in the pointer will likely be used as a
reference.)

> I have several procedures in a service program that are used to access 
> different fields in a database and I want to make sure that if I 
> return
the
> database field that it wont change if the service program is used to 
> get
a
> value from a different record. Also I thought about moving the value 
> from the field to a work field in the procedure but I was worried the 
> memory could be reclaimed.

It won't change, unless you're passing a pointer and basing a variable on
that pointer.  (Or doing something equally obvious, like using the same
variable to store the return value for subsequent calls.)

Your srvpgm may not perform well -- depending on the fields and how often
you're doing this -- but then, that may not be one of your goals.

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






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