RE: Prototypes and parameters

Reeve:

One way to look at this is similar to how it seems handled by many system APIs. 
Often, you'll see an API parm described simply as Char(*) with no length 
directly associated. Perhaps that's the way you could view it... just pass a 
pointer back to whatever variable you want to fill.

Of course, you'll notice that these APIs also have an additional parameter that 
indicates a length so the API doesn't just start filling some arbitrary size of 
memory. You don't exactly have a <length> parm, but you do have a second parm 
that effectively acts as a <format> and implicitly carries a length.

So, your called procedure then receives FORMAT and RTN_VAR_ADDRESS. Your 
procedure doesn't care about exactly what variable is being filled back in the 
calling procedure; all it cares is that it's allowed to start filling memory at 
the location pointed to by RTN_VAR_ADDRESS and it can't fill any more memery 
than the length indicated by FORMAT. When FORMAT is 'TERMS', it knows the 
implicit length is 3; when FORMAT is 'STATE', it knows the length limit is 2.

When you prototype lookup() in the calling procedure, declare a pointer by 
value for the second parm. When you call lookup(), pass %addr(terms_code) or 
%addr(sh_state). Inside lookup(), you _could_ declare the second parm as 
q_alpha_10 10A by reference if you really wish or you can again declare a 
pointer and use it as a basing pointer for perhaps q_alpha_10. Just be sure you 
never use more than the maximum left-most positions of q_alpha_10 than are 
indicated by FORMAT.

Something like this (mostly, but someone will correct any errors):

In caller:

D LOOKUP          PR...
D   FORMAT                      10A
D   RTN_VAR_ADDRESS               * VALUE

C                   callp     lookup('TERMS':%addr(terms_code))
C                   callp     lookup('STATE':%addr(sh_state))

In lookup():

D LOOKUP          PR/PI...
D   FORMAT                      10A
D   RTN_VAR_ADDRESS               * VALUE
D   q_alpha_10    S             10A BASED(RTN_VAR_ADDRESS)
                  <== note 'S'tandalone

Just be very aware that when, for example, you pass the address of sh_state 
(2A), you don't alter more than the first two positions of q_alpha_10.

Tom Liotta

rpg400-l-request@midrange.com wrote:

>   2. Prototypes and parameters (Reeve Fritchman)
>
>I have a general-purpose pop-up window used to display and select values
>from a reference file.
>
>Parameter 1 is the reference name and it's passed in as a literal ('TERMS',
>'STATE').
>Parameter 2 is the field I want the value selected by the user returned into
>(back to the caller).
>
>Both parameters are 10A.
>
>Currently, the program is called with a prototype using EXTPGM(=91LOOKUP=92=
>)=2E  A
>typical implementation looks like this:
>
>     C                   callp     lookup('TERMS':q_alpha_10)
>     C                   eval      terms_code =3D
>%subst(q_alpha_10:1:%size(terms_code))
>     C                   callp     lookup('STATE':q_alpha_10)
>     C                   eval      sh_state =3D
>%subst(q_alpha_10:1:%size(sh_state))
>
>Now, the complication: the size of the second parameter varies (based on
>what I=92m looking up): "terms_code" is 3A, but "sh_state" is 2A.  Improper
>management of the parameters (size) has caused problems (decimal data errors
>because the improperly-sized parameter 2 overflows into adjacent fields in
>memory); the second line solved the problem.
>
>Because LOOKUP is called with EXTPGM, OPDESC doesn=92t work.  Yes, it should
>be in a service program but circumstances of time and customer politics
>don't allow it.
>
>I=92ve done this too:
>
>     C                   callp     lookup('TERMS':q_alpha_10)
>     C                   eval      terms_code =3D q_alpha_10
>     C                   callp     lookup('STATE':q_alpha_10)
>     C                   eval      sh_state   =3D q_alpha_10
>
>This is the ideal solution:
>
>     C                   callp     lookup('TERMS':terms_code)
>     C                   callp     lookup('STATE':sh_state)
>
>
>I've tinkered with VARYING, setting the length, etc. but am unable to come
>up with a way to
>implement the ideal solution.  Perhaps it=92s too much Halloween candy, but
>I'm sure there's a better way to juggle OPTIONS(*VARSIZE) and VARYING to
>make this work...or is there?

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! 
http://channels.netscape.com/ns/browsers/download.jsp

Get your own FREE, personal Netscape Mail account today at 
http://webmail.netscape.com/