ESU's for the new Environmnet....

max_xx

Well Known Member
ESU\'s for the new Environmnet....

Gd'Day every1,

Config.
------------
E812
TR - 8.96
Enterprise Server - RHEL
Webserver - RHEL


I've created a new environment, its a copy of PY environment.
I've used Environment Director for that.

Well, the env is created and everything seems to be fine.

I am a bit worried about the ESU's.

All the ESU's had already been applied to PY. So it would have definitely affected the objects of the new ENV.

But the ESU application shows that they have been applied to just DV and PY.
I can apply them back to the new environment but I guess there is no point as they already have been applied.

Is there any other way to tell JDE that they already have been applied to to UAT.
The same will hold true for the ESU projects in OMW for the new environment.

Ques. 1 -> Is there any point in doing all these things as we all know the sole purpose of updating the objects has been done.

Ques. 2 -> If there is, than can it be done by firing queries in the backend and updating the ESU tables(God Damn the Tables), which tables would it be then ???


Thanks a lot in advance.

Warm Regards,
Max
 
Re: ESU\'s for the new Environmnet....

A little dated, but essentially you need to update some tables. I usually copy out the records from each, containing the environment/path code the copy was made from, and change the environment/path code to the new name, then insert the records back into the original.
 
Re: ESU\'s for the new Environmnet....

Fantastic.

Thanks a lot.

smile.gif
 
Re: ESU\'s for the new Environmnet....

There is actually no point in copying these records into new custom environment. This is pure cosmetics. You may do it if you want but if neglect this it will have no negative effect. All merges in the system are done on “by object” basis not on “by ESU”. It serves only information purposes when you query an object or look for an ESU.

Applying the ESU again is a bad idea. Theoretically it should do no harm - only update ESU information, but objects should not be applied anyway as they are already there so no point in doing it.
 
Re: ESU\'s for the new Environmnet....

Issue: Around 300 ESUs applied when installing EnterpriseOne are still out there and need cleaned up. The ESUs were not directly applied to Production since the environment was copied. The ESU Updated environments columns does not show PD811 but they have been applied to PD811.

Use KG document "How to make EnterpriseOne think ESUs have been applied to a Copied environment".

Steps.

Note: This process uses SQL Server Management Studio to copy and paste new records.

1. Enter planner on DS and get ESU names.
2. Use SQL Server Management Studio to pull data from F9671.

Select the PSSY811 database

SELECT *
FROM F9671
WHERE (SDPKGNAME = 'JJ10001')

-> Can use multiple where to pull more than one also

Highlight all the rows for PY811.
Copy and Paste into Excel
In Excel, change the data in the environment column (SUSUDFUT2) from PY811 to PD811. Be sure to remove trailing blanks.
Remove trailing blanks from the Package name (SDPKGNAME) using Trim function/Paste as Values.
Paste back (you are adding the records) into the table in Studio.


3. Use SQL Server Management Studio to pull data from F9672.

SELECT *
FROM F9672
WHERE (SUPKGNAME = 'JJ10001')

Highlight all the rows for PY811.
Copy and Paste into Excel
In Excel, change the data in the environment column (SUPATHCD) from PY811 to PD811. Be sure to remove trailing blanks.
Remove trailing blanks from the release (SURLS) using Trim function/Paste as Values.
Remove trailing blanks from the package name (SUPKGNAME) using Trim function/Paste as Values.
Paste back into the table (you are adding the records) in Studio.

4. Once all the data has been updated in the planner database, update the enterprise server tables using R98403.

Backup the F9671 and F9672 tables on the iSeries in the SY811 library
On the deployment server, logon to DEP811 using PSFT.
Go to Batch Versions (BV in fastpath)
Batch Application = R98403
PO#1 blank PO#2 System - 811 PO#3 PO#4 Blank PO#5 PSFTPLAN PO#6 1 or 0 PO#7 2
Use version MHS0002. Data selection is set to F9671. Change for F9672
Can launch in Proof mode first to verify it will run.
Run LOCAL
Verify record counts for Local tables vs Enterprise Tables.

5. Now we can cleanup the ESUs

On the deployment server, logon to PSFTPLAN using PSFT.
Go to Electronic Software Updates
Form Menu, Remove Updates
Select (or Multiselect) updates
Choose option "Remove Files Only (Cleanup)"
From the Exit Bar, click Remove Updates.
This will remove the SQL Database but leave a reference to the ESU (shows as crossed out).
 
Back
Top