JDE Package Build: Pro Tip

Build your Production Full Packages on QA or Dev Enterprise Server ------- Yes you read that right! And no I am not smoking anything suspicious.

Seriously, there are more than one benefits of doing this. Before I actually go ahead and enlist the benefits, lets take a look as to how we can set this up. You now know that all you need to do for JDE system to recognize a server or machine is to update in a certain table somewhere. This will be no different! Lets see what all tables we need out here.

When we assemble a package , we select the server we want to build the package on based on the entries in F98611 (DataSource Master) Table. So that's where we need to change. Now, we have two DataSource Master Tables, one in the Server Map and one in the System data source. Here we will do the changes in F98611 in the System DataSource because thats where my System looks into for the server info.

If you have the same "SYSXXX" the entry for all your enterprise servers should already exist there and you will not need to configure anything separately. But if your SYSXXX for production is separate you will need to insert the QA server name in the table. This is what you will need to insert in the SYSXXX.F98611 table:

insert into sysXXX.f98611
select omenhv, 'NEWSERVERNAME' omdatp, 'newservername' omsrvr, omdatb, omoown, omdllname, omll, omlib, omomui, omomto, omomds, omomjd, omomcc, omdstp, ompid, omdatuse, omuser, omocm1, omjobn, omocm2, omupmj, omocm3, omupmt, omocma, omocmb, omocmc, omocmdsc from sysXXX.f98611
where omdatp ='NEWSERVERNAME' and omsrvr = 'newservername'

Insert, commit and restart your EOne services for the changes to take effect. Unless you restart the services the entry will not show up on the Server Selection Screen in the Package Assembly application. No points guessing why we need to bounce the services for the entry to show up in that table: Its a bootstrap table.

Now you can select your QA server when you are building a PD full package and the build happily runs on the QA Enterprise server. Yaay!

But wait! What happens after the build completes. You can not deploy a package built on the QA server onto the PD enterprise server, Can you?

Of course, not!! But there is something else we can do. Go onto your Deployment server, under the PACKAGE\packagename dir you will have a folder by the name of the Operating system of your PD enterprise server. Inside this you will have a "enterpriseservername.inf" file. Go ahead and open it.

It will look somewhat like this:

[SERVER PACKAGE]
PackageName=PD7334FQ
Type=FULL
Platform=SUN5.10Generic_139555-08
BuildMachine=qaentsrvr
BuildPort=6010
SPEC=1
SpecList=0 , 1 , 10 , 13 , 14 , 15 , 16 , 17 , 18 , 2 ,
BSFN=1
CAEC=1
CALLBSFN=1
CBUSPART=1
CCONVERT=1

You will need to update the name of the file to "pdentservr.INF" and change the BuidMachine to pdentsrvr. Save and exit.
There may be a case where you are running two different versions of OS on you enterprise servers. If that be the case, you will need to update the Platform accordingly. SSH into your PD enterprise server and run "uname - a " to get the OS name and just update it in the inf. This takes care of the client part of the build. Fun is at the server part.

For a package to be deployed the package has to exist in the /jdedwardsoneworld/exxx/packages dir of your enterprise server. Now, that we have build the package on the QA Enterprise server we need to send it over to this dir on the PD Enterprise Server. Make sure you have "sftp" enabled between the two servers and libraries for "tar" utility are installed on both of them. Here's how you transfer your package beween QA and PD Enterprise servers:

1. ssh into your qa ent server
2. go into the /apps/jdedwardsoneworl/packages dir using cd command
3. run this tar -cvf  temppkg pdpackagename
4. this creates a zip file called temppkg for your full package "pdpackagename"
5. sftp pdentsrvr
6. login with your passwd... its mandatory that you have the same userid owning all the jde files and folders on the two servers.
7. go into the /apps/jdedwardsoneworl/packages dir using cd command
8. run this ... put temppkg
9. Once the copy completes login to your pd ent server
10. go into the /apps/jdedwardsoneworl/packages dir using cd command
11. run this... tar -xvf temppkg
12. Voila .... you have your pdpackagename dir in the /apps/jdedwardsoneworl/packages dir

Now your pd package is ready for deployment. Oh my goodness!! So much effort just for Package build and deployment!!

Well, a lot of this is just one time setup.And it sure has a lot of advantages. Its time we see what they actually are. Here you go:

• You can run a PD build during business hours. No night outs!!<Happy CNC>
• Ube's running on the PD ent server will not affect the speed of build. <Happy CNC>
• Scheduler server can continue to run while the build is ON and you can just stop it when you want to deploy the package <Happy Suits>
• Your setup complies to the SOX control which abolishes installation of compilers on Production machines. <Happy Suits>

So two reasons to get a Happy CNC and two for the Suits, I say there can never be a more Win Win in a single act!!

Jokes apart, compilers on production servers are indeed frowned upon in the SOX parlance and there exists a way where we can avoid this completely in JDE. This also helps if you need to trouble shoot a build for anyreason, it can be done whenever needed with no affect to the business whatsoever.

I know this has become one long post and you may have questions about the approach. Well that's why whe have the comment section there. Feel free to ask away....


Jd Edwards by Donatienne Ruby, Christabel [Paperback]

Find us on Google+

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!!

What's up with Vi

Continuing with my last few posts on basics of Unix world that a CNC needs from time to time, today I chose to talk about the Vi editor. Its one of the most powerful editors on the console and certainly must know aspect of CNC administration.

Here are the few commands i know and have used over the years in Vi extensively. If you don't get it straight away just practice with patience and you will be rolling in no time

