Understanding the Data Dictionary

Hi Everybody,
We've had some of our business consultants complain that the changes they have made to the data dictionary don't always show up in their Universal Batch Engine (UBE) reports.

For example, the consultant creates the R55xxx report which has a field with a single decimal. They change the Data Dictionary item for that field to have two decimals. But the UBE still shows one decimal.

I'd like to understand the theory on this. This is what I understand up to now:
1) There is a data source for the data dictionary ("Data Dictionary B7333") which contains the F92xx tables. The Knowledge Garden document "Major OneWorld Tech Tables" says that these same tables also exist in OneWorld Local, but I don't find them in OneWorld Local (maybe this should happen if we replicate the data dictionary to the client?)
2) The Enterprise server has the Table Access Management (TAM) files ddclmn, dddict, ddpkeyd, ddpkeyh, ddtabl, and ddtext for each path code.
3) Each client has the same TAM files for each path code.

Okay, here are my questions:
1) What information is stored in the data source Data Dictionary B7333?
2) Is this the same information that gets stored in the dd???? TAM files, or something else? Extra points for a breakout of what each TAM is doing.
3) Do I have to make a package to distribute data dictionary changes? If so, since data dictionary items can't be added directly to a package, what should I add?
4) Any theories on why the data dictionary changes aren't appearing for our business consultants (I don't rule out PEBCAK).

Thanks in advance.

Tim...

Your statements are correct...and to replicate the DD changes stored in
the DD tables, three things...you run R92TAM to recreate the DD*.* files
(I generally do this on a fat client). These files then can be copied to
clients and a W2K based ES. Or you can build a full package and deploy
it everywhere. Or for client purposes you can delete the DDDICT and
DDTEXT files and they should JITI if the environment is set up to do so.

Of course, I'm assuming that you are NOT using DD replication...I know I
haven't seen it used since about 2000 or so.

Regards,

Jim
On Fri, 16 May 2003 02:49:46 -0700 (PDT) timallen <[email protected]>
writes:
We've had some of our business consultants complain

For example,

I'd
1) There is a data source for the data dictionary ("Data
2) The Enterprise server has the Table
3) Each client has the!

Okay, here are my
1) What information is stored in the data source Data
2) Is this the same information that gets stored
3) Do I have to make a package
4)

Thanks in

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!

This may answer 3) and 4):

When me make a change to the DD we had to blow away the local spec files on the fat client to see the changes since they are pulled down the the client. We are running partial clients in a Jiti enviroment. This may be why they are not seeing the changes. I just send them a batch file to run. I haven't needed this in awhile so I'm not sure why I have a global tables delete in there also. There may be other better methods (anyone?):

rem Program: OWUpdateDD.bat
rem Date : 5/14/2002
rem Purpose: Delete OW Global tables and Dictionary files so they get reloaded
cls
@echo off
echo.
echo Removing Global Tables and Data Dictionary Files
c:
cd \
Cd b7\PY7333\Spec
del glbltbl.ddb
del glbltbl.xdb
del dddict.ddb
del dddict.xdb
del ddtext.ddb
del ddtext.xdb
echo Finished Prototype (PY7333)
cd \
Cd b7\PD7333\Spec
del glbltbl.ddb
del glbltbl.xdb
del dddict.ddb
del dddict.xdb
del ddtext.ddb
del ddtext.xdb
echo Finished Production (PD7333)
echo.
echo Please ignore the following messages:
echo.
echo "System could not find the path specified..."
echo "Could not find..."
echo.
echo This means the files are already deleted or do not exist.
echo.
echo OneWorld update has completed.
echo.
pause

-Grant

An aside: there are special programs and proceedures used to update data decimals. Look on the knowledge garden for "Decimals in Distribution" and you will find some white papers that explain everything

Tim,
the DD* TAM files hold the same information as the F92* database tables, but
in different format. When you build a full package some DD* TAM files are
not build. DD information for them are always JITIed down, to ddtext, dddict
and glbltbl files as you need them on a fat client as well as on the server.
So, lets say a DD-item is already on a client (in the above files) and then
you changed it. The client will not be aware of this change and not JITI
down the new version on this ITEM. The easy way is to simply delete these
three (pairs of) files and you will see JITI next time you log on. You can
delete these files on the ES as well (make sure the services are down).
You cannot build packages for DD items. However, a new full package will
zero out these files und you get all changed DD items down to the WS.
Problem with full server builds is that it does not replace the DDdict, etc
files, it maintains the old ones. It would be wise to delete these files
from your server's pathcode when you deploy a full package.

There are ways to build full dddict, ddtext and glbltbl files running R92TAM
and R98CRTGL, but that would be necessary for JAS and WTS only.

F92 files in One World Local? Only on the deployment server.
There is a description on how to set up DD replication so you will always
get changes of DD items as they occur. Don't even try to implement it. It's
very tricky, even for JEDI Masters, and I would guess that it doesn't even
work.


Now *I* have a question: what's PEBCAK for non EFLs (English First
Language)?

Hope this answers your questions, Gerd

One note to add. Run R92TAM and R98CRTGL before building a full package. Just after you launch the package, copy dddict*.*, ddtext*.* and glbtbl*.* to the Spec directory of the package build. When the compress occurs, you have full DD and Global Tables on the client installs. After the build, edit the package INF and tell it not to replace the Global Tables and DD (one line, but I don't remember the syntax).

Now, PEBCAK, it means Problem Exists Between Chair and Keyboard... the end user is the problem, not the system.