Jobs not executing correctly with multiple WINSCP jobs

Document ID : KB000014119
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

We have a job running on the following agent version: 

CA Workload Automation Agent 
for Microsoft Windows 32-bit 
Version R11.3, Service Pack 2, Maintenance Level 1, Build 525 

Having problems running multiple WINSCP jobs on the same agent at the same time.

Question:

We have a job running on the following agent version: 

CA Workload Automation Agent 
for Microsoft Windows 32-bit 
Version R11.3, Service Pack 2, Maintenance Level 1, Build 525 

Here’s a recap of what the issue happening with the jobs as reported by the app team: 

• iXp wrongly reports jobs as being successful sometimes, even when they don’t run to completion. I can tell the jobs haven’t run to completion because there is no log file, or just a partial log file; and there is no output file in the expected location. 
• I believe this issue is being caused by WinSCP – a new data transmission package I’m testing with in SIT. When you and I were looking at this last month, this issue was happening with many jobs – most of which were not WinSCP jobs; but, I had been testing with WinSCP at the time. My theory is that WinSCP somehow ‘crippled’ (ha ha) the Autosys Agent, so that it would report jobs as successful without actually running them. When we restarted the Agent, the issue cleared up temporarily. 
• We are not having this issue in other environments, even though the same level of Windows maintenance has been applied. So this doesn’t seem to be related to Windows maintenance. We just received maintenance on March 4th, with no change in the symptoms. 
• I stopped testing with WinSCP last week, and looking back at the log files for the rest of our batch, I didn’t see the issue occurring. 
• I started testing with the WinSCP jobs today, and began seeing this issue again. It normally happens regularly between 2 jobs which are doing WinSCP transmissions – one job will execute correctly and the other job will not execute – but both will be reported as successful. I also saw this happen with 1 WinSCP job and a non-WinSCP job being started at the same time – the WinSCP job executed correctly, but the non-WinSCP job didn’t execute and reported success. 
• When I open up 3 command windows and run 3 WinSCP jobs simultaneously outside of Autosys – they all execute correctly and produce the expected output. When I run these same 3 jobs via Autosys, 1 of the jobs always does not execute as expected, but reports success. When I run the 3 scripts via Autosys and skip the WinSCP call in the jobs, they execute correctly every time. 

The WinSCP version they are using is: 

WinSCP version 5.7.6 

Are there any known issues with AutoSys and WinSCP? 

Environment:
CA Workload Automation Agent for Microsoft Windows 32-bit Version R11.3, Service Pack 2, Maintenance Level 1, Build 525
Answer:

The main difference between running a command from the command line and running it as a scheduled job is that the scheduled job creates a new terminal services logon session, and (since the jobs are not marked as interactive) a new console. 

The WinSCP site has useful debugging help: https://winscp.net/eng/docs/troubleshooting#scripting. They recommend using the "/log" parameter to get more information on jobs. That should show more information on scripts that end prematurely. 

Also: https://winscp.net/eng/docs/faq_script_vs_gui and https://winscp.net/eng/docs/guide_debugging_scheduler talk about debugging problems with scripts run from automation. 

Since I can't see how the winscp script is run in the batch file, I don't know if the exit code from winscp is being captured by the batch file and returned as the exit code of the batch file. That way, if winscp fails, the job will fail too. 

They mention that winscp.com scripting opens a new console window. This can be problematic for headless jobs that run entirely in the background. 

If the debugging shows that there is a conflict in multiple jobs trying to attach to the same console, they can try setting: 

oscomponent.su.newconsole=true 

I see in the Frontier_POS.log that there are file transfers being done with scpg3.exe. It's possible that there is a conflict when running two SSH products at the same time. Winscp logging may give more information, and there may be information in the Windows Application Log or the System Log.