PRTTRGPGM from Java

[thosmore]

We have a tiny server utility which runs PRTTRGPGM output into a table and then compares its output with a table of files that SHOULD have trigger programs running. Any discrepancy is an issue for the sys admin. This utility runs fine when called from the command line, but it is designed to be called from a Java application. When called from Java, however, the PRTTRGPGM spooled output is mysteriously generated out of a QPRTJOB thread, which makes it invisible to CPYSPLF, which is looking for a spool-file generated by the current job.

If anybody out there has any hacks, workarounds or incantations for this, we'd be happy to hear them. TIA,

Thom

[bryce4president]

Re: PRTTRGPGM from Java

can I see your java code that you are using to call the PRTTRGPGM?

[thosmore]

Re: PRTTRGPGM from Java

The Java code isn't really the issue. As it turns out, I should have posted this under CL--I just now mocked up the call in VB, and the results are (somewhat predictably) the same. As long as the PRTTRGPGM call up and decides to run in its own job stream, the printfile output is going to be invisible to the caller. Just when I thought I'd seen it all... .

However, under the heading More than One Way to Skin a Cat, I rewrote the server code this morning to use DSPFD to extract the trigger info, which it can do directly to an outfile, thereby accomplishing the goal and nixing ten lines of nasty code in the bargain.

[bryce4president]

Re: PRTTRGPGM from Java

Cool. I didn't realize you were calling a CL from your Java. I thought you were calling the command line statement right from your java code.

It didn't sound all too surprising that our PRTTRGPGM was running in the QPRTJOB...but I wasn't positive it was right and didn't want to sound like a dunce.

[thosmore]

Re: PRTTRGPGM from Java

Do you want to elaborate on the QPRTJOB issue? Isn't that unusual behavior, for a CL command issued in the context of a single CL program to run in its own job? Moreover, why does it appear to do this ONLY when called from VB/Java, while calls from the command line work fine?

[bryce4president]

Re: PRTTRGPGM from Java

The Java is in its own job. If you are using something like

Statement chgqaqqini = myConn.createStatement();
			chgqaqqini.executeUpdate("CALL QSYS/QCMDEXC('CRTDUPOBJ OBJ(QAQQINI) FROMLIB(QUSRSYS) OBJTYPE(*FILE) TOLIB(QTEMP) DATA(*YES) CST(*YES) TRG(*YES)',0000000098.00000)");
			chgqaqqini.executeUpdate("UPDATE QTEMP/QAQQINI SET QQVAL='*YES' WHERE QQPARM='IGNORE_DERIVED_INDEX' OR QQPARM='MESSAGES_DEBUG'");
			chgqaqqini.executeUpdate("CALL QSYS/QCMDEXC('CHGQRYA QRYOPTLIB(QTEMP)', 0000000024.00000)");

Now this code isn't emulating what you are doing...it is just illustrating how you make command line calls from a java class. These calls run in the JAVA programs job. But this is calling the command line directly from the JAVA, not calling a compiled CL program from my JAVA. I can't vouch for how it the latter would react.

If you are calling the CL from the JAVA is the CL program itself running in the same job as your JAVA code? I would think that it is.

I know the ramblings don't explain anything. Just for some reason it didn't surprise me that it was running in QPRTJOB. I have a feeling it has something to do with the way you call it from the web programs. Are you running them off a WAS?

[thosmore]

Re: PRTTRGPGM from Java

I'm familiar with the issue of different server programs handling different facets of Java/VB requests. Run an AS400 program or command call that places data in QTEMP, and then try to connect to that data in a separate statement, and you will find that the command handlers and I/O handlers run out of different server apps, so the QTEMP object established by one is not accessible to the other. Stored procedures can get around this by combining the command execution and data access in a single call.

But that isn't what's happening here. What's happing here is that a CL command within the context of a single CL program runs as a separate job when the CL program is invoked from VB or Java (no web-server involved). Here's the call:

// Program call has 1 parameters, all input/output (for now)
ProgramParameter[] prmList = new ProgramParameter[1];
// Setup an empty return parameter of size 4
prmList[0] = new ProgramParameter(new byte[4], 4); // return parm only
// Setup the program to call with the parameter list
ProgramCall as400ProgramCall = new ProgramCall(as400,"/QSYS.LIB/GALCRT.LIB/CHKTRGPGM.PGM",prmList);
//Run the command
if (as400ProgramCall.run() == true)
. . .

[bryce4president]

Re: PRTTRGPGM from Java

My fist guess would be that its something behind the scenes in both the VB and Java when they are creating their ProgramCall instances. Possibly something in the run() method as well. Both would be points of interest to look into.