Issue with MultiFoundation and Service Pack 89820


Active Member
Hello All

I am trying to run multi-foundation with 89721 (Production) on one port 6014 on Prod Server and 89820 on a different port 6114 on Test Server and when I start up services on the Test Server the jde logs complain about not being able to find the Security Server

1944/5240 MAIN_THREAD Sun Nov 08 17:34:12.988000 jdecsec.c2113
JDENET Error = eConnectionFailed

1944/5240 MAIN_THREAD Sun Nov 08 17:34:12.988001 jdecsec.c2546
Failed to communicate with security server: Unable to locate Security Server

1944/5240 MAIN_THREAD Sun Nov 08 17:34:12.988002 jdecsec.c262
Failed to validate user JDE by password

1944/5240 MAIN_THREAD Sun Nov 08 17:34:12.988003 Jdb_ctl.c4147
JDB1100015 - Failed to complete Security check by Pwd

1944/5240 MAIN_THREAD Sun Nov 08 17:34:12.988004 Jdb_omp1.c639
JDB9900246 - Failed to find existence of default OMAP for environment STARTUP

The SecurityServer is the PROD server at port 6014 and I assume the Test Server service is trying to validate against port 6014 on the PROD server for Security Server and since I have set the connect and listen port on TEST server to be 6114 per the instructions of many Multiple Foundation documents, it is not able to connect.

Of course when I change the CONNECT port number to 6014 on the TEST Server, the JDE Service comes up fine and logs are clean.

I have looked at 3 or 4 documents on "Multi Foundation" to refresh and see what I am missing but none of the documents address this aspect.

Has anyone run into this?

In the interest of full disclosure I did build a new full client package with new service pack but not a server package (thus I did not deploy one either) because in my mind it seems I need to get the new service pack to start up clean with different port before I can expect to connect and build a clean server package.

Also, I did not MOVE the DV812 pathcode directory over - I copied it to new service pack level and I RENAMED the DV812 pathcode to "DV812OFF" so it should not be interfering with anything. I should also mentioned I tried changing port reference in F96511 table which none of the "Multiple Foundation" docs I reviewed talked about specifically as to how to how it may or may not relate to security server.

Before commenting :) (and no egotistical, insincere, presumptuous j*** off responses either) ideally, I would like to say I do NOT want to turn SecurityServer off anywhere, I do not want to designate/define a second security server, add another OCM/system database nor do I want to change any other aspect of my E1 system configuration except within the Test Server JDE.INI file. I am trying to make this work within what the known documents say but it doesn't seem possible. I know I have had multi foundation work before so I assume I must have forgotten a simple config option.

Is there a way to make this work WITHOUT doing any of the above?

As always, I am fully willing to admit I forgot something, and I will withold comments on the product or opening a SAR until I hear from colleagues. :)

Thank you all in advance.

Also, has anyone noticed you have to use WINDOWS NT Authentication for 89820 service pack to connect via ODBC on the Deployment Server? I am working that call with Oracle now. I proved that out because I can use SQL Server login account with 89721 but not 89820.

Joe Tirado
Senior CNC Consultant

Sebastian Sajaroff

Legendary Poster
Hi Joe :

Have you set different IPC start values for both instances?

I remember that Windows installations required a CLSID
unique identifier per instance, have you checked that too?


Jeremy M.

Well Known Member
I remember when I tried to set up Multi Foundation and it turned out to be a disaster. I was running 8.96.x.x and wanted to run 8.97.x.x on the test environments. Turned out 8.97 used a different password encryption method and the only way to set it up was to have two sets of security tables. Maybe that is still the case between major tool releases?


VIP Member

please try searching the Oracle site for a Red Paper called "Multifoundation with Tools Release 8.97 and Onwards".

It was publised July 2009 and has the file name "(MultifoundationToolsRel8.97.pdf".

