The problems were not really functional on the new JDE encryption algorithm. They simply added some code to the sign-on Screen. But the Q1 One-Off also added like 17 additional SARs which threw off our regression testing and forced us to go back to O1. WARNING - CNCs - In applying Q1 LOOK up ALL the documentation on it. If you are NOT applying it all at once but are going into a multi-foundation situation for testing, you will have to follow the SP-22 docs closely because they ask you to temporarilly point your security table of users F98OWSEC AWAY from B733X - System to ServerName - Server Map and also to copy your current F98OWSEC table to that location and then re-map in OCM your F98OWSEC table to that temp datasource. If you do NOT do this, then any login attempt using the new algorithm will corrupt the F98OWSEC table - as it is "seen" by LOWER than SP-22_Q1 foundations. Because I didn't know that PS had modifed ONLY the BASE SP-22 doc with P1 One-Off, and I had applied SP-22 base many months ago, I did not read this nor implement the required changes and also a RELATED and required ESU which installs a new P98OWSEC that can detect which security encryption algorithm is in place. So NOT doing this made the user account JDE corrupted from ALL other foundations I had out there (SP-18.1) and I had to call our DBA and have him restore the table which immediately fixed the issue. I also suggest you temporarily create a JDE2 user account with parallel JDE powers to test this. Don't forget to:
1. Create a Multi-foundation instance to be running under SP-22_Q1 on a DIFFERENT Port than the usual 6009. 2. Create that independent CLSID for that new foundation. 3. Allocate a higher location for IPC - such as 10002 for that new foundation. 4. First Install the ESU per Win2k/Unix/AS400 and then 5. Copy the F98OWsSEC table per the instructions. 6. Point the F98OWSEC table to that datasourse ServerName - Server Map location for whatever Environment you're testing, such as DV733x you should have no problems at all. Just think it thru and you WON't Corrupt any user accounts, which just means that the column which contains the encryption gets the NEW SP-22_Q1 data making it "bad" to LESS than SP-22_Q1. I've done this 5 times on different environments and it worked fine until we were forced to go back to O1 for reasons previously mentioned. Also, remember to build packages in that multi-foundation env, you'll have take into account the different Port numbers and also to modify the security section either on your deployment server or workstation to point AWAY from B733x - System to that temp datasource ServerName - Server Map. It all works fine if you take your time and follow ALL of JDE's steps.. Oh and also - on the DS you'll also may have to point DEP733x's F98OWSEC to the new temp datasource,ServerName - Server Map, after applying the security-related ESU. Hope this helps [email protected]
SP-22_P1 (Now Recalled) and now SP-22_Q1, address a major security issue, potentially involving the security algorithm used by JDE. It may be of major interest to security types.
