This question is specifically related to the JT400 class ProgramCallDocument, with it's method callProgram(String ProgramName)
I've tried wapping the call in a try/catch - but it's not throwing an exception, the debugger goes into the callProgram method, and just sits there indefinitely.
A small amount of specific information about the API is available here:
http://publib.boulder.ibm.com/infocenter/iadthelp/v7r0/index.jsp?topic=/com.ibm.etools.iseries.toolbox.doc/rzahhxpcmlusing.htm
Here's the code that I'm running:
AS400 as400System = AS400Factory.getAS400System()
ProgramCallDocument programCallDocument = new ProgramCallDocument(as400System, "com.sample.xpcml.Sample.xpcml")
programCallDocument.setStringValue("sampleProgramName.value", sampleValue)
Boolean didProgramCallDocumentRunSuccessfullyOnTheAS400 = programCallDocument.callProgram("sampleProgramName")
The last line of that snippet is the one that just sits there. I left out the try/catch for brevity.
The XPCML file that the ProgramCallDocument constructor uses is just a proprietary XML format that IBM uses for specifying the parameter lengths and types for a program call. I can come back and add it in if it would be helpful, but the ProgramCallDocument constructor runs validation on the XML, and it didn't come up with any validation errors. I'm not familiar with JT400, or how it does Program Calls, so any assistance would be wonderful.
As a further note, doing some more digging on a related issue today I also found this SO post:
Monitor and handle MSGW messages on a job on an IBM i-series (AS/400) from Java
I think it's relevant to this question, because it's about ways to trap MSGW status on the Java/Groovy side.
It's very likely the called program went into a MSGW status (error).
Check WRKACTJOB JOB(QZRCSRVS) to find the program call job and see the status as well as review the job log.
It may be easier to call a native program using the CommandCall class or as a JDBC stored procedure.
Here's an example of the CommandCall usage in Groovy:
sys = AS400Factory.AS400System
cmd = new CommandCall(sys)
if (!cmd.run "CALL MYLIB.MYPGM PARM('${sampleValue}')") {
println cmd.messageList
}
Related
I am working on an integration with Apache Drill which enables users to query PDF files directly using SQL. I'm about 80% done and really impressed with how well Tabula works for this.
However, when I execute the first Drill query that uses the Tabula libraries a Java icon pops up and I get the following text in the command line:
2020-10-25 15:06:55.770 java[71188:7121498] Persistent UI failed to open file file://localhost/Users/******/Saved%20Application%20State/net.java.openjdk.cmd.savedState/window_1.data: Permission denied (13)
I changed the permissions on that directory but I'm still getting the Java popup.
This is not normal behavior for Drill and my goal here was to integrate Tabula programmatically. Is Tabula trying to open a window or something like that and if so, is there a way to disable this? I noted that this does not occur in my unit tests.
Here are some relevant code snippets:
public static List<Table> extractTablesFromPDF(PDDocument document, ExtractionAlgorithm algorithm) {
NurminenDetectionAlgorithm detectionAlgorithm = new NurminenDetectionAlgorithm();
ExtractionAlgorithm algExtractor;
SpreadsheetExtractionAlgorithm extractor=new SpreadsheetExtractionAlgorithm();
ObjectExtractor objectExtractor = new ObjectExtractor(document);
PageIterator pages = objectExtractor.extract();
List<Table> tables= new ArrayList<>();
while (pages.hasNext()) {
Page page = pages.next();
algExtractor = algorithm;
/*if (extractor.isTabular(page)) {
algExtractor=new SpreadsheetExtractionAlgorithm();
}
else {
algExtractor = new BasicExtractionAlgorithm();
}*/
List<Rectangle> tablesOnPage = detectionAlgorithm.detect(page);
for (Rectangle guessRect : tablesOnPage) {
Page guess = page.getArea(guessRect);
tables.addAll(algExtractor.extract(guess));
}
}
return tables;
}
This doesn't happen in my unit tests.
Thanks in advance for your help!
Because some code is executed that does an operation that is usually, but technically not necessarily, involved in things that require so-called 'headful' mode (well, that's perhaps not really a term, but the opposite, 'headless' certainly is). This causes a few things to happen, including that icon showing up.
One easy way out of this is to force headless mode. But note that when you do this, any of these 'usually but technically not neccessarily headful' operations may either [1] work fine and no longer show that icon, or, [2] crash with a HeadlessException. Which one you end up with is not just dependent on which operation you're doing, but also which VM you are doing it on - as a rule once one of these ops works fine and no longer throws, later versions won't revert back to throwing (in other words, newer versions of java offer more things that work in headless mode).
To force headless mode, run java with java -Djava.awt.headless=true.
If you must do it from within java code, run System.setProperty("java.awt.headless", "true"); at least once, and before you do any of these 'usually causes headful mode' operations.
Presumably, the thing that is causes headful mode to occur is something graphics involved, such as rendering a JPG or PNG into an ImageBuffer. It's not surprising that Apache Drill is doing this to 'read' images, for example.
Another option is to just upgrade your VM, maybe that helps. As a general rule, features 'move downwards' on this line:
Requires headful mode; running it makes the VM go headful (icon appears); if java.awt.headless is set, the operation fails with a HeadlessException.
Causes headful mode; running it makes the VM go headful. However, if headless is set, it works fine and won't do that.
Completely freed. Running the code works fine and does not cause the VM to go headful. the headless flag has no bearing whatsoever on how the code operates.
While integrating invoices into SAP in my Java application on Windows, I am having the following error "R6025 - Pure virtual function call".
However, my application runs on multiple clients in a single version and I have no problems with any of the clients, just this specific one!
During testing with the application in the client environment, I noticed that the error always happens when using the "add" to add the first line in the invoice.
invoiceV1.getLines().add(); // The error happens here!
System.out.println("THIS LINE NOT APPEARS ON CMD");
invoiceV1.getLines().setCurrentLine(lineNum);
............ SETTING LINE VALUES ..........
lineNum++;
As far as i know, you don't need to set the .add() on the first line. Try to put an if just to check if it is the first line or not.
If that doesn't work, you could consider an enviroment error? Or some instalattion problem?
Is there a way to create an AEM package via a java code ?
We need to package some content every night via a service run by a cron job.
I checked online and it seems to be possible using a curl command. But either way, I'd need this done via a daily service running a java code.
Please refer to some of the links given below :
1)https://helpx.adobe.com/experience-manager/using/dynamic_aem_packages.html
2)http://cq5experiences.blogspot.in/2014/01/creating-packages-using-java-code-in-cq5.html
The main code goes something like this :
final JcrPackage jcrPackage = getPackageHelper().createPackageFromPathFilterSets(packageResources,
request.getResourceResolver().adaptTo(Session.class),
properties.get(PACKAGE_GROUP_NAME, getDefaultPackageGroupName()),
properties.get(PACKAGE_NAME, getDefaultPackageName()),
properties.get(PACKAGE_VERSION, DEFAULT_PACKAGE_VERSION),
PackageHelper.ConflictResolution.valueOf(properties.get(CONFLICT_RESOLUTION,
PackageHelper.ConflictResolution.IncrementVersion.toString())),
packageDefinitionProperties
);
So first of all you can create a scheduler and in the scheduler's run method you can write the logic to package the required filter paths .
Hoping this is helpful for you.
I am trying to connect to a SAS-driven remote database from within R, using RJDBC. The first time I do a dbConnect, I get an error:
Error in .jcall(drv#jdrv, "Ljava/sql/Connection;", "connect", as.character(url)[1],
: java.lang.NoClassDefFoundError: com/sas/net/crypto/CryptoException
When I do the dbConnect a second time after the first call, it connects fine, and I get back an object of class JDBCConnection.
I looked in the sas.core.jar file (from the latest 94M2 SAS JDBC drivers), and can see CryptoException listed in there. However, I am also curious why it was trying to throw a CryptoException.
Question 1: How can I silently ignore the error on the first dbConnect call?
Question 2: Why was it trying to throw a CryptoException? What can I do to prevent this? (This may cancel question 1.)
This is the same question as shared on the SAS Support Communities page:
https://communities.sas.com/thread/80620
There you shared the code you are using
https://github.com/wthielen/wrds/blob/7edfbfe89ddc329618be72e591cc0bd50e294ea4/R/wrds.R#L47
In this code, the problem appears to be that you are trying to set the classpath before initializing the JVM. Using .jinit() before the call to .jaddClassPath should correct the issue. In the doc for .jinit and since you are developing a package, you may want to use .jpackage instead of .jinit
https://www.rforge.net/doc/packages/rJava/jpackage.html
I was having the same problems and tried the above solutions with no change.
The solution on my computer was modifying the .Renviron file which holds the classpath to the java drivers. Replacing "JDBC_Drivers" with "WRDS_Drivers" was all that was needed:
CLASSPATH="C:/Users/nicol/Documents/WRDS_Drivers/sas.core.jar;C:/Users/nicol/Documents/WRDS_Drivers/sas.intrnet.javatools.jar"
I just added some print statements to see what arguments are actually being passed to the methods, but nothing is ever printed to the console. For instance, I have:
#ApiMethod(name = "getListings")
public List<Listing> getListings() {
System.out.println("Getting listings");
return ofy().load().type(Listing.class).list();
}
If I make a change to the return statement (e.g. adding a filter), I can see the changes, but it never prints anything. Does anybody know what's going on here?
I use https://code.google.com/p/gwt-log/ Works with objectify just fine.
This way client code and server code can use the same logging statements. [That's useful since if I'm offline and can't call the server, I'll try handling stuff locally]. So it'll work fine in shared code and objectify objects that are being sent to/from the client/server.
See https://code.google.com/p/gwt-log/wiki/GettingStarted but basically the steps are:
1) configure *.gwt.xml
<!-- For development, a default of `DEBUG` is recommended -->
<inherits name="com.allen_sauer.gwt.log.gwt-log-DEBUG" />
2) import to your java code
import com.allen_sauer.gwt.log.client.Log;
3) log
Log.debug("Getting listings");
System.out does not write to the App Engine logs. System.err does.
Use java.util.logging. It's usually helpful to use a facade for j.u.l like http://www.slf4j.org/
In server-side programming, console print statements are generally not used.