dcl-pr SRVALGO_SetParmAlpha ind;
pNomParm char(20) const;
pValParm char(50) const;
end-pr;
dcl-pr SRVALGO_SetParmNum ind;
pNomParm char(20) const;
pValParm zoned(15:5) const;
end-pr;
dcl-pr SRVALGO_SetParmDate ind;
pNomParm char(20) const;
pValParm date const;
end-pr;
dcl-pr SRVALGO_SetParmTimestamp ind;
pNomParm char(20) const;
pValParm timestamp const;
end-pr;
dcl-pr SRVALGO_SetParmInd ind;
pNomParm char(20) const;
pValParm ind const;
end-pr;
dcl-pr SRVALGO_SetParm ind OVERLOAD(SRVALGO_SetParmAlpha:SRVALGO_SetParmNum:SRVALGO_SetParmDate:
SRVALGO_SetParmTimestamp:SRVALGO_SetParmInd); //compile Non OK.
...
dcl-s zpsa char(2);
dcl-s zalla packed(2:0);
...
SRVALGO_SetParm('STKD.DZONE.PRECEDENT':zpsa);
RNF0203: PROTOTYPES SRVALGO_SETPARMALPHA AND SRVALGO_SETPARMIND BOTH MATCH THE CALL; FIRST MATCH ASSUMED.
SRVALGO_SetParm('STKD.DZONE.PRECEDENT':zalla);
J'ai donc un problème uniquement entre SRVALGO_SetParmAlpha et SRVALGO_SetParmInd. Il ne sait pas déterminer la fonction à appeler lorsque le paramètre est Alpha ou booléen.
Quelqu'un aurait-il des informations sur le sujet, une solution à proposer ?
C'est effectivement un problème probablement avec const, quand les paramètres sont compatibles
voici ce que dit la doc.
No consideration is given to which prototype has the best match for a particular parameter. For example, assume that the passed parameter is defined with type PACKED(8), and one candidate prototype defines that parameter with keywords PACKED(5:2) and CONST, and another candidate prototype defines that parameter with keywords PACKED(15:5) and CONST. For this call, the compiler will consider the parameter to match both those candidate prototypes even though the PACKED(15:5) parameter is a better match for the PACKED(8) passed parameter.
Je comprends bien lorsque le compilateur doit choisir en packed(5:0) et packed(8:0).
Mais je ne voulais pas croire qu'il interprète un booléen (ind) comme un alpha (char).
D'ailleurs, 2 fonctions, ayant comme paramètre un char(50) pour l'une et un char(1000) pour l'autre, ne pourraient bénéficier de l'overload? Je testerai à l'occasion.
Je vais retirer le SRVALGO_SetParmNum ind de l'overload.
C'est dommage.