All that 20 or 30 year old code that had been written on the assumption it would be long gone before two digit years became a problem (including the main ERP software I was running at the time).
It's the end of the working week - for most of us. Time to kick back, brew a morning cuppa and delve into this week's On Call, our weekly readers' column of tech traumas. This time, we meet "Ted", who tells us about a time he worked for an outsourcer in a government department that got into a pickle over licensing for a very …
When I studied programming at university in the 70's my lecturer emphasised that software we wrote then would still be in use at the turn of the century so we must always use 4 digits for the year. When I tried to implement this in my student placement the next year the senior developer I worked for refused to let me use 4 digit years as 'we can't afford the storage and anything you write will be replaced in a couple of years', Roll forward 15 years and I rejoined the organisation as the tech support manager. The suite of programs I had written as a student had been altered significantly but were still in use, even better the code base had been so stable it hadn't been looked at for over 5 years, unfortunately it still had 2 digit years, The suite was a feed from line of business systems into the finance application so failure would have stopped all financial processes. During the period the organisation had moved completely away fro COBOL and the only 2 people in the organisation who had ever programmed in it were myself and one of my sysprogs needless to say she did a fantastic job and the issue was mitigated well before the millennium. The irony was that the senior dev was still there and was responsible for the core finance application. Come the millennium all the line of business systems carried on working, the feeds executed perfectly but the finance system stopped because the cockwomble had not chased the supplier for the service pack required to make the core system y2k compliant. AC to preserve the reputation of the organisation I'd happily embarrass arrogant idiot who brought us to our knees for 48 hours while we had to fix his mess.
I graduated from highschool in 2001, I love these stories because they remind me to cover my ass every time someone forces me to do something unmaintanable because it's "only temporary". NodeJS as a whole is the worst example of this package changes or just NPM being down can kill your build within months, god nows what it will be like in 5 years, let alone 10 or 15.
I have actually read a story about one (and only one) use case wherein something being unmaintainable was absolutely fine.
There was a system that had to do some precise math - some very, very, very, VERY precise math - on some rather cheap (for its use case) hardware, with next to nothing in the way of storage. It had to do this math blistering fast, repeatedly, very very quickly.
It would fill up all its storage and RAM and overflow and completely crash out and go FUBAR in a very short amount of time - on the order of about ten minutes or so.
A sharp-eyed new hand on this development project foresaw this problem, brought it to the attention of the lead of the project, who agreed that yes, this overflow and crash-out would indeed happen in roughly the timeframe the newbie had calculated, good spotting that.
The newbie asked when they were going to fix it, and how.
They were not, the lead said. It was absolutely fine.
The newbie boggled at this for a moment. The lead asked the newbie if he had taken the time to recall exactly what it was that was doing all this blisteringly fast, accurate math.
It was a physics system. That was part of the guidance package, of an air-to-air missile.
The computer would overflow and freeze up in about ten minutes. The missile had a maximum flight time of about eight, with an average engagement time of under two minutes or something.
Oh, said the newbie. Yes, that would indeed make the overflow irrelevant.
(All numbers pulled out of my arse because this is just my recollecting a story that may well have been pulled out of someone else's arse a long time ago, and are for illustrative purposes only.)
In the early days of Rails I remember someone on a forum saying 'I like the look of Rails but I worry about its long term maintainability'. Let's say that this was in March, it got an arsey reply saying 'huh, you don't know what you're talking about, I've been using it since November and the maintainability's fine'.
Except that when many of these systems were written, a byte (called character at the time) was most likely 6 bits. Even when the term "byte" was introduced, it was defined as "The smallest addressable unit of storage), by which definition I have used machines with 1, 4, 5, 6, 7, 8, 9, 12, 16, 24, 32, and 60 bit bytes. Most of those would have no trouble stashing a number > 200 (C'mon, who expects to live past 2100? Other than those who have met pretty spry people in their 90s), but not all. Time is hard.
"Byte" became synonymous with "octet" in the same way the "baud" became (equally erroneously) synonymous with "bit per second" about the time (and probably due to) the proliferation of Personal computing, and the notion that "Every computer in the world works _EXACTLY_ like the S-100 box I built from a kit".
I wrote assembler for all those machines.
CDC6400, 6600 and 7600 were 60 bit machines - with 10 6-bit chars in each - or, with huge struggles, 12-bit punch card column images (don't try that at home).
PDP-8s had 12 bit words, and also used 6bit chars.
NO ONE EVER called a 6-bit char a byte. If you did, IBM would probably have sued your pants off. IBM had 8-bits. everyone else did not (until 16-bit machines and Unix).
None of the above machines had any standard way of inputting 8-bit bytes. Nor was there much agreement on how to read 7-bit or 9-bit mag tape - the only agreement seemed to be "Don't use the IBM card punch codes or EBCDIC" - but then again, most sane people would agree not to use EBCDIC.
The ASR33s connected to them processed 8-bit character patterns - but mostly by discarding at least two bits. You either had all lower case (Algol) or all upper case (FORTRAN, COBOL). Of course, real British computers used 5-hole baudot punched tape (Numbers, numbers, letters, letters :-)
Yes, we had IDRIS - UNIX in ALL UPPER CASE - and my ears till hurt 50 years later!
Actually, most business software at the time often implemented integers including dates as Packed Binary Coded Decimal, storing one decimal number in a 4 bit nibble, so two digits in a single 8 bit byte.
This was the case for a lot of COBOL and RPG programs, two of the languages most often used for business applications.
Many machines actually included instructions to do arithmetic in packed BCD, including s/360, VAX, Burroughs, and even the 68000 (this list comes from Wikipedia, but I knew about s/360 and VAX).
Other systems using 12, 24 and 36 bit words would store 3, 6 and 9 decimal digits in their word. Some of the 24 and 36 bit word length systems also used 6 bit characters, with 4 or 6 characters encoded in a single word.
Honestly, youngsters today, No sense of history! They think x86 is the be-all and end-all of processors.
If you wan to save memory space, you use a byte for the year.
But then you need a bit of software that runs every time you need to use the date. Like I said, old microprocessors don't have a lot of space to keep these conversion functions....and also, it's going to slow things down, on a processor that is probably already running flat out.
"To be fair, the two bytes that you saved by only using two digit years was frequently important in the early days of microprocessors and memory sizes of 4K (including OS)."
Why would a 2 digit year need 2 bytes? You can store -32768 to +32767 in two bytes. That should cover for most date eventualities. Day and month and year will fit nicely in a pair or bytes. At least that's how dates were stored on the video rental shop application I wrote to run on a 48KB TRS-80 back in the day. This had no chance of being used beyond 2000 so I used 4 bits for month, 5 bits for day, 4 bits for year and the remaining bits for status flags rented/not rented, overdue. (I thought a 16 year lifespan for this app was being a bit generous)
I remember spending a long summer in the early 90s re-writing hundreds of COBOL modules of an ERP system to be Y2K compliant. ISTR that they kept 2 digits on the input masks and database and used a sliding window technique to work out the century part for reporting and prefixing dates on the forms.
Yes, early 90s. My employer saw the event coming and wanted everything in and tested long before the final date.
I see it used a lot these days by leavers as a reason why Brexit won't be bad.
"It's all project fear! Remember Y2K? That was a load of made up rubbish too, why should we believe anyone who says Brexit will be bad?".
Naturally you can't reason with these people and point out that Y2K wasn't a disaster because a lot of people worked (and billed) a lot of hours to sort it all out. They just call you a brainwashed remainer or something.
My partner's elderly stepfather tried that one on me. He quickly became very quiet when I explained to him that, as a seasoned software developer who happened to be around before the turn of the millennium, I had first-hand experience of why what he was saying was bollocks. He then tried to claim it was Thatcher who took us into the EU (then EEC), before I politely pointed out that we joined some six years before she was elected. I don't blame him for having these ideas, they've been drip-fed into people by the right-wing media and weasels like Farage, Johnson Gove, Rees-Mogg et al.
Interestingly, of the three people who I personally know who voted to leave the EU, he and one other have now changed their minds. The remaining one lived on sick benefit for 20 years for a purported back injury that mysteriously didn't manifest itself when riding motorbikes, and is known for having such "clever" ideas such as not paying for electricity and getting a diesel generator instead (you can draw your own conclusions about the honesty and intelligence profile of this individual). I know this isn't a statistically significant sample of leavers, but I can't help but think it's probably representative.
"if I adopt your logic, [nearly] everyone that voted remain is clever, has very strong morals and goes to church/synagogue/mosque regularly..?"
That's how "opinion polls" usually work, isn't it? Make some unjustified/unsubstantiated assumptions about the population as a whole, ask a few people some questions, and scale it up to fit the client's desired answer.
On the other hand, I think it's fair to say that everyone who voted and everyone who didn't vote was massively lied to by politicians and businesspeople and other malcontents. I'm sure there'll be a special place in Hell for the significant ones, but I'd really rather the public saw those people getting their rewards before very long, pour encourager les autres.
I'm selfish, I VOTED remain, for the reason that even though it was against my personal benefit, the overall cost to our society would be reduced but worse in the long-term and my business would be negatively impacted the least, through the foreseeable political infighting.
However, as the proletariat has spoken, and we're not any time soon, returning to the Hanseatic League or Zollverein, then I reckon a bit of light Benedictine 2.0 wouldn't go amiss. Would you believe we invented fizzy wine as well. Left on the docks on a cold day. #devilsbrew #itsnotmeitsyou
Considering the lies were flowing hot and heavy from both sides, it's safe to say they cancelled each other out. People vote the way they want to vote, even if they later claim otherwise. I always find that when someone says "They only voted that way because they didn't properly understand" or "They voted against their own best interests" that it's the person speaking that had the real problems. The problems are the vote didn't go their way and they can't comprehend that other people have different opinions and different priorities than they do.
Can I play?
"Clever" in the Yorkshire meaning of the word. Whose morals, Kemosabe? I'm terribly sorry heathen, wrong church/synagogue/mosque; kindly report to reprocessing.
(As a Yank, I don't really have a dog in the Brexit race ... but I rather suspect the actual answer lies somewhere between the two extremes of the loudmouths. Kinda normal for human political theater, no?)
There's no such thing, it's a bit like going to the pub and being miserable.
With regards to Yanks and hand in the game, its usually a team effort I'd wager; language, measurement, science and of course technology. You just have more through scale, though not necessarily efficiency. #ricardofaithful
Nah, if they were clever they would have SHOWN UP AND VOTED. Only 37 percent of the British electorate voted to leave while 35 percent voted to stay. 28 percent were so clever they stayed at home. When you don't vote, you are agreeing to whatever gets decided, and don't have the right to complain if it doesn't go your way. The vote is valid because everyone had a choice on whether or not to vote, and it was so well advertised even we on the other side of the planet knew the vote was coming. Our media wouldn't shut up about it before, during and especially after.
If you didn't like Brexit and didn't vote, let that be lesson to you next time a vote comes up. I have no dog in that fight, but I think Britain will do a lot better out of the EU than in although it's going to be a rough couple of years until it's all sorted out.
Depends what you mean by EEC and EU. Thatcher certainly signed the Single European Act in 1986, which most people would regard as the beginning of the EU as we know it [free movement of people in particular]. There was no vote about that, as I recall. any protest would have been drowned out by Thatcher! [Yes, that is sarcastic!] And, it is worth noting, people tend to vote after thought and should not be blamed for the childish debate conducted by Cameron, Farage and all the other "names" - greatly assisted in ignorance by the "meejah" and press.
Y2K wasn't a disaster because a lot of people worked (and billed) a lot of hours to sort it all out
Including me - did Y2K testing for everything from Windows servers to firewalls (via various flavours of Unix).
Then most of the y2k projects ended and dumped lots of minimally-capable people out into the contract market and rates hit the floor (I was charging £40/hr in the late 90's - when the y2k glut happened I was lucky to find a contract with rates of £15/hr). At which point I went permie again (by blagging a job doing Solaris and networking supprt even though I'd done very little of either before..)
Yet it's still widely reported that Y2K was some sort of myth rather than a period in which lots of people worked really hard (and made pots of money).
Worked really hard. Check
Made Pots of Money. Negative
I made sure that every single computer in what used to be one of the largest IT department of any government agency was completely y2k compliant, This not only included departmental computers but in many cases the personal computers of ministers, secretaries (the under/permanent ones - not the typists) and their various researchers etc. All in all, a truly mammoth task achieved with 100% success rate.
True to form though, we were "required" to be on call on NYE. If I recall correctly, we took about 20 or so prank calls from drunken bureaucrats asking us to fix their computers, each request was carefully logged and a an internal cost notice for £5,000 submitted to each drunken idiot's immediate head for on-site emergency attendance in the early hours of 1st January 2000.
As part of a pre-Y2K exercise I did a bit of work with a worldwide outfit doing remote management of relatively simple onsite equipment with no onsite support (what would later become known as M2M comms; back in those days it was being done over dialup, RF modem, and X.25, ie well before the days of broadband and IP, never mind IoT).
By 1998, maybe earlier, their installed networking kit and associated software and newtorking had already been investigated and the architects and engineers were convinced hat even though it was a bit long in the tooth it would be OK.
Some of the older kit didn't have pieces of paper from the vendors to satisfy the supplier's purchasing and legal teams, but the techies had considered that, and decided it was a more acceptable risk than ripping it out and redesigning.
Then with maybe a year or less to go, the legal+commercial folks decided anything that didn't have a vendor piece of paper saying "trust me, it'll be fine" was to be replaced, ASAP. This M2M network was one of the victims.
The paper pushers would rather something known to work, something that had been working for years, was ripped out and replaced in the space of 6 months by something that hadn't even been specified (let alone architected, written and purchased and tested and rolled out globally).
That was when I started thinking that it might be a good idea to have my own arrangements for backup electricity supplies at home, just in case. It looked to me and others that in the event of an ordinary routine failure in some important systems e.g. utility supplies, in a period of maybe 24 hours either side of the big day, the boardroom paperpushers would be calling in the lawyers and blaming it on Y2K, rather than following the usual route of getting the C+I/SCADA (or whatever) people to do their usual magick.
Times have changed.
I hope all those internal cost payments paid for a serious office party on expenses to make up for it?
(I'm assuming they were indeed paid and said drunken idiots were given the bollocking they deserve even though this is the Civil Service and they were likely knighted for their services to pissing off the plebs)
It was less widely reported that some UK supermarket chain ran into a problem some time in 1996 when they received a delivery of tinned beans with an expiry date in 2000. They kept changing the expiry date down to December 1999 for a few months until the software was fixed.
"Loans and mortgages that have 25 or more years of life in them were seeing the Y2K "problem" by 1975 or sooner."
I remember reading of a company being asked to tender for software to manage a property registry. Their proposal mentioned 4 digit years as Y2K was approaching. The prospective client said they didn't want that. The company noticed that the spec mentioned leases running back into previous centuries. They decided not to tender.
There was the story of one insurance company who was _mostly_ Y2K ready. The only problem was that they couldn't handle people who were burn and lived in _three_ centuries, like born in 1899 and still getting a pension in 2000. They found they had 14 cases, so instead of changing the software, someone got the responsibility to handle these 14 people manually.
If two digits were stored for the year, and it didn't have any years earlier than "65" for instance, you could add a bit of logic to do "if year < 65 then fullyear = 2000 + year". Before someone says "what about birthdates" anything that was written in the dusty deck era would have had to assume the possibility of people being born prior to 1900 so would have have had other issues with a two digit year.
Of course Y2K provided a great excuse to rip out the old equipment, if someone had fixed it then you'd never get upper management to agree to replace it. I often wonder how much of the economic boom in the late 90s was due to Y2K spending - and how much the recession that had already begun prior to 9/11 was due to "all our equipment is brand new, we don't need to replace anything".
My grandfather, who lived to almost 102, had an argument with his life insurance company as they wanted him to cash in his policy and, for tax reasons, he didn't want to. Turns out that the problem was that the age field in their database system only allocated 2 digits for age.
Given how expensive it would be for them to redo their systems, he could have held out for getting double its value as a payout, which would pay the taxes and then some. Everybody wins :)
Though assuming they no longer sell those whole life policies or don't sell them to minors they could have just assumed anyone under 10 was 100 + age...
I'm on the other side of these conversations. My company sells permanent licenses for software but issues activation keys with expiry dates. The keys are somehow linked to the maintenance contract. It makes no sense and the bosses keep contradicting themselves about what the rules are.
So one day in a meeting the conversation came around to how to force users to upgrade. A boss said that we could do it via the key expiry date. He asked me what we would do with a request for a key to a Jurassic version. He wasn't impressed when I said that I would do whatever was necessary to get that client a key.
Software is weird.
Well, that's why I refuse to (personally) use any software that comes with any kind of "fuel"* that needs to be "topped up" periodically even if it insists it's free and will always be available. It's just voluntarily putting on a collar with a leash somebody else is free to tug on** any time.
* actual real-world example.
** you better be a latex-clad dominatrix if you want to try that with me
Yeah, I've purchased "perpetual" licences with key expiry dates in them lasting a mere 5 years. That supplier got dumped, just as we were about to order 7 figures worth from them, because of that behaviour. Lucky we check these things before placing large orders eh?
They also argued with us over how we were running it (on non-internet connected standalones with (deliberate) artificially high clock rates which meant that a day in the real word advanced the system clock by 1 month. so we hit a licence issue in just 2 months of running the test setup.) None of their business what my system does or how I've fudged it, I required a perpetual licence which means perpetual. not time limited.
Oh how that salesman cried. And oh how soundly I slept.
Oh how that salesman cried
Probably worth it just for that result alone. One of the sub-goals of any *proper* IT person is to make Sales and Marketing cry..
(Some say that there is an exemption clause for the S&M people in your own organisation. Purists like me disagree)
I had to threaten ligation with one vendor when I needed a new licence key for software we owned but had let the support contract lapse on. This was a deliberate act as we were in the process of decommissioning the application because of their piss poor support.
Their annual support cost was so high I used the budget to fund the replacement app and still made a significant saving and the business department affected had agreed that if there was a major incident we would probably be able to complete the commissioning of the new app before the original vendor would respond to the call. We had not used their support service for a couple of years as it was so dire and our own team had learnt how to bring it back to life after its frequent crashing and data corruption incidents.
Not Salesfarce but we have had arguments with a supplier over the last 2 years about them trying to charge us for either: getting them to correct issues due to them incorrectly configuring systems in the first place or them having to get another company to correct their mistakes...
"My company sells permanent licenses for software but issues activation keys with expiry dates. The keys are somehow linked to the maintenance contract. It makes no sense and the bosses keep contradicting themselves about what the rules are."
Perhaps you should enquire if they've checked with their legal advisors. It sounds as if there's a distinct possibility of it being considered fraud.
"The keys are somehow linked to the maintenance contract."
I had a client who reverse-engineered the keys because the vendor's maintenance was so dire. He reckoned I did a better job. Over the years I certainly dug out a few very peculiar things they'd done. That's apart from the things discovered right at the start such as the scripts to set up the system which had .sql suffixes and weren't SQL.
I ran into that recently with one of our 'small' apps- We are looking to migrate the app to a new VM running a newer OS AND upgrade the software in one go. The publisher recently changed how they issue license keys (which are tied to the support contract)- When I asked for a new key, both the sales rep and the support rep said 'oh, we don't do that anymore, as long as your contract is paid up you'll be fine.'
Then I told them what version of their software we are on, and what my plans were, and they magically decided to issue us a current, valid key, along with some useful instructions on performing the migration.
I had a fun situation when working for a media company many years ago. I used a program suit that had a batch converter for audio files. When the.company upgraded to the latest version of the program the batch converter ceased to exist. So I was looking at manually converting a hell of a lot of files on a Friday afternoon. Someone in IT support pointed out that we were technically still in posession of the software discs for the original version. Sadly we didn't have a license for it though the new version was using it. As a result I was told we couldn't use it as we were being FACT compliant which sucked for me. I said I'd call the UK arm of the company and plead with them to give me a license/key for just the bactch converter. I did just that one Friday afternoon and the bloke I spoke to told me I needed to make my explanation quick as he wanted to go to the pub. I made my case and he said he understood and would send the key for just the batch converter by email. I then asked about the license which we also needed. He said he'd write something official on Monday and shove it in the Royal Mail on Monday if I'd hang up so he could head off to the boozer.
True to his word on Wednesday a "license" arrived on headed notepaper. The compliance bloke in IT support wasn't very keen on it but grudgingly accepted it.
I miss the good old days where you installed a piece of software onto a server, confirmed it was working correctly, then just left it to it for months/years on end.
Nowerdays with regular security patching, poorer hardware/software etc. you can guarantee that odd reboots and other such issues will arise from time to time.
Years ago when I was with a different company, we found a server running as an additional domain controller hidden in the corner of a comms room at the opposite side of the building. Everyone had forgotten it was there and it hadn't been touched or rebooted for years - yet it was still happily working away without issue.
Then its dead as far as you are concerned.
All critical boxes need to be under support. If for no other reason than to remind management these systems exist.
If you cannot get a replacement box in 1 day then its dead, just just dont know it til the psu shorts and you find yourself explaning why the companies offline for 2 weeks and there was no backup plan
>All critical boxes need to be under support
As a Government tentacle, we have to abide by the cringingly-names "Cyber Essentials" - most of which is actually sensible rules.
One of which is "don't use software or hardware that's no longer under support except in in justifiable circumstances".
Said circumstances have to be approved by the auditor..
"And hardware dies after 10 years."
Nope. I'm currently working on replacing my old server - a secondhand user-grade PIII. The fans are screaming (bearings about gone), but otherwise working fine. It's been running continuously (except the occasional power outage and even more rare reboot) for about 12 years... after the original owner was done with it.
Sez you. I happen to know one place where the 1974 Cobol compiler is in *heavy* daily use sans problems.
Your bug problem only occurs in modern release into the wild before it's fully baked deployment philosophy, where its effects are magnified by the twin miracles of late binding and dynamic linking at runtime.
In the old days stuff worked and if it didn't it was fixed by a swarm of people in suits.
Unless you foolishly bought IBM of course.
Sorry to be a party pooper, but you are likely paying more in electricity to run that thing for 3 months than it would cost to replace outright with modern hardware. I have got rid of many old boxes that otherwise ran well for just this reason, in one case consolidating several kW of power hungry servers into a single i7 based system that is much more frugal and paid for itself in a few weeks.
llaryllama, it's a fun project keeping it running, and an exercise in teaching the yoof what things were like in the dark ages, back when you actually had to understand how the equipment worked. The cost of hardware upkeep, electricity and the minimal CPU (by today's standards) aren't really an issue. It's not like I have several dozens of these things in that co-lo. My machine room/morgue/museum/mausoleum (depending on the mood of the wife) is my real exercise in wasting BTUs ... how many times in the last two decades have YOU needed an IBM 1401 or System/360-20, Honeywell 316, Amdahl 570 or Burroughs B2500 at home? At least Baby, the 27 year old S/390, is still making money ...
Some people meditate. I collect and restore big iron.
I think the point of the original post was more "You can't rely on a specific piece of hardware running forever" rather than "All hardware has the same lifespan". In that sense, that is correct. Software and hardware never had a miraculous period where it would run forever. Some systems will run a very long time, while others would fail quickly.
"Thats never been the case, ever.
All software has bugs, some huge.
And hardware dies after 10 years."
Nowerdays, yes. However older hardware/software was generally better built IMO. These days, companies are too quick to release software knowing that they can easily patch it if there's bugs that turn up. Back in the 90s, this was far less common, and companies had to test their software more rigorously. Of course it also helped that software back then was simpler and less bloated which helped make testing more effective and the emergence of bugs less likely - the more code, the greater the chance of bugs in it, and the more effort needed to test it thoroughly.
As for hardware, I own an SGI Indigo2 (from 1995) that is still working fine. Plenty of these systems are still in commercial use today as earlier Indigo2s were commonly used to control expensive MRI machines. Hardware wise, they're built like tanks - a far cry from today's increasingly disposable hardware.
I'm still running a HP JetDirect print server. It's long since out of support because the official configuration software has a Y2K bug(!), but it keeps chugging along pushing parallel bytes to a LaserJet 5MP+. The pair will soon hit the quarter century mark.
(The installation is actually quite modern.. it's using the 10baseT port, not the 10base2.)
Expired licence checked only at startup? Sounds like a job for turning back the clock, starting the software, and putting the clock forward again. Mighht be able to get away with a LD_PRELOAD that overrides the time functions (for the first call, or first minute, enough to time to validate the licence) just for that process if the temporary time displacement might affect the other software negatively.
One place I know of supplies software and had the chance to get their system in to VeryBigCo, with the only issue being they refused to accept the license that was on offer. So, they sent their own "standard" license with a "use it or lose it" letter. The document was big, very big, but the supplier was small in those days with no funds for a proper review. The potential sale was also very big and would fund future development costs for years.
The contract was signed, money received and all was well... until the unexpected cheque for £lots arrived some years later.
"What's this?" the accounts manager said. "Strange, as they paid on delivery years back".
Someone decided to get the license agreement out, dusted it off and started to read. Page 127, clause 29.3.11 indicated that further license payments were due if the software was moved on to more powerful hardware. Roll on Moore's Law!
The company received may other additional payments over years before the customer asked to renegotiate the license :-)
PHB: 'This piss-ant little vendor wants us to accept a perpetual license agreement. Sounds too good to be true. It must be a trap. You there. Copy and paste the Oracle terms and tell them to accept a grown-up's license agreement or fuck off. This is why they pay me the big bucks.'
The document was big, very big, but the supplier was small in those days with no funds for a proper review.
Big customer, small vendor. Just the situation where a review is essential. They were very lucky in their customer.
We had three old AS/400 mini computers. The end user kept insisting that the data held within them was vital, but refused to pay to have it converted and transferred to a modern system.
It took 20 years to get them decommissioned. I think the breaking point was the H/W maintenance firm was unable to get the 2GB SCSI disks anymore.
I've been Redmond free at home for twenty years, and Redmond free professionally for coming up on ten ... except one lonely, airgapped Win2K machine that runs AutoCAD. It'll finally be allowed to sleep this Spring, when I should have all my old CAD files transferred & verified on the new systems.
Sometimes inertia is the easy way out ... even for those of us who know better.
Sometimes inertia is the easy way out ...
I'm a big fan of gravity, too, which can come into play quickly if a very heavy, overhead object topples toward the hardware in desperate need of recycling.
Paraphrasing the BOFH: "You cannot always wait for things to happen. Sometimes you have to make them happen."
"a very heavy, overhead object topples toward the hardware in desperate need of recycling."
If you're going to invoke the BOFH you have to remember that he'd probably do things more economically. Like have the hardware itself toppling towards a boss in desparate need of recycling.
Indeed. One of my many jobs at work is in the charity shop arm of the business, selling stuff on eBay; we acquired an old machine that sorely needed to go to the recycler, but the c. 20 year old (!) Foxconn motherboard, complete with a 120MHz Pentium 1, was still ticking away fine. Was even Y2K compliant and accepted a date of 24 Jan 2019 without issues. We sold it for nearly £100 on eBay!
virtualize an AS/400 (aka iSeries) on VMware/Xen/Hyper-V
Well - many, many years ago I had the (dis)pleasure of testing an S/370 emulator provided by MicroFocus (I think) on the basis that your programmers could bench-check their code before getting the actual mainframe involved.
I presented something that was curiously similar (though actually unalike) and S/370 machine. Sadly, ever attempt to try to run TPF on it crashed the emulator. We did (sort of) later get it to work, but only by making enough changes that the programmers code no longer assembled properly..
Also, I suspect that IBM (our supplier of PCs, networking, printers and mainframes at the time) got wind of the project and Words Were Said to our senior management - at which point the project became a Non-Project and also A Project That Never Had Existed.
I've been at the same place for 19 years. The first year a department bought a new version of their primary software but refused to bring the data over from the old version. 6 years later they did it again. Now we have 2 old systems just sitting around for the times when historical data is needed. One of these days one of them isn't going to wake up and the wailing and gnashing of teeth will be epic.
Luckily I have multiple email CYAs - not that we still won't be blamed for any failure of course. ;)
Did I mention that the original developer was a one man band and he died? Without the software being put in a repository? Oh, and this is our legal department too.
And in light of that - Anon.
This sounds very similar to the recent issue with a Cybercurrency archive where the only person with the passcode for the external wallet (Containing $millions ) died, taking the password with him to the grave. I suspect management is currently trying to contact him via medium :)
The piece of server software that covered the majority of sales when I started work was OS/2 based, and towards the end of its life licences were issued by one OS/2 machine in the US. It became increasingly difficult to get licences as the machine obviously wasn't well maintained or documented, and the supplier hadn't bothered to port the licensing software to Windows complete with OS/2 support, when the server software moved to NT.
Poor show, especially considering it was per seat licensing, each one was not cheap, and there was a healthy reseller margin included. For receiving a fair bit of money for not doing very much, the process really should be as streamlined as possible.
We used to sell software with licences linked to the HW ID. We once got a support call from a customer who'd had a board replacement on some very old (but still supported) HW and needed a new licence key for an old application. The problem was that the entire team who had managed that licence software had been laid off years before, when we gave up on that model and stopped selling those products. Their systems were long scrapped.
Happily someone remembered that I had been doing the client-side work for many of the licensed products, and called me to see if I could help. To simplify the dev and test process I'd once persuaded the license centre guys to give me a bootleg copy of the tool to generate keys, after swearing cross-my-heart to only ever to use it for lab testing. Much excavating in decade-old email folders turned up the tool & the instructions, and a new permanent key was generated for that customer. In the years that followed we had a few other cases like that.
Never delete old tools, you just never know when they might be useful!
"Never delete old tools, you just never know when they might be useful!"
Got that right ... I have been known to fix decades old machines with code I carefully tucked away when they were new. I've got stuff dating back to the late 1960s, "just in case" ... including obscure firmware. If I did what I do with code with hardware, I'd be a hoarder of the worst imaginable kind. It's almost a neurosis ... but I'm the guy "they" call in an emergency, and it sure pays the big bucks.
If you do certifiable work for aircraft/spacecraft you have to be able to produce hardware/software for the 30+ years of service. OK, you can upgrade the LRU (Line Replaceable Unit) to a newer version that is FFF (Form, Fit and Function) compliant for new supplies, but you still have to be able to produce identical binaries for the old systems and have retained some representative hardware to test it on.
If there is a crash and the FAA, etc. come knocking on the door, they may want you to prove it did work as intended when new, or worse, make you fix a bug from 20 years back.
There are many companies with store rooms full of very old PC kit, hardware dongles, components, etc. all stored in nitrogen, just in case. Yet another reason why your military or aircraft kit cost so much more than the retail equivalent.
(I personally know someone who has to practice their core memory fixing skills for a yearly test, just in case!)
Anonymous, as I used to work for a company that threw all the old kit out during a weekend soon after a takeover. Our protestations to the new senior management once we found out were to no avail as it had all been shredded!
The fun really starts when the original supplier goes down, takes the activation server down with them and you need to work out how to generate your own keys to get the thing working again for a reinstall.
If you're lucky they bought their license solution in, it has an SDK and you can find the right magic numbers in the installer to roll your own key. My favourite bit of that is I think it actually worked out quicker to do all that than the original email ping-pong for getting a key.
We have an Archimedes (yes, from the 80s) that still sees use testing equipment that comes in for maintenance.
Its running software to do the testing, and we have no way of moving it to a more modern machine.
Though I hear that there might be a new re-write of the system to remove the dependency on a machine for which we have no spares... sometime...
Similar situation at a previous employer, using a well-known engineering package. The business wanted to expand a cluster of servers which were a slack handful of versions out of date and needed license keys. Vendor reluctantly agreed to provide after hauling their key generator out of cold storage and getting it running again, on the proviso that the new servers were only for reviewing old files and NOT going to be used for production-level work. Appropriate promises were made, but I'll leave it to you to estimate how long that particular caveat was respected for...
Visited a small engineering company last week, to review their request for an order management system.
The current system is using Lotus Approach - the about screen showing 1998 and references to 'Year 2000 updates' (from memory - seems a bit early to be thinking of 2000). So it's been in use for 20 years.
It's still running and the advice was "If it ain't broke, don't fix it".
To be fair - it is running on a Windows 7 machine - so something has been updated in the meantime.
We are going to fix it though - they use QuickBooks and there are add-ons which do all they want, integrated into QuickBooks. So recommendation is to move to this.
I worked in a small engineering company about 10 years ago and they had a DOS machine running a specialist software package linked to a handheld colour scanner in the QC dept (I'm thinking spectrometer but not 100% sure).
Until it broke one day I didn't even know it existed, no network connection so it never showed up on scans.
The HDD had some bad sectors which a VCR scan with remap fixed and it booted back up. I recommended an upgrade but the software cost was in the £thousands so no go. I did P2V into VMWare Player just in case though.
They probably still use it.
I used to manage a "Beowulf cluster" that was actually 80-odd Pentium 4s independently running windows and some specialist actuarial software, each taking a segment of the customer data we needed to model (using a master-slaves type deal). We had plenty of licenses, and helpfully the license check was only done at startup by the Master.
Unhelpfully the licenses were done with hardware dongles and the actuaries (who developed the models and ran local tests to confirm results) needed them too. Over the years, more and more of the dongles had gotten lost (or obsolete - we had a mix of USB and parallel-port dongles) and since the cluster only needed dongles for the "masters" we gave some of them out and slowly reduced the pool of potential master machines. All the ones left were using the older style dongles screwed into the back of the machines.
Then, one day, we had an upgrade, and every machine needed to relicense. Not wanting to get behind the racks, I managed to score a few spare USB dongles someone had hidden in their desk "because it's so hard to find them when we need them", and spent most of a morning plugging them into four machines at a time to do the startup processes.
How about this workaround to get the business back on its feet again
1. Change the date back on the system to a point several years ago.
2. Reboot the server / restart application. Licence product will probably come up OK
3. Change the date back to the correct value.
4. Talk to vendor to get a longer term fix.
5. Talk to management about resolving the issue permanently.
People did strange things in the early 1980s. This was a machine control system based around a TMS9900. No source code of course. The "woodpecker" function had failed. This is a function in which a drill is progressively inserted deeper and deeper withdrawing each time so it gets swarf cleared and lubricated. Yes there are the expected jokes about it.
I used to be able to write TMS9900 assembler in my head so took a dump of the eprom and had a look. No sign of a cycle with varied timing.
To cut a long story short, the designers of the thing obviously hadn't understood the use of interrupts and the timers and had built an analogue circuit using a unijunction transistor, which had failed. It was more or less unobtainable but the circuit was easily redesigned using a PUT.
At the same company, three years in a row the MRP supplier failed to deliver a new licence till two days after the old one expired, despite having been paid, and then were shocked when we migrated to a more modern system run by people who could get their act together. They were mainly shocked because we were able to extract their database instead of paying them £1500 a day to do it.
This is why DRM is never acceptable. Imagine if the original software company was no longer around?
You would have to pay for a reverser to patch / crack the binary? ;)
I hope the software company was billed for lost earnings due to downtime whilst their erronious license was dicking around.
Likewise always assume that temporary means permenant.
This includes locations of downloaded files that have been placed in a temporary directory until I can think of somewhere better, temporary one-off scripts to fix an imediate problem, and the temporary location of last weekends curry that I was planning to reheat.
"The root cause was that the previous expired key was only for five years – "the software maker was assured that the software would be decommissioned soon"."
But they PAID for a never expiring license so you give them one. You don't make it expire when they've paid for a never expire one.
... that time when I saved the company's bacon virtualizing a very old, 'we need to keep it running until we can get the last two apps off it' database server that used to a two node cluster with a shared 'smart' storage array between them. It was running SQL 2003 on server 2K3. The hardware was out of warranty and support, and in examining the storage array I found some very alarming risks- the fool who built the cluster used a single disk for both the quorum and DTC drives instead of mirrored pairs, which meant that the entire cluster was a single drive failure away from total failure. Once I pointed this out to management (and after one of the two nodes failed), I got the green light to virtualize the remaining node in the cluster. It took three tries to P2V the machine. The first attempt failed courtesy of a disk failure on one of the raid arrays, the second attempt worked but produced a non-viable machine that we ran out of time on the change window trying to correct. Third time was the charm, thankfully.
I left the physical hardware running but disconnected in the event we needed to pull something from it post- change, which lasted exactly a week until the failure I had warned them about occurred (quorum drive failed, taking out the cluster).
We had a vendor who assured us that the SW of a rather important government system did not have an expiry date lock. However, one fine day, it all stopped working. With the new copy, we got another assurance that there is no expiry date lock. Having learned a lesson, we used a GPS constellation simulator to crank the clock forward until the system locked again. We took a screen shot and sent it to the vendor...
I was in my last year of school, 74 (see what I did there) and was watching a TV documentary about this looming problem that was going to happen just 60 seconds after 11:59pm on 31st December 1999 and how it needed to be fixed before then otherwise it would cause all sorts of problems. Now remember that this was way before Personal Computers were available but it was a widely known problem 26 years or more before in the industry since hell, there was a TV doco about it.
Fast forward many years and we have the "great panic" with retired coders lured from retirement to save the world from mass destruction (ok, the dramatic exaggeration is my poetic licence), planes falling from the skies and those litter bugs plus creating a nuisance criminals were going to be prematurely released from prisons (possibly along with the father rapist as well. For saving the world for worse fates in the future, these brave pensioners would end up earning pockets full of cash as a reward for their noble sacrifices.
It was Windows 98 that when released in mid May 1998, just 18½ months before armageddon and it was NOT Y2K compliant. WTF were Microdickheads thinking especially since I, as a PFY, had known about this problem some 24 years earlier. Still, it just goes to show that Microshaft didn't give a Microshit about their Microsoftware or their valueless customers even then (but we all knew this from years earlier though, didn't we). What a clusterfuck. :rolleyes:
Work for a small support company in the SE of some place not to be mentioned - we have a sizable industrial/academic base that is still running machinery such as milling, medical and mass spec equipment that is 20+ years old, and they will do anything to keep their XP machines going because even if it costs XXXX to do what it takes to revive the PC, that is still much better than paying XXXXXX/XXXXXXX to replace a functional machine that has no software upgrade available or it costs XXXXX to get the new software......
One piece of software I wrote only kept the last digit of the year. For the most part it worked just fine, as I had another table that expanded the last digit to a (get this) a two digit year. That was OK as well. Turns out that the company only lasted around 5 years, but I continued to do some consulting after that.
Yes, it was memory limited, it was the '80s and I was using an 8 bit micro.
Life goes on. I still have a machine close to that one in my garage.
MRI scanner at (classified_location) which was down for an entire week due to the ancient PC it was connected to contracting SQL Slammer.
Of course every other machine in the building had been patched but somehow it got either missed or overlooked.
And what happens a few years later? Cryptolocker.
who did things on the cheap. We ordered some temporary licenses to get going on a project requiring HP Virtualisation, with a PO number quoted and the paper work would follow on. 6 weeks later the vendor queried me on the purchase order to issue the permanent keys, and when I checked with accounts, the PM had cancelled the purchase order the day after we received the temporary keys. I went to the Data Centre Manager and did my scone at him ("you may be happy being cheating fraudulent scumbags with vendors but not on my watch" - or words to that effect). Didn't change anything in the short term, but the PM got fired 6 months later for being useless (apparently he had "forgotten" to budget for OS Licenses, and Database Licenses, and hardware costs, and a whole lot of other things) and the loan kit and temp licenses got given back to HP.
My place has a piece of critical network infrastructure, i.e. the whole wireless network, which is long since end of life (no hardware replacement available) and no support contract either.
Some of the WLAN controllers require you to use Internet Exploiter and an old, old version of Java in order to manage them.
Guess whose job it is to support it?
This story freaked me out.
Reading the article, I had to double check that it wasn't about the project I spent 12 years on.
It too was an OCR project for a government department (but in Australia).
We had an almost identical experience with the license.
Our first task when we took over the maintenance (from one guy working from his shed) was to do the Y2K fix. This was quite surprising as the software had been written in about 1995.
For the entire time we spent maintaining it the department was trying to find a replacement.
During that time we had fixed the many bugs, and the software would run for months, and handle far more work than it was originally designed to do.
Eventually our contract expired and we had to move on.
A few years later I got a call from the department asking if I would mind being contacted if the software needed fixing.
Last I heard it was still doing work that the replacement couldn't handle - still running on '90s vintage HP workstations.
I had this with a 15 year-old piece of hardware, UNIX leisure software and a failed hardware RAID, I'm pretty certain that the uptime was longer than my career at the time. Fortunately, their was one man from Brazil, in Florida with global corp, plus the tapes and a virtual forensically replaced environment. I'll recover the DOS client from Citrix, obrigado! #picasso
Had a kid in his early 20s come into the PC shop I worked at practically in tears, it seemed his dad had FINALLY let him run the lumber mill for the first time while the old man went on his first vacation in 20 years...and the PC than ran the CNC that did custom columns went down and they had a contract worth tens of thousands that was gonna go belly up if they couldn't get the columns made!
The problem? The CNC system, which was this huge thing that cost them a couple hundred thousand back in the day...only worked with an ISA card plugged into a PC running Windows 3.1 and this was a year into Win 7 being out so needless to say no shops had Win 3.1 systems lying about and they needed the thing on THAT day! He had been to 2 other shops before he came into ours and was damn near in tears, told the boss the problem who replied "If anybody in town has something like that in would be my head guy,he's a packrat..YO GET UP HERE" and when he told me the issue and showed me the system I said "Yeah I got a couple of old 200Mhz with ISA slots back in my workshed at home but I'm kinda tied up here"...he just started throwing cash, gave the boss $250 just to "borrow" me for a couple hours, gave me $300 a pop for the 2 systems and another $350 to set them up by cloning his old drive to the "new" systems and making sure it all worked.
The moral of the story? If your butt depends on a crucial system? Best have backups. I ended up putting him in touch with an old engineer friend of mine (RIP David, you are missed) who built him a couple of serial port adapters that would take the place of the old ISA card if it ever goes tits up and last I heard that old CNC is still cranking out fancy columns using my old 200mhz workstation from back in the day.
Software licences and who "owns it" in large companies with bespoke service departments must always be a laugh. I had an MD ask me if I had ever heard of some software they were getting billed for (via an all team email). My department used to be part of his thiefdom and everything we used was because of his wants at the time. I quietly went to his desk and pointed at an icon on his own desktop. It was the software in question. No one in any of his divisions used it and we all assumed it was part of the other ones use... and the man who put it there forgot it was him or what it did. The cost was "a lot" a year for years.
We recently had a Y2.019K problem. A file format that we and various other bits of software support used COBOL / FORTRAN fixed format stylee records and had 2 year dates - the original vendor that defined it was long gone even in the run up to Y2K. So we defined a windowing rule whereby if the year field started 19 or 20 we assumed that it was a 4 year date and the reset of the records were shifted 2 characters to the right.
So, inevitably, this year we discovered that some people were still writing 2 year dates, and now they are 19...
It's all about your business model, given that in the past you as a business owner bet on the right platform to run, which obviously was and is some PC UNIX i386 variant in the case of Unix/Linux. SCO OpenServer has been around since the days of the AT 80286 PC's. Today when looking for the latest you type in www.sco.com and arrive at Xinuos which no one knows. However your old SCO UNIX keys seem still to work or not ... If however you can get SCO OS5 to run on the latest hot x86_64 iron available, making your old applications available at todays cpu and disk speeds, you win. If applications which run on ScoOS5 follow the same business model no one will complain.
Biting the hand that feeds IT © 1998–2019