V3R2M0 からのBIFFコードとしてプロシージャーのポインターを示す %PADDR があるが
どのような使用目的があるのかが、よくわからない人も多いと思われる。
直接、プロシージャーを呼べばよいものを、何故ポインターを指定する必要があるのかが
明確でないのかも知れない。
%PADDR を使用する目的は不明な汎用的なプロシージャーの実行を可能にすることである。
例えばある親プログラムから子の *SRVPGM を呼び出すことを想定しよう。

PGMA はデータ・ベース MYFILE をアクセスして一覧表を印刷する。
PGMB はデータ・ベース MYFILE をアクセスして画面に表示する。

そこでデータ・ベースをアクセスする部分は共通しているので、ひとつの *SRVPGM に
まとめるものとする。処理は次のようになる。

PGMA から開始 » SRVPGMA で MYFILE をアクセス » PGMA に戻って一覧表を印刷
PGMB から開始 » SRVPGMA で MYFILE をアクセス » PGMB に戻って画面表示

いずれの場合も MYFILE をアクセスする SRVPGMA にキーなどのレコードを取得するための
情報を渡すことになるが、同時に次の処理としての「一覧表印刷」や「画面表示」の処理だけ
をプロシージャーとして定義しておいて、SRVPGMA にプロシージャーのポインターを渡してやり、
PGMA や PGMB に戻ってからプロシージャーを実行するのではなくSRVPGMA の中で
親プログラムのプロシージャーを呼び出すように記述することができる。

つまり SRVPGMA のプロシージャーを呼び出すときに

CALLP  CHILD(SHCODE:%PADDR('MYPRINT')

のようにして親PGM の MYPRINT というプロシージャーのポインターも渡してやる。
子*SRVPGM では MYFILE を SHOCDE を使ってアクセスした後で

CALLB  PROC

のようにして、親PGM のプロシージャーを子自身が実行することができるのである。
さて、このような処理にどのような利点があるのであろう？
読者は処理を複雑にしているだけのように思われるかも知れない。
この処理の意味は MVS である処理の分離である。
親PGM はユーザー・インター・フェースの部分しか行っていない。
これに対して子SRVPGM はデータ・アクセスの部分しか行っていない。
さらにはプロシージャーを直接、呼ぶよりは繰り返し処理となるとポインタによる操作のほうが
パフォーマンスが向上する利点もある。
不明な名前のプロシージャーを動的に実行できる汎用性を備えたいのであれば%PADDR の
使用が必要となる。