Page 1 of 2 1 2 LastLast
Results 1 to 10 of 17

Thread: One World XE SPC Auth Codes expiring

  1. #1

    One World XE SPC Auth Codes expiring

    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.

  2. #2
    Join Date
    Dec 2000
    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: 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.
    Attached Images Attached Images
    Justin Miller

  3. #3
    Join Date
    Dec 2000
    Hi Mark,

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


    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.
    Justin Miller

  4. #4
    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)

  5. #5
    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
    Faulting application name: activConsole.exe, version:, 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.

    Lilian Tey

  6. #6
    Member Tom_Davidson's Avatar
    Join Date
    Nov 2000
    Wisconsin, USA

    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?
    Cleindori Consulting
    8.12/, 9.1/, 9.2/
    IBM i, WebLogic on Windows, DBCS, Global installations.

  7. #7
    Join Date
    Jun 2001
    Colorful Colorado

    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 by Segfault; 02-22-2019 at 08:33 AM.

  8. #8
    My company may need to browse the history data after 19 years. Any solutions for this issue?

  9. #9
    H again, we are working through some testing using the procedure outlined in the modified document ( )

    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 [IMG]file:///C:/Users/MARK~1.CLA/AppData/Local/Temp/msohtmlclip1/01/clip_image002.jpg[/IMG] 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...?


  10. #10
    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?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
The legal restrictions and terms of use applicable to this site are available here.
Use of this site signifies your agreement to the terms of use.
JDELIST is NOT affiliated with JD Edwards® & Company, Oracle or Peoplesoft. Contents of this site are neither endorsed nor approved by JD Edwards® & Company and, or Oracle.