Problem with new path code

Tom_Davidson

Tom_Davidson

VIP Member
I am getting the following messages in my UBE Kernel when I try to submit a UBE from BV (web or fat) in a new path code I have created, UBE's run fine from RUNUBE, and everything else seems to work fine, any ideas?

GetReleaseCache - failed to find the data source or pathcode, DEHYPD812, in metadata release cache.
Jan 18 18:22:24.376136 SpecUtil.c3425 - 177842/6535 MAIN_THREAD GetMetadataReleaseLevelOfPathCode - Unable to determine spec release level of the path code DEHYPD812. Cannot determine metadata format version of this path code. Cannot acccess metadata (specs)!
Jan 18 18:22:24.376160 jdeknube.c784 - 177842/6535 MAIN_THREAD UBE submit- Copying specs from client - Next message packet index = 8.
Jan 18 18:22:24.376288 jdeknube.c853 - 177842/6535 MAIN_THREAD KNT0000547 - Not supported spec format type = 14

Thanks Tom

E1 8.12, Tools: 8.98.1.2, ES as/400, OAS 10.1.3.1
 
Have you added the environment with the new path code to the Enterprise Server's list of environments? Are there OCM mappings for the Server Map side for your new environment and path code? Also, have you created the data sources for the environment and path code on the Server Map side?
 
Hi Tom,
I think you'll need to build and deploy a full package if you haven't already done so.
after that you will probably need to do a full web gen.
Rich
 
Ken, ES's environments: Yes. OCM on Server Map side: Yes. DS's on Server Map side: Yes

Since it's a new production path code, I'm already running one other live prod path code for these services, I'm trying to avoid bouncing services if I can, or at least be sure that I'll get it fixed by bouncing them.

Tom
 
Resolved: Problem with new path code

This is how I resolved the above issue:

I had to kill each of my UBE kernels for them to pick up the new DS's. I did this slowly killing one during slow times and letting them respawn.

I was carefull to kill each kernel while I was in a known slow time for ube submission, then tried to turn on the debug log for the killed kernel to send it to zombie status immediately

Tom
 
Re: Resolved: Problem with new path code

If you had done all that configuration, and not bounced services yet, that would explain why killing the kernel fixed the problem. When a new kernel spawned, it would have read the new OCM, data source, and environment records, and picked up that the new environment/path code was valid.
 
Re: Resolved: Problem with new path code

Ken,

Yea I know. I guess the clearing cache doesn't work on UBE kernels.
frown.gif
I really was hoping it would, as we don't bring our production instance down very often.

Thanks for the ideas.

Tom
 
Back
Top