Re: Passing Parms -- RPG400-L

Question - whether you change the number of parameters or the component of
a single parameter, surely ALL programs that call the single/multiple
parameter program MAY need to be retrofitted for the change - depending
upon what that change is? In other words, some analysis will need to be
done either way.

You're right, though I'd like to draw attention to the words "depending onthe change" in your paragraph.

If you're careful to not change the attributes of existing parameters, andyou're careful to always add the new parameters to the end of the list,and you're careful to make all new parameters optional, then you can avoidneeding to recompile the callers (unless, of course, they require tehadded functionality.)

Granted, you can do the same thing with a data structure as well, but youneed meta information (either in the DS, or passed separately) thatdescribes how long teh data structure is, so that the program thatreceives the parameter knows which version of the DS it needs to workwith. That is, in fact, how IBM's APIs work.

However, my point (made in a previous message, but perhaps without dueemphasis) is that it's EASIER to do that with single parameters ratherthan all parms together in one data structure, because you don't have topass the extra meta-info, you can use the %parms BIF instead.

The other advantage to the single parm solution comes when you need tochange an existing parm instead of adding a new one to the end. With thesingle parm solution, you can lessen the impact because only callers thatactually use that parm are affected -- whereas with the DS solution, ifyou make a field longer or shorter, it changes the whole DS, and thereforeimpacts all callers.

The goal is to eliminate the need for retrofitting in as manycircumstances as possible -- and that's why I don't like data structuresas much as parameter lists. At least, as a rule of thumb.


There are exceptions to every rule, of course.