Time: Sat Sep 13 08:06:05 1997 by primenet.com (8.8.5/8.8.5) with ESMTP id IAA21462; Sat, 13 Sep 1997 08:06:26 -0700 (MST) by usr05.primenet.com (8.8.5/8.8.5) with SMTP id IAA19644; Sat, 13 Sep 1997 08:01:29 -0700 (MST) Date: Sat, 13 Sep 1997 08:01:18 -0700 To: (Recipient list suppressed) From: Paul Andrew Mitchell [address in tool bar] Subject: SLS: THE ULTIMATE TAX REFORM: JANUARY 1, 2000 Down the tubes in a bit bucket. They are strangling themselves in their own "codes" (COBOL, Fortran, C, Assembly, PL/I, etc.) Halleluia!! /s/ Paul Mitchell former systems programmer >I know this is long, but it's worht a look. Any of you programmers out >there care to comment?? > >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 >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. > > > >********************************************** >To subscribe or unsubscribe, email: > majordomo@majordomo.pobox.com >with the message: > subscribe ignition-point email@address >or > unsubscribe ignition-point email@address >********************************************** >http://www.telepath.com/believer >********************************************** > > ======================================================================== Paul Andrew Mitchell : Counselor at Law, federal witness B.A., Political Science, UCLA; M.S., Public Administration, U.C. Irvine tel: (520) 320-1514: machine; fax: (520) 320-1256: 24-hour/day-night email: [address in tool bar] : using Eudora Pro 3.0.3 on 586 CPU website: http://www.supremelaw.com : visit the Supreme Law Library now ship to: c/o 2509 N. Campbell, #1776 : this is free speech, at its best Tucson, Arizona state : state zone, not the federal zone Postal Zone 85719/tdc : USPS delays first class w/o this As agents of the Most High, we came here to establish justice. We shall not leave, until our mission is accomplished and justice reigns eternal. ======================================================================== [This text formatted on-screen in Courier 11, non-proportional spacing.]
Return to Table of Contents for
Supreme Law School: E-mail