COBOL
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I work at a company that has an IBM Mainframe for the main part of the business. I develop .NET applications that must interface with it and its done in 2 flavors, TCP/IP Sockets interfacing with COBOL and a middleware solution that interfaces with the COBOL to expose web services. Its arcane and extremely difficult to code for. Needless to say my error handling techniques are top notch! And we employ at least 40 COBOL programmers to maintain the mainframe. Good news is the system is converting out of the mainframe but it will take 2 years to do it.
- D. Schrenker ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "If we knew what we were doing, it wouldn't be called research." - Albert Einstein
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I get pings from recruiters now and again because they see COBOL (from 1997 and earlier) on my resume. Despite the fact that I list technologies such as ASP.NET 4, Linq, Java, et cetera first on my resume, they somehow operate under the delusion that I'd be interested in going backwards 20 years in time. I did get an email yesterday from someone wanting experience with (among other things) EDL. For those that don't know, EDL was an assembler-like language which ran on IBM Series/1s. IBM discontinued those beasts in the early 90s-ish. Where I was working at that time did some kind of translation to C on RS/6000s becuase that was clearly more sensible than writing the system natively. Sigh. I was almost interested enough to write back to this recruiter and ask how her client is still running EDL 20 years after IBM discontinued support for the hardware on which it ran, but that passed. Actually, that wasn't a horrible way to start out development. Tiny little boxes, so it forced you to be conscious of resources. Debugging was getting a paper listing, which had the machine code printed to the left of the EDL code, setting breakpoints at memory addresses and interrogating data by address. Learned a lot more about what's "under the hood" than I suspect is common today. Even though there were some good experiences, I sure am glad to have moved on.
-
'Probably' interfacing to a COBOL system 'somewhere'. Our app communicates to everything via FIX and so for all I know there's a COBOL system out there, somewhere, talking ot us. :~
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
I have to process data from ABNAmro - it arrives as a big, variable content but fixed length record, text file and is obviously generated from an old COBOL system because the (PDF!) data description for the records uses various COBOL number formats. The newer fields, however, tend to use slightly more 'conventional' number layouts... As I have a system here for reading COBOL data directly providing the schema is available, I did ask if they had an original or XML schema, but got no reply 8) So I had to recreate the schema 'by hand' - what I actually did was use Access to build relationship and field descriptor tables and then I wrote a bit of VBA to emit an XML schema from that, which - when fed into the data editor - allowed me to read the records held therein...
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Did teach Cobol in evening school in my local college for a year; Was "formally" taught Cobol by my first full-time employer (I'd used Fortran for previous commercial work) In school, my first major project was - don't laugh - a Cobol interpreter, itself written in interpreted Basic. We had a dial-up link to a University machine, had to enter code via punched tape. Having learnt the entire Basic language syntax I wanted more, had heard of Cobol, and wanted to learn it. So got a couple of books on its syntax and wrote an interpreter, so I could write some Cobol programs. With all i/o being either via the keyboard or punchtape, even double-interpreted cobol ran fast enough to keep up with whatever input you threw at it. Wasn't a complete Cobol implementation, but was a true subset and some of the programs subsequently compiled and ran first-time on IBM360 mainframes... That was back in 1969 so this is my 6th decade of programming... :omg: and whilst I still use "Basic" I've not used Cobol for almost 20 years.
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I was working on COBOL directly until just over 2 years ago when my contract wasn't renewed. Haven't worked on COBOL since. But I was mostly a COBOL programmer for 25+ years, with a little SQL, Access, and VB/VBA thrown in for the last few years. No COBOL now - just SQL, Access, and VB/VBA now - maybe some Java and/or .NET in the near future for me too. :) Jerry
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I'm 33 years old and I used to be a maniframe COBOL progammer for 8 years. I've been coding in C#.Net for the past 7 years, though. I learned COBOL in a technical school during the years of the Y2K conversion. I started professionally when I was 18 years old and quickly became very bored with what I was doing. So, thank God for .Net and the opportunity for me to learn it. This is the interesting part. I worked at a company that will remain nameless, but it's a very large broadcasting company. Anyhow, they re-hosted their mainframe COBOL code to Windows servers into using COBOL.Net. Yeah, I said it. COBOL.Net. It's made by Fujitsu. If you think COBOL is horrible, you should see the COBOL.Net syntax. My God! Anyhow, as far as COBOL being extinct...It is not. It is very much alive and probably accounts for as much as 75% of all of the lines of code in the world. The problem is that there is no new COBOL development and no one really wants to pay to rewrite legacy COBOL systems because why fix something that isn't broken. So, you will integrate with a lot of AS400 or mainframe COBOL systems. I believe that the mainframe actually has the ability to interpret and use Web services now. Well, that's my comment. I'll be interested to see the replies.... :)
Mark Harrington "If GM had kept up with technology like the computer industry has, we would all be driving $25 cars that got 1000 MPG" --Bill Gates
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I get pings from recruiters now and again because they see COBOL (from 1997 and earlier) on my resume. Despite the fact that I list technologies such as ASP.NET 4, Linq, Java, et cetera first on my resume, they somehow operate under the delusion that I'd be interested in going backwards 20 years in time. I did get an email yesterday from someone wanting experience with (among other things) EDL. For those that don't know, EDL was an assembler-like language which ran on IBM Series/1s. IBM discontinued those beasts in the early 90s-ish. Where I was working at that time did some kind of translation to C on RS/6000s becuase that was clearly more sensible than writing the system natively. Sigh. I was almost interested enough to write back to this recruiter and ask how her client is still running EDL 20 years after IBM discontinued support for the hardware on which it ran, but that passed. Actually, that wasn't a horrible way to start out development. Tiny little boxes, so it forced you to be conscious of resources. Debugging was getting a paper listing, which had the machine code printed to the left of the EDL code, setting breakpoints at memory addresses and interrogating data by address. Learned a lot more about what's "under the hood" than I suspect is common today. Even though there were some good experiences, I sure am glad to have moved on.
-
Moving to it? From what? RPG? Assembler? That's pretty funny.
Mark Harrington "If GM had kept up with technology like the computer industry has, we would all be driving $25 cars that got 1000 MPG" --Bill Gates
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I learned it at college in 1973 along with FORTRAN. Although, mostly despised at first by the Engineering & scientific community of the time, i currently consider its verbose structured more practical now (if properly modernized), because the current "modern" languages are more difficult to master every day. Not to mention the great variety of them. Back in the days, we basically had FORTRAN for Science in general, and COBOL for Business. At the time, one was a Systems Analyst and one had to analyze the system to mechanized with computers, write the program, test, debug it, implement and maintain it and do hardware maintenance, also. Nowadays, you cannot do all this due to the much bigger complexity of the systems environment, which required specialization. But, the sometimes unnecessary complexity of the current programming languages did not help, either. COBOL had a wonderful simplicity, because humans do talk that way. Never underestimate old things, just because they are old, as long as they perform and deliver. Dante
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
COBOL is everywhere. Many of the trading systems still use it. I'm accessing COBOL servers by using web services everyday.
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Yep. I work on COBOL. Every day. Even today! :) AS/400, COBOL, DB2, REXX and JCL. All the age old technology is still used. Very robust and secure - No wonder they have stood the test of time - at least for so long. :) On our system, we have codes written almost 30-35 years ago! Its definitely fun. :)
-- There's no such thing as perfect. Someone always finds something amiss. And when nobody says anything, you feel something's amiss!
-
Yep. I work on COBOL. Every day. Even today! :) AS/400, COBOL, DB2, REXX and JCL. All the age old technology is still used. Very robust and secure - No wonder they have stood the test of time - at least for so long. :) On our system, we have codes written almost 30-35 years ago! Its definitely fun. :)
-- There's no such thing as perfect. Someone always finds something amiss. And when nobody says anything, you feel something's amiss!
-
I know a company that still uses COBOL. It was their language standard because the managers had written in it prior to becoming managers. The AS/400 still has a COBOL compiler and they still add new featrues to it. They also support RPG in several different flavors. I've developed many programs in COBOL and RPG. They are like any other language, write the instruction properly and it will produce the expected results. COBOL is very wordy compared to most languages today and that seems to be its biggest downfall.
Ah yes, our motto was "Why use one line when two will do"!
Ger
-
I get pings from recruiters now and again because they see COBOL (from 1997 and earlier) on my resume. Despite the fact that I list technologies such as ASP.NET 4, Linq, Java, et cetera first on my resume, they somehow operate under the delusion that I'd be interested in going backwards 20 years in time. I did get an email yesterday from someone wanting experience with (among other things) EDL. For those that don't know, EDL was an assembler-like language which ran on IBM Series/1s. IBM discontinued those beasts in the early 90s-ish. Where I was working at that time did some kind of translation to C on RS/6000s becuase that was clearly more sensible than writing the system natively. Sigh. I was almost interested enough to write back to this recruiter and ask how her client is still running EDL 20 years after IBM discontinued support for the hardware on which it ran, but that passed. Actually, that wasn't a horrible way to start out development. Tiny little boxes, so it forced you to be conscious of resources. Debugging was getting a paper listing, which had the machine code printed to the left of the EDL code, setting breakpoints at memory addresses and interrogating data by address. Learned a lot more about what's "under the hood" than I suspect is common today. Even though there were some good experiences, I sure am glad to have moved on.
Funny, I worked with EDL as well. I thought I was the only person left on earth that even remembered it!
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I Learned COBOL in 1964 from the original Military COBOL manuals promoted by Naval Rear Admiral Grace Hopper http://en.wikipedia.org/wiki/Grace_Hopper[^] the original promoter of the language. It was designed to get control back from the Hardware manufacturers, like IBM, by making a machine-independent, easy to use language for Common Business Oriented programing. I used it for 20 years on various platforms: IBM, WANG VS, DEC VAX; MicroFocus and RM on UNIX, Linux, and Windows. The WANG VS was the most powerful COBOL machine ever created. Development was an order of magnitude easier than IBM and performance an order of magnitude faster. I still have MicroFocus and RM COBOL source that is maintained by some of our Team. We still do custom work each year. In the 80's I wrote a comprehensive Distribution System for the WANG VS that was very successful for me. I sold it years ago. I am not sure what its current status is. I taught COBOL at Universities for several years. This was normally in a File Processing class. Most students taking this class were juniors. They had taken at least one other language already, Normally PASCAL or FORTRAN. The students could pick from COBOL, PASCAL, or Fortran to do the Labs. The Labs used a DEC VAX. I taught them the Syntax for the File Processing statements for each language If they had any prior COBOL exposure it was normally the slow, buggy Microsoft version. So they were inclined to pick PASCAL or FORTRAN. They did not consider that the versions for the VAX would be vastly superior. The students using COBOL for the Labs wrote about 30% of the code that the others did. Their code ran much faster and cleaner. Since the class was group presentations, they special purpose of COBOL became clear to all by the end of the semester. To me, Perl was the COBOL of the 80's and 90's in an Internet setting. It has had a similar life-cycle. I still create and maintain Perl scripts on Linux boxes. COBOL is not dead nor is Perl. Both are actively in use and have maintained Application source libraries. You can see this by checking the code library statistics. Neither will ever be as popular as they once were. COBOL has been largely replaced by Database and SQL Applications. Perl has been replaced by Python, JavaScript, and Node.js. If you are interested in the history of COBOL, and how it helped
-
Really? That recent? Wow. I've only ever heard about COBOL and how that went extinct by the same meteorite that did the dinosaurs. To have actually worked on/with a living fossil at college, 10 years ago? Wow. OT: It took me a few days to get that blasted song out of my head.
If the post was helpful, please vote, eh! Quote worthy: I hereby claim this thread in the name of Drivel. Now and forever, defiant to the end. What is Multiple Sclerosis[^]? Food
Worked with COBOL for two years starting in '76 (NOT 1876!! Nor 76 BC) Then went to blessed FORTRAN for a couple of years except for one project my partner insisted had to be in COBOL. What a pain! (Code and partner.) :laugh: The closest I got to it after that was a SQL ETL project a few years back. The formatting looked like it was built for COBOL.
-
Chris Meech's post[^] piqued my interest because I've been talking to a few guys lately, on the quiet so as not to bust their cover, who do COBOL. So it got me wondering: who's doing COBOL directly, or at the least, interfacing with COBOL modules or back end systems?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
This year my boss made the decision to buy an ERP to run the business. We had many candidates and one of them was Oracle's PeopleSoft. At some point we had a list of the software that comprised PeopleSoft and one of the components is Microfocus COBOL and not only a runtime license but a full developer license. In the end we did not buy that ERP but for a few days we were thinking that we had to learn COBOL...