THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700
rodwelch@pacbell.net
S U M M A R Y
DIARY: March 5, 2004 05:04 AM Friday;
Rod Welch
Fixed SDS program launch that was broken by recent improvement.
1...Summary/Objective
..............
Click here to comment!
CONTACTS
SUBJECTS
Diary Summary Creating Record for Prior Date Crashing Completely Beca
SDS Program Launch Group Manager Operation Failing to Archive Prior D
Schedule for prev day archived
New Record Prior Date Create in Diary Summary Rather than in the Sche
Schedule Extend Automatically
Lesson Learned Little Deviations on Inconsequential Details Have Cas
Launch SDS Program Operations Lesson Learned Little Deviations on In
1009 -
1009 - ..
1010 - Summary/Objective
1011 -
101101 - Follow up ref SDS 7 5C4L. ref SDS 6 0000.
101102 -
101103 - Last night, tried to make a diary for a prior date using the newer
101104 - method of entering a specification in the diary summary, for which
101105 - functions were developed on 030816. ref SDS 7 0001
101107 - ..
101108 - The thing was crashing, big time. The screen lit up with different
101109 - colors and could not do anything except shut down the session.
101111 - ..
101112 - This event presents a case study for lessons learned that fits the
101113 - model of little deviations leading to big, cascading problems, along
101114 - the lines of the case study reported by PMI during a professional
101115 - event at Asilomar on 940611. ref SDS 2 8239 Morris noticed the same
101116 - challenge occurs in management, reported on 921127. ref SDS 1 0674
101117 - Earlier in 400 BC, Aristotle stated the general rule about little
101118 - deviations from the truth multiplying into conflict, crisis and
101119 - calamity over time. ref OF 13 JV3G NASA regularly learns this lesson
101120 - publicly, reported on 991001, ref SDS 4 SX58, as we all do privately,
101121 - but refuse to admit the magnitude of the problems we face, noted by
101122 - Andy Grove from experience working at Intel, reviewed on 980307.
101123 - ref SDS 3 1657
101125 - ..
101126 - Today, investigation showed that a method was adopted on 030816 of
101127 - getting the day of the week by using the Schedule and Diary record for
101128 - the prior date that is created each day by 04702 during program
101129 - launch. ref SDS 5 FV7H
101131 - ..
101132 - For the past few days, I, also, noticed, during transferring work
101133 - operations from c13 to c12 and back, that several files were listed
101134 - with blank underscores in the filename. At the time, scrolling was
101135 - occurring so quickly on the screen that I was unable to attach any
101136 - meaning, other than to note something different was occurring from
101137 - what is normally observed during this operation.
101139 - ..
101140 - This morning, finally found out what these strange strings were that
101141 - were flowing by on the screen. Beginning on 040229, none of the
101142 - Schedule and Diary records have been archived. The descriptions are
101143 - there, so they show up in the Diary Summary listing, but the files are
101144 - not there.
101146 - ..
101147 - This explains why the function to create a prior date diary crashed.
101148 - A loop occurred, because when the code tried to open the Schedule and
101149 - Diary record to get the User name and day of the week, it was missing,
101150 - so the code went into a routine to report a missing record, and this
101151 - entails looking in the Schedule and Diary record to get the User name
101152 - and day of the week, so it just got into a loop of opening endless
101153 - files.
101155 - ..
101156 - So, the question is why have these records suddenly stopped, after
101157 - being created for 20 years?
101159 - ..
101160 - Research this morning discovered these tasks, which are largely
101161 - unrelated, created a cascading impact that caused a lot of big
101162 - problems.
101164 - ..
101165 - Work on 040229 to slightly expand and refine capability developed on
101166 - 031217, ref SDS 6 7X6M, for increasing the Schedule automatically, to
101167 - always provide several months of dates from the current date, and
101168 - without taxing user span of attention, some changes were made to
101169 - 04702. ref SDS 7 5C4L None of the substantative changes caused the
101170 - problems today. One thing that was done, simply because of devoting
101171 - time to work in 04702, ref OF 1 D15O, was to change the method of line
101172 - number calls that are read and processed by the compression macro 011,
101173 - by adding a line location identifier rather rely on unique code
101174 - strings to be interpreted correctly by 011. This change was developed
101175 - some years ago, but a lot of legacy code has not been updated, so when
101176 - code is being reviewed, if there is time, as on 040229, work is done
101177 - to conform the code to the stronger method, similar to the change from
101178 - cut and paste to the chara read op.
101180 - ..
101181 - Specifically...
101182 -
101183 - s /yy /
101184 -
101185 - ...was changed to...
101186 -
101187 - *%sy
101188 - s /yy /
101189 -
101190 - ...and the code was changed to enter the specification on the 2nd line
101191 - instead of the first.
101193 - ..
101194 - When this was created and tested on 040229, everything seemed to run
101195 - correctly. Discovered today that looks can be deceiving. Seeing
101196 - should not always be believed, without careful attention to span of
101197 - attention.
101199 - ..
101200 - Here is the problem.
101202 - ..
101203 - When the spec is entered on the 2nd line from the top of the file, the
101204 - cursor remains in this position. This means that on subsequent
101205 - processing that enters a specification into 04702, which occurs below
101206 - -label get29, ref OF 1 4Q8G, the cursor is still on line 2. Guess
101207 - what activity is occuring at -label get29. Yep, its archiving the
101208 - Schedule and Diary record, which suddenly stopped working on 040229.
101209 - ref SDS 0 WI79
101211 - ..
101212 - The cause of the problem is that the command that positions entry of
101213 - the specification did not specify the line, but simply assumed the
101214 - cursor was still on line 1, because that is the way code was done for
101215 - many years.
101217 - ..
101218 - This morning took time to go through 04702 and update all of the line
101219 - calls and adjusted positioning to use line 2, rather than line 1.
101221 - ..
101222 - Testing showed this restored the function that archives the Schedule
101223 - and Diary record.
101225 - ..
101226 - Testing further showed that once the Schedule and Diary record is in
101227 - place, than the code for creating a prior date diary also functions
101228 - correctly. There is no need to create the missing Schedule and Diary
101229 - records, because the only thing being drawn is the User name and the
101230 - day of the week. The user name is consistent, so any of the records
101231 - is adequate, and the code is designed to find the nearest Schedule and
101232 - Diary record, since occassionally none is created, when there is no
101233 - activity on a particular date. There is a slight problem that the day
101234 - of the week will be incorrect, but it is not used for processing and
101235 - so is solely informational. If Morris ever comes up with a command to
101236 - dig out the day of the week based on a date, we can fix this, but in
101237 - the meantime there is no harm no foul on this.
101239 - ..
101240 - However, having a listing in the Diary Summary for a Scheduel and
101241 - Diary record that does not exist is problematic, because this creates
101242 - the loop encountered last night. ref SDS 0 WI79
101244 - ..
101245 - The solution was to remove the pointers to the Schedule and Diary
101246 - records in the Description data base for the 4 dates since 040229.
101247 -
101248 -
101249 -
101250 -
101251 -
101252 -
101253 -
101254 -
101255 -
101256 -
101257 -
101258 -
1013 -