Re: File Read in Subprocedure WAS(Re: More on RPG style)

Yes, you have to pass the data back and forth. So technically, it could
be a large amount of data (passed by reference though). But the
flexibility outweighs any issue this would cause in my opinion. If all of
your IO for a given set of tables is directed through a single service
program,changes become very easy.

Let's say your original application did not use commitment control (don't
know why anyone would do that, but that's another topic). Your boss tells
you to implement commitment control on the application. Guess how many
places you need to deal with it? One.

Or lets say your corporate controller wants an email whenever someone
changes a customer's credit limit. Do you need to care how many different
people and how many different screens can change the credit limit? No.
All you need is a check in the UpdateCustomer() procedure.

Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi



Bryce Martin <BMartin@xxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/01/2010 10:24 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)






So if I use a procedure in a seperate service program to do the read then
I have to pass a datastructure of all the fields basically? That seems
quite heavy doesn't it? Or do you have a param list that is a mile long?
The read doesn't carry into the main line or to other procedures correct?


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



BMay@xxxxxxxxx
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/01/2010 10:11 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)






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