The Daily WTF: Curious Perversions in Information Technology

operagost · 2014-01-08 Reply Admin

IN THE YEAR... TWO THOUSAND... IN THE YEAR... TWO THOUSAAAAAND

2014-01-08 Reply Admin

Hannes:
faoileag:
Hannes:
I really don't know why some people think it's "good practice" to truncate information they want to store.
I don't think they thought it to be a "good practice", at least the article doesn't say so.

Yeah, that's why I put it in "", I just couldn't think of a better word. ;)

It's just one of these things you can't avoid if you have fixed-width datafields.
What alternative would there be? Turning customers down because the name of the street they live in is too long? Not hiring the perfect match for a position because his surname happens to be longer than the max the payroll system can handle?

This may be true for the 70s, 80s and even the 90s, but there's no excuse for truncating data nowadays.

If you want to implement fixed-width records to contain potentially unlimited data, you set up an index field at the start so as to allow multiple records to hold your data. So, for example, index 1 fields 1 to 50 contains the first 50 characters of the first name, index 2 fields 1 to 50 contains the second 50 characters, etc. etc. Then there is no need to truncate -- but at the expense of an inefficient use of space.

devjoe · 2014-01-08 Reply Admin

mara:
<oblig>http://www.cbsnews.com/news/hawaii-womans-last-name-so-long-it-wont-fit-on-her-license/</oblig>

A bonus WTF in this article is that even though her name contains an okina (the Hawaiian character that looks like an apostrophe) and it's shown using one in the picture, and the okina is specifically mentioned in the article, the article text omits it, not even using an apostrophe to represent it.

2014-01-08 Reply Admin

Hannes:
This may be true for the 70s, 80s and even the 90s, but there's no excuse for truncating data nowadays.

There's even an excuse for truncating data in the 2020s: if you then still do your stuff on a legacy system from the 70s and don't have the budget, or don't dare, to migrate to a modern platform.

Although in this day and age, you will probably not live to see the 2020s if you don't migrate, at least not if customer data is involved.

2014-01-08 Reply Admin

TRWTF is PC programmers who can allow themselves to believe that a multi-million dollar operating system can't handle anything except US-English. When DB2 needs to store Finnish names, it assigns CCSID(278). UTF-8 is CCSID(1208).

Now get off my lawn!

Steve The Cynic · 2014-01-08 Reply Admin

devjoe:
mara:
<oblig>http://www.cbsnews.com/news/hawaii-womans-last-name-so-long-it-wont-fit-on-her-license/</oblig>
A bonus WTF in this article is that even though her name contains an okina (the Hawaiian character that looks like an apostrophe) and it's shown using one in the picture, and the okina is specifically mentioned in the article, the article text omits it, not even using an apostrophe to represent it.

If done according to strict form, the okina looks more like an upside-down apostrophe (a "6" rather than a "9"). You can see this sometimes on road signs in Hawai'i. (If we're being pedantic, we should include the okina in the name of the place...)

(About the author: No, I don't live in Hawaii. I've spent a grand total of two weeks there in my life. One of those two weeks was the 9th to 16th of September 2001 (yes, that made leaving the place interesting), the other two years earlier. But I have a medium-weight interest in human linguistics.)

Steve The Cynic · 2014-01-08 Reply Admin

Daniel:
There's no reason they can't support at least UTF-7.

That's either a medium-difficulty troll, or a subtle trypogaphical error.

bjolling · 2014-01-08 Reply Admin

John:
faoileag:
John:
faoileag:
Tim:
faoileag:
If it costs X man hours to convert the legacy data delivered by the cobol system in the web service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.
what if 0<x<1? </troll>
Oh come on. If someone comes up to you and says: "Give me an estimate: how long does it take you to write a converter that takes a 2000 EBCDIC character large string as input and delivers an instance of the appropriate data object with its fields set accordingly?" do you answer "No prob, chief, give me 15mins"???
Comparatively speaking, yes.
Tim was just highlighting a flaw in my example - my assumption that X^2 is larger than X. Which isn't true if you allow for time units that are fractions of man hours ((1/2)^2 is 1/4).
There's always a nitpicker around to highlight such things - I know, I am one myself :-)

The square is always bigger and it's easy to prove. Construct a square of any side length X. This has area X^2, right? Now, take an identical copy of any of its sides. This has length X, yes? Now simply place it entirely inside the square. You might have to angle it a bit so it fits in there. X cannot be more than X^2 or it would not fit. Since by inspection you can see some unused space remaining in the square, X is in fact strictly smaller than X^2.

What if the width of one side is larger than X?

2014-01-08 Reply Admin

QJo:
If you want to implement fixed-width records to contain potentially unlimited data, you set up an index field at the start so as to allow multiple records to hold your data.

I thought about that, but without knowledge of COBOL and especially the legacy system in question, I don't know if this is a viable strategy.

Think address label printing. One record, one label. Print characters directly from the record, no fuss. With chained records, you will have to assemble the strings to be printed from the multiple records before you print. If that is possible at all and the label printer itself does not also expect a fixed width 2000 character record.

CAPTCHA dolor - It must be a dolor in the ... to work with such a system.

2014-01-08 Reply Admin

Looks like .Net handles EBCDIC conversion if you don't want to do it on the COBOL side:

var ebcdic = Encoding.GetEncoding("IBM037");
var value = ebcdic.GetString(ebcdicBytes);

http://stackoverflow.com/questions/2858202/how-to-convert-from-ebcdic-to-ascii-in-c-net

So with that and an array of field lenghts I don't see why this should take more than 15mins.

no laughing matter · 2014-01-08 Reply Admin

CrankyOldFart:
The fact that names in the Enterprise System still can't handle accented characters (or I'm going to guess hyphenated last names) is the WTF.
Actually, the real WTF would be to expect some clerk in accounting to know how to enter an accented character, or to care enough to bother doing.

Yes that is typical for COBOL systems: The original data was submitted by the customer on a Web form, but the clerk in accounting now is copying it manually because there is no connection between the Web frontend and the mainframe backend.

(Another reason to promote COBOL on wheelchair!)

2014-01-08 Reply Admin

no laughing matter:
Obligatory Comment: TRWTF is COBOL.
Even at the time of its invention there were already better alternatives (Lisp) which could handle more than fixed-width data structures.

Not only is COBOL crippled, it also cripples the mind. The inventors were dumb and it should be dumped!

TRWTF is all the developers and programmers who say COBOL is "crippled" and should be replaced without understanding what it is or what it does because all they know is "cool shit" and how to count in 42 languages. They have no idea about "real world" use of computer systems and data processing. I would rather have my banking and payroll run in a 40 year old COBOL environment than to deal with some "cool shit" solution that gets updated every 10 minutes by two guys who have never had a date and haven't showered in 3 months that are more concerned with the XBox-Playstation debate than writing a program that works or with a "drag and drop" automatic web application that starts with no programming and ends with "I dunno... let's reboot and see if that fixes it"

It's not that COBOL can't handle variable width data. Instead, it was designed with the ability to view a flat data file as a database table BEFORE databases existed. COBOL reads an entire row -- not fields -- from the data file and assigns variables according to the fixed-width directives which define the variable fields. It can also can do things like zero pad numbers so there's none of that "if (ZIP < 10000)..." crap.

The real trouble with adding an email field to the mess in this article or to expanding the width of the field (remember the Y2K fiasco?) is two fold: 1- EACH AND EVERY PROGRAM that looks at the file MUST be recoded so as to redefine the data structure and then recompiled, but this can be made easier with the proper use of COPYBOOKs (yes, there is 'improper' use and it can leave you worse off than not using them at all); 2- EACH AND EVERY FILE must be converted by selecting all data into wider fields in a new table or file. Eaasy enough to do with a database table, but if you're using EBCDIC you have to also write a program to convert records from one file format to another while making sure to handle all the padding and othe conversion and then repeat this for all the files you need to modify and THEN you need to be sure to go through your entire code base to make sure that all your "if (ZIP < 10000)" type workarounds and all your date calculations will work correctly with the new files.

Now turn off your Xbox and go take a shower!

2014-01-08 Reply Admin

