The Daily WTF: Curious Perversions in Information Technology

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

She didn't even remove a bug. Her male subordinates did that for her.

2014-01-08 Reply Admin

REVOLUTION!

Scarlet Manuka · 2014-01-08 Reply Admin

Tux "Tuxedo" Penguin:
Except... never saw e-mail address longer than 50 chars and maximum could be even 30.

I thought I'd have a look in our database to see what we have in the way of long email addresses.

Most of them seem to be multiple addresses shoved into one field, or address + description ("Greg Smith - Company Name Redacted [email protected]"), though the winner is actually a 26-character long valid email address with 74 spaces in front of it (guess how long our email field is).

Once I filtered those out, the longest remaining were a few that looked like someone mangled two email addresses together in such a way that it could technically be a valid email address, but pretty certainly isn't (e.g. "[email protected]").

But the longest email address in there that seemed to be an actually valid, pure email address - was 52 characters. And there were three more at 51 characters. So I'm glad we didn't take your advice. Four customers may not be many, but why should we make it harder to market to them?

Of course, if we'd set it at 30 characters we would have missed a much larger number - a quick look says probably around 55,000. That would have been TRWTF.

(At 50 characters I spotted "[email protected]", but I am not counting that as a likely valid email address...)

2014-01-09 Reply Admin

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 :-)

Somebody should have pointed out that time^2 isn't a meaningful dimension for a programming task.

2014-01-09 Reply Admin

Scarlet Manuka:
Tux "Tuxedo" Penguin:
Except... never saw e-mail address longer than 50 chars and maximum could be even 30.
I thought I'd have a look in our database to see what we have in the way of long email addresses.
Most of them seem to be multiple addresses shoved into one field, or address + description ("Greg Smith - Company Name Redacted [email protected]"), though the winner is actually a 26-character long valid email address with 74 spaces in front of it (guess how long our email field is).

Once I filtered those out, the longest remaining were a few that looked like someone mangled two email addresses together in such a way that it could technically be a valid email address, but pretty certainly isn't (e.g. "[email protected]").

But the longest email address in there that seemed to be an actually valid, pure email address - was 52 characters. And there were three more at 51 characters. So I'm glad we didn't take your advice. Four customers may not be many, but why should we make it harder to market to them?

Of course, if we'd set it at 30 characters we would have missed a much larger number - a quick look says probably around 55,000. That would have been TRWTF.

(At 50 characters I spotted "[email protected]", but I am not counting that as a likely valid email address...)

As I said, people with such e-mail addresses are walking WTFs themselves.

tin · 2014-01-09 Reply Admin

Scarlet Manuka:
I thought I'd have a look in our database to see what we have in the way of long email addresses. <snip> the longest email address in there that seemed to be an actually valid, pure email address - was 52 characters. And there were three more at 51 characters. So I'm glad we didn't take your advice. Four customers may not be many, but why should we make it harder to market to them?

My bank's website once told me my email address is not valid, despite already using it for 2 of my 3 accounts. When I asked what the deal was, I was told that it's not valid due to a hyphen. Funnily enough, they managed to send the reply to that supposedly invalid address.

Scarlet Manuka:
At 50 characters I spotted "[email protected]", but I am not counting that as a likely valid email address...

That's the sort of email address I often put for websites with questionable motives... Normally I use better grammar in my email address, but sometimes I'm too annoyed to care :p

2014-01-09 Reply Admin

Decius:
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...
Somebody should have pointed out that time^2 isn't a meaningful dimension for a programming task.

I know. That's why I didn't write (X man hours)^2

2014-01-09 Reply Admin

admin@llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk might disagree with you.

2014-01-09 Reply Admin

Or we happily run UTF16? Cobol is updated slowly. But you won't break code from 85 without enormous good reason.

How many languages can still compile and run code written 25 years ago?

2014-01-09 Reply Admin

Steve The Cynic:
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.

You're TRWTF here.

Zemm · 2014-01-09 Reply Admin

Tux "Tuxedo" Penguin:
As I said, people with such e-mail addresses are walking WTFs themselves.

I once had to deal with someone with an email address like John.O'[email protected]. I wonder how many other sites he has issues with? It originally didn't occur to me to allow apostrophes in the email address.

2014-01-09 Reply Admin

The first 40 bytes were the client first name, the next 30 the last name, etc.

Ms Keihanaikukauakahihuliheekahaunaele does not approve!

Long-named US woman celebrates government climb-down

And let's hope this isn't spam now by adding this line.

2014-01-09 Reply Admin

Well... UTF-7 converts to 7-bit ASCII

