FOR MOST RECENT/VALID INFORMATION, CONSULT HELP ON FEEDBACK PAGE OR
CONTACT LINDA HENDRICKSON (x3913)




From ljh@SLAC.Stanford.EDU Wed May 12 15:34:08 1999
Date: Wed, 12 May 1999 12:18:58 -0700 (PDT)
From: "Linda Hendrickson (650)926-3913" 
To: YOCKY@SLAC.Stanford.EDU
Subject: this invalidates your warranty

While looking for the PEPII run schedule on the WWW,
I happened upon the operations web page, and found an
article of advice on setting up feedbacks,
"How to combat FBCK MEASMISS in weird machine modes".

This hereby invalidates any warranty on feedbacks.
It contains poor advice (which I notice reflects current
practices), erroneous information, and a copy of my documentation
which is obsolete.  The unidentified author admits they don't
understand the help in CREATE BPM BUFRING (where I keep
frequently-updated documentation),  but advises blindly editing
beamcodes and feedbacks without any warning
of possible fallout, or any advice to communicate or document changes.
I'm sure everyone is just trying to be productive, but you must've
noticed the time-bombs being left around, at least this week.

Here are 3 examples:

1. Editing BPMD beamcodes without consultation can cause
unexpected fallout.  For example the case where someone helpfully
edited an inj_e- BPMD beamcode intended for LC00.  This resulted
in all BPM measurements for both users and feedback being broken
for several days in LI00,  even on other BPM definitions.
There was an immediate cater, which took days of Tony Gromme's
time to sort out.  This was a time-bomb, which didn't break LI00
acquisitions until after the micro was IPLd, days after the dbedit.

2. Restoring feedback mask configs can break feedbacks in
unintended locations.  This is another time-bomb situation where
feedbacks don't necessarily break until much later when a micro
is IPLd.  For example this week a mask config was restored, probably
to address the DR13 problem, but nobody reinitialized the feedbacks
in DR11 and the restored masks would have broken those feedbacks
as soon as DR11 was IPLd.

3. Editing FBCK BPMDs can break the other feedbacks in the same
micro if you're not careful.  You noticed how that happened in DR13
over the weekend.

Feedback masks, BPMDs, beamcodes, and even feedback
HSTA and HDSC bits are a complicated configuration which often
must go together.  To try to keep a handle on it,
I've made a serious effort to keep the help on CREATE BPM BUFRING
updated, but I cannot do this if the OPS procedures do not
include communicating or documenting changes.

This week, I've added more information on possible conflicts to the help.
Failure to consider these issues can lead to the types of problems which
I mentioned.

Here's some advice:

1. Consider making a request for support in advance, and communicating
the plans for feedbacks and beamcodes.  (We are usually
cooperative, except when people stomp all over the feedback
databases without documenting or communicating, and then criticize our
documentation.)

2. Read and understand the help in CREATE BPM BUFRING.  If it is
too complicated, or you don't have time to comprehend it,
you have no business making changes.  Feel free to ask for information
or provide suggestions for help content.

3. Test any changes, and if they don't work, back them out and ask
for support.  Check out all feedbacks on the same micros if you
change a feedback BPMD or masks;  check out all feedbacks using a BPMD if
you change a BPMD beamcode.  Check out all feedbacks if you restore
a mask config;  this means CREATING BPM BUFRINGs on all measurement
micros, watching for error messages, and checking that feedbacks receive
good measurements for the right beam.

4. Communicate and document any changes.  Send email to MWS and LJH,
and update the help for CREATE BPM BUFRING.  (This help is updated by
typing "EDITHELP FBCKCALB").