We're running Portal 8.5 on top of WAS ND 8.5.5.21 with Java v8 across the board (referenced as java_1.8_64_bundled) which is referenced correctly everywhere except in the ConfigEngine.bat located at .../IBM/WebSphere/ConfigEngine/
My questions are:
The ConfigEngine.bat at line 16 references java_1.7_64 as shown in the attached screenshot. Where is this coming from?
How is the ConfigEngine.bat updated to reflect the latest Java version installation (java_1.8_64_bundled)? Is this a manual edit or an automated edit?
I just checked your screenshot and compared that with the ConfigEngine.bat file of my test-system, which is on Portal 9.5 CF222. On my version of that file I don't see that java reference in line 16! the two lines 16 and 17 at all are not on my version. Can you please let me know the exact cumulative fix version for which you see that? Currently I think there are maybe two situations here...
1) Either it was hard coded earlier in our product on a specific version and we already fixed that with newer CFs
2) or this was added manually to that file.
The ConfigEngine java usually will always been updated with the newest Java as soon as you update the SDK and run the applyCF.sh script to update your profile.
Thorsten and Jerry, thank you for your reply. We're running WebSphere Portal V8.5.0.0 with CF15 installed. I have no knowledge of someone having changed the file manually.
We upgraded the Java SDK separately about four years after we installed CF15. Assuming the line wasn't hard coded in the first place, the update appears to have missed this line in the ConfigEngine. bat file when we applied the Java SDK v8 update. I checked all four of our environments and all ConfigEngine.bat files are identical to the screenshot I included here.
Thank you. We are aware CF15 is very old, and we are preparing to update Portal to the latest CF. However, while running the ConfigEngine Portal Health Check utility, a step prior to updating the CF, we are experiencing an issue. The utility completes with BUILD SUCCESSFUL but the HealthCheck-timestamp.log contains connection errors for all six of Portal's databases. We found line 16 in the ConfigEngine.bat file while troubleshooting, which led to my question to the forum.
Because in newer versions I can see that these two lines are not included, did you already try to remove them to solve your problem? If you see more side effects, then I would suggest you to open a HCL case. So that we can check the database related errors in detail. These maybe occur, because of wrong property settings that are defined in any properties file (for example wkplc.properties or dbtype.properties). It could be that you maybe use a jdbc-driver version that is shipped for java 6 in java7 or java 8. Without knowing the exact exceptions it is hard to guide. That might been then also better to discuss that in a HCL case.
Thank you, Thorsten. We found that removing lines didn't change the outcome, so we opted instead to manually update line 16 (it really didn't matter either way.)
We found the resolution of the issue we were experiencing are addressed in the following Knowledge Base articles.
ConfigEngine task "health-check-update" report contains error, "ERROR: Unable to connect to release database"
The Portal Health Check utility ran with BUILD SUCCESSFUL, and no database connection errors after we manually edited the RunConfigEngine.py at line 36 and replaced the following string: