At 03:48 PM 1/12/00 EST, Ernst wrote:
>Jud McCranie wrote:
>
>>This is getting off topic, but:
>>The criteria for something to be patentable is that the average
>>practitioner in the field wouldn't think of it. So it boils down to
>>whether the average programmer would think of windowing, given the problem.
>
>Well, that's the major criterion (non-obviousness) if no one has explicitly
>demonstrated or patented a similar thing previously...
>
>>" Dickens applied for the patent in October 1996 "
>>
>>I was using windowing in 1987, so his patent is invalid (prior invention).
>
>...in that case windowing is considered "prior art," and the patent is invalid
>on its face. Jud, assuming you have reasonable supporting documentation for
>your use of windowing prior to 1996, you should consider sending it to the
>U.S. patent and trademark office, http://www.uspto.gov (even if you have no
>desire to attempt to patent it - clearly, showing that you merely thought of
>it before 1996 in order to invalidate Joe Schmoe's patent is much easier than
>proving that you thought of it before anyone else did and seeking a patent
>yourself). Note that prior art is most easily established via publication,
>public use or sale - if you only wrote a windowing script for your own use,
>it may be more difficult to prove.
>
>
>From a programming perspective, my own top "why 2K" question is this this:
>even given that the person(s) who first used a mere 2 characters to store
>the year had good reason (e.g. severely limited computer memory) to do so,
>why didn't they use those 2 precious bytes as a 2-byte integer?
>Had they done so, we'd be talking instead about the "Y32K" or "Y64K" bug,
>and even Microsoft might have had sufficient time to fix their software
>by then. :)
>
>-Ernst
>
It wasn't so much the computer memory, Ernst, as it was the disk storage
space. An insurance application record would have perhaps 6 dates within
100 bytes: date of applicant's birth, date application for insurance was
taken, date of proposed enrollment, date the first premium was due, date the
premium was received/recorded in the system, date of expiration if the
payments stopped, and probably more. Saving the "century" field 6 times was
12 bytes saved in COBOL PIC 99 mode.
Clever was the use of COBOL PIC XX as a COMPUTATIONAL field to store a date
in 16 bits (which was the length of PIX XX). 7 bits for year since 2^7 =
128 so a year value up to 99 was stored there; 5 bits for day since 2^5 = 32
so a day value was stored there and 4 bits for month as 2^4 = 16 so a month
value was stored there. Two bytes for a YEAR-MONTH-DAY value was great.
Adding century was a bummer to this idea. The programmer had to have a
REDEFINED PIC 99 COMP-4 of the PIC XX and then use a routine to extract
three fields.
As some may recall, the packed-digits format (COMP-3) was also used to store
disk space on the file's record. IBM created/used this format to allow
space savings.
But the bottom line was that in the 1960's and 1970's, disk store space was
expensive and saving it was worth the effort spent in more programming
(people were cheaper that computers, in a way). Yes, memory was expensive
and limited, but it was not the cause of the Y2K issue.
No one in the late 1980's EVER believed that the PC would be as powerful as
it is now, that disk storage would be as cheap, and that all these
improvement would be in the home !! Only the 1.44 MB diskette of ten years
ago remains the same.
And I am delighted that MERSENNE.ORG lets me hunt for giant primes even if I
never find one.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
