Missing COBOL
-
For the first time in 20 years I have been tasked with writing a line of business application - it uses C#, WPF, SQL Server and Entity Framework I really miss COBOL and ISAM files.
RugbyLeague wrote:
I really miss COBOL and ISAM files.
What the hell for???? I took 3 semesters of COBOL in college, and if I never did it again I would be quite happy.
If it's not broken, fix it until it is
-
So the £30 million they spent on the new glass and brushed metal looking place has got a cupboard for an old 386? how thoughtful in this day and age..
no its a multi million pound super computer (it just emulates a 386)
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
You missed out on a shed load of fun if you've never done COBOL. Imagine drunk s_x without the guilty feeling; or the s_x or getting drunk to start with.
Reality is an illusion caused by a lack of alcohol
-
RugbyLeague wrote:
I really miss COBOL and ISAM files.
What the hell for???? I took 3 semesters of COBOL in college, and if I never did it again I would be quite happy.
If it's not broken, fix it until it is
I have no intention of using it again - just sometimes I hark back to a simpler age
-
Simplier? have you never dropped a box of punch cards?
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
TThat was before my time :-D
-
I have no intention of using it again - just sometimes I hark back to a simpler age
Simplier? have you never dropped a box of punch cards?
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
For the first time in 20 years I have been tasked with writing a line of business application - it uses C#, WPF, SQL Server and Entity Framework I really miss COBOL and ISAM files.
-
For the first time in 20 years I have been tasked with writing a line of business application - it uses C#, WPF, SQL Server and Entity Framework I really miss COBOL and ISAM files.
-
For the first time in 20 years I have been tasked with writing a line of business application - it uses C#, WPF, SQL Server and Entity Framework I really miss COBOL and ISAM files.
In my opinion, the main trouble with modern languages/frameworks/IDEs is the lack of good documentation, combined to their excessive size and complexity. You can't find primers that give you the basic recipes to get started. Instead you face unmanageable piles of uninformative, unstructured reference manuals. It was possible to learn Cobol. You will never really know C# nor WPF nor SQL Server nor Entity Framework. Programming has moved from a scientific discipline to a pathetic maze crossing. Sorry for the bad news ;-).
-
In my opinion, the main trouble with modern languages/frameworks/IDEs is the lack of good documentation, combined to their excessive size and complexity. You can't find primers that give you the basic recipes to get started. Instead you face unmanageable piles of uninformative, unstructured reference manuals. It was possible to learn Cobol. You will never really know C# nor WPF nor SQL Server nor Entity Framework. Programming has moved from a scientific discipline to a pathetic maze crossing. Sorry for the bad news ;-).
I like to think I am pretty good at C# and WPF - I have written compilers in C# and award winning inverted index database software in C# with a WPF GUI - but I know what you mean. There's a lot of programming by Google done these days - and if you find 100 articles answering your question you'll generally find 100 conflicting answers.
-
Actually I switched to the imaginatively named "PL/1" ("Programming Language One" - gosh, what an amazing name; when are we going to see "PL/2"?) which is like going from Heroine to Methadone! PL/1 was weird. It was like doing COBOL in FORTRAN. Thank god I was doing C on my own time to keep me sane!.
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
There was a cartoon at the time showing a COBOL Mum and a FORTRAN Dad cooing over their baby PL/1 offspring, while through the window, a whistling ALGOL Milkman was placing bottles on their doorstep.
All that is necessary for Evil to succeed is for Good Folks to keep voting for their Party. - Cornelius Thirp
-
I thought that was LINC (Lucky its not cobol or Laugh I nearly Cried, as it was nicknamed )
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
When I was using it (LINC 4?), it generated 1000s of lines of COBOL which often compiled with errors. Corrections had to be made to the generated COBOL source, when you could work out what LINC was attempting.
Bergholt Stuttley Johnson wrote:
Laugh I nearly Cried
Too bloody right. :laugh:
All that is necessary for Evil to succeed is for Good Folks to keep voting for their Party. - Cornelius Thirp
-
-
Simplier? have you never dropped a box of punch cards?
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
When I started college, the year ahead of me was still on punch cards for COBOL and FORTran. Fortunately for me, over Christmas break, a new VAX/VMS system was installed and I never had to use punch cards. Still had 3 semesters of COBOL though. When I started working, ironically, it was in FORTRan. The college no longer offered a course in FORTRan...
-
-
For the first time in 20 years I have been tasked with writing a line of business application - it uses C#, WPF, SQL Server and Entity Framework I really miss COBOL and ISAM files.
I did a phone billing program in '77 for the company I worked for that took the billing tape from the phone company and split out the charges to the different departments. Although I was a S/370 Assembler programmer, I decided to write the application in COBOL. We had two teams at the company, one programming in Assembler and the other in COBOL. The Assembler team thought the COBOL programmers needed help getting dressed in the mornings. I, therefore, was viewed as a traitor. My argument was that it was an accounting problem and therefore needed to be written in an accounting language. Actually I was more concerned with data conversion. The phone company billing tape used every possible form of data storage that the S/370 supported (EBCDIC, binary, BCD - packed and unpacked, etc.), I feared I would spend more time debugging the numeric conversions than I would the main application. In the end I did some pretty wild stuff for COBOL, like dynamic arrays and multi-pass data collection. In the end it worked magnificently and they rolled the report into the President's office were he got his jollies finding his secretary had made $70 worth of personal long distance calls. They then decided the reports needed to go no further down than VP's, even though I had designed the reports to go to the end users so they could police themselves. But the corporate culture was not what you knew, but what you had on someone else. In the end, they decided it was a good thing I had written it in COBOL, they could fluff off maintenance of it to the COBOL side. It was the last program I wrote for them and in COBOL. Afterwards I found I had made the program intelligent enough that it figured out changes to the data stream by itself and needed no further modifications (I was so proud to hear that, I had really worked hard to make it smart) and that there were many horror stories from mismanagement of the report from people getting fired over phone use to astronomical bills that could have been avoided if the information had been allowed to filter down to the intended recipients. I still have a copy of it in my files.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
I did a phone billing program in '77 for the company I worked for that took the billing tape from the phone company and split out the charges to the different departments. Although I was a S/370 Assembler programmer, I decided to write the application in COBOL. We had two teams at the company, one programming in Assembler and the other in COBOL. The Assembler team thought the COBOL programmers needed help getting dressed in the mornings. I, therefore, was viewed as a traitor. My argument was that it was an accounting problem and therefore needed to be written in an accounting language. Actually I was more concerned with data conversion. The phone company billing tape used every possible form of data storage that the S/370 supported (EBCDIC, binary, BCD - packed and unpacked, etc.), I feared I would spend more time debugging the numeric conversions than I would the main application. In the end I did some pretty wild stuff for COBOL, like dynamic arrays and multi-pass data collection. In the end it worked magnificently and they rolled the report into the President's office were he got his jollies finding his secretary had made $70 worth of personal long distance calls. They then decided the reports needed to go no further down than VP's, even though I had designed the reports to go to the end users so they could police themselves. But the corporate culture was not what you knew, but what you had on someone else. In the end, they decided it was a good thing I had written it in COBOL, they could fluff off maintenance of it to the COBOL side. It was the last program I wrote for them and in COBOL. Afterwards I found I had made the program intelligent enough that it figured out changes to the data stream by itself and needed no further modifications (I was so proud to hear that, I had really worked hard to make it smart) and that there were many horror stories from mismanagement of the report from people getting fired over phone use to astronomical bills that could have been avoided if the information had been allowed to filter down to the intended recipients. I still have a copy of it in my files.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
Nice to hear some good things about COBOL. I have been going back in time; started out with the new languages in .Net, C, VB6, and finally ACOB. It doesn't matter what the language is, just do what you have to do with whatever you have and code for clarity; don't make it difficult to analyze or read. It has taken me more than a year to flow chart a program so I know what it does and doesn't do because there is no documentation. It is only one of thousands of batch runs and TIP programs; I think I have plenty to do until 2027:cool:
-
For the first time in 20 years I have been tasked with writing a line of business application - it uses C#, WPF, SQL Server and Entity Framework I really miss COBOL and ISAM files.
You don't have to miss them. You can do all that using Visual COBOL, a full-fledged member of Visual Studio 2010 and 2012. (Also available for Eclipse.) Go to the Micro Focus web site and follow the link for a free trial version. For a slightly less COBOL-hostile crowd, visit/join the Microfocus Community. You will find out that we do a bit more than COBOL.
Tom Morrison Micro Focus
-
You are thinking perhaps of a Kobold[^]?
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
-
For the first time in 20 years I have been tasked with writing a line of business application - it uses C#, WPF, SQL Server and Entity Framework I really miss COBOL and ISAM files.
Good luck with that. I've been writing LOB apps for 25 years now. The only one of those "tools" that might be helpful is the Transact-SQL in SQL server. LOB apps are procedural by definition. Humans don't think in objects. OOP simply doesn't work (unless you have a team including a full-time documenter to remember all those ?@#?% objects). And don't forget about money. None of the current MS products handle currency transactions properly unless you decide to work in pennies. They all produce rounding errors that you have to handle. No version of C will do money properly. Especially when chaining transactions ((Qty * price = sale)* sales tax) for example. Any multiplication involving fractions of percentages ending in 5 (1.45% for example)will round unpredictably. COBOL uses BCD math that produces accurate results. We are actually considering moving our main app into COBOL because the "modern" tools are too complex and way, way too verbose.