We are trying to install the JZOS Batch Launcher. The function consists of three pieces: a load module that must be put into a z/OS PDSE, a sample start proc that can be tailored and put into an appropriate PROCLIB, and sample JCL that can be tailored and put into an appropriate SAMPLIB.
On submitting the job we are getting return code=0101. Below are the trace details which we are getting in the job:
Output from DD:STDENV config shell script:
waiting for child shell process to complete
waitChild()
child shell process exited with exit code 0
waitChild()
Child shell process exited without printing environment; //STDENV should not contain 'exit'
adoptEnvironment()
run()
cleanup()
JZOS batch launcher elapsed time=0 seconds, cpu time=0.040000 seconds
JZOS batch launcher failed, return code=101
cleanup()
~JzosVM()
~JzosVM()
After looking this up and reading more,we then tried to run the job with superuser access and the job ran fine. So we need to know what privileges we require without being a superuser which will enable us to run the job successfully.
Related
I would like to run a jar file using a robot framework test suite, because this test-case is to be included among other test cases.
When the jar is run from the cmd, it produces the expected output, which can take 10 minutes, and then it ends.
My issue is that I'm not capable to detect when the execution of the jar is finished. I tried several keywords combination, in the last attempt I used the keyword Process Should Be Stopped, as shown below, and the result is that the process is always running.
One of my doubts is: which process is running, java? or the execution of the jar?
*** Settings ***
Library Process
Library OperatingSystem
Suite Setup log running on ${properties.hostname}
Suite Teardown Terminate All Processes kill=True
Variables C:/Users/theUser/Desktop/CheckOutRegression/Regression/RegressionScripts/config/properties.py
*** Test Cases ***
Check jar execution
${data}= Start Process java -jar da-1.0-SNAPSHOT.jar importFile1.json importFile2.zip cwd=${properties.pathToScripts} alias=myProc
${wait}= Wait Until Keyword Succeeds 10x 60s Process Should Be Stopped myProc
Log ${wait}
${result}= Get Process Result myProc
Log ${data.stdout}
Do you know how I can check that the execution of the jar file is finished?
Am executing a jar file in remote server using jenkins job build step through publish over ssh.
Input build parameters for the job,say list - a,b,c,d,e
Execution command for publish over ssh -
cd /myjarfilepath
for input in $list
do
java -Xmx1024m -cp myApp.jar com.CommandLineRunner $input
done
job fails with error
ERROR: Exception when publishing, exception message [Exec timed out or was interrupted after 120,000 ms]
It runs successfully for one input. Say if it fails for input b then it gets terminated without executing the jar for c,d,e. I want execute the jar for all the inputs available.
Any suggestions will be appreciated!
Thanks.
Yes this is because of default timeout set to=120000. By updating transfers->Advanced->Exec Timeout(ms). I was able to build for all in loop successfully.
I have a file "myFile.gcode" which contains some G-code commands. As it stands Universal Gcode Sender allows the user to upload a file to be executed. However I would like "myFile.gcode" to be run as soon as the program starts up instead of me having to upload it.
Is this possible with the out-of-the-box .jar file?
.jar available at https://winder.github.io/ugs_website/
If not I have the following idea,
Trace through the code and reverse engineer it to auto run the file. To do this I decompiled the .jar file, but when tracing through the code I'm having trouble finding the starting point (main class) of the code.
In summary, is this possible?
And, what could make tracing this code easier?
Yes there is a new feature for running CLI-commands, download the latest nightly build of Universal G-code Sender Classic and run the follwing:
# java -cp UniversalGcodeSender.jar com.willwinder.ugs.cli.TerminalClient --help
This will print the available parameters and options:
-b,--baud <baudrate> Baud rate to connect with.
-c,--controller <controller> What type of controller firmware we are
connecting to, defaults to "GRBL". These
are the available firmwares: [GRBL, TinyG,
Testing (Delay), Smoothie Board, Testing]
-d,--daemon Starts in daemon mode providing a web
pendant UI
-dr,--driver <driver> Sets and saves the connection driver
setting. These are the available drivers:
[JSERIALCOMM, JSSC, TCP]
-f,--file <filename> Opens a file for streaming to controller
and will exit upon completion.
-h,--help Prints the help information.
-ho,--home If a homing process should be done before
any gcode files are sent to the
controller.
-l,--list Lists all available ports.
-p,--port <port> Which port for the controller to connect
to. I.e /dev/ttyUSB0 (on Unix-like systems
or COM4 (on windows).
-pp,--print-progressbar Prints the progress of the file stream
-ps,--print-stream Prints the streamed lines to console
-r,--reset-alarm Resets any alarm
-v,--version Prints the software version.
-w,--workspace <dir> Sets and saves the workspace directory
setting
Sending a file can be done using the following command:
# java -cp UniversalGcodeSender.jar com.willwinder.ugs.cli.TerminalClient --controller GRBL --port /dev/ttyUSB0 --baud 115200 --print-progressbar --file test.gcode
Connected to "Grbl 0.9z" on baud 115200
Running file "test.gcode"
test.gcode 52% │██████████████████████▉ │ 55/105 (0:00:06 / 0:00:05)
Facing the below error when running the filewatcher job. File that is being watched is already in place.
ctmfw /amex/RSM_1099CTEST.txt CREATE 0 1800 10 3 0 N 0001 2359 NO_MIN_AGE NO_MAX_AGE
/opt/bmc/controlm/cmagentd/ctm/runtime/CMD.0000ctkt_002: line 2:
ctmfw: command not found
Can someone help me identify the cause of this issue.
Thanks in Advance!
The ctmfw command is provided by Control-M/Agent component. You must validate that you are running that Job on a server where a Control-M Agent is installed. In addition, it must be executed with the operating system user under which the agent was installed or, with a user who has execution privileges over the ctmfw utility.
I am trying to diagnose a problem where a Java web application I'm using (Jenkins) becomes unresponsive. If I run jstack without the -F flag it doesn't give me anything, but if I put the flag in to force a thread dump not only do I get a result, but the application starts responding and goes on as if nothing had happened until it eventually stops responding again.
What does jstack -F flag do that would affect a running JVM and cause an unresponsive application to start responding again?
You can see the source to jstack here. The -F argument changes how jstack connects to the jvm. With -F (or -m) JStack connects to the jvm using the java debugger interface. If a pid is specified, JStack connects with the SA PID Attaching Connector which says,
The process to be debugged need not have been started in debug
mode(ie, with -agentlib:jdwp or -Xrunjdwp). It is permissable for the
process to be hung.
I don't know why it would cause an unresponsive application to start responding again, but the link above also says,
The process is suspended when this connector attaches and resumed when
this connector detaches.
This may have an effect.
jstack -F -l pid is similarly to (assume working dir is JAVA_HOME)
bin/java -Dsun.jvm.hotspot.debugger.useWindbgDebugger -Dsun.jvm.hotspot.debugger.useProcDebugger -cp lib/sa-jdi.jar;lib/tools.jar sun.tools.jstack.JStack -F -l pid
and in the sun.tools.jstack.JStack code
if (arg.equals("-F")) {
useSA = true;
}
.....
// now execute using the SA JStack tool or the built-in thread dumper
if (useSA) {
// parameters (<pid> or <exe> <core>
...
runJStackTool(mixed, locks, params);
} else {
// pass -l to thread dump operation to get extra lock info
String pid = args[optionCount];
...
runThreadDump(pid, params);
}
and since -F is passed in, runJStackTool is called to load sun.jvm.hotspot.tools.JStack, it have same effect of invoking directly
bin\java -Dsun.jvm.hotspot.debugger.useWindbgDebugger -Dsun.jvm.hotspot.debugger.useProcDebugger -cp lib/sa-jdi.jar;lib/tools.jar sun.jvm.hotspot.tools.JStack pid
and sun.jvm.hotspot.tools.JStack will call sun.jvm.hotspot.bugspot.BugSpotAgent attach -> go ->setupVM method
Maybe below code is the magic
jvmdi = new ServiceabilityAgentJVMDIModule(debugger, saLibNames);
if (jvmdi.canAttach()) {
jvmdi.attach();
jvmdi.setCommandTimeout(6000);
debugPrintln("Attached to Serviceability Agent's JVMDI module.");
// Jog VM to suspended point with JVMDI module
resume();
suspendJava();
suspend();
debugPrintln("Suspended all Java threads.");
}
it will suspend all Java threads in the target process. if your application is hang for thread starvation, the suspend method call may relax them.