Maintaining Consistent Primavera P6 Client Configuration Files Across Multiple Users Using PowerShell

PowerShell 5.0 icon

In setting up Oracle’s Primavera P6 EPPM version 18.8, I discovered that users who connected to the client via Citrix were not picking up changes that were made to the default configuration file.

Normally, if that file is changed and is newer than the user’s own file, it will be overwritten with the default. In this case, users were not seeing the newer file, and when I looked, they often had no local profile on the Citrix server.

As it turned out, the user profiles were set up as roaming profiles that were deleted upon logoff. This wouldn’t necessarily be a problem, except that the their copy of the config file was always listed as newer than the default.

A workaround was to be logged into the server via RDP, and to have the user log in via Citrix. At that time, the config file could be manually copied, overwriting the user’s old file, and then (most importantly!) manually opening and saving the user’s file, so that it would remain in place in their roaming profile even after logoff.

This is clearly not a feasible practice in a production environment. However, an automated script that does this could solve this problem! Save the following as a .cmd file and make sure it is run prior to running the P6 client executable.

copy "C:\Program Files\Oracle\Primavera P6\P6 Professional\18.8.0\Data\PrmBootStrapV2.xml" "C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0" /y

powershell (Get-ChildItem 'C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0\PrmBootStrapV2.xml').CreationTime = $(Get-Date)
powershell (Get-ChildItem 'C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0\PrmBootStrapV2.xml').LastAccessTime = $(Get-Date)
powershell (Get-ChildItem 'C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0\PrmBootStrapV2.xml').LastWritetime = $(Get-Date)

As long as the Citrix server has PowerShell installed, this should work.

Update: Part 2 has a script that will allow for both Local and Roaming profiles.

Blockchain: Where to Begin?

Blockchain symbolic representation

Blockchain is a technology that I hear about almost every day now. 

And yet I haven’t found the best place to learn about it – both its concepts and its implementation. With so many courses and books, where to begin?

Those of you who have learned about it and use it regularly – what resources did you use? What, if any, certifications are legitimate?

You may leave your thoughts in the comments, or tweet me: @deepinthecode.

Examining the TransactionObject in PowerBuilder During Update and Delete

PowerBuilder logo

During the upgrade of an application from Sybase PowerBuilder 6.5 to SAP PowerBuilder 12.6, I ran into a bug in the Update event that had me suspicious that the TransactionObject was somehow changing, causing the update to be directed toward a different database.

As it turns out, the bug was due to a trigger in the main database that was selecting data from another database. 

Even so, I learned about something quite valuable: the SQLPreview event. 

event sqlpreview
this.setsqlpreview(sqlsyntax)
end event

If you set a watch on sqlsyntax, you can see the SQL code associated with the data update.

Memory Issues with Oracle WebLogic Smart Update

Oracle WebLogic Smart Updater splash screen

If you need to update Oracle WebLogic 10.3.6 on Solaris / UNIX / Linux with a security patch or service pack, you will likely find yourself using the Oracle Smart Update program. 

This program, which is run by executing the script bsu.sh, is usually found in the utils/bsu folder underneath the BEA Home folder. For example, if your BEA Home folder is “/u01/app/bea64/middleware”, you would change directory to “/u01/app/bea64/middleware/utils/bsu”, and execute bsu.sh, after uploading the required patch files to the cache_dir directory.

{user@server:/:}# cd /u01/app/bea64/middleware/utils/bsu
{user@server:/u01/app/bea64/middleware/utils/bsu:}# ./bsu.sh

Officially, this is how you would execute the program. Except that, for whatever reason, it seems that this script has not provided nearly enough memory for the program to run. Unfortunately, you will likely not find this out for almost an hour, while you get the splash screen above and your server attempts to run the program.

One Eternity Later

After the interminable wait is up, your program has crashed, and you finish pulling what’s left of your hair out, you can begin to troubleshoot the problem. Or, hopefully, you will have found this post before trying any of this!

Let’s look at the source of the problem. Literally.

{user@server:/u01/app/bea64/middleware/utils/bsu:}# cat bsu.sh
#!/bin/sh
JAVA_HOME="/usr/jdk/instances/jdk1.8.0"
MEM_ARGS="-Xms256m -Xmx512m"
"$JAVA_HOME/bin/java" ${MEM_ARGS} -jar patch-client.jar $*
{user@server:/u01/app/bea64/middleware/utils/bsu:}#

See that MEM_ARGS variable? This isn’t 1999 anymore, so let’s change the memory allocation, shall we? Oh, I should mention that if you’re still using a 32-bit version of Java, you’ll be constrained by that pesky 2 GB limit and will have to adjust accordingly.

Let’s see how much memory we have. I’m running Solaris, so this is what I ran:

{user@server:/u01/app/bea64/middleware/utils/bsu:}# prtconf | grep Memory
prtconf: devinfo facility not available
Memory size: 131072 Megabytes
{user@server:/u01/app/bea64/middleware/utils/bsu:}#

Also, I ran “java -d64” just to ensure that I am indeed running a 64-bit JVM.

Using everyone’s favorite editor (vi, of course), I increased the JVM memory allocations and saved the script as a new file: bsumem.sh.

#!/bin/sh
JAVA_HOME="/usr/jdk/instances/jdk1.8.0"
MEM_ARGS="-Xms32255m -Xmx64510m"
"$JAVA_HOME/bin/java" ${MEM_ARGS} -jar patch-client.jar $*

After saving the file, I executed it: “./bsumem.sh”

Oracle Smart Update loading...

At this point, go pop some popcorn and watch an episode of something on Netflix or Amazon Prime. Don’t worry, the program will still be loading when you finish. (You might actually want to check every 15 minutes or so just to make sure that no other errors crashed the app!)

Once your show is over, you can come back and if you held your mouth right when executing the last command, the program will be ready to load the patch. Or you may have to wait another 15-20 minutes, but it should be relatively soon.

I have yet to figure out why this program takes so long to run, though from what I’ve read, it’s a common – if not universal – experience.