Friday, 14 June 2013

EM12C will not start Could not initialize class oracle.dfw.impl.common.TempFileManager

em12c will not start!

It just won't start.

generally, my recommended EM12C start sequence is:

  1. listener
  2. database
  3. oms
  4. wls
  5. agent

but my OMS would fail and take ages to do so.

I was getting in /u01/app/oracle/middleware/gc_inst/user_projects/domains/GCDomain/servers/EMGC_ADMINSERVER/logs/EMGC_ADMINSERVER.out

java.lang.NoClassDefFoundError: Could not initialize class oracle.dfw.impl.common.TempFileManager

Of course, this is not the first log to look at, generally you start with:


This gave me double barreled 404's!!

2013-06-14 14:50:35,974 [main] DEBUG oms.StatusOMSCmd processStatusOMS.240 - console page status code is 404
2013-06-14 14:50:36,022 [main] DEBUG oms.StatusOMSCmd processStatusOMS.242 - pbs page status code is 404
2013-06-14 14:50:36,022 [main] DEBUG oms.StatusOMSCmd processStatusOMS.245 - console header is null
2013-06-14 14:50:36,023 [main] DEBUG oms.StatusOMSCmd processStatusOMS.247 - pbs header is null
2013-06-14 14:50:36,023 [main] DEBUG oms.StatusOMSCmd processStatusOMS.285 - Both Console and PBS are down. Status codes are: Console - 404 and PBS - 404

Which means nothing

What I must say at this stage is that I did notice someone had tried to run weblogic as root, as I had to change permissions on some of the log files that WLS wanted to write to.  It's a dead give-away with WLS, but not so with EM12C layers.

Then, I got to oracle support and used my search string: 
java.lang.NoClassDefFoundError: Could not initialize class oracle.dfw.impl.common.TempFileManager

I got a direct hit:

It seems that there is something dodgey in the /tmp dir.  It was really weird, I had a directory called:
oracle-dfw-5069570897830055595.tmp in /tmp, but oracle could not even list it.  When I tried to use root, it could not see it?? Anyways, without investigating much further I deleted the dir /tmp/oracle-dfw-5069570897830055595.tmp and was able to start oms first go!

Seconds later I was getting my alerts and I felt better about EM12C

Monday, 3 June 2013

Printing from JD Edwards, tray selection, BIP to PCL etc

I was recently onsite for a client trying to solve a fairly simple printing issue - tray selection for BIP output.  Surely, very simple...  This was a windows enterprise server, not too sure if this makes it easier or harder.

Of course, let's do some simple analysis first to know where we are at with our capabilities.

I create a couple of local printers on my workstation and share them.  Easy, then I can create JD Edwards printer definitions to \\workstation\printer and see the output.  Great.  I can toggle between PCL, PDF and PS and see what is coming out and what works and what does not and then build some working scenarios from there.

I pause my windows printer and then look in the C:\Windows\System32\spool\PRINTERS

standard report output: (1 page PDF)
PDF - 55K
PCL - 4K (I love PCL)
PS - 55K

Then I run a BIP job, two pages
PDF - 67K (rename the .spl and you can open it as a PDF - nice)
PS - 67K (rename the .spl as a PDF and you can open it - weird!!)
PCL - 8K (does not have any graphics!!!)

So, the analysis from above might be as you expect.  ALL outputs work from both BIP and standard, but BIP cannot put graphics into the PCL output.  This is important.  If you have PCL printers, you cannot print immediate from BIP and have the reports look great (or can you?).

All of the above is good to know, but does not help me with my main problem, printing to a particular tray of a particular printer.

What options do I try:

  • Create a windoze printer definition that defaults the correct tray and address this from E1.  Does not work.  Default paper tray is used - this is annoying.
  • Force the printer definition in E1 to use the tray that you want - no - does not work
  • Write my own "JDE conversion program" and have that do the printing - too complicated at this stage, although seems possible
  • Use OSA's to grab the output and then print to the printer that I want.  BUT - OSA does not get called from BIP output - Doh!
    • As a side note, I did write this code as an OSA and got everything printing fine from E1 with my OSA.  All tray selection working perfectly.
    • Note that this is quite difficult, as you cannot run an interactive program from a windows service.  I was dabbling in "createProcessW", "shellExecuteEx" I could not bring myself to use "system" - but I probably could have.
    • The long and hard lesson out of this is that you cannot run any processes from a windows service (as all of the kernels run as a service) to execute a program that requires a desktop  / interactive session.  My idea was to run acrord32.exe with the /T option to print the adobe document to my printer of choice.  Hey, this would be nice and neat and get my out of my PCL limitations too...  But, adobe wants desktop resources, so this will not work.  I did get it working with the Fox-It viewer.  This is a really nice viewer and performs a great job with the printing in this scenario. I recommend this software, it also closes the exe when the print is done, not like Adobe that just likes to hang around for nothing!!
To reduce my compile and build and deploy times, I started just calling a script from the OSA, this worked like a treat.

The command that the script runs to print a PDF to a specified printer looks like the below:

C:\Program Files (x86)\Foxit Software\Foxit Reader\Foxit Reader.exe" /t "D:\JDEdwards\E910\ddp\PrintQueue\R0010P_XJDE0001_55464_PDF.pdf" "\\svfpr04\OPS CENTRAL RICOH MP 7001 -T2"

But, this would not work from BIP, as BIP does not use OSA functionality when writing the PDF - which is the ULTIMATE pain!!!

So, back to the drawing board after a lot of code has been written and is working.  My final solution is a work-around until BIP tray selection logic is going to catch up.  I cannot retrofit all the printers in the organisation with PS drivers or PDF drivers!

I finally decided to script once again, but a different angle.

As you know BIP output is written only to the database by default, so it's not like you can just grab the output from the tables and send it to the printer, BIP does a lot of magic there to do that stuff for you - BUT you can enable BIP archiving, which will write all output to a dir on the enterprise server (I can feel a script coming on!!!).

Then a simple WMI based vbscript to listen for createFile events in teh BIP archive dir can be written.  Do some testing on filename and we have a solution!  We can also query the database from the script and get all of the printer information from the job and actually direct the output to the proper E1 printer - nice!

But, lets be honest.  It's not that nice.  Sure I can avoid replacing all my PCL printers (hey - maybe that is NICE).  Reprint from E1 is still dodgy for tray selection, but the end users can do it from Adobe - workaround when the script breaks.  But it's just another thing to go wrong with printing, which should be super simple and should just work.

At the end of the day, there is about 40 lines of script (20 doing debugging and logging) to print BIP output to PCL printers.