Enterprise Server Migration: UNIX

In my opinion after Package builds, Server Migrations are the real staple food for a JDEdwards CNC consultant. The constant changes in OS technologies and the ever expiring hardware support contracts ensure that we do at least a couple of such migrations in a financial year. If your setup is configured for high availability then you get to do it more often than you would like.

I still remember as a young trainee getting a grasp of this was a nightmare. I have an unexplained fear of the Typical Installation Plan (P98240) application and the white space that it shows. Grids do not scare me as much as that particular white space. All the mumbling rumblings of creating and add on plan, adding the new enterprise server and then removing the old one went over my head in those days as a trainee. But I did one thing well, nodded my head as though I understood every last word of my trainer and sailed through the training. I am more of a guy who knows that if he is drowning he can swim but just wont do it for leisure in a swimming pool. I got to have the waves to challenge me.

Finally when I got to do my first real Unix Enterprise Server Migration at a client's place i dug deep. I dug so deep that I landed at the tables that govern them all. It all started making sense and i have done 9 such migrations this far. Lets talk about the tables that we should be looking at:

• SYSXXX.F98611 : DataSource Master Table
• SYSXXX.F986101: Object Configuration Master Table
• SYSXXX.F91300: Schedule Job Master Table
• SYSXXX.F9650: Machine Master Table
• SYSXXX.F9651: Machine Detail Table
• SVMXXX.F98611: Data Source Master (Server Map DataSource)
• SVMXXX.F986101: Object Configuration Master (Server Map DataSource)

Here SYSXXX stands for the Sys schema in the database that has all the tables that fall under the "System - ProductVersion " data source. For instance System - 812 will have a SYS812 schema and System - B7334 will have a SYS7334 schema. Similarly there will be a SVM7334 schema for 'EnterpriseServerName - B7334 Server Map" data source.

If you just change the old server name to new server name in the above tables your migration is half done. Here's a sample Update query that can be run to update the same in say SYSXXX.F98611.

Update SYSXXX.F98611 set omsrvr = 'newserver' where omsrvr = 'oldserver';

 All you need to do is get the old server name and replace it with the new one, matching case to case.To get the entire list of updates that you should make, you can just go to the tables I specified and pick the values that you need to change. Once you get all the values it should be fairly easy chalking all the update statements out.  Be very careful with the case of the name, specially in Unix



The next step is fairly simple. Once you get the new server ready, make sure you have "rsync" command working on the new server. Make sure you have the same user id configured on this new box. Once you are able to login to the new box with the same id, follow the following steps.

• Copy and paste your .profile from the old server to the new server
• Make sure you can reach your database from the new server. If you have NAS mounts for the database clients make sure they are connecting properly
• Check the "cc" libraries if they are consistent with those on the old server. Make sure the version is in the MTR.
• Run "Rsync" to sync up the base "\jdedwardsoneworld" directory on the new server with the old server. Here's the syntax of typical rsync run:      rsync -avz --rsync-path=/usr/local/bin/rsync /apps/jdedwardsoneworld/* jdeuser@newservername:/apps/jdedwardsoneworld
• Update the JDE.INI to reflect the newservername as the security server. Do this step only if you know that the old server was a security server.
• Run ./RunOneWorld.sh and you should be delighted and dancing by now.
• Before you get too excited run the porttest and check the output. 

So this is how I do my Server Migrations. I find it fairly easy to control and it keeps me away from the Installation Plan. Rather than executing something which I don't know the details of I am much more comfortable changing value and controlling my destiny!!

Lets talk .profile

The .profile file in a Unix environment is a "know all" file. It resides under the /home/<userid> dir of the os and it's the first one to be executed whenever that particular user logs in. This is the file that creates the environment for the user and has all the shell options and environment variables defined.

Before we go into how JDE uses this file and why is it important for it, lets see what all it has first:

First and foremost comes PATH:

As the name suggests this is where the path to the dirs of the installed software go. Lets suppose we have a Unix user account MaxPayne. If MaxPayne has all the paths to the software or commands he uses defined in the .profile , he can run those command from anywhere once he logs in to the Unix shell.

Then comes the Editor.

More often than not, when we talk about default shell its the BASH shell and MaxPayne is no different. His shell is bash too and his .profile has Vi as an editor. Vi Editor is one of the most powerful command line editors that we have. Refer my post for the details about using Vi. If you need to change your editor all you need to do is specify it here in the .profile. For the record MaxPayne loves Vi.

Now we see PS1

PS1 defines what the command prompt looks like in the shell. Typically you will find the server name at the command prompt. But MaxPayne is smarter, he has included the $PWD in the PS1 definition so that he can see which dir he is in without ever needing to run pswd again!!

Last common entry is the Alias

Aliases are used to rename some commonly used commands. For example alias dir=ls will help a confused windows user to get the directory information he needs. Aliasing dir with ls tell the unix system to run ls every time MaxPayne types dir.

All the above are default entries in the .profile of any user. When it comes to a JDE Enterprise server what we see are the Oracle homes and the oneworld homes defined in the .profile. When the platform pack is run in the system it creates a .oneworld file in the user dir. This file tells the jde processes where all the JDE files are. We load this .oneworld in the .profile of the JDE file owner. Unless this is done services will not be able to start. So now when you see load libraries failing or path related issues coming up on restart, you know where to check. Majority of the times a corrupted .profile is the source of this.

This in brief is what .profile means to the JDE CNC. If you need any help configuring yours feel free to drop me a comment.