But there's actually UTF-EBCDIC. Sort of like UTF-8 but with 160 one-byte-characters at the position EBCDIC expects them. All others unicode chars are generally longer than UTF-8 (1 to 5 bytes instead of 1 to 4 for UTF-8)

Yes, some sort of WTF in itself, but at least you can use Unicode there. "Just" add a transformation layer before displaying.

2014-01-09 Reply Admin

Conversion never dies. When your clients have all been forced to deal with the server's limitations and the server now gets replaced it just means that the old bugs and limits must now be BUILT INTO THE NEW SYSTEM as the clients all depend on them.

2014-01-09 Reply Admin

The maximum email address length is, by RFC 5321, 254 characters. Since that's not by any means impossible to store or process, your code should be written to accomodate it.

CarnivorousHippie · 2014-01-09 Reply Admin

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.

At the risk of feeding the troll, this is equivalent to stating that (a) sqrt(2) > 1, and (b) it's perfectly valid to disregard units of measurement when comparing numbers.

2014-01-09 Reply Admin

This is one of the reasons I really dislike how relational databases have been created - having to define the type of data and the length of it seems just as bad.

2014-01-09 Reply Admin

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

The your bank runs into the problem they had with me. I took a one year assignment to Europe. my "zip code" ( postal code was EW3017. They could send my statements to me, but could send other correspondence because that system could not handle my postal code.

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

I went oversea to help create European versions of our software ( French, Italian, German, Spanish ). When we went to test for cost, the Italian version went kablooey ( buffer overrun) because the system could not handle adding Italian lira

2014-01-09 Reply Admin

Cobol guy:
Or we happily run UTF16? Cobol is updated slowly. But you won't break code from 85 without enormous good reason.
How many languages can still compile and run code written 25 years ago?

Lots. Even the first C standard is celebrating its silver anniversary.

2014-01-09 Reply Admin

Tux "Tuxedo" Penguin:
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.

Really ? never work with anyone for India ? Our longest is 36. We routinely ask my boss to test because his is 32, which is our limit.

2014-01-09 Reply Admin

Loose Bree:
"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 SNOBOL.

FTFY

2014-01-10 Reply Admin

I'm not a COBOLer, but I'll argue pretty strongly that you are wrong on all counts. It's useful to regard the times, as core memory finally dropped below $.01 per bit - $10,000 per megabyte in the early 1970s, CPU cycles were in kilohertz, and hard drives had seek times on the order of 0.25 second. Virtual memory, timesharing and multiprocessing were bleeding edge.

At that time, almost any reasonably large program was likely to require overlays - part of the program was run, then swapped out while another part was run. The standard bank's mainframe in 1969, the 360-20, was pretty similar in capacity and performance to the PC-AT of the late 1980s.

Almost no 'business' program written in LISP would have been able to run on those machines at all, much less in any performant way. Those were times when programmers wrote self-modifying code and re-entrant routines with multiple entries and exits, to save a few bytes and cycles. It was HARD to fit a full high speed transaction processing system into one of those machines. And input was mostly via punch cards - no interactive editing here!

I was surprised to learn, from a co-worker in 1980, that COBOL on a DEC-10 could call assembler directly and had access to fast sorting methods (written in assembler) and hardware interfaces on the machine. It was substantially faster than C or any other language.

COBOL was if nothing else, an effective early tool that greatly broadened the field of people who could produce useful work on a computer, cleverly using terms that business and accounting people were familiar with and limiting the visibility of the essential simplicity of the compiler's ability to parse language. Admiral Grace Hopper, the primary inventor of COBOL, is a person worth learning something about.

2014-01-10 Reply Admin

John:
Julia:
...inevitably led to error codes "," and "(doublequote)". By that point any semblance of sanity in the CSV was well and truly gone...
...now everyone who has to read those CSV files will take longer to figure out what the F*%^ is going on...

TRWTF is not using standard .csv libraries that can escape special characters. Don't even try to complain about maintaining regexes that parse HTML.

no laughing matter · 2014-01-10 Reply Admin

Bob:
Don't even try to complain about maintaining regexes that parse HTML.

FTFY!

chubertdev · 2014-01-10 Reply Admin

Coding Practices MUST Be Followed:
This is one of the reasons I really dislike how relational databases have been created - having to define the type of data and the length of it seems just as bad.

/trout

no laughing matter · 2014-01-10 Reply Admin

Gary B:
I'm not a COBOLer, but I'll argue pretty strongly that you are wrong on all counts. It's useful to regard the times, as core memory finally dropped below $.01 per bit - $10,000 per megabyte in the early 1970s, CPU cycles were in kilohertz, and hard drives had seek times on the order of 0.25 second. Virtual memory, timesharing and multiprocessing were bleeding edge.

That's no excuse for incompetence! They stored years in a format that required only 2 bytes - but covered only years 1900-1999!

With two bytes with 8 bits you can cover 65536 years - even with 7bits-per-byte it's 16384 years - more than the usual 4-digit-format can represent!

So much for effective and memory-saving tools!

2014-01-10 Reply Admin

no laughing matter:
Gary B:
I'm not a COBOLer, but I'll argue pretty strongly that you are wrong on all counts. It's useful to regard the times, as core memory finally dropped below $.01 per bit - $10,000 per megabyte in the early 1970s, CPU cycles were in kilohertz, and hard drives had seek times on the order of 0.25 second. Virtual memory, timesharing and multiprocessing were bleeding edge.
That's no excuse for incompetence! They stored years in a format that required only 2 bytes - but covered only years 1900-1999!

Don't be ridiculous - of course the two digit years were stored as a single byte of packed BCD.

2014-01-10 Reply Admin

So why is it that I not only work with variable length records that are 8000+ characters long, but email addresses that can be up to 1000 characters? I'm still working mainframe COBOL that way just fine. When we pass stuff the the network it is automatically converted to ASCII as part of the download (IND$FILE does the conversion too, if that's what you want to use).

no laughing matter · 2014-01-10 Reply Admin

anonymous:
no laughing matter:
Gary B:
I'm not a COBOLer, but I'll argue pretty strongly that you are wrong on all counts. It's useful to regard the times, as core memory finally dropped below $.01 per bit - $10,000 per megabyte in the early 1970s, CPU cycles were in kilohertz, and hard drives had seek times on the order of 0.25 second. Virtual memory, timesharing and multiprocessing were bleeding edge.
That's no excuse for incompetence! They stored years in a format that required only 2 bytes - but covered only years 1900-1999!
Don't be ridiculous - of course the two digit years were stored as a single byte of packed BCD.

So 100 years where 256 would have been possible?

2014-01-11 Reply Admin

Trying to look into management's mind here:

This: --> cross-platform COBOL web service specification <--

looks like every new web service should be written according to the spec.

As in: When a C# app publishes an interface to a Java app, it still has to follow the spec. After all, Cobol might join the interface party at some future time.

2014-01-12 Reply Admin

I was a COBOL programmer in the 1970's and early 1980's.

COBOL always supported variable length records and variable length fields in records. It would also handle record lengths far in excess of 2k bytes. The practical record limit on IBM systems was about 32k bytes.

IBM's first SQL implementations used COBOL in SYSTEM R* and later DB2. There was no problem handling all the fixed and variable length data formats that SQL allowed.

Coyne · 2014-01-12 Reply Admin

Boy these guys are backwards...I'd at least accept the 2000 character string in ASCII. [roll eyes]

2014-01-13 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.

Ah, FORTRAN. I first learned to program in FORTRAN. In 2010.

2014-01-13 Reply Admin

Geoff:
ORLY:
Umm, the WTF isn't the 2000 character field, or even EBCDIC interface.
It's the fact that in 40 years, the COBOL system is still limited by these things. The fact that this Enterprise System still merrily truncates email addresses and this is considered acceptable is the WTF.

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.

The COBOL folks are still stuck in the 1970s, regardless of the interface.

I am not advocating doing a bunch of new development in COBOL. But this sounds like more a people and budget problem then a technology one. COBOL does bulk records processing very very well and its very easy to write a stable bug free code in. On any modern COBOL system you certainly can do character conversion at least to/from ASCII easily and handle Unicode (with some minor challenges).

The way I see it is one ore more of the following is true:

The COBOL team is working on a really old platform, like COBOL 85 or older and nobody will pay for the upgrade.

The COBOL team has lots of separate programs that work on the data, didn't use COPYBOOKS effectively and has built a very non-enterprisy mess of spaghetti that they can't maintain

The COBOL team has lost all of its competent members over the years and just ain't up to the job.

Agreed.

Since they mention ebcdic - that implies MVS / OS390 / zOS. Unless they are doing web services from a never ending batch job, they run COBOL in CICS - the app server of the COBOL world.

CICS TS supports Web Services and has for a long time now. Remember, CICS was released the same year as Unix. It's evolved over time. CICS Gateway is actually written in Java. They have mainframe commands written by the JES (Job Entry System) team that converts native CICS threads into Websphere's J9 JVM threads and back.

You want WTF - I know a night who was writing dynamic web pages in REXX just two years ago.

