Re: Externalizing I/O Was: File Read in Subprocedure WAS(Re: More on RPG style)

20+ years ago I work on software called TOM for The Office Manager. It
ran on the Wang 2200. It was rather based on Wang Basic but used TOM for
everything. So all of my I/O was done via TOM. Actually I had no clue
how to do I/O without TOM. I've forgotten most of what I ever learned
about TOM. And as hard of a time as I am having trying to figure out what
the big advantage of externalizing I/O is and all that happy jack, I have
to remember that I actually worked with a system that did that and it
wasn't too bad.

But, how many people dig this idea of externalizing I/O and are not the
person who has access to the raw source for the getters and whatnot?

If you are in a shop that insists on this, what's the point to learning
SQL and whatnot? Unless, you are the high priest in charge of the getters
and whatnot.



Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
Date: 03/01/2010 01:08 PM
Subject: Re: File Read in Subprocedure WAS(Re: More on RPG style)
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



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.

--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.