What you want to do is achievable. I would strongly recommend 898.2.1.CPU as opposed to Typically the ".0" releases are packed ful of new great stuff and this one is no different. I had one of my consultants who did have some issues with (812, AS400)and they are moving to I'm doing an Xe to 9.0.1 (Oracle DBMS, OAS) upgrade this week and will be going with the latest.

Please try checking the following tables:

F96511 (this is likely the smoking gun and you have to SQL it)
P9654A (accesses the F9650 and F9651 and this is another possible smoking gun)

In the P9654A make sure that you have an entry for your new Enterprise Server on the new port.
Wslect the new enterprise server and on the Form exit select environment.
Enter your new environment that is on the new server.
Generate the server map (I usually back up my F986110 and F98611 in the Server Map before doing this).

Also check your path code definition to make sure that the new path code exists.
The path code needs to have data sources for the Central Objects defined in both the Server Map and System Map.
OCM's of course need to be defined in both locations as well.



Active Member
Thank you Colin Jeremy and Sebastian for your thoughts and replies.

I did see the MF with 897 and Onwards, that was one of the ones I reviewed, yes I checked and updated F96511 and made another enterprise server entry with port 6114- I fear it is a situation where I have to create a second security table and security server.

I have not had a chance to bounce the JDE Service on PROD server - I was hoping I didn't need to because of the Clear Cache function capability on WSJ command.

I will review though everything you guys recommended but still am going to open call with Oracle as this isn't as easy as it should have been and I know for a fact things have changed between 897 and 898 as I already discovered the "hard coding" of the sa login problem on the Deployment Server.

Thanks again though all.


Active Member
Ah Sebastian yes the CLS id. I remember generating one of those manually years ago using some little Windows tool I believe (to be honest I was hoping that WASNT necessary still :) wouldn't that be funny if it still is? I don't see that anywhere mentioned in voluminous PDF documentation.

I did NOT do that part. I did change the startIPCKeyValue though.

I will check this out.
Joe Tirado


Active Member
Hello Jeremy Colin and Sebastian

The issue is as I and Jermey suspected: you have to add/define a SECOND Security Server with a Second JDE812 database (can copy existing) and point that second JDE.INI (with the new port in my case 6114) to use that instead of existing JDE.INI in current service pack. I also had to define two new data sources then update the OCM records to point to them. What a MAJOR OMISSION in the MultiFoundation documentation. Kind of a pain.

Maybe it is there and I missed it.

Thanks for your help.

Joe Tirado


Legendary Poster
Hi Joe

Multifoundation IS a pain - I know, I'm setting up a chinese one right now at one of my customers.

The benefit of using an Intel platform of course is that its easier just to put together an entire instance on a new piece of hardware - that way, you don't necessarily have to worry about IPC values or anything else - just slap 8.97 on one box, and 8.98 on another ! On the 400 you can create LPAR's to do the same thing....whichever way is easier and is more beneficial ! Just my 1/2c


Well Known Member
This might be a silly questions: I had requested our CNC group to setup multi-foundation and one of the CNC consultant is recommending we do VM (Virtual Machine) install. I'm not even sure how that would work. Is the VM for deployment server, enterprise server or both.. and how the package build pick up the right tools level. My question is: is VM used in place of multi-foundation? If so, what are the pro/cons?



Legendary Poster
That was what I was alluding to. There is no issue using a VMWare server to create a multifoundation environment - the VM would be just for the application server (not database or deployment server). You might need a VM Server for the client side as well - either the JAS server or a fat client, depending on the version you're running. The benefit of using a separate server is that you're not going to impact your current system as much, and that you have the ability to bounce/test/play with the new second server more freely. Its still recommended to change the port to a higher port value, just to prevent your dev/test/production users to connect - but its not totally necessary.


Well Known Member
How about your deployment server? Would you switch your folder from one tools level to the other when you build a package?


Active Member
Wayyyy late to replying here Wes but I am old school: I switch (rename) folders on deployment server when I want to go back and forth between releases. Have to change port # in jde.ini file but I am too lazy to setup two directory structures. Besides, it still works! :)