J. Kissel, J. Driggers, S. Dwyer

I've already mentioned this a few months ago in LHO aLOG 27517, but I'll repeat these requests again, because we've thought a little bit more on how we'd like them implemented.

Thing we need to make SDF more maintainable:
1) Remove the distinction between SAFE and DOWN for SUS and SEI. Because SEI and SUS come up with the watchdog tripped, and the start up state for both systems guardian has the masterswitch off, there's no difference between these states. 
2) A rapid way to assess and change a group of front-end model's SDF reference files. I.e. we should be able to switch between OBSERVE and DOWN quickly instead of having the 4 screen, 15 clicks per front-end process it is now.
3) A easy, built in way to find out what channels of a given front-end are controlled by all guardians, such that we can un-monitor them.
4) A much easier way to reconcile non-initialized and not-found channels than the still-confusing SDF Save and SDF Restore screens.

Regarding 
(1) -- This has been completed. The SUS that *have* down.snaps all now have their safe.snaps soft-linked to their down.snaps.
(2) -- we now have a rapid way to assess at which reference file a front end is looking, because I've modified the overview. However, we still need a rapid way to change them all. Sheila and Jenne have programmed the enforcement of those front end models that *have* down.snaps to reference them in the DOWN state of the ISC_LOCK guardian, using shell scripts like
/opt/rtcds/userapps/release/isc/h1/guardian/
All_SDF_down.sh
All_SDF_observe.sh

These are rapid ways to change them all, once created, but because the SDF system identifies models by DCUID number instead of model name, it's arduous to create and maintain such a script.

(3) -- We still don't have this. Jamie and Jenne (and several others, I'm sure) have already discussed that parsing guardian code to find what channels it touches is intractable. 
As such, the new idea is that we have some script that 
     (a) takes two burt snapshots of an entire front-end model EPICs settings database
     (b) compares them -- any channel that has a change between those two snap files gets flagged for not-monitoring, all others get flagged for monitoring.
     (c) Those flags are absorbed into a *single* SDF file (with none on this unmaintainable several-file nonsense), and then
     (d) all monitored settings values are accepted.
We imagine this script to be run once a week, or so.

(4) -- We can now initialize a value by just flipping over to the "CHANS NOT INIT" menu, and accepting them. However, by default, they go into the list of channels *not* monitored. In order to initialize them as monitored, one has to remember to select *MON* (all) and then confirm. Until we get (3) addressed, the functionality should be that hitting *accept* for a non-initialized channel should automatically monitor it. For CHANS NOT FOUND We still must do the multi-screen, confusing save and reload.

This entry is posted as a request to the CDS software team to help us out. We don't think we can accomplish the solutions to (3) or (4), and we're mildly unhappy with the work-arounds we've done for (1) and (2). Thanks ahead of time.