Microbee Computers are Back

Is this a horses for course comment? Do you have any figures on the current percentage implementation of Cobol?

Reply to
terryc
Loading thread data ...

If it is above zero, it wouldn't be by much. COBOL was such a forgiving language that, in its day, thousands of programmers who should have starved to death paid off mortgages and raised families.

Reply to
T.T.

Was already studying programming, but the course was in Pascal which I wasn't a big fan of. There were a few sys admins and and real programmers there (keeping the old Vax 11/780 alive) who I got to know and undertook C programming myself (not part of the Uni course). Unix was written in C so it was a good place to start reading code. Surprisingly the code was very well structured and documented throughout, making it easy to understand.

In any case, you and I are not the target

Agree with that. The GUI sort of killed off the 'Ready>' prompt of the old Z80 machines.

Some changes from K&R C to ANSI C.

I remember the teletype machines and the old thermal printer terminals. Wrote a program that took over them from a remote console, allowing copious BEL and FF characters to be sent to them, surprising the first year undergrads :)

Reply to
swanny

It's so easy even I can use it

--









X-No-Archive: Yes
Reply to
atec77

Don't need a Coldfire processor to be run uCLinux. There's even an Atmel dev board that runs it and has a complete toolchain for development (NGW100 board). Has two 10/100 network ports.

Or a PIC32 dev module, which is also good enough to run uCLinux.

Reply to
swanny

You'd be surprised, the big banks still have a lot of COBOL embedded in their back office applications

Reply to
keithr

Mmmmm, I suspect a lot of people are fooled by the fact that it doesn't figure much in contracts/jobs. i.e. all new code is written in something else so cobol is dead.

..then they retired and left a mountain of code to be maintained and a single mention of exposure to cobol in my resume brought continual offers of cobol contracts(until I removed it).

If it ain't broke, then you don't fix it* and that cobol code was doing a lot of the back office grunt work and it stayed there until it couldn't be patched anymore and they found the millions to replace it.

I would be too surprised that in the banking and financial services world, that there isn't a mountain of it still sitting there quietly processing data. It might be the real reson why we don't have instant cheque clearance.

*I worked in one financial institution where they had a large refidgerator sized small mainframe sitting there doing zip/zilch/nada all day except for a single international dialup to collect a handful of numbers each night. It wasn't just that any other machine in the data centre or a PC could have easily taken on the job, but the fact that they didn't have the OS security rating. so it stayed.
Reply to
terryc

Matt Starr will be very interested.

Reply to
John Whorfin

All useful languages are like that. (not just computer programming languages, all.)

C is one of the smallestt languages. it's got fewer keywords and other symbols than most other languages.

that's like saying if aome automobiles crash then the concept of automibiles is flawed

--
?? 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net
Reply to
Jasen Betts

The problem was that a /temporary/ change - made to stabilise things while something else was being tested - got put back *without* being reviewed.

It doesn't matter *what* language you use, if the code isn't reviewed then using it could cause the proverbial monkeys to fly out your butt!

Yes, I use C, and prefer it. I learned it back in 1981, after learning Pascal in 1980, and then various assemblers and COBOLs and FORTRANs and DIBOL and SPL and SPAN and POWERflex and perl and SQL and C++ and ...

Cheers, Gary B-)

--
When men talk to their friends, they insult each other.
They don't really mean it.
When women talk to their friends, they compliment each other.
They don't mean it either.
Reply to
Gary R. Schmidt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.