Missing COBOL
-
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.
-
ISAM for sure, but I can't fully agree with COBOL.
Reality is an illusion caused by a lack of alcohol
-
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 :) I got into programming because I was working at a printers which did huge batch runs of pension bonus notices etc - I started just as chap setting up the batch runs but only 4 could be run at once and they could take days so I had plenty of spare time - so I taught myself COBOL and wrote games - just simple things such as card games and connect 4 type things - when the company advertised for a programmer I put my name forward - they were surprised I knew COBOL as I had never mentioned it to management - so I told them I had been writing games on their computer - which they weren't keen on - but I told my boss where to look on the system for the games menu - 5 minutes later he called me to say none of them worked as he couldn't log in - then I realised - his name was David and I had hooked into the D key throughout the system so it dropped out of the games system every time D was pressed in case he came into our office - he was logging in using his forename and being kicked out - that took some explaining but I got the job.
-
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.
Dead Right COBOL is lousy at virtually everything except one - writing business logic where it's great - ever try writing a multi level Bill of Materials explosion in C#
-
Nice :) I got into programming because I was working at a printers which did huge batch runs of pension bonus notices etc - I started just as chap setting up the batch runs but only 4 could be run at once and they could take days so I had plenty of spare time - so I taught myself COBOL and wrote games - just simple things such as card games and connect 4 type things - when the company advertised for a programmer I put my name forward - they were surprised I knew COBOL as I had never mentioned it to management - so I told them I had been writing games on their computer - which they weren't keen on - but I told my boss where to look on the system for the games menu - 5 minutes later he called me to say none of them worked as he couldn't log in - then I realised - his name was David and I had hooked into the D key throughout the system so it dropped out of the games system every time D was pressed in case he came into our office - he was logging in using his forename and being kicked out - that took some explaining but I got the job.
Sweet :laugh: I used to work as a computer operator third shift and would be given a list of programs to run for the night. I had made an agreement with management that if there was any time left over, I could run my own programs. So I'd rewrite the programs to make them run faster. :-D FORTRAN was the preferred language there, however I also wrote system utilities to make operations easier in Assembler. One program I (re)wrote was a program to play Battleship against a human opponent. When I went to the company that I wrote the phone billing program for, I adapted the Battleship program so it would run on the local dialect. I showed if off to my boss and as he played the game, I noticed that he had placed his ships in such a manner that the primary hunt pattern was going to hit every one of them. There was no way he was going to win, so he came away impressed. But speaking of Dave, at one job I had a Macintosh that I had replaced the error beep with 2001: A Space Odyssey's "I'm sorry Dave, I'm afraid I can't do that." And happened to demonstrate it to a coworker named Dave. After he listened to it, his body language went tense, he pushed himself away from the desk, and not taking his eyes off the computer asked, "How did it know my name was Dave?" It never occurred to me that he didn't know that soundbyte. :wtf: It made me want to load Cheech & Chong's "Dave's not here!" just to mess with him more.
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.
-
Sweet :laugh: I used to work as a computer operator third shift and would be given a list of programs to run for the night. I had made an agreement with management that if there was any time left over, I could run my own programs. So I'd rewrite the programs to make them run faster. :-D FORTRAN was the preferred language there, however I also wrote system utilities to make operations easier in Assembler. One program I (re)wrote was a program to play Battleship against a human opponent. When I went to the company that I wrote the phone billing program for, I adapted the Battleship program so it would run on the local dialect. I showed if off to my boss and as he played the game, I noticed that he had placed his ships in such a manner that the primary hunt pattern was going to hit every one of them. There was no way he was going to win, so he came away impressed. But speaking of Dave, at one job I had a Macintosh that I had replaced the error beep with 2001: A Space Odyssey's "I'm sorry Dave, I'm afraid I can't do that." And happened to demonstrate it to a coworker named Dave. After he listened to it, his body language went tense, he pushed himself away from the desk, and not taking his eyes off the computer asked, "How did it know my name was Dave?" It never occurred to me that he didn't know that soundbyte. :wtf: It made me want to load Cheech & Chong's "Dave's not here!" just to mess with him more.
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.
Excellent :laugh:
-
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.
I agree - the LOB app I am writing isn't even that complicated but the tools are hideous - Entity Framework is beyond awful just for some simple data access
-
I agree - the LOB app I am writing isn't even that complicated but the tools are hideous - Entity Framework is beyond awful just for some simple data access