Reg versus Premium Fuel experiament in 09 PT Cruiser

Different industry, different priorities. Almost none of the Y2K
problem was in control systems, embedded systems, or the like (a
mailling list I'm on was considering creating "Certified Y2K compliant"
stickers to put on our pre-electronic engine management cars. We were
also considering "Warning: this automobile has not been tested for Y2K
compliance" stickers to put on cars on used-car lots, but I digress).
It was almost all in the financial, insurance, and government-regulatory
etc areas.

But even given that, I'm not quite sure why you think waiting until your
bank was suddenly in regulatory non-compliance on 1/1/2000 and starting
to fix it then would have been better than spending a couple of years
getting it fixed so the customers (and more importantly, the regulators)
didn't notice -- the fixes had to happen in any event, the only issue
was when and how panicked.

As for your ATM example: if you'd been the manager in charge of the
software for those machines for your bank and they'd quit working on
1/1/2000, you'd have been looking for work by some time early that
morning. And firing you would have been the vice-president you report
to's last official act (with probably several layers of severed heads in
between) as well. The only things more important than keeping uptime
for customers are backup and regulatory compliance (and in banking,
regulatory compliance includes backups).

Nor on my machines. But (1) my machines don't have anything major on
them by the standards I'm describing, and (2) everything had been fixed
in advance -- which is the point.

 

Hah! If you can show me where to find one. Except, I do own a 1942
Gravely that has points in the magneto - never used a timing light on it
- always followed the book on statically timing it.

Of course, as you no doubt know, when you get metal transfer, you get
peaks and valleys on the points and then feeler gages (or a 3x5 card)
don't tell you anything with any accuracy.

 

The problem was the many data files that still contained a 2 digit
year. All those files had to be converted.
And any program reading them had to changed and compiled or
assembled to accommodate the new file format.
Even if the program did nothing with the date.
Yes, there were - and probably still are - assembler programs running
in major apps. I was called recently about taking an assembler job.
If you think about how much of business data contains a start date -
birthday, policy, account, etc, etc, etc, and the old data files with
2 digit years, it's pretty easy to see the scope of the problem.
Those data files had to plugged with 19 before the calendar flipped to
20, and of course everything had to be tested up the yazoo first.
Most stuff was addressed well before crunch time, but there was plenty
to do in the last 2 years when push came to shove.
DB2 - the major mainframe database - was designed with 8 digit dates,
so presented no problem. It was all the old tape and disk files and
the programs that touched them that posed the problem.

--Vic

 

Yeah I haven't put a timing light on a small engine much either and I'm
not sure if points and magneto behave the same as points and coil as far
as wear patterns.

Well i did say observe not use a feeler gauge. Also i expect to some
extent the metal transfer also produces some porosity which takes up
more space than the original metal and may account for some of the
closing of the gap.

-jim

 

That was my impression, though I admit I haven't researched the issue
thoroughly.

 

Yep. The fact that those in the business knew it was coming long
before the public caught on didn't hurt either. Now the "general
wisdom" is that Y2K was a "boy who cried wolf" scenario, when actually
the wolf DID arrive, only to find wolf-proof brick walls and cranky
called-out-of-retirement COBOL programmers with shotguns (they're
mostly safely back in retirement now, in a better position for the Y2K
money...)

 

Not going to be a big problem. The time_t type is 64-bits on any
modern Unix system. Even Windows uses 64 bits.

I make no promises for Y10k.

 

And said fix will be a bulb which relies on the incandescence of an
electrically heated metal filament immersed in an inert gas sealed in
a glass envelope. Sure, it uses a little more energy, but it's SAFER,
and more ENVIRONMENTALLY FRIENDLY don't you know

Unfortunately GE gave up their research into high-efficiency
incandescents. I think Phillips is still working on theirs, though,
both the quartz-capsule HIRs inside a standard bulb envelope and
exotic filament treaatments.

 

Unix systems got bit, just not as much. I ran into one... a version
control system which would corrupt the database if it was ever run
after Y2K. Repairing that (proprietary and undocumented) database to
the point where we could get the code out of it was not fun. I wish I
remembered the name of the VCS so I could denigrate it properly, but
the company is long since out of business anyway.

 

I think your date of 2012 is correct for the Maya predictions. There was
another
prediction recently which claimed a disaster event for 11-11-09. On that
date I
will watch "Law and Order", most likely, and go to bed.

 

I did some cleanup work for some people who had a realtime factory automation
system written in COBOL running on a VMS machine. Don't ask how it got that
way.

