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
No, I decided to go down the disclosure route - I made mention of my COBOL heritage in my profile. Sad reality is that if I ever get another commercial development gig it will be COBOL.
Ger
-
Pah! I was developing software on the System 36 and 38 when the AS/400 was still project Silverlake!! Dinosaurs? Proto-bloody-zoa mate!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Well if the vasectomy broke your heart, I'd strongly urge you to seek alternate medical services. I'm no doctor, but I'm pretty sure that's not how it's supposed to work.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
Jim Crafton wrote:
Well if the vasectomy broke your heart
Hardly
Jim Crafton wrote:
I'd strongly urge you to seek alternate medical services.
Too late, jobs done
Jim Crafton wrote:
I'm no doctor, but I'm pretty sure that's not how it's supposed to work.
Wasn't the most pleasent of everprience whilst being awake during the op.
Software Kinetics Wear a hard hat it's under construction
Metro RSS -
Same here... I think our AS/400 accounting system is COBOL, but I reach it through HTTP/XML queries... But back in the 90s, I did spend part of a summer teaching an old COBOL programmer transition to VB...
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)It could be worse, I had to port an RPG program to C once, now that was painful.
-
No, I decided to go down the disclosure route - I made mention of my COBOL heritage in my profile. Sad reality is that if I ever get another commercial development gig it will be COBOL.
Ger
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.
-
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!