J. Kissel, P. Thomas

As per work permit 4840, and in order to resolve issues reported in CDS Bugzilla #721, I've added the "accum_overflow = 1" flag to the parameters block at the top level of the H1SUSSRM and H1SUSTMSX front end models this morning. With this addition, these SUS will match every other SUS's overflow behavior in that it will accumulate overflows for each individual channel in their respective DAC monitors, as opposed to displaying the overflow rate. For reference, this was added to every other suspension during the changes described in ECR E1300578, and on pg 18 of G1301192; see aLOGs from November 2013 (e.g. 8226, 8325, etc.), and these were just accidentally overlooked in all the fervor of activity. 

Detailed Notes
SRM
captured safe.snap before restart, but just in case alignment offsets are 
p    0
y   2000
safe did *not* restore alignment offsets... why? moving on.
restored alignment to values prior to restart.
IPC errors popped up on SR3 and OMC because SRM is the master model, distributing Binary I/O channels to the other two. Upon restart the connection was lost, but it's a one-time error. A diag reset on the GDS_TP screen cleared the error.

TMSX
captured safe.snap before restart, but just in case alignment offsets are
p -24
y -315
safe restored alignment correctly.

Tested cumulative overflow on TMSX by adding large offset to M1 F3 COILOUTF. DAC saturates, and DAC monitor accumulates as expected.
Tested cumulative overflow on SRM by adding large offset to M2 UL COILOUTF. DAC saturates, and DAC monitor accumulates as expected.

safe.snaps committed to userapps repo.