I thought that I’d record some CNC101 stuff, as I’m finishing up some documentation and thought I’d share some of the basics.
Post installation I think that it’s a great idea to take a snapshot of the system configuration by using "SupportAssistant”, this records a bunch of details about the system that you might want to refer to, once you’ve handed it over to the client. It’s a helpful and useful utility. I record a “generic issue” profile from the deployment server as a matter of course and then save the .gss file to my clients directory.
Get it from https://support.oracle.com patches and updates, jdedwards
Then choose the “Support Applications” menu item and search.
Next time I get asked about OCM’s or Central Objects counts – I can refer back to my SA file. It’s also great for creating documentation for the site. One thing it highlights is consistency for ESU application. This MUST be right. You cannot leave pathcodes looking inconsistent at a site, everything must be left neat and tidy and equal. I’m referring here to the common practice of duplicating pathcodes. This is done easily manually – but you MUST ensure that you fix the planner database to reflect that the ESU’s applied to your pathcodes are the same.
Firstly, if you are using OEE for the local database on the deployment server (you should be!), just use sqlplusw from the command line. jde jde and e1local will get you a command prompt.
So now, I need to work out why TR looks like no ESUs (or ASUs) for that matter have been applied. I do actually know why, as I did not copy the history when I copied the pathcode, but I need to work out how I can re-apply the history for when I need to run ESU’s against TR.
I enabled jde logging on the dep server ini file and then went to the ASU screen.
The following SQL reveals how JDE populates the grid:
SELECT * FROM JDESY900.F9671 WHERE ( SDPKGNAME = 'UL2' AND SDSUDET = '90' )
SDPKGNAME SD SD SDSUDATE SDSUTIME SD SDSUDFUT2 SDSUDFUT3 SDUSER SDPID SDUPMJ SDUPMT
---------- -- -- ---------- ---------- -- ---------- ---------- ---------- ---------- ---------- ---
UL2 90 15 111082 161018 PS900 0 JDE P9670 111082 161018
UL2 90 15 111067 101629 PY900 0 JDE P9670 111067 101629
There is a line per pathcode.
I can simply duplicate this for the missing ESU’s and problem solved.
create table F9671tmp as SELECT * FROM JDESY900.F9671 WHERE ( SDPKGNAME = 'UL2' ) ;
See that I’m missing PD and TR from the list
Execute the following:
update f9671tmp set sdsudfut2 = 'PD900' where sdsudfut2 = 'PS900' ;
update f9671tmp set sdsudfut2 = 'TR900' where sdsudfut2 = 'PY900'
insert into JDESY900.F9671 select * from F9671tmp ;
2 rows created.
SQL> commit ;
Commit complete.
Then you see the proper pathcodes from the ASU screen.
Now for the big one. I have > 800 ESU’s that I need to do the same for… but the work is the same effort for 800 as it was for 1 ASU.
1* create table F9671tmp as select * from JDESY900.F9671 WHERE ( sdsudfut2 = 'PY900' )
SQL> /Table created.
SQL> update f9671tmp set sdsudfut2 = 'TR900' ;
3363 rows updated.
SQL> insert into JDESY900.F9671 select * from F9671tmp where SDPKGNAME like 'JL%' ;
3355 rows created.
SQL> commit ;
Commit complete.
SQL> drop table F9671tmp ;
Table dropped.
So now, it looks like all ESU’s have been applied to TR900 also – great!
1 comment:
F9671 and F9672, both in planner and system should be taking care as part of the new pathcode setup. More on oracle support "E1: ESU: Net Change Functionality of Software Updates [ID 651812.1]".
Post a Comment