Preparing the Remnant for the far side of the crisis

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/

(large file elided, as it's really too large to comment on in bits, even
eliding most of it)

Gary North is not the only one forecasting a "meltdown."

There's simply no way that much code can be refactored to get the "00"
problem fixed. It isn't, of course, just a matter of doing a
search-and-replace on "00" and replacing it with "2000." For example, the
date code was picked to be 2 digits (back in the 1950s and 60s and well
into the 70s, 80s, and even 90s) to save space. Switching to 4-digit dates
would require recompilation of the code (for which the compilers may not
even run properly any longer), and the old hardware will of course not
accept straightforwardly recompiled code (because part of the code "tucked"
these compressed numbers into small registers, as but one of many examples).

Anyway, the best CASE and suchlike tools are inadequate to solve this, as
North notes.

Also, just _testing_ the new code will be a huge project. As North notes,
this will take down mainframes needed to handle the already-increasing
load. And new flaws will occur, just due to bad code and not even related
to the 00 issue. Several years would be far too short to take on this
effort...the 8 months (!!) being talked about by the IRS is laughable.

I don't know the impact. As just one example: a lot of people will be
getting warning notices asking where there Social Security payouts are
being reported, or demanding verification that they are eligible, etc.
(Various subroutines buried in millions of line of code scattered on
hundreds of old machines will incorrectly calculate ages, of course.)

(The IRS could try to "turn off" anything related to sending out notices
about age-related situations, e.g, about Social Security and IRAs and the
like, but this would chop revenue out. And add to the confusion, as people
send queries back to the IRS.)