If you do not want to go the full path straight away just concentrate on the "basicest"  operations of creating, navigating , inserting and deleting in a Vi editor and you will be good for a while!! :)

General Startup
To use vi: vi filename
To exit vi and save changes: ZZ   or  :wq
To exit vi without saving changes: :q!
To enter vi command mode: [esc]

Counts
        A number preceding any vi command tells vi to repeat
that command that many times.

Cursor Movement

h       move left (backspace)

j       move down

k       move up

l       move right (spacebar)

[return]   move to the beginning of the next line

$       last column on the current line

0       move cursor to the first column on the
current line

^       move cursor to first nonblank column on the
current line

w       move to the beginning of the next word or
punctuation mark

W       move past the next space

b       move to the beginning of the previous word
or punctuation mark

B       move to the beginning of the previous word,
ignores punctuation

        e       end of next word or punctuation mark

        E       end of next word, ignoring punctuation

        H       move cursor to the top of the screen

        M       move cursor to the middle of the screen

        L       move cursor to the bottom of the screen

Screen Movement

       G        move to the last line in the file

       xG       move to line x

       z+       move current line to top of screen

       z        move current line to the middle of screen

       z-       move current line to the bottom of screen

       ^F       move forward one screen

       ^B       move backward one line

       ^D       move forward one half screen

       ^U       move backward one half screen

       ^R       redraw screen
( does not work with VT100 type terminals )

       ^L       redraw screen
( does not work with Televideo terminals )

Inserting

       r        replace character under cursor with next
character typed

       R        keep replacing character until [esc] is hit

       i        insert before cursor

       a        append after cursor

       A        append at end of line

       O        open line above cursor and enter append mode

Deleting

x       delete character under cursor

dd      delete line under cursor

        dw      delete word under cursor

        db      delete word before cursor

Copying Code

        yy      (yank)'copies' line which may then be put by
the p(put) command. Precede with a count for
multiple lines.

Put Command
        brings back previous deletion or yank of lines,
words, or characters

        P       bring back before cursor

        p       bring back after cursor

Find Commands

?       finds a word going backwards

/       finds a word going forwards

        f       finds a character on the line under the
cursor going forward

        F       finds a character on the line under the
cursor going backwards

        t       find a character on the current line going
forward and stop one character before it

T       find a character on the current line going
backward and stop one character before it

; repeat last f, F, t, T

Miscellaneous Commands

. repeat last command

u undoes last command issued

U undoes all commands on one line

xp deletes first character and inserts after
second (swap)

J join current line with the next line

^G display current line number

% if at one parenthesis, will jump to its mate

mx mark current line with character x

'x find line marked with character x

NOTE: Marks are internal and not written to the file.

Line Editor Mode
Any commands form the line editor ex can be issued
upon entering line mode.

To enter: type ':'

To exit: press[return] or [esc]

ex Commands
For a complete list consult the
UNIX Programmer's Manual

READING FILES
copies (reads) filename after cursor in file
currently editing

:r filename

WRITE FILE

:w saves the current file without quitting

MOVING

:# move to line #

:$ move to last line of file

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.

Let’s Mount …..

When i was introduced t0 JDE the first and foremost thing that motivated me to go for becoming a CNC expert was that it gave me opportunity to work on UNIX.  Its beyond doubt one of the most formidable platforms for any business and i was a lover since my early college days :)

One of the biggest differentiating factors in Unix is its file system handling. People coming from the Windows world find it difficult to understand that the file storage has nothing to do with the  drives they see in the explorer but is actually a mounted space allocated from the memory available.  Its this “mounting” that makes any file system available for storage.

Syntax for Mount command is as follows:

$ mount /dev/hda3  /home

This command will “load” the resource or filesystem in disk drive hda3 into the local /home and then /home will have the memory on hda3 for use.

The best part of Mount is that you can not only mount hard drives connected to your server but use ones that are connected to the network as well.  This is what is meant when some one says “the db client is a NAS mount”!!

Remember that there is no registry to be maintained in Unix and we don’t necessarily have to install an application on a particular machine to use it. It’s all about the Environment Variable and the file locations.  So if you have an executable and the right parameters set for it in the environment variable, the executable knows how to take care of itself. It knows exactly where to look for the files it needs to execute.

Now when anyone says that the “db client is a NAS mount”, you can figure out that the DB client is installed on a different machine in the network and that particular drive is mounted in your Enterprise server and the Environment variables on your JDE Enterprise Server are set such that your  server knows where to look for the DB client files when its trying to connect to the DB. As far as both the servers concerned are in the same domain and can reach each other in quick time, this works seamlessly.

The biggest advantage that this brings is maintenance of the supporting Applications. If the company has several hundreds of databases this architecture helps the DB support group to maintain all the db’s on their own servers and all the app teams can just mount the locations. Patching and maintenance is spared of the fragmentation and the upgrades can be handled much more efficiently.

If you want to check all the mount points that are currently there on your server execute the following command:  more /etc/auto_direct

Have fun!!

Let me know if the post gives you a little bit of an insight on Mount as a UNIX feature. You can always check the man pages for details about any UNIX command. My intention over here was to drive away the initial fear of “what’s this!!” from anyone who is new to the world of Unix & CNC admin.

Using the netwm utility on UNIX Application Servers

The netwm utility can be found under the $SYSTEM/bin32 directory of a JDE unix application server. This utility can be used to get/clear the net and kernel procedures running for that instance.

Following is the syntax for the utility:

usage: netwm [-r] [-c pid]

where:
-r optionally clears the kernel request counts.
-c optionally clears the process information for pid which can be either a net or kernel process.

If only the structure header information is returned by the netwm command it means that the services are down and need to be restarted.