In the beginning, you had to meticulously write out your assembly language computer program - instruction by instruction - and then flip switches to enter it into the computer. Fast forward a few years and FORTRAN made its entrance. It was highly useful, but not for business applications. A bit later, COBOL came along, and the business folks were off and running...

This may well be the WORST 'history lesson' about computer languages EVER.

This first paragraph is the real WTF of this story.

2014-01-08 Reply Admin

faoileag:
Oh come on. If someone comes up to you and says: "Give me an estimate: how long does it take you to write a converter that takes a 2000 EBCDIC character large string as input and delivers an instance of the appropriate data object with its fields set accordingly?" do you answer "No prob, chief, give me 15mins"???

Yes, and then I spend those 15 minutes writing my resignation letter.

2014-01-08 Reply Admin

Anon:
Legacy systems should be burned to the ground, and their advocates with.
Legacy systems are the reasons we can't have nice things, such as functioning healthcare.

If you concede that "Expecting to get goods and services from my neighbor without having to pay him for it" is a Legacy system, then you are correct.

no laughing matter · 2014-01-08 Reply Admin

Bananafish:
It's not that COBOL can't *handle* variable width data. Instead, it was designed with the ability to view a flat data file as a database table BEFORE databases existed. COBOL reads an entire row -- not fields -- from the data file and assigns variables according to the fixed-width directives which define the variable fields.

You still end up with fixed-width variables, the variability only means you can have different combinations (or numbers) of those fixed-width variables.

Yep i once had to write a parser for such a mainframe data file. First an indicator byte to signal which record type / combination of variables to expect and then the still fixed-width variables (strings padded with blanks). Even XML looks slim in comparison!

Bananafish:
It can also can do things like zero pad numbers so there's none of that "if (ZIP < 10000)..." crap.

Uh, what?

System.out.println(new DecimalFormat("00000").format(123));
-> 00123

Besides: A ZIP is an identifier, not a number! Why-the-fuck to you want to treat an identifier as a number? You use numbers if you need to perform calculations on them, otherwise use another data type!

Bananafish:
The real trouble with adding an email field to the mess in this article or to expanding the width of the field (remember the Y2K fiasco?) is two fold: 1- EACH AND EVERY PROGRAM that looks at the file MUST be recoded (...) 2- EACH AND EVERY FILE must be converted (...)

And that is not a very strong indicator of a crippled language and data format?

As a Webservice is the topic of the article: A webservice is based on XML, and this means the schema is not hardcoded but defined in a separate file, where it can be changed centrally. If you made hardcoded assumptions about the schema that means either your program is a WTF or you were forced to do it because your programming language is crippled!

2014-01-08 Reply Admin

bjolling:
John:
faoileag:
John:
faoileag:
Tim:
faoileag:
If it costs X man hours to convert the legacy data delivered by the cobol system in the web service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.
what if 0<x<1? </troll>
Oh come on. If someone comes up to you and says: "Give me an estimate: how long does it take you to write a converter that takes a 2000 EBCDIC character large string as input and delivers an instance of the appropriate data object with its fields set accordingly?" do you answer "No prob, chief, give me 15mins"???
Comparatively speaking, yes.
Tim was just highlighting a flaw in my example - my assumption that X^2 is larger than X. Which isn't true if you allow for time units that are fractions of man hours ((1/2)^2 is 1/4).
There's always a nitpicker around to highlight such things - I know, I am one myself :-)

The square is always bigger and it's easy to prove. Construct a square of any side length X. This has area X^2, right? Now, take an identical copy of any of its sides. This has length X, yes? Now simply place it entirely inside the square. You might have to angle it a bit so it fits in there. X cannot be more than X^2 or it would not fit. Since by inspection you can see some unused space remaining in the square, X is in fact strictly smaller than X^2.

What if the width of one side is larger than X?

Then your square is broken.

2014-01-08 Reply Admin

anonymous:
...Then your square is broken.

What if X=1 ?

2014-01-08 Reply Admin

no laughing matter:
Besides: A ZIP is an identifier, not a number! Why-the-fuck to you want to treat an identifier as a number? You use numbers if you need to perform calculations on them, otherwise use another data type!

