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



You know what? This is an elegant solution to a difficult problem. And it will work well. But, six
months down the road, it will be unmaintainable to the vast majority of RPG programmers. <disclaimer>
If you understood what this program was doing and were able to come up with the correct answer, you
are one of the few </disclaimer>. The reason is that it depends upon side effects in order to work.
By defining the parameter as a pointer, and the CheckField as a based field, you were at least
acknowledging in the code that something is going on outside of the sub-procedure that the
sub-procedure is depending on to make it work. Unfortunately if CheckField were passed in without
using the parameter, there is no way to know that the parameter value will change without some line of
code explicitly changing it. It is not an expected thing for a parameter being passed into a
sub-procedure to change when a read is performed within the sub-procedure, particularly when no
parameters of the sub-procedure are named for fields in the file being read. BTW naming a parameter
of a sub-procedure for a field in a file will not cause the parameter to be changed when that field is
read.

To make this more maintainable, I would use SQL to read through the file, and actually pass in the
name of the column that you want to compare, along with the comparison value. That way you could
build a custom SQL, and execute it. The sub-procedure no longer depends on side effects to work, and
the maintenance programmer can tell exactly what you are doing, and can easily deduce why you are
doing it.

Case in point. It took some discussion and a fairly long thread before Scott figured out just what
you were trying to do. Imagine if you were looking at this some time down the road and were unable to
determine why this worked. Without the explanation of what you were trying to accomplish, how long
would it have taken him? And Scott is no slouch when it comes to RPG. Would Joe programmer be able
to figure it out in a reasonable amount of time? Not likely, and then you would have another of the
special purpose sub-procedures like you have right now.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Don Wereschuk
Sent: Tuesday, January 22, 2008 2:23 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Passing Parameters

Scott: You're absolutely right. I was having a bad day and wasn't thinking straight and some detail
got me confused and frustrated and I apologize for the confusion concerning my code. Your sample along
with Adam's put me back on track and I was able to code the procedure and have it work the way I
wanted ( a good night's sleep and a fresh start also helped) I do thank you and all others for the
help and suggestions. They did help.

Thanks, Don.

******************************************
Don Wereschuk
ISD - Programmer/Analyst
Simcoe Parts Service Inc.
Phone: 705-435-7814 Ex: 302
Fax: 705-435-6746
mailto:dwereschuk@xxxxxxxxxxxxxxx
******************************************
"Save the Cheerleader - Save the world" - Hiro Nakamura

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, January 22, 2008 12:36 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Passing Parameters

Hi Don,

Scott, your code was very similar but what I was trying to do was
pass the name of the field and not the actual data in the field ( not
filerec.PLCD but 'filerec.PLCD'

Sorry, your code does NOT pass the name of the field. If you think it
does, then you don't even understand what your code does.

What it does is pass the ADDRESS of the field. That's what the %addr()
is for, it passes the address of the field. How the heck did you write
your code at all if you didn't understand this?

The reason your code works is because the address of the field is within
the space in memory occupied by the filerec data structure. So when
data is read into filerec, your pointer points to the particular field
within the data structure. It has nothing to do with the name of the
field, it has to do with it's address -- that is, where it's stored in
memory.

Under the covers, in the internals of the machine, my code will look
identical to yours. The difference, at the human-level, is that I'm
passing a subfield of the data structure directly, whereas you're
passing a pointer to a subfield of the data structure, and then
dereferencing them. ultimately, we both end up with a 50A field that's
in the same area of memory as your file subfield, so they do exactly the
same thing.

--
This is the RPG programming on the AS400 / iSeries (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.