Reassign/Release Processing occurs when a member is deleted from a Move Request or the status of a Move Request changes to DELETED or MOVED TO some level (that is, the move is complete). If a member is deleted from a Move Request, only that member is processed. When the status of a Move Request changes, each member in that Move Request goes through this processing.
During Reassign/Release Processing, the Inventory Records for the member in question are examined. If no Inventory Records exist for this member or if the member is not assigned, processing halts. If the member's assigned-to Move Request number is blank or if the member is assigned to the Move Request being processed, processing continues. If the member is assigned to a different Move Request, its assignment is not changed.
CA‑PanAPT maintains a cross reference on the database of all Move Requests to which each member is defined. This cross reference is used during Reassign/Release processing to find the Move Request with the earliest scheduled final move date for the members being processed. Move Requests that have been completed (are in a status of MOVED TO some level), and Move Requests that are in a DELETED status or one of the Backout statuses are skipped during this process.
If a member is to be reassigned, CA‑PanAPT looks at the Reassign/Transfer flag on the Control File to determine if the assigned-to user should also change. If this flag is set to 2, the member remains assigned to the same user. If the flag is 1, the member is transferred to the owner of the new Move Request. If the member is being reassigned because the Move Request was moved to its final destination (as opposed to being deleted), CA‑PanAPT then examines the Move Req Assignment Option on the Control File to determine if concurrent development assistance is enabled (a value of 3 in this field). If it is, CA‑PanAPT sets the concurrent development flag for all occurrences of this member in every Move Request except the one from which it is being released. This serves as an indication that other changes might need to be consolidated into the versions being moved. The Move Requests cannot be moved until the concurrent development flag is manually reset.
If no other Move Requests containing the member are found, the Library Code record for the Library Code containing this member is read. If the Auto-Release flag is set to Y, the Inventory Record for this member is released, that is, its assignment flag is set to N, and its assigned-to user and Move Request are blanked out. If the Auto-Release flag in this Library Code is N, the Inventory Record's assigned-to Move Request is blanked, but the assigned-to user is not changed.
If any members are reassigned or released during online processing, messages are written to the ISPF Log that indicate what changes were made. (See the "Control File" chapter for details about the Reassign/Transfer flag; the "Library Codes" chapter for more information about the Auto-Release indicator; and the "Inventory Records" chapter for more information about the assignment fields.)
Note: CA‑PanAPT performs no authorization checks during Reassign/Release Processing. If a user who does not have authority to assign or release Inventory Records deletes a member from a Move Request, this member can be reassigned or released despite this user's lack of authority to perform these tasks explicitly.
Reassign/Release processing works differently for a rework Move Request than others. A rework Move Request is one that was created using the Copy for Rework action. CA‑PanAPT always attempts to reassign members back to the original Move Request before considering any other Move Requests.
|
Copyright © 2004 CA.
All rights reserved.
|
|