Location of DDDICT / DDTEXT / GLBLTBL

[wcgodfrey]

List:

I have a situation where I need to have multiple
copies of DDDICT, DDTEXT and GLBLTBL for one
environment and I am exploring various ways of
accomplishing this.

One method would be to have seperate path codes
(probably the way I will go) however if there is
another way I would like to explore that option also.

Does any one know how JDE determines where to go to
find the DDDICT / DDTEXT and GLBLTBL files. Not how
to build them but where to put them?

Bill Godfrey
XE Coexistant SP 14.2
WIN2000 Batch/Terminal Servers
SQL 7 SP 6

_______________________________________________________

 

[Zoltan_Gyimesi]

Hi Bill,
Excuse me that I couldn't answer your question, I just want to add some information for you.

JDE strongly do not recommend to use multiple DD in a single OW system. It has several problems and can cause several faults in data integrity, etc. If I am right, JDE do not support this type of configuration.

I suppose, you have a good reason to use multiple DD and you know the possible traps of it and you are enough cautiuos to implement it.

I suppose, multiple Path Code is not a complete solution for it because in a standard installation all Path Code share the same data dictionary.

If my memory serves me well then once I have seen a documentation about how to implement multiple Data Dictionary on the Knowledge Garden. Sorry, I can not point to it but you can try to search for it on the KG.

Good luck,
Zoltán
P.S.: Could you share with us why do you want to use multiple Data Dictionary and/or what is your problem exactly?

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

 

[wcgodfrey]

Zoltan (and List)

My proble is the following. We currently have
several seperate world enviornments running with there
own data dictionary (some are on seperate AS400's) and
there is the desire to bring all these companies
together inside one data base.
Unfortunately over time (several years) there have
been good business cases brought forward and some
companies have modified the data dictionary (most
notably QTY fields have different display decimals) in
some cases there are quite a few data dictionary
discrepencies between enviornments. The goal is to
convert the company to one world as soon as possible
and then migrate the data to one environment once they
are running one world.
The problem is one deployemnt server, and
therefore as JDE recommends one data dictionary. This
causes a problem when company A has inventory of 4 and
company B looks as inventory and sees 4.000 but in the
data base the value must be stored as 4 or 4000 but
both is not an option (as I am sure you are aware).
This is the delema. I realize that during an
upgrade process JDE (between releases) JDE actually
recommends that the PY enviornment map be changed to
the new data dictionary for the new release while the
customized objects are migrated etc. (This I got from
the Deploy applications course given by someone at
JDE)
My thought therefore is to create the above
situation on a more perminant / temporary basis and
hope I do not regret it later.


--- Zoltan_Gyimesi <[email protected]> wrote:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=OWDEV&Number=17852


_______________________________________________________

 

[JEMILLER]

Bill,

Are you saying that you would like to have different users of the *same* environment use different data dictionaries?

If so, I think you have a problem getting this to work reliably and safely.

My primary concern is that you would now be asking the system to work with the same tables using different display decimal settings depending on (I assume) user group/department. In your current World deployment you are protected from data integrity issues because your tables are separate. I do have a couple of "wild" ideas that might accomplish what you want but if not configured just right and monitored could cause data integrity issues.

The data dictionary location is controlled by the OCM mappings for the F92* series tables. However, these mappings only decide where to retrieve the DD items during Data Dictionary replication by JITR or when generating a full set of DD specs with the R92TAM UBE.

At runtime the applications grab data dictionary information from the DDICT and DDTEXT spec files located in the path code associated with the environment where the user is logged in. If you have pre-generated the dictionary specs by using R92TAM, no JITR will occur and you will only need to grab from these files. If you have not pre-generated these files then the JITR process will look at the OCM mappings for the F92* files and pull the required information from wherever the mappings point. Once a given DD item has JITI'd it will not be pulled down again.

It seems to me that although you could generate a different set of DD specs for different user groups, it would be difficult to force users logging into the same environment to use different DD specs.

On a fat client deployment I guess you could control this via the Windows login script, copying the right set of full DD specs to the path code based on the user logging in.

On a Citrix thin client deployment you could install specific DD specs to specific servers and then control which servers a given user or group would be logged into.

These solutions would be messy and hard to maintain. The only thing I see JDE supporting is to have a single display decimal precision decided for each field and then have the World files converted during the load process into your new shared database.

Regards,






Justin Miller
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX

 

[Carl_Fisher]

This all looks very dangerous. You will get data integrity issues all over the place. You are not segregating your database so, different users will see different display decimals for the same records!!!

I think your better solution is to choose a set of common display decimals, and do a conversion on the data from each site as you migrate it into OneWorld. This would give a consistent result.

You can always check if you have got the Data Conversion correct by running reconciliation reports and other custom reports to validate data out of World and into OneWorld.

OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development

 

[David Robertson]

Hi Bill,
We are running 2 data dictioanries, on B7332 though. The reason here is for change control. Developers do not have access to the production Data Dictionary.

There are a lot of things to consider and track. Any change to be made must be analysed, and may need to be done to all of your DD's. Any ESU's, watch those. Make sure your different groups can't see each others data, or at the least can't modify each others data.

The local cached DD definitions, at least here, are under the SPEC directory in the pathcode. So you need to set up a pathcode for each DD that you want. You then need a different environment for each group, pointing to their own DD, OCM 's back to the same data, with a lot of careful consideration.

To use just a single environment and single pathcode will be a nightmare. I do not know if you can change the location of the SPEC files, so you would need to map the DD tables for each user seperately, and have some sort of batch to run just before OW on the client to decide which DD is to be used, then rename the files around. Very dangerous, and hard to control.

Just a quick note... I would try to avoid the situation you are getting yourself into at all costs. While it seems a maybe a good way to get everyone onto OW, I think you'll end up so involved in just keeping this thing working you'll never have time to merge the different groups.

Good luck.
Dave

 

[David Robertson]

Hi Bill,
We are running 2 data dictioanries, on B7332 though. The reason here is for change control. Developers do not have access to the production Data Dictionary.

There are a lot of things to consider and track. Any change to be made must be analysed, and may need to be done to all of your DD's. Any ESU's, watch those. Make sure your different groups can't see each others data, or at the least can't modify each others data.

The local cached DD definitions, at least here, are under the SPEC directory in the pathcode. So you need to set up a pathcode for each DD that you want. You then need a different environment for each group, pointing to their own DD, OCM 's back to the same data, with a lot of careful consideration.

To use just a single environment and single pathcode will be a nightmare. I do not know if you can change the location of the SPEC files, so you would need to map the DD tables for each user seperately, and have some sort of batch to run just before OW on the client to decide which DD is to be used, then rename the files around. Very dangerous, and hard to control.

Just a quick note... I would try to avoid the situation you are getting yourself into this at all costs. While it seems a maybe a good way to get everyone onto OW, I think you'll end up so involved in just keeping this thing working you'll never have time to merge the different groups.

Good luck.
Dave

 

[Zoltan_Gyimesi]

Hi Bill,
I was almost sure that you will be get a lot of valuable replies after I have read yesterday your answer to my questions where you identified your problems, situations.

My oppinion is the same as Carl's. The best way to use a single data dictionary with common display decimals (supposly the highest value) and converting QTY field when they move to the common database(s).

If you will choose this way then take care for the other possible differences between the DDs like:

1.) Examine all custom changes (if there is any) on standard (or common) DD Items one by one and make decissions how to handle them.
2.) Include all custom DD Items (if there is any) from all DDs into the common DD.

