Reason for change
ft2Util had the LAT mode from the Magic 7 file as an 'unsigned int' instead of an 'signed int'. This caused a crash in fitsGen for mode values of 0 (it apparently causes some casting problem). And this weekend's data contained mode zero data.
Please note that the complete range of LAT modes and their meaning is GD proprietary and ITAR controlled and I have no idea what they all are 
Test Procedure
We have processed real data with mode zero on DEV with this version of L1Proc.
Rollback procedure
We can roll back to the previous version of L1Proc.
CCB Jira
Details
ft2Util v1r2p9:
- Observing mode is declared as a signed integer variable. In the ft2Util it was an unsigned one. This generated and error in FITSIO due to the typecasting only when the value of the observing mode is 0. LONE-45
Complete set of tags for L1Proc 1.46
Code Versions
GlastRelease (sim/recon) v13r11p6
ScienceTools (Level 2) : v9r5
Science Ops (task defs, scripts):
Level 1 pipeline code and applications running in L1:
svac/L1Pipeline: v1r45
dataMonitoring/AlarmsCfg: v1r0p4
dataMonitoring/FastMonCfg: v1r0p10
dataMonitoring/DigiReconCalMeritCfg: v1r0p15
dataMonitoring/Common: v3r0p13
dataMonitoring/FastMon: v3r0p13
datMonitoring/IGRF: v1r0p1
svac/Monitor: v1r0p13
svac/EngineeringModelRoot: v3r14
svac/TestReport: v5r8
users/richard/pipelineDatasets: v0r4
ft2Util: v1r2p9*
GPLtools: v1r10