I have an issue with WFA and the "add volume to dataset via Perl" command. My OCUM server is slow in creating the job and the workflow job appears to fail even though the job is still running on the OCUM server. SSH servers on Windows are not allowed and an exception won't be approved, and migrating 4200 primary and nearly 1k secondary volumes into a Linux PM instance is not practical either.
Is there a way to adjust the timeout without changing the certification of the command?
We are trying to position WFA to replace some homebrew scripting and that has required custom commands with the customer asking how it is better to be using WFA as the commands are not necessarily supported.
I have already had to use the custom PERL refresh monitor and wait on refresh commands here in the community, as well as create my own for changing a volume security style to NTFS as we don't use qtrees. The more I have to remove from certified status, the less the customer is seeing it as a benefit over their own homebrew options.
Thanks in advance,
Message was edited by: Scott Chubb only 1100 or so secondary volumes, that should have been 1k secondary jobs not 10k.
Solved! See The Solution
5 REPLIES 5
Some related post.
Unfortunately, at present there is no way to increase the timeout without losing the certification.
We can file an RFE for the same. Can you raise a support case.
It is definitely my DFM server as the job does actually complete, only a timeout on the wait in WFA. We have identified on the new DFM server that it is taking an inordinate amount of time to add a job to some of our larger datasets even on the CLI. We are having the server team look into that, I was hoping that I could adjust the timeout to allow the job to complete without error until we can identify where the slowness on the new system is coming from.
That is the easy part...I would even change it in the code directly if that were an option. Customer sign off is going to require me to justify every command that is not certified and 100% supported which is where the dilemma resides.
I am actually more likely to let the job report the timeout(and show a failure) in WFA and rely on the scripts we already have in place to identify when a volume was not added properly rather then add another non-certified command.