2014-01-13 Reply Admin

mainframe web developer:
Since they mention ebcdic - that implies MVS / OS390 / zOS.

Or VM/CMS, or DOS (not that DOS, that DOS), or whatever the 1130's operating system was called.

mainframe web developer:
Remember, CICS was released the same year as Unix. It's evolved over time.

Well, Unix allowed your program to call read() and write() all by itself from day 1.

2014-01-14 Reply Admin

no laughing matter:
anonymous:
no laughing matter:
Gary B:
I'm not a COBOLer, but I'll argue pretty strongly that you are wrong on all counts. It's useful to regard the times, as core memory finally dropped below $.01 per bit - $10,000 per megabyte in the early 1970s, CPU cycles were in kilohertz, and hard drives had seek times on the order of 0.25 second. Virtual memory, timesharing and multiprocessing were bleeding edge.
That's no excuse for incompetence! They stored years in a format that required only 2 bytes - but covered only years 1900-1999!
Don't be ridiculous - of course the two digit years were stored as a single byte of packed BCD.
So 100 years where 256 would have been possible?

In one case you simply take a (packed) BCD and paint it to the screen, in the other case you have to add a value to a starting year, transform to decimal characters (some divisions involved), perhaps cut to two digits, etc.

If you never expect your program to still run in thirty years, which would you use in, say, 1969?

2014-01-14 Reply Admin

Engywuck:
no laughing matter:
anonymous:
Don't be ridiculous - of course the two digit years were stored as a single byte of packed BCD.
So 100 years where 256 would have been possible?

In one case you simply take a (packed) BCD and paint it to the screen, in the other case you have to add a value to a starting year, transform to decimal characters (some divisions involved), perhaps cut to two digits, etc.

This. The reduction in capacity was an acceptable compromise considering the ease in processing BCD and besides, all of the code that used 2-digit years was surely going to be replaced before they needed more than two digits.

2014-01-17 Reply Admin

Very Nice article will definitely improve our knowledge... Being a Web Designing and Development company ourselves, we also provide some attractive,innovative websites You can view a few of our Web Services Here

Kuba · 2014-01-17 Reply Admin

You know what's the biggest catch in all of this? COBOL can be reasonably easily ported to oftentimes better performing C++. Easily, you ask? Easily as in machine-ported. I've helped with a project like that, and man, modern C++ compilers beat the crap out of legacy COBOL compilers.

Kuba · 2014-01-17 Reply Admin

Chris M.:
The maximum email address length is, by RFC 5321, 254 characters. Since that's not by any means impossible to store or process, your code should be written to accomodate it.

All the while many business "software" (clusterfuck) "developers" (dumbasses) have not even heard of an RFC. They just do it their way, obviously nobody before them gave it any thought and they must be the brave first tacklers of a "big" problem.

Snooder · 2014-01-17 Reply Admin

Tux "Tuxedo" Penguin:
As I said, people with such e-mail addresses are walking WTFs themselves.

[email protected] clocks in at 53 characters and is a perfectly valid example and not even particularly outrageous example of a professional email. Now imagine someone with a hyphenated last name. Or a slightly longer domain name.

The point here is that capping the length of a character field for arbitrary reasons is bad. It's acceptably bad for extreme lengths, or for fields that are almost certain not to approach that length. Capping at 50 characters for either a name or email address is not acceptable.

2014-01-21 Reply Admin

Snooder:
Tux "Tuxedo" Penguin:
As I said, people with such e-mail addresses are walking WTFs themselves.

[email protected] clocks in at 53 characters and is a perfectly valid example and not even particularly outrageous example of a professional email. Now imagine someone with a hyphenated last name. Or a slightly longer domain name.

The point here is that capping the length of a character field for arbitrary reasons is bad. It's acceptably bad for extreme lengths, or for fields that are almost certain not to approach that length. Capping at 50 characters for either a name or email address is not acceptable.

Yeah, now just imagine what Janice Keihanaikukauakahihulihe'ekahaunaele's e-mail address would look like.

2014-01-22 Reply Admin

anonymous:
Snooder:
Tux "Tuxedo" Penguin:
As I said, people with such e-mail addresses are walking WTFs themselves.
[email protected] clocks in at 53 characters and is a perfectly valid example and not even particularly outrageous example of a professional email. Now imagine someone with a hyphenated last name. Or a slightly longer domain name.
Yeah, now just imagine what Janice Keihanaikukauakahihulihe'ekahaunaele's e-mail address would look like.

janice.keihanaikukauakahihulihe'[email protected]

Web Services...The COBOL Way

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