Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

> ## Passing parameters

> The publisher can pass parameters in the same way as for a `RUN` statement. Ordinarily, any such parameters are `INPUT` parameters so that the publishing procedure can pass one or more values into each subscriber. `INPUT` parameters are the norm because the publisher normally does not want to know the specifics of who the subscribers are and therefore is unlikely to be interested in output from them. If the publisher wants to get a specific response back, then it is better to use a `RUN` statement with a known procedure handle to run it in.

> In particular, an `OUTPUT` parameter is almost always a bad idea because its value is received only from the last subscribing procedure to execute. If there are multiple subscribers, the `OUTPUT` parameter returned by the rest of them is discarded. Since there is no way to determine which of multiple subscribers will run last, this is not a reliable or useful mechanism.

> On the other hand, there are times when it can be useful to pass an `INPUT-OUTPUT` parameter. In this case, each subscriber in turn receives the current value of the parameter and can act on it and modify it. The next subscriber receives the modified value and can modify it further. Finally, the publisher receives it as output from the final subscriber and can see the collective result. This is useful in cases where all the subscribers need to contribute something to a final total, perhaps adding a value to the current value of the parameter or appending something to the end of a delimited list. The publisher then sees the result of all the calls. Again, there is no determined order for the subscribers to be called, but if the order of execution is not important, then an `INPUT-OUTPUT` parameter is sometimes useful.

> The final subscriber can also pass back a string in a `RETURN` statement that is received by the publisher as the `RETURN-VALUE` just as if the publisher had used a `RUN` statement. Again, there is no way to know which subscriber will be the final one called, so each subscriber could append text to the existing `RETURN-VALUE` in a way similar to using an `INPUT-OUTPUT` parameter in a form such as the one in the following example. In this code, the `RETURN` statement appends the value of the local `CHARACTER` variable `cMyIdent` to the current `RETURN-VALUE`:

>     RETURN RETURN-VALUE + “ “ + cMyIdent.

> Each subscriber can see the value returned by the previous subscriber in its `RETURN-VALUE`. If this is the final statement in each subscriber’s internal procedure, then the publisher can look at the value of `RETURN-VALUE` and see all the accumulated values of `cMyIdent` for all the subscribers.

> The `PUBLISH` statement always executes `NO-ERROR`. If there are no subscribers, no error message results. If one or more subscribers have a parameter list that does not match the parameters in the `PUBLISH` statement, then those subscribers do not receive the event and, likewise, no error results. For this reason, it is important to make sure that subscribers have the proper calling sequence. Otherwise, their procedures will not be run and it might not be clear to you why the `PUBLISH` statement seems to have failed.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095