We are using PSUtilities.misc:makeSystemCall svc to run an .exe file through a command.
(the command runs a ws_ftp exe to SFTP a file)
If we run the svc, we are getting a status code of 128 (I believe the java svc is exiting abnormally).
This was working fine prev and we are facing this prob now. The same svc is working fine in TEST env.
There are no changes done to the env or to the svc.
Could you please help us in resolving the issue.
The 128 is the return code from the command line (the OS). Determine what that code means for your OS.
Thanks for the quick reply Reamon.
I searched in google what this status code means. All I could get is this code will be returned when the ‘process’ process.exitValue() in your java svc exits abnormally.
Our OS is windows 2003 server.
The same command when given in Start/Run works absolutely fine but when given to the svc returns a code of 128.
extended settings looks fine.
Could you pls let me know if I am missing some thing here.
It is returned when the command line execution exits abnormally.
http://www.hiteksoftware.com/mize/Knowledge/articles/049.htm indicates 128 is “There are no child processes to wait for.” This would seem to indicate that the Java code did not invoke the command line program successfully.
Keep in mind that when executing a command via this mechanism, there is no path and no environment variables. If you’re depending on those you may need to adjust. Also, you may need to invoke command.exe instead of the program directly. There is material on the web that covers some of this. It can be more involved than one might expect it to be.
Below is the code we are using in wM java svc.
This code was working fine from wM 7.1 till recently, but now we are getting status 128.
Also, while saving a java svc, we are getting an error “cannot compile due to the below errors” and there are no errors listed.
FYI, we have different versions of java in dev and test.
As the svc is not working as expected in dev, we migrated the java svc from TEST.
It seems some where the settings got corrupted
Could you please guide us here if you find some thing.
// DOS Syntax: cmd.exe /c ‘command’
// Example: cmd.exe /c copy log.txt log2.txt
IDataCursor idcPipeline = pipeline.getCursor();
String strOutput = "";
String strError = "";
String strCommand = null;
strCommand = (String)idcPipeline.getValue();
String strSynchronous = (String)idcPipeline.getValue();
Process process = null;
process = (Runtime.getRuntime()).exec(strCommand);
// Provide an outlet for IO for the process
BufferedReader ir = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader er = new BufferedReader(new InputStreamReader(process.getErrorStream()));
while ((line = ir.readLine()) != null)
strOutput += line + '\n';
while ((line = er.readLine()) != null)
strError += line + '\n';
catch (Exception e)
throw new ServiceException(e.toString());
if (strSynchronous.equals("true") && process != null)
int status = process.exitValue();
The command we are using looks like below.
cmd.exe /c E:\WSPROFTPClient-Licenced\wsftppro.exe -u xxx -w yyy -s local:E:\webMethods7\IntegrationServer\ApplicationData\zzz.txt -d “Shared Sites!FFF:/data/”
The same command given in Start/run works fine but when to the java svc (code given below) throwing a status 128.
This says some settings needed to run java svc are missing.
Could you please help us
You probably ought to resolve this first. This could be due to a jar file conflict.
Thanks again Reamon…
We could resolve the issue finally…
We noticed that the system env variables were set up differently in dev to that of TEST env.
We changed the env variables and deleted JAVA_HOME path.
After the reboot, the issue is resolved and the java svc is working as expected.
At this point I do not tell wht exactly went wrong. We are investigating further to understand the cause of the issue as we did not do any changes to the system recently.
Your swift response gave us so much confidence that we could solve this problem despite having minimal java knowledge.
Thanks again for being there for us…