The SCLM bind processor in the above examples only works for binds on the machine where SCLM exists. For binds on other LPARs, the bind processor must use file tailoring to create a job to perform the bind. If the JES queue is shared between the LPARs then the job can be submitted from the bind exec with the appropriate routing parameter to submit the bind on the other LPAR. If the JES queue is not shared then a more complicated delivery of the bind JCL will be needed, possibly using FTP.

If you want to implement binds on other LPARs through a submitted job, it is best to create them in the Build user exit or Promote user exit or both. This way, only one bind job must be created for a package build or promote. See User exits for more information.

For example, assume that your development and test environments reside on the same LPAR that SCLM is running on, but your PROD database and executables are on a different LPAR. In this case your bind processor would use the DB2CLIST method of binding for the DEV builds and promotes to TEST. However, when the promote to PROD is actioned, the DB2CLIST and DB2OUT members are still promoted to PROD but no bind is done. Instead, once the promote has finished the SCLM work, the promote copy user exit or purge user exit is invoked. The exit is coded such that a list of the DBRMs being promoted is extracted from the PROMEXIT file. The processor then builds a job using ISPF file tailoring techniques that will do the bind for all the required members. The generated job is transferred and submitted to the production LPAR.