We've heard of it!
Welcome again to “Who, me?”, The Register’s Monday muck-up in which readers recount their worst mistakes. This week meet “Paul”, who managed to mess up the global insurance industry with a virtual currency. Here’s how. “The year was 1988,” Paul told Who, me? “I had just left school at 16 and started my first job as a …
There's a sadly now departed friend of mine who was ripped off by a local bureau de change. The holiday money he'd changed back into pounds had been done at well above the advertised rates. So instead of getting 75p per unit of foreign currency he got 50p. The "printer has run out of ink/paper" excuse was used so as not to give him a receipt. He was still jet lagged and didn't spot the mistake until a day or so later when he was very annoyed. He went back and complained but with no record of the transaction it was a losing game.
So he went armed with a learning remote control and copied the infra red signals used to change the LED currency display board in the window. Over the next few days he would alter the prices of all the currencies whenever he could. They were offering $3 to the £ one morning and a queue had formed of people wanting to take advantage of this.
@AC Taken from:
In the UK, manufacturing makes up 11% of GVA, 44% of total UK exports, 70% of business R&D, and directly employs 2.6 million people.
The UK does manufacture a lot of stuff. It's all forigen owened or so heavily automated that it employs far fewer people than it did before but don't foget the pound has already been devalued since the vote and depending on what the Brexit terms are it could fall further still.
The UK does manufacture a lot of stuff
Yes, it's now the 8th largest manufacturing nation, just a shade behind France (and the UK is going up, while France is going down). Unsurprisingly the big nations are China, USA, Japan, S. Korea, India, but to claim the UK doesn't have a manufacturing industry is complete nonsense.
@James51 - I think the AC has the usual issue with economic and political facts. You can't trust what politicians appear to be saying, as the actual facts will screw with them.
The most common fallacy is the relating of jobs to industry. Obviously all industries involve some amount of labour, but the major gains in productivity and efficacy involve automating many tasks.
Thus UK industry is about average for a country of it's size, albeit without any specilised industry. The only reason Germany and the Netherlands have "extra" manufacturing is because they make a lot of the tools that go into factories. If you don't include them, then the UK, France, Germany, Italy et al are about the same.
The biggest shift, and this goes for the USA too, is that there is a lot less manufacturing jobs. Hence the perception "we don't make anything anymore" rather than "we make what we used to with ten people instead of 300".
There's also a difference in perception of what "manufacturing" is. Many people don't consider component manufacturing to be "proper" making stuff. Even when it's a moderately complex component, people will often equate assembly with manufacture. Hence the idea that China makes everything, rather than stuff is made everywhere, and then assembled in China.
'The only reason Germany and the Netherlands have "extra" manufacturing is because they make a lot of the tools that go into factories.'
I thought the 'tools' went into Parliament and only occasionally went into factories when publicity was required, like that Gideon character. He certainly looked as out of place as a Politician. At an Olympic Award Ceremony. Watching our politicians at the moment they seem to be behaving as designed, German tools, making a right fist of Brexit.
"The UK does manufacture a lot of stuff."
We had the ridiculous slogan in the 1980s that we live in a "post-industrial age". It was a deliberate distortion of the reality that there would be less manufacturing jobs, to pretend that decline in manufacturing did not matter. it was cynically used to justify the deliberate destruction of the economy outside the south east. It was part of a social engineering policy along with the forced sale of council houses with legislation that prevented councils using the proceeds to build new houses. The goal was to undermine communities which were traditionally non-conservative. The result we have a lopside economy geographically, artifically concentrated in a pampered and subsidised south east and a disfunctional housing market with a catastrophic shortage of housing causing ridiculously high prices and rents. Nothing will change because those in charge benefit from high house prices and simply don't care about anything outside the south east.
@AC - the destruction of the north -- Thatcher's scythe fo destruction over northern England has been likened to the Norman onslaught. That first one crushed the north for centuries, and it was only the Industrial Revolution that made the northern counties fourish again. How long will Thatcher's blight last?
"Come and visit Hastings, then tell me exactly what is 'pampered and subsidised' about it."
The corner of the UK nearest the EU is a relatively poor one. I remember once on a Parliamentary lobby an MP for one of the constituencies there complaining that he kept trying to draw government attention to the fact, but they regarded the entire SE corner of the UK as if it was homogeneous. Of course, it's really London and the Home Counties with a spur to Cambridge, the M4 corridor, Hampshire and Dorset. Bath is part of the South-East nowadays.
In the Soviet Union they had different working currencies for different parts of the country. Workers in military factories got paid in special currency that could buy things ordinary workers couldn't; spivs and high officials could use dollar shops. I wonder if we're headed for the same post-Brexit?
Come to Portsmouth and say that in Paulsgrove/Somerstown areas... or Southampton's St Mary's district for example....
And as for "whaaa northern rail does'nt get any money" come to waterloo and try the pompey express... 1 hour 25 mins to go 65 miles........ that is if the infrastructure/trains does'nt fall over somewhere and block the system up (usually in south London).
Anyway , back to the topic of the mis-placed decimal point, one of my former collegues at a previous employer did that.... moved the robot's reference point 150mm instead of 15mm....
Only did £25 000 of damage ...... with a very loud bang.... the machine was going 2500rpm when the arm hit....
It's an interesting claim but to what extent is it based on the notional heads of companies being there when the profitable work is done elsewhere?
My funds are based in Leadenhall Street and Edinburgh, but I live in neither place and the money was earned from businesses based in the Southwest. In fact, recently I've started moving money to be managed closer to home.
Re: London and the South East subsidise the rest of the country,
Rather depends how you define that. Some might say that London drains investment opportunities way from the rest of the country and gets a disproportionate share of infrastructure investment. It's Cross Rail versus electrification.....
so heavily automated that it employs far fewer people than it did before
This, in large part. In 1994 I worked for a company that made industrial process automation equipment. Not PLCs as such, but loop controllers and process supervision machines, the sort of thing we might call SCADA today. (Some of it was SCADA, but other parts were much closer to the process.
Anyway, I had to go on-site at a British Steel (as it was then) plant at Port Talbot in South Wales, and during that trip, I got to talking with my company's guys in the local office up there. They both had formerly worked at the Port Talbot plant, and they remarked on how at its height, the plant had employed 27000 people(1), and when I went there, it was just 8000.
(1) The site was big enough that I drove in one entrance to the main site offices, from there to the actual building where the problem devices were, and from there to the exit at the other end of the plant, and clocked up eight miles of driving.
Back then there were plans to crate an "heavy Lira" and remove two or three zeros, like France did with the Franc years ago. Then came the Euro and it wasn't needed.
Just if our new government achieve its not-so-hidden plan to leave the Euro, be ready to add again space for a large number of digits... and exchanges rates changing by the minute.
They actually done this with the Romanian currency years ago (LEU/RON).
They took off the 4 trailing zeros, so 50,000 became 5.
When I was over there, both sets of notes were still in use, actually, was fairly straightforward to use, don't know about behind the scenes though I think the currency name changed as well to make it easier to deal with, think RON became LEU
Think I still have a 50,000 note around here somewhere.
Right, they officially dropped 4 zeros and then, to confuse the innocent tourists, they continued to give prices in thousands of Ron. Pleasant surprise, when you pull the big bill to pay the totally overpriced soft drink, just to receive 90% back as your change. Or not, because as a stupid tourist you totally deserve to overpay.
I was, accidentally, there for the changeover; all the banks and ATMs were closed for a couple of days, which was somewhat irritating since I'd turned up without any cash because Romanian lei are hard to come by.
Particularly irritating was that, when the ATMs reopened, they were still dispensing the old notes!
But in currency futures saw an accountant I know put an extra zero in an order for Yennfornthebyear for a large business. Ordering hundreds of millions of pounds worth instead of tens of millions.
By the time he spotted it (end of the day) and it could be corrected (start of the next day) the currency markets had moved.... fortunately they had moved in his favour.
We had a guy once who inserted a new row into a table, offsetting the others. That month we accidentally billed all of our customers using the timestamp field instead of their total charge.
If only one of them had just paid the bill without looking we could all have retired, but no. We had to recall and reissue all those £1.3 billion invoices.
"Old code only referred to the fields by number, $row, $row, so a new column in the middle offset all the subsequent ones."
There's your problem right there. It's an SQL system so nobody of any competence should do that. Had the code been
adapted reused without changes from something older?
I do recall working on a system that took a series of rent payments for a period, stored them in an array and then put them into a series of columns in a single row on the basis that it would be more efficient - not when you had to search all the columns to find out which payment had been missed rather than look for the row with a zero in it.
>> Old code only referred to the fields by number, $row, $row, so a new column in the middle offset all the subsequent ones."
> There's your problem right there. It's an SQL system so nobody of any competence should do that. Had the code been adapted reused without changes from something older?
I've seen plenty of similar examples, written in the last decade or so. Sometimes it's because people aren't experienced developers, but it's also sometimes because people think they're being clever.
As the second comment here notes, in the legacy libraries used by PHP (and presumably, Perl, etc) indexing by the numeric column ID is measurably faster:
(And it's probably still true today, but with modern hardware, I'm guessing the elapsed-time delta is significantly smaller. I've not had enough caffeine, nor do I have enough interest to knock up a test script!)
Personally, I value readability over "optimisations" like this - if you're reading and writing to a database, then disk and network I/O are the biggest factors when it comes to performance issues, usually by several orders of magnitude.
indexing by the numeric column ID is measurably faster
If you only need a few columns but SELECT * then you're losing performance in the amount of surplus data you're cramming into the pipeline from the database.
Personally, I value readability over "optimisations" like this
It's not just readability. It's the fact that such "optimisations" are just errors waiting to happen - as in this example.
Interactively I might write a SELECT *, but that's only the first step to putting together a proper script to get out the data I want. More years ago than I care to think of I wrote a few little programs which would delve into the Informix system catalogs to write code snippets of SELECT, variable declarations & the like which could be incorporated into a program (!! in vi lends itself to that) which would then be edited down to what was needed; just as
effortless lazy as SELECT * but a good deal safer.
>> indexing by the numeric column ID is measurably faster
> If you only need a few columns but SELECT * then you're losing performance in the amount of surplus data you're cramming into the pipeline from the database.
Not to mention what happens under the hood if one of those columns in * is a blob of some form. The expression is "penny wise, pound foolish". Obviously a field index directly converts to a memory address offset so will be faster than an abstraction like a field name, but even that abstraction will likely use some sort of hash lookup internally or otherwise cache on first access, so you can bet your bottom dollar that the difference in almost any real world scenario is too small to reliably measure.
There are occasions to use column numbering, such as computing a row total at runtime for an arbitrary number of columns, but if you're in a position where you need to eek a bit more performance out of your system, there will almost certainly be lower hanging fruit to pick which carries much less risk and gives an order of magnitude benefit over this.
That doesn't even get into the find references to field X in table Y type problems which comes up in the real world quite a lot.
Now, the proper way to have done this, would have been to create a class -- or, since it looks like Perl, a package -- defining an object that matches a single record in the database; with a constructor method to create a new record from an array, and accessor methods which allow you to retrieve one record object or an array of record objects matching a particular key, and retrieve and modify the individual fields within a record object. And so you hide all the ugly SQL plumbing away in methods.
Meanwhile, in the real world, when some tie-wearer who regards writing future-proof, reusable code as mere prettification asked you to make "just a quick change" that you asked them about -- knowing that if they wanted such a thing, you would have to write the program differently than if they didn't -- before you started and they promised categorically that they absolutely would not ask for, and which is going to require you to rewrite the whole lot from scratch to implement, all you can really do is sob quietly into your coffee for a few minutes and then bang something quick out before the next change-of-mind.
> Presumably this wasn't an RDBMS
I can't see how you came to that assumption. SELECT * will include all columns that get added in the future. Many also have the misguided understanding that addressing a field by name is more expensive than by number. One of those premature optimisation consequences.
You can do this sort of nonsense with MS SQL, Oracle, postgres, mysql, and pretty much anything that would term itself as a rdbms and paired with any modern languages like c#, Java, .....
The thing that you can definitely conclude is that pretty much any test case coverage (even manual) would have prevented it from being released.
"Apart from anything else one would hope that columns are being selected into typed variables and that this would likely throw an error if they get out of line. Of course if everything's a string"
SELECT * is fine where you have a properly designed schema and views. It's making things Strings that are not that used to cause me to go librarian-poo with the bounce on the head routine.
Then there are the "programmers" who when not tearing the wings off beetles use things like Hibernate and set it up so that the variable names in Java are different from those in the tables, with slews of XML. Now the schema can't be modified, even if trivially, without modifying the XML...so what was the gain exactly? More maintenance and all so some unfortunate guy in Bangalore doesn't get to learn how to use JDBC.
Hey, I'm retired. Pulse rate down to 58 again, all well.
> "SELECT *" - Screams with pain.
It's one of those things that is nearly always a bad idea. There are some use cases for it where you cannot know the columns available until runtime, but for the most part, it is the result of some code snippet they found in SO.
But the same thing can also occur without selecting * if you think two BAL methods consuming the same DAL method, and one of those BAL methods now needs an additional fact. BAL method one is making an inappropriate assumption about a promise that the DAL never made, and the author of BAL method two failed to consider the effect of their change on others, but the real blame in my eyes is that the author of BAL method one didn't write a test case against the DAL method that would fail if the order was changed (in effect escalating those field orders to a promise). Had they done this, the second author would have had their commit rejected until they either stopped changing the sequence of these columns or adjusted the other methods accordingly.
Type safety can help, but only if the two types aren't otherwise assignable. But it isn't going to save you if you expect an int and the new column is also an int. Some modern languages are even using duck typing, so may not even "break" at runtime. Imagine accidentally selecting an int into a float field or something of that nature. You might get a number, just not the one you need to give the correct output.
>> Presumably this wasn't an RDBMS
> I can't see how you came to that assumption. SELECT * will include all columns that get added in the future. Many also have the misguided understanding that addressing a field by name is more expensive than by number. One of those premature optimisation consequences.
Doesn't even have to be a SELECT * - as per the manual page I just posted, many libraries have the option of indexing the "columns" of each individual record by numeric position or label. So for "SELECT a, b, c", you can refer to element c as either record[c] *or* record.
Personally, I tend to terminate such constructs with extreme prejudice when I come across them - unless there's a very good reason to minimise the code's footprint, readability (and hence maintainability) should always take priority.
If only one of them had just paid the bill without looking we could all have retired, but no. We had to recall and reissue all those £1.3 billion invoices.
In today's world, the employees would have been laid off, the buildings closed, and manglement would have taken the money as a "bonus" and left the country.
This Tech Rookie once did something similar. It was noticed when it was discovered that we had not paid any infantry officers but had blown the vote for lady dentists. Fortunately this was the early 1970's and systems were not integrated and the manual read across prompted the question "have we had a recruiting drive lady dentists".
aged 15, several of us doing Computer Studies were assigned to a national bank's office in Salford. There we sat for three days, all day, processing cheques by encoding the amounts handwritten on the front into magnetic/flourescent machine readable amounts printed on the back. Being sat next to a lovely lady, she quickly got me up to speed on all the features of the imprinting machine. When I spoke to my friends after the first day had finished, I discovered that they hadn't had the benefit of such tutelage and had mistakenly used the wrong buttons. The machines had a whole variety of 0 keys, single, double, triple and even quadruple zeroes. There must have been several thousand cheques went to clearing that day with encoding errors measurable in orders of magnitude. Oops. That was the first and last time they took on work experience placements for many, many years.
"There must have been several thousand cheques went to clearing that day with encoding errors measurable in orders of magnitude. "
While also doing Computer Studies many years ago, we got taken down to the local Town Hall to see their mainframe and ancillary equipment. One of the things that stuck in my mind was the people typing up the paper tapes from the coding sheets. On completion, the tape and sheets were passed to the checkers. The checkers then fed through the tape and typed the data from the coding sheets again. If a key press didn't match what was on the paper tape, the keyboard physically locked and the error could be checked and corrected. This applied to ALL coding sheets to be transferred to paper tape.
It sound like that bank ought to have been doing something similar.
Not checkers, "verifiers".
Ours made a second copy of the tape.
Funny story. I once wrote a softcover program (you can do that sort of thing in a language that emphasizes readability over terseness) and it got verified 9 times.
And I was menaced by the punch-room supervisor when she found out and she made me run it in front of her to prove it was a real program -it was - and it was the only job I submitted to come back with no typos.
"Not checkers, "verifiers".
Ours made a second copy of the tape."
Yes, you are correct. It was about 40 years ago :-)
The copy tape would stop at the mis-type where the verifier would then check if the error was on his/her key-press or the first tape and then press the unlock key and either re-type the key that locked it, correcting the original error, or press the correct key if the verifier had mis-typed. Any remaining errors would have been the fault of the person filling out the coding sheets ;-) (or potentially, bit the initial data entry clerk AND the verifier making the same mistake!)
I challenge you, John Brown (no body), to cite a male keypunch operative.
They were called punch girls for a reason. Mostly young, single and not looking to stay there forever.
Some days they were the only reason for going into work.
Yes that is sexist. It was also the reality. See also: Typing Pool.
And before anyone screams and leaps, in that same place of work my boss was a woman.
As for winking in the bit about coding sheet blame, that's why people who came out of that era had distinctive ways of writing the characters 0 (or O), I, G (or is it a 9? or a 6?) and Z (or is it a 2?).
I still slash zeroes and bar Zs out of habit.
I still remember entering lots of license keys for a full text database in the early 90's.
The license keys came via fax!
Luckily we worked out that zeros had a slash as did Z's, there were no lower case I's and my collegue worked out there were no lower case L's!!
"On completion, the tape and sheets were passed to the checkers. The checkers then fed through the tape and typed the data from the coding sheets again."
Same thing happened with cards and probably with key-to-disk data entry.
It probably got ditched on grounds of expense.
The steal the rounding errors "scheme" was around for a long time (I'd read about it in a seventies-era book); it was one of those things that everyone knew had happened but when pressed could never come up with an actual example.
It's not surprising that writers of both films had heard about it. Maybe it was taken from Superman 3, maybe not.
I asked a subordinate to order some preprinted forms that we used for data capture (Not everyone had a computer back in the day, so many staff filled in the form with a pen and the form was used to enter information into an Oracle database). I countersigned the order, unfortunately it was for 500 reams of paper and not the 500 sheets (1 ream) that we needed. We were still using the excess as scrap paper when I left 2 years later - By which time most of the staff had computers, so there was little need for the form anyway.
I still have headed paper from when I first set up my company. The header shows a logo, and contact details as-were at the time: these were important, as the credibility of a real office address was one of the hoops I had to jump through to get accredited to accept card payments over the 'net.
The details on it have been out-of-date (so the paper can't be used for business purposes) since about 2001. But I still use them for test printouts and such private matters, and from time to time I get to jot on the back of a superior-quality envelope-substitute.
Working at a large international computer company, I needed to order 2 of the largest memory dimms (8MB I think, and quite expensive at the time, even as an internal purchase) that were available for a particular type of machine. Two packages turned up, and were put in a store room waiting for a suitable time to fit them.
After a week or so, I finally opened the packages to find not two dimms, but two carrier containers, each containing 20 dimms (I thought the boxes were a bit large, but this company was renowned for using boxes that were too big).
I talked to my manager, and he said fit the two we had ordered, and put the rest back in the store to see whether anybody missed them. Unfortunately, after about a month, the manager said he was contacted by the department responsible for shipping the dimms, asking whether we might have received more than we should, and although he thought about denying it, eventually relented and had the extra items sent back.
It was a shame, as the extra ones would have allowed me to double the memory in all of the X-terminals that we had on the staff desks at the time.
Our electronic ordering system now flags up (to the user who entered the order) any orders to companies that have supply multiples. If they insist the order is OK, it then sanity checks the actual amount ordered using the online catalogues and asks again. Cut the admin workload amazingly.
Back in the distant past when I worked for a year at Thames Water, we would regularly get duplicated orders from RS. The issue was that the accounts department would insist on sending an order in even if it had been made by telephone and despite us writing "telephoned order" all over the form that went to accounts, they'd invariably process it as a standard order. This was the same accounts department that wouldn't let us buy computers because the computer budget had been used up.
We instead purchased a number of "electronic logging machines".
This was the same accounts department that wouldn't let us buy computers because the computer budget had been used up.
We instead purchased a number of "electronic logging machines".
According to legend a Botany prof at QUB was having problems getting the University to allow a departmental vehicle. Successfully smuggled into a list of things such as microscopes was a VW Microbus.
Unfortunately it got written off by someone making a rather sharp turn into the road where the glass houses were; by the time I got there the vehicle was a rather ancient Mini. We probably knocked a few bits off the sump cooling fins driving it up mountains.
"Ah yes, ordering 100 items from RS Components, and not noticing they were sold in lots of 50. Been there, done that"
Oh, RS were worse than that. When they had 6-digit stock codes, they used to reuse them.
This meant that on the day before a catalogue change I placed a routine order for a hundred small signal amplifier transistors, but owing to a holdup in purchasing they were actually ordered two days later. The day after that, GI calls up and says "we have a pallet for you".
One hundred 12W loudspeakers. RS did take them back. But the upshot was that we opened an account with a semiconductor-only distributor who supplied by manufacturer part number.
Esteemed Author» The job wasn’t hard, but was complicated by the fact that back in 1988 memory was at a premium so the firm tried not to use all the numerals in very large numbers.
We'll save a few hundred thousand pounds in memory so that our profits in the billions look bigger.
Lloyds surely had a bob or two spare. if anyone could afford memory for their computers, it was a large company in the financial services sector.
A 1980 IBM mainframe. Ran at several MIPS. Main memory several dozen megabytes if you completely maxed out. Consumed several dozen kilowatts. Cost: I don't know. Could you buy one or was it some kind of rental model?
Compare to the original IBM PC (1981). Ran at several dozen KIPS (yes the clock speed was 4Mhz but instructions took a dozen or so cycles to run and unless you were happy with 8-bit numbers you'd need quite a few instructions even to add a couple of numbers). Main memory several dozen kilobytes. Consumed several dozen watts. (Guessing there. Anyone know?) Cost: $1500.
If you weren't there, it's probably quite hard to get your head round how crap they were. And yet, you could do so much if you were careful about it.
Similar problem back in the 1970s with an insurance company. Memory is expensive, so all numeric values were stored in a packed format - that's common, two decimal digits per byte, with a zero and sign (C for positive) in the last byte. To save space we stored everything by chopping off the last byte, so we could store a ten-digit number in 5 bytes instead of 6 - and then had to do some odd pointer-based overlaying of fields (in PL/1) to actually manipulate the numbers). Kids today have no idea of what we went through...
"Similar problem back in the 1970s with an insurance company. Memory is expensive"
And not only in the '70s. In the '90s I kept saying -and being ignored - that we needed more memory in an HP-UX box. Then an OS upgrade put it into thrashing. An engineer with new memory was summoned up PDQ with promises (huh!) to take more notice of what I said in the future.
I had lots of luverly code that stored UK telephone numbers as integers. 0000000000 to 0999999999. Then Big Number Day happened, ints only gave me 01x to 02x with a bit of jiggery-pokery. Luckily, I could move to opaque 5-byte floats before we needed to start storing 07x numbers.
In 1988 servers/mainframes and their associated bits, were far from cheap.
Couple that with the amount of "we don't need this new fangled stuff" in the head bean-counter type department and you have your answer. It's the bonus of them and those above them that you're talking about spending.
I remember the computer world from early nineties onwards and I remember being quite impressed by VAX and the by small little Macs in the labs that we used to do our statistics on (SE/30 maybe?). Memory then was expensive, it is true.
I understand that servers & mainframes were not cheap but for a company as large as Lloyds to spend so much on computers and need to do jiggery-pokery with big numbers does seem strange. I shouldn't be so surprised by human nature though.
@deadlockvictim re: " I remember being quite impressed by VAX and the by small little Macs in the labs that we used to do our statistics on"
I think this explains why you are having problems grasping things; you've not done any serious programming.
All programmers have to make decisions, especially about numbers and even more so when they represent money: the formats (ie. int/float/BCD/string) being used, the precision based on the facts presented to them, these decisions will take into account the data, the machine being used and the programming language. This also includes those who wrote the math/stats libraries you used.
I think also you overlook the massive improvement in system performance: The real reason why people were able to "downsize the mainframe" in the late 1990's was more because if you re-architected (and I did) a 1970's mainframe application to use the late 1990's hardware and computing paradigm, you could often go from needing a chunky mainframe to some relatively modest minicomputer - in one client case it was from needing a £17m(*) mainframe upgrade to a £1m(*) overspecified NUMA configuration ...
It wasn't to save memory. It was because of bad programming practice. A single byte can store 256 years. But it you store each number as a character, you use two bytes and get only 99. Or one and 99 if you use BCD.
The "character/string" as the universal data format is also what now makes a lot of web applications crap.
Because also of bad debugging techniques, it's far easier to make everything a string and print it somewhere....
AC blithers on the subject of Y2K:
It wasn't to save memory. It was because of bad programming practice. A single byte can store 256 years. But it you store each number as a character, you use two bytes and get only 99. Or one and 99 if you use BCD.
SInce only IBM mainframes used that byte structure (ICL 1900s used a twenty four bit word on the ones I worked on, and the Univac 1100 series could chop their 36 bit word a number of ways, including a six, nine or 18 bit "byte"), this is a rather specific bit of misinformation.
In the general case it was because the Cobol library routines of the day returned a two year date when asked to ACCEPT DATE FROM TODAY. Poor programming? Arguably. But done at the compiler/systems programming level.
I have said before, thinking "Y2K" was a problem confined to only recording two digits of the year is to be woefully under-informed. My absolute fave was the bank round the corner where the accounting software had been properly hardened with four-year dates but the ATM vestibule door locks (which used epochal dates) hadn't. New Year's Day: NO ADMITTANCE, NO EXCEPTIONS. Apparently the door lock computer thought everyone's cards were backdated 1999 years or something.
Still, some of you will get your own chance in the trenches when whole scads of legacy "modern language" stuff everyone has forgotten prop up the corporate infrastructure goes nails-up in about 13 years or so. Good hunting.
I think that you will find that ICL mainframes were also hexadecimal and used BCD. EBCDIC if my rather hazy memory serves me.
First used in the ICL System 4, which was a licensed RCA Spectra, which in turn was a rip off of an IBM 360 IIRC. The BCD was almost identical to that used by IBM. I think one value was swapped round to get round copyright or whatever. I saw one of the very early "System 4" machines which still had the RCA logos on it.
The 2900 range followed on from System 4, and the 1900 range was dropped. One of the more mind bending parts of my career was to get involved in machines (2960 then 2966) which ran microcode emulation of a 1900. Having cut my teeth on Hexadecimal it was a bit of a wrench to go to using Octal. All those nice letters had disappeated, along with 8 and 9.
I specifically called out the ICL 1900 range. While I worked on 2900s it was in the days when no-one trusted either of the two different flavours of VME and were running four DME "slots" - effectively making them 1900s. I never bothered getting into the internals because I was looking for a Sperry contract by then. ICL were in an obvious sunset situation even I could see a mile off.
I don't know how you weren't swept up in the mad rush to convert from ICL 1900s to Univac 1100/60s when a three-letter blitherer from ICL claimed they were dropping support for 1900/DME codebases*. The stampede was such that Sperry corp in the UK set up a special unit of so-called "1900 experts" to lead people through the conversion required.
Are my bone fides acceptable, or do we need to talk about PLAN, Applications Manager, XKYE, XPJC and DMAP? Can we declare this tackle-measuring a draw and give it a GO 29?
* - This wasn't new. ICL had a special corps of blithering director-level people who would announce things that would cause mass stampedes of customers to other people's mainframes. According to my sources Dataskil was formed as a place to park one such individual who made a remark about the future lack of support of tape in GEORGE** without actually firing him.
** - Best name for an operating system ever. Grown out of a previous thing called "Automatic Operator" and renamed for for obvious reasons*** that make the widely-known backronym laughable.
*** - If you are British, and have a working knowledge of pilot slang.
"A single byte can store 256 years."
You can also use a longer integer to store whole dates or even date & time depending on the length and resolution of time but at some point you have to convert between integer and human-readable form and vice versa. Part of the the issue is the formats which those humans wish to use. In particular people like to write years as a couple of digits and if that's the case the programmer has to make some assumption about how to fill out the missing digits. Prior to late C20th the assumption would be that those were 1 and 9. Nowadays we tend to have assumptions based on some sliding window - it the provided digits are less than some amount it's 2 and 0.
"Why do you think the Y2K bug ever existed if not to save some memory?"
Storing dates as a binary number (like UNIX's time_t) actually saves more memory. I think the two-digit year was so widespread because people really just did write two-digit years and so that was carried over into computer software without thinking about it.
As I recall Lloyds did not change from a punch card-based system until 1990. There used to be a saying that there were 3 visible man-made things from space, The Great Wall of China, the Hole at Kimberley and the Lloyds of London paper mountain.
The excuse was always that due to the sheer volume of trade there would never be the opportunity to switch off one system and switch over to a new system.
I think more than just memory being expensive, the quoted number of Lira for £1M being 2,208,236,622 (2.2 billion!) is pushing on the door of 32 bits. I'm going to assume even in the 70s financial institutions used datatypes that could deal with large numbers accurately, but some of these currencies may have hit limits in that handling.
I was called to the accounts office with my manager to explain the One million dollar transaction on my company credit card bill. At first I was horrified, until I remembered buying a Zimbabwean $1M bill on eBay (it cost a couple of quid), as a joke for a Zim friend's birthday. I'd intending using my personal card, but my computer had autofilled the company card number and I hadn't noticed.
After an explanation and a bit of banter at my expense, I coughed up the £2 to pay my debt.
A company that I worked for sold software to banks in Zimbabwe.
They asked us to customise the software for them to add six digits to all the amounts. By the time it was done the six digits were not enough. They talked about getting us to do it again but the order never came. We tried to contact the banks but nobody was answering the phones. We assumed that the employees were to busy trying to get food to talk to us about trivialities like software development.
I was working behind the bar one night/morning and being tall couldn't see the amount without bending down which was getting difficult to return from. Next day the boss asked me about the missing £1/4 million or so from consecutive transactions being incorrectly returned,
I told him I'd drunk it!
In days gone by I worked for a large life assurance company who had a reverse-lira issue. Some of their 'Industrial Branch' old policies (life assurance collected weekly by agent knocking on doors) went back decades, and when they matured they need to be processed on modern computer systems - which had to handle weekly premiums of 1/5d or even some in farthings. So they multiplied the pounds by 960 and did all their sums in farthings.
"Guy on a bike knocking on doors" was a pretty common method for collecting subscriptions back in the day - my Granddad did it for years after WW2.
Though he never really said who he was collecting *for*, so maybe it was the mob! I should ask my Gran about that while I still have the chance...
My first job when I left school was for a company that did exactly that. After a few years in the office, I was "promoted" to a door to door collector position - which proved utterly to me that I never ever ever want to work in sales of any sort, nor do I ever want a job that again exposes me to not working in the mornings and becoming a watcher of daytime tv. That was in the 1990s and whilst it was a pretty archaic business model, there were still a good few companies in the UK in the Industrial Life Assurance market.
When I was growing up in the Western Isles in the 60s/70s, a bloke from the Council used to come round once a fortnight to collect the rent. After I went to Sheffield Uni and had my eyes opened to the wicked world, I was home on holiday and he turned up. My mother said "Oh, here's the rent boy." I gently tried to explain what a rent boy actually was, but she shrugged it off and said "He'll always be the rent boy to me."
Paris because, well, vaguely in the same area...
"life assurance collected weekly by agent knocking on doors"
Isnt this called collecting with menaces? Who did you work for the Mob? :P
That's why it's called "life assurance"...paying assures that you'll live.
...and the converse, of course.
Ask me about our loan offers...low interest rate [compounded hourly]
[the one with the blackjack in the pocket]
Way, way ago, working with a very early on-line CICS motor insurance claims system, there was sudden panic when it looked as if the company had just had a massive increase in claims. Turned out someone had entered a total loss claim for a fairly expensive car (£6000.00) without the decimal point. It was early days - sense checking and validation wasn't as tight then as it (sometimes) is now!
A decade or so back when I was working at the Revenue, a memo came around to look for a missing cheque from the DOD. I can't remember how much it was worth (~500k, maybe?), but I remember very clearly it being described as "PAYE for the Ghurkhas".
Of course, back then, it was really obvious that there was a widening gap in public and private IT. So much tax was collected by bank transfers, records sent electronically... but the DoD sent in cheques, and the NHS sent us /microfiche/ records. In 2006.
I kinda hope that's changed, but I have a feeling I'd be disappointed.
Turkish Lira & Brazilian Cruzero also feature high in my concerns.
Indeed for Brazil we ended up with a problem that the exchange rate exceeded 99,999 (went up to about 140000 to the pound IIRC) exceeding the exchange rate capability in the system by being far in excess of the other currencies with high value exchanges. This was a ledger system for a bank so was intended to handle large numbers too.
This led to truncation in reporting vast numbers, let alone the internal maths of dealing with currencies. We also had to creates a "meta" currency to handle it. Never mind the local people who live their pushing barrow loads of near worthless cash around to buy food. Didn't actually break the system, but we came pretty close!
I don't deal with the excitement of global currencies any more, with arbitrary regulatory changes, reporting standards, odd payment holidays, competing clearing systems and time zones etc. My shop makes up for this of course, by adding lots of internal complexity all by itself.
The other side of the coin...
On holiday in France pre-Euro, took 200 quid (in francs) out of cash machine. Got home a couple of weeks later to find multiple messages to contact bank, including "tour account is overdrawn, please deposit 18 grand immediately). Turns out whoever entered the daily exchange rate for the bank had set 1 franc as 9.5 quid instead of the other way round. And the stupid bank had then merrily debited this from our account, not noticing that taking this amount out of a cash machine was not exactly likely...
Cue bouncing mortgage payment, standing orders etc -- took us weeks to sort out. Never even got a proper apology or any kind of compensation either. Thank you Nationwide :-(
When I lived in Cambridge they were awful. The work around used to be to put a different area's proxy into your browser*.
* thanks (u)cam.misc** for the tip
**It appears cam.misc is still just about alive, no idea if the University's internal newsgroups are still going though
Yes it's all coming back. I too chose alternative proxies. Anonymous: Late nineties I think. I was one of those who bought and still has on the shelf the £100 Surfboard box and subsequently got a £5 monthly reduction to compensate when they started supplying the kit.
Of course you can dig around in cam.misc (but perhaps not using VM's broken servers) for more.
COBOL on PDP-10 systems allowed for 10 digit numbers - you could choose where the decimal point lay. In the system that I worked on, we had S9(6)V9(4) fields for unit prices, but if the country code indicated Italy, we had to use S9(6)V99 instead.
Dates on this system were held in 4-digit YYMM format - my first task as a fresh-faced programmer (in late 1978) was to change all the code (and the data) that regarded 7912 as an indicator for (e.g) cancelled orders - we couldn't take any more room, so just used 9912 as the new indicator. The system presumably died before Y2K, I'd moved on a couple of times by that point.
Regarding the penultimate paragraph I remember a mainframe operations supervisor for an insurance company telling one of his underlings that his job, as supervisor, was making sure the said underling was doing his job properly.
In my last job for a major IT services company, I also saw the flap that resulted when the wrong exchange rate was used for the nightly batch run on a stock exchange application that serviced stockbrokers spread all over the country.
I once had to spend an entire week working out why a company had been sent an insurance payment of $0.00
Lloyds syndicates would usually only take a small percentage of the risk for something large, and frequently package up portions of these risks and sell them on or take out reinsurance against claims.
Claims against an oil spill or fire could run into billions so you needed the risk spread over hundreds of syndicates.
So when an oil tanker claimed $50.00 in paint after it touched the side of the lock in the panama canal our system took the claim and started splitting out the different shares and raising claims against other syndicates.
By the time it had gone through this a few cycles over a few days as different syndicates processed their claims and raised new ones for their reinsurance then every single syndicate involved had decided that their share of the claim rounded down to 0.
Had a similar issue at an old job in the City.
A junior customer service bod was doing payments / transfers for the first time. After being shown the ropes, was left to do one on his own. He put the 7 digit customer reference in the transfer amount field, paying some lucky customer over 100 times what they should have received...
Thanks to mistakes like that, all the management/professional grades here are on a rota so we take turns in checking all the manual payments we make (dozens to at worst low hundreds a day, thankfully - avoiding manual work is a BFD in the fun-filled world of "not paying people the wrong amount").
Everyone grade 4+, even the IT-types who've made the error of being embedded in the Finance area, including muggins.
Fun recent discovery - RBS, Barclays, etc... they won't let the clerks enter an impossible account number. HSBC, however, don't validate the account numbers you use, so it's much easier for mistakes to occur.
It also happens the other way round. A friend told me how decades ago, when the UK oil industry was going metric, they had a young chap (work experience or new graduate) in their design office. This young chap hesitantly approached his boss and explained he got the impression that the engineering department had designed a 100 km subsea pipeline, but that the procurement department was about to invite bids for 100 miles of the stuff. The next day the young chap was treated to a very good lunch at a posh restaurant by one of the senior bosses as he had prevented a mistake of many millions of pounds.
"This young chap hesitantly approached his boss and explained he got the impression that the engineering department had designed a 100 km subsea pipeline, but that the procurement department was about to invite bids for 100 miles"
One of the first tasks I had as a young researcher was proof-reading a paper based on someone's thesis. This was in the days when papers were set in metal type and I think this was final page-proofs. The subject was sea-level changes and the original levelling was done in feet with both imperial and metric quoted in the paper. I realised that all the metric conversions were wrong; the error went all the way to the thesis and nobody, not even the external examiner, had noticed. No nice meal, though.
* The levelling staff was calibrated in decimal feet: feet and 10ths of feet which I think was quite common back in the day.
I worked for a stock market data company that originally had their software running on PDP-11s and while newer hardware was in use, the data format stayed the same. A few of us were using Berkshire Hathaway shares for testing screen formats since it was the highest value per share on the NYSE. We noticed that the class B never went over $32767 1/2. I mentioned that to someone who knew all the very odd settings in the database and a few keystrokes latter the price magically crossed that 16 bit value.
As a contractor, I've seen more than my fair share of corporate screwups, given that I was usually being employed to fix them.
The two "Who, Me" type examples I can think of were eerily similar. Both happened to a new employee during his first week (in one case, it was his first *day*). They were different industry (avionics and banking), but the common theme was that new, untrained employees should never be given the ability to do that much damage in the first place.
In the first case, the avionics employee, on day one, was given a computer system and told to run a script that would retrieve the source code, do a build, generate a hex file, which he was to write to floppy, then trot over to the eprom programmer, and burn an emprom with said hex file. He unfortunately inverted a few parameters on the (admittedly both complex and counter intuitive) script, and instead of generating a hex file from source, managed to read an empty hex file, and write it into the source tree, overwriting about three months of unsaved work.
This cost the company in the low six figures, just in terms of the lost work, not even factoring in things like contract delays that were incurred and the like. The new hire, unsurprisingly, full expected to be sacked, but his director (his boss' boss) said "Why would I fire you? I just spend $200K training you!". Of course, said director had choice words as to why an untrained, unsupervised new hire was put in a position where he *could* do so much damage. Questions as to why the script process was undocumented, completely counter intuitive, and capable of overwriting developer source were raised, as was the issue of why three months of developer work was not saved and archived properly in the first place.
The second case was simpler, and somewhat less costly. A new employee doing tech support for a trading floor was given a spot on the trading floor. For his computer, he basically got a box of scraps, and was told to build himself a working computer. The trading floor was token ring, specifically 4mb token ring. In the box of computer parts, there were more than one token ring card, so new hire picked the fastest (I believe it was either 8mb or 12mb, whatever was top end around 1992). He puts his computer, gets into DOS, all is good, and then he plugs in his token ring cable into the wall socket. Within about 100ms, the entire trading floor went offline. Traders do not like going offline. The quoted number was something like $70,000 for every minute that the network is offline, in terms of lost opportunity costs, but of course, that's all projection, not calculable fact. What was calculable was that it took about 15 minutes after new hire disconnected his PC from the ring and the ring was restored.
In both cases, the new hire may well have screwed up, but in both cases, the fault was with their management for giving untrained, unmonitored employees capabilities well above their skill levels.
it 'cost' the department nearly 500k in 1983 dollars of computer time;
My first real live program as a trainee programmer , spec handed to me and coded as per, there was a an if statement that had no else , so I asked ... 'nah that will never happen' - well it did, it shouldn't have, but it did, and the resulting loop cost 500k on the mainframe.
No big deal was made of it, but I was asked to give manglement the original spec , on which I had jotted a note , 'can this happen ?' , supervisor got a kick up the backside, and the offending record was corrected.
Once had a panic because the computer I was using (at the time some nasty monstrosity of a recycled laptop) had the source code window open to make changes.
So instead of hitting "program" (Alt-P) somehow ended up in the source window and b0rked 3 lines of the source but only noticed when the program came back with a compile error
Cue major SHTF and someone had to fix it from memory.
Also accidentally trashed 4 different computers with a drive "test" tool which didn't sanity check to see if the drive being tested was actually (a) connected to USB and (b) wasn't the system drive with the operating system on it. FFS!
And this is why I no longer work in IT...
Brazil was so used to divide their currency by 1000 that they would simply stamp the new value over printed money, up until the Real (Brazilian Real, or BRL), due to the astounding inflation of 80% PER MONTH at some point.
When the Real was implanted, we had to divide by 1750 instead of 1000. And that freaking value would create a LOT of periodic continued fractions... (tithe?) generating all sorts of headache due to the last decimal not matching due to rounding / truncating the value, or if it was done by hand or on a machine.
So, a coke would cost, for the sake of example, 759,75 or 759,76 depending on who or what did the math. When it came to gasoline or anything sold by large amounts, it generated an huge problem... like the "Superman 3 decimal cent paycheck syndrome" of sorts.
It took a while until values were sorted out in the new currency and people forgot about this.
My first job out of university was with a large international German electronics manufacturer with a rude sounding name; they'd sponsored me through uni.
I was tasked with generating multiple EDIFACT messages from the SQL database using VB, one of which was the INVOIC file. One of the fields in the message, I can't remember which, indicated by use of a single character whether the message was an invoice or a credit. I got it the wrong way around and accidentally sent out around DM 10 million of credit that should have been invoices.
Fortunately we only invoiced our regional offices around the world, not the end customer, and the mistake was quickly spotted.
As a temp I worked one time, at the turn of the century, for the company that has a suspension bridge in its logo, and got proper training from a person that also had a major in micromanagement... So one day he came over to tell me how to do what I was already doing, by giving the example. ... I had just entered the barcode of a ram-card, when he intervened, and showed me how to do stuff. By scanning the barcode of the machine it came from (the M4500). ... Next day, I got my curious foreman, looking about for a pallet of ram-cards. 4.5 meeelion of them, to be exact. So I ask what he is looking for. Well, 4.5 meeellion ram-cards.... We go back to the point of origin, and he, presto, what is there in the field for number of ram-cards received? M4.5... I guess he machine understood that as 4.5 meeelion... Where my micromagaging instructor should have added a 1, before going to the next object in line. ... Years later I found out what these cards actually did cost, and calculated that whas a total of One Beelion dollars... I wiped out with a few strokes, correcting the micromanager. About a tenth of the value of the company at that time. ~ ~ ~ ... Maybe I should become a banker... ~ ~ ~
Biting the hand that feeds IT © 1998–2019