From: Brian Atkins (brian@posthuman.com)
Date: Thu Sep 18 1997 - 14:11:42 MDT
Found this on cypherpunks list, might be interesting for you all.
--
The future has arrived; it's just not evenly distributed.
-William Gibson
attached mail follows:
A little fairy tale.
Has a happy ending, and everything...
Cheers,
Bob Hettinga
--- begin forwarded text
Date: Wed, 17 Sep 1997 19:13:41 -0500
From: Bill GL Stafford <springco@arn.net>
Organization: Spring Management Company
MIME-Version: 1.0
To: Robert Hettinga <rah@shipwright.com>
Subject: Preparing the Remnant for the far side of the crisis
Robert;
This is a rather long post. I wanted for you to see it personally. It is
important and I wanted to clear it thru you. If I don't see it posted I
will know
you did not chose to post it.
Best personal regards,
Bill GL Stafford
Began fowarded mail:
>From: jmcnally@bigdog.fred.net
>Date sent: Thu, 11 Sep 1997 10:42:20 -0400 (EDT)
>Subject: REMNANT REVIEW of September 5, 1997
>
>Gary North's
> REMNANT REVIEW
>emailbonus: Matt. 6:33-34
>year2000@garynorth.com
>
> Preparing the Remnant for the far side of the crisis
>
>Vol. 24, No. 9 590 September 5, 1997
>
> I am hereby lifting the copyright of this issue of
> Remnant Review. This one I want you to send to your
> friends, neighbors, boss, Congressman, and anyone
> else who might want advance information on the end,
> at long last, of the 16th Amendment: vetoed by Year
> 2000 noncompliant computers. Photocopy it, print it,
> whatever. Then visit my Web site for full documen-
> tation (under "Government"):
>
>THE ULTIMATE TAX REFORM: JANUARY 1, 2000
>
> What I am about to report will verify what I have been saying all
>year. If this doesn't constitute proof, I don't know what can persuade
>you. From this point on, anyone who tells you that the Millennium Bug
>is not a big deal, or who says, "We'll just have to wait and see about y2k,
>there's no need to hurry," simply doesn't know what he's talking about.
>Ignore him.
>
> On August 21, I stumbled into the most amazing government
>document I have ever seen. I had read a brief news story about a
>company that had applied for a contract to work as a subcontractor for
>the IRS in a restructuring of its computer systems. The IRS admitted to
>Congress last January that its $4 billion, 11-year attempt to modernize
>its computer systems had failed. Here was a follow-up story. So, I went
>to the company's Web site to find more information. This led me on a
>merry chase across the Web.
>
> Finally I landed on the IRS's page -- specifically, its page
>relating to
>its PRIME project. There were pages of blue links to documents, each
>one with a strange name or the name of a state. It was not clear to me at
>first what I had discovered. So, I started clicking links. I found
>nothing that I could understand, link after link: government bureaucratese.
>Then I hit pay dirt: the mother lode, my friends -- what we have been
>waiting for since 1913. Deliverance. Free at last, free at last! THE
>IRS'S MAINFRAME COMPUTERS -- 63 OF THEM, PLUS MICROCOMPUTERS -- ARE ON
>THE BRINK OF TOTAL COLLAPSE. Yee-hah!
>
> This amazing admission appears in an innocuously titled document,
>"Request for Comments (RFC) for Modernization Prime Systems
>Integration Services Contractor" (May 15, 1997). The author is Arthur
>Gross, Associate Commissioner of the IRS and Chief Information
>Officer, i.e., the senior IRS computer honcho. It was Mr. Gross who
>went before Congress in January to admit defeat.
>
> Mr. Gross now says that the IRS is no longer capable of operating its
>own computer systems. The IRS has over 7,500 people involved in just
>computer maintenance, with a budget a $1 billion a year (Appendix B.
>p. 2), yet they can no longer handle the load. And so, says Mr. Gross,
>some of them are going to get fired. You can imagine the continuing
>morale problem that this announcement will cause! The IS (information
>systems) division will be, as they say, DOWNSIZED. From now on, the
>IRS must achieve the following:
>
> . . . shifting the focus of IS management to a
> business orientation: servicing customers with
> exponentially increasing technology needs,
> implementing massive new technology applications
> on schedule within budget while managing the
> downsizing of the IS organization
> (Appendix B. p. 2).
>
> Do you think that people slaving away in their cubicles, trying to fix
>the Millennium Bug, will respond favorably to this notice? "Fix it, and
>then you're out!" Mr. Gross knows better. So, with this amazing
>document, he calls on private industry to come in and TAKE OVER
>THE ENTIRE IRS COMPUTER DIVISION. This is what Mr. Gross
>calls "a strategic partnership" (p. 1). The new partners will have to fix
>the Millennium Bug. The IRS will give them exactly eight months, start
>to finish: October 1, 1998 to the end of June, 1999.
>
> The IRS's Digital Augean Stables
>
> Perhaps you have had trouble on occasion getting information from
>the IRS about your account. After reading this document, I now know
>why. The information is held in what the IRS calls "Master Files" (p.
>4). These files are held in the Martinsburg, West Virginia, computer.
>This computer receives data sent in by 10 regional centers that use a
>total of 60 separate mainframes. These mainframes do not talk to each
>other. Or, as Mr. Gross puts it, they are part of "an extraordinarily
>complex array of legacy and stand-alone modernized systems with
>respect both to connectivity and inoperability between the mainframe
>platforms and the plethora of distributed systems" (p. 4). This is
>bureaucratese, but I do understand the word, INOPERABILITY.
>
> The tax data build up in the local mainframes for five business days.
>Then they are uploaded to West Virginia. This may take up to 10 actual
>days. Then the Martinsburg computer sends it all back to the regional
>computers in the Service Centers. Then the information is made
>available to the "Customer Service Representatives" (p. 5), i.e., local tax
>collectors. The elapsed time may take two weeks.
>
> But . . . it turns out that the actual source payment documents are
>not sent to the Master Files. Neither is "specific payment or tax
>information." This information stays in what the IRS calls
>STOVEPIPED SYSTEMS, meaning stand-alone data bases "which, for
>the most part, are not integrated with either the Master Files or the
>corporate on-line system, IDRS" (p. 5). Separate tax assessments for the
>same person can appear in six separate systems, and these do not
>communicate with each other (p. 5). "Further, each system generates
>management reporting information which is not homogeneous, one with
>the other . . ." (p. 7). To help us visualize this mess, and much larger
>messes, the document includes charts. These charts are so complex that
>my printer was unable to print out the 116-page document -- probably
>not enough RAM. I had to get two other people involved to get one
>readable copy.
>
> I have included one of these charts on the back page, just for fun.
>Go ahead. Take a quick look. No need to get out your magnifying glass
>just yet. Then comes the key admission: "These infrastructures are
>largely not century date compliant . . ." (p. 11). The phrase "century
>date compliant" is the government's phrase for Year 2000-compliant. In
>other words, THE IRS'S COMPUTERS ARE GOING TO CRASH.
>Now hear this:
>
> In addition to three computing centers, (Memphis,
> Detroit and Martinsburg) the latter of which is a
> fully operational tax processing center, the IRS
> deploys a total of sixty mainframes in its ten
> regional service centers.
>
> None of the mainframes are compliant, thereby
> necessitating immediate actions ranging from
> systems software upgrades to replacement (p. 9).
>
>It gets worse:
>
> A still greater and far reaching wave of work
> in the form of the Century Date Project is
> cascading over the diminishing workforce that
> is already insufficient to keep pace with the
> historical levels of workload. For the Internal
> Revenue Service, the Century Date Project is
> uniquely challenging, given the aged and non-
> century compliant date legacy applications and
> infrastructure as well as thousands of undocumented
> applications systems developed by business personnel
> in the IRS field operations which are resident on
> distributed infrastructures but not as yet
> inventoried (p. 13).
>
> Notice especially two key words: "undocumented" and "inventoried."
>"Undocumented" means there is no code writer's manual. They either
>lost it or they never had it. "Inventoried" means they know where all of
>the code is installed. But it says: "not as yet inventoried." How much
>code? Lots.
>
> The IS organization has inventoried and scheduled
> for analysis and conversion, as required, the
> approximately 62 million lines of computer code
> comprising the IRS core business systems. With
> respect to the business supported field
> applications and infrastructures, however, we do
> not know what we do not know. Until central field
> systems and infrastructures are completed, the IRS
> will be unable to analyze, plan, and schedule the
> field system conversion (p. 13).
>
> I love this phrase: WE DO NOT KNOW WHAT WE DO NOT
>KNOW. This is surely not bureaucratese. Now, let's put all of this into
>a clearer perspective. The Social Security Administration discovered its
>y2k problem in 1989. In 1991, programmers began to work on
>correcting the agency's 30 million lines of code. By mid-1996, they had
>completed repairs on 6 million lines (CIO Magazine, Sept. 15, 1996.)
>Got that? It took five years for them to fix 6 million lines. But the IRS
>has 62 million lines THAT THEY KNOW ABOUT, but they don't know
>about the rest. It's out there, but there is no inventory of it.
>
> Consider the fact that they have not completed their inventory. The
>1996 "California White Paper," which is the y2k guide issued by the IS
>division of the California state government's y2k repair project, says that
>inventory constitutes 1% of the overall code repair project. Awareness
>is 1%. So, after you get finished with inventory, YOU HAVE 98% OF
>YOUR PROJECT AHEAD OF YOU. Meanwhile, the IRS has not yet
>completed its inventory.
>
> The IRS has led the American welfare state into a trap. The Federal
>government, like the U.S. economy, will be restructured in the year
>2000. Most Americans will be in bankruptcy by 2001, but they will be
>free.
>
> Meanwhile, the news media are all a-dither about the Clinton-
>Congress accord on taxes, which will balance the budget in 2002. As
>George Gobel used to say, "Suuuuuure it will." Who is going to collect
>revenues in 2000?
>
> Please Help Get Us Out of This Mess!
>
> The next section of Mr. Gross's report I find truly unique. When was
>the last time you read something like this in an agency's report on its
>own capacity? (The next time will be the first.)
>
> THE CHALLENGE: THE INFORMATION SYSTEMS (IS)
> ORGANIZATION LACKS SUFFICIENT TECHNICAL
> MANAGEMENT CAPACITY TO SIMULTANEOUSLY
> SUPPORT TODAY'S ENVIRONMENT, EFFECTUATE THE
> CENTURY DATE CONVERSION AND MANAGE
> MODERNIZATION (p. 13).
>
> This states the IRS's problem clearly: its computer systems are just
>barely making it now, and the Year 2000 Problem will torpedo them.
>
> Mr. Gross then announces the IRS's solution: quit. The IRS has
>now admitted that "tax administration is its core business" and it will
>now "shift responsibility for systems development and integration
>services to the private sector . . ." (p. 54). But first, it must find
>some well-heeled partners.
>
> "The IRS has acknowledged that its expertise now and in the future
>is tax administration." This means that "the IS organization must be
>rebuilt to preserve the existing environment and partner with the private
>sector to Modernize the IRS" (p. 13). I love it when someone capitalizes
>"Modernize." Especially when it really means "officially bury."
>
> Then the coup de grace: "Any reasonable strategy to move forward,
>therefore, would focus on managing the immediate crisis -- 'stay in
>business' while building capacity to prepare for future Modernization"
>(p. 14). Then comes part 2 of the report:
>
> The Next Eighteen Months:
> Staying in Business and
> Preparing for Modernization
>
> Mr. Gross knows that there is a deadline, and it isn't 2000. It's
>months earlier. He has selected June, 1999. Most organizations have
>elected December, 1998. This allows a year for testing. Mr. Gross is
>more realistic. He knows late 1998 is too early. The IRS can't do it. (I
>would say that late 2008 is too early. The IRS has tried to revamp its
>computer system before.)
>
> . . . the IRS must undertake and complete major infrastructure
>initiatives no later than June 1999, to minimally ensure century date
>compliance for each of its existing mainframes and/or their successor
>platforms. At the same time, the IRS must complete the inventory of its
>field infrastructures as well as develop and exercise a century date
>compliance plan for the conversion replacement and/or elimination of
>those infrastructures. (p. 19).
>
> Then comes an astounding sentence. This sentence is astounding
>because it begins with the word, IF. (Note: RFC stands for Request for
>Comment.)
> IF THE INFRASTRUCTURE ANALYSIS BECOMES
>AVAILABLE, UPDATES WILL BE PROVIDED TO POTENTIAL
>OFFERERS TO ASSIST IN DEVELOPING RESPONSES TO THE
>RFC.
>
> If...? IF...? He is warning all those private firms that he is inviting
>in to clean up the mess that they may not be given the code analysis. But
>code analysis constitutes the crucial 15% of any Year 2000 repair job,
>according to the California White Paper. Then, and only then, can code
>revision begin.
>
> Meanwhile, the IRS system's code is collapsing even without y2k.
>The programmers are not able to test all of the new code. Mr. Gross
>calls this "Product Assurance." This division, he says, has "sunk to
>staffing levels less than 30 percent of the minimum industry standard . .
>.. ." This makes it "one of the highest priorities within the IS
>organization, given that, today, major tax systems are not subjected to
>comprehensive testing prior to being migrated to production" (p. 15). In
>short, Congress passes new tax code legislation, and the IRS
>programmers implement these changes WITHOUT TESTING THE
>NEW CODE. Now comes y2k. As he says, "the Century Date
>Conversion will place an extraordinary additional burden on the Product
>Assurance Program." I don't want to bore you, but when I find the most
>amazing government document I've ever seen, I just can't stop. Neither
>could Mr. Gross:
>
> Regrettably, the challenge is far more overarching: to modernize
>functioning but aged legacy systems which have been nearly irreparably
>overlaid by and interfaced with a tangle of stovepiped distributed
>applications systems and networked infrastructures (p. 55).
>
> I'll summarize. The IRS has got bad code on 63 aging mainframe
>systems, plus micros. It has lost some of the code manuals. It does not
>know how much code it has. It must now move ("migrate") the data
>from these y2k noncompliant computers -- data stored in legacy
>programs that are not y2k compliant -- to new computers with new
>programs. These computers must interact with each other, unlike
>today's system. Bear in mind that some of this code -- I have seen
>estimates as high as 30% -- is written in Assembler language, which is
>not understood by most programmers today: perhaps 50,000 of them,
>worldwide (Cory Hamasaki's estimate). Then everything must be tested,
>side by side, old system vs. new system, on mainframe computers, before
>anyone can trust anything. (This assumes that extra mainframes are
>available, but they aren't.) Warning:
>
> Beyond the magnitude of the applications system migration, the
>complexity and enormity of the date conversion that would be required
>necessitates careful planning and risk mitigation strategies (e.g.,
>parallel processing). While the risks inherent in Phase III may be nearly
>incalculable given the age of the systems, the absence of critical
>documentation, dependency on Assembler Language Code (ALC) and
>the inevitable turnover of IRS workforce supporting these systems, it is
>essential to plan and execute the conversion of the Master Files and its
>related suite of applications (p. 30).
>
> I'll say it's essential! The key question is: Is it possible? No.
>
> Can you believe this sentence? "The risks inherent in Phase III may
>be nearly incalculable . . ." What does he mean, "may be"? They ARE.
>
> Meanwhile, Congress keeps changing the Internal Revenue Code.
>This creates a programming nightmare: coding the new laws. So, how
>big is this project? Here is how Mr. Gross describes it: "Modernization
>is the single largest systems integration undertaking in world eclipsing
>in breadth and depth any previous efforts of either the public or private
>sector. Given the fluid nature of the Nation's Tax Laws, Modernization
>is likely to be the most dynamic, creating even greater complexity and,
>in turn, compounding the risks" (p. 54). Many, many risks.
>
> Two questions arise: (1) Who is going to fix it? (2) At what price?
>The answer? He has no answer. All he knows is that this project is so
>huge that NORMAL COMPETITIVE BIDDING WILL NOT WORK.
>For this project, the IRS is not saying what its "partners" will be paid.
>It's open for negotiation.
>
> You may be thinking: "Boondoggle." I'm thinking: "Legal liability
>in 2000 larger than any company's board of directors would rationally
>want to risk, unless they think Congress will pass a no-liability law in
>2000." Here is Mr. Gross's description of the special arrangement. Pay
>close attention to the words "competitive process." He bold faces them; I
>do, too.
>
> Our challenge, therefore, is to FORGE A BUSINESS PLAN AND
> PUBLIC/PRIVATE PARTNERSHIP in accordance with federal
> governmental procurement laws and regulations ABSENT THE
> TRADITIONAL LEVEL OF DETAILED REQUIREMENTS
> TYPICALLY ESTABLISHED AS THE BASIS OF THE
> COMPETITIVE PROCESS (p. 60).
>
> He calls on businesses to create a "DETAILED SYSTEMS
>DEVELOPMENT PLAN" (p. 60). He goes on: "In general, the IRS
>seeks to create a business plan which: Shares risk with the private
>sector; Incents [incents???!!!] the private sector to either share or
>assume the 'front end' capital investment . . ." (p. 60). Read it again.
>Yes, it really says that. THE IRS WANTS THE PRIVATE SECTOR
>TO PUT UP MOST OR ALL OF THE MONEY TO FIX ITS ENTIRE
>SYSTEM.
>
> This is why the minimum requirement for a company to make a bid
>is $200 million in working capital. It has to have experience in
>computers. It must be able to repair 5 million lines of code (p. 70).
>
> How complex is this job? The complexity is mind-boggling: a seven-
>volume "Modernization Blueprint." To buy it on paper costs $465, or
>you can get a copy on a free CD-ROM. Needless to say, I got the CD-ROM.
>
> So, you think, at least the IRS is getting on top of this problem.
>Suuuuure, it is. The contract award date is [let's hear a drum roll,
>please]: October 1, 1998 (p. 73). How realistic is this? You may
>remember Mr. Gross's deadline: June 1999. So, he expects these firms
>to be able to fix 62 million lines of noncompliant code, if they can find
>the missing code in the field offices, even though the IRS has lost the
>documentation for some of this code, in an eight-month window of
>productivity. Social Security isn't compliant after seven years of work
>on less than half the IRS's number of lines of code.
>
> The IRS is facing a complete breakdown. Its staff can't fix the code.
>The IRS wants private firms to pay for the upgrade and manage the
>computer systems from now on. It does not know how much code it has.
>It does not have manuals for all of the old code. It does not even know
>how to pay the firms that get the contracts: either by "contractually
>greed upon fees" or "pursuant to measurable outcomes of the
>implemented systems" (p. 61). It has called for very large and
>experienced firms to submit comments by October 1, 1997.
>
> In short, the IRS does not know what it is doing, let alone what it
>has to do. It only knows that it has to find a few suckers in private
>industry
>to bear the costs of implementing a new, improved IRS computer system
>and then assume responsibility for getting it Year 2000-compliant
>between October 1, 1998 and the end of June 1999. ("There's one born
>every minute.") Here are 12 companies that have expressed interest:
>nderson Consulting, Computer Sciences Corporation, EDS
>Government Services (EDS is not itself y2k compliant), GTE
>Government Systems, Hughes Information Technology Systems, IBM,
>Litton PRC, Lockheed Martin Corporation, Northrup Grumman
>Corporation, Ratheon E-Systems, Tracor Information Systems
>Company, and TRW. The list is posted at:
>
>http://www.ustreas.gov/treasury/bureaus/irs/prime/interest.htm
> Conclusion
>
> It's all over but the shouting. The IRS is going bye-bye.
>Accompanying it will be the political career of Mr. Gingrich and the
>historical reputation of Mr. Clinton. Bill Clinton will be remembered as
>the President on whose watch the Federal government shut down and
>stayed shut down. First Mate Newt will try to avoid going down with
>the ship of state, but he won't make it. And as for Al Gore . . . . Well,
>maybe he can get a job herding cattle on the Texas ranch of his ex-
>roommate at Harvard, Tommy Lee Jones. Think of it: not "Gore in
>2000," but GORED IN 2000. Mr. Information Highway will hit a dead end.
>
> On June 30, 1999, the IRS will know that its computers are still
>noncompliant. On the next day, July 1, fiscal year 2000 rolls over on
>the Federal government's computers and on every state government's
>computer that has not rolled over (and shut down) on a bi-annual basis
>on July 1, 1998. Almost every state: about half a dozen will roll over on
>October 1, 1999.
>
> In 1999, chaos will hit the financial markets, all over the world --
>assuming that this does not happen earlier, which I do not assume. The
>public will know the truth in 1999: THE DEFAULT ON U.S.
>GOVERNMENT DEBT IS AT HAND. The tax man won't be able to
>collect in 2000. The tax man will be blind. Consider how many banks
>and money market funds are filled with T-bills and T-bonds. Consider
>how the government will operate with the IRS completely shut down.
>Congress hasn't thought much about this. Neither has Bill Clinton.
>
END
-- ÐÏࡱá Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bill GL Stafford Content-Disposition: attachment; filename="vcard.vcf" --- end forwarded text ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 14:44:55 MST