FE Required Services

• Client Services Requirements (to be supported by a new FE infrastructure)
• RETDAT
• RETDAT on T-clock
• Guaranteed readable
• Better response time ~20ms?
• SETDAT
• Guaranteed settable
• snapshot
• New format
• Arm device must be local need an error code for when arm device is not local
• FTP
• New format
• alarms
• Multiple alarms (state-based)
• alarm scan on event
• alarm scan on enabled/disabled based on state variables
• Do not have to talk to front-ender
• T-clock, MDAT, Beam sync
• All events and frames
• Ability to attach callbacks to event arrivial
• Subject to signal cable availability
• DABBEL templates
• ACNET AUX yes, but which typecodes?
• Support all UDP trunks
• States functionality
• Persistence functionality (state-based?) - either WRITER/SYBSET or something better
• Support for DB news
• FE-to-FE communication
• Client logging?
• Run II Immediate Needs (which can not wait for a new FE infrastructure, and therefore must be satisfied with the existing infrastructure)
• Improve RETDAT response time(DAE - Cahill)
• Give FE programmer more of SSDN(Camac replacement - Neswold)
• Support "smart modules" which do their own alarm scan(Camac replacement - Neswold)
• Support "smart modules" which do their own data collection(RETDAT) on event(Camac replacement - Neswold)
• States functionality, i.e., ability to request and receive state device changes ? (Collimators - Kramper)
• Multi-threaded RETDAT ? (Camac replacement - Neswold)
• What else should be on this list?
• Milestones for the FE infrastructure group
1. Transfer WRS technical contact from Rich Neswold to Carl Schumann
2. Support vxworks 5.3 development on nova.fnal.gov.  This includes preparing "official/standard" infinite retry bootroms and kernels.  Keepers are responsible for the deployment of the official bootroms and kernels on their front-ends.
3. Support vxworks 5.4 development on nova.fnal.gov.  Again this includes preparing bootroms and kernels.  The port of individual FEs to 5.4 are the keepers' responsibility.
4. Add support for Run II Immediate Needs to existing FE infrastructure
5. Evaluate and install vxVMI, if acceptable, to provide memory protection for OS and constant memory segments.   Build standard kernels with vxVMI.  Existing code that modifies strings may need fixed.
6. Evaluate compiled javas and install a compiled java, if acceptable.  This compiled java should be part of a tool set that supports C and C++ also, along with a debugger that can handle source level debugging of all three languages.  Compiler needs to handle both java source and bytecodes.   Bytecode compilation is need for Sybase's jConnect.   It would realy be great if the java enviroment could support some interuptation so that for example PDB's which did not exist when the FE's code was compiled could be loaded dynamically.  Loading code dynamicaly might not be supported by some FE keepers.
7. Develop a new front-end infrastructure which supports all of the Client Services listed above.  Ideally this new infrastructure would be written in Java and reuse as much existing Java code as possible.   To support this reuse the existing Java code may need extended and at the very least documented.   This may be pie-in-the-sky but it woud be great if the new infrastructure would allow the FE programmer callbacks to be written in C, C++, or Java.

Security, Privacy, Legal