Datadictionary issue

78aspide78

78aspide78

VIP Member
Dear All,
Im running 9.1 release (TR 9.1.0.4) on ISeries DB server.
Sometimes I have a strange issue with datadictionary. From different applications and report the quantity (UORG for example but I think all from QTYINV class) became to be stored on the database without taking care of display decimal. I have 4 decimal for my data item, so the right behaviour is to store the value of 4 as 40000 but it is stored as 4. I'm sure that is a local dd corruption problem (related to enterprise server) because deleting the global table e dd spec from the path code of the ent. server and restarting the services everything works fine (until the next time).

I'm sure it's not related to the OS and the machine because the issue is the same on WIN and ISeries platform, and I'm sure it's not related to pkg deploy because too.

Does anyone have any ideas on this?
 
Hi Bruno,

I'm at a 8.98.4.2 client (SQL Server, Websphere) and we have seen the same DD issue. Haven't found the cause yet, but definately points to an enterprise DD problem. Did you get anywhere with your problem?

Craig
 
Just a hunch, since I've seen something similar with decimalization and formatting.

Are either of you Multi-Currency?

There's a bug, where if a currency value does not have a currency value assigned to it and the organization is Multi-Currency - Decimalization can be ignored for display values (formatting/edit code and decimalization).

I'm wondering if the issue is progressing into other realms, now.

To Resolve the issue, copy the Default Currency to a <blank> currency.

(db)
 
Thanks Dan,

We're not seeing the issue with any currency amounts, just quantites (QNTY to be specific right now).

Craig
 
Hi Craig,
I was not able to understand the root of the issue.
Two weeks ago I decided to run the QTYINV conversion program to be sure that all DD from this class have the same decimals.

I don't know if this will resolve the issue (it happens once per month).

I upgraded the TR too with no success, so it's not a TR bug (I have other clients running the same release and TR with no issue).

I think somethings goes wrong when the ent server try to update the local dd.
 
Hi there,

We've been trying to cope with this issue for a year now. We reported it on this forum already (look at posts with QTYINV as search key).
I agree, it is NOT related to TR: We are E1 8.12 with 8.98.4.6 but seen it on 8.98.2.1.
It's not related to hardware either : we had it on P5 with running AIx5.3 and WS5 and we have it now on P7 running AIX6.1 and WS7.

There's another I can tell you : seems to us that each time the issue appeared, it was after a FP generation crashed and we had to build another.
Has it been the same for you?

Greetings

Eric
 
Hi Eric,
what do you mean with "it was after a FP generation crashed and we had to build another"?
 
Hi bruno
Here's a scenario

- Transfer objects from PY to PD
- Launch build on FULL package
- It crashed (Through CNC manual action for example during build on enterprise server)
- Correct the error and relaunch the FULL package
- FULL package build finished successfully
- Deploying ...

From this time, all update package generated an issue with the QTYINV value (*1000)

Greetings

Eric
 
We have also connected this issue with a full package build, though we did not have any crash during the process. Each time a full package is built, QNTY will display * 1000 (0 display decimals). Delete the DD files in the path code, and it's fine. As a band-aid, that is now the CNC practice after deploying a full package.

The F9210 data has not been changed. No error messages in package build logs. Frustrating.
 
For what it's worth, when a full package fails, for any reason, I delete it and start over. I've had way to many strange things happen when I try to re-start a full package.

Tom
 
Craig, so you are able to run JDE without dd issue if you delete the dd local spec after each full pkg? or issue comes again before a new full pkg?
 
Hi Bruno,

So far we have not seen the issue re-appear without building a full package. We delete the dddict, ddtext and glbltbl tam files that get delivered with the full package and the display is correct. If I get more info, I'll repost to this thread.

Craig
 
Thanks.
So my next action plan is:
1)stop the service and delete the local spec
2)start the service and turn on the metadata kernel log
3)repeat these steps each time a non hot pkg is deployed (BSFN, Table, etc..).

I hope to find a final solution.
 
Just so I understand ...

you are saying that the corruption happens without a full package build?
 
The intersting thing about this is that the DD files delivered with Full Packages on Servers are actually empty. So in effect, deploying a Full Package actually works the same as deleting the old DD specs, or supposed to work like this...
 
Hi Alex,

Yes, I thought the same thing but according to the CNC team, the pathcode contains a set of DD files that are not empty (but very small) after the build and deploy.

Perhaps it is something with the build machine?

Craig
 
I think, .ddb's are actually empty (0 bytes size) and .xdb's are about 3k in size - these are index files, they only contain the index framework structures, with no actual content.

I would have thought that this is very difficult to get wrong when building, so JDE very probably gets it right. My prime suspect would be what happens at the first atetmpt to use them by the Enterprise Server after the deployment: it must be trying to populate them with all the data that it immediately needs and probably does that concurrently too.

Or perhaps it never closes the open handles to the original files during the deployment.

You should be able to easily test it: what if you were to delete these 6 files from the finished Package and then Deploy it? - this should clean up any pre-existing DD specs in the target PathCode & is effectively the same as deleting them manually. Except that the Server is running at the time, so if my theory about E/S choking when doing the initial DD build is correct, it would make no difference and you would still end up with the same issue.

I assume that when you say "we delete these files", you mean that you shut down the services, delete the files and then start the services up, right? - that's probably what it really needs anyway, so you'll just have to do this as a post-deployment manual step until it's fixed in the foundation, I guess...
 
Yes, it randomly happens, we are able to work for some week but sometimes the problems occurs.
 
My theory was the same but in actuality it was rather different. Consider this on a server with no user activity other than CNC ...

DV path code exhibits "corrupt" DD issue
Delete 6 tam files (no services stopped)
DV path code normal
Build and deploy full DV package
DV path code exhibits "corrupt" DD issue
Delete 6 tam files (no services stopped)
DV path code normal
Re-Deploy full Package
DV path code normal

I'm pretty sure the DD tam files contained data (.ddb) after the build, but I'll try to verify that tomorrow.
 
Back
Top