Sascha,

Re: Want more

Hmmm. I was really thinking about how the APIs are used and work; rather
than missing services. 


Re: FoxAPI and om_set_confirm

AIS (no longer shipped) implemente uread/uwrite as follows:

*       uread is implemented with the OM call getval.
*       uwrite is implemented with the OM call setval.
*       Neither uread and uwrite set the IMPORT flag on their OM call.

        The current version of FoxAPI (V4.2.x) implements uread/uwrite as
follows:

*       uread is implemented with the OM call getval.
*       uwrite is implemented with the OM call set_confirm.
*       Both uread and uwrite set the IMPORT flag on their OM call.

I don't remember how FoxAPI V4.0 and V4.1 implemented uread/uwrite, but I
know they did not use the IMPORT table and I think they used set_confirm.


The automatic use of the IMPORT table in V4.2.x means that uread/uwrite are
what you want.

However, the use of the IMPORT table has an interesting side effect.  The
IMPORT table can be filled.

This means that you might need to enlarge the IMPORT table. An entry is used
in the IMPORT table for each unique compound name or Shared Variable name
(actually for each new Top Level Name).

Use show_params to check how full the IMPORT table is. See Chapter 9 of
B0193ND - System Administration Guide for 50 Series Systems (Solaris 2.x);
it covers the reconfiguration that you might require.

Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 


        -----Original Message-----
        From:   Sascha Wildner [SMTP:[EMAIL PROTECTED]]
        Sent:   Wednesday, January 10, 2001 2:13 AM
        To:     Foxboro DCS Mail List
        Subject:        Re: A request for questions

        Hi,

        although FoxAPI supports change driven reading of objects with
qread() there
        is one thing which is still dearly missing: a proper equivalent to
        om_set_confirm() which allowed to write a single object without
broadcasting
        and without opening a list.  Of course, the first time you had to
broadcast
        but then you could give the call the object's PSAP address.

        FoxAPI (to my knowledge, please correct me if I'm wrong) supports
either
        unbuffered writing (which broadcasts every time) or buffered (data
set
        based) writing which secures the point (undesirable in many cases).

        Next point on the wish list: ICCAPI.  The major hassle in AW70 based
systems
        is that you don't have access to a CP which is not hosted by your
machine.
        This generates a lot of unnecessary work where you have to walk from
one end
        of the plant to another just to get to the machine which hosts the
CP whose
        configuration you want to change.  The only workaround I know of is
to
        enable the telnetd on the host and use telnet/iccdrvr.tsk to do your
changes
        which is not an option for most people.

        Also: On the AW70 platform there are some other things missing such
as an
        equivalent to the Human Interface Calls or C language header files
for the
        Nutcracker Shell (to allow for Nucracker based applications).

        Want more? :)


        Regards,
        Sascha


        ----- Original Message -----
        From: "Johnson, Alex P (Foxboro)" <[EMAIL PROTECTED]>
        To: "Foxboro DCS Mail List" <[EMAIL PROTECTED]>
        Sent: Tuesday, January 09, 2001 10:29 PM
        Subject: RE: A request for questions


        > Darryl brings up a good point.
        >
        > What I should say about the OM API is that it is deprecated, i.e.,
it is
        > supported on Solaris at least, but all new application should be
written
        to
        > FoxAPI instead.
        >
        > You will note that the OM header files do not exist for NT to help
        > "encourage" the shift to FoxAPI.
        >
        >
        >
        > Regards,
        >
        >
        > Alex Johnson
        > 10707 Haddington
        > Houston, TX 77043
        > 713.722.2859 (office)
        > 713.722.2700 (switchboard)
        > 713.932.0222 (fax)
        > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
        >
        >
        > -----Original Message-----
        > From: Darryl Bond [SMTP:[EMAIL PROTECTED]]
        > Sent: Tuesday, January 09, 2001 3:12 PM
        > To: Foxboro DCS Mail List
        > Subject: Re: A request for questions
        >
        > "Johnson, Alex P (Foxboro)" wrote:
        > >
        > > I've been asked to speak at the 'Gulf Coast User's Group'
meeting
        > on Jan
        > > 24th. The topic requested is I/A Series Calls.
        > >
        > > Since this is a topic that is a little hard to cover in a couple
        > of hours, I
        > > was wondering if you folks had questions in this area.
        > >
        > > My thought was that you folks could summit questions to me and I
        > will (try
        > > to) answer them and present the results at the GCUG meeting and
on
        > this
        > > forum.
        > >
        > > The calls that most people seem interested in include:
        > >
        > > IPC - Inter-process communication. These calls can be used to
        > communicate
        > > between programs and to send/receive standard I/A Series
messages,
        > e.g.,
        > > alarms.
        > > OM - Object Manager calls. These are the calls that provide
access
        > to I/A
        > > Series process data at the lowest level.
        > Some examples of using omlists and dqchange would be good. I
        > remember
        > trying to get event driven changes to go some years ago without
        > success.
        > The example in the manual didn't work (If my memory is correct).
        > Polling
        > the list worked Ok though and got me out of the hole at the time.
        >
        >
        > > FoxAPI - A suite of APIs that provide access to process data
        > (legacy AIS
        > > calls and new CDX calls), CSA data, and historical data (legacy
        > API and new
        > > API).
        > > Display Manager commands - These are the commands used in
Display
        > Manager
        > > scripts.
        > >
        > > Any comments? or questions?
        > >
        > > Regards,
        > >
        > > Alex Johnson
        > > 10707 Haddington
        > > Houston, TX 77043
        > > 713.722.2859 (office)
        > > 713.722.2700 (switchboard)
        > > 713.932.0222 (fax)
        > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
        > >
        >
        >
        >
-----------------------------------------------------------------------
        > This list is neither sponsored nor endorsed by the Foxboro
Company.
        > All
        > postings from this list are the work of list subscribers and no
        > warranty
        > is made or implied as to the accuracy of any information
        > disseminated
        > through this medium. By subscribing to this list you agree to hold
        > the
        > list sponsor(s) blameless for any and all mishaps which might
occur
        > due to
        > your application of information received from this mailing list.
        >
        > To be removed from this list, send mail to
        > [EMAIL PROTECTED]
        > with "unsubscribe foxboro" in the Subject. Or, send any mail to
        > [EMAIL PROTECTED]
        >
        >
-----------------------------------------------------------------------
        > This list is neither sponsored nor endorsed by the Foxboro
Company. All
        > postings from this list are the work of list subscribers and no
warranty
        > is made or implied as to the accuracy of any information
disseminated
        > through this medium. By subscribing to this list you agree to hold
the
        > list sponsor(s) blameless for any and all mishaps which might
occur due to
        > your application of information received from this mailing list.
        >
        > To be removed from this list, send mail to
        > [EMAIL PROTECTED]
        > with "unsubscribe foxboro" in the Subject. Or, send any mail to
        > [EMAIL PROTECTED]
        >


        
-----------------------------------------------------------------------
        This list is neither sponsored nor endorsed by the Foxboro Company.
All 
        postings from this list are the work of list subscribers and no
warranty 
        is made or implied as to the accuracy of any information
disseminated 
        through this medium. By subscribing to this list you agree to hold
the 
        list sponsor(s) blameless for any and all mishaps which might occur
due to 
        your application of information received from this mailing list.

        To be removed from this list, send mail to 
        [EMAIL PROTECTED] 
        with "unsubscribe foxboro" in the Subject. Or, send any mail to
        [EMAIL PROTECTED]

-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Reply via email to