When building environments with PeopleTools 8.53 & 8.54 everything will be going along tickety boo and it will go to encrypt the passwords and bam:

Error: Process aborted. Possibly due to JVM is not available or missing java class or empty password.

Well, isn’t that interesting.  The PeopleTools 8.53 and 8.54 have a new SALT component to its passwords and clearly uses the Java to do the encryption.  Add %PS_HOME%\jre\bin to the beginning of the PATH variable and re-run data mover and try the encryption of the passwords again.

When running the Simple Connection Test Cobol you may encounter an error such as:

SUCCESSFUL DATABASE CONNECT AND DISCONNECT
PTPSQLRT – ERROR IN BIND SETUP/DATA
STATEMENT=PTPUSTAT_U_PRCRQSE
VARIABLE#=001
DATA TYPE=001
DATA LEN =00001
SCALE =000

Application Program Failed
Action Type : SQL UPDATE
In Pgm Section : SQLRT: PROCESS-SETUP(BIND)
With Return Code: 08001
Error Message : Invalid bind variable number
Stored Stmt : PTPUSTAT_U_PRCRQSE
SQL Statement : UPDATE PSPRCSRQST SET RUNSTATUS = :1 ,PRCSRTNCD = :2 ,ENDDTT
M = SYSDATE ,LASTUPDDTTM = SYSDATE ,CONTINUEJOB = :3 WHERE P
RCSINSTANCE = :4

at pos 00028

PTPSQLRT – Error Encountered
No longer have connection to DB due to an error from previous
action: SQL UPDATE. Bypassing current action: SQL SELECT.
Terminating Program.

Interestingly, your gut should be saying you have the wrong PeopleTools COBOL being ran, and you’d be right.  In my case I had all the compiles done correctly, but I was working in a decoupled home environment, but the source for the application came from an old system where the Application home still had the COBOL source combined with application and tools code.  Once I removed the PT* cobols from the source and recompiled and moved the files around correctly, everything worked like a charm!

Over the past several days I have been configuring multiple systems with multiple Peopletools versions and I think my mind snapped somewhere.  This 32/64 bit thing is so frustrating.  Basically 8.54 is almost completely 64 bit, but 8.53 is still a 50/50 chance.  When it comes to Crystal with 8.54 you need to make sure you use the 64 bit run time library where as 8.53 and down use the 32 bit run time.  However if you have the full install of crystal so that you can develop reports, you need to put the CrystalExePath to the the full install win32_x86 32 bit directory.

I found this absolutely helpful case on Support:  1540788.1:

PeopleSoft PeopleTools 8.53+ uses the SAP Crystal Reports runtime engine for .NET Framework 4, (Crystal Reports version for Visual Studio 2010), as the runtime for running SAP Crystal Reports. This must be downloaded from the SAP website. Link

Download the Runtime:  PeopleTools 8.53 – 32bit and PeopleTools 8.54 – 64 bit.

When configuring the process scheduler set the CrystalEXEPath to:

8.53:  CrystalEXEPath = C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86

8.54:  CrystalEXEPath = C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win64_x64

If you have Crystal Reports 2008 installed as well as the runtime set the CrystalEXEPath to:

CrystalEXEPath = C:\Program Files (x86)\Business Objects\BusinessObjects Enterprise 12.0\win32_x86

Note:  This are the default install paths and maybe different depending on how you installed them.

I don’t pretend to be an Oracle DBA but I can fuddle my way through most of it without too much of an issue, but there are some really odd things with how Oracle works that drive me crazy.  One of the things that drives me crazy is cloning.  In SQL Server I can clone a database very easily and usually very quickly.  Oracle NOT so much.  I have written a procedure to follow for cloning in the past that is missing a very critical element so I am updated that post and also writing it here for future reference.

When I clone the database I simply copy my data directory with houses my temp and perm tablespaces, and the recreate statement I use puts all the permanent tablespaces back in, but the temporary ones need to be re-added as well.  This can be done with the command:

ALTER tablespace {TableSpaceName} add TEMPFILE ‘{Directory Path/TableSpace.dbf}’ reuse;

If you look in the dump file that is mentioned in the cloning post, at the bottom you should find the TEMPFILE reuse statements for the database.  Just copy them and change the paths and add that to the create script or run the steps manually in sqlplus and you will be good to go!

Oracle Database: Oracle Performance Secret

When working with a new Oracle Database on a Windows 2012R2 server running Oracle 11.2.0.4.  The PeopleTools Upgrade process was on the last step which is to do a Final Alter Audit (FNLALTAUD).  This Upgrade Step looks at all the tables within the system and determines if the metadata is in sync with what is actually in the database.

14 hours into the process and has to be done, but as per usual it is next to impossible to tell with PeopleSoft.  Since this really should not take anymore than an hour or two, the process is killed and the following Oracle Performance Secret is executed in SQLPlus:

analyze table sys.CDEF$ delete statistics;
analyze table sys.CON$ delete statistics;
analyze table sys.USER$ delete statistics;

Rerunning the Upgrade Task after apply the Oracle Performance Secret and it is now running in:  29 minutes.  That is much more acceptable.

What is the SYS Schema?

The SYS schema stores all of the base tables and views for the Oracle Database’s Data Dictionary.  The Data Dictionary is critical to the operation of Oracle Database.  It is imperative to maintain the integrity of the data dictionary, so manipulation of the Data Dictionary should only be done by Oracle itself.

Where did this fix come from?

During upgrades of environments there has been some reported cases of very poor performance using Oracle PeopleSoft Data Mover to import data into the new environment.  We have experienced this problem while upgrading environments specifically the Final Table Audit (or Initial Audit) Upgrade Tasks.  PeopleSoft has a very high number of constraints (Finance v9.2, I just queried had 2.7 million rows), which are stored on the CDEF$ & CON$ Data Dictionary Tables. If the Cost Based Optimizer (COB) has bad statistics to work from it is often seen that the optimization plan will come up with Full Table Scans which are extremely poor performing.  Patch #4618615 & #5103126 from Oracle apparently address this issue, and so the problem should be limited to Oracle Database 10.2 to 11.0.  However, often times when poor performance is effecting an environment we apply this Oracle Performance Secret and performance typically is greatly improved.