Updating VMS to V5.5 fixed all of the OS-related Y2K issues, none of which
really mattered anyway since none of the code used the system date. The
code, however, accepted a human-entered Julian date in the form of two
digits for the year, then three digits for the number of days since Jan 1.
It treated the Julian date number as an integer and the only acceptance
testing it did on the date was that it couldn't be lower than 85000. Which
of course was a problem when the date turned to 00001.

Nobody had any of the source code for this mess, so I patched the binary
so it compared it with 0 instead of 85000. Problem solved. Actual coding
time about 10 minutes, time to figure out what the code actually did (a
combination of the operators really having no clue how the system worked
and a lack of documentation) about two weeks.

If I'd had the source code, it wouldn't have been a big deal to fix it
so it calculated the actual Julian date from the system date, but I really
didn't want to work with this stuff any more than necessary.
--scott

 

I have HIR's in one of my Concordes. Apparently they haven't caught on
yet. I think they even quit making the hi beam (9006) bulb in it. But
I do have a spare on the shelf (actually was planning on putting that in
my second Concorde, but haven't gotten aroundtuit since the headlight
assembly has to be modified slightly to accept angle-based bulbs).

 

Hah! Yeah - that one's really got me worried. Something tells me there
will be bigger things to be worried about by then - or maybe all
problems will be over by then.

 

Well that whole theory that a tankful of leaded fuel protected the
valves forever was crafted in hindsight, after it became clear that old
engines were not burning valves with unleaded gasoline as had been
predicted.
If you do research you might look at the studies done by those who
build engines designed to run on LPG. What those studies demonstrated
is that soot makes some difference in wear on valves. Hardened valves
were used in LPG engines long before they were used in gasoline engines
because LPG engines eat valves more than gasoline engines. The reason LP
gas engines erode valves faster is because they burn so cleanly. The
valves erode because of the clean metal on metal contact. Tests have
shown that you can counter the valve wear problem in LPG engines by just
burning a tiny amount of oil along with the LPG. The soot produced
protects the valves. It should be obvious that 1960's gasoline engines
did not have this problem of burning fuel too cleanly.

If you do your research you will note that the tests that showed the
benefit of lead were all done under very extreme conditions where
engines were run at extremely high rpm high load conditions. It has
never been demonstrated that lead makes a noticeable difference in valve
wear under normal driving conditions.

Where TEL did make a clear difference was in oil refinery economics. It
allowed the oil companies to produce and sell the mix of products that
maximized profits. In simple terms, it was a way to increase demand
plus lower production cost.

Another big difference that has resulted from removing lead from
gasoline is engines last longer without lead, oil change intervals can
be made longer and spark plugs last considerably longer. Those changes
have been documented in side by side comparisons of the same engines on
the 2 types of fuel. Those differences are directly related to removing
lead from the fuel and not changes in engine design or changes in
materials used.

-jim

 

http://news.yahoo.com/s/ap/20091011/ap_on_re_la_am_ca/lt_mexico_apocalypse2012

 

I think your date of 2012 is correct for the Maya predictions. There was

The major disaster that will happen on 11-11-09 is that almost everyone will
forget the anniversary of the armistice. People need to remember what happens
when countries get embroiled in badly-thought-out wars. That's what the day
is all about...
--scott

 

My personal feeling, based on observation, is that the world was and is at
much greater risk due to unspec'd, untested & unverified software being
hacked out in third world countries than anything we could ever conceive
related to two digit date years. All that Y2K hype sure did keep a bunch of
SW people employed for a year or so though.

 

What the Y2K hype did was cause a lot of people to go back and go through
some of their old code and do documentation and maintenance work that was
years if not decades overdue.

People who get badly-designed and badly-tested code from the lowest bidder
are indeed a problem. But people who think they don't need to do spend money
to properly document what they have, and don't think they need to spend money
to keep what they have up to date, they're just as much of one.
--scott

 

With all due respect, Scott, we get badly designed and poorly debugged code
even
from MicroSoft.

Windows Vista sucks buffalo whangs.

But I know what you mean.. Our VP in charge of communications cut a deal
several
years ago with Lotus for our corporate software. They paid $50 per user to
Lotus,
and this was some of the worst software I ever saw. After several years of
bitching
and groaning, the Lotus software upgrades brought it into respectable
performance.
Then, the Information Services jerks cancelled it and bought Microsoft.
This caused
a LOT of older data, reports, etc to move quickly to incompatible formats.

I have one personal computer running Linux and using Open Office. I may
never buy
another Microsoft based OS or bit of software if I can help it.

 

You say it like you're disagreeing.