TFZ
Well Known Member
Did you delete the ojdbc7.jar from the misc folder (or rename it?)
bluelake
Active Member
We have ojdbc8.jar placed in MISC folder. Could you provide details what mismatch is?
bluelake
Active Member
The issue is fixed. There are two things to attention: 1) place 3 files into MISC folder: ojdbc8.jar, ons.jar, ucp.jar 2) delete all other files under MISC folder. This is very important. If you have more jdbc driver files under MISC, it will cause problem too. Because multiple jdbc drivers will be loaded. You are expected to see error msg like : package oracle.jdbc.pool is sealed.
bluelake
Active Member
New issue: when we try to apply BSFN ESU for 64-bit using Change Assistant, the baseline ESU JN10023 failed to apply. Any idea? Some other ESU can be applied successfully in same way. Thanks.
JohnDanter2
VIP Member
Don't you also need to take into account what other linked software you maybe using first?
We for example have to wait until we upgrade our Oracle database and wait for DSI to certify MEP with 9.2.6. all this before we take 9.2.6.
We for example have to wait until we upgrade our Oracle database and wait for DSI to certify MEP with 9.2.6. all this before we take 9.2.6.
bluelake
Active Member
This is a good point. Now the ESU deployment issue is fixed. We switch tools release back to 32-bit TR924 to deploy JN10023, it worked. Then switch tools release again to TR926.
bluelake
Active Member
New issue: deploy BSFN ESU - JN17537 to DV920 failed. A database login shows asking for password. The user name TESTDTA is correct. The database name is wrong. The correct database name should be our non-prod database. Now it connects prod database. Why a wrong database name is used in this ESU deploy. Thx.
ice_cube210
VIP Member
Check your database data source definitions in your planner environment. Perhaps a wrong definition somewhere
bluelake
Active Member
Data source in Planner is verified and it is correct. We successfully deploy all other BSFN ESU successfully. This is the only one with problem.
serenity_now
Active Member
Hi bluelake / anyone else in same boat,
Are you able to give a high level rundown of how your upgrade has went? We are in a similar position (going from 9.2.4.3 32-bit to 9.2.6.x 64-bit). We have already upgraded our Deployment Server to 2019 but I am still contemplating on the best approach. Install the 64-bit ESUs first, upgrade to 64-bit, then upgrade the tools, or do it all in one shot. Our issue is availability of people to test so one-shot seems easier from that standpoint but introduces other variables as well.
glen7x
Well Known Member
The major step would be installing the ASU. What is the latest ASU / Update installted to your machine?
serenity_now
Active Member
We wouldn't be installing the ASU but the 64 bit ESUs that I know contain a few baselines. Still a lot less impact than UN6 when reviewing the items based on the modules we use. To answer your question though the latest ASU is UN2 with sporadic ESUs since then
bluelake
Active Member
Question about ZERO Downtime package deployment: It is clear that full package can be deployed with zero downtime. How about Update package? Will the deployment of update package lock the target server?
DSauve
Legendary Poster
The Zero Downtime deployment is for full packages only (so far). As of now, I believe that update packages will still lock the target server.
bluelake
Active Member
Thanks. After i review the folder structure on JDE Enterprise server, I find sub folder is only created based on full package under bin64. I think you are right.
bluelake
Active Member
New question: we upgraded DV to 64-bit from 32 bit. Developers begin to check custom C BSFN for retrofit. My question is in addition to data type changes, are there any other changes required in C code? What we learned from Oracle is to change data types from long to int, time_t to jdetime_t, and Size_t to jdesize_t. Thanks
BOster
Legendary Poster
I thought there was a tool to do all of these changes similar to the tool used for the unicode conversion. Additionally, we are still 32bit but on our TR when we check in an object it does the 64bit conversion of the code and places in \include64 and \source64. In other words I didn't think it was necessary to manually fix the things you are listing.
I would guess going forward NEW code would need to implicitly specify these new things.
My understanding is the things that need to be manually fixed were things like raw pointers being passed out/in of functions and dynamic linking to 3rd party libs, etc.
I would guess going forward NEW code would need to implicitly specify these new things.
My understanding is the things that need to be manually fixed were things like raw pointers being passed out/in of functions and dynamic linking to 3rd party libs, etc.
JohnDanter2
VIP Member
As others have said
We installed 9.2.5.5 as 32 bit first then upgraded it to 64bit using the supplied tools
Next step would be 9.2.6 if we needed it but that's going to wait a few months/years before we do (don't ask)
We installed 9.2.5.5 as 32 bit first then upgraded it to 64bit using the supplied tools
Next step would be 9.2.6 if we needed it but that's going to wait a few months/years before we do (don't ask)
serenity_now
Active Member
Did you run into any issues with the 64-bit process? It's looking like we will be going from 32-bit to the new Tools and 64-bit at the same time (as well as applying the 64-bit ESUs).. much like your last statement, don't ask but it's basically now or never! Have done countless Tools upgrades but never applying a bunch of ESUs and 64-bit at the same time. Writing out the steps it all seems doable but I am sure there will be bumps.
P.S nice to see fellow Welshman!