GOOD LUCK!!!!
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

 

[cbruce]

Bill,

Your request is quite unusual. First of all, realize that DDDICT, DDTEXT, and GLBLTBL are cache TAM files. This means they are essentially temporary and dispensible. Each of these files is a replicated version of DD and table specs in your Central RDB.

To answer your question on where JDE expects to find these files; the answer is in the JDE.INI. In the install section of the INI, there is a subkey in the [INSTALLS] key called "B733=C:\b7". The value of this key is the root of the OneWorld install on the client. There is another subkey under the [SVR] key that is called "SpecPath=spec". Hence in this case, "C:\b7\spec" is the directory where OneWorld writes and reads DDDICT, DDTEXT, and GLBLTBL.

Good luck in whatever you are doing...

 

[wcgodfrey]

List:
Thank you for all of the replies. The
information was quite useful. There was a slight
misunderstanding in that the different companies will
also be in different data bases. They will not share
the same tables.
Based on your responses the separate path code (as I
suspected) would be the cleanest however I am still
arguing to not even do it that way. I am hopeful that
data conversion is coming however that will be a long
process due to coexistence and modified code in world
that will also have to be examined.

Bill Godfrey
XE Coexistant SP14.2
WIN2000 batch/terminal servers
SQL 7 SP 6

_______________________________________________________

 

[David Robertson]

Hi cbruce,

good to know the JDE.INI keys that you mentioned, as I missed SpecPath under svr key.

One point though, the spec directory is normally beneaith the pathcode, so "SpecPath=spec" would result in OW looking in "C:\b7\{pathcode}\spec" for DDDICT etc., not "C:\b7\spec". The only directories off B7 for me are the pathcodes, System, and PrintQueue, definitely no Spec.

Cheers,
David