Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
![]() Create_Cascaded_UR (ATRCCUR2, ATRCCUR3, ATR4CCUR) z/OS MVS Programming: Resource Recovery SA23-1395-00 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A work manager calls the Create_Cascaded_UR service to create a
UR that is associated with an existing UR. Typically, a work manager
would do this when a single work request involves multiple work managers.
The initial work manager would obtain the initial work context that
represented the work request. When the work request moved from the
execution environment of the original work manager into another work
manager's environment, the latter work manager could obtain a new
work context to represent the work request, allowing it to manipulate
the work context as it needs. There are three versions of Create_Cascaded_UR,
each with different parameters.
By using the Create_Cascaded_UR service to create a new UR for the new work context that is cascaded from the original UR, the second work manager ensures that the resources changed by the work request when it is running in its new execution environment are committed or backed out atomically along with those resources changed while the work request was running in other environments. A work manager that creates a cascaded UR is responsible for informing RRS when the application running under the UR is application execution complete by calling the Set_Side_Information service specifying the ATR_APPL_COMPLETE information identifier. Express_UR_Interest (ATREINT2, ATREINT4, ATREINT5 or ATR4EINT) can also be used to create a cascaded UR, if the creator also wants to express interest in the UR. Multisystem cascaded transactions: When one work manager requests another work manager, residing on a different system, to become part of an existing work request, the requesting work manager is responsible for transferring all of the data needed by the new work manager, including the UR token representing the work request. The new work manager may then use the Create_Cascaded_UR service to create a new UR, associated with a new work context, to be cascaded from the received UR token. As with normal (non-multisystem) cascaded transactions, a work manager that creates a multisystem cascaded transaction is responsible for informing RRS when the part of the application executing under a multisystem cascaded UR is complete by using the Set_Side_Information service to mark the UR as application-complete. See Cascaded transactions for more information about cascaded transactions, including Multisystem cascaded transactions for more information about multisystem cascaded transactions. EnvironmentThe requirements for the caller are:
Programming requirementsEither link edit your object code with the linkable stub routine ATRRCSS (31 bit) or ATRR4CSS (64 bit) from SYS1.CSSLIB, or LOAD and CALL the callable service. The high level language (HLL) definitions for the callable service are:
RestrictionsFor the call, the child UR state must be in-reset and the parent UR must be in-reset or in-flight. The parent UR must not be in local transaction mode. When the resource
manager issues the call in SRB mode:
A caller that is PKM 8–15 problem state must specify a parent_UR_token for a UR that is associated with a DU native context associated with a task in the current home address space, or a private context owned by a PKM 8–15 problem state resource manager registered in the home address space. A caller that is PKM 8–15 problem state must specify a child_context_token for a context that is either a DU native context associated with a task in the current home address space, or a private context owned by a PKM 8–15 problem state resource manager registered in the home address space. Note: A call to the Retrieve_UR_Data service that does
not specify ATR_EXTENDED_STATES for the states_option could
cause a UR to go into an in-flight state. Once a UR has gone in-flight,
it can no longer be made into a cascaded UR.
Input register informationBefore issuing the call, the caller does not have to place any information into any register unless using it in register notation for the parameters, or using it as a base register. Output register informationWhen control
returns to the caller, the GPRs contain:
When control returns to the caller, the ARs
contain:
Some callers depend on register contents remaining the same before and after issuing a call. If the system changes the contents of registers on which the caller depends, the caller must save them before calling the service, and restore them after the system returns control. Performance implicationsNone. SyntaxWrite the appropriate call as shown in the syntax diagrams. You must code the parameters in the CALL statement as shown.
ParametersThe parameters are explained
as follows:
ABEND codesThe call might result in an abend X'5C4' with a reason code of either X'001F0000' or X'001F0001'. See z/OS MVS System Codes for the explanations and actions. Return codesWhen the service returns control to the resource manager, GPR 15 and return_code contain a hexadecimal return code.
ExampleIn the pseudocode example, the
calling program attempts to create a parent-child relationship between
the current unit of recovery and another unit of recovery that is
to be the parent UR of the current UR. Storage for the call parameters
has already been allocated.
![]() ![]() ![]() |
![]() |