Re: It appears that it's possible for (at least) FoxAPI to obtain the
"owners" of the data it wants one of 2 ways. One way is, as you said
broadcasting the request. The second seems to eb looking in the
configuration database. Is this correct?
FoxAPI can use CSA to obtain the station that holds a given compound. CSA is
the database that is used to maintain uniqueness of compound and block
names.
This behavior is the default. However, it can make opening a list quite slow
since a large number of CSA queries can be generated.
The FoxAPI configuration attribute nocsaonread controls this.
If nocsaonread is set, an OM broadcast is used.
From the FoxAPI Information Bulletin available from TAC:
nocsaonread
0 = The technique used to connect to objects for read-only
is different from that used by the AIS package. Specifically, CSA is used
to locate the station in which the object resides. The effect is a slowing
of the connection process, a decrease in network activity after the
connections have been made and the establishment of the requirement that
CSA be accessible.
1 = The technique used to connect to objects for read-only
is similar to that used by the AIS package. Specifically, CSA is not used
to locate the station in which the object resides. The effect is a speedup
of the connection process, an increase in network activity after the
connections have been made and the absence of the requirement that CSA be
accessible. The 'nocsaonread' flag should be specified for read-only lists,
the 'use_omopen' flag is for read/write lists
The default is 0.
Regards,
Alex Johnson
Invensys
10707 Haddington
Houston, TX 77063
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
For the latest information on ArchestrA, go to
www.invensys.com/Archestra.html
<http://www.invensys.com/divisions/Archestra.html> .
-----Original Message-----
From: stan [SMTP:stanb@xxxxxxxx]
Sent: Thursday, December 12, 2002 7:14 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FOXAPI Configuration for Foxhistory
Ver 2.0
On Wed, Dec 11, 2002 at 04:38:45PM -0500, Johnson, Alex (Foxboro)
wrote:
>
> Your primary assumption on the operation of the OM is wrong.
>
--- Excelent desciption of data flow sniped.
>
> Does this help?
Indeed it does. The key peices of the puzzle that I was missing are:
1. The idea that a data consumer generates a list for each data
source.
2. The fact that ultimate data flow is point to point, and not
broadcast.
I've been reading the FoxAPI docs, and with the information you have
given
me, plus the information I gleamed there. I have a followup
question.
It appears that it's possible for (at least) FoxAPI to obatian the
"owners"
of the data it wants one of 2 ways. One way is, as you said
broadcasting
the request. The second seems to eb looking in the configuration
database.
Is this correct?
--
"They that would give up essential liberty for temporary safety
deserve
neither liberty nor safety."
-- Benjamin Franklin
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys
Process
Systems (formerly The Foxboro Company). Use the info you obtain here
at
your own risks. Read
http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list:
http://www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave