SCM doesn't connect with build servers

Products

• CA Harvest Software Change Manager
• CA Harvest Software Change Manager - OpenMake Meister

Issue/Introduction

SCM not connecting to Openmake 2012 build server when running a process workflow. The same scripts work fine with 2008 server. We are in a process of migrating from 2008 server. I worked with the Openmake support team and we found that if "nointeractive" is removed from script, the build runs fine. We tested by running the script straight from Command prompt. Please help. thank you.

-rport "5500"
-prg "sv_workflow_receiver.bat"
-syn
-nointeractive
-er "********"
-m ********
-args "AUTO_DEMOTE=false,AUTO_DEPLOY=false,AUTO_PROMOTE=false,BROKER=scmp,HARUSER=skum01f,HARUSER_EMAIL=*******,HAR_VERSION=12,HAR_VPATH=TEST_Windows_Setup,ITEM=###NO_ITEM###,PACKAGE='Dummy_package',PROJECT=TEST_Windows_Setup,SCHEDULE=FALSE,STATE=STG,WF_DEBUG=TRUE"

Environment

Release : 12.6

Component : CA Harvest Software Change Manager

Cause

Here's what I've found about the -nointeractive option of the hexecp command:

With r12FP1 and above a new parameter was added for hexecp called -nointeractive which overcomes the following problem: Running synchronous hexecp's against a multi-user agent on Windows would eventually start to fail. It was found that an ACL (Access Control List) that the agent uses reaches its quota. For synchronous hexecps the multi-user agent accesses this ACL which is shared by all processes on a machine and adds 3 ACEs (Access Control Entries). A typical ACL would store about 85 ACEs. When synchronous hexecps are done, we remove those 3 ACEs. However, other applications could be using up this ACL and not freeing up their ACEs when they're done, and the Harvest agent is exposing that Windows resource problem. In any case, non-interactive programs run by hexecp don't need to create those ACEs, and as workaround solution, we're adding an option for hexecp to bypass creating ACEs if a user is running a non-interactive program against a multi-user Windows agent. ++ The implication of this is that if you were to reboot the system the hexecp may work for a while before the problem manifests itself.

So I am wondering if “-nointeractive” is really needed in your case.  Some possible options at this point are:

• Remove the “-nointeractive” option from the UDP that executes your hexecp command.  This appears to solve the problem when running it from the command prompt, and might not even be needed.
• Switch your hexecp command to run asynchronously (-asyn) instead of synchronously (-syn).
• In the notes from some of the previous cases I found, running the agent in single-user mode instead of multi-user mode solved the problem as well, but this might not be a viable workaround since it involves running the agent for a single user in the foreground, rather than running it as a service in the background.

 

Resolution

Suggested to remove the -nointeractive option from the hexecp command inside the build script and test to see if the problem is resolved, and if any other problems arise as a result.