Explanation of Distributed and Central Objects

timallen

timallen

Well Known Member
I just explained what OneWorld objects are to one of our techs, and I wanted to confirm that my explanation was accurate. During the explanation I had some doubts as well. Here is what I told him:

** What kinds of objects are there? **
There are two kinds of objects: 1) Distributed Objects in the form of Table Access Management (TAM) file specifications and DLLs, and 2) Central Objects. Central Objects are stored in the database on the Data Server (which in our case is also the Enterprise Server, but which can be a separate server).

** Where are objects stored? **
Distributed and Central Objects are found in four places in the Configurable Network Computing (CNC) Arquitecture: 1) The Path Code directories of Fat Clients and Java or Terminal Servers, 2) The Path Codes of the Enterprise Server, 3) The Path Codes of the Deployment Server, and 4) The Central Objects tables in the database on the Data Server.

** How are objects used? **
1) When a fat or thin Client works in OneWorld, he or she uses the Distributed Objects (TAMs and DLLs) stored in the Path Code (A directory named PY7333 for example) on his or her PC or on the Java or Terminal Server. OneWorld *never* runs directly off of Central Objects, only off of Distributed Objects.

2) When a Universal Batch Engine (UBE) report is run on the Enterprise Server, the Enterprise Server does its work using the TAM files and DLLs stored in the Path Code for the Environment where the UBE is being executed. Again, it is using these Distributed Objects to do its work, not the Central Objects in the Database (This is a confusing point, since the Data Server and the Enterprise Server often are the same machine).

If the Enterprise Server does not have specs for a UBE and a client with those specs runs the UBE on the Enterprise Server, those specs are copied to the Enterprise Server from the client before launching the UBE.

3) The TAM file specifications and DLLs in the Path Code directories on the Deployment Server only exist to let the OneWorld Client work on the Deployment Server, in exactly the same way the a normal workstation works. (IS THIS TRUE?)

4) The Central Objects in the Data Server database exist for two purposes:
a) If a workstation tries to execute a program and it doesn't have the specs for that program, it requests them from Central Objects, and these specs are incorporated into the workstations' TAM files on the fly, Just In Time. (NOTE: I have a doubt here-- who packages these specifications: the workstation, the data server, the Deployment server? Also, what about the DLLs necessary to make the program run-- how do those get to the machine?)
b) When a package is built, the building machine requests the specifications from Central Objects and translates those specs into TAM files and DLLs. These TAM files and DLLs are stored in the Deployment Server in the form of the package, and when a client receives the package, the Specs and DLLs are copied directly from the Deployment Server. (POINT TO CONFIRM: The C and NER source for creating DLLs is extracted from Central Objects, right?)

One upshot of this last point is that the Specs on the building machine are not used to build the package-- the specs are extracted from Central Objects and the Package Build is done with these. (IS THIS RIGHT?)

** Existential Doubts **
One major doubt I have here is how DLLs on client machines get updated. If I have a fat client with a partial package, and the fat client has never executed a particular UBE which uses a business function that the client doesn't have in his or her DLLs, I'm guessing that the UBE will not run. I think this because I can't see how the DLLs which exist in the path code of the workstation could get updated on the fly (this would imply recompilation of the DLL, and I know that isn't happening during a JITI). However, usually JITI works-- does this mean that the partial package client *does* have a full complement of business functions in the DLLs even though it doesn't have all the specs?

Sorry to ramble on here-- I think this subject is very central to understanding how the CNC works, so I want to get this completely right. Any observations or clarifications would be greatly appreciated. Thanks in advance.
 
Hi timallen,
That was a nice piece of information. The concept what you have discussed is simply great atleast for buddy CNC guys (like me). Well here's what i have to add or say
1) Answer to ponit no 3 : that true. the deployement server is exactly the same as any workstation when it comes to TAM files, but yes the full package folder contains the complete converted TAM files (spec)
2) In point no 4b i guess you are mistaken. below is what i did just two days back. I have successfully replicated one path code from a different setup totaly. What i did was got the export of PY7333 CRPCTL and OL records for PY and imported in my database and replaced my .c and .h files and build a full a full package. Successfull. thats what the story is.

Hope this is useful
 
Tim

I think you have a pretty good understanding of distributed objects (also called run time or replicated objects) and central objects.

The central objects are the specs in you RDB and the C components. The specs are stored in your database on your enterprise server in tables F987* (plus a few more). The C components are stored on your deployment server in the respective pathcodes.

