|1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020||Index||1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020|
|<== Date ==>||<== Thread ==>|
|From:||Marty Kraimer <email@example.com>|
|Date:||Thu, 11 Jan 2007 06:10:13 -0500|
A new release of the javaIOC is now available. See
With the major exception of remote access, the basic functionality required for a working javaIOC is now implemented. Because remote access and no support, except for testing, is implemented the javaIOC is not ready for real applications.
The following is a brief summary of what is implemented.
A javaIOC is a Process Variable (PV) database, which is a "smart" database, i.e. a database consisting of records that can be processed. Each record instance has support code the implements record processing.
A PV record is a set of structured data. Each record has a recordType, which is just a top level structure. A structure is a set of fields that can have any of the following types:
Each field can optionaly have associated support, which is identified by a supportName.
A simple example of how these data types with associated support can be used is linkArray. A linkArray is an array of links with associated support. Any recordType can have an arrayLink field. When a record instances is defined the array of links can be created. An output record can have the array be a combination of process and output links. Thus any output record can also have builtin the capability of the V3 fanout and dfanout records.
Record processing is implemented. Each record instance can have only a single process requestor, i.e. code must register to be the process requestor.
Records can be periodically or event scanned. For periodic scanning the rate and priority is specified. The rate can be any value desired, with the restriction that the fastest rate is determined by the underlying java/os implementation. For event scanning, each event is identified by an eventName, which allows event scanning to replace the V3 event and I/O Intr scanning.
A listener can be attached to an field of a record. If the field is a structure than the listener is notified whenever any field within the structure is modified. In particular if the listener attaches to the record itself then the listener is notofied when any filed in the record is modified.
Local channel access is implemented. The CA client can issue process, get, put, and monitor requests. The client can modify the supportName associated with any field and also the configuration structure of a link field. When this is done the old support is automatically stopped and new support attached. Monitoring is implemented via ChannelData, which holds modified data, and ChannelDataQueue, which is a queue of ChannelDatas.
Support is implemented for process, input, output, and monitor links. It will work for both local and remote channel access but for now only local access is available.