Windows Command Line – No Network Drives

I am really not a big fan of User Account Controls and Policies to control users on Windows Servers.  I completely understand the need to control users and limit access as needed, but in order to run PeopleSoft and many ERP systems on windows, the account used to setup the window machine typically needs full administrative access.

The other day, I was on a restricted system and I dropped down to a command line (run as administrator) to do some COBOL compiling and of course my source was on a network drive and there was no sign of my network drive.  As it turned out there is a permission that controls weather or not I can see the network drives as the administrator.  However instead of getting crazy and doing a registry edit, I opted for a quick easy fix in this case.

Run the command line cmd.exe as administrator and then map the network drive from the command line:

net use <drive-letter> \\UNC-Path\To folder\You Want To Map\<share>

 

Change Assistant – Performance Issues

Just working through some PUM patching of an HCM environment and the change package that was created was a little on the large size.  In the past large change assistant templates cause extreme delays in trying to get change assistant to respond.

One thing you can do is increase the Heap Size of Change assistant.  The easiest way to do this is to create a shortcut to changeassistant.exe and append the parameter:   -Xmx1024m

In PeopleTools 8.54, I have also found that to minimize the size of the application, you can do an Initial Pass with just the source and/or target steps.  This cuts out a number of steps and makes an easier package to work with.  Also, you can disable the file deployment and do it the old fashion manual way and this too will reduce the template work load.

For example I am doing Image 9 to 12 HCM patching right now, and the file deployment is approximately 1/3rd of the entire change package XML file.

Happy Patching….

 

Unicode in a Non-Unicode Database

Ran into an odd issue when moving file attachments from the database to file storage.  When users attached files sometimes those filenames contained unicode characters and the process PeopleSoft employees to addAttachments and/or putAttachments allows those characters to pass into the database, however because the database is non-unicode in order to reference those filenames the unicode character references need to be scrubbed out of the filenames in order for the copyAttachment function to work.

Oracle Allows you to use the function unistr to put a unicode reference into a string.  In order to work through them I found references for unicode characters, this allowed list out the original file name which had references like <80><99> from a unix output file, so I generated a file that removed the <80><99> reference and added in a || unistr(‘\characternumber’) || reference:

update ps_pv_att_db_srv set attachsysfilename = ‘USER12014-01-01-12.12.12.461The_Fish_Restaurant.pdf’  where attachsysfilename = ‘USER12014-01-01.12.12.12.461The_F’ || unistr(‘\2019’) || ‘ish_Restaurant.pdf’;

It isn’t pretty but it works.  I had a whole series of characters in the database that just should not have been there which included commas, quotas, semi-colons, question marks, many odd ball characters like trademark, copyright, registered, french accent characters etc…. Once I had the file attachment record fixed, make sure that you also update the file attachment reference record as well to the same name.

I didn’t try it out in SQL Server as I didn’t have any references to it but there is a UNICODE function that should behave very closely to Oracle’s UNISTR.

PeopleSoft – Move File Attachments (Database to SFTP)

This is the scenario, client needs to move from database stored file attachments to an actual file share, this allows them to remove 1/4 of their entire database storage needs out to a storage area.  Clearly this is a good thing. So, here is the quick run down on what we did:

1. Copy all the existing URL references that contained record:// for backup purposes.

2. Setup a SSH account with a SSH key pair for security

3. Install the SSH key pair into the digital certificates

4. Change all the existing URLs that point to the database storage to the new SFTP storage locations.

5. Run the Orphan cleanup process for File Attachments

6. Copy the file attachments from the OLDURL to the NEWURL

7. Setup the default file attachment server to use the new URL attachment server.

8. Generate a list of all the attachments moved into the file storage and compare that against what was actually in the attachment record

9. Purged the attachment record of all the migrated files.

10.  Updated attachment reference records when necessary if they referenced the old URL in any way.

This is where we ran into an interesting problem with unicode characters.  The process was relatively slow, and we found that to move approximately 200,000 files took about 40 hours.  So to get into production what we did was made a copy of production and run the process in a test environment.  Then we moved all the files that we copied to the production file share and than removed all the entries from the database attachment record that were already moved and then ran the tiny subset of new attachments out to the storage so we could minimize our downtime.

 

Smart Panda Newsletter – April 2015

Smart Thinking Newsletter

5 Ways an Effective ERP Helps to Grow Your Business

In today’s competitive market, it’s more important than ever that your company runs efficiently and has good data management in order to serve your customers quickly and effectively.

A great ERP strategy helps you save on costs, leaving more room in your operating budget for marketing. Meanwhile, your company will be able to react more quickly and plan ahead.