RE: SELECT & WHENEQ Question

["Holden Tommy" <Tommy.Holden@xxxxxxxxxxxxxxxxx>]

If/select whatever....I would still just return the appropriate
value...then no loop etc, will be in the main proc.  Just do the callp &
return the correct value via return variable or inline parm (I'd prefer
inline parn for this particular situation...

  GetFacility( K@Fac );

PGetFacility          B
D GetFacility         PI
D   Facility                      like(K@Fac)
  /free
     // determine correct facility
     return;
 /end-free
PGetFacilty           E


Note spacing is probably way off due to coding in text format in the
email...lazy me....

Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilt, Charles
Sent: Wednesday, August 16, 2006 8:40 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: SELECT & WHENEQ Question

I agree that the code should be in a subproc.

But I disagree that the original DOU + SELECT should be used.

IMHO, the DOU + SELECT were ugly and unclear, as proof, consider the
difficulties with the original rewrite.

On the other hand, both the nested IFs or either of loops that used the
checkValue array made were clear as to what was going on.

Sure you could comment the heck out of the original DOU + SELECT,
particularly with it in a subproc.  But clearer code is always better
than comments, assuming no performance impacts.



Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Holden Tommy
> Sent: Wednesday, August 16, 2006 9:26 AM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: SELECT & WHENEQ Question
>
> Seems the simplest solution would be to move the select to a subproc &
> have the subproc return the actual value of the K@Fac field.......just
> my opinion... 
>
>
> Thanks,
> Tommy Holden