textfiles/magazines/JAUC/juac10.txt

From dfox@fc.net Sat Jan 21 06:21:58 1995
Received: from freeside.fc.net (freeside.fc.net [198.6.198.2]) by bigboote.WPI.EDU (8.6.9/8.6) with ESMTP id GAA16077 for <mikecap@wpi.edu>; Sat, 21 Jan 1995 06:21:53 -0500
Received: (from dfox@localhost) by freeside.fc.net (8.6.8.1/8.6.6) id FAA01518 for mikecap@wpi.edu; Sat, 21 Jan 1995 05:18:54 -0600
Date: Sat, 21 Jan 1995 05:18:54 -0600
From: Malik Al-Rashim <dfox@fc.net>
Message-Id: <199501211118.FAA01518@freeside.fc.net>
To: mikecap@wpi.edu
Subject: JAUC-File10
Status: O

 
                              CALLER ID FAQ

 By Padgett Peterson (padgett@tccslr.dnet.mmc.com)

 Frequently Asked Questions About Caller-ID v1.1 Mar. 1994

 1) What is Caller-ID ?

    First ask "What is ANI"

 2) OK, What is ANI ?

 ANI or Automatic Number Identification is a mechanism by  which the
 different telephone companies determine what account is to be charged for
 a call, This information is passed between Telcos and was originally
 for  billing  purposes and predated both SS7 (Signaling  System 7)
 and (C)LASS (Local Area Signaling  Services was the original AT&T
 designations, the "C" was added by Bellcore after divesture) services
 which make CNID or Calling  Number IDentification as Caller-ID is more
 properly known, possible.

 Since the Telcos had ANI, the decision was made to make it available
 to authorized parties such as 911 service and law enforcement agencies.
 ANI is also used to let a Telco operator know who is calling.

 More recently, ANI is used to report to 800 and 900  subscribers,
 who made the calls they have received, in the first case so that
 the  800 subscriber knows who the charge is for, and so that 900
 number subscribers know who to charge.

 Thus while ANI is similar to CALLER-ID and may provide the same
 information, they are actually two different services and ANI information
 is not necessarily the same as what will appear on a CALLER-ID display.

 3) Now (maybe) what is Caller-ID ?

 Caller-ID is a Telco offering that is a byproduct of (C)LASS services.
 In this case, only those numbers reported by participating exchanges are
 returned, exactly which are and which are not is currently (March 1994)
 at the Telco's discretion.

 The Federal Government has stated that it is their intent that nationwide
 CNID be available by mid-1995. The full text of this decision may be
 found FCC Report No. DC-2571 issued on March  8, 1994.

 The biggest effect of the ruling is to mandate transport of CPN (customer
 provided number) information between interconnecting networks eliminating
 the effective inter-LATA-only limitation that exists today in most areas.

 Currently there are two types of Caller-ID.  The first (often referred
 to as "basic" service) just returns the calling number or an error
 message and the date/time of the call.

 The second ("enhanced" Caller-ID) also may return the directory
 information about the calling number. At a minimum, the name of the
 subscriber is returned (the subscriber is not the same as the caller,
 the phone company has no way to determine who is actually on the line).

 4) How is the Caller-ID information provided ?

 As a 1200 baud, 7 data bits, 1 stop bit data stream usually transmitted
 following the first and before the second ring signal on the line. Note
 that this is not a standard Bell 212 or CCITT v22 data format so a
 standard modem will probably not be able to receive it. Further, the
 serial information exists as such only from the recipient's switch to
 the callee's location.  Between carriers the signal exists as data packets.

 The signal is provided before the circuit is complete: picking up the
 receiver before the data stream is finished will stop/corrupt the
 transmission.

 Currently there are two types of information returned: a  "short form"
 which contains the date/time (telco and not local) of the call and the
 calling number or error message. The "long form" will also contain the
 name and possibly the address (directory information) of the calling phone.

 The  "short  form"  stream  consists of a  set  of  null  values, followed
 by a two byte prefix, followed by the DATE (Month/Day), TIME (24 hour
 format), and number including area code in  ASCII, followed by a 2s
 compliment checksum.  Most modems/caller id devices will format the data
 but the raw stream looks like this :
 0412303232383134333434303735353537373737xx
 or (prefix)02281334407555777(checksum)

 A formatted output would look like this:
 Date -   Feb 28
 Time -   1:34 pm
 Number - (407)555-7777

 5) Can a Caller-ID signal be forged/altered ?

 Since the signal is provided by the local Telco switch and the calling
 party's line is not connected until after the phone is answered, generally
 the signal cannot be altered from the distant end.  Manipulation would
 have to take place either at the switch or on the called party's line.

 However, the foregoing applies only to a properly designed CNID unit.
 For instance the Motorola M145447 chip has a "power down" option that
 wakes the Chip up when the phone rings for just long enough to receive,
 process, and deliver the CNID signal after which it shuts down until the
 next call.

 Should this option be disabled, the chip will be in a "listen always"
 state and it is theoretically possible to "flood" a line making a
 vulnerable box record successive erroneous numbers.

 I have received a report of a device called "Presto Chango" that
 can transmit an extra ADSI modem tone after the call has been picked up
 that will cause a susceptible box to display the later information. It
 was also reported to me that CNID boxes marketed by US-West as their
 brand and made by CIDCO have been used to demonstrate the "Presto Chango"
 box.

 6) What is "ID Blocking" ?

 Most Telco's providing Caller-ID have been required to also provide the
 ability for a calling party to suppress the Caller-ID signal. Generally
 this is done by pressing star-six-seven before making the call. In most
 cases this will block the next call only however some Telcos have decided
 to implement this in a bewildering array of methods. The best answer is
 to contact the service provider and get an answer in writing.

 Currently this is supplied as either by-call or by-line blocking.  By-Call
 is preferred since the caller must consciously block the transmission
 on each call.  By-Line blocking as currently implemented has the
 disadvantage that the caller, without having a second caller-id equipped
 line to use for checking, has no way of knowing if the last star-six-seven
 toggled blocking on or off.

 Note that blocking is provided by a "privacy" bit that is transmitted
 along with the CNID information and so is still available to the Telco
 switch, just not to the subscriber as a CNID  signal. Consequently related
 services such as call trace, call return, & call block may still work.

 7) What happens if a call is forwarded ?

 Generally, the number reported is that of the last phone to forward the
 call. Again there are some Telco differences so use the same precaution
 as in (6). If the forwarding is done by customer owned equipment there
 is no way of telling but will probably be the last calling number.

 Note that as specified, CNID is *supposed* to return the number of the
 originating caller but this is at the mercy of all forwarding devices,
 some of which may not be compliant.

 8)  What happens if I have two phone lines and a black box to do
 the forwarding ?

 If you have two phone lines or use a PBX with outdialing features, the
 reported number will be that of the last line to dial. Currently there
 is no way to tell a black box from a  human holding two handsets together.

 9)  I called somebody from a company phone (555-1234) but their Caller-ID
 device reported 555-1000.

 Often a company with multiple trunks from the Telco and their own
 switch will report a generic number for all of the trunks.

 There is a defined protocol for PBXs to pass true CNID information on
 outgoing lines but it will be a long time before all existing COT
 (Customer Owned Telephone) equipment is upgraded to meet this standard
 unless they have a reason to do so.

 10) I  run a BBS. How can I use Caller-ID to authenticate/log callers ?

 There are two ways. The first utilizes a separate Caller-ID box
 with  a  serial  cable  or an internal card. This sends the information
 back to a PC which can then decide whether to answer the phone and what
 device should respond. Some of these are available which can handle
 multiple phone lines per card and multiple cards per PC.

 The second (and most common) is for the capability to be built in a modem
 or FAX/modem. While limited to a single line per modem, the information
 can be transmitted through the normal COM port to a program that again
 can decide whether or not  to  answer the phone and how. There is a
 FreeWare Caller-ID ASP script for Procomm Plus v2.x available for FTP
 from the Telecom archive.  Most such software packages will also log each
 call as it is received and the action taken.

 Of course for true wizards, there are chips available (one of the first
 was the Motorola MC145447) that can recognize the CNID signal and
 transform it into a proper RS-232 (serial) signal.

 11) How is security enhanced by using Caller-ID over a Call-Back
 service or one-time-passwords for dial-up access ?

 Caller-ID has one great advantage over any other mechanism for telephone
 lines. It allows the customer to decide *before* picking up the receiver,
 whether to answer the call.

 Consider hackers, crackers, and phreaks. Their goal in life is to forcibly
 penetrate electronic systems without permission (sounds like rape doesn't
 it ?). They employ demon dialers and "finger hacking" to discover
 responsive numbers, often checking every number in a 10,000 number
 exchange.

 If they get a response such as a modem tone, they have a target and
 will often spend days or weeks trying every possible combination of codes
 to get in. With Caller-ID answer selection, the  miscreant will never
 get to the modem tone in the first place, yet for an authorized number,
 the tone will appear on the second ring. Previously the best solution
 for dial-ups was to set the modem to answer on the sixth ring (ats0=6).
 Few hackers will wait that long but it can also irritate customers.

 12) What error messages will Caller-ID return ?

 a) "Out of Area" - (Telco) the call came from outside the Telco's
 service area and the Telco either has no available information or
 has chosen not to return what information it has.

 b)  "Blocked" or "Private" - (Telco) the caller either has permanent
 call blocking enabled or has dialed star-six-seven for this call. You do
 not have to answer either.

 c) "Buffer Full" - (device manufacturer) there are many Caller-ID devices
 on the market and exactly how they have chosen to implement storage is up
 to the manufacturer. This probably means that the divide has a limited
 buffer space and the device is either losing the earliest call records or
 has stopped recording new calls.

 d)  "Data  Error" or "Data Error #x" - (device  manufacturer) signal was
 received that was substandard in some way or for which the checksum did
 not match the contents.

 e)  "No  Data Sent" - (device manufacturer) Signal was received consisting
 entirely of nulls or with missing information but a proper checksum.

 13) Why are so many people against Caller-ID ?

 FUD - Fear, Uncertainty, & Doubt or 10,000,000 lemmings can't be wrong.
 There were some justifiable concerns that some people (battered wives,
 undercover policemen) might be endangered or subject to harassment
 (doctors, lawyers, celebrities) by Caller-ID.  As mentioned above there
 are several legitimate ways to either block Caller-ID or to have it return
 a different number.  It is up to the caller. The advantage is that with
 Caller-ID, for the first time, the called party has the same "right of
 refusal".

 Expect yet another Telco service (at a slight additional charge) to be
 offered to return an office number for calls made from home. Crisis
 centers could return the number of the local police station.


 Compiled by Padgett Peterson. Constructive comments to:
 padgett@tccslr.dnet.mmc.com  Brickbats >nul.

 Thanks for additional material to:

 David J. Kovan
 Robert Krten
 John Levine
 David G. Lewis
 Karl Voss

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

                THE PENTIUM BUG WAR ENDS AS WE KNOW IT

 By James Baar and Theodore Baar

 The  real long-term significance of the Great Intel Pentium Flaw
 Imbroglio is the imminent demise of the current practice of public
 relations and corporate and government communications as we know them.

 Ironically caught unaware of the communications world it helped create,
 Intel suffered a public relations near-disaster.  Intel's arch competitor,
 IBM, wandered bubba-like into a public relations bog the future depths
 of which are still to be determined.

 Clearly we soon will see on the boneyard of history such communications
 artifacts as:

       --The lengthy, well-spun news release or official statement
 explaining what "really" happened or why a product "really" is a
 breakthrough for all mankind.

       --The news conference where the news is that what the media said
 yesterday or last week is "really" not the news at all.

       --The  necessity to convince rushed and often ill-informed
 journalists and beautiful and much more ill-informed TV anchors that your
 truth is "really" true.

       The Internet is doing to public relations what CSPAN,  CNN Forums
 and talk radio are doing to news coverage:  When you are there, the
 messenger is extraneous.  And, on the Internet, you are there and you are
 the messenger as well..

       The Pentium Flaw War was the first major corporate war to be fought
 primarily in cyberspace. The initial, very scattered shots were fired
 more than five months ago on the Internet; major engagements got underway
 in October; and a worldwide battle raged through November and early
 December.

      Little of this was noted particularly in the general or trade media
 until near the end.  And then it was reported as a highly technical
 problem of limited general interest.  Only when IBM found it convenient
 to drop the equivalent of a small nuclear weapon did most of the major
 national media take note that something much more than an academic,
 technically obscure brawl was underway.

 Only then did the WALL STREET JOURNAL shout from it's front page:

       Chip Shot
       Computer Giants' War
       Over Flaw in Pentium
       Jolts the PC Industry

 And, on the same day, the NEW YORK TIMES shouted from it's front page:

       I.B.M. HALTS SALES
       OF IT'S COMPUTERS
       WITH FLAWED CHIP

 Both  stories were inspired belatedly by an IBM announcement that it was
 suspending sales (sort of) of any of it's personal computers that included
 the Intel Pentium chip because the chip had a flaw.

 Well,  ho-hum:  Except for the IBM announcement, this was old news along
 the Information Highway.  And the IBM announcement was immediately
 discounted by many of the veteran cyberspace combatants of the Pentium
 War as highly suspect: something similar to Parliament coming out against
 slavery in America after Lexington and Concord.

 Most great military engagements begin quite casually if not accidentally:
 A sniper picks off a poacher stealing a chicken.  A nervous platoon leader
 calls in a little artillery fire on a bunker.  A lost company stumbles
 on a tank column.

 Back in June, Intel and some of it's customers already knew about the bug
 that was preventing the new Pentium microprocessors to divide accurately
 out to more than nine or 10 decimal places in some cases.  Intel did not
 publish the information. If any messages about the bug appeared here and
 there in various newsgroups on the Internet for the next few months,
 they initially attracted little attention.

 This was not the kind of consumer problem that causes a lot of excitement
 at your neighborhood 24-hour store.  But this bug was of interest -- and
 in some cases importance to parts of the world technical community
 engaged in major mathematical calculations: This is a community that also
 appreciates that such a flaw is not the first nor will be the last in
 the increasing complexity of computer components and software; exalts
 technical openness; recognizes quickly when it is being stonewalled; and
 has a biting specialized sense of outrage and humor.

 Prof. Thomas Nicely of Lynchburg College reports that when he began
 running into a potential flaw in the Pentium in June he started a three
 month effort to determine whether the problem was the Pentium or something
 else.  For example, his own calculations; or possibly known bugs in other
 hardware such as the Borland C Compiler.  And in Copenhagen mathematicians
 developed a T-shirt satirizing the Intel chip logo "Intel Inside" as "No
 Intelligence Inside" and published memos saying "We knew about it  early
 in June..."

 Intel managed to downplay and contain word of the bug for the most part
 through the next three months.  Any callers were told at first that a fix
 was underway and that the bug affected only very special situations.

 Then, on Oct. 30, Dr. Nicely posted a message to "whom it may concern"
 on the Internet,  reporting his findings and his frustrations with getting
 Intel to pay serious attention to him. In the succeeding weeks, the war
 between Intel and it's users exploded.  Each day there were more reports
 about the bug and Intel's truculence.

 The number of the strings of messages on the Internet increased and grew
 longer as users at universities, laboratories and corporations around the
 world reported the same bug and it's potential variations;  discussed
 their research for possibly more bugs; and reported on their
 unsatisfactory and frustrating phone calls to Intel.

      And here was where the war was really fought.

 Intel treated each caller as an individual, linear event to be dealt with
 in isolation; turned around or at least mollified.  Intel's position was
 that this was a routine bug that was being taken care of and was of no
 major importance to most of it's customers. The Intel position essentially
 remained that there was no need for a general replacement on demand; that
 the problem was relatively minor;  that if a user was engaged in the kind
 of heavy mathematics that could be affected by the bug then Intel, if
 it agreed, would replace a Pentium.

 Meantime, Intel and it's commercial allies continued to promote and sell
 Pentiums.  More than four million Pentiums were reported sold.

 The words "greedy" and  "arrogance" became popular on the Internet among
 customers describing Intel's position.  The Internet discussion was highly
 technical and  profane.  It also included useful suggestions for
 broadening the discussion.   For example, participants were provided
 with the Fax number of the New York Times.  And more and more of the
 callers to Intel shared their mostly frustrating experiences on the
 Internet with a worldwide audience of customers.   An angry mob -- slowly
 recognized as a major threat by Intel --  began to assemble in cyberspace

 Intel CEO Andrew Grove issued a statement on the Internet Nov. 27 seeking
 to quiet the mob.  Instead the roar in cyberspace increased.  Intel's
 Software Lab Technology Lab Director Richard Wirt on Dec. 8 issued a
 statement on the Internet describing Intel plans to provide a fix for the
 flaw.  The roar continued and spread and Intel's weakening protests were
 increasingly drowned out as the users reinforced each other with new data
 and complaints around the clock around the world.

 It was at this point on Dec.12 that IBM -- a reported minor player in the
 sale of Pentiums,  but the developer of a competitive chip, the PowerPC --
 decided to announce both on the Internet and to the major national media
 the halting of it's shipments of Pentium-based IBM PCs.

 The war was now spread to the major national media where the problem was
 easily confused with various consumer product recalls and the Internet
 where IBM's move was both discounted as self-serving and used
 simultaneously to pummel Intel further.

 By Dec. 20 Intel had had enough.  It agreed to a general recall and
 apologized for not doing so sooner.

    The public relations lessons are clear.

 People  --  particularly customers --  are no longer isolated waiting to
 learn sooner or later what is happening through the third party media
 screen and, in turn,  relying on  the  third  party media to screen and
 sooner or later report their reaction.  Even when the third party media
 is accurate this process can take many days.

 Through the Internet, people -- particularly customers --  can tell a
 corporation or organization exactly what they think and why and share that
 simultaneously and instantaneously with all concerned around the world.
 The Internet returns the world to the agora where everyone hears what was
 said; and everyone hears all comments and reactions;  everyone knows who
 is talking and can make credibility judgments.

 The first Intel error was not to spot the issue stirring on the Internet
 months ago when the commentary was helpful and understanding.  At that
 time and for several months later, Internet commentators could have been
 embraced and thanked for their efforts; immediate plans for a work-around
 fix could have been disclosed;  and work on a permanent fix could have
 been described:  all in cyberspace among sophisticated customers who well
 understand the complex nature of the technology.

 Intel's second error was not to recognize that because of the Internet it
 no longer could reason at least semi-privately with customers and advance
 rational technical arguments.  In pre-cyberspace days, that could be
 effective:  the customer is grudgingly mollified until the issue is
 eventually resolved.  But in this case,  as it's customers shared both
 their problems and experiences  with each other in real time, they fed
 each others frustrations; were empowered as a group to demand better
 treatment;  and built mutual strength with each day for new battles to
 come.

 Intel's third error was not to go directly on line with it's customers and
 deal with the issue interactively.  Instead, Intel pursued the classic
 static public relations mode of issuing statements and news releases.
 These were turned into blackened ruins by Internet flame messages in a
 matter of hours.

 Meantime, IBM by it's announcement, uncorked the Law of Unanticipated
 Consequences.  The Internet mob really understood the issue; the general
 public for the most part did not.  IBM, with motives already under
 suspicion, opened the bottle labeled "Doubt about Technology" to the
 overall potential future detriment of the Information Technology Industry
 in general.

 As  more people around the world join the millions already using the
 Internet for communications,  corporations and government will be forced
 if they wish to succeed to function within the new realities of cyberspace:
 information is shared and sifted by thousands of knowledgeable people;
 time is collapsed; facts are quickly checked; loss of credibility can be
 instantaneous;  second chances are rare and harder to effect;  grandstand
 plays better be perfect;  and the playing off of one audience against
 another is far more easily detected.

 Above all else, a smattering of obscure messages or even a random one or
 two can no longer be automatically disregarded as mere technical mumbling.
 For example, is anyone following up on a recent Internet potential bug
 message regarding AMD DX-80 chips or another regarding "something about a
 conditional loop" in the Pentium?

 One final cyberspace reality of note:  instant corrosive humor is abundant
 and effective.  (If they really are laughing about you, you can't be taken
 seriously anymore.)  This was ably demonstrated by the Internet author
 who wrote for the delectation of Intel customers and potential customers
 everywhere a Star Trek parody.  He called it:  "BBUUGGS IINN
 SSPPAACCEE!!".

 (This article is from a forthcoming issue of Knowledge Tools News, an
 electronic newsletter of Omegacom, Inc. James Baar (jimbar@omegacom.com)
 is president/managing consultant.  Theodore Baar (tedbar@omegacom.com.)
 is vice president/chief technologist.)

 -----------
 Copyright (c) 1994 Omegacom, Inc., all rights reserved.  This article may
 be posted to any USENET newsgroup,  on-line service, or BBS as long as it
 is posted in it's entirety and includes this copyright statement. All
 other rights reserved. This article may not be included in commercial
 collections or compilations without express permission from Omegacom,
 Inc.  jimbar@omegacom.com.  For all other uses you must seek permission
 of Omegacom, Inc.  jimbar@omegacom.com

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

                 NON-DISCLOSURE AGREEMENT OF DR. NICELY

 The following message was posted to the Internet by Dr. Thomas Nicely,
 discover of the Pentium Floating Point Unit Flaw. The first part deals
 with a question regarding Dr. Nicely's signing of a non-disclosure
 agreement with Intel.

 TO:     Whomever It May Concern
 FROM:   Dr. Thomas R. Nicely, Lynchburg College, Lynchburg, Virginia
         (nicely@acavax.lynchburg.edu)
 RE:     Pentium Bug and Intel NDA
 DATE:   94.11.25.1400 EST

 This is in reply to Paul Rubin's (phr@netcom.com) inquiry of 23 November.

 * I signed a temporary nondisclosure agreement with Intel on 10 November.

 * There was no coercion or threat of any kind, by either party.

 * The NDA was signed in the course of discussions to determine
   whether or not an agreement (such as a consultancy) could be reached
   which would prove beneficial in the long term to myself, to the Intel
   Corporation, and to my employer, Lynchburg College.

 * From 10 November until 22 November, I deflected all inquiries regarding
   the Pentium FPU to Intel's representatives.  This was a consequence of
   my own mistaken interpretation of the NDA; I was treating it in the
   manner of a security clearance; I once held a clearance for secret
   restricted data in X-division (nuclear weapon design and analysis)
   at Los Alamos National Laboratory, and that clearance treated most
   information concerned as "born secret," even if the information was
   acquired prior to the clearance and/or independently.  In the same
   spirit, I removed from the College's VAX anonymous FTP directory
   copies of the codes used to analyze the Pentium chip for the bug.

 * After receiving some complaints in this regard, Intel (on its own
   initiative) informed me on 22 November that I was free to discuss
   publicly the discovery and nature of the Pentium FPU bug, since this was
   my own work, accomplished prior to signing the NDA and without
   assistance from Intel; and that the primary purpose of the NDA was to
   insure confidentiality of information exchanged in the course of any
   consulting I might do for Intel in the future.

 * To this date, Intel has been most cooperative in alleviating difficulties
   caused for my own research (computational number theory; distribution of
   twin primes and other constellations, and the sums of their reciprocals)
   by the presence of the bug.  They have shipped replacement chips for the
   CPUs in the machines I am using, and I have verified that the new chips
   are free of the bug (zero errors in > 1e15 simulated random divisions).

 * I cannot speak for Intel regarding its policies on CPU replacement for
   Pentium systems having the bug; that is a management decision which
   obviously must take into account the constraints of supply, inventory,
   logistics, expense, and public relations.  To date, I believe Intel has
   handled the affair in essentially the manner that could usually be
   expected of most businesses operating in a highly competitive, low-margin
   capitalistic economy.  Any Pentium owner who feels the need for a
   replacement CPU should contact Intel Customer Service and Tech
   Support at 800-628-8686, or Intel representative John Thompson at
   408-765-1279.

 * I probably have a somewhat different perspective on the bug than most
   users.  It is my opinion that the current generation of microprocessors
   (and possibly all of them since, say, the 8080) has become so complex
   that it is no longer possible to completely debug them, or even to
   determine every bug that exists in one.  Thus, the discovery of this
   particular bug should not be any great surprise.  There have been many
   well-publicized bugs in the past (e.g., the 32-bit multiply bug in the
   early 80386s, the arctangent bug in the early 80486s, the stack-handling
   bug in the early 8088s, and the Motorola 68K revision F bug).
   Furthermore, in view of this, all mission-critical computations should
   be performed multiple times, in settings as independent as possible---
   preferably with different CPUs, operating systems, and software
   algorithms.  Where different platforms are not available, the same
   computation should be performed using algorithms as independent as
   possible; this was in fact how I pinpointed the Pentium bug---the
   sums of the reciprocals of the twin primes were being done in both
   long double floating point (64 significant bits) and in extended
   precision using arrays of integers (26 decimal digits at that time,
   53 decimal digits currently).  Dual calculations were also being run
   on 486 and Pentium systems.

 * Note that the bug can be temporarily circumvented by locking out
   the FPU.  For most DOS applications, this can be done by means of the
   DOS commands SET 87=NO (for executables created by Borland compilers)
   and SET NO87=NO87 (for executables created by Microsoft compilers).
   Of course, this is at best a performance-killing band-aid; some
   applications require an FPU, while Windows and most DOS extenders
   ignore these environmental variables.  In theory, it should be
   possible to write a fairly short (100 lines?) utility code which
   enters protected mode (ring 0), sets up a valid global descriptor table
   (and perhaps a valid interrupt descriptor table), resets the emulation
   bit in the machine status word of control register 0, and then re-enters
   real mode.  Running such a code at boot time should lock out the FPU
   even for Windows and DOS extended applications; a similar code could
   reactivate the FPU at will.  Unfortunately, I haven't had the time to
   write the code yet!

 * To date, my analysis indicates that the bug will appear in about 1 in
   31 billion random divisions and 1 in 1.26 billion random reciprocals.
   These figures are similar to the rate of 1 in 9.5 billion attributed to
   Intel.  In my own application (distribution of twin primes and the sum
   of their reciprocals) no error appeared for values < 824e9.  Most users
   will find these values reassuring; those of us doing computational
   number theory, chaos theory, or analysis of ill-conditioned matrices
   may still want a new, bug-free CPU.

 * To date, the worst-case error of which I am aware is an example
   apparently posted by Tim Coe of Vitesse Semiconductors on 14 November,
   indicating that the quotient 4195835.0/3145727.0 is returned correctly
   to only 14 significant bits (5 significant decimal digits).  I have not
   yet had a chance to verify this example.

 * Copies of some of the codes I have used to analyze the bug (updated to
   reflect later developments) will be restored to the anonymous FTP
   directory [anonymous.nicely.pentbug] of Lynchburg College's VAX server
   (machine ID acavax.lynchburg.edu) as soon as I get time to update and
   post them.

 * Feel free to transmit this communication as you wish.

 Sincerely,

 Dr. Thomas R. Nicely

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

                 THE COMPUTER NEVERMORE (The Raven)

 By Unknown

 Once upon a midnight dreary, fingers cramped and vision bleary,
 System manuals piled high and wasted paper on the floor
 Longing for the warmth of bedsheets,
 Still I sat there, doing spreadsheets;
 Having reached the bottom line,
 I took a floppy from the drawer.
 Typing with a steady hand, then invoked the SAVE command
 But I got a reprimand: it read 'Abort, Retry, Ignore.'

 Was this some occult illusion? Some maniacal intrusion?
 These were choices Solomon himself had never faced before.
 Carefully, I weighed my options.
 These three seemed to be the top ones.
 Clearly I must now adopt one:
 Choose 'Abort, Retry, Ignore.'

 With my fingers pale and trembling,
 Slowly toward the keyboard bending,
 Longing for a happy ending, hoping all would be restored,
 Praying for some guarantee
 Finally I pressed a key--
 But on the screen what did I see?
 Again:  'Abort, Retry, Ignore.'

 I tried to catch the chips off-guard--
 I pressed again, but twice as hard.
 Luck was just not in the cards.
 I saw what I had seen before.
 Now I typed in desperation
 Trying random combinations
 Still there came the incantation:
 Choose:  'Abort, Retry, Ignore.'

 There I sat, distraught exhausted, by my own machine accosted
 Getting up I turned away and paced across the office floor.
 And then I saw an awful sight:
 A bold and blinding flash of light--
 A lightning bolt had cut the night and shook me to my very core.
 I saw the screen collapse and die
 'Oh no--my data base,' I cried
 I thought I heard a voice reply,
 'You'll see your data Nevermore!'

 To this day I do not know
 The place to which lost data goes
 I bet it goes to heaven where the angels have it stored
 But as for productivity, well
 I fear that IT goes straight to hell
 And that Us the tale I have to tell
 Your choice:  'Abort, Retry, Ignore.'

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

                  TWAS THE NIGHT BEFORE STAR TREK...

 'Twas the night before Christmas, when all through the ship
 Not a circuit was buzzing, not one microchip;
 The phasers were hung in the armory securely,
 In hope that no alien would get up that early.

 The crewmen were nestled all snug in their bunks
 (Except for the few who were partying drunks);
 And Picard in his nightshirt, and Bev in her lace,
 Had just settled down for a neat face to face...

 When out in the hall there arose such a racket,
 That we leapt from our beds, pulling on pant and jacket.
 Away to the lifts we all shot like a gun,
 Leapt into the cars and yelled loudly "Deck One!"

 The bridge red-alert lights, which flashed through the din,
 Gave a lustre of Hades to objects within.
 When, what on the viewscreen, our eyes should behold,
 But a weird kind of sleigh, and some guy who looked old.

 But the glint in his eyes was so strange and askew,
 That we knew in a moment it had to be Q.
 His sleigh grew much larger as closer he came.
 Then he zapped on the bridge and addressed us by name:

 "It's Riker, It's Data, It's Worf and Jean-Luc!
 It's Geordi, And Wesley, the genetic fluke!
 To the top of the bridge, to the top of the hall!
 Now float away! Float away! Float away all!"

 As leaves in the autumn are whisked off the street,
 So the floor of the bridge came away from our feet,
 And up to the ceiling, our bodies they flew,
 As the captain called out, "What the Hell is this, Q?!"

 The prankster just laughed and expanded his grin,
 And, snapping his fingers, he vanished again.
 As we took in our plight, and were looking around,
 The spell was removed, and we crashed to the ground.

 Then Q, dressed in fur from his head to his toe,
 Appeared once again, to continue the show.
 "That's enough!" cried the captain, "You'll stop this at once!"
 And Riker said, "Worf, take aim at this dunce!"

 "I'm deeply offended, Jean-Luc" replied Q,
 "I just wanted to celebrate Christmas with you."
 As we scoffed at his words, he produced a large sack.
 He dumped out the contents and took a step back.

 "I've brought gifts," he said, "just to show I'm sincere.
 There's something delightful for everyone here."
 He sat on the floor, and dug into his pile,
 And handed out gifts with his most charming smile:

 "For Counselor Troi, there's no need to explain.
 Here's Tylenol-Beta for all of your pain.
 For Worf I've some mints, as his breath's not too great,
 And for Geordi LaForge, an inflatable date."

 For Wesley, some hormones, and Clearasil-plus;
 For Data, a joke book, For Riker a truss.
 For Beverly Crusher, there's sleek lingerie,
 And for Jean-Luc, the thrill of just seeing her that way."

 And he sprang to his feet with that grin on his face
 And, clapping his hands, disappeared into space.
 But we heard him exclaim as he dwindled from sight,
 "Merry Christmas to all, and to all a good flight!"

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

                              SANTA SOURCE CODE

 By Unknown

 #bash

 better !pout !cry
 better watchout
 lpr why
 santa claus <north pole >town

 cat /etc/passwd >list
 ncheck list
 ncheck list
 cat list | grep naughty >nogiftlist
 cat list | grep nice >giftlist
 santa claus <north pole >town

 who | grep sleeping
 who | grep awake
 who | egrep 'bag|good'
 for (goodnes sake) {
         be good
         }

 better !pout !cry
 better watchout
 lpr why
 santa claus <north pole >town


 [original source unknown]

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%