Mark Vakoc

Subscribe to Mark Vakoc feed
Information and tips about the Server Manager for JD Edwards EnterpriseOne product from the developers that wrote it.Mike Brown
Updated: 5 hours 53 min ago

Here we go....

Tue, 2007-11-06 20:16
If you can read this it means we have gone GA with the 8.97 tools release.  Download, install, and go crazy with Server Manager.  And stay tuned for more tips, tricks, and detailed information about Server Manager.

Multi-Foundation on UNIX

Mon, 2007-10-15 19:43
Today I wanted to setup multi-foundation on the same enterprise server on my Linux based server. I had an existing server that I wanted to "clone" to create two additional installs for testing various tools releases. The primary was installed using platform pack and was already upgraded to 8.97 using SM.

I wanted to take advantage of the multiple instance support in EnterpriseOne that allows multiple instances to run under the same OS user. Typical multi-foundation setups operate each enterprise server install as a different OS user. This works fine, but with the advent of server manager and it's management agents it would require installing and operating a separate managed home for each OS user. This setup works fine, but operating under the same OS user requires only a single agent install which seems like a good idea.

The first think I did was to stop the existing enterprise server using SM. In a shell I performed a recursive copy of the base directory (/u02/jdedwards/e812 in this case) to /u02/jdedwards/port6015 and /u02/jdedwards/port6016). Back in server manager I created two new instances by registering these new installations with unique instance names.

Using SM I went through and modified all the configuration items that were install specific. I went through each configuration category and looked for those settings that referenced the old install path and updated them accordingly. Off the top of my head I had to change the following settings
  • Install Path
  • Build Area
  • XTS Repository
  • JDE and JDEDEBUG log configurations
  • log file configurations
  • Compiler and associated locations
There are also some settings that are not install location specific that I knew add to be modified. These include
  • The JDENET listen and connect ports (set to 6015 and 6016)
  • The IPC Start Key (set to unique, non-overlapping values)
Since these new servers were a copy of an existing install I had to modify some of the startup scripts to use the new install paths. These scripts were located in the SharedScripts folder found underneath the base install. This included changing the paths in
If you are on a release earlier than 8.11SP1 (and thus prior to the platform pack installer) the settings are instead contained in the .oneworld located in the user's home location.  Since this single file defines paths that would be different for each enterprise server instance it is better to use multiple OS users in this case.

Finally, since I'd be running these servers under the same OS user I had to modify the and scripts to set the variable "MULTIPLE_INSTANCE" to 1. This instructs the scripts to be aware that multiple foundations are running under the same OS user. I made this change for all servers, including the original server used as the source.

Back in SM I tried to start all my new servers. The new servers all failed to start. Looking at the SM logs and a little digging later I realized a problem in the logic in the script that determines if processes are already running. The script makes a series of calls to the ps application and filters based on OS user and the JDENET port. Since my new installs included the JDENET port in the path (6015 and 6016) it was incorrectly thinking the startup script itself was an existing E1 process and failed start the server. I changed the install locations so they didn't include the 6015 and 6016 values in the path and all worked.

This is probably not a typical setup but once configured it works very well. There are a few notes I'd like to mention.

First, when performing my initial installation plan I had anticipated these additional ports and defined them initially. This is probably not normal, so one would have to modify their original plan to add the new ports. This creates many of the DB records required for the server such as the F965* tables and the package discovery tables (812 and later).

Secondly one must be aware of the changes made to and to set the MULTIPLE_INSTANCE=1 line. Since these scripts are delivered with the tools release they will be overwritten with each new tools release I upgrade the servers to. I'll have to go back and modify those.

Although this isn't a true step by step guide to configuring multi-foundation I hope it helps the experienced CNCs with some guidance to configuring this sort of configuration.

INI Madness Tamed!

Wed, 2007-09-19 22:52
As many might be aware the task of managing the INI files, used to store the configuration of our server based products, can be difficult at best. Server Manager addresses many of these problems in the following ways:

Complete INIs:
Server Manager provides a web based tools release specific mechanism for editing the configuration files of our server based products. Using Server Manager there should be no reason to manually edit the INI files directly. Server Manager provides a web based view/editing of all the configuration files.

