On 29/01/2009, at 2:31 AM, David FOXWELL wrote:
I have an unenviable task of converting a 16yr old RPG to ILE. It
calls a lot of other smaller RPG or modules as we called them
before we had ILE. Each one copy booked in from QCPYSRC.
I have to make it 100% ILE as it is intended to run in a named
activation group.
So you are intending to convert the main RPG to ILE with a named
activation group AND are intending to convert all the sub-programs
(or modules as you call them) to ILE with either the same named
activation group or *CALLER. Yes?
At the beginning of the program, it reads in a data area. As I'm
not that experienced with data areas, I've already done a little
debugging. I noticed that the data area gets modified when LR is
on, without coding OUT.
I only found out because the zone I read the data area into got
modified somewhere.
Then it must be defined as a UDS. Refer to Data Area Data Structures
in the RPG documentation to see how they work. Also, there was a
recent discussion on these entities so you should find additional
information in the archives.
I thought I would read in the data area in my main procedure and
then directly call a subprocedure with CONST on the parameter to
protect my data area. However, from experience I've noticed that it
is still possible to modify the parameter inadvertently, and we
have already discussed this. Someone said that CONST in reality
only means that the parameter is not INTENDED to be changed.
Do you mean a real sub-procedure (i.e., code within a P B and P E
boundary) or an external sub-program? If you mean a real sub-
procedure (which should just be termed procedure) then as long as you
do not LIE to the compiler the parameter WILL be protected from
change. You can lie to to compiler in a number of ways:
1) Have the caller and callee use different prototypes (e.g., the
caller says CONST but the callee doesn't).
2) Mess with the data definitions to address the CONST storage via
another mechanism and change it that way.
Therefore for CONST to work as intended the same prototype must be
used by both the caller and callee. Consider it a contract between
the two parties. The caller says "I don't want this changed" and the
callee says "OK, I'll accept that and won't change it". The compiler
does what it can to ensure that contract is honoured.
So, I just thought it was a bit ironic : normally, I use CONST on
all parameters used for input. But now that I REALLY don't want my
parameter to be changed, I shall code VALUE instead.
Not "ironic" at all.
If you use CONST you can (by lying to the compiler) use CONST in the
caller and no const in the callee. However, with VALUE you MUST
specify VALUE in both caller and callee else you will not receive the
correct data.
It should be apparent that if you use VALUE in the caller you have to
change the callee to match. Therefore if you must change the callee
then why not change it to CONST and thus stop lying to the compiler?
I really hate VALUE and will only use it when I need to call a
procedure that has been written to expect parameters by value (i.e.,
C or Unix stuff). In all other cases I use CONST. The primary reason
I hate VALUE is that is allows the variable to be changed in the
callee leading to confusion (not on my part) as to why this variable
was changed and shows in debug as changed but is "magically" gone
when control returns to the caller. CONST will not allow the variable
to be changed (unless the programmer deliberately attempts to
circumvent the compiler) which to me makes the interface more hardened.
I've also seen ugly code where input variables (with VALUE) get used
as work variables in the callee BECAUSE any changes will not be
visible to the caller. That's just sloppy and makes for messy and
unclear code.
Also, CONST can be used between program calls whereas VALUE is
restricted to procedure calls. (Incidentally this is not an OS
restriction but rather a compiler restriction.)
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
