Designing your application to access distributed data

You can design applications that access data on another database management system (DBMS) other than your local system. You should consider the limitations and recommendations for such programs when designing them.

To design your application to access distributed data:

1. Ensure that the appropriate authorization ID has been granted authorization at the remote server to connect to that server and use resources from it.
2. If your application contains SQL statements that run at the requester, include at the requester a database request module (DBRM) that is bound directly into a package that is included in the plan's package list.
3. Copy the requester package to any remote server that is accessed by the application via a bind package copy command and include the remote packages in the application plan's package list.
   Recommendation: Specify an asterisk (*) instead of a specific name in the location name of any package entry of a plan so that the plan does not have to be rebound whenever a new location is accessed by the application or a different location is to be accessed.
   
4. For TSO and batch applications that update data at a remote server, ensure that one of the following conditions is true:
   • No other connections exist.
   • All existing connections are to servers that are restricted to read-only operations.
   Restriction: If neither of these conditions are met, the application is restricted to read-only operations.

   If one of these conditions is met, and if the first connection in a logical unit of work is to a server that supports two-phase commit, that server and all servers that support two-phase commit can update data. However, if the first connection is to a server that does not support two-phase commit, only that server is allowed to update data.

5. For programs that access at least one restricted system, ensure that your program does not violate any of the limitations for accessing restricted systems. A restricted system is a DBMS that does not implement two-phase commit processing.
   Accessing restricted systems has the following limitations:

   • For programs that access CICS® or IMS™, you cannot update data on restricted systems.
   • Within a unit of work, you cannot update a restricted system after updating a non-restricted system.
   • Within a unit of work, if you update a restricted system, you cannot update any other systems.
   If you are accessing a mixture of systems, some of which might be restricted, you can perform the following actions:

   • Read from any of the systems at any time.
   • Update any one system many times in one unit of work.
   • Update many systems, including CICS or IMS, in one unit of work, provided that none of them is a restricted system. If the first system you update in a unit of work is not restricted, any attempt to update a restricted system in that unit of work returns an error.
   • Update one restricted system in a unit of work, provided that you do not try to update any other system in the same unit of work. If the first system you update in a unit of work is restricted, any attempt to update any other system in that unit of work returns an error.