JDB9900600 - jdeRemoveDataPtr() Issue

[PlanetOneWorld]

Hi all,

I have been getting this nightmarish error..in the jde.log and not been able to resolve it for sometime now. There are couple of threads for this but no success story has been posted yet.

JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr().

I am using Std BSFN's for BOM Explosion. In one of the Business function's a pointer is being used and I have made sure to call the Close pointer option(i.e jdeRemoveDataPtr()). It is an unconditional call and gets to that code when I pass ProcessMode as 9. Apart from this I do not see any other references to pointers.

So any Idea why I am getting this error. Like others who had this before, this issue comes up only after processing a large set of records. One important that I have noticed is, once the report finishes, I cannot access any object in OMW or anywhere as I get the error stating Objects References are blank.

Any Ideas/Suggestions will be of great help,
thanks in advance,
Sats

 

[Vish Nath]

Hi,

The cause of error "JDB9900600" in your case might be due to passing wrong parameters.

Which BSFN you are using? Please post your parameters and jdedebug.log.

What might have happened is that the BSFN which you are using might not be getting the handle pointers created in first call, back in subsequent calls and might be creating them again in every calls.

You can try using BSFN B3003090 (F3002 Get Next BOM Record Shell) in combination with B3003450 (Cache Process BOM Shell) for exploding BOM. I have used it sucessfully manytimes for Multi-Level Explosion of BOM. You can have a look at R30460 to study the parameters.

Hope it helps.

 

[PlanetOneWorld]

Thanks Vish for the response. I am using the same business functions in a report that has been cloned from R30460. All the parameters are fine. The report works perfectly alright for smaller Data Selection.

I am able make progress, the issue is with X4101 being called from B3003090. Memory is being allocated in X4101 and is being deallocated in B3003090. The report works fine until the pointer reaches a value 999. I heard that there is a limit per session of pointers use as 999.

Is there a way to reset this value? or is there any workaround. Thanks again.

 

[craig_welton]

Hi,

Do you have the same problem with the UBE R30460?

We had to chase down a similar issue a while ago. If B3003090 is freeing the memory, it should also call jdeRemoveDataPtr to remove the pointer from the internal list. If you examine the jdedebug.log, the function calls will pass the pointer as a GENLNG. As you saw, it is a value up to 999. This is an index to a list of pointers. Run the UBE for one item, the pointer index should increase and decrease to the same number if everything is removed. If not, a function is not performing the remove. It takes some research but you should be able to find the culprit.

Craig

 

[PlanetOneWorld]

Thanks Craig for the reply. Well the culprit in question is the "GetItemNumberbyShortItem" function (X4101). The calling function B3003090, is doing both the pointer removal and deallocation of memory. I see the value becoming 'Zero' in debug. But when the next line comes and the jdeStoreDataPtr() is called, the genlng field has an incremental value rather than 1. I am not sure where this index is coming from. Could this be through some internal functions. If so how can I reset it..

I read a post stating that this a limitation in XE, we are on JDE5 (B7334). Any ideas if beyond XE this has been fixed or if any ESU needs to be applied?

thanks again in advance.

 

[craig_welton]

The limit is still 1000 stored pointers (we had the issue in 8.96). There is no way to reset the list. The rule is if you store a pointer in the list, you must remove it. You said the UBE is a copy of the vanilla BOM print. Does the stock JDE UBE cause the same problem? If not, in what way did you modify it in your cloned object?

Craig

 

[PlanetOneWorld]

Craig,

In order to make the things simple, I have developed a new report based on Item Branch Plant F4102. Called the X4101 - GetItemMasterby2ndItem function. This function creates a ponier and passes it back thru a genlng variable. I pass this genlng variable back to X4101 - FreePointerToItemMaster to free the pointer.

If I run this report in XE, I get the JDB9900600 error but when I run the same in 8.12 I see no error. Oracle then must have taken care of this in the newer release..so there could be some solution for this..I am planning to open a call with them...but the solution they have provided for a similar request is to run the report for smaller range of Data..but in our case..we can't Data Select..as we need to run this report for a wider range.

 

[craig_welton]

Hi,

I checked the 8.10 source for the X4101 functions. They are very simple and don't reference any SARs regarding the remove pointer issue. It is possible that the bug is with the jdeRemoveDataPtr API and was fixed with a later tools release.

Craig

 

[PlanetOneWorld]

Craig..this is what I am exactly looking to get answered from Oracle. If they have fixed in the newer releases at the tool level, they could very well..share the same code change with the prior versions. I guess there is not much for us to do as of now. Thanks for all your help. Will update the forum once I hear something.

 

[Oliver]

Hi,

There's a SAR 8565111 that describes exactly the issue posted and has an ESU for it, JK14176. Anybody can test this for me, if this really works.

thanks.

 

[TRL602002]

Hi,

We had the similar issue when we are trying to issue materials using P31113. The main business function which caused us the memory leak was B3101130 which calls GetItemMasterBy2ndItem (X4101) master business funciton. I found that X4101 creates the pointer and it expects the programs which calls this function to remove the pointer. When we did the change to remove the pointer in B3101130, after this we stop getting memory leaks.

We contacted Denver and tried to convince them using our findings. After a day they came back and gave us a SAR 8361231. It looks like this issue was reported some time back and they had this SAR ready in February 2007. They have sent us a paper fix for this SAR and we went ahead and applied in our system.

Regards,


Gopi Premanand