Tools 9.1.0.4 and PrintImmediate

We just finished upgrading to tool release 9.1.0.4. For some bizarre reason, for one report we have intermittent PrintImmediate problems.

Same report & same version. Both jobs are submitted using the Robot Scheduler.

Test #1 - PDF is generated and spooled output to the Create!Form queue on AS400.

Test #2 - PDF is generated and no spooled output to the Create!Form queue on AS400. Same report / same version as test #1.

Interesting.... I think I have seen this happen a few times on our end too. We are in the middle of testing and I had some users say they run something (like a PO) that normally goes right to the DIRECTOR queue for CreateForm and is delivered to the user. They say they don't get it. I go to the job and I see that indeed it was generated and says it is already in the DIRECTOR queue so can't see why it didn't get to them? I just hit Print on the job again and the user got it just fine. I went and ran same version and they got the job just fine.

I didn't even think it might be a problem within E1 tools but now this has me thinking. I'm going to keep an eye on this. Have you contacted Oracle about it yet? We were on 9.1.2 and just recently went to 9.1.3.

That sounds exactly like what we are seeing.

Sannan,

I do have an SR open with Oracle but I am dealing with front-line people.

How did you know it was a tools problem? Or, did you just happen to upgrade?

Here's a troubleshooting idea. Wouldn't it be nice to see what E1 sent to the OS print spooler? Or if it did at all?

On Unix systems when you define a printer in E1 as *JDE PCL it calls the script $SYSTEM/bin32/PCL_PRINTER. For *JDE PS it calls the script $SYSTEM/bin32/POSTSCRIPT_PRINTER. If you want to see that E1 sent the print job to the print spooler you can add a simple logging statements to the bottom the scripts you care about to log each printer output call. Here's a simple example for the PCL_PRINTER script that logs a timestamp and arguments from E1 to the script:
echo "`date` PCL_PRINTER args: " `echo $* ` >> /tmp/printdebug.log

Of course this is Unix and I'm not sure if it works the same for the iSeries. Let us know if you figure it out for iSeries.

Thanks dscheef. We may need to try that. I think both of those commands will work with iSeries.

We have been testing this for several hours.

What we found was that the developer specified printer_X on the RunUBE command in the Robot job def. The default printer in JDE was specified as printer_y. Printer_x was on hold. After we changed Robot, things started to work (more) normally.

The working theory now is that the kernels were getting confused over what printer to use given 2 different printers and PrintImmediate.

The strange thing was that it wasn't every time that this happened.