Recently, I was working on a PeopleTools 8.44 to 8.54 Upgrade and ran into some major issues with the fact that the database so far behind in so many areas.  On the Oracle platform PeopleSoft changed the way it handled Long datatype fields and also how it handled Date & Time datatype fields.  The  part that I found was very difficult was some of the scripts that are more current don’t seem to take into account that coming from 8.44 might be an issue in handling these different datatypes.

Basically, in order to make this upgrade work I did a 8.44 to 8.53 upgrade first, and made sure that the LONG TO LOB datatype conversion was ran before the upgrade and that the DATABASE_OPTIONS field on PSSTATUS was set to 34 datatype setting.  Otherwise I ran into all sorts of weird issues with datatypes.

DATE and DATETIME, LONG and LOB fields in PeopleSoft and Oracle database

Smart Thinking Newsletter

Can You Improve ERP User Adoption (Without Starting Over?)

Even the most perfect ERP implementation won’t succeed in the long run if users are unwilling to come on board or resist using new aspects of the system – so how do you get users to embrace new ERP functionality? Here are three quick tips:

• Training: Continuous and easy to access
• Documentation: Provide users with what they need to understand the system and processes
• Improve user experience: Make it friendly

Yesterday, I was working with Oracle’s data pump export tool, which is something I don’t normally do. I am not really sure why Oracle is so difficult to work with in regards to backing up, migration of data and recovery of data. I mean it is just flat out confusing when you don’t do it on a regular bases.

So I ran into all sorts of weird errors. The first one was:

ORA-23603: STREAMS enqueue aborted due to low SGA – after some research I found that the my SGA area was too small, which in my opinion “Who Cares” you are simply dumping data to a flat file why in the world does that need to be complicated, but….

The quick google search turned up to increase the streams_pool_size parameter and increase the SGA memory target area. The first change I needed to make was to increase the sysctl parameter to as this parameter defines the maximum size in bytes of a single shared memory segment that a Linux process can allocate in its virtual address space. So I modified the sysctl.conf file and increased my kernel.shmmax paramter and set the change active with the sysctl -p call. You need to shutdown/start the database for this change to be made. I also modified the init.ora file to increase the streams_pool_size parameter.

It took a couple of tries to get everything to run correctly, however, the last run I did presented me with the UDE-00008 error. What the heck, everything looks great, so again another google search reveals a novel idea: check the logs:

Master table “SYSTEM”.”SYS_EXPORT_FULL_02? successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_FULL_02 is:
/oracle/datadump/fs92demo.dmp
Job “SYSTEM”.”SYS_EXPORT_FULL_02? successfully completed at Wed Jun 17 11:13:53 2015 elapsed 0 00:41:17

Well, what do we have here. Everything completed successfully. Apparently there is a glitch in Oracle’s data pump that sometimes appears randomly however, the job has ran successfully. Simply ignore the error and move on! If you want to read up on the bug apparently the bug number on Oracle is: 5969934. I honestly, didn’t take the time to read it.

Smart Thinking Newsletter

5 Reasons to Avoid an ERP “Frakencloud”

What is a “frakencloud”? In a nutshell, it’s when your system is a cobbled together network of various applications that over time grown and create a monster.
Initially, these applications are intended to make a system more agile, more flexible, but over the long term they can create serious issues. Inefficiencies, security risks, and reduces a company’s ability to serve its clients.

I was doing a PeopleTools upgrade using Change Assistant from 8.44 to 8.54 recently, and have found that upgrading to 8.54 can be a pinch problematic mainly because of the 32bit to 64bit change-over.  So I have found it easier to do two upgrades:  8.44 to 8.53 and then 8.53 to 8.54.

One interesting problem I ran into was I reverted a failed attempt and missed a step and I had an upgrade template thinking I was going from 8.44 to 8.53 but the environment thought my database was at 8.54, so as change assistant went through the script it started skipping steps.

I ended up having to go back to the database level and set the TOOLSREL on PSSTATUS to 8.44 and rebuild the environment in Change Assistant.  Then create a new job with the updated environment and the upgrade template, then I changed the database back to the correct level it was at and marked all the completed steps in the template complete and ran the steps that were being skipped. Change Assistant will read the Tools Release level from PTSTATUS table when the Change Assistant job builds from the template and if that level is different then when the job starts any step is not at the right level will be skipped in when Change Assistant processes through the job.