Installation of 8.97.1 service pack - IPC errors for Application Server...

altquark

altquark

Legendary Poster
Hi everyone

ok - I'm trying to install a new Enterprise Server (Application Server) using the 8.97 server manager. I've run into a couple of issues I'd like to highlight - but I also have an unsolved issue as well.

First of all, its important to note that the underscore character "_" should not be in a server name. The server manager will not recognize a server with the underscore. This was an issue with the JAS server (where the cookie didn't recognize the underscore) but app servers haven't been affected before. Under 8.97 you need to be aware of this little gotcha.

Now, I renamed my server - but when I deploy the Enterprise Server code (intel) to the machine, it installs - but when I try and start I get a bunch of IPC errors. Usually these errors indicate that the services should be uninstalled and reinstalled - which I've tried a couple of times - and I've also ensured the services start as a known administrator account to no effect. Has anyone else encountered these issues on an Intel platform - and have a solution ?
<font class="small">Code:</font><hr /><pre>
3340/2372 MAIN_THREAD Sun Jun 08 15:59:33.919008 ipcmisc.c299
IPC2100012 - ipcGetResource called with an invalid name parameter JdeProcShm.

3340/2372 MAIN_THREAD Sun Jun 08 15:59:33.919014 ipcmisc.c299
IPC2100009 - ipcCreateResource (called from UNKNOWN:-1) called with an invalid name - name=JdeProcShm, type=5, flags=1, size=3420164, init=0.

3340/2372 MAIN_THREAD Sun Jun 08 15:59:33.919017 ipcmisc.c299
ipcSawInit: Error: ipcCreateResource 3

3340/2372 MAIN_THREAD Sun Jun 08 15:59:33.919026 ipcmisc.c299
IPC3000010 - IPC function called with an invalid handle.

3340/2372 MAIN_THREAD Sun Jun 08 15:59:33.919029 ipcmisc.c299
Error: ipcLockResource 2

</pre><hr />
 
I'm sure you've done this, but we're seeing some issues with the changes made to the JDE.INI in the management and metadata kernel definitions. Also, we found that there are some SM agent updates available depending on which TR you are on (we were using 8.97.1.1). We're still trying to sort through the kernel issues with Oracle.
 
yes - I'm trying to implement 8.97.1.1, and deploying 897E11_06_50.par - there isn't any newer SP is there ? Gawd. I really expected that by now, Oracle would have gotten 8.97 stable for deployment.
 
Jon,=0A=0AI have had the SM-based deploy create an invalid IPC start key on the Intel platform. Normally on Intel you don't actually need the key. I n some cases I have found that SM is generating the JDE.INI with a null IPC start key value. The ipcCreateResource is trying to work with a null valu e. This results in the "invalid name" message. At least that has been the cause for the message you are reporting in a couple of my 8.97 Intel insta lls.=0A=0AThis is from an SM-created JDE.INI where I saw the problem:=0A=0A [JDEIPC]=0AipcTrace=3D0=0AmaxNumberOfResources=3D2000=0AmaxNumberOfSemaphor es=3D1000=0AstartIPCKeyValue=3D=0AavgResourceNameLength=3D40=0A=0AJustin=0A =0A=0A
 
Here is my JDEIPC section :

[ QUOTE ]

[JDEIPC]
ipcTrace=1
maxNumberOfResources=2000
maxNumberOfSemaphores=1000
;CLSID=
;startIPCKeyValue=6000
startIPCKeyValue=
avgResourceNameLength=40


[/ QUOTE ]

Note - I changed the startIPCKeyValue from =6000 to nothing. No effect. I have also tried bumping up the number of resources and semaphores to no effect.

I have a strong suspicion that this is actually a security issue. I have also tried running porttest - and get "process <porttest> cannot be registered"
 
Yep, that looks like the culprit. Your startIPCKeyValue is null. The=0Ast andard for Intel servers prior to SM was to deliver the CLSID and=0AstartIP CKeyValue commented out in the JDE.INI. With the=0AstartIPCKeyValue not pr esent I believe the ipcResource apis just=0Ainitialize the values to blank or don't use them at all. With the key=0Apresent but null it seems that th e apis actually try to pass a null=0Avalue to the underlying window ipc cre ation function and that causes it=0Ato choke.=0A=0AWhat I have been doing i s just adding a numeric value for this value=0Ajust as I would under Unix. I started by deleting the startIPCKeyValue=0Aentry that Server Manager pla ced there. But I figured it might just=0Aput it back at some point in the future. As an aside I always populate=0ACLSID with something. I create a unique value that represents the=0Ainstance that the JDE.INI belongs to jus t in case I will do=0Amulti-foundation. I don't know if CLSID is even requ ired anymore. It=0Amight be used when creating the service entries. I rec all the=0Amulti-foundation documentation used to have you generate a GUID t ype of=0Avalue using a windows utility. I typically use something like=0Ae 812ent-6014-dv which I figure is a value that would never be generated=0Aby other windows program. =0A=0A
 
ok - I changed the values to the following :

[ QUOTE ]

[JDEIPC]
ipcTrace=0
maxNumberOfResources=2000
maxNumberOfSemaphores=1000
startIPCKeyValue=234789789479
avgResourceNameLength=40


[/ QUOTE ]

and have had no effect. Still the same errors.
 
To be honest with you, I believe it's going back to the days of "validation in the field". We're grappling with issues with 8.97.1.1, and there is a SM update available. The rub is, we've been told that what we are seeing is reported by several clients, so they are not sure they want us to apply the SM update. Our issues too revolve around kernel and .INI setting issues (actual wrong settings in the INI).
 
holy crap. Thats a pretty nasty state of affairs. I've been telling my customers that 8.97 seems to be stable because others have successfully been implementing it over the past few months. Now I'm learning that its not stable at all - that it doesn't even install correctly. That SUCKS. Makes everyone in the field look like an idiot....

yeah - good one oracle. Nice way to promote your new server manager ...grrrr

Well, I have a call into Orcl - hopefully its something stoopid on my part.
 
8.97 is fine.........just a few glitches like anything else that's new.

My major issues are on WAS ND (hurts oh so bad) and on the iSeries where the kernel definitions are all wrong and I have to manually retype them - yep all 32 of them.

No I haven't logged these issues because I would not want to deprive anyone else of the similar joy.

Overall people are please with 8.97 - I've done 9 since Nov and there is no slow down in sight.

Colin
 
doh

Maybe I have to eat crow.

Why do I trust that Visual Studio is installed correctly by someone else ? Looking for VS .NET 2005 CD and will reinstall myself...
 
Just a FYI with VS 2005, there is a POC fix that has a reengineered BUSBUILD.EXE. We ran into a situation with 8.97 where attempting to use debug or in cases rebuilding a DLL would cause complete corruption. Oracle is aware of it, and has the BUSBUILD.EXE available...so I'm sure it happened to others.
 
Jon - what was your resolution for this error - we are doing a failover test with AS/400s 8.12/8.97.1.1 and are getting the exact error that you are

Thanks, Nolan
 
FYI - you can RE-generate a new CLSID.TXT file by opening up a DOS prompt and typing
UUIDGEN –oc:\clsid.txt

then copy the value newly-generated in the C:\clsid.txt file in the following area on the new enterprise server’s JDE.ini file in node

[JDEIPC]
ipcTrace=0
CLSID=e2b983c4-efb8-4578-b770-a168d101f171
 
I realize this is an old post but does anyone have a solution? I am encountering this issue today when we tried to switch over to our DR box. We are on E812 with TR8.98.3.3 on IBM I.

Help.

Thanks.
 
Being that a DR Box isn't, necessarily, an exact replicator of the box it mirrors for - have you considered clearing the necessary SQL Packages?

In the past, I've found that 'some' IPC errors are related to SQL Packages. Once cleared, they magically go away, no rhyme, no reason.

If you read the last few posts, it appears the issue was resolved with either re-installation of Visual Studio (and an update) and identifying the CLSID.

There is an endless list of issues that cause IPC errors....

Hopefully, today was a test of a DR Cutover. If that is the case, your organization should be PROUD that you actually test the DR Box! Many test the DR, less than they validate that Backups actually can be restored!


(db)
 
Back
Top