Use $Get[fieldname] procedures. I personally avoid passing the entire data structure for the reason you gave.
-Kurt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of MattLavinder@xxxxxxxxxxxxxxxxxxx
Sent: Monday, March 01, 2010 10:50 AM
To: RPG programming on the IBM i / System i
Cc: RPG programming on the IBM i / System i; rpg400-l-bounces@xxxxxxxxxxxx
Subject: Re: File Read in Subprocedure WAS(Re: More on RPG style)
Brian-
How do you handle file changes...specifically adding fields? I've used a
strategy similar to yours and I have always wondered what would be the best
approach if and when I have to add a new field to the file. As it is now,
it seems every program accessing the service program data structure will
need to be recompiled. Personally, not having to recompile as much is the
MAJOR benefit I would like to gain from file encapsulation in RPG.
And don't give me a "you should think ahead" line. :-) We work in a
business where we are very responsive to client's needs, and sometimes
customers come up with off the wall stuff we would have never thought of in
a million years.
Matt
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|BMay@xxxxxxxxx |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|03/01/2010 11:40 AM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: File Read in Subprocedure WAS(Re: More on RPG style). |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
In order to make the condition work, the return value is defined as an
indicator. The procedure passes back *On or *Off depending on whether or
not a record was found. As for the data, there are a number of ways to do
it.
The simplest way is to define an externally described data structure using
EXTNAME and pass it back and forth as a parameter. This is not my
favorite way to do it, but it will definitely work. I personally prefer
to create a data structure of only the most commonly used columns to cut
down the length of the parameters being passed. For the less commonly
used columns, I will usually create "Get" procedures to retrieve them only
when needed.
To handle the setll, I normally use what I call a "Cursor Control"
parameter. So that parameter tells the procedure whether it should issue
the setll and then do the read (or reade) or if it should just grab the
next (or previous). So a typical loop for me would look something like
this:
Cursor_Ctl = cResetCursor ;
Dow BOM_GetLineDtl(BOM# : BOM_Dtl_DS : Cursor_Ctl) ;
Cursor_Ctl = cNextRec ;
// Do whatever with BOM Detail data
EndDo ;
Hope that clarifies,
Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi
rob@xxxxxxxxx
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/01/2010 09:59 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
Subject
Re: File Read in Subprocedure WAS(Re: More on RPG style)
Brian,
How do you pass it back and forth as parameters and still do
Dow ReadMyfile();
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: BMay@xxxxxxxxx
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Date: 03/01/2010 10:44 AM
Subject: Re: File Read in Subprocedure WAS(Re: More on RPG style)
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Bryce,
I have service programs doing exactly what you mention. What you have to
do is have another procedure to do the setll (or maybe just a parameter
flag). Also, you need to pass the data back and forth as parameters.
Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi
Bryce Martin <BMartin@xxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/01/2010 09:07 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
Subject
File Read in Subprocedure WAS(Re: More on RPG style)
I like the readability of the dow ReadFile(); approach. But if I was to
do that I'd want to have a service program that has all my file read
subprocedures together, that way I would only ever have to code the file
read 1 time for any given file or logical. Is this possible? I can't
think that it is, but maybe I'm wrong. If I setll in my program, will
that translate over to an exported procedure call?
Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
rob@xxxxxxxxx
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/01/2010 08:53 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
Subject
Re: More on RPG style
No, you're right. It's an evolutionary process.
First there was subroutines, and they were ok.
And a branch off of the evolutionary ladder was called programs, if you
came from the S/36 family tree you can remember NOT having them.
Then there was subprocedures and they are good. Local variables and
making your own bifs are good. Being able to pass in a number of
variables and getting a return variable helped to clarify.
Then there was service programs. Move your subprocedures to there (might
want to dispose of those global variables). This allows you to get the
modularization of called programs but keep the bif type look and other
advantages.
Besides, I find this more readable
setll myfile;
dow ReadMyfile();
// process row
...
if recid<>'A';
iter;
endif;
EndDo;
Than
setll myfile;
read myfile; // priming read
dow not %eof(myfile);
// process row
if recid<>'A';
iter;
endif;
read myfile;
EndDo;
That, and the second example has an infinite loop while the first doesn't.
And, if you want to move the recid <>'A' logic into ReadMyfile you could.
And, if you wanted to have ReadMyfile get data from other files, like if
your reading a transaction file and you wanted to bring in the customer
name upon a break, you could.
Or, if you wanted to handle some really rare exceptions you could, like if
there was an error from a mythical before read trigger.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: David FOXWELL <David.FOXWELL@xxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Date: 03/01/2010 05:48 AM
Subject: More on RPG style
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Hi,
I tend to divide my code into subprocedures in a program just to improve
readability, even when there is very little risk of that subprocedure
being called from anywhere else. Each subprocedure will correspond to a
specific task executed by the program.
Eg,
/FREE
IF not doThis ( )
RETURN
ENDIF;
IF NOT DoThat ( )
RETURN
ENDIF;
/END-FREE
In these cases I will use global variables unless not possible. That
leaves me with a load of one line prototype declarations in my code :
D doThis PR
D doThat PR
I've just discovered that this style seems to annoy at least one
programmer who prefers to see all the code in one main procedure and does
not like to see all those PR's PI's and returns, etc. Rather embarassing.
Am I justified in coding in this way or am I wrongly using subprocedures?
--
This is the RPG programming on the IBM i / System i (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 IBM i / System i (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 message (including any attachments) is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---
--
This is the RPG programming on the IBM i / System i (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 IBM i / System i (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 IBM i / System i (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 IBM i / System i (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..
midrange.com
