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

No offence,

but is it just the old File Server Technique we used 22+ years ago to make
speed
on a B10 or a 5363, not having to open files several times in a
structured one program
per screen structure you are discussing ?

I first used File Servers on a 5363 S/36 with ASNA's RPGIII compiler and
today I use them
as Remote Procedure Calls in web development where input is FORMS data and
output
is data either wrapped in an HTML table, XML or JSON.

I have a hard time to understand what they should do in a NATIVE
structured environment
today.

The reason to use them in RIA based web does however make sence because
data is
retrieved by call backs from the client and therefor dosn't have to reside
in the program
that serves the RIA application to the Client.

Henrik

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

Yep, that's the idea.

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

Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/01/2010 02:20 PM
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)

Bear with me on this. Between yours and Kurt's responses, I think I'm
starting to understand.

1) The service program doesn't have to be only getters and setters. It
can
have whatever I want.

2) I could have 'group' setters and getters. Example: virtually every
time
I want the item description, I also want the pack, size, brand, extended
description, and class, ie, other fields that describe the item. So the
service program could have a GetItemDescriptiveInfo subprocedure. And a
GetItemInventory to get cases, units, and weight on hand fields. And a
GetItemMovement to get all received MTD/YTD as well as shipped MTD/YTD
fields. And a GetItemCosts to get last, average, market, and all other
cost
fields. And on and on, ad infinitum.

On Mon, Mar 1, 2010 at 1:31 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Jeff,

Two questions...

1) What are you doing with the 35 fields
2) Are the 35 fields used in more than one place?

If you're performing business logic on the fields, consider putting
into it's own procedure in the file(s) service program.

Otherwise, say you're just outputting to a screen or report...and
these 35 are commonly used together then just have a DS that contains
the 35 fields.

HTH,

Charles

On Mon, Mar 1, 2010 at 12:28 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:

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

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

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,

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

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

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.