Unable to Open PDFs when Multiple Logic Servers

DBohner-(db)

Legendary Poster
This is, probably, a no-brainer for the experienced CNC?

This weekend we went from 9.1.4.4 to tools 9.1.5.7. This morning we realized that we have an issue with Work Submitted Jobs - not being able to pull from our Windows Logic Server, when users are logged into the web.

  • Most of our UBEs run on iSeries Enterprise Server. We have a select number of UBEs that run on a Windows Logic / Batch Server
  • From the Web Client after submitting a UBE to the iSeries Enterprise - we can open the PDFs generated
  • From the Web Client after submitting a UBE to the Windows Logic/Batch server - we CANNOT open the PDFs generated
  • From a Fat Client - we can open all PDFs generated by either iSeries or Windows logic Servers

We can replicate the above - in all environments (DV, PY and PD)...

Thoughts - Recommendations

(db)
 
I assume users are going to Form -> Advanced in WSJ (on the WebClient), changing the server to the Windows Server and retrieving the PDF? Check the JAS logs .. it should point you in the right direction.
 
Generally - whichever way they go to WSJ, they cannot pull PDFs that are generated on the Windows Logic Server.
 
They can see the records in WSJ for the jobs that ran on the windows server , but not view the PDF ? How about view log ? Is it the same error ?

It seems to be an issue with the windows network credentials may be. When using a FAT client , it will use the user's windows credentials.

What platform is your web server on ? Windows or iSeries ? Did you change web servers with the tools upgrade ? If they are windows web servers what account is the windows service running with for the Server Manager Agent ?
 
I remember going through this after an upgrade and it turned out to be a file permissions issue on the Windows servers. I agree with Hari, check the JAS log.
 
Deep in the bowels of the web log I read:
"ube.myService() : The file may not exist on Enterprise Server or Security prevents the user from viewing the file"

What the heck is ube.myservice()?

(db)
 
ube is (probably) the Java class used by E1 and mysevice() is one of its methods.

From a Fat Client - we can open all PDFs generated by either iSeries or Windows logic Servers

When you say you can view the PDF from a fat client, are you running WSJ in E1's fat client (i.e. windows app) or from the local web client (i.e. http://localhost:8888/jde)?
 
Using the WSJ (Fat) we can pull the PDFs.
Using the WSJ (Local Web) we cannot pull the PDFs.
 
Do you have Windows Firewall turned on on the Windows Server? If so, you need to verify that the firewall is configured to allow all jde kernels to communicate. Something in your network configuration is blocking the communication.
 
Appears to be a 9.1.5.7 Tools issue.

The WSJ Screen pulls from the correctly mapped F986110

However, when we try to open a PDF
- if the PDF was created on the iSeries - the Correctly mapped F986110 is queried for the location
- if the PDF was created on the Windows Server - the windows server map for the F986110 is used (not the correctly OCM'd map for that server - btw).

Anyone else on 9.1.5.7 that has multiple batch / logic servers? I'm curious if it is just us...

(db)
 
Verified that this works without issues on 9.1.5.7 with an iSeries / Windows Server logic server.
 
Could this be an incorrect mapping in the server map OCM? Since the fat client works, which users the system OCM.

Craig
 
Craig - Dan cannot get it to work from the local web client either (where only the System OCM is used), so the issue is elsewhere, IMO.
 
MD - does not spawn PDF (or attempt to open Acrobat). Simply get that error message that the file could not be found on the server.

Here's the oddity, when the WSJ Screen is populated - the F986110 fetch looks like this:
28 Jul 2016 07:09:44,396 [APP ] STRANGEPERSON - [JDBJ] SELECT * FROM SVM900.F986110 WHERE ((JCJOBNBR = ? AND JCEXEHOST = ? )) ORDER BY JCEXEHOST ASC , JCJOBNBR ASC

And when the fetch to determine where the file is located occurs - the F986110 fetch looks like this:
28 Jul 2016 07:09:44,487 [APP ] - [JDBJ] SELECT JCUSER,JCFNDFUF2 FROM APPLIB9.F986110 WHERE ((JCEXEHOST = ? AND JCJOBNBR = ? ))

Since the location record had been written to the Server Map F986110 - the fetch to APPLIB9 will not find a record (and thus, the 'file not found')....

Thanks Hari - for validating that we are not alone.

Craig - you going to InFocus =D

(db)
 
Silly question - But I am sure you have already compared the ES ini (Windows server specifically) files with the backups before the Tools upgrade just to make sure that the SM did not change anything on them?
 
Dan - I suspect that the server map data source in the JDE.INI file of the Windows server is not set up correctly. If your CNC created APPLIB9 to hold the server map records for this Windows server, that server map data source should be set up in the INI file. Also check the ODBC for this sever map datasource on the Windows server.

Try this: Submit a report to the Windows server with debugging turned on. Check the debug log to see which F986110 is being used. That should match the one that the CNC intended.
 
Us (Oracle and me) did a web-ex, and went all-over the INI(s) - they stated they were setup correctly.

The submits were as expected, the WSJ was as expected but the PDF Fetch 'selection from F986110' is hosed...

Watch, this will turn out to be an O instead of an 0 or VV instead of W or Case-Sensitivity =(

(db)
 
Wow! That's baffling.
Daniel, have you found the BSFN/NER call which is made before that F986110 SQL fetch? Since it is working on the client it would interesting to compare where exactly the entry "APPLIB9.F986110" is being fetched from on the server side.

Are you coming to Infocus? Looks like there would be some good discussion around this issue at Infocus! :))

Thanks,
Soumen
 
Back
Top