3.14 Work List

1. 3.14 Work List IOC Core Channel Access

2. Changes to IOC Core • Online add/delete of record instances • Tool to support online add/delete • OS independent layer to support port of IOC Core • Revisit time stamp library • Redundancy • Standard set of statistics available through pseudo-channels • Log writes to database fields • Use priority in scan tasks differently • Frequency-based monitor notification • Port database to the portable server • Improve array handling capabilities • ANSI-fy src/drv/old - drivers Put off until later…….. • Extensible link type definition - 4.0 • Adding record, device, driver support

3. Changes to IOC Core - Online Add/Delete • Changeable links was the first part of the task and was completed in 3.13 • dynamic lockset computation taken from IOC init and done dynamically • Downloading record instances during operation will need to be supported • IOC initialization has to be broken up and called at any time • record initialization must be possible at any time during operation • device initialization and driver initialization must be possible at any time • modifications may need to be made for all device and driver support

4. Changes to IOC Core - tools to support add/delete • Is the request to load new records initiated in the host or the target? • Will we use dbLoadRecords or a network protocol to accomplish this? • How closely integrated will this be with the existing configuration tools? • CAPFAST • GDCT • DCT • Relational and OO databases • ASCII (AWK/PERL/VI)

5. Changes to IOC Core - OS independent layer • Operating system services needing a compatibility layer • SymFindByName • Semaphores • Task Create • Interrupt Services • Timer management • Bus to local addresses • Sockets • Create list of services needed - partial list above • Put the existing ones in the source release control for common use • Document the compatibility layer

6. Changes to IOC Core - Revisit Time Stamp Library • Use UNIX time stamp format • Use the standard UNIX routines for time in place of the existing time stamp library • Verify the year 2000 is no problem • Resolve a newly discovered time stamp issue at TJNAF

7. Changes to IOC Core - Redundancy • All database record types? • State notation language • Which drivers can handle redundant hardware? • How do you mix redundant and non-redundant hardware capability • Recreate it - merge Tate changes • Is this required by anyone?

8. Changes to IOC Core - Statistics from IOC • CPU utilization • Memory utilization • Stack usage • Critical task state of health • running/suspended/etc… • periodicity of scan tasks - do they start on time • number of records processed by each scan task • CPU utilization per task

9. Changes to IOC Core - Logging Database Writes • Uses of write logging • discover unexpected access to a record • use the log as a playback script complete with delay/value information • Logging done at the channel access write level • Ability to log writes to a database enabled on a record by record basis • Integrate the logging into a tool that allows callable access

10. Changes to IOC Core - Task Priorities • Currently scan tasks are given tasks priorities: ioevent high, ioevent med, ioevent low, .1 sec high, .1secmed. .10 sec low, channel acc. • New scheme would allow setting the relative priorities of scan tasks amongst themselves and in relationship with the channel access server. NOTE: channel access buffering is a side affect of having a lower priority than scanning • Several priorities will be reserved above channel access to continue the current relationship between scan tasks and channel access. • Several priorities will be reserved where the channel access client and the scan tasks can be interleaved to provide more suitable environment for closed-loop control over the network and a more controlled degradation mode.

11. Changes to IOC Core - Frequency Based Monitors • Add two notification methods: minimum interval and regular interval • Minimum interval would check only when the record is being processed. Notification is sent when the specified time has expired - this is inline code for record processing. • Regular interval monitors would send values regardless of record processing • a new thread would be needed to service these • synchronizing with record processing is important for time stamp alignment

12. Channel Access Modifications - V3 w/Old Server • 1 dimensional big arrays supported • name caching / alternate name services in the client • coalesce multiple requests for a single channel to one request to the IOC • use a common data object for the gateway and CDEV (merge the functionality of CDEV Data and GDD)

13. Channel Access Modifications - V3 w/Portable Server (3.14 or later) • Put the new server in the IOC • Revise CA buffering so that 32K is not used - it becomes configurable • Control over monitor engine - rate limit, queue length limit, independent deadband, trigger from an alternate channel • JAVA client • Multipriority client connections to the server • Export transaction semantics to the client • Client conversions in the client • Special server library for exporting C variables (no database needed) • Pseudo channels to make server statistics available • Hooks to log all writes (specified in access control) • C++ API for client - review interface to CDEV as part of design • Review portable server doc’s

14. Channel Access Modifications - V4 • Compress the protocol - header, data, alignment • Multi-dimensional array support • User defined containers exported to the client API • User defined application types to the client API • User defined event types to the client API