One World XE SPC Auth Codes expiring

MarkusC

Member
Hi, we have been running an old version of OneWorld XE for almost 20 years and recently all users (Fat and Citrix) received a JD Edwards Security Warning stating that the Software license was about to expire. Our support partner managed to generate a new SPC code with a new date (6 months into the future), and clients were able to re-authorise, but no one seems to know why this happened in the first place. Would it be that someone arbitrarily set a date when the software was first installed and this date has now come up?

Appreciate if anyone can shed any light on this.
Thanks
Mark
 
I recalled the oldest date for SPC generator being June 2019 when Oracle released it to allow older release to continue to issue their own SPC codes.

I just downloaded it and confirmed my recollection. The expiry date the SPC generator uses is June-30-2019 which I believe was the original "drop dead" date for XE.

Unless Oracle are releasing another generator this will likely affect anybody on XE. If you are still on support and log a ticket I would do that. You can also trying emailing: [email protected] explaining the situation even if you are not on support/have not active CSI (customer support identified) You no doubt have a perpetual use license and they are responsible to make sure you can keep running your software even if it is no longer "supported".

If you are not on active support but are dealing with an Oracle business partner they should be able to log a ticket under their CSI. I ended up doing this for a B7332 client a few years back where the SPC generator does not work and they couldn't log a ticket with Oracle due to having no CSI. It took me a lot of effort and I eventually had to get the Asia Pacific support manager (my neck of the woods) on the phone to explain the whole thing. In the end I got an SPC code issued for them.
 

Attachments

  • spc_gen.jpg
    spc_gen.jpg
    9.2 KB · Views: 56
Many thanks Justin, you are a star! Unfortunately off support now so looks like the jde.ini option is the best one for us. Appreciate your quick reply and help. Cheers. Mark (AUSPAC too)
 
Already set the JDE.INI setting BDSEC=ROBIN, do a testing on the computer for few date.

Found the results of our JDE One World B7333 SP24.20 when set the date of computer to:
1. 01 July 2019 - JDE can run
2. 18 Feb 2038 - JDE can run
3. 19 Feb 2038 and date after - JDE crash

My conclusion is JDE System will crash after 18 Feb 2038, below is the detail of the event viewer.

Log Name: Application
Source: Application Error
Date: 19/1/2038 12:36:45 PM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: JDECLIENT03.ysp.com.my
Description:
Faulting application name: activConsole.exe, version: 1.0.0.1, time stamp: 0x4f8436eb
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0xc0000005

Appreciate if anyone facing this and have solution.

Thanks.
Lilian Tey
 
Lilian,

It looks like this might be an issue in Visual C, but to be honest hopefully by the time you get there, you will be on a more current version.

I'm not sure a business would want to be on 40 year old software.

My career has been about 40 years, and I'm pretty sure no one would want to still be running on the software that was available at the beginning of it.

Why do you think this is an issue?
 
Lilian,

The date you picked in 2038 is after a 32 bit time_t datatype in C overflows (it overflows on Jan 19, 2038 - and the error you posted says "Date: 19/1/2038 12:36:45 PM" which is Jan 19.)

I suspect the issues you are having is from being on old code that doesn't support 64bit time_t (all 32 bit builds of EOne!!!!) -- which is another reason 9.2.3 64bit is a necessity for all to be considering before 2038.
 
Last edited:
My company may need to browse the history data after 19 years. Any solutions for this issue?
 
