Can you provide details on how the /IAS FUNC=RECONFIG command works and how to better use it in production?
Article ID: 41439
Updated On:
Products
Issue/Introduction
Can you provide details on how the /IAS FUNC=RECONFIG command works?
Does it go over the whole IAS Agent definition file, trying to establish/removing the connection only for the modified agent definitions or does it disconnect and then reconnect all the agent defined, regardless of the fact that their definitions were changed?
Which operations are really performed by this command both on Mainframe and Agent side?
Would it be safe to use the command on a regular basis, so also in the middle of the business day on a production environment and is there any best practice about the frequency of the command in production in terms of resources consumption, workload management and performance impact versus the Agent side?
Environment
Component:
Cause
In CA 7 IAS Component (both 11.0 and 12.0), the /IAS,FUNC=RECONFIG command requests CA Integrated Agent Services (CA IAS) to activate additions, deletions, and changes made to agents defined in the IASAGENT DD statement.
Resolution
When you do the /IAS,FUNC=RECONFIG command, IAS will read the entire IASGENT file and do a DNS LOOKUP for each Server defined. This command is pretty expansive, meaning it takes resources, especially depending on the amount of Agents defined to the IAS Agent file. So IAS attempts to reach out each Server present in the IASAGENT file again and refresh the connection, that's why it is better to do it only when needed.
IAS invokes an IBM facility using the IBM EZASMI macro with TYPE=GETHOSTBYNAME or GETADDRINFO (depends on whether you are IPv4 or IPv6) to do domain name lookups. These are only done once (e.g. at startup or during a RECONFIG) and IAS stores the address in memory.
Regardless of whether you use a DNS name or an IP Address to define the Agent in the IAS Agent file, after a RECONFIG you will always get messages written to both the CA7 Browse and CA7 log datasets. If unsuccessful, you will get the CIAS-41 message, while if successful, you will get CIAS-07 messages (multiple per agent as the agent has different components).
We have two queues of messages, high priority and normal. The only messages that go into the high priority queue are the messages generated by RECONFIG. They will all be processed before any normal messages (job or command requests).
The RETRYINTERVAL, RETRYCOUNT and SLEEPTIME set in the IAS Agent definition file for each AGENT entry, determine how often IAS attempts to connect to the agent that is in ‘NO’ status after startup and when sending jobs or commands.
CA 7 scheduling activity will not be frozen during this activity because the DNS lookup is done under a separate subtask. Existing work will continue to be processed. All results (agent job feedback, reconfig feedback) are added to a queue for processing by CA 7. This is no different than CA 7 processing 100 jobs versus 9000 jobs.
The command should not affect the active workload, even if it attempts to reach out to each server in the file.
When agents are removed from the IAS Agent definition file, the product no longer attempts to send any messages to that agent. However, the CA 7 Manager most probably will still be defined to the agent, so this agent will attempt to send messages back to the Manager unless you update the agentparm.txt file and remove the manager definition.
The RECONFIG command can be issued at any time but you need to take into consideration that you are tying up resources by repeatedly issuing RECONFIG.
If you add agents on a daily basis, try to add them at one time and issue a single RECONFIG. If you don’t add agents, there is usually no need to issue the command. The exception to this is if you lose connectivity to one or more agents, it may be necessary to issue the RECONFIG to get reconnected. Typically if you stop and restart an agent (already defined to the Manager) it will automatically reconnect.
Make sure you always have the latest IAS and CA7 GA PTFs applied to provide the complete descriptive information on the LAGENT command display and the better interface functionality.
Also, if you add agents frequently, add the ADDAGENT parameter to the MANAGER statement. This allocates additional storage for future agents that might be added (so you don’t have a CA 7 outage).
Once IAS connect to an agent, the LAGENT status is at that moment. The RECONFIG basically updates the status of all agents. So, if you have not sent any messages to an agent for days, the LAGENT will show the status from days ago (assuming the agent has not be stopped and restarted).
Only if the agent was already defined to the Manager and stopped and restarted the connection is initiated from the distributed side. If the agent was never in the agent definition file the connection starts from the Manager side.
How long it could take a RECONFIG is more dependent on how a site has TCP/IP set up, not CA 7.
In an acceptable situation it takes maybe 15-20 seconds wall clock time to go through 300 agents. There are tools on the web which can provide more information of this process at your site.
For example, https://www.ultratools.com/tools/dnsHostingSpeed.
Assuming you have the latest IAS and CA7 maintenance, issue the LAGENT command and check the 'Active' column. You may see YES, NO_CON, NO_DNS, NO_MSG, NO_SOC. When all agents have been processed, you should not see NO (unless it is an alias name). This will provide a good indication of how long RECONFIG takes at your site.
Regarding when to do a RECONFIG it really depends on how often you add or remove agents and if you need to use them right away. Ideally you would want to do a RECONFIG when you are not running many jobs to agents.
Feedback
