Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/spss-shift/14029.rpt Дата изменения: Thu Jan 30 03:13:26 2014 Дата индексирования: Fri Feb 28 08:23:24 2014 Кодировка: Поисковые слова: trees

SPST Shift Summary
29-Jan-2014 Day 029
** Day Shift **


Personnel: Hathaway

Shift Checkout by: Hathaway

System Status:
Diskspace: DATA: @62% TREE: @62% PREP: @62% MS: @62%

Calendars in progress: 14034 built

SMS status: 140347c8/sa034y01_f

Shortfall Numbers:
Week: 14041 Total: 22 TDE: 0 TDW: 6 171: 0 TDS: 16 (jrc)

FLIGHT:
14034:
from Hathaway -

o Ran the tdrs_optimizer tool, got 97 deletes of 213 events, an
expected higher number than had been usual.
Found a new-to-me behavior. In the re-create USMs, the selected
start time typically defaults to a near current time; in this case
it was 029:15:32:35, which has generally been a good time to use -
early enough to cover the start of the working (034) calendar, but
no early than times of events already past.
This time - the schedman gave:

/data/scheduling/spss_flight_data/pass/sched/h029152107.cfm
Enter CFM file or =/data/scheduling/spss_flight_data/pass/sched/h029152107.cfm >
*** ERROR: Corrupted CFM file! ***
Start time None
End time 2014.040:23:58:19
Traceback (most recent call last):
File "/data/scheduling/spss_tools/com//do_spss_cmds.py", line 57, in
exec "status = " + run_string
File "", line 1, in
File "/data/scheduling/spss_tools/com/schedman.py", line 115, in run
tdrs_schedule = sched_util.tdrs_schedule(option, root_output_path, cfm_path)
File "/data/scheduling/spss_tools/com/sched_util.py", line 205, in __init__
self.set_cfm_file(cfm_path)
File "/data/scheduling/spss_tools/com/sched_util.py", line 301, in set_cfm_file
self.cfm_span, self.tdrs_a, self.tdrs_b = get_times_from_cfm(self.cfm_input_file)
File "/data/scheduling/spss_tools/com/sched_util.py", line 537, in get_times_from_cfm
wind = time_util.window(start_time,end_time)
File "/data/scheduling/spss_tools/com/time_util.py", line 1092, in __init__
raise TypeError(WinError)
TypeError: Window constructor requires a pair of
spss_time objects

Somehow the Start time was found as "None", which errored. When I
entered a manual start time of 029:00:00:00, the process completed
normally, giving a usable schedule.
Not knowing if this matters, I saw a FOT_REQUEST_SYSTEM from yesterday
to cancel a Change Request for
Current Event Start Time: 2014.029/17:47:00
Current Event Stop Time: 2014.029/18:09:36
There is a change by lstake for the previous event at 29:16:00:56

Just after that 029:15:32:35 default. Coincidence?
However there also is/was an event at: 029 15:05:00 - 029 15:58:56
which brackets that default. If a USM/CFM file gets Corrupted when
the Start is in the middle of an event (possibly currently in use,
changing Status from Granted to Completed), one would think we would
have stumbled on this before, as I routinely use the default start time
and event coverage occurs fairly often.
In any case, the workaround does work.


o The usual bi-weekly gstdn update came in during the afternoon.
Started up a fresh PASS MS/CL run with this. If no changes or
surprises, expect to got to Product Delivery Thursday once signoff
is received and FOT ready.

BUGS ENCOUNTERED:

MISCELLANEOUS:
********************************************************************************
NO swing shift report!