Suppose that Procedure A has the ProDataSet definition for dsOrder used in the example procedure. After filling the ProDataSet, it passes it to Procedure B, as shown:

RUN B.p (INPUT DATASET dsOrder BY-REFERENCE).

Procedure B has the same static ProDataSet definition. Procedure B obtains a reference to DATASET dsOrder without it being copied. Procedure B can then reference the current records in ttOrder and ttOline directly. Buffer currency in Procedure B is the same as in Procedure A. For example, if Procedure B is responding to a record fill event for the ttOrder table, then the current record in ttOrder is the one just filled:

IF ttOrder.ShipDate NE ? THEN 
  ttOrder.PromiseDate = ttOrder.ShipDate.

Procedure B can also navigate through the ProDataSet and its temp-tables:

FOR EACH ttOline OF ttOrder:
…
END.

On return to Procedure A, any changes made by Procedure B are visible to Procedure A because the ProDataSet is the same object.

If B.p is remote from A.p, then the ProDataSet is copied into Procedure B because it is an INPUT parameter. It is not copied back to Procedure A. If it were defined as an INPUT-OUTPUT parameter, then any changes would be passed back across the network to Procedure A and the end result would be the same as if it had been called locally. Therefore the INPUT-OUTPUT mode should be used when changes can be made that should be seen by the caller. The INPUT case is supported so that when the called procedure does not make any changes, the ProDataSet is not needlessly copied back to Procedure A. The OUTPUT case is supported so that if the original data in the ProDataSet is not used by Procedure B and only Procedure B's changes (creates or the result of a FILL) are to be used and passed back to Procedure A, the ProDataSet is not needlessly copied into Procedure B.