× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.