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*.
Believe it or not, my alma mater teaches a 1-semester COBOL class. Nothing terribly modern (Cobol-85 when I took the course in '01), no object-oriented stuff, but apparently we're in demand from certain companies.
Hail Eris, full of mischief...
E pluribus sanguinem
Article: "...which was based on a Sun Solaris environment." Me: You should pay attention before posting. Me: Oh, ok.
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.
If you had recompile the arithmetic module of your browser, it would have been ok. Fucking noob can't read the documentations...
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's because those boxes had thousands of people working on them over the years.
Don't confuse good codebase with millions of hours of effort. That's comparing fruits to vegetables...
So says my brother, anyway, who made a fortune off of fixing non-Y2K compliant machines.
Me, I was fixing windows home boxes at the time, and just laughed. Mostly. ;)
SB
It's old. The more humans I meet, the more I like my cats. At least they are honest.
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
I believe nearly any coder with any experience and a language reference guide can read through code and make changes w[h]ere needed.
And any coder with no knowledge of any other programming language would find COBOL enjoyable to code in.
Having run personally comparisons of Cobol to Modern coding languages on the same box, Cobol kicks but due to the much lower overhead per transaction. And Assembler is even faster.
Sounds to me like you are arguing my side of the case, whether you realize it or not. COBOL is not meant for all kinds of problems but it is very good at what it does, particularly things like transaction processing.
Leave the gun, take the cannolis.
"Sauce code" FTW!
Obama is a twitter sock puppet
Don't be so sure. Back in the day it looked pretty good coming from assembler, especially when you realized they were going to pay you the same amount of money. And most people today don't realize what a pain in the ass pre-ANSI C was.
Leave the gun, take the cannolis.
thing. OpenSolaris is just as expensive as linux (as in free). and last time I looked OpenSolaris runs on HP hardware as well as linux. Now if you need technical support it's going to cost you either way.
I may not be a smart man, but I know what an inode is.
This is an extremely true statement. No one to my knowledge has ever claimed to enjoy coding in COBOL. It is a horrible language when it comes to being slick and creative. It is very simple and dry and has a lot less opportunity for variation in coding styles. But then again, COBOL was designed with that in mind and was quite successful in that. It gets the business jobs done quite well though which makes its name rather apt. I couldn't imagine anyone using COBOL to write a game or a utility or any complex application. But then again, I learned it on a mainframe type of environment and used it essentially as a report generation language.
I don't know why the USPS wishes to cut cut costs. Postage hasn't gone up, it is still just 2 cents a day.
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.
Now we know what Ballmer does when he runs out of chairs...
;)
"...there are some things that can beat smartness and foresight. Awkwardness and stupidity can." ~ Mark Twain
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.
Why not move to OpenSolaris?
- oZ
// i am here.
postgre?
rewriting history since 2109
They started using it 12 years ago for scanning destination addresses with OCR software. http://www.linuxjournal.com/article/2985 I already know someone is going to say something about that is why their mail got lost, got redirected to /dev/null, etc...
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 know COBOL. However, I would consider coding in it only if terrorists catch me and made me code in it at gunpoint.
I hope all of their terminals run Linux because their history with mixed systems is horrible. If the number of packages I've lost after FedEx hands my SmartPost packages over to USPS is any indication I'd hate to see what happens if they run their software the same way.
Was Cobol left over from a Mainframe that was migrated over to Sun Boxes? Generally speaking Solaris is not a platform that one chooses for Cobol.
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.
Haven't you heard of W.A.S.T.E.?
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
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.
designed for ease of expression for less-than-stellar programmers
Actually it was designed to be "self-documenting" more than anything and it is pretty successful at that. Most programmers should be able to pick up a COBOL program and figure out what it is doing pretty easily. That it was/is relatively easy to learn was a bonus.
Trust me, the same kind of people who were writing crappy COBOL code 30 years ago are today writing crappy Java or C#. It's rarely about the language.
Leave the gun, take the cannolis.
I think the reason many keep hiring older coders to handle COBOL is that the kids freak out when asked to program in anything that's not a trendy buzzword.
The big snag with COBOL is that it is boring, and intended for boring applications run by boring people. Fresh out of school most students don't want to do the boring stuff, not realizing there aren't enough rock star jobs to go around.
I'm sure the libertarians will chime in that they could do that much cheaper if the (subsidized) USPS weren't in the way...
I am happy with the USPS, and, coincidentally, it happens to be mandated by the US Constitution.
Now if the Federal government would stop doing things that it is NOT constitutionally authorized to do, maybe those things would run smoother.
This issue is a bit more complicated than you think.
If they were writing everything from scratch, it would be better to use a modern programming language. It would run faster and be easier to maintain.
However, you have something that works and does millions (if not billions) of dollars of business each day. The question becomes "How much downtime is acceptable for the Post Office in order to rewrite their software into a modern language?"
If you can't have any downtime, you do things really, really carefully.
Besides, how would it help Linux if the Postal Service is dragged in front of Congress for system problems because they were switching to Linux and Open Source Software? Microsoft would have a field day with that.
I agree. That's why I was careful to insert the word "mature." I understand and agree with the boring aspects of COBOL. But the fact of the matter is that it's work and it brings money home to feed the family. I know I'd definitely go for coding in COBOL right now if someone were to give me the opportunity.
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.
Well. All this talk of speed. Are we talking speed of execution, or speed of development? I would be willing to bet the speed of development under COBOL would be relatively poor, compared to just about any other scripting language you can think of. *Any* language, in fact.
Can you imagine doing *anything* with an associative array in COBOL? Even (shudder) OO-COBOL?
Right, because having system in Solaris, they could not migrate to OpenSolaris, hence chose Linux instead...
Divide by around 4 for a standard working week and then add a bit more for peak times and expansion, plus the fact that those machines are probably doing something a bit different to your inhouse workflow. Also do they call a transaction everything dealing with an envelope and does FedEx do the same?
The comment was definitely about execution speed.
I can't argue with the ease of development using scripting languages. That's their main selling point so they better excel at it. However, in COBOL's problem domain it could stand up to a Java or C++ or C# reasonably well in development speed. COBOL gets a bad rap for being verbose but have you seen Java, et. al. lately? That said, COBOL really falls down in terms of ease of code reuse and that's where modern languages have a distinct advantage.
I can't comment on OO-COBOL. I on bailed that segment of industry long before it became available. The COBOL I knew didn't even have dynamic memory allocation.
Leave the gun, take the cannolis.
COBOL is actually 50 years old. Commander Grace Hopper was the principal inventor of the language, starting in 1959. More on Grace Hopper at http://www.ideafinder.com/history/inventors/hopper.htm
Except it's GNU/Linux running COBOL code.
It's been a while since I've taken a CS class, but doesn't COBOL compile to a binary? For what the USPS needs, it was probably more economical to port their old COBOL code over to Linux, instead of rewriting ungodly numbers of processes in a snazzy new language that 1) they may not know as well 2) wouldn't necessarily run faster than the stuff written originally in COBOL.
One problem is that from an accounting perspective, employees are seen an an expense and fail to see them as an asset. There are also assumptions and failures to appreciate how important knowing and understanding the business is. I have seen time and time again where a company thinks they can simply toss out old people and bring in new people as if the experience and understanding of THAT particular company were worthless. The common story of companies being forced to bring back their previous fired COBOL programmers because they realized they were completely mistaken is a pretty extreme example of this. Typically, when a company realizes it has made a mistake, it never admits it and spins it to sound like it was part of a plan... kind of the way Coca-Cola did when it changed its recipe from sugar to corn syrup... everyone was so busy complaining about "new coke" and grateful to get "old coke" back that they didn't realize that it now has HFCS (high fructose corn syrup) which simply isn't as good as sugar.
In any case, most companies won't admit to making any sort of mistake when it comes to hiring and firing. I was once replaced by one of those IT outsource firms and I still haven't heard the end of complaints from the users I once served about how bad it is there... people can't get things fixed soon enough or well enough. Try as much as you like, but IT isn't as "cookie cutter" or "one-size-fits-all" as C-level management would like to believe.
I'm in the middle of porting an accounting system that's currently Cobol-based, and running on an RS6000/AIX, to Linux using OpenCOBOL . OpenCOBOL is GPL'ed too. The machine hardware I'm porting to is an HP Proliant DL380 and the distro is Red Hat Enterprise 5 64-bits. So far everything is going great. I'm not even a Cobol programmer, and had to alter very little of the application source code to compile and run under OpenCOBOL on Linux, mostly just some raw unix file I/O code, and it took me less than a day to learn enough Cobol to fix the source code and recompile it to work under Linux.
I have asked this question before and never got any real answer:
What resources are currently available for someone who's interested in learning Cobol? It seems that most books are long out-of-print.
It may be an easy language to learn, but some comprehensive documentation would be nice to have. Opencobol is available with a simple "yum install" on Fedora Linux. But... what comes next?
If you're a zombie and you know it, bite your friend!
Trust me, the same kind of people who were writing crappy COBOL code 30 years ago are today writing crappy Java or C#. It's rarely about the language.
That's a good thing. There needs to be languages for the majority of the area under the curve. Some language geeks here will argue whether Python or Ruby or Brainfuck are the most perfect languages, and start debating closures, lambda calculus, and co-routines, but in the real world most programmers are looking at them and going 'WTF is wrong with these people?', deserved or not.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
What resources are currently available for someone who's interested in learning Cobol? It seems that most books are long out-of-print.
Find someone who's been programming in COBOL for 30 years, borrow his 'Learning COBOL' book, and engage in copyright law civil disobedience. Throw up a torrent when you're done.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Slick and creative eh? I bet your one of those types who doesn't wear a suit conforming to DOCNR XQ3451/82.
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;
Actually I don't know why people complain so much about Cobol. There are much fouler propietary languages around in any company that start off as quick and dirty hacks and have gradually been extended and changed to work around the initial flaws and limitations. Most of those are seriously horrible to go in and change because the only documentation is the source code for the buggy tool that parses them.
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;
Or you lost your job and a COBOL job opened up.
Which leads me to : My COBOL programming wife is still looking for a job. I sent her to the USPS web site to see if they still need programmers. We are not seeing many jobs otherwise, despite everyone saying "companies are hiring back their COBOL programmers". I think the jobs all went to India.
Ok, I'm with you. You're saying its really really easy. Right? Lets just read more of you statement attesting to its ease.
Whaaa? School? to learn the language? I thought "It is EXTREMELY easy"? Do you think I went to School to learn any of the programming languages I currently use?
But really, we don't train employees with everything they need to know. They are expected to know how to teach themselves the skills necessary to accomplish the job, as they do it. If that means a new language, so be it.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Of course you could get a dramatic speed improvement running Apple ][ code on any emulation, even another 6502 machine. One of the Apple ][ features is that it was underclocked by 50% to run cool enough that it didn't need a fan and you rarely had to reseat chips that were climbing out of their sockets from thermal creep (the bane of all those poor fools who were messing about with the Trash-Eighties).
Once I was the proud owner of what might have been the very first second hand Apple ][+ on the market between San Francisco and Portland. It had a fully populated lower 48 of RAM! Dual 5.25" floppy drives on ribbon cables! Use it during prime time on TV and ruin the reception of all your neighbors, who couldn't imagine what could be causing those squirmy worms that distorted their Dukes of Hazzard show!
Ah! I am SO glad that those days are now distant memories!
Will
It seems that most books are long out-of-print
I just came up with 16 COBOL books on Amazon.
Opencobol is available
Don't know how good that compiler is but I don't think that's the main impediment to learning the language. It's kind of boring. It's great at reading, processing, and writing data. It's good, but slightly cumbersome, for reports. But beyond that there isn't much to be done with it. So unless you have some ready-to-go datasets to process at home I think it would be hard to sustain interest.
Leave the gun, take the cannolis.
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
As others have pointed out, stamp prices are quite reasonable. They've even solved the hassle of makeup stamps by issuing the "forever" series. Why would I want to buy any other kinf of stamp?
No, if there's one thing that bothers me about the USPS, it's bulk mail. I send all of it straight to the recycling bin, often without even opening. It's a horrible waste.
Of course, without bulk mail the stamps would cost even more since apparently bulk is a proft center. I'd be willing to pay extra for 1st class if I could opt out of bulk though.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I was under the impression that COBOL was a programming language and not an operating system.
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.
Agree. There is too much emphasis on "making the numbers" in the current quarter. Boards of Directors don't have patience for investing for future and sustaining profits. Training the workforce will not pay off this quarter.
Ha Ha, have you tried the public library?
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". :)
I imagine the savings have more to do with switching from Sun hardware to HP hardware than switching to Linux.
No you do not understand so have the wrong numbers.
To put things simply they are not a 24/7/365 operation even if you are so the number of transactions per second is going to be different for a the same number of transactions per day (idle or reduced capacity at night remember). Then there is the consideration that what you call a transaction may be very different to what they call a transaction. The text seems to imply one per item delivered.
Anyway, I have had no contact with FedEx since a forklift tine shaped hole magically appeared in the side of one of my servers in transit with apparently no involvement by FedEx. I know it's huge but my point here is real world estimates of values should be shaped by the conditions that constrain then instead of a rough transactions per day divided by 86400 = transactions per second. That's MBA thinking and nowhere near a model of the real world as defined by when you can get people to feed stuff into the machines.
http://gcn.com/Articles/2009/07/13/Update2-USPS-open-source-Product-Tracking-System.aspx?p=1
The service is moving 1,300 Sun Solaris midrange servers to a Hewlett-Packard Linux environment. USPS is using Novellâ(TM)s SUSE Linux on the mainframe and distributed computing platforms to forge greater interoperability between the two environments, Byrne said.
Yet Socrates himself is particularly missed.
A lovely little thinker but a bugger when he's pissed.
So it's like when someone has ingrown toenails, but at least he's finally bought himself some spiffy new shoes.
....all I can think is how lame the Sun salesman must have been.
Yeah, Chip sucks at computer. emailed from my Macwheel.
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[...]
You mean: ADD 2 TO 2 GIVING RIDICULOUSLYLONGVARIABLENAME
and: CALCULATE RIDICULOUSLYLONGVARIABLENAME = 2 + 2
It gets worse with operations with longer names and other variables:
MULTIPLY WEIGHT-OF-SPARROW BY NUMBER-OF-SPARROWS GIVING TOTAL-WEIGHT
-- Wodin
Typical: one publication writes a shitty article, another publication does a shitty job of summarizing it, then a /. submitter does a shitty job of summarizing the shitty summary of the shitty article, then hundreds of posters babble about the cost of postage.
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.
COBOL handles with ease big volumes of data, because normally the data is organized in a very methodical fashion (more often than not DBMS are the direct replacement of old COBOL systems).
People deriding COBOL for its speed simply don't know what they are talking about.
IANAL but write like a drunk one.
"I couldn't imagine anyone using COBOL to write a game or a utility or any complex application."
And then
"I learned it on a mainframe type of environment and used it essentially as a report generation language."
Well. Duh!
IANAL but write like a drunk one.
In which kind of Communist country do you live?
IANAL but write like a drunk one.
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.
Yay, now this icon I made some years ago has become more relevant: http://www.linuxcentral.com/_v3/_site_components/html/data_box/left_gray_box/hdr-newsletter.gif
so they can ship more junk mail. That's pretty much what the PO do nowadays since online billing is widely available.
My cell provider (Turkcell) has an excellent offer for digital signatures which is actually embedded in sim card itself. It can be used dynamically for realtime signing, logins (single login) etc.
Details in this pdf http://www.turkcell.com.tr/c/docs/bultenler/20081219_Turkcell_Mobile_Signature.pdf
Just before I jumped to it, I remembered I use OS X only and wondered what happens to actual signed mail (govt. accepted), pdf signing, login extensions... Guess what? No support even on such device independent (e.g. no Win Mo) solution. Absolutely nothing.
I think the digital signature schemes suffer from windows dependence these days especially if you think about iPhones (Unix) and Nokia. I don't know about Win Mobile scene, I wouldn't be surprised if they basically work.
What is the situation on Linux?
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.
Dead on. Loyalty is purchased with loyalty. Fire employees at the drop of a hat (pick your euphemism: terminate, make redundant, lay off, downsize, right size, etc) and you'll find that employees will also quit at the drop of a hat. Offer entry level salaries while insisting on highly educated people and the supply of highly educated people in that field will dry up.
Offer a fair deal where termination only happens for cause and your workforce will quickly become equally loyal.
Big surprise, short-sighted corporate management comes back to bite their asses.
The real problem is that they want to demand people with at least 5 years of experience in COBOL, but nobody is willing to be the source of that experience. This naturally means the the pool of 'qualified candidates' is quite small. Since it's been that way for many years now, that pool is also shrinking fast. It reminds me of actual job listings I saw demanding 5 years of experience in Java when Java had only been out for a year.
Thanks for the corrections. I still have a COBOL manual around, somewhere, I think. But the last time I opened it was nearly 20 years ago.
Will
It's saving grace is the fully defined data structure
And its saving Grace is Admiral Hopper.
Squirrel!
I know COBOL.
[Lex] "This is a COBOL system - I know this !" [/Lex]
Squirrel!
Creators Admit UNIX, C Hoax
Squirrel!
Normal communication? You're right, probably not. :)
However, moving around physical merchandise (in my case trading cards), yes. Can't email that stuff quite yet.
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
I have heard that for years, but every COBOL programmer I know is making top dollar and in demand.
The Kruger Dunning explains most post on
FedEx already does a lot of the back-end processing/moving-of-stuff for the USPS's Express Mail options
A more visible-to-the-end-user sign of this may be FedEx drop boxes right next to a Post Office location, maybe because the FedEx people are making pickups anyway?
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
As a software programmer, I must say that COBOL is incredibly hard and no one but a few of us select people could possible maintain it ... for less then 125 an hour.. *cough* ~
The Kruger Dunning explains most post on
http://xkcd.com/281/
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
Well, it is not practical to name it GNU/Linux but when people forget the "GNU" part, they poison the decade+ old legendary Debian with MS patents and behave like nothing interesting happened.
Read the F'n Mail!
Slashdot, where armchair scientists get shouted down and armchair theologians get modded up.
What resources are currently available for someone who's interested in learning Cobol? It seems that most books are long out-of-print.
I've recently decided to have a look at COBOL just for the sake of it, and, to my surprise, there was a bunch of more-or-less recent books on O'Reilly Safari about it. Here are those that were published after 2000:
I've found the first book to be a reasonable overview of the language; I didn't yet look at the second one.
... my neighbor post office worker is smirking, I wonder if they will start wearing a penguin badge.
TOP DSLR Cameras Reviews of the top DSLRs
COBOL, yeah, but COBOL on Linux..
TOP DSLR Cameras Reviews of the top DSLRs
The GCN article this is based on has many significant factual errors. HP is not really involved. The migration is to IBM's ZLinux, which is SuSE Linux running on the Z-Os platform, as virtual servers. Hewlett-Packard has nothing to do with it other than managing hardware. It certainly isn't "HP Linux". The number of servers quoted is not how many are used for tracking. More like the total number being migrated. Sadly, the part about the COBOL stuff is true, though only chunks of the app were written in COBOL (i.e. those that ran on the mainframes). Mostly it's the stuff that relates to finances, not surprisingly.
In the darkness of future past, The magician longs to see. One chants between two worlds, "Fire, walk with me!"
Don't be so sure. Back in the day it looked pretty good coming from assembler, especially when you realized they were going to pay you the same amount of money. And most people today don't realize what a pain in the ass pre-ANSI C was.
That's not how I remember those days. I sort of worked for a small company delivering COBOL databases, really stayed only for about month-long training period. I already new COBOL well actually, and senior programmers were mostly refactoring old data-bases for new customers or restructuring them by adding new kinds or reports/fields and some such things. So when the senior programmer was showing me how to fulfill given wish list, I was mostly trying to figure out how he did this or that editing move in vi, especially considering the speed with which it was being done. vi beeps if you make a silly move, so you could differentiate by ear boyz from men. I also haven't used UNIX before, so that was also interesting. I don't remember really hating COBOL, I just found it very tedious and boring. It tries to make program very verbose, turning it into a novel, and that's not how programmer's brain work. For elegance I used Pascal, at least for a while until I learned LISP, which made programming languages interesting in their own right. And also lots of FORTRAN and BASIC, but above all assembler. In those days you would really try to squeeze out cycles from tight loops, or implement a fancy algorithm at low level, and that was fun. When C became more popular I didn't really see what's all the fuss about because the whole idea of "high-level assembler" was not impressive since we still had low-level assembler, and, needless to say, porting was not an issue, but performance was. Only when I tried to learn Motorola 68000 did C begin to make sense.
I've gotta go now to check my lawn...