Whilst your ZIP example conforms to this rule, not everything does. Autonumber ID fields are identifiers and almost never need any kind of math or calculation performed on them; this does not make them a good fit for being persisted as a string.

We have DBAs here who constantly complain that our 4-digit site identifiers should all be varchar(4) instead of smallint. Problem is, most of our primary keys are entirely or partially made up of the store number column, and would double in size if they were to be converted to 4 characters instead of 2 bytes. On a table with millions of rows, suddenly the dogmatic view of "it's a name not a number make it a string lol!1" doesn't seem like quite such a bright idea.

2014-01-08 Reply Admin

snoofle, the word "intact" is not hyphenated.

2014-01-08 Reply Admin

faoileag:
Although in this day and age, you will probably not live to see the 2020s if you don't migrate, at least not if customer data is involved.

This.

Also, since it seems I was too vague in my previous posts, I wasn't specifically talking about the example in the article when I wrote about people who think it's a good idea to truncate data. But even nowadays, with modern applications (and by "modern" I mean that they aren't legacy applications that have been migrated, but something that was developed in this century), some people think it's a good idea to truncate data. But then again, "some people" are just stupid. ;)

2014-01-08 Reply Admin

Krunt:
anonymous:
...Then your square is broken.

What if X=1 ?

The width of one side still can't be more than X unless your square is broken.

chubertdev · 2014-01-08 Reply Admin

TheDailyWTF.com has officially run out of source material.

2014-01-08 Reply Admin

Are you saying the wtf is that software technology over 40 years old exists, and while powerful, it's not quite as versatile as other similar technologies developed with the benefit of 40 years experience?

Because that's like saying a caveman armed with an axe is a WTF, because he hasn't hit the nearby neanderthal village with napalm.

Or are you saying that the wtf is that some companies have existing systems that work really well, but because of changing times they want to add some extra functionality without breaking the old systems that work really well?

Because "if it ain't broke, don't fix it" is probably a principle that we should all adhere to.

Gene Wirchenko · 2014-01-08 Reply Admin

Anon:
Legacy systems should be burned to the ground, and their advocates with.
Legacy systems are the reasons we can't have nice things, such as functioning healthcare.

Ever written a system? Was it used for very long?

Six months from now, your new system is now a legacy system.

Legacy systems are how we got to where we are. It has been a long time since we could do without computer systems.

That stated, systems should be updated over time.

Sincerely,

Gene Wirchenko

Gene Wirchenko · 2014-01-08 Reply Admin

What is the wtf exactly?:
Because "if it ain't broke, don't fix it" is probably a principle that we should all adhere to.

Another is that there is a limit to the number of times that duct tape and its friends is a good solution. Technical debt and all that.

Sincerely,

Gene Wirchenko

2014-01-08 Reply Admin

What if X=-1?

Do I get math/science awards for finding a negative length?

herby · 2014-01-08 Reply Admin

For ZIP codes, it is pretty easy: use longs (there are zip codes greater than 65536), and then "%05ld".

As for COBOL: There is the story of the COBOL programmer who didn't want to be caught up in the Y2K whirlwind, so he enlisted a company to put him in suspended animation for a few years in 1998. Turns out they forgot about him, and when he woke up, he asked "Has the Y2K problem been solved?", to which they responded: "Yes, that was long ago. We woke you up when we realized you were a COBOL programmer. You see we have this problem with 4 digit dates and thought you might be able to solve it". He then asked: "What year is it?". The reply was "Oh, 9998. We have two years to get this working.".

Yes friends, COBOL will be around long after we have all figured out that 2100 is NOT a leap year.

p.s. Don't use floating points for money. It doesn't work!

DrPepper · 2014-01-08 Reply Admin

Cobol is of course alive and well. Take a look at this wtf article: http://thedailywtf.com/Articles/No_Need_to_Change_It!_.aspx

2014-01-08 Reply Admin

ZoomST:
We all were wrongly commenting here. Comments don't have exactly 2000 characters, and they are not in EBCDIC. WRONG! We youngsters, with these fancy web services, C-sharpies, Javanese beans, and new COBOL versions beyond the glorious '85... despicable us.

'85? Newfangled... I coded '77 Cobol. WATBOL, to be precise.

2014-01-08 Reply Admin

CrushU:
What if X=-1?
Do I get math/science awards for finding a negative length?

Negative length is just positive length in the opposite direction.

2014-01-08 Reply Admin

It's even crazier than that. In two dimensions, the side of the square is a null set, so it has measure zero. This means the side of the square fits infinite times inside the square. You will never be able to fill the square with sides.

2014-01-08 Reply Admin

anonymous:
Krunt:
anonymous:
...Then your square is broken.

What if X=1 ?
The width of one side still can't be more than X unless your square is broken.

But in that case X^2 is not > X. It's the same.

2014-01-08 Reply Admin

manamarama:
It's even crazier than that. In two dimensions, the side of the square is a null set, so it has measure zero. This means the side of the square fits infinite times inside the square. You will never be able to fill the square with sides.

Assuming zero thickness sides, yes. And you won't have to angle them. You'll only have to angle them if the thickness of the sides is nonzero, in which case you'll also not be able to fit an infinite number of sides inside of the square.

2014-01-08 Reply Admin

manamarama:
It's even crazier than that. In two dimensions, the side of the square is a null set, so it has measure zero. This means the side of the square fits infinite times inside the square. You will never be able to fill the square with sides.

You're missing something essential about measure and integration. In particular, null sets are "closed under countable addition". But in a hand-wavy sort of way, you can view integration as summation over an uncountable index. Countable addition does not apply. This is kind of the point of integration, and is the reason why we have measure theory, non-standard analysis, etc.

chubertdev · 2014-01-08 Reply Admin

Steve The Cynic:
(About the author: No, I don't live in Hawaii. I've spent a grand total of two weeks there in my life. One of those two weeks was the 9th to 16th of September 2001 (yes, that made leaving the place interesting), the other two years earlier. But I have a medium-weight interest in human linguistics.)

Yeah, I flew PVD to AUS on the 26th, and it was still pretty hectic then. Although not quite what my grandmother went through, attempting to fly BOS to DEN on the 11th, and ending up in BUF.

2014-01-08 Reply Admin

Krunt:
But in that case X^2 is not > X. It's the same.

That has nothing to do with the post which I was replying to in my original post. Read it again:

anonymous:
bjolling:
John:
The square is always bigger and it's easy to prove. Construct a square of any side length X. This has area X^2, right? Now, take an identical copy of any of its sides. This has length X, yes? Now simply place it entirely inside the square. You might have to angle it a bit so it fits in there. X cannot be more than X^2 or it would not fit. Since by inspection you can see some unused space remaining in the square, X is in fact strictly smaller than X^2.
What if the width of one side is larger than X?
Then your square is broken.

Loose Bree · 2014-01-08 Reply Admin

"Fixed-width is enough for all!" "And do it all with COBOL!" said Manager man who's web service plan was just a hell-bound snow ball.

2014-01-08 Reply Admin

manamarama:
It's even crazier than that. In two dimensions, the side of the square is a null set, so it has measure zero. This means the side of the square fits infinite times inside the square. You will never be able to fill the square with sides.

If you take one of the sides and try to stick it inside the square, it just escapes out of the hole where that side was.

2014-01-08 Reply Admin

The WTF?

Fujitsu released COBOL.Net about 15 years ago. Creates web services quite nicely.

2014-01-08 Reply Admin

Cube wrangler.:
manamarama:
It's even crazier than that. In two dimensions, the side of the square is a null set, so it has measure zero. This means the side of the square fits infinite times inside the square. You will never be able to fill the square with sides.

If you take one of the sides and try to stick it inside the square, it just escapes out of the hole where that side was.

Only if you removed the south side of the square like a dummy. Or the north side, if you live in the Southern Hemisphere.

2014-01-08 Reply Admin

In my 30+ years experience in IT, the major problem with having variable-length fields is that at the end of the process there's normally a database table with fixed-length (or severely limited) columns. So you can change the web-services to allow for email addresses of 64Kb, but if the relevant database table only allows 50 bytes then you're wasting your time.

