Question : ILE proto

Hi Friends,

I try to combine 2 working parts of programs that work fine, now I get doubl;e definition errors...
Maybe because it's some time ago that I wrote this kind of stuff, but I can't Find the solution
(In real live the PM#S are not 4 but 400)

And yes I see there is a double definition, but how to solve this?

Thanks EXPERTS !!!!!

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:



P #BLDSTR         B                   EXPORT                     
D #BLDSTR         PI          1600A   VARYING                    
D   StrInp                    1600A   CONST VARYING              
D                                     OPTIONS(*VARSIZE)          
D   PM#001                     100A   CONST VARYING              
D                                      OPTIONS(*VARSIZE:*NOPASS)  
D   PM#002                     100A   CONST VARYING              
D                                      OPTIONS(*VARSIZE:*NOPASS)  
D   PM#003                     100A   CONST VARYING              
D                                      OPTIONS(*VARSIZE:*NOPASS)  
D   PM#004                     100A   CONST VARYING              
D                                      OPTIONS(*VARSIZE:*NOPASS)  
DPM#DS            DS                                        
D PM#001                       100A   Overlay(PM#DS:*NEXT) 
D PM#002                       100A   Overlay(PM#DS:*NEXT) 
D PM#003                       100A   Overlay(PM#DS:*NEXT) 
D PM#004                       100A   Overlay(PM#DS:*NEXT) 
D PM#                          100A   Dim(4) Overlay(PM#DS:1)

Answer : ILE proto

Can't I use a likeds in my PR(PI) part?

As long as the calling proc sends in a DS, then you can use a DS on the receiving side.

That is, if the calling proc passes a parameter "by reference", your receiving proc is only going to receive an address -- the definition is irrelevant as far as the system is concerned; it is essentially only relevant in terms of maintainability. (But that's an important relevance. You want to re-use definitions between caller and callee in order to minimize bugs from incompatible definitions.)

If the memory is defined within a DS in the calling proc, you can use the same DS definition in the called proc because they will be pointing at the same memory (as long as passed "by reference"). And in that case, there wouldn't be any need for your proc to EVAL from/to the argument and a separate DS; the values would already be in the DS.

Or if a group of 400 variables all happen to be in contiguous memory in the calling proc and they all have the same definition, you only need to pass the address of the first variable -- the called proc can define its argument to be a 400-element array. (Of course, it can be tricky to make sure that you are using contiguous memory -- a DS is often used for that.)

But having different definitions between the calling and called procs is what widens the risk of mismatched parms. So we regularly use /COPY members to help ensure that we reference memory the same way on both ends.

If you pass in a DS, you'll have to load the DS with values in every proc that calls your proc. If you pass in separate parms, you only load the DS in your proc. You have to choose where the memory management takes place.

If this is in a proc that will only be bound into a single program, it might not make any difference. It will only be done in one piece of code either way.

But if your proc may be called from multiple other procs, you should see that loading the array might be best in your proc. Don't dictate to the calling procs how they must organize their variables.

The answer is... it depends.

Tom