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: September 17, 2003 12:40 PM Wednesday; Rod Welch

Gary reported problems creating an Action Item review record.

1...Summary/Objective


..............
Click here to comment!

CONTACTS 

SUBJECTS
Action Item Support for Schedules Budgets Assisting People with Actio
Action Item Report Failed Using SDS a Record on 030916 Has an Incorre
Action Item Report Failed Record on 030916 Has an Incorrect Format Ne

1605 -
1605 -    ..
1606 - Summary/Objective
1607 -
160701 - Follow up ref SDS 1 VV4P.
160702 -
160703 - Gary encountered another problem doing an action item report on the
160704 -  combat project.
160706 -  ..
160707 - The beginning of the report is messed up, with a double underline.
160709 -  ..
160710 - There is also a duplication in the first Follow up link line, and a
160711 - conjested situation with an extraneous anchor.  This was noticed the
160712 - other day when we ran the first report for Paul to review action
160713 - items.  At that time, there was not enough time to investigate.
160714 - Today, with more problems piling up, time was allocated to fix these
160715 - problems.
160716 -
160717 -     Review shows both problems occurred as a result of work on 030828
160718 -     modifying the format for the default new SDS record that adds a
160719 -     control field and an explanation with an underline in order to
160720 -     allow tasks to run without crashing when a record is encountered
160721 -     that does not have a subject. ref SDS 2 9U6G
160723 -      ..
160724 -     The code for creating an Action Item review meeting record was
160725 -     positioning the first entry too low, and it was adding an
160726 -     underline for the subject description, which is not needed now.
160727 -
160728 -           Changed macro file 070301 to capture the control field
160729 -           string starting with the employee field, rather than column
160730 -           1, because we only have about 80 char that can be read with
160731 -           macro 1188 and subjects strings can now get close to 100
160732 -           char. ref OF 1 U75K  Same change was made for entering the
160733 -           string to the new record. ref OF 1 JY7O
160735 -  ..
160736 - Line 1090, ref OF 1 V64G, -label deldub in 070301
160737 -
160738 -    This is where the problem occurs that causes a double underline on
160739 -    the first pass, because the original code constructed a description
160740 -    and underline because the template for a new control field was
160741 -    blank.  To fix the problem of people not having time to enter a
160742 -    subject, a default subject format was developed and this has a
160743 -    structure that is different from what the code was designed to
160744 -    process.
160745 -
160747 -  ..
160748 - The end of the report shows that a record on 030916, just yesterday
160749 - is messed up.  The underlying record is messed up as well.
160751 -  ..
160752 - Research shows that the report itself seems to be causing the record
160753 - format to fail, rather than having anything wrong with the record
160754 - that is causing the report to fail.
160756 -  ..
160757 - There are two records on 030916.  It is the 2nd record that is
160758 - causing the problem.  After running the action item report, if the
160759 - 1st record is removed, and then the report is converted into an SDS
160760 - record, the problem with the record on 030916 does not occur.
160762 -  ..
160763 - This turned out to be a false positive.
160765 -  ..
160766 - The only reason the 1st record is a problem is because the code was
160767 - not designed to handle action items for two different records on the
160768 - same day.  There was not a deliberate design to avoid this condition,
160769 - it was just overlooked as something that required special handling,
160770 - and up until now this condition has not been encountered.
160771 -
160773 -  ..
160774 - Line 1070, ref OF 1 QR7K, -label cfelp in 070301 about 70 lines below
160775 -
160776 -    Basic problem is that we need to build another control field for a
160777 -    second record on the same date.  The code was assuming that if the
160778 -    record was on the same date, it didn't need to construct a control
160779 -    field, and other parts of the code were wired to expect another
160780 -    control field, and so the lack of structure, caused the 2nd record
160781 -    to be configured as an action item report, because everything got
160782 -    mixed up, and then the code was saving the original record because
160783 -    previously, it may have been necessary to add anchors for links,
160784 -    even though now all records are saved originally with adequate
160785 -    anchors, so saving a messed up record compounded the problem.
160787 -     ..
160788 -    immed 2r
160789 -    up
160790 -    ins_text!0000 -   !
160791 -    immed 5r
160792 -    up
160793 -    ins_text!0513 -    Time Milg Emply T  Bill Function  Special Subject/File!
160794 -    up
160795 -    ins_text!05 - K101 00.0 0000 00000 0 00000!
160796 -    up
160797 -    ins_text!0501 - This is a test!
160798 -    up
160799 -    ins_text!0501 - ===================!
160800 -    up 2
160801 -    loc_cur 0 10
160802 -    macro 987
160803 -    down 5
160804 -
160805 -        Modified the code here to build a control field each pass that
160806 -        has new revised structure.  Also decided to add an anchor
160807 -        above each segment where a control field is created.
160808 -
160810 -  ..
160811 - We have two problems....
160812 -
160813 -    1.  There is a number entered on the Follow up line at the top of
160814 -        the record, and
160815 -
160816 -        Turns out this is not a mistake, it reports total number of
160817 -        pending action items.
160818 -
160820 -         ..
160821 -    2.  If a current record is included in the report it is not being
160822 -        purged, evidently because the code is using the record ID to
160823 -        construct the file ID, rather than using gfname.
160825 -         ..
160826 -        This problem is caused by not clearing the command string to
160827 -        purge the record.  The prior pass has a standard length SDS
160828 -        record spec, whereas the path and filename for a current SDS
160829 -        record is shorter, so added a command to shear off the excess.
160830 -        ref OF 1 K57J
160831 -
160833 -  ..
160834 - Submitted a letter to Gary via email explaining problems and
160835 - corrections that solve the problems he had today.
160836 -
160837 -    1.  Sent him a revised macro for...
160838 -
160839 -                     c: sd 03 070301
160841 -         ..
160842 -    2.  SDS record for Bruce...
160843 -
160844 -             D:\SD\08\GLJDY\02\03\09\16\100018
160846 -         ..
160847 -        ...to replace corrupted file on 030916. ref SDS 3 0001
160849 -  ..
160850 - Gary will need to delete the initial record he created for today at
160851 - 1050a with the description "Action Item Review to handle OBE
160852 - items..." and then create another task using the new code.
160854 -  ..
160855 - Gary mentioned in a call this afternoon that he ran a report and it
160856 - did not include the activity for today.  I have now run several
160857 - reports they all include today, when today's date is included in the
160858 - specification, which is a default param for the general report in the
160859 - Manage menu of the Schedule, which  I think is what Gary is using.
160860 -
160861 -
160862 -
160863 -
160864 -
160865 -
160866 -
160867 -
160868 -
1609 -