Tuesday, 8 November 2011

Basics due to lack of blogging–ESU history correction

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

image 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' ) ;

image

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.

image

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:

Anonymous said...

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]".

Extending JDE to generative AI