SLD Unix Conversion

Goals

1. Complete removal of any dependence on SLACVM. This includes
   • Removal of dependence on VM as a code-distribution hub, by reimplementation of existing code-distribution hub or replacement of code distribution system by another system (See below).
   • Porting of all SLD servers on VM including:
     • The SLD production and MC log analyser servers
     • All servers dealing with tape handling/Oracle interface
     • Replacement of the SLACVM STGSERVE server
     • Porting of WWW interfaces to SLDNEWS/SLD Oracle/SLDNAMES
   • Replacement of any other functionality which currently only resides on VM (Oracle maintainence tools?)
2. Setting up SLD IDA based analysis facility on Unix. This should include:
   • Jazelle,
   • IDA,
   • SLD event display,
   • Midas GUI interface,
   • access to datasets on disk and tape (c.f. current OPENTAPE capabilities, including staging and ability to read and write multi-volume datasets),
   • ability to dynamically load user code (c.f. current VMS capability)
3. Setting up complete SLD reconstruction/MC/analysis environment on Unix. This includes:
   • Access to complete SLD software system, including development and production areas (or equivalent)
   • An SLD shell (c.f. SANE/CETI) or (preferably) a dynamic loading system (c.f VMS IDA).
   • Simple user interface for submitting and monitoring batch jobs.
   • Complete set of utility programs, e.g. PREPMORT, GETFREE, etc.
   • The work of porting the code should include thorough testing of the MC and reconstruction system to verify that they give results consistent with the existing VM/VMS based system.
4. Implementation of complete SLD farm system, including monitoring and performance tools (c.f. current VMS MC farm)

• Improved code management, including ability to archive, use and restore complete frozen copies of SLD production code.
• Improved interactive analysis environment, including very high speed IO (possibly through the use of Unix hardware designed for high throughput applications), improved GUI interface, etc.
• Random access to (RAW) data.
• Completion of some currently incomplete features of SLD software, e.g.Template Libraries

Major parts of the conversion effort should be planned and discussed within the SLD software group in advance of implementation.

An incomprehensible MacProject accompanies this note.

Porting the SLD code distribution system

The current system provides the following capabilities

• Code distribution between VM and VMS platforms at SLAC and elsewhere. Note that once the system is installed it operates without any manual intervention (in principle) and provides real time updates at all remote sites.
• New files can be installed by authorized users at any site. Any installed file is automatically transferred to all other sites.
• The system handles code, news, help/documentation, binary (Jazelle) data and calibration constants.
• The system segments SLD into "sections", with different collaborators authorized to update different sections.
• The system allows distributes both "production" and "development" code and allows users at remote sites to choose which sections of "development" code they wish to use at any instant.
• The system currently uses both BITNET and DECNET

The VM portions of the current system certainly need to be replaced. Rather than just reimplementing the current functionality elsewhere this may be a good opportunity to evaluate how to modify/update the system. If so the update must carefully address the following migration issues:

• A system (possibly temporary) must be put in place ASAP which will provide some form of code distribution between VMS and Unix. It is very hard to port code to the new system if changes to the existing code render the ported code obsolete before the port is completed. Similarly Unix and VM/VMS versions of the code should not be allowed to diverge since this will produce a maintainence nightmare.
• The current system must remain in operation until a fully functional and tested system is ready to replace it. This will probably require old and new systems to co-exist at least temporarily (maybe permanently?)
• The updated system must continue to function with VMS systems both at SLAC and at remote sites.
• The need to change the way the code appears on VMS and the way code is updated should be minimized. Where changes are necessary they should bring improved functionality to users.