(ZOS) Registering an external address space with a local daemon group or cell using optimized local adapters
For optimized local adapters to make an outbound call to the local daemon group or an inbound call to a WebSphere Application Server cell, we must bind the current address space to the WAS daemon group and establish connection attributes.
The WAS daemon group must be active on the same z/OS image that the register request originates from. If we are using the Customer Information Control System (CICS ), the task-related user exit (TRUE) program must be activated before a connection is made between CICS and WAS.
If we are using the Information Management System (IMS™), the optimized local adapter external subsystem interface must be installed and activated before applications begin calling the optimized local adapter APIs.
Tasks
- Define the parameters to use in the connection. When we are using CICS, the reg_flag_trans flag is set to 1 to indicate that the connections created under this register name are to be attached to RRS and joined with the work done in a WAS global transaction. Setting this flag to 0 (zero) indicates that there are not connections created under this register name that are to be attached to RRS and joined with the work done in a WAS global transaction.
For inbound calls, a security context is always propagated to WAS and it contains the user ID of the address space making the request. For CICS, the reg_flag_C2Wprop flag propagates the user ID that the CICS task is currently using, rather than the user ID from the address space.
For outbound calls, the reg_flag_W2Cprop flag tells WAS to propagate the user ID to CICS. CICS then attempts to start the target program with that user ID.
To read more about using security, see the topics, Securing optimized local adapters for inbound support and Securing optimized local adapters for outbound support.
- Verify that the register name is not already used in another cell that this address space is connected to. An address space verification is done to ensure that the register name is not already in use by another cell. If the register name is used by another cell, an error return code is passed back and the register request fails.
- Set up the client address space native language application to call the BBOA1REG API. The daemon group and server name are passed, and an input string that represents the name, or register name used by the WAS daemon.
A 0 (zero) return and reason code indicates that the client address space is now bound to the WAS daemon group and servered. Future calls that interact with this WAS must either have the supplied register name or a specific connection handle created using that register name accompanying them.
After completing this task, the passed register name string is reserved in the current address space. No other register calls can be made with this token until an unregister call is received for it.
If we use the minimum connections setting on this call, the result is a pool of connections that are pre-established with the target server and waiting for requests. Also, a registration entry context or control block is created and associated with the register name string. Each unique register name has a register context. ultiple register names with the same address space and thread can bind with one or more WAS daemon groups.
What to do next
To read more about the BBOA1REG API, see the topic Optimized local adapters for z/OS native APIs.
Related:
Optimized local adapters on WAS for z/OS Install a resource adapter archive Enable the server environment to use optimized local adapters Enable optimized local adapters support in IMS Enable optimized local adapters support in CICS Secure optimized local adapters for outbound support Secure optimized local adapters for inbound support Optimized local adapters for z/OS APIs