Slashdot Mirror
US Postal Service Moves To GNU/Linux
twitter writes "The US Postal Service has moved its Cobol package tracking software to HP machines running GNU/Linux. 1,300 servers handle 40 million transactions a day and cost less than the last system, which was based on a Sun Solaris environment." The migration took a year. The USPS isn't spelling how big the savings are, except that they are "significant."
we don't have to ask if it runs Linux.
The higher the technology, the sharper that two-edged sword.
that's pretty damn good time to move a system.
Now f they could drop tues, thurs and sat mail service they would save a bundle.
The Kruger Dunning explains most post on
With all those "savings" are we going to see a decrease in the cost of postage?
Oh wait...
Beer is proof that God loves us and wants us to be happy.
Someone needs to get the facts!
If they switched to Windows instead, they'd probably see twice the savings.
Just ask the London Stock Exchange.
Your point?
There isn't anything wrong with COBOL for these kind of transactions.
The Kruger Dunning explains most post on
They moved their package tracking system to Linux? I wonder if, when you ask it where your shipment is, it will tell you to find it yourself in a condescending manner.
Does it make you happy you're so strange?
Submitted with the headline "Linux Penguin goes postal."
Tracking's going to waste a lot of time playing around with Compiz instead of working.
QamuIs Heg qaq law' lorvIs yInqaq puS
I see they used the Micro Focus COBOL compiler, which is not FOSS by a long shot.
Now they can run a couple of Postfix servers and put themselves out of business!
I have something in common with Stephen Hawking...
If you're 30-something, you rely on email.
If you're in your 20s, you use IM
If you're 13 like me, it's all Twitter, all the time. Bonus: I have no need to receive packages because I shoplift everything.
I'm sure I could get a dramatic speed improvement running Apple II 6502 code on an emulator on a Mac Pro simply because the emulator can run faster than the original hardware.
Given that it took 1400 Linux boxes to handle the load, I'd say your post is, at best ignorant, at worst, a blatant troll.
a) Just because it's COBOL, doesn't mean it was running on crappy hardware.
b) COBOL is far from dead, in that many applications running today are written in it. Believe it or not, it makes more sense to continue to run that old code than to rewrite from scratch in the latest shiny because they already know *it works*.
That was my thought, too. That's pretty impressive. If it's true, whoever coordinated the move really knew what they were doing. Maybe we should elect them to the highest office in 2012 ;)
I don't think they should drop any service, tho. But then I've never understood why Sundays were considered a "day off", even. It's just another day, no matter what religious people or anyone else consider it to be. The sun rises, the sun sets, there's nothing to differentiate it from any other day, outside of some superstitious people who happen to have had influence.
Hey, it's a capitalistic society we live in, right? We should all be working 24/7/365+1/4, right? For the greater good?
Pardon my sarcasm. Or don't. I do my penance on my days off. Like today. Penance being doing laundry, housework, cleaning out the cat boxes, working on the peace treaty with my SO, fixing odds and ends, etc. It's enough. Tomorrow will be another twelve hours of busting my ass saving people from the errors of their ways*. ;)
*I speak literally, there. I make most of my money being a maintenance person for apartment buildings.
SB
It's old. The more humans I meet, the more I like my cats. At least they are honest.
Have you ever coded in COBOL? I have. It is EXTREMELY easy. It is quite close to English and is not at all cryptic. I believe nearly any coder with any experience and a language reference guide can read through code and make changes were needed. It has been almost 10 years since I last wrote a PIC statement, but I am quite confident that not only I, but just about anyone could do it. While I think the stories about pulling old programmers out of mothballs (retirement) is rather heartening, I think they are blowing the problem out of proportion. What these companies should be doing is hiring experienced and mature coders who can learn COBOL then send them to school.
What I find disheartening is the fact that businesses are no longer able to see education and training of employees as a worthwhile investment. (I know why they probably don't see it as worthwhile and it has a lot to do with employee loyalty, but I have to insist that the problem of loyalty didn't really happen until employers started treating their employees as disposable... they have no qualms with firing and laying off people at-will and yet they expect employees to be loyal? Get real!)
they could still reap even more benefits by recoding for modern languages and coding practices
Maybe. The fact is it appears they successfully migrated the system to a new platform within a year. I have seen many "modern" systems still jerking around with UML after a year and I can't count how many were never brought fruition.
But then, this is the US Postal Service. COBOL's probably fast enough for the task.
COBOL has a lot of issues but speed isn't a big one. I'm willing to bet that on tasks that are appropriate to COBOL it would kick most "modern" scripting languages asses in terms of speed.
Leave the gun, take the cannolis.
1300 servers, processing 40 million transactions a day... that's about 30,800 transactions per server. Or one transaction every 2.8 seconds or so. With an entire Linux box dedicated to it.
I work in the scan processing group at FedEx. At peak, we see over 100,000,000 transactions a day. And that's handled on 45 linux boxes, and 12 more for the database, doing upwards of 6000 transactions per second during bursts. That's a peak of about 133 transactions per second, per box. That's a little better than 0.3 TPS for the Post Office. So we have about 400 times the performance with 5% of the hardware. By that margin, I could do their processing with about 25 boxes total. That would mean another 98% savings on hardware alone.
For some reason, I fail to be really impressed that they've gone from "Crappy performance and Expensive" to "Crappy performance and less expensive."
I wonder if I can get the bazillion dollar contract to rewrite their system... No, wait, my name isn't "Boeing" or "Lockheed" or Ken Murtha.
Life, the Universe, and Everything... in my image.
This will be helpful the next time I have a COBOL package which I want tracked.
Well, look on the bright side...
Now we can say, with all confidence, that the world's largest mail server runs Linux
No sig for the moment.
cost less than the last system, which was based on a Sun Solaris environment.
Two thoughts:
Advice: on VPS providers
If they're running RedHat, now they owe RH $349/year/box instead of paying Sun. That's not any cheaper.
If they've switched to CentOS or something else that costs nothing (and comes with no support), they could have switched to OpenSolaris, had an easier migration and lower retraining costs, and saved just as much money.
If they were paying Sun's extortion for hardware support, they were stupid. With the number of servers they have, they could easily come out ahead by buying some shelf spares.
I wouldn't be at all surprised to find out they were running a bunch of Sun E10Ks before and paying gigantic support bills and gigantic electric bills, and now they've switched commodity hardware and, guess what, it's cheaper! They probably could have switched to 650 (that's 1300/2, for those of you not paying attention) Sun T5120s and saved a bunch of rack space and a bunch of electricity compared to the Linux boxes.
Sure, so long as you never need to make any changes to the code. The surviving COBOL coders have gone back into comfortable retirement with the money they made fixing Y2K. So they've moved from old iron to a modern operating system; they could still reap even more benefits by recoding for modern languages and coding practices.
But then, this is the US Postal Service. COBOL's probably fast enough for the task.
So you're saying that COBOL is so hideously difficult, so byzantine, so labyrinthine in nature that no one could possibly learn it now? That programmers educated today have no possibility of understanding a language that was designed some decades ago? You realize that C is 30 years old now, right?
This sort of fear mongering through ignorance is getting stale. COBOL is just another language, and one that happened to be designed for ease of expression for less-than-stellar programmers. Legions of students have learned enough C over a weekend to code up the examples in K&R, so I'm actually quite confident that professional programmers can, without any prior experience in COBOL, learn the language, even become proficient in it, in a brief enough time to make modifications to existing code bases.
Look, we're talking about learning a computer language and modifying or maintaining code, not learning Elizabethan English well enough to write a new Shakespeare play that can pass off as an original. It just isn't that hard.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Will this allow them to improve their tracking system?
UPS has had an amazing tracking system for years. FedEx has improve theirs, to the point they have good estimated delivery dates and can show you what's going on with your package pretty well, like UPS.
When dealing with the post office, their system works but is... antiquated. When paying for any kind of fast shipping (overnight, two day) I can receive my package before the tracking number pulls up a package. It's not every time, but it's enough to make me not care much. What I really care about is estimated delivery dates. I want to know when I'll get my package. I usually don't care if my package is in NYC, Duluth, or San Antonio. It will get where it needs to go. I would rather have the step-by-step tracking information show up later and have things like estimated TOA show up fast.
I remember as a kid (I'm 26) you could order something from a catalog and you had basically no idea when it would show up from UPS, etc. Today I can find out where my UPS package was last scanned, nearly up to the minute. Very cool.
That would make a neat visualization. They should put that on their site, little packages moving along their correct routes around the country.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
I have to agree. When I was 19 and interning in the accounting department at a chemical plant, I was asked to add a new field to one of their systems because I knew FORTRAN. I looked at their code, told them that it was not FORTRAN, but I thought I understood what was going on. They said fine. After a couple of hours of monkey-see-monkey-do I had made the change and verified that the field showed up on the screen that they wanted it on, saved the values as expected and showed up in the modified reports where they wanted. It was not until over 20 years later that I looked inside a COBOL book and realized that I had been unknowingly 'tainted'. It was that easy.
COBOL is not "slow". It is a compiled language. Sure the source code may involve a lot more lines and words than the equivalent C, but it likely compiles down to roughly the same size.
Since the article mentioned that the code was ported I'm assuming it was natively compiled and not just running under an emulator.
http://www.linuxjournal.com/article/2985
Linux has been sorting the US Mail for over a decade, and doing it faster, cheaper, and more accurately than it ever did before.
Actually, I use to code in Cobol, and there are lots of problems with the language as a language.
It isn't even a full procedural language let alone not object oriented. The alleged advantage of the "English-like" syntax is actually a big disadvantage because it is wordy and hard to skim, or see the structure of the program.
It's saving grace is the fully defined data structure that makes it easy to read and write records.
The problem with Cobol is that it was designed by a committee which really didn't understand what problem they were trying to solve. They thought that if you made programming languages more natural, it would be easier for programmers to program in. It was at least 15 years before the concept of top-down programming.
No, Cobol was a bear to program in. It isn't the worst language I've ever used (Fortran 66, 8085A assembler, APL, Thoroughbred Basic, Cadol, and RPG were some of the languages I use to know.) But, it certainly there in contention with the worst of them.
OPenSolaris isn't dying and BSD isn't dead. That just FUD spread by pepople that don't know any better.
and that is reality, so right back at you.
I may not be a smart man, but I know what an inode is.
COBOL runs quite fast; it is a compiled language that was designed from the start for compiler optimization of business logic code. Think in terms of well written C.
COBOL's reputation for being slow has to do with writing the programs, and dates back to its earliest days when code had to be written as SET RIDICULOUSLYLONGVARIABLENAME EQUAL TO 2 PLUS 2. Development time sped up a lot when Gracie was finally convinced that RIDICULOUSLYLONGVARIABLENAME = 2 + 2 would work as well (the original approach had to do with coders handprinting the instructions on coding forms that were then given to keypunch operators who knew nothing about computer languages but could type really fast and accurately... so long as their fingers didn't have to reach too far from the home keys).
I was never found of COBOL in school, and never did much with it. But I agree with others that anyone who has worked with a couple of programming languages could probably master COBOL in a matter of hours: in retrospect, it is basically a simple and obvious language. What I probably could not do is reverse engineer some of the constructs that were used back in the day: a lot of weird code was developed to work around hardware limitations that no one born after 1980 will have ever seen. Much of that wasn't documented well, and I think that is why old COBOL programmers are in demand. They remember that this particular type of data structure was used to optimize read-write operations on dual high speed tapes... to a younger programmer it just looks like arbitrary stupidity and they don't know what to do with it.
Will
Sure, so long as you never need to make any changes to the code. The surviving COBOL coders have gone back into comfortable retirement with the money they made fixing Y2K. So they've moved from old iron to a modern operating system; they could still reap even more benefits by recoding for modern languages and coding practices.
There's seldom a benefit to be found in taking millions of lines of code that are working exactly as needed and re-writing them from then ground up simply because the language isn't snazzy enough. There's a large number of COBOL programmers still in the work force; even if they all charged premium if the system is maintainable it will be still be cheaper than writing a new one. Yours is the same kind of thinking that leads people into buying new cars every few years -- "Well, it will cost less than repairing the old one when it breaks down". In both cases, it is a very rare exception for the most expensive available alternative to cost less.
But then, this is the US Postal Service. COBOL's probably fast enough for the task.
COBOL compiles down to executable machine code (presumably ELF) -- language isn't going to affect performance here.
Actually I've read Fortran was faster than C back in the 80's because it did not suffer from pointer aliasing and the like. Basically it was a simpler language and thus easier for a simple compiler to turn into efficient assembler. I've also see a surreal page where Basic code was translated into SSE assembler. Obviously the mapping from Basic arithmetic to SSE is pretty trivial to do. That's probably true of Fortran or Cobol but it defintely isn't true of C or C++ once the compiler has to worry about pointer aliasing. A lot of C programmers tend to concentrate on writing easy to read code and let the compiler turn it into something efficient too, it's a very different mindset from people who told the compiler exactly what sequence of operations they wanted because optimizers weren't practical.
That being said if you look at the output of a modern C compiler it is very very good. Still back in the days when more primitive languages were popular, I think that was not the case.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
From memory, this is the routing the letter took.
1) Road Vehicle, Post Box to Airport
2) Helicopter - Scilly Isles to Mainland (Penzance) (Scheduled Service)
3) Road Vehicle to Airport (approx 80 miles)
4) Plane (1) to East Midlands (Mail Charter)
5) Plane (2) to Edinburgh(Mail Charter)
6) Plane (3) to Kinross (Mail Charter)
7) Road Vehicle to Inverness ( at least 30 miles)
8) Plane (4) to Kirkwall (Mail Charter)
9) Road Vehicle to Destination
All in less than 24 hours. Ok, the distnce (approx 850 miles) does not stack up against the distances in North America but for the number of steps the mail took I think it is pretty impressive.
When it works, Royal Mail does good work but all too often the 'posties' are out on Strike often over trivial things. When I was a student and worked delivering the Christmas poat, the locl sorting office went on strike for a day. The reason? The Canteen (works restaurant) had decided to limit the number of Tomato Sauce sachets that were given away free with a full breakfast to two instead of three. Total Stupidity if you ask me.
That said, the people who deliver the mail as opposed to those who sort it in the back office are far more in touch with the real world and often (like their USPS bretheren) got to extra ordinary length to deliver the post.
I'd rather be riding my '63 Triumph T120.
I think the summary and the TFA are a bit confusing. It probably would have been better had the summary linked not just to the TFA but also directly to the gcn.com article which is linked to from TFA, or maybe better yet, just to the gcn.com article. What I get from that gcn.com article is this:
a) There is a mainframe that is talking to ~1300 "midrange" servers.
b) The mainframe is an IBM Z-series which has been shifted over from an IBM proprietary OS to Novell SUSE Linux.
c) The COBOL code is running on the *mainframe*, not the ~1300 servers! (TFA summary is wrong on this)
d) Because the mainframe is now running Linux, and because of a USPS IT decision to standardize on Linux (this is why OpenSolaris was never an option - sorry OpenSolaris fans), they're now converting the servers to Linux as well for better interoperability between the mainframe environment and server environments.
e) As for what this system is actually tracking:
Events are transactions that occur at the service's retail counters, such as shipping and picking up packages or the delivery of priority mail by carriers to businesses and residences. The mail is scanned to confirm delivery, and that information is sent to the PTS database. ...
âoeWe're inserting like 40 million events a day,â he added. ...
The PTS has 56 transaction types, such as acceptance scans and delivery confirmations, that have now all been migrated to Linux.
The gcn.com article has more info, but even it is confusing to me. Questions:
What is an "HP Linux Environment" (Does HP have its own version of Linux? What distro is HP using?)
Any Z-series gurus reading this want to chime in and explain what the IFL actually is (Page 2 of article)?
Yes, I know, I could Google for those answers, but I'm already worn out just doing what the original story submitter should have done. Just consider the above an "improved summary". :)
When every hiring manager skims your resume looking for the latest trendy buzzwords, a thinking person who wants to be hired will quickly realize that experience with those tools is a necessity if you want a career in software development. "Kids" (really now, we're talking about most developers) do not want to maintain or program COBOL because they know they will not be hireable after a several year stint at a COBOL shop.
Camping on quad since 1996.
Because it provides a social necessity.
If the service was not socialized then small communicates will either not be served or would have to pay more to send (or even receive) a letter.
IANAL but write like a drunk one.
There's seldom a benefit to be found in taking millions of lines of code that are working exactly as needed and re-writing them from then ground up simply because the language isn't snazzy enough.
In other words, if it ain't broke, don't fix it.. Programmers often like to "fix" things (i.e., rewrite them) and you're absolutely right: the best management decision is often to leave it alone.
The higher the technology, the sharper that two-edged sword.