440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700

Date: Sun, 29 Apr 2001 12:08:44 -0700

03 00050 61 01042901

Mr. Richard Karpinski
Computer Generalist
5833 Ross Branch Road
P.O. Box 262
Forestville, CA 95436-0262

Subject:   SDS Improvement

Dear Dick,

Thanks for a thoughtful letter responding to my request for feedback on SDS customer profile issues, following up a recent inquiry.

Your point about knowledge being a sort of double edged sword aligns with experience using SDS, which shows that ordinary stuff that occurs day-to-day from doing things, meetings, calls and so on, becomes very complex very quickly. The conscious mind masks 90% of this complexity, so we are unaware and unfettered by it, which is a blessing in some respects, but leads to constant mistakes. SDS exposes this stuff, and so affords the chance to avoid mistakes, but at a price of stress, particularly in giving notice, sounding the alert, as it were, to disbelieving people. Another KM dilemma.

The post script in your letter sounds like your assignment with Apple has finished up. Didn't you also have some editing work on a book that was underway for awhile? Jack Park, who is contributing on the OHS/DKR project has been talking about doing a book series. You might contact him about contributing. My feeling is that you could be a big help.

There is an improvement I need for SDS, which you might consider.

SDS is a DOS application and so has a limit of 640K. Most records and uses of SDS are never impacted, but there are occasions when an experienced user will crank out a big record, and of course when reports are assembled, then 640K can become an issue. Actually, the bigger problem is that memory becomes fragmented, and so ordinary use over a day leads to out of memory problems. Since SDS is used constantly, what might be called "memory recovery" is bigger problem than the actual 640K limit.

SDS is written in assembly language. I think I may have mentioned it is actually written in a macro language for an editor, that is then compiled. In any case, does your background and interest provide a basis to address this particular problem? One solution would be to change 16-bit pointers to 32-bit pointers. This is pretty tedious work that would require a lot of debugging. Another solution might be to create a patch to use extended, or expanded, memory, or something like that.

If this is something you could take up, I would like to talk about how we might proceed, i.e., how much it would cost, etc.




Rod Welch