If the IRS is only now beginning to address this monumental problem, as the
reports we are now seeing suggest, then a meltdown is inevitable. There
simply are not enough programmers to handle the job, and by Brooks' Law
(which is dominant over Moore's Law, of course) not even thousands of
skilled programmers could accomplish what is needed.

And certainly not in just a few years, much less the 8 months (!!!) being
planned.

Another thing: taxpayers and corporations will _add_ to the confusion, by
sending letters and queries back to the IRS asking about some letter or
warning they got from the IRS. For some, this will even be a tactic to
delay payment almost indefinitely. ("I received your letter of blah blah
telling me I am not eligible for blah blah benefits. Before I can complete
my tax return for the year 1999, please advise me about blah blah.")

It is conceivable that the Year 2000 problem, which is really the "archaic,
distributedm, chaotic, too-big data base problem," could accelerate the
conversion to a simpler tax, perhaps a 15% flat tax. (Even a flat tax needs
consideration of what income really is, what apparent income is not real
income, etc. But a flat tax which ignored Social Security income and
deductions, for example, or other social transfer payments, would be much
simpler for government computers to handle.)

The notion of privatizing the system will not really help much, not in the
handful of months before the impact hits. And there are worrisome aspects
to this privatization. Recall that previous regimes had problems collecting
taxes, and issued "letters of marque and reprisal" for "privateers" to stop
ships on the high seas to collect taxes for the crown. Sir Francis Drake
made his fortune this way, collecting taxes for Elizabeth I.

How will it go when Electronic Data Systems or TRW are the ones computing
the taxes owed? (TRW has that nice advantage of already having our credit
spending habits.)

It's gonna be exciting.

--Tim May


The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^1398269     | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

the y2k question with regards to the government has a key
question: suppose computers start cranking out nonsense.
how fast can each problem be fixed? the IRS has armies
of people *right*now* that do nothing but fix problems
created by the computers. how far would this force go
toward fixing all y2k problems? not far, I imagine. but
one thing that Gary North is not emphasizing a lot is
that the big question is how fast new forces can be mobilized
when the government finds itself in a crisis. it is
true at the current rate it looks dismal for the govt to
fix the problems in time, but govt has huge amounts of 
monetary resources to throw at problems when it wants to.
does anyone have any idea how much cash sloshes around in
defense industries? 

sure, the computers may go haywire
for a few days, or a few weeks, but this may not have
a noticeable impact on govt as usual. the govt has an
army of clerks that can be mobilized to do by hand much
of what is required. it is a small force, but what I am pointing
out is that this is not a black-or-white success-failure
proposition. the government is  notoriously ingenious at
"limping along" on limited resources!!

===

this is my call out to PROGRAMMERS not to work on projects
that you don't consider ideologically valid. let's start
a movement in which "intellectual capital" refuses to be
routed toward supporting oppressive, self-perpetuating,
dying welfare-state institutions.  imagine a worldwide
programmer union or movement in which programmers refuse
to work on y2k problems in the government and refuse to
work on other projects they do not support, no matter what
the money. 

they say that every man has his price.
integrity has no price!! imagine, would you turn down any
amount of money to work on the corrupt state mechanisms?
this is exactly what is required to bring them down. as
long as they can continue to bribe the populace with its
own money, they will continue.

Vlad the Imposter writes:

> this is my call out to PROGRAMMERS not to work on projects
> that you don't consider ideologically valid. let's start
> a movement in which "intellectual capital" refuses to be
> routed toward supporting oppressive, self-perpetuating,
> dying welfare-state institutions.  imagine a worldwide
> programmer union or movement in which programmers refuse
> to work on y2k problems in the government and refuse to
> work on other projects they do not support, no matter what
> the money. 
> 
> they say that every man has his price.
> integrity has no price!! imagine, would you turn down any
> amount of money to work on the corrupt state mechanisms?
> this is exactly what is required to bring them down. as
> long as they can continue to bribe the populace with its
> own money, they will continue.

Wow.  I never expected to see Detweiler championing Tim's "collapse
of governments" theme.


-- Jeff

> they say that every man has his price.
> integrity has no price!! imagine, would you turn down any
> amount of money to work on the corrupt state mechanisms?
> this is exactly what is required to bring them down. as
> long as they can continue to bribe the populace with its
> own money, they will continue.

I once worked for the city version of the evil corrupt state mechanism
here in NYC.  It's not as bad as people think it is, it's actually FAR
WORSE.

Here's my experiences:

The sysadmin there had quit unexpectedly and took a severance package.
Because the dude took severance, this closed the "line" for the job, which
means there was no longer a sysadmin postition available.  So they were
forced to hire me as a "special consultant" for supposedly two weeks -
took them two months to recreate the position.

When they were going to create an ID (no big deal, just a kodak like
camera with a laminator and some pre-printed text - for which they use
typewriters, yes typewriters to create) I had to wait a few days to get
one.  To quote the Human Resources weasel as to a reason "Because the temp
who makes them won't be here until Wednesday" (this was a full time, full
fledged gooberment employee.  The temp was expectedly a high school kid.)

After about another two months, I had to go through a "background check."
I had to pay for said background check.  All this being mandatory, failure
to do so results in instant firing and never being able to work there
again, etc.  I had to pay for this with a POSTAL money order. No check, no
bank money order - because those expire in 90 days and these buttfucked
people take longer than that to cash them in.  So not only do you get to
bend over for the city to peek into your ass, you have to pay for it too,
in a weird way.

All the forms are paper, xeroxed and re-xeroxed and re-xeroxed from
ancient type written forms, and they're mostly illegible.  One of the
forms was for politicians that clearly states that working for the city
means you're a public figgure and that you can expect NO PRIVACY and that
they may snoop on you in any way shape or form including health and credit
records, etc.

The beurocracy was legendary.  They were running on 286's with DOS and
Windoze 3.1 with 2 megs of ram and 20 to 80Mb hard drives...  This was in
the time of Windows 95 and pentium machines...  Viruses everywhere.

The network was the shittiest thing I ever saw running all 300 machines of
that department on 10b2! Yes! Coax, with Coax hubs.  50% of the time spent
was tracking down a loose connection that some ditz seccy had kicked out
(no offense to secretaries, but these folks were as smart as bricks.)

Everything is politics, politics, politics.  These folx care about nothing
else.  And corruption was prevalent.  One of the common things was for
various departments ordering say, 386's or 486's and having those rerouted
to the higher ups' and the dept ordering the 486's would get 286.  Memory,
CDROMS, sound cards, and other standard stuff ordered there was re-routed
elsewhere though ordered with the machine, the user would get a stripped
machine for which the city paid for a full one. And yes software piracy
was prevalent, even for server software.

Basically the life forms there rate only 1/2 an evolution scale point
higher than the life forms that live on welfare and social security
checks.  The only difference is that they work, they pay is about the
same.

This gentlemen is what our government is like.  It was a wrteching
experience to find this out personally, but it was worth it to see the
true nature of the beast that governs us though I puke at the thought of
what I went through there...

(By the way, did you know there is such a thing as a sewer tax that
businesses pay for, and that bakeries can get a discount on, because
baking makes most of the water they use evaporate and not go down the
sewer?  Such was the trivia there...)

=====================================Kaos=Keraunos=Kybernetos==============
.+.^.+.|  Ray Arachelian    |Prying open my 3rd eye.  So good to see |./|\.
..\|/..|sunder@sundernet.com|you once again. I thought you were      |/\|/\
<--*-->| ------------------ |hiding, and you thought that I had run  |\/|\/
../|\..| "A toast to Odin,  |away chasing the tail of dogma. I opened|.\|/.
.+.v.+.|God of screwdrivers"|my eye and there we were....            |.....
======================= http://www.sundernet.com ==========================

On Thu, 18 Sep 1997, Robert Hettinga posted:
(and someone else wrote)

> >
> >     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.

Two words,

"Sell Bonds!"


> "... 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/

Interesting juxtaposition, eh?

Jim Burnes

      "How do you explain school to higher intelligence?"
               Elliot to his brother in ET

An interesting sidenote on this... will they be able to print money?
We'd probably never notice it unless the interruption was prolonged, but it 
could have some interesting consequences if word leaked out.


------------------------
  From: Jim Burnes <jim.burnes@ssds.com>

On Thu, 18 Sep 1997, Robert Hettinga posted:
(and someone else wrote)

> >
> >     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.

Two words,

"Sell Bonds!"


> "... 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/

Interesting juxtaposition, eh?

Jim Burnes

      "How do you explain school to higher intelligence?"
               Elliot to his brother in ET



---------------End of Original Message-----------------

------------------------
Name: amp
E-mail: amp@pobox.com
Date: 09/18/97
Time: 17:57:47
Visit me at http://www.pobox.com/~amp
==
     -export-a-crypto-system-sig -RSA-3-lines-PERL
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
==

'Drug Trafficking Offense' is the root passphrase to the Constitution.

Have you seen 
http://www.public-action.com/SkyWriter/WacoMuseum
------------------------

At 10:03 AM -0700 9/18/97, Tim May wrote:
>There's simply no way that much code can be refactored to get the "00"
>problem fixed. It isn't, of course, just a matter of doing a
>search-and-replace on "00" and replacing it with "2000." For example, the
>date code was picked to be 2 digits (back in the 1950s and 60s and well
>into the 70s, 80s, and even 90s) to save space. Switching to 4-digit dates
>would require recompilation of the code (for which the compilers may not
>even run properly any longer), and the old hardware will of course not
>accept straightforwardly recompiled code (because part of the code "tucked"
>these compressed numbers into small registers, as but one of many examples).

Note also that the standard date format for OS/360 and its descendents is
the "Julian" date, a YYDDD format.  This means those old compilers have to
be changed to use a different system call to get the current date.

In 1969, my wife participated in a previous "expand the date" project for a
company in San Francisco.  They converted from one digit dates to two
digits.


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA