What is the best procedure to activate a new IODEF when Astex is active?
Article ID: 115805
Updated On:
Products
ASTEX Performance
Issue/Introduction
In today's z/OS environments you can dynamically activate a new system wide IODEF. You can do this by LPAR or across multiple systems.
When using CA Astex on multiple LPARs/systems what is the best procedure to follow when activating the ne IODEF?
Since IODEFs are basically system managed tables of devices that can be dynamically changed and CA Astex must monitor the devices it is always good to be aware of the Astex started task status at the time the IODEF is being activated. Are their any special Astex processes executing at the time? How many Astex systems are executing across multiple systems?
CA Astex will build a UCB table at startup containing all the current UCB addresses that are specified in the startup parms. This means that you can activate a new IODEF if none of the changes you have made affect any of the Astex managed UCB addresses.
However, if there are UCBs that may have their status changed when the new IODEF is activated then you could experience abends when the specific UCB is called for in a allocation. This also includes 3rd party products that may allocate UCBs dynamically.
S0C4 abends are the most popular that will be experienced.
When using CA Astex on multiple LPARs/systems what is the best procedure to follow when activating the ne IODEF?
Since IODEFs are basically system managed tables of devices that can be dynamically changed and CA Astex must monitor the devices it is always good to be aware of the Astex started task status at the time the IODEF is being activated. Are their any special Astex processes executing at the time? How many Astex systems are executing across multiple systems?
CA Astex will build a UCB table at startup containing all the current UCB addresses that are specified in the startup parms. This means that you can activate a new IODEF if none of the changes you have made affect any of the Astex managed UCB addresses.
However, if there are UCBs that may have their status changed when the new IODEF is activated then you could experience abends when the specific UCB is called for in a allocation. This also includes 3rd party products that may allocate UCBs dynamically.
S0C4 abends are the most popular that will be experienced.
Environment
z/OS
any level of CA Astex
any level of CA Astex
Resolution
The best policy is to determine if any UCBs being managed by Astex will be affected by the new IODEF. If yes, then plan to shutdown any Astex subsystems that are active on the systems to be affected by the new IODEF.
1) Review all UCB changes
2) Match the devices to the Astex startup parms device table listing
3) Shutdown any affected Astex subtasks on the affected systems with the new IODEF
4) Activate the new IODEF and follow any quality assurance testing required
5) Activate Astex started tasks across the affected systems, all should come up totally clean with no error messages
1) Review all UCB changes
2) Match the devices to the Astex startup parms device table listing
3) Shutdown any affected Astex subtasks on the affected systems with the new IODEF
4) Activate the new IODEF and follow any quality assurance testing required
5) Activate Astex started tasks across the affected systems, all should come up totally clean with no error messages
Feedback
Yes
No
Powered by
