Re: Procedure Parameter Change (was Exported Variables)

I have a problem with a blanket statement that procedure parameters
should "never" change. While it is not something that should be done
thoughtlessly, I don't see how it is any more involved than changing a
field in a file. If I change a field from 1A to 3A, or from 1A to 1P, I
will have to at a minimum recompile any programs that reference the
file, and I may need to change the programs as well. How is changing a
procedure parameter any different? The change in the service program's
signature will prevent me from unknowingly using a changed procedure,
and if it is in a bound module, the procedure won't change until I
rebind the program at which point I will hopefully either be changing
the main module code or at least get an error indicating the the
procedure call is no longer correct. 

I would argue that, done correctly, using LIKE in the parameter
definitions will make potential problems fewer, or at least easier to
fix. If the parameters are defined like a file field, for instance, then
the only reason the parameter would change is if the file field changed,
which would probably be a "good thing". In fact I would possibly
recommend that the parameters on the PI be defined LIKE the parameters
in the PR, or visa versa. This way they are basically guaranteed to be
in sync and any programs that copy in the PR will have the correct and
current parameters.

Joe Lee

>>> pmorgan@xxxxxxxxxxxxxx 01/12/2005 08:13:51 >>>
Kurt,

I don't believe this is a style argument.  Style refers more to a
coding
standard that improves readability and understanding of a program.  A
style
argument against LIKE would be a decrease in readability.  You have to
track
down the referring variable to determine the type and size of the LIKE
defined variable.   That slows down the reading and understanding of
programs using LIKE definitions.  I'm not arguing against LIKE on
style
grounds.  In this case I'm arguing that LIKE on a procedure interface
can be
a source of programming errors.

In your example I wouldn't have a beef about changing a const parameter
from
1A to 3A.  The calling program wouldn't care about this change.  It
can
continue to be fat, dumb and happy passing a 1A value to a 3A const
parameter.  This slight change doesn't really impact the calling
program.

However, what if the LIKE definition switched from 1A to 1P 0 (single
alphanumeric to single packed number)?  Compile errors with the
calling
program?  A run time error when the calling program tried to pass a 1A
parameter to a service program expecting a 1P 0?  Not good.

Here's another example.  How about a function defined as:

D FieldA                            1A

D Function       PR               LIKE(FieldA)
D  Value                             1A Const

My calling procedure would be using it as:

D Result                     1A

 Result = Function('X');

What if FieldA went from 1A to 3A?  I'd start losing some data in my
calling
program as a result of the function changing.  This is an 'accident
waiting
to happen' in the calling program because of the LIKE define in the
prototype.  The calling program's compile wouldn't complain that the
returned value was now 3A.  The  calling program would start truncating
the
returned 3A value without a complaint.  This is a 'silent' error in
the
calling program.

Instead of using the LIKE definition to automatically modify Function
I'd
make a new Function2:

D Function2  PR                3A
D  Value                            1A Const

then leisurely modify the calling programs to use Function2 instead of
Function.  Meanwhile Function 'gracefully fails' when it encounters an
actual 3A value.  Maybe that 3A field only has 1A values until the
switch to
Function2 has been completed.  Maybe taking the first or last char in
the 3A
field is ok.  Maybe Function reports a problem with encountering an
actual
3A value when it can only return a 1A value.  Would depend on the
situation.
It's up to Function to handle the problem and not the Function
callers.

Coding an immutable procedure interface (API) isn't really related to
ILE
programming.  It's just good software engineering which applies to any
language.  LIKE definitions are a feature of the RPG language - not
just
ILE.  IMHO using a LIKE define for an OPM program entry parameter is
also a
bad idea.

Paul

-- 
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333

"Kurt Anderson" wrote

> Why allow the program to give a soft error about something that
should
> have been allowed in the first place if the coding was done?  Not to
> mention it seems that having to code this check into every place the
> procedure is called is far more tedious than actually modifying the
> procedure parameter.

> How would the program know?  What if 'A' and 'ABC' were valid, giving
a
> general situation, it couldn't know that it received 'A' when it
should
> have received 'ABC' because 'A' is a valid code.
>

> Say we have the following:
>
> file:
> FileA: FldA 1A
>
> Procedure:
> D ProcA           PR
> D  FldA                          1A   Const
> D  FldB                         10A
>
> Procedure call:
> FileA( code_likeFldA : anotherfield );
>
> Then the file was modified to be:
> FileA: FldA 3A
>
> My thought is: modify the procedure to be 3A instead of 1A (which I
> think you're saying is wrong, or more prone to problems).
>

> Thanks again for sticking with me here.
> I've been in ILE for not quite a year, and while I've learned a lot,
> there's a lot more yet to learn.