The manual I have says the following:
"Copy sdconf.rec to SDCONF.REC data set
1. Download the sdconf.rec file from the RSA Authentication Manager Security Console.
2. Use your tool of choice to copy sdconf.rec in to the SDCONF.REC data set on the z/OS system.
Copy the file in binary mode. "
I have searched the site looking for this file. All I find are typically older references to it. Is there such a thing as the RSA Authentication Manager Security Console still?
You can generate and download sdconf.rec from RSA Security Console primary instance. You must be administrator to generate and download sdconf.rec.
also note: z/OS is a standard UDP agent, and you can essentially use an sdconf.rec copied from any existing working agent that uses an sdconf.rec, if you cannot get to the Security Console and download a fresh one.
IBM MFA for z/OS - RSA Standard Agent Implementation Guide
Lastly, on 8.x.x.x.x AM servers, though we do not recommend this, there is an sdconf.rec on the filesystem that the radius engine uses, so it can process authentications.
So, failing all other ways to obtain an sdconf.rec, from the command line of the RSA AM server itself, look for: /opt/rsa/am/radius/sdconf.rec.
It is a binary file so you'd need to sftp a copy off the machine to use it elsewhere.
The sdconf.rec tells the agent who the primary is, and who the replicas are if you did an automatic rebalance before generating it. It also tells the agent how long to wait for a response from the AM server, and how many times to retry before giving up and trying another replica. 5 retries is a holdover from a long time ago, when there might have been an unreliable network (think X.25), so you wanted a lot of retransmissions to make sure your authentication request packet got through. But for a long time, networks have been pretty reliable, there for if an AM server did not respond after 3 requests (initial and 2 retries or attempts), it very likely will not reply after 6 attempts (initial and 5 retries).
So 5 retries is most often a waste of time if it comes into play.
Changing Retry attempts begs the question: should you change the re-transmission timeout or Maximum time between each retry (assuming no response)? Short answer, usually not, only exception might be a single increase to 6 seconds in a very busy agent - very busy being 10s of thousands of users on that agent in a short amount of time.
If you make this timeout too short, less than 5 seconds, you do not give the AM servers enough time to respond, so your agent sends a second or subsequent authentication request while the 1st response is in transit. This results in a re-use failed authentication, because the same token-code is used for two authentications.
I have seen one occasion or situation where increasing this timeout to 6 seconds actually helped to solve a problem. Customer was up north, where there is a lot of snow during the winter, and during snowstorms up to 17,000 employees were told to work from home and use a VPN connection to work. When all of these users started working during the morning of the snowstorm, the AM server logs showed 100s to 1000s of authentication failures due to re-use. The AM servers were so inundated with the authentication requests that during peak usage it was taking the AM server about 5.1 seconds to respond to an authentication request. This occurred between 7:30-9:30am, there were no problems after 9:30am. We increased the max timeout to 6 seconds, generated and downloaded a new sdconf.rec, placed the file on the VPN server and no more problem.
You can generate and download sdconf.rec from RSA Security Console primary instance. You must be administrator to generate and download sdconf.rec.