2014-01-08 Reply Admin

Charles F.:
John:
Instead, it makes much more sense to: 1. convert the COBOL directly into Java, which can run on the legacy AS/400s.
FTFY.

This, in the context of the OP, is a canard on AS/400s.

Everything on AS/400s was stored in relational-like tables. Source code was stored in tables. They had three columns: line_no decimal(6,2), source_text char(80), and date_modified decimal(6,0). (Y2K was handled by the date windowing technique: year > 39 implies century is 19.)

Maybe some mainframe programmers who were forced to port to an AS/400 created tables with a single 2000-character column, and studiously ignored all the built-in features like keys, indexes, views, ACIDity, etc. But that was not the way of the AS/400 at all.

2014-01-08 Reply Admin

Krunt:
We have DBAs here who constantly complain that our 4-digit site identifiers should all be varchar(4) instead of smallint. Problem is, most of our primary keys are entirely or partially made up of the store number column, and would double in size if they were to be converted to 4 characters instead of 2 bytes. On a table with millions of rows, suddenly the dogmatic view of "it's a name not a number make it a string lol!1" doesn't seem like quite such a bright idea.

Only "millions" of rows? What hardware are you running on? An Arduino? An extra 5 MB times maybe (10 columns and 30 indexes) has been immaterial since 2003 at least.

Now, if your DBA's were insisting that the smallint be replaced by a BLOB that is a Quicktime(R) movie of someone reciting the company mission statement, and then writing the site ID on a blackboard ... then you might have a problem.

2014-01-08 Reply Admin

herby:
For ZIP codes, it is pretty easy: use longs (there are zip codes greater than 65536), and then "%05ld".

That's completely and utterly wrong. Go wash your brain out with soap.

ZIP codes aren't just numbers and are not a consistent length either.

In the US, they may have a dash in them. In most of the world they are alphanumeric.

I regularly find online shopping websites that make it impossible for any US resident to enter their full ZIP or for almost any non-US citizen to enter their details at all.

If you aren't going to do maths on it, NEVER store it as a number.

But remember that ++i is maths...

2014-01-08 Reply Admin

Except... never saw e-mail address longer than 50 chars and maximum could be even 30.

CAPTCHA: secundum

Secundum, anyone who has e-mail address longer than 50 chars is a walking WTF himself.

2014-01-08 Reply Admin

no laughing matter:
Obligatory Comment: TRWTF is COBOL.
Even at the time of its invention there were already better alternatives (Lisp) which could handle more than fixed-width data structures.

Not only is COBOL crippled, it also cripples the mind. The inventors were dumb and it should be dumped!

COBOL was designed by woman...

2014-01-08 Reply Admin

sunnyboy:
In the beginning, you had to meticulously write out your assembly language computer program - instruction by instruction - and then flip switches to enter it into the computer. Fast forward a few years and FORTRAN made its entrance. It was highly useful, but not for business applications. A bit later, COBOL came along, and the business folks were off and running...

This may well be the WORST 'history lesson' about computer languages EVER.

This first paragraph is the real WTF of this story.

In the beginning, you had to meticulously write out your MACHINE language computer program... Machine language and Assembly language look a lot alike, but Assembly is a step "above" Machine language.

2014-01-08 Reply Admin

Maybe you won't find many email addresses with more than 50 characters, but some services allow you to specify multiple email addresses (comma-separated) in one field, and thus send the same message to a number of recipients.

2014-01-08 Reply Admin

Tux "Tuxedo" Penguin:
no laughing matter:
Obligatory Comment: TRWTF is COBOL.
Even at the time of its invention there were already better alternatives (Lisp) which could handle more than fixed-width data structures.

Not only is COBOL crippled, it also cripples the mind. The inventors were dumb and it should be dumped!

COBOL was designed by woman...

And here she is: https://www.youtube.com/watch?v=JEpsKnWZrJ8 https://www.youtube.com/watch?v=zWNADC_ZYlM

Web Services...The COBOL Way

Leave a comment on “Web Services...The COBOL Way”