RE: File Read in Subprocedure WAS(Re: More on RPG style) -- RPG400-L

Yep.

You may have a subprocedure in your program called GetItemFields() in which you'd put all of those $get() procedures.

Keep in mind you can also put business logic into this kind of service program to reduce the number of fields that need to be accessible by the caller.

Another nice thing about this type of service program, I've found, is that it ties into CL very easily, essentially giving you all the power of RPG I/O in CL. And not just CL, but this type of service program should be accessible by Java and PHP (and others, although my exposure to non-green screen interfacing is limited, (I'm trying to forget VARPG)).

-Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Crosby
Sent: Monday, March 01, 2010 11:29 AM
To: RPG programming on the IBM i / System i
Subject: Re: File Read in Subprocedure WAS(Re: More on RPG style)

Question on this approach:

What do you do when you need 35 or so fields from the item file?

I'm in program A. I have the item number. I need brand, pack, size,
description, category, class, last receipt date, qty received
today/WTD/MTD/YTD, qty on hand, qty reserved, last ship date, qty shipped
today/WTD/MTD/YTD, vendor, vendor item number, etc, etc, etc. Do you have
35 lines in Program A calling 35 $get... procedures? Do then put those 35
$get... statements into a single procedure in Program A?

Thanks.

On Mon, Mar 1, 2010 at 11:36 AM, Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx

wrote:

Passing a data structure isn't heavy if it's passed by reference.

Personally, I create $get... and $set... procedures for every field (with a
utility so it's not super time intensive to code).

In this way, I perceive the service program as kind of a cloud of data. I
reach up into the cloud when I need something.

-Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Bryce Martin
Sent: Monday, March 01, 2010 10:07 AM
To: RPG programming on the IBM i / System i
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
--
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 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.