gerd_renz3
VIP Member
Tim, pretty long questions. Hard to read through all of it. Here are some
coments:
3) Half true. During package build the pathcode\bin32 directory is updated,
the pathcode\spec directory never gets updated, unless you do a copy-paste
by hand (you cannot deploy a package to the DS itself). Take a closer look
at the pathcode\spec files. They are the size similar to a partial package.
Logging into PD7333 on the DS will probably not behave exactly the same as
when logging into PD from a WS.
4b) NERs are stored in the relational database. During package build
NER-spec-code is translated into C-code and Nxxxxxx.c files are being
created and compiled later on. The Nxxxxxx.c files are stored in
package\source and copied to \\DS\b7333\pathcode\source at the end of the
build process.
When you build a package you EXECUTE the specs from the spec directory in
the pathcode you are logged in to. The specs CREATED in the package are
taken from your relational database (select * from pd7333.f98741 ) and put
into TAM format.
DLLs are always build completely for partial or full packages. DLLs or
single BSFNs are NOT being JITIed to the WS at any time. I think it's
technically impossible.
Hope this helped, Gerd
-----Mensagem original-----
De: [email protected] [mailto
[email protected]]Em nome
de timallen
Enviada em: quinta-feira, 27 de março de 2003 08:13
Para: [email protected]
Assunto: Explanation of Distributed and Central Objects
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
co!
pied 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 ful!
l 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.
--
Tim Allen, (JDE Jedi Master) Barcelona
B7332, ES RS6000 AIX, DS W2K, Oracle 8.1.7
www.javajunkies.org
--------------------------
To view this thread, go to:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=52185
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World® / XE mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com
JDEList is not affiliated with JDEdwards®
+ - - - - - - - - - - - - - - - - - - - - - - - -+
********Confidencialidade do Correio do Eletrônico***************
Informações confidenciais podem estar contidas nesta mensagem. Se você não
se encontra na lista de destinatários ou não é o remetente da mesma, você
não deve copiar ou enviar esta mensagem para ninguém. Neste caso, você deve
destruir e notificar o remetente da mesma. A empresa considera opiniões,
conclusões e outras informações que não se relacionam com o negócio oficial
da corporação de responsabilidade do usuário do serviço.
********Confidencialidade do Correio do Eletrônico***************
Informações confidenciais podem estar contidas nesta mensagem. Se você não
se encontra na lista de destinatários ou não é o remetente da mesma, você
não deve copiar ou enviar esta mensagem para ninguém. Neste caso, você deve
destruir e notificar o remetente da mesma. A empresa considera opiniões,
conclusões e outras informações que não se relacionam com o negócio oficial
da corporação de responsabilidade do usuário do serviço.
coments:
3) Half true. During package build the pathcode\bin32 directory is updated,
the pathcode\spec directory never gets updated, unless you do a copy-paste
by hand (you cannot deploy a package to the DS itself). Take a closer look
at the pathcode\spec files. They are the size similar to a partial package.
Logging into PD7333 on the DS will probably not behave exactly the same as
when logging into PD from a WS.
4b) NERs are stored in the relational database. During package build
NER-spec-code is translated into C-code and Nxxxxxx.c files are being
created and compiled later on. The Nxxxxxx.c files are stored in
package\source and copied to \\DS\b7333\pathcode\source at the end of the
build process.
When you build a package you EXECUTE the specs from the spec directory in
the pathcode you are logged in to. The specs CREATED in the package are
taken from your relational database (select * from pd7333.f98741 ) and put
into TAM format.
DLLs are always build completely for partial or full packages. DLLs or
single BSFNs are NOT being JITIed to the WS at any time. I think it's
technically impossible.
Hope this helped, Gerd
-----Mensagem original-----
De: [email protected] [mailto
[email protected]]Em nomede timallen
Enviada em: quinta-feira, 27 de março de 2003 08:13
Para: [email protected]
Assunto: Explanation of Distributed and Central Objects
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
co!
pied 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 ful!
l 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.
--
Tim Allen, (JDE Jedi Master) Barcelona
B7332, ES RS6000 AIX, DS W2K, Oracle 8.1.7
www.javajunkies.org
--------------------------
To view this thread, go to:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=52185
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World® / XE mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com
JDEList is not affiliated with JDEdwards®
+ - - - - - - - - - - - - - - - - - - - - - - - -+
********Confidencialidade do Correio do Eletrônico***************
Informações confidenciais podem estar contidas nesta mensagem. Se você não
se encontra na lista de destinatários ou não é o remetente da mesma, você
não deve copiar ou enviar esta mensagem para ninguém. Neste caso, você deve
destruir e notificar o remetente da mesma. A empresa considera opiniões,
conclusões e outras informações que não se relacionam com o negócio oficial
da corporação de responsabilidade do usuário do serviço.
********Confidencialidade do Correio do Eletrônico***************
Informações confidenciais podem estar contidas nesta mensagem. Se você não
se encontra na lista de destinatários ou não é o remetente da mesma, você
não deve copiar ou enviar esta mensagem para ninguém. Neste caso, você deve
destruir e notificar o remetente da mesma. A empresa considera opiniões,
conclusões e outras informações que não se relacionam com o negócio oficial
da corporação de responsabilidade do usuário do serviço.
