The programming notes that follow may be relevant as you code your application interface:

• Optional input parameters on the OSREQ macro may be omitted. OAM processing identifies omitted optional input parameters as follows:
  • If the optional input parameter has not been specified on any of the OSREQ macro forms (MF=L, MF=M, or MF=E), the parameter pointer is zero.
  • If the optional input parameter is specified on one of the OSREQ macro forms but the value identified by the parameter is null, then the parameter has the appropriate null value. The concept of null is different for different parameters. A null RETPD parameter value is zero. A null STORCLAS parameter value is indicated by either a length value of zero or the entire name containing blanks.
  • If the optional input parameters MGMTCLAS and STORCLAS are omitted, these parameter values are supplied by the ACS routines, as described in OSREQ keyword parameter descriptions.
• If you do not specify a collection name on any function other than ACCESS or UNACCESS, STOREPRT, or STOREEND a return code and a reason code are generated, and the requested function is not performed. The collection name is required if the function is to be completed. If a specified collection name does not exist in the catalog for any function other than STORE, STOREBEG, ACCESS, or UNACCESS, a return code and a reason code are generated.
• When an MVS catalog entry is created for a new collection on a STORE or STOREBEG function or the specified storage class or management class is overridden by the ACS routines, a warning return code of 4 and a reason code with the fourth byte indicating the processing status are generated. The conditions are possible in all combinations. The processing status in the fourth byte of the reason code contains individual bits that indicate the presence or absence of each of the conditions.
• The caller must establish synchronization points for DB2 inserts, updates, and deletes for the OSREQ functions STORE, STOREEND, DELETE, CHANGE, and RETRIEVE as soon as possible (to minimize DB2 timeouts or deadlocks), depending on return code. The synchronization must occur within 24 hours for objects stored in the file system (to avoid loss of data).
• In order to allow your application to establish synchronization points in DB2, the DBRM from your application program must be bound in the CBRIDBS plan. The SAMPLIB job CBRABIND (or CBRIBIND for DASD-only users) is used to create the CBRIDBS plan in DB2. For more information on the CBRABIND, CBRIBIND jobs, and CBRIDBS plan, refer to the z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support.

  If your application uses the IADDRESS keyword, the application connection to DB2 must be established and have an open thread. The plan identified for the open thread can include any DBRMs or packages that are needed by the application. However, it must also contain the DB2 packages created by the CBRIBIND job for the CBRIDBS plan. For more information on the bind jobs or on the DB2 plans, refer to z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support.

• If the OSREQ macro is invoked and either the OSREQ parameter list or the token area is in nonaddressable storage, a program check occurs within the executable OSREQ macro code. For diagnostic purposes, the potential reason code for the specific error is preloaded into register 0 before storage is accessed. The register 0 contents in the abend summary should contain a reason code that indicates the parameter or storage problem. This also applies if the token contents have been corrupted before invoking the OSREQ macro.
• If the return code word or reason code word are not located in addressable storage, the return and reason codes are only found in general registers 15 and 0, respectively, upon return from OSREQ.