H again, we are working through some testing using the procedure outlined in the modified document ( https://www.oracle.com/webfolder/te...rds/White Papers/JDE_Licensing_Whitepaper.pdf )

+++++
Service Packs 17.1 and later for OneWorld Xe/ERP 8 Jde.ini entry needed.

The verification of licenses on the Development Client can be bypassed by adding an entry to the file. Additionally, users must manually copy several files from the Deployment Server to the Development Client.

To copy files from the Deployment Server to the Development Client:

1. Locate the jde.ini file on the Deployment Server. The typical location is: C:\ Windows

2. Edit the jde.ini file to add the following line in the section of the [DB SYSTEM SETTINGS] file on the Deployment Server: BDSEC=ROBIN Adding this statement disables the license verification on the Deployment Server.

3. You must also add the statement mentioned in the previous step to the same section in the jde.ini template file that will be copied to Development Clients when they are installed. This jde.ini template file is located on the Deployment Server in the following directory: \OneWorld Client Install\MISC

4. After installing a Development Client, copy files: from: Deployment Server
clip_image002.jpg
to: Development Client C:\
The files to copy are:
• Jdeapps*.*
• Jdesec*.*
• Jdemod*.*
+++++

However in SP24 seems jdesec files are not on the deployment server... Changed the client date to 1 Jul 2019 and client security failed...

Any hints or suggestions re: the process we are following here...?

Thanks.
Mark
 
Mark we are in similar position, and are now toying around with date settings to keep it running, then modifying the date on the software side. However I wanted to check, were you able to get past the client security failing?
 
JDE Expirty

Hello, this URL no longer works, can you please provide which changes need to be made in the .INI file? We are receiving the expiration message today

Hi Mark,

I dug a bit more and found that Oracle already addressed the June 2019 expiry in a document.

See: https://www.oracle.com/webfolder/te...ent_Licensing_for_Various_Tools_Releases .pdf

At the end of the document they mention XE. The old JDE.INI setting BDSEC=ROBIN (backdoor security) trick which we used to use with standalone is the official way to get past June 2019.
 
Hi, this document no longer opens, we are getting this error today. Can you please provide specific steps of what needs to be done at the jde.ini file?
 
Hi Mark,

Not sure if your issue is resolved yet. We are also on JDE Xe SP 24 and we have followed the steps in the Oracle white paper and it works so far.
You are right jdesec*.* are not on the deployment server in SP24 but we were advised to copy jdeclnt*.* instead of the jdesec*.* .

So we coped 8 files from the deployment server in total:
jdeapp*.*
jdeclnt*.*
jdecode*.*
jdemod*.*

So far, users are able to login JDE and no issues have been reported yet.
Hope this helps.

-Priya
 
Has anyone tried installing the XE Client on a Windows 10 machine? We have been running B7333 for about 19 years and and upgraded our Deployment Server to 2008 last year. We used the BDSEC=ROBIN trick to fix our Win7 clients but now that we are trying to run on Win10, we are getting this message: License Violation You are not licensed to execute this application. for more information please contact your Oracle Sales Representative. I'm sure this has to do with XE not being certified on Win10, but has anyone found a work around?
 
Just a follow up to this in case anyone needs the fix to install XE Client on a Windows 10 machine:

Install iseries access and latest patch. - restart pc
Install OneWorld client as administrator. - restart pc
The following files need to be copied from your deployment server to C:\Program Files (x86)\JDEdwards\B7\JdeData\
jdeapp.ddp
jdeapp.xdp
jdeauth.dda
jdeauth.xda
jdemod.ddm
jdemod.xdm
jdesec.dds
jdesec.xds
Create symbolic links on root C: pointing to the above files:
Search cmd – Run as administrator
cd / (to root C:)
mklink jdeapp.ddp “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdeapp.ddp”
mklink jdeapp.xdp “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdeapp.xdp”
mklink jdeauth.dda “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdeauth.dda”
mklink jdeauth.xda “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdeauth.xda”
mklink jdemod.ddm “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdemod.ddm”
mklink jdemod.xdm “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdemod.xdm”
mklink jdesec.dds “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdesec.dds”
mklink jdesec.xds “C:\Program Files (x86)\JDEdwards\B7\JdeData\jdesec.xds”

Open Solution Explorer.
 
Last year I used this to continue using JDE. BDSEC=ROBIN. As of October 2020, it has stopped working and I am getting the license error again. Any one else run into this problem? What else can I do to get back into JDE. We only need 1 more year for tax reasons to keep the old system alive.
 
Last year I used this to continue using JDE. BDSEC=ROBIN. As of October 2020, it has stopped working and I am getting the license error again. Any one else run into this problem? What else can I do to get back into JDE. We only need 1 more year for tax reasons to keep the old system alive.
Did you try the steps I outlined above? We haven't had any issues running XE since making these changes on our WIN 10 systems. The BDSEC=ROBIN only seems to work if you are running on a WIN 7 system.
 
Back
Top