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



Aaron,

We did this originally for just the reason you outlined.

Our experience was the effort we saved with the degree of separation 
(recompiles) was adding to the effort necessary to implement and maintain the 
code.  I think that if we had a CASE level tool that would not be the issue.

We also don't have to deal with distributing our code to external customers

Note: We are definitely using our in-house code generating tool.  Not sure I 
can send the code out though :0(    I would recommend that you do write your 
own, pays for itself.


>>> ALBartell@taylorcorp.com 04/12/02 08:25AM >>>
But now you don't have the same degree of separation because I am guessing
you define an external data structure in the programs that use the
getState() and setState() modules.  If you keep it at a field level like so

eval custName = getCustName()

then you don't have to recompile every program that uses the customer file
when the customer name gets expanded by 30 bytes, just the ones that
actually use customer name.

In my situation changing the customer master file requires quite the work
and since we have to distribute our software to about 20 companies the
chance for level checks is much much higher.

Aaron Bartell



-----Original Message-----
From: Andrew Lutz [mailto:alutz@pmigroup.com]
Sent: Friday, April 12, 2002 9:56 AM
To: rpg400-l@midrange.com
Subject: RE: Separation of Presentation, BL, and I/O Tiers


Aaron,

I have implemented this setter/getter for every field methodology in a
previous project.

Yes, we generated the programs automatically.

But eventually you must maintain them outside the generator.  Lot of work.
Not to mention a lot of procedures, that made Large programs.

This time we are implementing a

getState()

setState()

style approach where the entire object structure is passed.  Much simpler.
Easier to maintain.  Smaller programs.


>>> ALBartell@taylorcorp.com 04/12/02 06:32AM >>>
We are trying something new in our software where we are doing something
similar to what is being talked about here.  We are creating IO modules for
all of our files.

Here's what I am wondering.  Since every service program will be the same
except for the names of the subprocedures we are thinking about writing a
program to produce the getter and setter methods for each field, similar to
how some Java IDE's do it for you based on the variables you define in the
object.  We wouldn't be writing a program to do this if there wasn't a
gazillion files that we had in our software, but each one needs to have a
service program created for it.

Has anybody done this before, and if you have would you be willing to share
the code that it took to dynamically write the programs?

Thanks in advance,
Aaron Bartell



-----Original Message-----
From: dmosley@dancik.com [mailto:dmosley@dancik.com]
Sent: Wednesday, April 10, 2002 2:35 PM
To: rpg400-l@midrange.com
Subject: RE: Separation of Presentation, BL, and I/O Tiers



I curious about the use of MODS (and thank you Aaron for asking the
meaning).
Is the use of MODS easier than using single record retrieval.
Reason I'm asking, is becuase I've created a very basic service program
with two primary procedures.   @SETLL, and @RTV.
The @SETLL dynamicaly builds the Select statement based on passed
position-values, and prepares the statement.
Then I would do a DO-loop around my @RTV and retrieve each individual
record as they are FETCHed.  The @RTV would pass back an error-indicator.
This indicator would specify either EndOfFile, or Error-Occurred during the
FETCH.

Anyway, I've been using this type of retrieval for a while, and never
really thought about using MODS.  Does using MODS enhance the performance
of the FETCH any?

Thanks
dav


David L. Mosley, Jr.
Systems Analyst
2000 CentreGreen Way
Suite 250
Cary, NC 27513



                    "Smith, Nelson"
                    <NSmith@lincare.c        To:
"'rpg400-l@midrange.com'" <rpg400-l@midrange.com>
                    om>                      cc:
                    Sent by:                 Subject:     RE: Separation of
Presentation, BL, and I/O Tiers
                    rpg400-l-admin@mi
                    drange.com


                    04/10/02 03:23 PM
                    Please respond to
                    rpg400-l






If you have to define it at the maximum occurs, what does being dynamic buy
you?  Would you immediately go in at program startup and resize it back
down
to a reasonable number?  Would that be the benefit?

You say "as for an array".  I thought I had seen examples of people
starting
off with a 100 element array and then resizing it to 200?  You can't do
that?

The end result I'd like to get to is to have an I/O routine that gets a
bunch of records (by RPG, SQL, Stored procedure, whatever), sizes an array
or ds to hold them based on the number it found, then just return a pointer
to the structure along with the number of records contained in it.

So, would the I/O module have to declare the MODS at the maximum Occurs,
get
the records, then reallocate the MODS back down to the actual number of
records retrieved, then return to the calling program?  Then, the calling
program would have to do the same thing, start off with a maximum size ds,
and reallocate it down after it got the pointer back from the I/O module?

Is that the scenario? Would there be any performance issues here, when an
application may be doing this for hundreds of files?

> -----Original Message-----
> From:   Jon Paris [SMTP:Jon.Paris@Partner400.com]
> Sent:   Wednesday, April 10, 2002 2:51 PM
> To:     rpg400-l@midrange.com
> Subject:     Separation of Presentation, BL, and I/O Tiers
>
>  >> I've seen several posters saying they could, but have seen no
examples
> of that, yet.
>
> MODS can be based (and therefore dynamically sized) just as arrays can.
> The
> limitation (as for an array) is that you must define the number of
> occurrences as the largest number you will ever need.  I like the
> technique
> because it has the added advantage that you can have multiple definitions
> of
> the DS and map them to individual occurrences of the MODS so you simply
> directly compare multiple occurrences.
>
> You can also use things like the C qsort and bsearch routines to sort and
> search the MODS.
>
> Jon Paris
> Partner400
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


****************************************************************************
****************************************************************************
****************************************************

This message originates from Lincare Holdings Inc. It contains information
which maybe confidential or privileged and is intended only for the
individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the
contents of this message.
All personal messages express views solely of the sender, which are not to
be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer.
If you received this message in error, please notify us immediately at
MailAdmin@lincare.com or (800) 284-2006.
****************************************************************************
****************************************************************************
****************************************************


_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



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.