Server Manager utilizes metadata about configuration settings that are delivered with each tools release. To accomplish this we performed many searches over the entire codebase to find every configuration item used. Our policy is: if something is configurable via INI it is configurable via Server Manager. This search resulted in the addition of many, some possibly obscure, configuration settings. It also resulted in the removal of many configuration items that have historically been delivered but are no longer relevant.

For existing enterprise servers that are registered with SM many configuration settings that were present in the JDE.INI that are no longer used will remain in the file, if present, but won't appear using the Server Manager GUI. For our web based servers the INIs are created when the instance is created, so will perfectly match the tools release initially used. If a setting is present in these web based INIs and the server is later upgraded to a release that obsoletes a setting that parameter will still remain in the file, but will no longer be viewable through the management console.

It is, of course, possible that we missed a setting. We did our best, but there are a lot of settings to manage. If a setting was missed and is therefore not available through the management console application it may always be edited directly within the file. All settings not known to SM will be maintained during tools release upgrades/downgrades.

Each configuration item is identified using a short, human readable description. An extended description is provided via the online help and bundled documentation. Default values, where applicable, are provided as reference. Many parameters provide a list of values detailing exactly what is allowed for each setting. For reference the documentation provides the INI filename, section, and entry for each setting.

We've also provided a reference document with the product detailing each setting. As of this writing this is over 350 pages. All the information in the documentation is also available in online help. If you are looking for a particular setting and are having trouble locating it using the new descriptions the documentation allows a quick lookup based on the INI entry details.

This reference documentation is current as of the 8.97 tools release. It will be kept current for all future tools releases. The reference may also be of assistance to earlier tools release but be aware that not all settings will be applicable to the earlier releases.

Relevant INIs:
Another task we undertook was to remove the configuration parameters that are not relevant to the product. Historically the JAS.INI and JDBJ.INI used for web servers were simply duplicated for the other web based products (collaborative portal, transaction server, PIMSync server, and the new business services server). We evaluated these products and removed from their configuration parameters that didn't apply. This means that each server has it's own unique set of configuration parameters. We hope this will reduce confusion in not appearing to require configuring parameters that do not apply to the server.

The transaction server (RTE) also previously contained three separate copies of each configuration file, one for each of the EARs that make up the product. This has been removed and only a single set of configuration files are shared among all the EARs.

There's much more to talk about configuration management in Server Manager: server groups, configuration comparison, and audit history. I hope to post on those topics in the future.

Quick History of Me

Wed, 2007-09-19 22:24
Here's a quick background of who I am, why I'm blogging, and what I hope to accomplish here.

I have been with JD Edwards/PeopleSoft/Oracle for almost ten years now. The first three or so years were spent on the support organizations SWAT team flying to customer sites to address specific customer issues and provide technical assistance. Life on the road was great; I traveled to more than twelve countries and countless client sites and really enjoyed the work. It came time to stop traveling so much so I settled down in the Denver area and created the Support Assistant diagnostic product. I'm still very proud of SA, and am glad to say that the product is alive and kicking. More on that later.

After working primarily on SA for five or so years I decided to tip my hat into something new. I wanted to apply my experience from the field and support organizations and create something new. The result is Server Manager. Specifically, I wanted to address
  • The difficulty in installing and upgrading our server based products
  • The difficulties around configuration management; understanding all the configuration parameters and managing the configuration of servers across an E1 installation
  • The difficulty in monitoring the activity of E1 servers
  • The difficulty associated with troubleshooting servers when something goes wrong
Hopefully you'll see that Server Manager addresses these and many other administration activities that will truly result in a lower cost of ownership.

As someone unbelievably addicted to blogs, generally of a geeky nature, I've been "inspired" by many others to use this forum to publish tips, tricks, knowledge, and general musings on the product of which I'm so proud. I'm particularly inspired by a blog by a co-worker entitled 'The Buttso Blathers' with very insightful posts on all things OAS (Oracle Application Server).

There is one thing this blog does not represent; it is not a support forum or a place to seek help.  So tune in and learn more about the exciting Server Manager product.


Wed, 2007-09-19 22:19
Before digging into the product itself I want to express some thanks to the team that worked on Server Manager. At this point I'll let the involved parties remain anonymous. This was a team effort, and I want to express my personal thanks to the development team and quality assurance team that helped create the product.

So, for all those involved in Server Manager, I say thanks.