From: "Vladimir Z. Nuri" <vznuri@netcom.com>
Date: Mon, 15 Sep 1997 11:52:57 +0800
To: cypherpunks@cyberpass.net
Subject: IRS tax reform y2k style
Message-ID: <199709150346.UAA18593@netcom13.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




Gary North has been predicting apocalypse on the y2k subject
for awhile. but he has a lot of data to back his claims.
this talks about the IRS computers and predicts they're going
to collapse.



------- Forwarded Message

- - -----BEGIN PGP SIGNED MESSAGE-----
>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 
>selected 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 
>agreed 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: 
>Anderson 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.
>
>
>
>
- - -----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBNBxwqA1+em56DF4lAQGQSQf8CmdfnQ8VVaABHBc8sr+Ux//h/CFJLCB3
toMNaHcVKv9IC/awB/2V4UVv5pq2z6yRgR/2Xl3npJNR91OFJp1Kbg5Q79XKrmYs
73odoCPeGHvkzS8oPouuHQzvv1csz/t7cHFwl2xeE7PppbvaoGBkkzavxaQT+5MF
ZJJ9MFQP71R9gdgIzRN1lvhFxYBiuBVfUWZ/Xm2663J56QjGPkscYbE++Ka1aWMy
ZDvtbVgaUYZo9NM7nv1zD+b1YzUuOCo0R5Mw07wINnTaLSlw5doNDXDhKINZuFgi
wHh0M7vOSM9pvOoJpYu75kB5anpEgSUQBST+YouaKrL8WHx5G3lHfg==
=4ELb
- - -----END PGP SIGNATURE-----


- -> Send "subscribe   snetnews " to majordomo@world.std.com
- ->  Posted by: Jack Doolin <jackdoolin@earthlink.net>


------- End of Forwarded Message