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



We have done some file maintenance, and I think there is some benefit there.

I don't have any code that I would be allowed to share, but if I ever get some free time I hope to write my own open source generator using the concepts learned from this project.

As far as performance we did some basic testing, and did not notice any measurable difference until you get up to around 10 million subprocedure calls.



albartell@xxxxxxxxx 9/28/2007 9:19:52 AM >>>

Have you gotten into the stage of needing to do file maintenance to see if
there is fruit to your labor?

Do you have an example you can show us?

I can see how code generators would definitely help the process, as long as
what they create is manageable.

3. Each field has a getter that returns it's data.
Have you done performance comparisons to see if there is any additional
overhead with having so many API calls?

Thanks,
Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of chris beck
Sent: Friday, September 28, 2007 9:07 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: MVC in RPG?

I believe that we have come up with a solid implementation of a Service
program DB abstraction layer in RPG. We have been creating a fairly large
new CGI app (over 100 files) from scratch for the past year and decied to
create a DB abstraction layer for the entire app. When it was proposed, I
thought it was a crazy idea. I thougt all we would be doing was createing
DAO's but this is not true. I created a tool that builds a module for each
file. We then only have to manually create a routine if we want to get the
data in a strange new way, but then I would have had to do it anyway with
tradional code and in every program that I wanted to use it. This way I only
ever have to code it once and it is hidden. This has saved us 10's of
thousands of lines of code.

Some other benefits:
I never have to wory obout coding a F spec, I just prototype in the file or
the service program and access the field I want.
I don't have about chains, setll reade or record locking, It just all
happens under the covers.
We don't need to create an index before writing a program, since all access
is through SQL we just periodically check the index advisor and let it
create what it needs.

I don't think I will ever write another RPG app without a DB abstraction
layer.

Answeres to Aaron's questions:
1. All files get one.
2. We return a indicator on a record load call, or on any other call we set
the SQL CPF Message and use another method (subprocedure) to retrieve it.
3. Each field has a getter that returns it's data.
4. opOrderbyCust(CustId);
dow getNextCustOrder();
// Process the records here.
endDo;
5. We never lock a record. The DAO automaticaly checks for record changes on
a update.
6. stCustOrderDesc('this is the order');
insertCustOrder(Custid:OrderId);

If I only need to get one record I would just call the routine for whatever
field I need. For example gtCustOrderDesc(CustId:OrderId);

Chris Beck


-------------------------------------------------

This email transmission and any documents, files or previous

email messages attached to it may contain information that is

confidential or legally privileged. If you are not the intended

recipient, you are hereby notified that any disclosure, copying,

printing, distributing or use of this transmission is strictly

prohibited. If you have received this transmission in error,

please immediately notify the sender by telephone or return

email and delete the original transmission and its attachments

without reading or saving in any manner.



The Evangelical Lutheran Good Samaritan Society.

---------------------------------------------------------

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.