The distributed objects are created from the central objects when you build a package. The TAMs come from the central object specs and the DLL's come from the C components.

Patty
 
replicated and central object

dear sully1,
i come across your post and its really a helpful post.
i just want to confirm few thing.
1)central objects are spec in rdb format sitting in database in enterprise server plus c component in deployment server in all the pathcodes. may i know what should i call the c component in local fat client?
2)u said tam from central object spec and dll from c component. may i know the c is in deployment, right? again, what happen to local client c component in source folder, include folder, obj folder?
3) you mean local client bin32(dll) build from c, right? the c from local or deployment.
4) what happen to bin32 folder in deployment server?

thanks alot
ben
 
Good questions Tim. Let me try some answers:

2) a batch server does not do JITI for UBE specs. You need to build a package. When you execute a UBE the VERSION specs get send to the server in form of instant mini packages. Look in your servers DEFAULT pathcode´s spec directory. You wil find lots of directories with user´s names. You may find in some of them leftovers from these version spec packages in the form of .pak files.

3) not really true. The specs that are in \\DS\B7333\pathcode\spec are aquivalent to an original partial package. Take a look, the file sizes are really small. These specs never get updated. If you try to deploy a package to the deployment server itself (don´t try it!) you will no be able to. You can only copy the specs here manually from the package. The DLLs in \\DS\B7333\pathcode\bin32, however, do get updates with every full package you build. So normally, what you have in the pathcodes on the DS is NOT the same as what you have on workstations.
In my opinion one should log on to the DS only to the Planner and Dep environments.

4a) C-objects (DLLs) do not get jitied down to the WS. You need to build and deploy a package. When JITI happens form a WS, it retrieves the spec information directly from the database by doing simple "selects" on the Central Objects´ tables. It stores the information in the local spec files.

4b) the central objects location for C-stuff (.c, .h files) is on the deployment server, like \\DS\b7333\pd7333\source . The C-code is taken from here, copied to the package and the compiled. NERs are stored in form of specs in Central Objects (database, F98741, etc). They are converted during package build time into C-source files and the compiled.
Yes, all other specs are extracted from the Central Objects and converted into TAM format. The package build process does a "select * from pd7333.f987.. " on all the Central Objects tables, one by one, and stores the result in TAM files.
The specs in the pathcode directories on the DS are not used at all during package build (unless you are logged in to that pathcode).

Partial packages do have a full set of DLLs. DLLs do not get updated via JITI. Note that when you do an update package with only one BSFN you will always receive (deploy) the entire respective DLL.

My two centavos, Gerd
 
Good questions Tim. Let me try some answers:

2) a batch server does not do JITI for UBE specs. You need to build a package. When you execute a UBE the VERSION specs get send to the server in form of instant mini packages. Look in your servers DEFAULT pathcode´s spec directory. You wil find lots of directories with user´s names. You may find in some of them leftovers from these version spec packages in the form of .pak files.

3) not really true. The specs that are in \\DS\B7333\pathcode\spec are aquivalent to an original partial package. Take a look, the file sizes are really small. These specs never get updated. If you try to deploy a package to the deployment server itself (don´t try it!) you will no be able to. You can only copy the specs here manually from the package. The DLLs in \\DS\B7333\pathcode\bin32, however, do get updates with every full package you build. So normally, what you have in the pathcodes on the DS is NOT the same as what you have on workstations.
In my opinion one should log on to the DS only to the Planner and Dep environments.

4a) C-objects (DLLs) do not get jitied down to the WS. You need to build and deploy a package. When JITI happens form a WS, it retrieves the spec information directly from the database by doing simple "selects" on the Central Objects´ tables. It stores the information in the local spec files.

4b) the central objects location for C-stuff (.c, .h files) is on the deployment server, like \\DS\b7333\pd7333\source . The C-code is taken from here, copied to the package and the compiled. NERs are stored in form of specs in Central Objects (database, F98741, etc). They are converted during package build time into C-source files and the compiled.
Yes, all other specs are extracted from the Central Objects and converted into TAM format. The package build process does a "select * from pd7333.f987.. " on all the Central Objects tables, one by one, and stores the result in TAM files.
The specs in the pathcode directories on the DS are not used at all during package build (unless you are logged in to that pathcode).

Partial packages do have a full set of DLLs. DLLs do not get updated via JITI. Note that when you do an update package with only one BSFN you will always receive (deploy) the entire respective DLL.

My two centavos, Gerd

Excellent post to understand the basics of CNC
 
Back
Top