In a local call, passing a ProDataSet as an INPUT parameter BY-REFERENCE makes it behave essentially like an INPUT-OUTPUT parameter. The called procedure uses its local definition of the ProDataSet, if any, only to verify that the definition is compatible with the INPUT parameter. It then adjusts any references to the parameter to point to the ProDataSet instance in the caller. As a result, any changes you make to data in the ProDataSet in the called procedure are actually made to the ProDataSet in the calling procedure, and so are visible there after the procedure returns.

Tip: If the called procedure can make changes that should be visible in the caller, then you should make the parameter INPUT-OUTPUT. This reflects what is actually going on, and also provides the correct behavior when the call is remote, as the changes must explicitly be passed back to the caller in that case. If the called procedure will only read the data and not change it, then make the parameter INPUT.

Why not always make the parameter INPUT-OUTPUT in this case?

If you configure your application so that the call is made to a remote session and the called procedure does not make any changes to the ProDataSet, then the AVM will needlessly pass the unchanged ProDataSet back to the caller, creating unnecessary network traffic. This is why the INPUT mode is still useful.